extensions to g rsvp te for point to multipoint te lsps draft raggarwa mpls rsvp te p2mp 01 txt
Skip this Video
Download Presentation
Extensions to G/RSVP-TE for Point to Multipoint TE LSPs <draft-raggarwa-mpls-rsvp-te-p2mp-01.txt>

Loading in 2 Seconds...

play fullscreen
1 / 16

Extensions to G/RSVP-TE for Point to Multipoint TE LSPs <draft-raggarwa-mpls-rsvp-te-p2mp-01.txt> - PowerPoint PPT Presentation

  • Uploaded on

Extensions to G/RSVP-TE for Point to Multipoint TE LSPs &lt;draft-raggarwa-mpls-rsvp-te-p2mp-01.txt&gt;.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Extensions to G/RSVP-TE for Point to Multipoint TE LSPs <draft-raggarwa-mpls-rsvp-te-p2mp-01.txt>' - jontae

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
extensions to g rsvp te for point to multipoint te lsps draft raggarwa mpls rsvp te p2mp 01 txt

Extensions to G/RSVP-TE for Point to Multipoint TE LSPs<draft-raggarwa-mpls-rsvp-te-p2mp-01.txt>

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)

achievements since san diego
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 => v01.txt has been made available on the web page <http://www.labn.net/~dimitri>
state management 1
State management (1)
  • Issue: solve incremental updates/aggregate state management and potential fragmentation on ERO expansion
  • Proposal: <sub-group originator ID, sub-group ID>
    • 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 <sub-group originator ID, sub-group ID> tuple is globally unique.
state management 2
State management (2)
  • Two ways to encode the above information:

a) Encode the <sub-group originator ID, sub-group ID> tuple in the P2MP sender template (new sender-template C-type value).

b) Encode the <sub-group originator ID, sub-group ID> as the “first” object of the <P2P_sub_LSP_ descriptor list>

  • Polling:
    • all agree on <sub-group originator ID, sub-group ID> tuple; those that favor b) encoding can live or are not opposed to solution a) encoding

=> do we get consensus of the group ?

open issues 1
Open Issues (1)

1) STYLE usage:

  • SE vs FF style usage
  • conditions for resource sharing

=> new section needed

2) P2MP SENDER_TEMPLATE object and FILTER_SPEC object encoding specifics  

=> Section 24.2

3) Review re-merge/cross-over conditions + re-merging or re-pair (case when data plane is not blocking)

=> Section 23

open issues 2
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 ?

=> 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 ?) => Section 3.4, 10 and 11

6) Stitching mechanism detail (P2MP and P2MP, P2MP and P2P) – in the scope of inter-domain effort

next steps
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


  • 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
achievements since seoul 1
Achievements since Seoul (1)
  • A single solution framework: merge between
    • <draft-raggarwa-mpls-p2mp-te-02.txt>
    • <draft-yasukawa-mpls-p2mp-rsvp-te-04.txt>
  • 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
    • <NO_CONSENSUS> 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)
achievements since seoul 2
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 > 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 (=> 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
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
open issue 2 incremental state update
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 => 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
open issue 3 re optimization
Open Issue 3: Re-optimization

Impact of partial re-optimization requires extra identifier => 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) ?
open issue 4 re merging
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 => differentiate case with and without common segment after "re-merging" point
  • Data plane impact (blocking issue)
  • Control plane issue:
    • aggregate state on “merging point” => if Path/Refresh message with an incremental semantic then issue disappears
    • since same SESSION and SENDER_TSPEC objects => 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
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
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
  • <draft-raggarwa-mpls-rsvp-p2mp-te-00.txt> is a reasonable basis for continuing this work
  • Consensus to make this document a MPLS WG I-d ?