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)

Limitations of the P2P Bypass approachnode protectionUsing P2P bypass tunnels for P2MP LSP node protection leads to

traffic duplication on some links during failure

R1R2

R5

R4

R3Duplication

Protected P2MP TE-LSP

P2P Bypass tunnel

Limitations of the P2P Bypass approachUsing P2P bypass tunnels for P2MP LSP link protection may also

lead to traffic duplication on some links during failure

R1

R3Duplication

R2

Protected P2MP TE-LSP

P2P Bypass tunnel

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

Protection with P2MP Bypass

R1

R2

R5

R4

R3

Protected P2MP TE-LSP

P2MP Bypass tunnel

IP25

IP22

IP28

IP37

IP40

IP5030IP45

R6

R7

P2MP tunnel B

P2MP tunnel P

Path P2MP tunnel Psender R1sub-lsp to R6UA Label 50IF-ID = tunnel B

Path P2MP tunnel Psender R1sub-lsp to R7UA Label 50IF-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

IP5021

IP5023

Changes since last version

Two new co-authors joined the draftThis new version accounts for comments received on the listSupport for link protectionSupport for LAN interface protection

A P2MP bypass that tunnels traffic towards all downstream LSRs on the LAN

The P2MP Bypass selection procedure has been extendedMultiple Bypass LSPsBypass LSP whose leaves are a superset of MPs

Clarification regarding bypass tunnel setup (implementation issue)Pre-established automatically or via configurationDynamically triggered upon primary P2MP LSP setup

Some rewordings for the sake of clarity

Link Protection

R1

R3

R2

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

Protected P2MP TE-LSPP2MP Bypass tunnel

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

P2MP Bypass Tunnel SelectionOption 1

Protected P2MP TE-LSPP2MP Bypass tunnel

P2MP Bypass Tunnel SelectionOption 2

Protected P2MP TE-LSP

P2MP Bypass tunnel

P2MP Bypass Tunnel SelectionOption 3

R6

drop

Protected P2MP TE-LSPP2MP Bypass tunnel

Next Steps

Procedures for LAN protection to be simplifiedNo need for backup signaling before the failure, as the primary LSP is

signaled using upstream label assignmentSame 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 pointsSupport 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 facilityNeed for new attributes in the RSVP-TE Attribute Flags TLV (RFC4420)?

–Protection with P2MP bypass tunnels desired

–Partial protection allowed

Conclusion

This draft complements the base P2MP RSVP-TE spec

FRR with P2MP Bypass tunnels is a useful improvementIt 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?

Thanks

Questions?