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