1. IETF 68, MPLS WG, Prague P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels draft-leroux-mpls-p2mp-te-bypass-01.txt J.L. Le Roux (France Telecom) R. Aggarwal (Juniper) J.P. Vasseur (Cisco Systems) M. Vigoureux (Alcatel-Lucent)

2. Limitations of the P2P Bypass approach node protection l Using P2P bypass tunnels for P2MP LSP node protection leads to traffic duplication on some links during failure R1R1 R2R2 R5 R4R4 R3 Duplication Protected P2MP TE-LSP P2P Bypass tunnel

3. Limitations of the P2P Bypass approach l Using P2P bypass tunnels for P2MP LSP link protection may also lead to traffic duplication on some links during failure R1 R3 Duplication R2 Protected P2MP TE-LSP P2P Bypass tunnel

4. Solution Overview l To overcome these limitations this draft defines extensions to the FRR procedures to support P2MP Bypass tunnels è Retain scalability advantages of MPLS label stacking è Avoids sending multiple copies of a packet on some links during failure l During failure the traffic is tunneled within one or more P2MP bypass towards the set of Merge Points thanks to label stacking è Inner label = backup LSP Label, used on the MP to forward traffic to the protected LSP. è Outer label = P2MP Bypass tunnel Label l To avoid data replication on the PLR, a same inner label is assigned by the PLR to all MPs on a given P2MP bypass è following RSVP-TE Upstream Label Assignment procedure –draft-ietf-mpls-rsvp-upstream l P2MP bypass may be used in conjunction with P2P bypass: they are not exclusive

5. Protection with P2MP Bypass R1R1 R2R2 R5R5 R4R4 R3R3 Protected P2MP TE-LSP P2MP Bypass tunnel IP 25 IP 22 IP 28 IP 37 IP 40 IP 5030 IP 45 R6R6 R7R7 P2MP tunnel B P2MP tunnel P Path P2MP tunnel P sender R1 sub-lsp to R6 UA Label 50 IF-ID = tunnel B Path P2MP tunnel P sender R1 sub-lsp to R7 UA Label 50 IF-ID = tunnel B 40 -> 45, R4 22, R5 25 -> 40, R2 FRR: 50, 30, R3 30-> 21, R4 23, R5 45-> 28, R6 21 -> P2MP Tunnel B ILM 22-> 37, R7 23 -> P2MP Tunnel B ILM P2MP tunnel B ILM (label 21) 50 -> 28, R6 P2MP tunnel B ILM (label 23) 50 -> 37, R7 IP 5021 IP 5023

6. Changes since last version l Two new co-authors joined the draft l This new version accounts for comments received on the list l Support for link protection l Support for LAN interface protection è A P2MP bypass that tunnels traffic towards all downstream LSRs on the LAN l The P2MP Bypass selection procedure has been extended è Multiple Bypass LSPs è Bypass LSP whose leaves are a superset of MPs l Clarification regarding bypass tunnel setup (implementation issue) è Pre-established automatically or via configuration è Dynamically triggered upon primary P2MP LSP setup l Some rewordings for the sake of clarity

7. Link Protection R1 R3 R2 l A P2MP bypass that tunnels traffic towards MPs downstream to the PLR l During failure all traffic is tunneled within the P2MP Bypass LSP l Some MPs are downstream to the PLR but not downstream to the failed element (not impacted by the failure) è The PLR must stop sending traffic to these MP within the protected P2MP LSP l Allows avoiding sending twice the traffic on a downstream link during failure Protected P2MP TE-LSP P2MP Bypass tunnel

8. P2MP Bypass Tunnel selection 1/3 è Various options to protect a P2MP LSP –1: A single P2MP Bypass LSP whose leaves exactly match the set of MPs –2: Several P2MP bypass LSPs whose combined leaves cover all MPs –3: A single P2MP Bypass LSP whose leaves are a superset of the set of MPs –Leaves that are not MP drop the traffic è These options differ in terms of data plane and control plane optimization –Option 1 increases the number of states but consumes less bandwidth than 2 and 3 è The choice depends on the desired state/bandwidth tradeoff, and the operational complexity –The choice may also be governed by the ability to find a path for such P2MP Bypass LSPs

9. P2MP Bypass Tunnel Selection Option 1 Protected P2MP TE-LSP P2MP Bypass tunnel

10. P2MP Bypass Tunnel Selection Option 2 Protected P2MP TE-LSP P2MP Bypass tunnel

11. P2MP Bypass Tunnel Selection Option 3 R6R6 drop Protected P2MP TE-LSP P2MP Bypass tunnel

12. Next Steps l Procedures for LAN protection to be simplified è No need for backup signaling before the failure, as the primary LSP is signaled using upstream label assignment è Same label can be used for primary and backup LSPs l Backward compatibility: Need to address the case where some downstream LSRs do not support upstream label assignment è Combination of P2P and P2MP Bypass tunnels to protect a given LSP l WG feedback required on the following points è Support for partial protection –Only protect a subset of MPs when all MPs cannot be covered è Cases where the PLR is not directly upstream to the protected facility è Need for new attributes in the RSVP-TE Attribute Flags TLV (RFC4420)? –Protection with P2MP bypass tunnels desired –Partial protection allowed

13. Conclusion l This draft complements the base P2MP RSVP-TE spec l FRR with P2MP Bypass tunnels is a useful improvement è It allows avoiding potentially expensive data duplication along the backup path l Straightforward procedures that rely on upstream label assignment l WG feedback is required l Adopt as WG doc?

14. Thanks Questions?