Extensions to G/RSVP-TE for Point to Multipoint TE LSPs 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 Seoul (1) A single solution framework: merge between – 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 – 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) 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 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 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 2: Incremental state update Two documented proposals –Based on refresh reduction –incremental State/Message (iPath/iResv, iPathTear/iResvTear) Evaluation criteria –is capability provided when refresh reduction is NOT supported –is state management based on {session, sender_template} –does adding, moving or deleting a sub-set of sub-LSPs, necessitate creation of new state and separate management of the old states(s) (timed out ?) –how the method solves (~ implementation specific) these properties => performance gain vs cost of the mechanisms introduced Solution direction: –new proposal based on sub-Group ID (sender_template encoding to be refined) –to be further elaborated

Open Issue 3: Re-optimization Impact of partial re-optimization requires extra identifier => P2P Sub-LSP ID (+ scope) Refers to the following requirements: 1)Do we need partial re-optimization ? –definition of partial re-optimization (functional) –mechanism of partial re-optimization (signaling) 2)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 3)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 => 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 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 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 is a reasonable basis for continuing this work Consensus to make this document a MPLS WG I-d ?