Extensions to GRSVPTE for Point to Multipoint TE LSPs draftraggarwamplsrsvptep2mp01.txt - PowerPoint PPT Presentation


PPT – Extensions to GRSVPTE for Point to Multipoint TE LSPs draftraggarwamplsrsvptep2mp01.txt PowerPoint presentation | free to view - id: 9dcf5-MWQwM


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

Extensions to GRSVPTE for Point to Multipoint TE LSPs draftraggarwamplsrsvptep2mp01.txt


1) STYLE usage: SE vs FF style usage. conditions for resource ... Investigate potential usage for incremental updates. Open Issue 2: Incremental state update ... – PowerPoint PPT presentation

Number of Views:43
Avg rating:3.0/5.0
Slides: 17
Provided by: papa3


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Extensions to GRSVPTE for Point to Multipoint TE LSPs draftraggarwamplsrsvptep2mp01.txt

Extensions to G/RSVP-TE for Point to Multipoint
TE LSPs ltdraft-raggarwa-mpls-rsvp-te-p2mp-01.txtgt
  • R.Aggarwal, D.Papadimitriou, and S.Yasukawa
    (Editors) and contributors (L.Berger, I.Bryskin,
    D.Cheng, J.Drake, A.Farrel, M.Jork, H.Kojima,
    K.Kompella, A.Kullberg, J-L Leroux, A.Malis,
    K.Sugisono, G.Swallow, M.Uga, J.-P.Vasseur, and

Achievements since San Diego
  • Succeed in delivering a consistent merged
  • Resolution on sub-group based state management
    and update (Path and Resv message)
  • Devise methods for implicit and explicit teardown
    (PathTear message)
  • Revision of the FF and SE flow descriptor lists
    (Resv message)
  • Revision of the remerging conditions and
    processing rules
  • the change log v00 gt v01.txt has been made
    available on the web page lthttp//www.labn.net/di

State management (1)
  • Issue solve incremental updates/aggregate state
    management and potential fragmentation on ERO
  • Proposal ltsub-group originator ID, sub-group IDgt
  • Sub-group originator ID TE Router-id of the node
    (ingress, transit) that sets the sub-group ID
  • Sub-group ID identifier (in the context of the
    sub-group originator ID) used to differentiate
    multiple Path messages that signal state for the
    same P2MP LSP Tunnel.
  • The ltsub-group originator ID, sub-group IDgt tuple
    is globally unique.

State management (2)
  • Two ways to encode the above information
  • a) Encode the ltsub-group originator ID, sub-group
    IDgt tuple in the P2MP sender template (new
    sender-template C-type value).
  • b) Encode the ltsub-group originator ID, sub-group
    IDgt as the first object of the ltP2P_sub_LSP_
    descriptor listgt
  • Polling
  • all agree on ltsub-group originator ID, sub-group
    IDgt tuple those that favor b) encoding can live
    or are not opposed to solution a) encoding
  • gt do we get consensus of the group ?

Open Issues (1)
  • 1) STYLE usage
  • SE vs FF style usage
  • conditions for resource sharing
  • gt new section needed
    object encoding specifics  
  • gt Section 24.2
  • 3) Review re-merge/cross-over conditions
    re-merging or re-pair (case when data plane is
    not blocking)
  • gt Section 23

Open Issues (2)
  • 4) Re-optimization
  • single/subset of P2P sub-LSP within a sub-group
  • single/subset of sub-groups
  • note requires consensus whether re-optimization
    may be performed on P2P sub-LSP basis or/and on
    sub-tree basis ?
  • gt Section 19
  • 5) Sub-ERO compression re-organisation (after
    grafting/pruning) device specific mechanisms for
    SERO such re-organisation (or is the current
    proposed text sufficiently tackling the issue ?)
    gt Section 3.4, 10 and 11
  • 6) Stitching mechanism detail (P2MP and P2MP,
    P2MP and P2P) in the scope of inter-domain

Next Steps
  • revision.1 (i.e. draft-raggarwa-mpls-rsvp-te-p2mp-
    01.txt) will be submitted after meeting as
    working i-d
  • see mail on the MPLS WG mailing list
  • lthttp//www.cell-relay.com/mhonarc/mpls/current/ms
  • revision.2 with revisited organization
    terminology before starting over
  • to be achieved before starting incorporating new
    discussion point resolutions
  • this should be closed by end-november at most
  • technical points to be addressed from this rev.2

