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

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

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 => v01.txt has been made available on the web page <http://www.labn.net/~dimitri>

3. 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.

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

5. 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

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

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 <http://www.cell-relay.com/mhonarc/mpls/current/msg00008.html> • 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 • <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)

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

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

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