< draft-ietf-bess-mvpn-fast-failover-13.txt | draft-ietf-bess-mvpn-fast-failover-14.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: May 19, 2021 Juniper Networks | Expires: June 19, 2021 Juniper Networks | |||
G. Mirsky, Ed. | G. Mirsky, Ed. | |||
ZTE Corp. | ZTE Corp. | |||
November 15, 2020 | December 16, 2020 | |||
Multicast VPN Fast Upstream Failover | Multicast VPN Fast Upstream Failover | |||
draft-ietf-bess-mvpn-fast-failover-13 | draft-ietf-bess-mvpn-fast-failover-14 | |||
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 consider the status of Provider-Tunnels (P-tunnels) when selecting | to consider the status of Provider-Tunnels (P-tunnels) when selecting | |||
the upstream PE for a VPN multicast flow. The fast failover is | the upstream PE for a VPN multicast flow. The fast failover is | |||
enabled by using RFC 8562 BFD for Multipoint Networks and the new BGP | enabled by using RFC 8562 BFD for Multipoint Networks and the new BGP | |||
Attribute - BFD Discriminator. Also, the document introduces a new | Attribute - BFD Discriminator. Also, the document introduces a new | |||
BGP Community, Standby PE, extending BGP Multicast VPN routing so | BGP Community, Standby PE, extending BGP Multicast VPN routing so | |||
skipping to change at page 1, line 41 ¶ | skipping to change at page 1, line 41 ¶ | |||
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 May 19, 2021. | This Internet-Draft will expire on June 19, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2020 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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
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. Conventions used in this document . . . . . . . . . . . . . . 3 | 2. Conventions used in this document . . . . . . . . . . . . . . 3 | |||
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 | |||
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. UMH Selection Based on Tunnel Status . . . . . . . . . . . . 5 | 3. UMH Selection Based on Tunnel Status . . . . . . . . . . . . 5 | |||
3.1. Determining the Status of a Tunnel . . . . . . . . . . . 6 | 3.1. Determining the Status of a Tunnel . . . . . . . . . . . 6 | |||
3.1.1. MVPN Tunnel Root Tracking . . . . . . . . . . . . . . 6 | 3.1.1. MVPN Tunnel Root Tracking . . . . . . . . . . . . . . 7 | |||
3.1.2. PE-P Upstream Link Status . . . . . . . . . . . . . . 7 | 3.1.2. PE-P Upstream Link Status . . . . . . . . . . . . . . 7 | |||
3.1.3. P2MP RSVP-TE Tunnels . . . . . . . . . . . . . . . . 7 | 3.1.3. P2MP RSVP-TE Tunnels . . . . . . . . . . . . . . . . 7 | |||
3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 8 | 3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 8 | |||
3.1.5. (C-S, C-G) Counter Information . . . . . . . . . . . 8 | 3.1.5. (C-S, C-G) Counter Information . . . . . . . . . . . 8 | |||
3.1.6. BFD Discriminator Attribute . . . . . . . . . . . . . 8 | 3.1.6. BFD Discriminator Attribute . . . . . . . . . . . . . 8 | |||
3.1.7. Per PE-CE Link BFD Discriminator . . . . . . . . . . 12 | 3.1.7. Per PE-CE Link BFD Discriminator . . . . . . . . . . 12 | |||
4. Standby C-multicast Route . . . . . . . . . . . . . . . . . . 12 | 4. Standby C-multicast Route . . . . . . . . . . . . . . . . . . 12 | |||
4.1. Downstream PE Behavior . . . . . . . . . . . . . . . . . 13 | 4.1. Downstream PE Behavior . . . . . . . . . . . . . . . . . 13 | |||
4.2. Upstream PE Behavior . . . . . . . . . . . . . . . . . . 14 | 4.2. Upstream PE Behavior . . . . . . . . . . . . . . . . . . 14 | |||
4.3. Reachability Determination . . . . . . . . . . . . . . . 15 | 4.3. Reachability Determination . . . . . . . . . . . . . . . 15 | |||
4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 15 | 4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 16 | |||
4.4.1. Inter-AS Procedures for downstream PEs, ASBR Fast | 4.4.1. Inter-AS Procedures for downstream PEs, ASBR Fast | |||
Failover . . . . . . . . . . . . . . . . . . . . . . 16 | Failover . . . . . . . . . . . . . . . . . . . . . . 16 | |||
4.4.2. Inter-AS Procedures for ASBRs . . . . . . . . . . . . 16 | 4.4.2. Inter-AS Procedures for ASBRs . . . . . . . . . . . . 16 | |||
5. Hot Root Standby . . . . . . . . . . . . . . . . . . . . . . 16 | 5. Hot Root Standby . . . . . . . . . . . . . . . . . . . . . . 17 | |||
6. Duplicate Packets . . . . . . . . . . . . . . . . . . . . . . 17 | 6. Duplicate Packets . . . . . . . . . . . . . . . . . . . . . . 18 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | |||
7.1. Standby PE Community . . . . . . . . . . . . . . . . . . 18 | 7.1. Standby PE Community . . . . . . . . . . . . . . . . . . 18 | |||
7.2. BFD Discriminator . . . . . . . . . . . . . . . . . . . . 18 | 7.2. BFD Discriminator . . . . . . . . . . . . . . . . . . . . 18 | |||
7.3. BFD Discriminator Optional Sub-TLV Type . . . . . . . . . 19 | 7.3. BFD Discriminator Optional Sub-TLV Type . . . . . . . . . 19 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 20 | 10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 20 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 22 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 23 | 11.2. Informative References . . . . . . . . . . . . . . . . . 23 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 | |||
1. Introduction | 1. Introduction | |||
It is assumed that the reader is familiar with the workings of | It is assumed that the reader is familiar with the workings of | |||
multicast MPLS/BGP IP VPNs as described in [RFC6513] and [RFC6514]. | multicast MPLS/BGP IP VPNs as described in [RFC6513] and [RFC6514]. | |||
In the context of multicast in BGP/MPLS VPNs [RFC6513], it is | In the context of multicast in BGP/MPLS VPNs [RFC6513], it is | |||
desirable to provide mechanisms allowing fast recovery of | desirable to provide mechanisms allowing fast recovery of | |||
connectivity on different types of failures. This document addresses | connectivity on different types of failures. This document addresses | |||
failures of elements in the provider network that are upstream of PEs | failures of elements in the provider network that are upstream of PEs | |||
skipping to change at page 3, line 31 ¶ | skipping to change at page 3, line 31 ¶ | |||
"fast failover" solution when used alone, but can be used together | "fast failover" solution when used alone, but can be used together | |||
with the mechanism described in Section 4 for a "fast failover" | with the mechanism described in Section 4 for a "fast failover" | |||
solution. | solution. | |||
Section 4 describes an optional BGP extension, a new Standby PE | Section 4 describes an optional BGP extension, a new Standby PE | |||
Community. that can speed up failover by not requiring any multicast | Community. that can speed up failover by not requiring any multicast | |||
VPN (MVPN) routing message exchange at recovery time. | VPN (MVPN) routing message exchange at recovery time. | |||
Section 5 describes a "hot leaf standby" mechanism that can be used | Section 5 describes a "hot leaf standby" mechanism that can be used | |||
to improve failover time in MVPN. The approach combines mechanisms | to improve failover time in MVPN. The approach combines mechanisms | |||
defined in Section 3 and Section 4 has similarities with the solution | defined in Section 3 and Section 4, and has similarities with the | |||
described in [RFC7431] to improve failover times when PIM routing is | solution described in [RFC7431] to improve failover times when PIM | |||
used in a network given some topology and metric constraints. | routing is used in a network given some topology and metric | |||
constraints. | ||||
The procedures described in this document are optional to enable an | The procedures described in this document are optional to enable an | |||
operator to provide protection for multicast services in BGP/MPLS IP | operator to provide protection for multicast services in BGP/MPLS IP | |||
VPNs. An operator would enable these mechanisms using a method | VPNs. An operator would enable these mechanisms using a method | |||
discussed in Section 3 in combination with the redundancy provided by | discussed in Section 3 combined with the redundancy provided by a | |||
a standby PE connected to the source of the multicast flow, and it is | standby PE connected to the multicast flow source. PEs that support | |||
assumed that all PEs in the network would support these mechanisms | these mechanisms would converge faster and thus provide a more stable | |||
for the procedures to work. In the case that a BGP implementation | multicast service. In the case that a BGP implementation does not | |||
does not recognize or is configured to not support the extensions | recognize or is configured to not support the extensions defined in | |||
defined in this document, it will continue to provide the multicast | this document, it will continue to provide the multicast service, as | |||
service, as described in [RFC6513]. | described in [RFC6513]. | |||
2. Conventions used in this document | 2. Conventions used in this document | |||
2.1. Requirements Language | 2.1. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
"OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
capitals, as shown here. | capitals, as shown here. | |||
2.2. Terminology | 2.2. Terminology | |||
skipping to change at page 5, line 33 ¶ | skipping to change at page 5, line 36 ¶ | |||
and it may be treated as if it is Up so that attempts to use the | and it may be treated as if it is Up so that attempts to use the | |||
tunnel are acceptable. The result is that, if a P-tunnel is Down | tunnel are acceptable. 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 | (see Section 3.1), the PE that is the root of the P-tunnel will not | |||
be considered for UMH selection. This will result in the downstream | be considered for UMH selection. This will result in the downstream | |||
PE failing over to use the next Upstream PE in the list of | PE failing over to use the next Upstream PE in the list of | |||
candidates. Some downstream PEs could arrive at a different | candidates. Some downstream PEs could arrive at a different | |||
conclusion regarding the tunnel's state because the failure impacts | conclusion regarding the tunnel's state because the failure impacts | |||
only a subset of branches. Because of that, the procedures of | only a subset of branches. Because of that, the procedures of | |||
Section 9.1.1 of [RFC6513] are applicable when using I-PMSI | Section 9.1.1 of [RFC6513] are applicable when using I-PMSI | |||
P-tunnels. That document is a foundation for this document, and its | P-tunnels. That document is a foundation for this document, and its | |||
processes all apply here. Section 9.1.1 mandates the use of specific | processes all apply here. | |||
procedures for sending intra-AS I-PMSI A-D Routes. | ||||
There are three options specified in Section 5.1 of [RFC6513] for a | There are three options specified in Section 5.1 of [RFC6513] for a | |||
downstream PE to select an Upstream PE. | downstream PE to select an Upstream PE. | |||
o The first two options select the Upstream PE from a candidate PE | o The first two options select the Upstream PE from a candidate PE | |||
set either based on an IP address or a hashing algorithm. When | set either based on an IP address or a hashing algorithm. When | |||
used together with the optional procedure of considering the | used together with the optional procedure of considering the | |||
P-tunnel status as in this document, a candidate Upstream PE is | P-tunnel status as in this document, a candidate Upstream PE is | |||
included in the set if it either: | included in the set if it either: | |||
skipping to change at page 6, line 24 ¶ | skipping to change at page 6, line 27 ¶ | |||
procedure of considering P-tunnel status as in this document, the | procedure of considering P-tunnel status as in this document, the | |||
Selected UMH Route is the best one among those whose originating | Selected UMH Route is the best one among those whose originating | |||
PE's P-tunnel is not "down". If that does not exist, the | PE's P-tunnel is not "down". If that does not exist, the | |||
installed UMH Route is selected regardless of the P-tunnel status. | installed UMH Route is selected regardless of the P-tunnel status. | |||
3.1. Determining the Status of a Tunnel | 3.1. Determining the Status of a Tunnel | |||
Different factors can be considered to determine the "status" of a | Different factors can be considered to determine the "status" of a | |||
P-tunnel and are described in the following sub-sections. The | P-tunnel and are described in the following sub-sections. The | |||
optional procedures described in this section also handle the case | optional procedures described in this section also handle the case | |||
the downstream PEs do not all apply the same rules to define what the | when the downstream PEs do not all apply the same rules to define | |||
status of a P-tunnel is (please see Section 6), and some of them will | what the status of a P-tunnel is (please see Section 6), and some of | |||
produce a result that may be different for different downstream PEs. | them will produce a result that may be different for different | |||
Thus, the "status" of a P-tunnel in this section is not a | downstream PEs. Thus, the "status" of a P-tunnel in this section is | |||
characteristic of the tunnel in itself, but is the tunnel status, as | not a characteristic of the tunnel in itself, but is the tunnel | |||
seen from a particular downstream PE. Additionally, some of the | status, as seen from a particular downstream PE. Additionally, some | |||
following methods determine the ability of a downstream PE to receive | of the following methods determine the ability of a downstream PE to | |||
traffic on the P-tunnel and not specifically on the status of the | receive traffic on the P-tunnel and not specifically on the status of | |||
P-tunnel itself. That could be referred to as "P-tunnel reception | the P-tunnel itself. That could be referred to as "P-tunnel | |||
status", but for simplicity, we will use the terminology of P-tunnel | reception status", but for simplicity, we will use the terminology of | |||
"status" for all of these methods. | P-tunnel "status" for all of these methods. | |||
Depending on the criteria used to determine the status of a P-tunnel, | Depending on the criteria used to determine the status of a P-tunnel, | |||
there may be an interaction with another resiliency mechanism used | there may be an interaction with another resiliency mechanism used | |||
for the P-tunnel itself, and the UMH update may happen immediately or | for the P-tunnel itself, and the UMH update may happen immediately or | |||
may need to be delayed. Each particular case is covered in each | may need to be delayed. Each particular case is covered in each | |||
separate sub-section below. | separate sub-section below. | |||
An implementation may support any combination of the methods | An implementation may support any combination of the methods | |||
described in this section and provide a network operator with control | described in this section and provide a network operator with control | |||
to choose which one to use in the particular deployment. | to choose which one to use in the particular deployment. | |||
skipping to change at page 7, line 47 ¶ | skipping to change at page 8, line 4 ¶ | |||
procedures specified in [RFC4875]. As a result, the downstream PE | procedures specified in [RFC4875]. As a result, the downstream PE | |||
can immediately update its UMH when the reachability condition | can immediately update its UMH when the reachability condition | |||
changes. | changes. | |||
When using this method and if the signaling state for a P2MP TE LSP | When using this method and if the signaling state for a P2MP TE LSP | |||
is removed (e.g., if the ingress of the P2MP TE LSP sends a PathTear | is removed (e.g., if the ingress of the P2MP TE LSP sends a PathTear | |||
message) or the P2MP TE LSP changes state from Up to Down as | message) or the P2MP TE LSP changes state from Up to Down as | |||
determined by procedures in [RFC4875], the status of the | determined by procedures in [RFC4875], the status of the | |||
corresponding P-tunnel MUST be re-evaluated. If the P-tunnel | corresponding P-tunnel MUST be re-evaluated. If the P-tunnel | |||
transitions from Up to Down state, the Upstream PE that is the | transitions from Up to Down state, the Upstream PE that is the | |||
ingress of the P-tunnel MUST NOT be considered a valid UMH. | ingress of the P-tunnel MUST NOT be considered as a valid candidate | |||
UMH. | ||||
3.1.4. Leaf-initiated P-tunnels | 3.1.4. Leaf-initiated P-tunnels | |||
An Upstream PE SHOULD be removed from the UMH candidate list for a | An Upstream PE SHOULD be removed from the UMH candidate list for a | |||
given (C-S, C-G) if the P-tunnel (I-PMSI or S-PMSI) for this (S, G) | given (C-S, C-G) if the P-tunnel (I-PMSI or S-PMSI) for this (S, G) | |||
is leaf-triggered (PIM, mLDP), but for some reason, internal to the | is leaf-triggered (PIM, mLDP), but for some reason, internal to the | |||
protocol, the upstream one-hop branch of the tunnel from P to PE | protocol, the upstream one-hop branch of the tunnel from P to PE | |||
cannot be built. As a result, the downstream PE can immediately | cannot be built. As a result, the downstream PE can immediately | |||
update its UMH when the reachability condition changes. | update its UMH when the reachability condition changes. | |||
skipping to change at page 8, line 32 ¶ | skipping to change at page 8, line 34 ¶ | |||
When such a procedure is used, in the context where fast restoration | When such a procedure is used, in the context where fast restoration | |||
mechanisms are used for the P-tunnels, a configurable timer MUST be | mechanisms are used for the P-tunnels, a configurable timer MUST be | |||
set on the downstream PE to wait before updating the UMH, to let the | set on the downstream PE to wait before updating the UMH, to let the | |||
P-tunnel restoration mechanism to execute its actions. An | P-tunnel restoration mechanism to execute its actions. An | |||
implementation SHOULD use three seconds as the default value for this | implementation SHOULD use three seconds as the default value for this | |||
timer. | timer. | |||
In cases where this mechanism is used in conjunction with the method | In cases where this mechanism is used in conjunction with the method | |||
described in Section 5, no prior knowledge of the rate of the | described in Section 5, 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. The | |||
detailed specification of this mechanism is outside the scope of this | ||||
document. | ||||
3.1.6. BFD Discriminator Attribute | 3.1.6. BFD Discriminator Attribute | |||
P-tunnel status may be derived from the status of a multipoint BFD | P-tunnel status may be derived from the status of a multipoint BFD | |||
session [RFC8562] whose discriminator is advertised along with an | session [RFC8562] whose discriminator is advertised 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 "BFD Discriminator". It is an optional | attribute called the "BFD Discriminator". It is an optional | |||
transitive BGP attribute. An implementation that does not recognize | transitive BGP attribute. An implementation that does not recognize | |||
skipping to change at page 9, line 34 ¶ | skipping to change at page 9, line 34 ¶ | |||
BFD Discriminator field is four octets long. | BFD Discriminator field is four octets long. | |||
Optional TLVs is the optional variable-length field that MAY be | Optional TLVs is the optional variable-length field that MAY be | |||
used in the BFD Discriminator attribute for future extensions. | used in the BFD Discriminator attribute for future extensions. | |||
TLVs MAY be included in a sequential or nested manner. To allow | TLVs MAY be included in a sequential or nested manner. To allow | |||
for TLV nesting, it is advised to define a new TLV as a variable- | for TLV nesting, it is advised to define a new TLV as a variable- | |||
length object. Figure 2 presents the Optional TLV format TLV that | length object. Figure 2 presents the Optional TLV format TLV that | |||
consists of: | consists of: | |||
* one octet-long field of TLV's Type value (Section 7.3) | * Type - a one-octet-long field that characterizes the | |||
interpretation of the Value field (Section 7.3) | ||||
* one octet-long field of the length of the Value field in octets | * Length - a one-octet-long field equal to the length of the | |||
Value field in octets | ||||
* variable length Value field. | * Value - a variable-length field. | |||
The length of a TLV MUST be multiple of four octets. | The length of a TLV as a whole MUST be multiple of four octets. | |||
0 1 2 3 | 0 1 2 3 | |||
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Length | Value ... | | Type | Length | Value ... | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 2: Format of the Optional TLV | Figure 2: Format of the Optional TLV | |||
The BFD Discriminator attribute MUST be considered malformed if its | The BFD Discriminator attribute MUST be considered malformed if its | |||
length is not a non-zero multiple of four. If the attribute | length is not a non-zero multiple of four. If the attribute is | |||
considered malformed, the UPDATE message SHALL be handled using the | deemed to be malformed, the UPDATE message SHALL be handled using the | |||
approach of Attribute Discard per [RFC7606]. | approach of Attribute Discard per [RFC7606]. | |||
3.1.6.1. Upstream PE Procedures | 3.1.6.1. Upstream PE Procedures | |||
To enable downstream PEs to track the P-tunnel status using a point- | To enable downstream PEs to track the P-tunnel status using a point- | |||
to-multipoint (P2MP) BFD session the Upstream PE: | to-multipoint (P2MP) BFD session the Upstream PE: | |||
o MUST initiate the BFD session and set bfd.SessionType = | o MUST initiate the BFD session and set bfd.SessionType = | |||
MultipointHead as described in [RFC8562]; | MultipointHead as described in [RFC8562]; | |||
skipping to change at page 10, line 36 ¶ | skipping to change at page 10, line 44 ¶ | |||
o MUST include the BFD Discriminator attribute in the x-PMSI A-D | o MUST include the BFD Discriminator attribute in the x-PMSI A-D | |||
Route with the value set to My Discriminator value; | Route with the 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 | |||
P-tunnel after the P-tunnel is considered established. Note that | P-tunnel after the P-tunnel is considered established. Note that | |||
the methods to declare a P-tunnel has been established are outside | the methods to declare a P-tunnel has been established are outside | |||
the scope of this specification. | the scope of this specification. | |||
If the tracking of the P-tunnel by using a P2MP BFD session is | If the tracking of the P-tunnel by using a P2MP BFD session is | |||
enabled after the x-PMSI A-D Route has been already advertised, the | enabled after the x-PMSI A-D Route has been already advertised, the | |||
x-PMSI A-D Route MUST be re-sent with precisely the same attributes | x-PMSI A-D Route MUST be re-sent with the only change between the | |||
as before and the BFD Discriminator attribute included. | previous advertisement and the new advertisement to be the inclusion | |||
of the BFD Discriminator attribute. | ||||
If the x-PMSI A-D Route is advertised with P-tunnel status tracked | If the x-PMSI A-D Route is advertised with P-tunnel status tracked | |||
using the P2MP BFD session and it is desired to stop tracking | using the P2MP BFD session, and it is desired to stop tracking | |||
P-tunnel status using BFD, then: | P-tunnel status using BFD, then: | |||
o x-PMSI A-D Route MUST be re-sent with precisely the same | o x-PMSI A-D Route MUST be re-sent with the only change between the | |||
attributes as before, but the BFD Discriminator attribute MUST be | previous advertisement and the new advertisement be the exclusion | |||
excluded; | of the BFD Discriminator attribute; | |||
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 BFD Discriminator attribute in the x-PMSI A-D | Upon receiving the BFD Discriminator attribute in the x-PMSI A-D | |||
Route, the downstream PE: | Route, the 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 Upstream PE and the IP address of | P-tunnel originating from the Upstream PE and the IP address of | |||
the Upstream PE; | the Upstream PE; | |||
o MUST create a P2MP BFD session and set bfd.SessionType = | o MUST create a P2MP BFD session and set bfd.SessionType = | |||
MultipointTail as described in [RFC8562]; | 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 [RFC6514] the BFD Control packet was received to | Identifier [RFC6514] the BFD Control packet was received on to | |||
properly demultiplex BFD sessions. | properly 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 [RFC8562], if the downstream PE receives Down or | According to [RFC8562], if the downstream PE receives Down or | |||
AdminDown in the State field of the BFD Control packet or associated | AdminDown in the State field of the BFD Control packet or associated | |||
with the BFD session Detection Timer expires, the BFD session is | with the BFD session Detection Timer associated with the BFD session | |||
down, i.e., bfd.SessionState == Down. When the BFD session state is | expires, the BFD session is down, i.e., bfd.SessionState == Down. | |||
Down, then the P-tunnel associated with the BFD session MUST be | When the BFD session state is Down, then the P-tunnel associated with | |||
considered down. If the site that contains C-S is connected to two | the BFD session MUST be considered down. If the site that contains | |||
or more PEs, a downstream PE will select one as its Primary Upstream | C-S is connected to two or more PEs, a downstream PE will select one | |||
PE, while others are considered as Standby Upstream PEs. In such a | as its Primary Upstream PE, while others are considered as Standby | |||
scenario, when the P-tunnel is considered down, the downstream PE MAY | Upstream PEs. In such a scenario, when the P-tunnel is considered | |||
initiate a switchover of the traffic from the Primary Upstream PE to | down, the downstream PE MAY initiate a switchover of the traffic from | |||
the Standby Upstream PE only if the Standby Upstream PE is deemed | the Primary Upstream PE to the Standby Upstream PE only if the | |||
available. | Standby Upstream PE is deemed to be in the Up state. That MAY be | |||
determined from the state of a P2MP BFD session with the Standby | ||||
Upstream PE as the MultipointHead. | ||||
If the downstream PE's P-tunnel is already established when the | If the downstream PE's P-tunnel is already established when the | |||
downstream PE receives the new x-PMSI A-D Route with BFD | downstream PE receives the new x-PMSI A-D Route with BFD | |||
Discriminator attribute, the downstream PE MUST associate the value | Discriminator attribute, the downstream PE MUST associate the value | |||
of BFD Discriminator field with the P-tunnel and follow procedures | of BFD Discriminator field with the P-tunnel and follow procedures | |||
listed above in this section if and only if the x-PMSI A-D Route was | listed above in this section if and only if the x-PMSI A-D Route was | |||
properly processed as per [RFC6514], and the BFD Discriminator | properly processed as per [RFC6514], and the BFD Discriminator | |||
attribute was validated. | attribute was validated. | |||
If the downstream PE's P-tunnel is already established, its state | If the downstream PE's P-tunnel is already established, its state | |||
skipping to change at page 12, line 31 ¶ | skipping to change at page 12, line 39 ¶ | |||
CE link within the time of bfd.DesiredMinTxInterval for the P2MP BFD | CE link within the time of bfd.DesiredMinTxInterval for the P2MP BFD | |||
session (in that case, the Upstream PE will start tracking the status | session (in that case, the Upstream PE will start tracking the status | |||
of the new PE-CE link). When a downstream PE receives that | of the new PE-CE link). When a downstream PE receives that | |||
bfd.LocalDiag code, it treats it as if the tunnel itself failed and | bfd.LocalDiag code, it treats it as if the tunnel itself failed and | |||
tries to switch to a backup PE. | tries to switch to a backup PE. | |||
4. Standby C-multicast Route | 4. Standby C-multicast Route | |||
The procedures described below are limited to the case where the site | The procedures described below are limited to the case where the site | |||
that contains C-S is connected to two or more PEs, though, to | that contains C-S is connected to two or more PEs, though, to | |||
simplify the description, the case of dual-homing is described. The | simplify the description, the case of dual-homing is described. In | |||
procedures require all the PEs of that MVPN to follow the same UMH | the case where more than two PEs are connected to the C-s site, | |||
selection procedure, as specified in [RFC6513], whether the PE | selection of the Standby PE can be performed using one of the methods | |||
selected based on its IP address, hashing algorithm described in | of selecting a UMH. Details of the selection are outside the scope | |||
section 5.1.3 of [RFC6513], or Installed UMH Route. The procedures | of this document. The procedures require all the PEs of that MVPN to | |||
assume that if a site of a given MVPN that contains C-S is dual-homed | follow the same UMH selection procedure, as specified in [RFC6513], | |||
to two PEs, then all the other sites of that MVPN would have two | whether the PE selected based on its IP address, the hashing | |||
unicast VPN routes (VPN-IPv4 or VPN-IPv6) to C-S, each with its RD. | algorithm described in section 5.1.3 of [RFC6513], or Installed UMH | |||
Route. The consistency of the UMH selection method used among all | ||||
PEs is expected to be provided by the management plane. The | ||||
procedures assume that if a site of a given MVPN that 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) to C-S, each with | ||||
its own RD. | ||||
As long as C-S is reachable via both PEs, a given downstream PE will | As long as C-S is reachable via both PEs, a given downstream PE will | |||
select one of the PEs connected to C-S as its Upstream PE for C-S. | select one of the PEs connected to C-S as its Upstream PE for C-S. | |||
We will refer to the other PE connected to C-S as the "Standby | We will refer to the other PE connected to C-S as the "Standby | |||
Upstream PE". Note that if the connectivity to C-S through the | Upstream PE". Note that if the connectivity to C-S through the | |||
Primary Upstream PE becomes unavailable, then the PE will select the | Primary Upstream PE becomes unavailable, then the PE will select the | |||
Standby Upstream PE as its Upstream PE for C-S. When the Primary PE | Standby Upstream PE as its Upstream PE for C-S. When the Primary PE | |||
later becomes available, then the PE will select the Primary Upstream | later becomes available, then the PE will select the Primary Upstream | |||
PE again as its Upstream PE. Such behavior is referred to as | PE again as its Upstream PE. Such behavior is referred to as | |||
"revertive" behavior and MUST be supported. Non-revertive behavior | "revertive" behavior and MUST be supported. Non-revertive behavior | |||
refers to the behavior of continuing to select the backup PE as the | refers to the behavior of continuing to select the backup PE as the | |||
UMH even after the Primary has come up. This non-revertive behavior | UMH even after the Primary has come up. This non-revertive behavior | |||
MAY also be supported by an implementation and would be enabled | MAY also be supported by an implementation and would be enabled | |||
through some configuration. | through some configuration. Selection of the behavior, revertive or | |||
non-revertive, is an operational issue, but it MUST be consistent on | ||||
all PEs in the given MVPN. | ||||
For readability, in the following sub-sections, the procedures are | For readability, in the following sub-sections, the procedures are | |||
described for BGP C-multicast Source Tree Join routes, but they apply | described for BGP C-multicast Source Tree Join routes, but they apply | |||
equally to BGP C-multicast Shared Tree Join routes for the case where | equally to BGP C-multicast Shared Tree Join routes for the case where | |||
the customer RP is dual-homed (substitute "C-RP" to "C-S"). | the customer RP is dual-homed (substitute "C-RP" to "C-S"). | |||
4.1. Downstream PE Behavior | 4.1. Downstream PE Behavior | |||
When a (downstream) PE connected to some site of an MVPN needs to | When a (downstream) PE connected to some site of an MVPN needs to | |||
send a C-multicast route (C-S, C-G), then following the procedures | send a C-multicast route (C-S, C-G), then following the procedures | |||
skipping to change at page 14, line 26 ¶ | skipping to change at page 14, line 45 ¶ | |||
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 (the use of the particular method to detect | when the PE determines (the use of the particular method to detect | |||
the failure is outside the scope of this document) that C-S is not | the failure is outside the scope of this document) that C-S is not | |||
reachable through some other PE, the PE SHOULD install VRF PIM | reachable through some other PE (more details are in Section 4.3), | |||
state corresponding to this Standby BGP C-multicast route (the | the PE SHOULD install VRF PIM state corresponding to this Standby | |||
result will be that a PIM Join message will be sent to the CE | BGP C-multicast route (the result will be that a PIM Join message | |||
towards C-S, and that the PE will receive (C-S, C-G) traffic), and | will be sent to the CE towards C-S, and that the PE will receive | |||
the PE SHOULD forward (C-S, C-G) traffic received by the PE to | (C-S, C-G) traffic), and the PE SHOULD forward (C-S, C-G) traffic | |||
other PEs through a P-tunnel rooted at the PE. | received by the PE to other PEs through a P-tunnel rooted at the | |||
PE. | ||||
Furthermore, irrespective of whether C-S carried in that route is | Furthermore, irrespective of whether C-S carried in that route is | |||
reachable through some other PE: | reachable through some other PE: | |||
a) based on local policy, as soon as the PE receives this Standby BGP | a) based on local policy, as soon as the PE receives this Standby BGP | |||
C-multicast route, the PE MAY install VRF PIM state corresponding | C-multicast route, the PE MAY install VRF PIM state corresponding | |||
to this BGP Source Tree Join route (the result will be that Join | to this BGP Source Tree Join route (the result will be that Join | |||
messages will be sent to the CE toward C-S, and that the PE will | messages will be sent to the CE toward C-S, and that the PE will | |||
receive (C-S, C-G) traffic) | receive (C-S, C-G) traffic) | |||
skipping to change at page 15, line 14 ¶ | skipping to change at page 15, line 34 ¶ | |||
Doing b) (which implies also doing a)) for a given (C-S, C-G) is | Doing b) (which implies also doing a)) for a given (C-S, C-G) is | |||
called "hot root standby". | called "hot root standby". | |||
Note that, if an Upstream PE uses an S-PMSI only policy, it shall | Note that, if an Upstream PE uses an S-PMSI only policy, it shall | |||
advertise an S-PMSI for a (C-S, C-G) as soon as it receives a | advertise an S-PMSI for a (C-S, C-G) as soon as it receives a | |||
C-multicast route for (C-S, C-G), normal or Standby; i.e., it shall | C-multicast route for (C-S, C-G), normal or Standby; i.e., it shall | |||
not wait for receiving a non-Standby C-multicast route before | not wait for receiving a non-Standby C-multicast route before | |||
advertising the corresponding S-PMSI. | advertising the corresponding S-PMSI. | |||
Section 9.3.2 of [RFC6514], describes the procedures of sending a | Section 9.3.2 of [RFC6513], describes the procedures of sending a | |||
Source-Active A-D Route as a result of receiving the C-multicast | Source-Active A-D Route as a result of receiving the C-multicast | |||
route. These procedures MUST be followed for both the normal and | route. These procedures MUST be followed for both the normal and | |||
Standby C-multicast routes. | Standby C-multicast routes. | |||
4.3. Reachability Determination | 4.3. Reachability Determination | |||
The Standby Upstream PE can use the following information to | The Standby Upstream PE can use the following information to | |||
determine that C-S can or cannot be reached through the Primary | determine that C-S can or cannot be reached through the Primary | |||
Upstream PE: | Upstream PE: | |||
skipping to change at page 16, line 34 ¶ | skipping to change at page 16, line 51 ¶ | |||
described in Section 4.1. | described in Section 4.1. | |||
4.4.2. Inter-AS Procedures for ASBRs | 4.4.2. Inter-AS Procedures for ASBRs | |||
When an Upstream ASBR receives a C-multicast route, and at least one | When an Upstream ASBR receives a C-multicast route, and at least one | |||
of the RTs of the route matches one of the ASBR Import RT, the ASBR, | of the RTs of the route matches one of the ASBR Import RT, the ASBR, | |||
that supports this specification, MUST try to locate an Inter-AS | that supports this specification, MUST try to locate an Inter-AS | |||
I-PMSI A-D Route whose RD and Source AS respectively match the RD and | I-PMSI A-D Route whose RD and Source AS respectively match the RD and | |||
Source AS carried in the C-multicast route. If the match is found, | Source AS carried in the C-multicast route. If the match is found, | |||
and the C-multicast route carries the Standby PE BGP Community, then | and the C-multicast route carries the Standby PE BGP Community, then | |||
the ASBR MUST perform as follows: | the ASBR implementation that supports this specification MUST be | |||
configurable to perform as follows: | ||||
o if the route was received over iBGP and its LOCAL_PREF attribute | o if the route was received over iBGP and its LOCAL_PREF attribute | |||
is set to zero, then it MUST be re-advertised in eBGP with a MED | is set to zero, then it MUST be re-advertised in eBGP with a MED | |||
attribute (MULTI_EXIT_DISC) set to the highest possible value | attribute (MULTI_EXIT_DISC) set to the highest possible value | |||
(0xffff) | (0xffff) | |||
o if the route was received over eBGP and its MED attribute set to | o if the route was received over eBGP and its MED attribute set to | |||
0xffff, then it MUST be re-advertised in iBGP with a LOCAL_PREF | 0xffff, then it MUST be re-advertised in iBGP with a LOCAL_PREF | |||
attribute set to zero | attribute set to zero | |||
Other ASBR procedures are applied without modification. | Other ASBR procedures are applied without modification and, when | |||
applied, MAY modify the above-listed behavior. | ||||
5. Hot Root Standby | 5. Hot Root Standby | |||
The mechanisms defined in Section 4 and Section 3 can be used | The mechanisms defined in Section 4 and Section 3 can be used | |||
together as follows. | 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) | |||
o Upstream PEs use the "hot standby" optional behavior and thus will | o Upstream PEs use the "hot standby" optional behavior and thus will | |||
forward traffic for a given multicast state as soon as they have | start forwarding traffic for a given multicast state after they | |||
whether a (primary) BGP C-multicast route or a Standby BGP | have whether a (primary) BGP C-multicast route or a Standby BGP | |||
C-multicast route for that state (or both) | C-multicast route for that state (or both) | |||
o downstream PEs accept traffic from the primary or standby tunnel, | o downstream PEs accept traffic from the primary or standby tunnel, | |||
based on the status of the tunnel (based on Section 3) | based on the status of the tunnel (based on Section 3) | |||
Other combinations of the mechanisms proposed in Section 4 and | Other combinations of the mechanisms proposed in Section 4 and | |||
Section 3 are for further study. | Section 3 are for further study. | |||
Note that the same level of protection would be achievable with a | Note that the same level of protection would be achievable with a | |||
simple C-multicast Source Tree Join route advertised to both the | simple C-multicast Source Tree Join route advertised to both the | |||
End of changes. 34 change blocks. | ||||
80 lines changed or deleted | 98 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |