Transcript P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels draft-ietf-mpls-p2mp-te-bypass-01.txt

P2MP MPLS-TE Fast Reroute
with P2MP Bypass Tunnels
draft-ietf-mpls-p2mp-te-bypass-01.txt
J.L. Le Roux (France Telecom)
R. Aggarwal (Juniper)
J.P. Vasseur (Cisco Systems)
M. Vigoureux (Alcatel-Lucent)
IETF 69, MPLS WG, Chicago
Document Overview
 Limitations of P2P bypass tunnels to protect a P2MP LSP =>
Traffic duplication…
 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
Changes since last version
 Draft adopted as WG document in May
 No PHP on the bypass tunnel to allow for context identification
Bypass signaled with the No-PHP desired bit, as specified in
draft-ali-mpls-rsvp-te-no-php-oob-mapping
 Reversion: Entirely rely on procedures defined in RFC4090
global and local revertive modes
 Clarifications on PLR location: local or remote
 Combination of P2P and P2MP Bypass tunnels for backward comp
 Bypass tunnel selection options clarified
 Link protection procedures clarified
 Procedures for Partial protection
 Some rewordings for the sake of clarity
Combination of P2P and P2MP Bypass
No Up Label capable
P2P Bypass
P2MP Bypass
 P2MP bypass and P2P bypass can be used in conjunction
For MP on P2P bypass => follow procedures in 4875
For MP on P2MP Bypass => follow procedures in this doc
 No upstream label assignment for MP leaves of P2P bypass
 Allows for backward compatibility with MP that do not support
upstream label assignment
P2MP Bypass Tunnel selection options
Various options to protect a P2MP LSP with P2MP bypass
– 1: A single P2MP Bypass tunnel whose leaves exactly match the set of MPs
– 2: A single P2MP Bypass tunnel whose leaves are a superset of the set of MPs
–Leaves that are not MP drop the traffic
– 3: Several P2MP bypass tunnels whose combined leaves cover all MPs
These options differ in terms of bandwidth consumption and number
of P2MP bypass to be maintained
P2MP Hierarchy => Tension between control plane and data plane
optimization
The choice depends on the desired state/bandwidth tradeoff, and the
operational complexity
Link protection with P2P Bypass
 Default procedure (defined in RFC4875)
 May lead to traffic duplication on some links during failure
When the bypass follows another downstream link on the P2MP LSP
Protected P2MP TE-LSP
P2P Bypass tunnel
Duplication
R1
R3
R2
Link Protection with P2MP Bypass
No Duplication
R3
Protected P2MP TE-LSP
P2MP Bypass tunnel
R1
R2
 OPTIONAL procedure: A link MAY be protected by A P2MP bypass
that tunnels traffic towards MPs downstream to the PLR
 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
P2MP Partial Protection
Uncovered MP
P2MP Primary
Partial prot allowed
P2MP Bypass
 In some cases the PLR may not be able to find a set of P2P and/or P2MP
Bypass Tunnels that cover all merge points
 "P2MP Partial Protection": Only a subset of MP are covered
upon failure, traffic will not be delivered to all leaf LSRs
 Default PLR behavior: Full protection if feasible else no protection
 The Ingress LSR may request for "P2MP Partial Protection", such that if a
P2MP LSP cannot be fully protected it is partially protected
Next Steps
 Need to align with the mpls-upstream draft => The PLR assigns
upstream labels from a single label space
 WG feedback required
 A new revision to be submitted before Vancouver meeting
figures, examples, clarifications
Thanks
Questions?
Appendix
Limitations of the P2P Bypass approach
node protection
 Using P2P bypass tunnels for P2MP LSP node protection leads to
traffic duplication on some links during failure
Duplication
Protected P2MP TE-LSP
P2P Bypass tunnel
R3
R
4
R
1
R
2
R5
Link protection with P2P Bypass
 Default procedure (defined in RFC4875)
 May lead to traffic duplication on some links during failure
When the bypass follows another downstream link on the P2MP LSP
Protected P2MP TE-LSP
P2P Bypass tunnel
Duplication
R1
R3
R2
Protection with P2MP Bypass
Protected P2MP TE-LSP
P2MP Bypass tunnel
Path P2MP tunnel P
sender R1
sub-lsp to R6
UA Label 50
IF-ID = tunnel B
30-> 21, R4
23, R5
R
3
21
50
IP
28
50
IP
45
P2MP tunnel P
25
23
IP
R
1
40
25 -> 40, R2
FRR: 50, 30, R3
R
6
R
4
P2MP tunnel B
30
IP
IP
50
IP
P2MP tunnel B ILM (label 21)
50 -> 28, R6
R
2
IP
40 -> 45, R4
22, R5
Path P2MP tunnel P
sender R1
sub-lsp to R7
UA Label 50
IF-ID = tunnel B
45-> 28, R6
21 -> P2MP Tunnel B ILM
22
IP
R
5
37
IP
R
7
22-> 37, R7
23 -> P2MP Tunnel B ILM
P2MP tunnel B ILM (label 23)
50 -> 37, R7
P2MP Bypass Tunnel Selection
Option 1
Protected P2MP TE-LSP
P2MP Bypass tunnel
P2MP Bypass Tunnel Selection
Option 2
drop
R
6
Protected P2MP TE-LSP
P2MP Bypass tunnel
P2MP Bypass Tunnel Selection
Option 3
Protected P2MP TE-LSP
P2MP Bypass tunnel