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

Backup Slides

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