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

Loading...

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



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

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

Description:

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
Category:

less

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

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


1
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
    L.Wei)

2
Achievements since San Diego
  • Succeed in delivering a consistent merged
    solution
  • 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
    mitrigt

3
State management (1)
  • Issue solve incremental updates/aggregate state
    management and potential fragmentation on ERO
    expansion
  • 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
    value.
  • 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.

4
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 ?

5
Open Issues (1)
  • 1) STYLE usage
  • SE vs FF style usage
  • conditions for resource sharing
  • gt new section needed
  • 2) P2MP SENDER_TEMPLATE object and FILTER_SPEC
    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

6
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
    effort

7
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
    g00008.htmlgt
  • 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

8
Backup Slides
9
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
    destination
  • SENDER_TEMPLATE and FILTER_SPEC objects remain
    unchanged
  • 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
    sub-LSPs
  • When multiple P2P sub-LSPs in one Path message
    ERO/RRO compression scheme and processing (one
    sub-ERO per P2P sub-LSP)

10
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
    MTU)
  • support aggregated state management and
    incremental state updates
  • metrics messaging comparison semantic impact
    of protocol extensions including on existing
    implementation
  • node capabilities to be assessed and detailed in
    a routing specific document
  • Single vs Multiple P2P sub-LSP in single Path
    message
  • 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)

11
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
    updates

12
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
    idempotent.
  • 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
    supported

13
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
    (functional)
  • 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
    replication
  • from req i-d such mechanism SHOULD be defined
  • Is it acceptable to only support full tree
    re-optimization (no data replication) ?

14
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)

15
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

16
Conclusion Next steps
  • Building blocks of the single solution are in
    place
  • Remaining open issues are being discussed and
    should be resolved within a short timeframe
  • Further progress achieved since draft was
    published
  • More discussion from the MPLS WG list is also
    expected
  • 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