< 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: February 8, 2020 Juniper Networks | |||
G. Mirsky, Ed. | G. Mirsky, Ed. | |||
ZTE Corp. | ZTE Corp. | |||
February 14, 2019 | August 7, 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 February 8, 2020. | |||
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 41 ¶ | skipping to change at page 2, line 41 ¶ | |||
3.1.6. BFD Discriminator . . . . . . . . . . . . . . . . . . 6 | 3.1.6. BFD Discriminator . . . . . . . . . . . . . . . . . . 6 | |||
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 . . . . . . . . . . . . . . . . . . . . . . 14 | |||
6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 15 | 6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 15 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
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 | |||
1. Introduction | 1. Introduction | |||
skipping to change at page 3, line 41 ¶ | skipping to change at page 3, line 41 ¶ | |||
The terminology used in this document is the terminology defined in | The terminology used in this document is the terminology defined in | |||
[RFC6513] and [RFC6514]. | [RFC6513] and [RFC6514]. | |||
x-PMSI: I-PMSI or S-PMSI | x-PMSI: I-PMSI or S-PMSI | |||
3. UMH Selection based on tunnel status | 3. UMH Selection based on tunnel status | |||
Current multicast VPN specifications [RFC6513], section 5.1, describe | Current multicast VPN specifications [RFC6513], section 5.1, describe | |||
the procedures used by a multicast VPN downstream PE to determine | the procedures used by a multicast VPN downstream PE to determine | |||
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, Because all PEs could arrive at | |||
each given PE in the list of candidate UMHs for a given (C-S,C-G) | a different conclusion regarding the state of the tunnel, procedures | |||
state. The result is that, if a P-tunnel is "down" (see | described in Section 9.1.1 of [RFC6513] MUST be used when using | |||
Section 3.1), the PE that is the root of the P-tunnel will not be | inclusive tunnels. | |||
considered for UMH selection, which will result in the downstream PE | ||||
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 | ||||
consistent across all PEs, then some may arrive at a different | ||||
conclusion regarding the state of the tunnel, In such a scenario, | ||||
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 | For a given downstream PE and a given VRF, the P-tunnel corresponding | |||
ahead of the current one. Whenever the downstream PE determines that | to a given upstream PE for a given (C-S, C-G) state is the S-PMSI | |||
one of these tunnels is no longer "known to down", the PE selects the | tunnel advertised by that upstream PE for this (C-S, C-G) and | |||
UMH corresponding to that as the new UMH. | imported 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. | ||||
More precisely, UMH determination for a given (C-S,C-G) will consider | There are three options specified in Section 5.1 of [RFC6513] for a | |||
the UMH candidates in the following order: | downstream PE to select an Upstream PE. | |||
o first, the UMH candidates that either (a) advertise a PMSI bound | o The first two options select the Upstream PE from a candidate PE | |||
to a tunnel, where the specified tunnel is not known to be down or | set either based on IP address or a hashing algorithm. When used | |||
(b) do not advertise any x-PMSI applicable to the given (C-S,C-G) | together with the optional procedure of considering the P-tunnel | |||
but have associated a VRF Route Import BGP attribute to the | status as in this document, a candidate upstream PE is included | |||
unicast VPN route for S (this is necessary to avoid incorrectly | in the set if it either: | |||
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 | o | |||
that is "down" -- these will thus be used as a last resort to | ||||
ensure a graceful fallback to the basic MVPN UMH selection | ||||
procedures in the hypothetical case where a false negative would | ||||
occur when determining the status of all tunnels | ||||
For a given downstream PE and a given VRF, the P-tunnel corresponding | A. advertise a PMSI bound to a tunnel, where the specified tunnel | |||
to a given upstream PE for a given (C-S,C-G) state is the S-PMSI | is not known to be down or up | |||
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 | ||||
advertised by that PE and imported into that VRF. | ||||
Note that this document assumes that if a site of a given MVPN that | B. do not advertise any x-PMSI applicable to the given (C-S, C-G) | |||
contains C-S is dual-homed to two PEs, then all the other sites of | but have associated a VRF Route Import BGP attribute to the | |||
that MVPN would have two unicast VPN routes (VPN-IPv4 or VPN-IPv6) | unicast VPN route for S (this is necessary to avoid | |||
routes to C-S, each with its own RD. | incorrectly invalidating a 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). | ||||
If the resulting candidate set is empty, then the procedure is | ||||
repeated without considering the P-tunnel status. | ||||
o The third option uses the installed UMH Route (i.e., the "best" | ||||
route towards the C-root) as the Selected UMH Route, and its | ||||
originating PE is the selected Upstream PE. With the optional | ||||
procedure of considering P-tunnel status as in this document, the | ||||
Selected UMH Route is the best one among those whose originating | ||||
PE's P-tunnel is not "down". If that does not exist, the | ||||
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 proposed in this section also allow that all | optional procedures proposed in this section also allow that all | |||
downstream PEs don't apply the same rules to define what the status | downstream PEs don't apply the same rules to define what the status | |||
of a P-tunnel is (please see Section 6), and some of them will | of a P-tunnel is (please see Section 6), and some of them will | |||
produce a result that may be different for different downstream PEs. | produce a result that may be different for different downstream PEs. | |||
Thus what is called the "status" of a P-tunnel in this section, is | Thus what is called the "status" of a P-tunnel in this section, is | |||
not a characteristic of the tunnel in itself, but is the status of | not a characteristic of the tunnel in itself, but is the status of | |||
the tunnel, *as seen from a particular downstream PE*. Additionally, | the tunnel, *as seen from a particular downstream PE*. Additionally, | |||
some of the following methods determine the ability of downstream PE | some of the following methods determine the ability of downstream PE | |||
to receive traffic on the P-tunnel and not specifically on the status | to receive traffic on the P-tunnel and not specifically on the status | |||
of the P-tunnel itself. This could be referred to as "P-tunnel | of the P-tunnel itself. That could be referred to as "P-tunnel | |||
reception status", but for simplicity, we will use the terminology of | reception status", but for simplicity, we will use the terminology of | |||
P-tunnel "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. | |||
3.1.1. mVPN tunnel root tracking | 3.1.1. mVPN tunnel root tracking | |||
A condition to consider that the status of a P-tunnel is up is that | A condition to consider that the status of a P-tunnel is up is that | |||
the root of the tunnel, as determined in the PMSI tunnel attribute, | the root of the tunnel, as determined in the PMSI tunnel attribute, | |||
is reachable through unicast routing tables. In this case, the | is reachable through unicast routing tables. In this case, the | |||
downstream PE can immediately update its UMH when the reachability | downstream PE can immediately update its UMH when the reachability | |||
condition changes. | condition changes. | |||
This is similar to BGP next-hop tracking for VPN routes, except that | That is similar to BGP next-hop tracking for VPN routes, except that | |||
the address considered is not the BGP next-hop address, but the root | the address considered is not the BGP next-hop address, but the root | |||
address in the PMSI tunnel attribute. | address in the PMSI tunnel attribute. | |||
If BGP next-hop tracking is done for VPN routes and the root address | If BGP next-hop tracking is done for VPN routes and the root address | |||
of a given tunnel happens to be the same as the next-hop address in | of a given tunnel happens to be the same as the next-hop address in | |||
the BGP auto-discovery route advertising the tunnel, then this | the BGP auto-discovery route advertising the tunnel, then this | |||
mechanisms may be omitted for this tunnel, as it will not bring any | mechanisms may be omitted for this tunnel, as it will not bring any | |||
specific benefit. | specific benefit. | |||
3.1.2. PE-P Upstream link status | 3.1.2. PE-P Upstream link status | |||
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 | |||
A PE can be removed from the UMH candidate list for a given (C-S, | A PE can be removed from the UMH candidate list for a given (C-S, | |||
C-G) if the P-tunnel (I or S , depending) for this (S, G) is leaf | C-G) if the P-tunnel (I or S, depending) for this (S, G) is leaf | |||
triggered (PIM, mLDP), but for some reason internal to the protocol | triggered (PIM, mLDP), but for some reason internal to the protocol | |||
the upstream one-hop branch of the tunnel from P to PE cannot be | the upstream one-hop branch of the tunnel from P to PE cannot be | |||
built. In this case, the downstream PE can immediately update its | built. In this case, the downstream PE can immediately update its | |||
UMH when the reachability condition changes. | UMH when the reachability condition changes. | |||
3.1.5. (C-S, C-G) counter information | 3.1.5. (C-S, C-G) counter information | |||
In cases, where the downstream node can be configured so that the | In cases, where the downstream node can be configured so that the | |||
maximum inter-packet time is known for all the multicast flows mapped | maximum inter-packet time is known for all the multicast flows mapped | |||
on a P-tunnel, the local per-(C-S,C-G) traffic counter information | on a P-tunnel, the local per-(C-S, C-G) traffic counter information | |||
for traffic received on this P-tunnel can be used to determine the | for traffic received on this P-tunnel can be used to determine the | |||
status of the P-tunnel. | status of the P-tunnel. | |||
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, 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, no prior knowledge of the rate of the multicast | |||
multicast streams is required; downstream PEs can compare reception | streams is required; downstream PEs can compare reception on the two | |||
on the two P-tunnels to determine when one of them is down. | 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". It 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) | | |||
+-------------------------------+ | +-------------------------------+ | |||
The Flags field has the following format: | The Flags field has the following format: | |||
0 1 2 3 4 5 6 7 | 0 1 2 3 4 5 6 7 | |||
+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+ | |||
| 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 a 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 an 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 the tracking of the P-tunnel by using a p2mp BFD session is | |||
enabled after the P-tunnel has been already signaled, then the | enabled after the x-PMSI A-D route has been already advertised, the | |||
procedure described above MUST be followed. Note that x-PMSI A-D | x-PMSI A-D Route MUST be re-sent with precisely the same attributes | |||
Route MUST be re-sent with exactly the same attributes as before and | as before 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 precisely the same | |||
as before, but the BGP-BFD Attribute MUST be excluded; | attributes 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 the transition of the BFD session | |||
session into Down state as the indication of the associated PE-CE | into Down state as the indication of the associated PE-CE link being | |||
link being down. | down. | |||
For SSM groups, the upstream PE advertises an (C-S, C-G) S-PMSI A-D | For SSM groups, the upstream PE advertises a (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 | |||
PE advertises a wildcard (*,G) S-PMSI A-D route. Note that all | upstream PE advertises a wildcard (*, G) S-PMSI A-D route. Note that | |||
S-PMSI A-D routes can signal the same P-tunnel, so there is no need | all S-PMSI A-D routes can signal the same P-tunnel, so there is no | |||
for a new P-tunnel for each S-PMSI A-D route. Multicast flows for | need for a new P-tunnel for each S-PMSI A-D route. Multicast flows | |||
which protection is desired is controlled by configuration/policy on | for which protection is desired are controlled by configuration/ | |||
the upstream PE. The protected link is the RPF PE-CE interface | policy on the upstream PE. The protected link is the RPF PE-CE | |||
towards the src/RP. The upstream PE advertises the BFD Discriminator | interface towards the src/RP. The upstream PE advertises the BFD | |||
of the protected link in the S-PMSI A-D route. If the route to the | Discriminator of the protected link in the S-PMSI A-D route. If the | |||
src/RP changes such that the RPF interface is changed to be a new PE- | route to the src/RP changes such that the RPF interface is changed to | |||
CE interface, then the upstream PE will update the S-PMSI A-D route | be a new PE-CE interface, then the upstream PE will update the S-PMSI | |||
with included BGP-BFD Attribute so that the previously advertised | A-D route with included BGP-BFD Attribute so that the previously | |||
value of the BFD Discriminator is associated with the new RPF link. | advertised value of the BFD Discriminator is associated with the new | |||
RPF link. | ||||
3.1.7.2. Downstream PE Procedures | 3.1.7.2. Downstream PE Procedures | |||
If an S-PMSI A-D route bound to a given C-multicast is signaled with | If an S-PMSI A-D route bound to a given C-multicast is signaled with | |||
a multipoint BFD session, then the upstream PE is considered during | a multipoint BFD session, then the upstream PE is considered during | |||
UMH selection for the C-multicast if and only if the corresponding | UMH selection for the C-multicast if and only if the corresponding | |||
BFD session is not in state Down, i.e., bfd.SessionState != Down. | BFD session is not in state Down, i.e., bfd.SessionState != Down. | |||
Whenever the state of the BFD session changes to Down the Provider | Whenever the state of the BFD session changes to Down the Provider | |||
Tunnel will be considered down, and the downstream PE MAY switch to | Tunnel will be considered down, and the downstream PE MAY switch to | |||
the backup Provider Tunnel only if the backup Provider Tunnel deemed | the backup Provider Tunnel only if the backup Provider Tunnel deemed | |||
skipping to change at page 10, line 41 ¶ | skipping to change at page 10, line 37 ¶ | |||
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 simplify | that contains C-S is connected to two or more PEs though, to simplify | |||
the description, the case of dual-homing is described. The | the description, the case of dual-homing is described. The | |||
procedures require all the PEs of that MVPN to follow the UMH | procedures require all the PEs of that MVPN to follow the UMH | |||
selection, as specified in [RFC6513], whether the PE selected based | selection, as specified in [RFC6513], whether the PE selected based | |||
on its IP address, hashing algorithm described in section 5.1.3 | on its IP address, hashing algorithm described in section 5.1.3 | |||
[RFC6513], or Installed UMH Route. The procedures assume that if a | [RFC6513], or Installed UMH Route. The procedures assume that if a | |||
site of a given MVPN that contains C-S is dual-homed to two PEs, then | 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 | all the other sites of that MVPN would have two unicast VPN routes | |||
(VPN-IPv4 or VPN-IPv6) routes to C-S, each with its own RD. | (VPN-IPv4 or VPN-IPv6) routes to C-S, each with its 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 with | select one of the PEs connected to C-S as its Upstream PE for C-S. | |||
respect to C-S. We will refer to the other PE connected to C-S as | We will refer to the other PE connected to C-S as the "Standby | |||
the "Standby Upstream PE". Note that if the connectivity to C-S | Upstream PE". Note that if the connectivity to C-S through the | |||
through the Primary Upstream PE becomes unavailable, then the PE will | Primary Upstream PE becomes unavailable, then the PE will select the | |||
select the Standby Upstream PE as its Upstream PE with respect to | Standby Upstream PE as its Upstream PE for C-S. When the Primary PE | |||
C-S. When the Primary PE later becomes available, then the PE will | later becomes available, then the PE will select the Primary Upstream | |||
select the Primary Upstream PE again as its Upstream PE. This is | PE again as its Upstream PE. Such behavior is referred to as | |||
referred to as "revertive" behavior and MUST be supported. Non- | "revertive" behavior and MUST be supported. Non-revertive behavior | |||
revertive behavior would refer to the behavior of continuing to | would refer to the behavior of continuing to select the backup PE as | |||
select the backup PE as the UMH even after the Primary has come up. | the UMH even after the Primary has come up. This non-revertive | |||
This non-revertive behavior can also be optionally supported by an | behavior can also be optionally supported by an implementation and | |||
implementation and would be enabled through some configuration. | would be enabled through some configuration. | |||
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 failover for the | equally to BGP C-multicast Shared Tree Join routes failover for the | |||
case where the customer RP is dual-homed (substitute "C-RP" to | case where the customer RP is dual-homed (substitute "C-RP" to | |||
"C-S"). | "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 | |||
specified in Section "Originating C-multicast routes by a PE" of | specified in Section "Originating C-multicast routes by a PE" of | |||
[RFC6514] the PE sends the C-multicast route with RT that identifies | [RFC6514] the PE sends the C-multicast route with RT that identifies | |||
the Upstream PE selected by the PE originating the route. As long as | the Upstream PE selected by the PE originating the route. As long as | |||
C-S is reachable via the Primary Upstream PE, the Upstream PE is the | C-S is reachable via the Primary Upstream PE, and the Upstream PE is | |||
Primary Upstream PE. If C-S is reachable only via the Standby | the Primary Upstream PE. If C-S is reachable only via the Standby | |||
Upstream PE, then the Upstream PE is the Standby Upstream PE. | Upstream PE, then the Upstream PE is the Standby Upstream PE. | |||
If C-S is reachable via both the Primary and the Standby Upstream PE, | If C-S is reachable via both the Primary and the Standby Upstream PE, | |||
then in addition to sending the C-multicast route with an RT that | then in addition to sending the C-multicast route with an RT that | |||
identifies the Primary Upstream PE, the PE also originates and sends | identifies the Primary Upstream PE, the PE also originates and sends | |||
a C-multicast route with an RT that identifies the Standby Upstream | a C-multicast route with an RT that identifies the Standby Upstream | |||
PE. This route, that has the semantics of being a 'standby' | PE. This route that has the semantics of being a 'standby' | |||
C-multicast route, is further called a "Standby BGP C-multicast | C-multicast route is further called a "Standby BGP C-multicast | |||
route", and is constructed as follows: | route", and is constructed as follows: | |||
o the NLRI is constructed as the original C-multicast route, except | o the NLRI is constructed as the original C-multicast route, except | |||
that the RD is the same as if the C-multicast route was built | that the RD is the same as if the C-multicast route was built | |||
using the standby PE as the UMH (it will carry the RD associated | using the standby PE as the UMH (it will carry the RD associated | |||
to the unicast VPN route advertised by the standby PE for S and a | to the unicast VPN route advertised by the standby PE for S and a | |||
Route Target derived from the standby PE's UMH route's VRF RT | Route Target derived from the standby PE's UMH route's VRF RT | |||
Import EC); | Import EC); | |||
o SHOULD carry the "Standby PE" BGP Community (this is a new BGP | o SHOULD carry the "Standby PE" BGP Community (this is a new BGP | |||
skipping to change at page 12, line 10 ¶ | skipping to change at page 12, line 5 ¶ | |||
community, then preference is given to the one *not* carrying the | community, then preference is given to the one *not* carrying the | |||
"Standby PE" attribute. Such a situation can happen when, for | "Standby PE" attribute. Such a situation can happen when, for | |||
instance, due to transient unicast routing inconsistencies, two | instance, due to transient unicast routing inconsistencies, two | |||
different downstream PEs consider different upstream PEs to be the | different downstream PEs consider different upstream PEs to be the | |||
primary one; in that case, without any precaution taken, both | primary one; in that case, without any precaution taken, both | |||
upstream PEs would process a standby C-multicast route and possibly | upstream PEs would process a standby C-multicast route and possibly | |||
stop forwarding at the same time. For this purpose, routes that | stop forwarding at the same time. For this purpose, routes that | |||
carry the "Standby PE" BGP Community MUST have the LOCAL_PREF | carry the "Standby PE" BGP Community MUST have the LOCAL_PREF | |||
attribute set to zero. | attribute set to zero. | |||
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 a | |||
an (C-S, C-G) it must join the corresponding P-tunnel. | (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 | |||
this Standby BGP C-multicast route (the result will be that a PIM | this Standby BGP C-multicast route (the result will be that a PIM | |||
Join message will be sent to the CE towards C-S, and that the PE | Join message will be sent to the CE towards C-S, and that the PE | |||
will receive (C-S,C-G) traffic), and the PE SHOULD forward (C-S, | will receive (C-S, C-G) traffic), and the PE SHOULD forward (C-S, | |||
C-G) traffic received by the PE to other PEs through a P-tunnel | C-G) traffic received by the PE to other PEs through a P-tunnel | |||
rooted at the PE. | 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) | |||
b) based on local policy, as soon as the PE receives this Standby BGP | b) based on local policy, as soon as the PE receives this Standby BGP | |||
C-multicast route, the PE MAY forward (C-S, C-G) traffic to other | C-multicast route, the PE MAY forward (C-S, C-G) traffic to other | |||
PEs through a P-tunnel independently of the reachability of C-S | PEs through a P-tunnel independently of the reachability of C-S | |||
through some other PE. [note that this implies also doing (a)] | through some other PE. [note that this implies also doing (a)] | |||
Doing neither (a) or (b) for a given (C-S,C-G) is called "cold root | Doing neither (a) or (b) for a given (C-S, C-G) is called "cold root | |||
standby". | standby". | |||
Doing (a) but not (b) for a given (C-S,C-G) is called "warm root | Doing (a) but not (b) for a given (C-S, C-G) is called "warm root | |||
standby". | standby". | |||
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 an (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 [RFC6514], describes the procedures of sending a | |||
Source-Active A-D result as a result of receiving the C-multicast | Source-Active A-D result as a result of receiving the C-multicast | |||
route. These procedures should be followed for both the normal and | route. These procedures should 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 PE can use the following information to determine that | The standby PE can use the following information to determine that | |||
C-S can or cannot be reached through the primary PE: | C-S can or cannot be reached through the primary PE: | |||
o presence/absence of a unicast VPN route toward C-S | o presence/absence of a unicast VPN route toward C-S | |||
o supposing that the standby PE is an egress of the tunnel rooted at | o supposing that the standby PE is the egress of the tunnel rooted | |||
the Primary PE, the standby PE can determine the reachability of | at the Primary PE, the standby PE can determine the reachability | |||
C-S through the Primary PE based on the status of this tunnel, | of C-S through the Primary PE based on the status of this tunnel, | |||
determined thanks to the same criteria as the ones described in | determined thanks to the same criteria as the ones described in | |||
Section 3.1 (without using the UMH selection procedures of | Section 3.1 (without using the UMH selection procedures of | |||
Section 3); | Section 3); | |||
o other mechanisms MAY be used. | o other mechanisms MAY be used. | |||
4.4. Inter-AS | 4.4. Inter-AS | |||
If the non-segmented inter-AS approach is used, the procedures in | If the non-segmented inter-AS approach is used, the procedures in | |||
section 4 can be applied. | section 4 can be applied. | |||
skipping to change at page 14, line 39 ¶ | skipping to change at page 14, line 32 ¶ | |||
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 | |||
locates an Inter-AS I-PMSI A-D route whose RD and Source AS matches | locates an Inter-AS I-PMSI A-D route whose RD and Source AS matches | |||
the RD and Source AS carried in the C-multicast route. If the match | the RD and Source AS carried in the C-multicast route. If the match | |||
is found, and C-multicast route carries the Standby PE BGP Community, | is found, and C-multicast route carries the Standby PE BGP Community, | |||
then the ASBR performs as follows: | then the ASBR performs as follows: | |||
o if the route was received over iBGP; the route is expected to have | o if the route was received over iBGP; the route is expected to have | |||
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) | |||
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 | forward traffic for a given multicast state as soon as they have | |||
whether a (primary) BGP C-multicast route or a Standby BGP | 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 | |||
primary and secondary upstream PEs (carrying as Route Target extended | primary and secondary upstream PEs (carrying as Route Target extended | |||
communities, the values of the VRF Route Import attribute of each VPN | communities, the values of the VRF Route Import attribute of each VPN | |||
route from each upstream PEs). The advantage of using the Standby | route from each upstream PEs). The advantage of using the Standby | |||
semantic for is that, supposing that downstream PEs always advertise | semantic for is that, supposing that downstream PEs always advertise | |||
a Standby C-multicast route to the secondary upstream PE, it allows | a Standby C-multicast route to the secondary upstream PE, it allows | |||
to choose the protection level through a change of configuration on | to choose the protection level through a change of configuration on | |||
skipping to change at page 15, line 47 ¶ | skipping to change at page 15, line 36 ¶ | |||
6. Duplicate packets | 6. Duplicate packets | |||
Multicast VPN specifications [RFC6513] impose that a PE only forwards | Multicast VPN specifications [RFC6513] impose that a PE only forwards | |||
to CEs the packets coming from the expected upstream PE | to CEs the packets coming from the expected upstream PE | |||
(Section 9.1). | (Section 9.1). | |||
We highlight the reader's attention to the fact that the respect of | We highlight the reader's attention to the fact that the respect of | |||
this part of multicast VPN specifications is especially important | this part of multicast VPN specifications is especially important | |||
when two distinct upstream PEs are susceptible to forward the same | when two distinct upstream PEs are susceptible to forward the same | |||
traffic on P-tunnels at the same time in the steady state. This will | traffic on P-tunnels at the same time in the steady state. That will | |||
be the case when "hot root standby" mode is used (Section 4), and | be the case when "hot root standby" mode is used (Section 4), and | |||
which can also be the case if procedures of Section 3 are used and | which can also be the case if procedures of Section 3 are used and | |||
(a) the rules determining the status of a tree are not the same on | (a) the rules determining the status of a tree are not the same on | |||
two distinct downstream PEs or (b) the rule determining the status of | two distinct downstream PEs or (b) the rule determining the status of | |||
a tree depend on conditions local to a PE (e.g. the PE-P upstream | a tree depends on conditions local to a PE (e.g., the PE-P upstream | |||
link being up). | link being up). | |||
7. IANA Considerations | 7. IANA Considerations | |||
Allocation is expected from IANA for the BGP "Standby PE" community. | Allocation is expected from IANA for the BGP "Standby PE" community. | |||
(TBC) | (TBC) | |||
8. Security Considerations | 8. Security Considerations | |||
9. Acknowledgments | 9. Acknowledgments | |||
skipping to change at page 18, line 24 ¶ | skipping to change at page 18, line 16 ¶ | |||
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. 59 change blocks. | ||||
154 lines changed or deleted | 158 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/ |