1 / 14

Limitations of the P2P Bypass approach node protection

desireeg
Download Presentation

Limitations of the P2P Bypass approach node protection

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. R1 R2 R5 R4 R3 Limitations of the P2P Bypass approachnode protection • Using P2P bypass tunnels for P2MP LSP node protection leads to traffic duplication on some links during failure Protected P2MP TE-LSP P2P Bypass tunnel Duplication

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

  4. Solution Overview • 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 • 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 • 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 • P2MP bypass may be used in conjunction with P2P bypass: they are not exclusive 

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

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

  7. R1 R3 R2 Link Protection Protected P2MP TE-LSP P2MP Bypass tunnel • A P2MP bypass that tunnels traffic towards MPs downstream to the PLR • During failure all traffic is tunneled within the P2MP Bypass LSP • 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 • Allows avoiding sending twice the traffic on a downstream link during failure

  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 SelectionOption 1 Protected P2MP TE-LSP P2MP Bypass tunnel

  10. P2MP Bypass Tunnel SelectionOption 2 Protected P2MP TE-LSP P2MP Bypass tunnel

  11. R6 P2MP Bypass Tunnel SelectionOption 3 Protected P2MP TE-LSP P2MP Bypass tunnel drop

  12. Next Steps • 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 • 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 • 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 • This draft complements the base P2MP RSVP-TE spec • FRR with P2MP Bypass tunnels is a useful improvement • It allows avoiding potentially expensive data duplication along the backup path • Straightforward procedures that rely on upstream label assignment • WG feedback is required • Adopt as WG doc?

  14. ThanksQuestions?

More Related