< draft-ietf-bess-mvpn-fast-failover-05.txt   draft-ietf-bess-mvpn-fast-failover-06.txt >
Network Working Group T. Morin, Ed. Network Working Group T. Morin, Ed.
Internet-Draft Orange Internet-Draft Orange
Intended status: Standards Track R. Kebler, Ed. Intended status: Standards Track R. Kebler, Ed.
Expires: August 18, 2019 Juniper Networks Expires: November 12, 2019 Juniper Networks
G. Mirsky, Ed. G. Mirsky, Ed.
ZTE Corp. ZTE Corp.
February 14, 2019 May 11, 2019
Multicast VPN fast upstream failover Multicast VPN fast upstream failover
draft-ietf-bess-mvpn-fast-failover-05 draft-ietf-bess-mvpn-fast-failover-06
Abstract Abstract
This document defines multicast VPN extensions and procedures that This document defines multicast VPN extensions and procedures that
allow fast failover for upstream failures, by allowing downstream PEs allow fast failover for upstream failures, by allowing downstream PEs
to take into account the status of Provider-Tunnels (P-tunnels) when to take into account the status of Provider-Tunnels (P-tunnels) when
selecting the upstream PE for a VPN multicast flow, and extending BGP selecting the upstream PE for a VPN multicast flow, and extending BGP
MVPN routing so that a C-multicast route can be advertised toward a MVPN routing so that a C-multicast route can be advertised toward a
standby upstream PE. standby upstream PE.
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 18, 2019. This Internet-Draft will expire on November 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. UMH Selection based on tunnel status . . . . . . . . . . . . 3 3. UMH Selection based on tunnel status . . . . . . . . . . . . 3
3.1. Determining the status of a tunnel . . . . . . . . . . . 4 3.1. Determining the status of a tunnel . . . . . . . . . . . 5
3.1.1. mVPN tunnel root tracking . . . . . . . . . . . . . . 5 3.1.1. mVPN tunnel root tracking . . . . . . . . . . . . . . 5
3.1.2. PE-P Upstream link status . . . . . . . . . . . . . . 5 3.1.2. PE-P Upstream link status . . . . . . . . . . . . . . 5
3.1.3. P2MP RSVP-TE tunnels . . . . . . . . . . . . . . . . 5 3.1.3. P2MP RSVP-TE tunnels . . . . . . . . . . . . . . . . 6
3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 6 3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 6
3.1.5. (C-S, C-G) counter information . . . . . . . . . . . 6 3.1.5. (C-S, C-G) counter information . . . . . . . . . . . 6
3.1.6. BFD Discriminator . . . . . . . . . . . . . . . . . . 6 3.1.6. BFD Discriminator . . . . . . . . . . . . . . . . . . 7
3.1.7. Per PE-CE link BFD Discriminator . . . . . . . . . . 9 3.1.7. Per PE-CE link BFD Discriminator . . . . . . . . . . 9
4. Standby C-multicast route . . . . . . . . . . . . . . . . . . 10 4. Standby C-multicast route . . . . . . . . . . . . . . . . . . 10
4.1. Downstream PE behavior . . . . . . . . . . . . . . . . . 11 4.1. Downstream PE behavior . . . . . . . . . . . . . . . . . 11
4.2. Upstream PE behavior . . . . . . . . . . . . . . . . . . 12 4.2. Upstream PE behavior . . . . . . . . . . . . . . . . . . 12
4.3. Reachability determination . . . . . . . . . . . . . . . 13 4.3. Reachability determination . . . . . . . . . . . . . . . 13
4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 13
4.4.1. Inter-AS procedures for downstream PEs, ASBR fast 4.4.1. Inter-AS procedures for downstream PEs, ASBR fast
failover . . . . . . . . . . . . . . . . . . . . . . 14 failover . . . . . . . . . . . . . . . . . . . . . . 14
4.4.2. Inter-AS procedures for ASBRs . . . . . . . . . . . . 14 4.4.2. Inter-AS procedures for ASBRs . . . . . . . . . . . . 14
5. Hot leaf standby . . . . . . . . . . . . . . . . . . . . . . 15 5. Hot Root Standby . . . . . . . . . . . . . . . . . . . . . . 15
6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 15 6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 16 10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
skipping to change at page 3, line 51 skipping to change at page 3, line 51
what the upstream multicast hop (UMH) is for a given (C-S,C-G). what the upstream multicast hop (UMH) is for a given (C-S,C-G).
The procedure described here is an OPTIONAL procedure that consists The procedure described here is an OPTIONAL procedure that consists
of having a downstream PE take into account the status of P-tunnels of having a downstream PE take into account the status of P-tunnels
rooted at each possible upstream PEs, for including or not including rooted at each possible upstream PEs, for including or not including
each given PE in the list of candidate UMHs for a given (C-S,C-G) each given PE in the list of candidate UMHs for a given (C-S,C-G)
state. The result is that, if a P-tunnel is "down" (see state. The result is that, if a P-tunnel is "down" (see
Section 3.1), the PE that is the root of the P-tunnel will not be Section 3.1), the PE that is the root of the P-tunnel will not be
considered for UMH selection, which will result in the downstream PE considered for UMH selection, which will result in the downstream PE
to failover to the upstream PE which is next in the list of to failover to the upstream PE which is next in the list of
candidates. If rules to determine the state of the P-tunnel are not candidates. Because all PEs could arrive at a different conclusion
consistent across all PEs, then some may arrive at a different regarding the state of the tunnel,, procedures described in
conclusion regarding the state of the tunnel, In such a scenario, Section 9.1.1 of [RFC6513] MUST be used when using inclusive tunnels.
procedures described in Section 9.1.1 of [RFC6513] MUST be used.
A downstream PE monitors the status of the tunnels of UMHs that are A downstream PE monitors the status of the tunnels of UMHs that are
ahead of the current one. Whenever the downstream PE determines that ahead of the current one. Whenever the downstream PE determines that
one of these tunnels is no longer "known to down", the PE selects the one of these tunnels is no longer "known to down", the PE selects the
UMH corresponding to that as the new UMH. UMH corresponding to that as the new UMH.
More precisely, UMH determination for a given (C-S,C-G) will consider More precisely, UMH determination for a given (C-S,C-G) will consider
the UMH candidates in the following order: the UMH candidates in the following order:
o first, the UMH candidates that either (a) advertise a PMSI bound o First, the UMH candidates that either
to a tunnel, where the specified tunnel is not known to be down or
(b) do not advertise any x-PMSI applicable to the given (C-S,C-G)
but have associated a VRF Route Import BGP attribute to the
unicast VPN route for S (this is necessary to avoid incorrectly
invalidating an UMH PE that would use a policy where no I-PMSI is
advertised for a given VRF and where only S-PMSI are used, the
S-PMSI advertisement being possibly done only after the upstream
PE receives a C-multicast route for (C-S, C-G)/(C-*, C-G) to be
carried over the advertised S-PMSI)
o second, the UMH candidates that advertise a PMSI bound to a tunnel A. advertise a PMSI bound to a tunnel, where the specified tunnel
is not known to be down or
B. do not advertise any x-PMSI applicable to the given (C-S,C-G)
but have associated a VRF Route Import BGP attribute to the
unicast VPN route for S (this is necessary to avoid
incorrectly invalidating an UMH PE that would use a policy
where no I-PMSI is advertised for a given VRF and where only
S-PMSI are used, the S-PMSI advertisement being possibly done
only after the upstream PE receives a C-multicast route for
(C-S, C-G)/(C-*, C-G) to be carried over the advertised
S-PMSI).
o Second, the PE advertising the next best route is to be
considered.
o Third, the UMH candidates that advertise a PMSI bound to a tunnel
that is "down" -- these will thus be used as a last resort to that is "down" -- these will thus be used as a last resort to
ensure a graceful fallback to the basic MVPN UMH selection ensure a graceful fallback to the basic MVPN UMH selection
procedures in the hypothetical case where a false negative would procedures in the hypothetical case where a false negative would
occur when determining the status of all tunnels occur when determining the status of all tunnels.
For a given downstream PE and a given VRF, the P-tunnel corresponding For a given downstream PE and a given VRF, the P-tunnel corresponding
to a given upstream PE for a given (C-S,C-G) state is the S-PMSI to a given upstream PE for a given (C-S,C-G) state is the S-PMSI
tunnel advertised by that upstream PE for this (C-S,C-G) and imported tunnel advertised by that upstream PE for this (C-S,C-G) and imported
into that VRF, or if there isn't any such S-PMSI, the I-PMSI tunnel into that VRF, or if there isn't any such S-PMSI, the I-PMSI tunnel
advertised by that PE and imported into that VRF. advertised by that PE and imported into that VRF.
Note that this document assumes that if a site of a given MVPN that Note that this document assumes that if a site of a given MVPN that
contains C-S is dual-homed to two PEs, then all the other sites of contains C-S is dual-homed to two PEs, then all the other sites of
that MVPN would have two unicast VPN routes (VPN-IPv4 or VPN-IPv6) that MVPN would have two unicast VPN routes (VPN-IPv4 or VPN-IPv6)
skipping to change at page 5, line 47 skipping to change at page 6, line 8
A condition to consider a tunnel status as Up can be that the last- A condition to consider a tunnel status as Up can be that the last-
hop link of the P-tunnel is up. hop link of the P-tunnel is up.
This method should not be used when there is a fast restoration This method should not be used when there is a fast restoration
mechanism (such as MPLS FRR [RFC4090]) in place for the link. mechanism (such as MPLS FRR [RFC4090]) in place for the link.
3.1.3. P2MP RSVP-TE tunnels 3.1.3. P2MP RSVP-TE tunnels
For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is For P-tunnels of type P2MP MPLS-TE, the status of the P-tunnel is
considered up if one or more of the P2MP RSVP-TE LSPs, identified by considered up if the sub-LSP to this downstream PE is in Up state.
the P-tunnel Attribute, are in Up state. The determination of The determination of whether a P2MP RSVP-TE LSP is in Up state
whether a P2MP RSVP-TE LSP is in Up state requires Path and Resv requires Path and Resv state for the LSP and is based on procedures
state for the LSP and is based on procedures in [RFC4875]. In this specified in [RFC4875]. In this case, the downstream PE can
case, the downstream PE can immediately update its UMH when the immediately update its UMH when the reachability condition changes.
reachability condition changes.
When signaling state for a P2MP TE LSP is removed (e.g. if the When signaling state for a P2MP TE LSP is removed (e.g. if the
ingress of the P2MP TE LSP sends a PathTear message) or the P2MP TE ingress of the P2MP TE LSP sends a PathTear message) or the P2MP TE
LSP changes state from Up to Down as determined by procedures in LSP changes state from Up to Down as determined by procedures in
[RFC4875], the status of the corresponding P-tunnel SHOULD be re- [RFC4875], the status of the corresponding P-tunnel SHOULD be re-
evaluated. If the P-tunnel transitions from up to Down state, the evaluated. If the P-tunnel transitions from up to Down state, the
upstream PE, that is the ingress of the P-tunnel, SHOULD NOT be upstream PE, that is the ingress of the P-tunnel, SHOULD NOT be
considered a valid UMH. considered a valid UMH.
3.1.4. Leaf-initiated P-tunnels 3.1.4. Leaf-initiated P-tunnels
skipping to change at page 6, line 43 skipping to change at page 6, line 50
mechanisms are used for the P-tunnels, downstream PEs should be mechanisms are used for the P-tunnels, downstream PEs should be
configured to wait before updating the UMH, to let the P-tunnel configured to wait before updating the UMH, to let the P-tunnel
restoration mechanism happen. A configurable timer MUST be provided restoration mechanism happen. A configurable timer MUST be provided
for this purpose, and it is recommended to provide a reasonable for this purpose, and it is recommended to provide a reasonable
default value for this timer. default value for this timer.
This method can be applicable, for instance, when a (C-S, C-G) flow This method can be applicable, for instance, when a (C-S, C-G) flow
is mapped on an S-PMSI. is mapped on an S-PMSI.
In cases where this mechanism is used in conjunction with In cases where this mechanism is used in conjunction with
Hot leaf standby, then no prior knowledge of the rate of the Hot Root Standby, then no prior knowledge of the rate of the
multicast streams is required; downstream PEs can compare reception multicast streams is required; downstream PEs can compare reception
on the two P-tunnels to determine when one of them is down. on the two P-tunnels to determine when one of them is down.
3.1.6. BFD Discriminator 3.1.6. BFD Discriminator
P-tunnel status can be derived from the status of a multipoint BFD P-tunnel status can be derived from the status of a multipoint BFD
session [I-D.ietf-bfd-multipoint] whose discriminator is advertised session [RFC8562] whose discriminator is advertised along with an
along with an x-PMSI A-D route. x-PMSI A-D route.
This document defines the format and ways of using a new BGP This document defines the format and ways of using a new BGP
attribute called the "BGP- BFD attribute". This is an optional attribute called the "BGP- BFD attribute". This is an optional
transitive BGP attribute. The format of this attribute is defined as transitive BGP attribute. The format of this attribute is defined as
follows: follows:
+-------------------------------+ +-------------------------------+
| Flags (1 octet) | | Flags (1 octet) |
+-------------------------------+ +-------------------------------+
| BFD Discriminator (4 octets) | | BFD Discriminator (4 octets) |
skipping to change at page 7, line 29 skipping to change at page 7, line 35
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| reserved | | reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
3.1.6.1. Upstream PE Procedures 3.1.6.1. Upstream PE Procedures
When it is desired to track the P-tunnel status using p2mp BFD When it is desired to track the P-tunnel status using p2mp BFD
session, the Upstream PE: session, the Upstream PE:
o MUST initiate BFD session and set bfd.SessionType = MultipointHead o MUST initiate BFD session and set bfd.SessionType = MultipointHead
as described in [I-D.ietf-bfd-multipoint]; as described in [RFC8562];
o MUST use address in 127.0.0.0/8 range for IPv4 or in o MUST use address in 127.0.0.0/8 range for IPv4 or in
0:0:0:0:0:FFFF:7F00:0/104 range for IPv6 as destination IP address 0:0:0:0:0:FFFF:7F00:0/104 range for IPv6 as destination IP address
when transmitting BFD control packets; when transmitting BFD control packets;
o MUST use the IP address of the Upstream PE as source IP address o MUST use the IP address of the Upstream PE as source IP address
when transmitting BFD control packets; when transmitting BFD control packets;
o MUST include the BGP-BFD Attribute in the x-PMSI A-D Route with o MUST include the BGP-BFD Attribute in the x-PMSI A-D Route with
BFD Discriminator value set to My Discriminator value; BFD Discriminator value set to My Discriminator value;
o MUST periodically transmit BFD control packets over the x-PMSI o MUST periodically transmit BFD control packets over the x-PMSI
tunnel. tunnel.
If tracking of the P-tunnel by using a p2mp BFD session is to be If tracking of the P-tunnel by using a p2mp BFD session is enabled
enabled after the P-tunnel has been already signaled, then the after the x-PMSI A-D route has been already advertised, the x-PMSI
procedure described above MUST be followed. Note that x-PMSI A-D A-D Route MUST be re-sent with exactly the same attributes as before
Route MUST be re-sent with exactly the same attributes as before and and the BGP-BFD Attribute included.
the BGP-BFD Attribute included.
If P-tunnel is already signaled, and P-tunnel status tracked using If the x-PMSI A-D route is advertised with P-tunnel status tracked
the p2mp BFD session and it is desired to stop tracking P-tunnel using the p2mp BFD session and it is desired to stop tracking
status using BFD, then: P-tunnel status using BFD, then:
o x-PMSI A-D Route MUST be re-sent with exactly the same attributes o x-PMSI A-D Route MUST be re-sent with exactly the same attributes
as before, but the BGP-BFD Attribute MUST be excluded; as before, but the BGP-BFD Attribute MUST be excluded;
o the p2mp BFD session SHOULD be deleted. o the p2mp BFD session SHOULD be deleted.
3.1.6.2. Downstream PE Procedures 3.1.6.2. Downstream PE Procedures
Upon receiving the BGP-BFD Attribute in the x-PMSI A-D Route, the Upon receiving the BGP-BFD Attribute in the x-PMSI A-D Route, the
Downstream PE: Downstream PE:
o MUST associate the received BFD discriminator value with the o MUST associate the received BFD discriminator value with the
P-tunnel originating from the Root PE and the IP address of the P-tunnel originating from the Root PE and the IP address of the
Upstream PE; Upstream PE;
o MUST create p2mp BFD session and set bfd.SessionType = o MUST create p2mp BFD session and set bfd.SessionType =
MultipointTail as described in [I-D.ietf-bfd-multipoint]; MultipointTail as described in [RFC8562];
o MUST use the source IP address of the BFD control packet, the o MUST use the source IP address of the BFD control packet, the
value of the BFD Discriminator field, and the x-PMSI tunnel value of the BFD Discriminator field, and the x-PMSI tunnel
identifier the BFD control packet was received to properly identifier the BFD control packet was received to properly
demultiplex BFD sessions. demultiplex BFD sessions.
After the state of the p2mp BFD session is up, i.e., bfd.SessionState After the state of the p2mp BFD session is up, i.e., bfd.SessionState
== Up, the session state will then be used to track the health of the == Up, the session state will then be used to track the health of the
P-tunnel. P-tunnel.
According to [I-D.ietf-bfd-multipoint], if the Downstream PE receives According to [RFC8562], if the Downstream PE receives Down or
Down or AdminDown in the State field of the BFD control packet or AdminDown in the State field of the BFD control packet or associated
associated with the BFD session Detection Timer expires, the BFD with the BFD session Detection Timer expires, the BFD session state
session state is down, i.e., bfd.SessionState == Down. When the BFD is down, i.e., bfd.SessionState == Down. When the BFD session state
session state is Down, then the P-tunnel associated with the BFD is Down, then the P-tunnel associated with the BFD session as down
session as down MUST be declared down. Then The Downstream PE MAY MUST be declared down. Then The Downstream PE MAY initiate a
initiate a switchover of the traffic from the Primary Upstream PE to switchover of the traffic from the Primary Upstream PE to the Standby
the Standby Upstream PE only if the Standby Upstream PE deemed Upstream PE only if the Standby Upstream PE deemed available. A
available. A different p2mp BFD session MAY monitor the state of the different p2mp BFD session MAY monitor the state of the Standby
Standby Upstream PE. Upstream PE.
If the Downstream PE's P-tunnel is already up when the Downstream PE If the Downstream PE's P-tunnel is already up when the Downstream PE
receives the new x-PMSI A-D Route with BGP-BFD Attribute, the receives the new x-PMSI A-D Route with BGP-BFD Attribute, the
Downstream PE MUST accept the x-PMSI A-D Route and associate the Downstream PE MUST accept the x-PMSI A-D Route and associate the
value of BFD Discriminator field with the P-tunnel. The Upstream PE value of BFD Discriminator field with the P-tunnel. The Upstream PE
MUST follow procedures listed above in this section to bring the p2mp MUST follow procedures listed above in this section to bring the p2mp
BFD session up and use it to monitor the state of the associated BFD session up and use it to monitor the state of the associated
P-tunnel. P-tunnel.
If the Downstream PE's P-tunnel is already up, its state being If the Downstream PE's P-tunnel is already up, its state being
monitored by the p2mp BFD session, and the Downstream PE receives the monitored by the p2mp BFD session, and the Downstream PE receives the
new x-PMSI A-D Route without the BGP-BFD Attribute, the Downstream new x-PMSI A-D Route without the BGP-BFD Attribute, the Downstream
PE: PE:
o MUST accept the x-PMSI A-D Route; o MUST accept the x-PMSI A-D Route;
o MUST stop receiving BFD control packets for this p2mp BFD session; o MUST stop processing BFD control packets for this p2mp BFD
session;
o SHOULD delete the p2mp BFD session associated with the P-tunnel; o SHOULD delete the p2mp BFD session associated with the P-tunnel;
o SHOULD NOT switch the traffic to the Standby Upstream PE. o SHOULD NOT switch the traffic to the Standby Upstream PE.
In such a scenario, in the context where fast restoration mechanisms
are used for the P-tunnels, leaf PEs should be configured to wait
before updating the UMH, to let the P-tunnel restoration mechanism
happen. A configurable timer MUST be provided for this purpose, and
it is RECOMMENDED to provide a reasonable default value for this
timer.
3.1.7. Per PE-CE link BFD Discriminator 3.1.7. Per PE-CE link BFD Discriminator
The following approach is defined for the fast failover in response The following approach is defined for the fast failover in response
to the detection of PE-CE link failures, in which UMH selection for a to the detection of PE-CE link failures, in which UMH selection for a
given C-multicast route takes into account the state of the BFD given C-multicast route takes into account the state of the BFD
session associated with the state of the upstream PE-CE link. session associated with the state of the upstream PE-CE link.
According to section 6.8.17 [RFC5880], failure of a PE-CE link MAY be
communicated to the downstream PE by setting the bfd.LocalDiag of the
p2mp BFD session associated with this link to Concatenated Path Down
and/or Reverse Concatenated Path Down. The mechanism to communicate
the mapping between the PE-CE link and the associated BFD session is
outside the scope of this document.
3.1.7.1. Upstream PE Procedures 3.1.7.1. Upstream PE Procedures
For each protected PE-CE link, the upstream PE initiates a multipoint For each protected PE-CE link, the upstream PE initiates a multipoint
BFD session [I-D.ietf-bfd-multipoint] as MultipointHead toward BFD session [RFC8562] as MultipointHead toward downstream PEs. A
downstream PEs. A downstream PE monitors the state of the p2mp downstream PE monitors the state of the p2mp session as
session as MultipointTail and MAY interpret transition of the BFD MultipointTail and MAY interpret transition of the BFD session into
session into Down state as the indication of the associated PE-CE Down state as the indication of the associated PE-CE link being down.
link being down.
For SSM groups, the upstream PE advertises an (C-S, C-G) S-PMSI A-D For SSM groups, the upstream PE advertises an (C-S, C-G) S-PMSI A-D
route or wildcard (S,*) S-PMSI A-D route for each received SSM (C-S, route or wildcard (S,*) S-PMSI A-D route for each received SSM (C-S,
C-G) C-multicast route for which protection is desired. For each ASM C-G) C-multicast route for which protection is desired. For each ASM
(C-S, C-G) C-multicast route for which protection is desired, the (C-S, C-G) C-multicast route for which protection is desired, the
upstream PE advertises a (C-S, C-G) S-PMSI A-D route. For each ASM upstream PE advertises a (C-S, C-G) S-PMSI A-D route. For each ASM
(*,G) C-Multicast route for which protection is desired, the upstream (*,G) C-Multicast route for which protection is desired, the upstream
PE advertises a wildcard (*,G) S-PMSI A-D route. Note that all PE advertises a wildcard (*,G) S-PMSI A-D route. Note that all
S-PMSI A-D routes can signal the same P-tunnel, so there is no need S-PMSI A-D routes can signal the same P-tunnel, so there is no need
for a new P-tunnel for each S-PMSI A-D route. Multicast flows for for a new P-tunnel for each S-PMSI A-D route. Multicast flows for
skipping to change at page 12, line 20 skipping to change at page 12, line 22
Note that, when a PE advertises such a Standby C-multicast join for Note that, when a PE advertises such a Standby C-multicast join for
an (C-S, C-G) it must join the corresponding P-tunnel. an (C-S, C-G) it must join the corresponding P-tunnel.
If at some later point the local PE determines that C-S is no longer If at some later point the local PE determines that C-S is no longer
reachable through the Primary Upstream PE, the Standby Upstream PE reachable through the Primary Upstream PE, the Standby Upstream PE
becomes the Upstream PE, and the local PE re-sends the C-multicast becomes the Upstream PE, and the local PE re-sends the C-multicast
route with RT that identifies the Standby Upstream PE, except that route with RT that identifies the Standby Upstream PE, except that
now the route does not carry the Standby PE BGP Community (which now the route does not carry the Standby PE BGP Community (which
results in replacing the old route with a new route, with the only results in replacing the old route with a new route, with the only
difference between these routes being the presence/absence of the difference between these routes being the presence/absence of the
Standby PE BGP Community). Standby PE BGP Community). Also, a LOCAL_PREF attribute MUST be set
to zero.
4.2. Upstream PE behavior 4.2. Upstream PE behavior
When a PE receives a C-multicast route for a particular (C-S, C-G), When a PE receives a C-multicast route for a particular (C-S, C-G),
and the RT carried in the route results in importing the route into a and the RT carried in the route results in importing the route into a
particular VRF on the PE, if the route carries the Standby PE BGP particular VRF on the PE, if the route carries the Standby PE BGP
Community, then the PE performs as follows: Community, then the PE performs as follows:
when the PE determines that C-S is not reachable through some when the PE determines that C-S is not reachable through some
other PE, the PE SHOULD install VRF PIM state corresponding to other PE, the PE SHOULD install VRF PIM state corresponding to
skipping to change at page 15, line 5 skipping to change at page 15, line 5
a LOCAL_PREF attribute set to zero and it should be re-advertised a LOCAL_PREF attribute set to zero and it should be re-advertised
in eBGP with a MED attribute (MULTI_EXIT_DISC) set to the highest in eBGP with a MED attribute (MULTI_EXIT_DISC) set to the highest
possible value (0xffff) possible value (0xffff)
o if the route was received over eBGP; the route is expected to have o if the route was received over eBGP; the route is expected to have
a MED attribute set of 0xffff and should be re-advertised in iBGP a MED attribute set of 0xffff and should be re-advertised in iBGP
with a LOCAL_PREF attribute set to zero with a LOCAL_PREF attribute set to zero
Other ASBR procedures are applied without modification. Other ASBR procedures are applied without modification.
5. Hot leaf standby 5. Hot Root Standby
The mechanisms defined in sections Section 4 and Section 3 can be The mechanisms defined in sections Section 4 and Section 3 can be
used together as follows. used together as follows.
The principle is that, for a given VRF (or possibly only for a given The principle is that, for a given VRF (or possibly only for a given
C-S,C-G): C-S,C-G):
o downstream PEs advertise a Standby BGP C-multicast route (based on o downstream PEs advertise a Standby BGP C-multicast route (based on
Section 4) Section 4)
skipping to change at page 18, line 24 skipping to change at page 18, line 24
701 E Middlefield Rd 701 E Middlefield Rd
Mountain View, CA 94043 Mountain View, CA 94043
USA USA
Email: kanwar.singh@alcatel-lucent.com Email: kanwar.singh@alcatel-lucent.com
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-bfd-multipoint]
Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for
Multipoint Networks", draft-ietf-bfd-multipoint-19 (work
in progress), December 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
Yasukawa, Ed., "Extensions to Resource Reservation Yasukawa, Ed., "Extensions to Resource Reservation
Protocol - Traffic Engineering (RSVP-TE) for Point-to- Protocol - Traffic Engineering (RSVP-TE) for Point-to-
Multipoint TE Label Switched Paths (LSPs)", RFC 4875, Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
DOI 10.17487/RFC4875, May 2007, DOI 10.17487/RFC4875, May 2007,
<https://www.rfc-editor.org/info/rfc4875>. <https://www.rfc-editor.org/info/rfc4875>.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection
(BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
<https://www.rfc-editor.org/info/rfc5880>.
[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February
2012, <https://www.rfc-editor.org/info/rfc6513>. 2012, <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<https://www.rfc-editor.org/info/rfc6514>. <https://www.rfc-editor.org/info/rfc6514>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8562] Katz, D., Ward, D., Pallagatti, S., Ed., and G. Mirsky,
Ed., "Bidirectional Forwarding Detection (BFD) for
Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562,
April 2019, <https://www.rfc-editor.org/info/rfc8562>.
11.2. Informative References 11.2. Informative References
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005, DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>. <https://www.rfc-editor.org/info/rfc4090>.
[RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B. [RFC7431] Karan, A., Filsfils, C., Wijnands, IJ., Ed., and B.
Decraene, "Multicast-Only Fast Reroute", RFC 7431, Decraene, "Multicast-Only Fast Reroute", RFC 7431,
DOI 10.17487/RFC7431, August 2015, DOI 10.17487/RFC7431, August 2015,
 End of changes. 29 change blocks. 
73 lines changed or deleted 81 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/