Backup Slides
Achievements since Seoul (1)
  • A single solution framework merge between
  • ltdraft-raggarwa-mpls-p2mp-te-02.txtgt
  • ltdraft-yasukawa-mpls-p2mp-rsvp-te-04.txtgt
  • P2MP TE LSP set of P2P sub-LSPs, each from
    ingress to the leaf
  • P2MP TE LSP Identification
  • New P2MP SESSION C-Type with P2MP Id as
  • SENDER_TEMPLATE and FILTER_SPEC objects remain
  • P2P sub-LSP identification
  • P2P SUB-LSP object with leaf destination address
  • ltNO_CONSENSUSgt on sub-LSP ID in P2P SUB-LSP or
    sub-Group_ID in SENDER_TEMPLATE object
  • Multiple Path messages can be used to signal a
    single P2MP TE LSP
  • Each Path message signals one or more P2P
  • When multiple P2P sub-LSPs in one Path message
    ERO/RRO compression scheme and processing (one
    sub-ERO per P2P sub-LSP)

Achievements since Seoul (2)
  • Legacy LSR support method(s)
  • LSP stitching
  • ( P2P FA-LSP when applicable)
  • Fast Reroute (MPLS only) Facility based Detour
    style protection
  • Reach consensus on solution requirements
  • support full refresh mechanisms (summary refresh
    optional but recommended)
  • address message fragmentation (message size gt
  • support aggregated state management and
    incremental state updates
  • metrics messaging comparison semantic impact
    of protocol extensions including on existing
  • node capabilities to be assessed and detailed in
    a routing specific document
  • Single vs Multiple P2P sub-LSP in single Path
  • dedicated section on refresh reduction (gt
    applicability of RFC 2961)
  • dedicated section on incremental state updates
    and aggregate state management
  • Remaining open issues identified and are under
    discussion (next slides)

Open Issue 1 State management
  • As part of the state management discussion
  • Issue sub-Group ID versus sub-LSP ID
  • Sub-Group ID identifier of destination (set)
  • Extreme case sub LSP_ID on the other end
    equivalent to the P2MP LSP_ID (ingress control)
  • Disambiguate message size (single Path) and group
    Path message together that collectively represent
    the P2MP TE LSP
  • Fragmentation and/or Aggregated state but still
    require an ID for sub-tree re-optimization
  • Investigate potential usage for incremental

Open Issue 2 Incremental state update
  • RSVP RFC2205 and G/RSVP-TE RFC3473/RFC3209
  • signaling of resource reservation by full state
    communication and synchronization in each state
    advertisement message
  • RFC2205 Path and Resv messages are
  • Refresh Overhead Reduction Extensions RFC2961
  • improvements to message handling and scaling of
    state refreshes
  • does not modify full state advertisement nature
    of Path/Resv messages
  • Full state advertisement in Path/Resv has some
    drawbacks when only portion(s) of previously
    advertised state modified gt processing overhead
    in identifying what state portion has changed
    message overhead of sending full state
  • Extend RSVP to reduce message size and state
    processing associated w/ state change (support
    incremental state updates and optimize state
    change processing) - on a hop-by-hop basis and
    particularly when Refresh Reduction is also

Open Issue 3 Re-optimization
  • Impact of partial re-optimization requires extra
    identifier gt P2P Sub-LSP ID ( scope)
  • Refers to the following requirements
  • Do we need partial re-optimization ?
  • definition of partial re-optimization
  • mechanism of partial re-optimization (signaling)
  • Do we need partial re-optimization if there is
    data replication during transient ?
  • there are mechanisms that are minimizing data
  • from req i-d such mechanism SHOULD be defined
  • Is it acceptable to only support full tree
    re-optimization (no data replication) ?

Open Issue 4 Re-merging
  • Occurs when nodes receives two streams from at
    least two different P_HOPs and data sent to the
    same or multiple outgoing interfaces gt
    differentiate case with and without common
    segment after "re-merging" point
  • Data plane impact (blocking issue)
  • Control plane issue
  • aggregate state on merging point gt if
    Path/Refresh message with an incremental semantic
    then issue disappears
  • since same SESSION and SENDER_TSPEC objects gt
    rely on P2P sub LSP_ID
  • Example where re-merging would be allowed change
    color/priority in the middle of the P2MP tree
    (per sub-tree due to administrative policies)

Open Issue 5 Recovery
  • There is general agreement on Fast Reroute
    applicability (MPLS only)
  • Facility based protection
  • Detour style protection
  • Fast Reroute text to be moved in a separate
    document once the base text is mature
  • GMPLS remains to be covered

Conclusion Next steps
  • Building blocks of the single solution are in
  • Remaining open issues are being discussed and
    should be resolved within a short timeframe
  • Further progress achieved since draft was
  • More discussion from the MPLS WG list is also
  • ltdraft-raggarwa-mpls-rsvp-p2mp-te-00.txtgt is a
    reasonable basis for continuing this work
  • Consensus to make this document a MPLS WG I-d ?
About PowerShow.com