Skip to main content

RFC 9026 - Multicast VPN Fast Upstream Failover

Abstract​

This document defines Multicast Virtual Private Network (VPN) extensions and procedures that allow fast failover for upstream failures by allowing downstream Provider Edges (PEs) to consider the status of Provider-Tunnels (P-tunnels) when selecting the Upstream PE for a VPN multicast flow. The fast failover is enabled by using "Bidirectional Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562) and the new BGP Attribute, BFD Discriminator. Also, this document introduces a new BGP Community, Standby PE, extending BGP Multicast VPN (MVPN) routing so that a C-multicast route can be advertised toward a Standby Upstream PE.

Status of This Memo​

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9026.

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents​

    1. Introduction
    1. Conventions Used in This Document
    1. UMH Selection Based on Tunnel Status
    1. Standby C-Multicast Route
    1. Hot Root Standby
    1. Duplicate Packets
    1. IANA Considerations
    1. Security Considerations
    1. References
  • Acknowledgments
  • Contributors
  • Authors' Addresses

1. Introduction​

It is assumed that the reader is familiar with the workings of multicast MPLS/BGP IP VPNs as described in [RFC6513] and [RFC6514].

In the context of multicast in BGP/MPLS VPNs [RFC6513], it is desirable to provide mechanisms allowing fast recovery of connectivity on different types of failures. This document addresses failures of elements in the provider network that are upstream of PEs connected to VPN sites with receivers.

Section 3 describes local procedures allowing an egress PE (a PE connected to a receiver site) to take into account the status of P-tunnels to determine the Upstream Multicast Hop (UMH) for a given (C-S,C-G). One of the optional methods uses [RFC8562] and the new BGP Attribute, BFD Discriminator. None of these methods provide a "fast failover" solution when used alone but can be used together with the mechanism described in Section 4 for a "fast failover" solution.

Section 4 describes an optional BGP extension, a new Standby PE Community, that can speed up failover by not requiring any Multicast VPN (MVPN) routing message exchange at recovery time.

Section 5 describes a "hot root standby" mechanism that can be used to improve failover time in MVPN. The approach combines mechanisms defined in Sections 3 and 4 and has similarities with the solution described in [RFC7431] to improve failover times when PIM routing is used in a network given some topology and metric constraints.

2. Conventions Used in This Document​

2.1. Requirements Language​

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2.2. Terminology​

The terminology used in this document is the terminology defined in [RFC6513] and [RFC6514].

2.3. Abbreviations​

This document uses the following abbreviations:

  • BFD: Bidirectional Forwarding Detection
  • MVPN: Multicast Virtual Private Network
  • NLRI: Network Layer Reachability Information
  • PE: Provider Edge
  • PMSI: Provider Multicast Service Interface
  • RPT: Rendezvous Point Tree
  • SPT: Shortest Path Tree
  • UMH: Upstream Multicast Hop
  • VPN: Virtual Private Network
  • VRF: VPN Routing and Forwarding

3. UMH Selection Based on Tunnel Status​

Section 5.1 of RFC 6513 describes procedures used by an MVPN downstream PE to determine the Upstream Multicast Hop (UMH) for a given (C-S,C-G).

For a given downstream PE and a given VRF, the P-tunnel corresponding to a given Upstream PE for a given (C-S,C-G) state is the S-PMSI tunnel advertised by that Upstream PE for that (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.

The procedure described here is optional one, based on a downstream PE taking into account the status of P-tunnels rooted at each possible Upstream PE, for including or not including each given PE in the list of candidate UMHs for a given (C-S,C-G) state. If it is not possible to determine whether a P-tunnel's current status is Up, the state shall be considered "not known to be Down", 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 (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 PE failing over to use the next Upstream PE in the list of candidates. Some downstream PEs could arrive at a different conclusion regarding the tunnel's state because the failure impacts only a subset of branches. Because of that, the procedures of Section 9.1.1 of RFC 6513 are applicable when using I-PMSI P-tunnels. That document is a foundation for this document, and its processes all apply here.

There are three options specified in Section 5.1 of RFC 6513 for a downstream PE to select an Upstream PE.

The first two options select the Upstream PE from a candidate PE set based either on an IP address or a hashing algorithm. When used together with the optional procedure of considering the P-tunnel status as in this document, a candidate Upstream PE is included in the set if it either:

  • advertises an x-PMSI bound to a tunnel, where the specified tunnel's state is not known to be Down, or,
  • does not advertise any x-PMSI applicable to the given (C-S,C-G) but has associated a VRF Route Import BGP Extended Community to the unicast VPN route for S. That is necessary to avoid incorrectly invalidating a UMH PE that would use a policy where no I-PMSI is advertised for a given VRF and where only S-PMSIs are used. The S-PMSI can be advertised 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.

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​

Different factors can be considered to determine the "status" of a P-tunnel and are described in the following subsections. The optional procedures described in this section also handle the case when the downstream PEs do not all apply the same rules to define what the status 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. Thus, the "status" of a P-tunnel in this section is not a characteristic of the tunnel in itself but is the tunnel status, as seen from a particular downstream PE. Additionally, some of the following methods determine the ability of a downstream PE to receive traffic on the P-tunnel and not specifically on the status of the P-tunnel itself. That could be referred to as "P-tunnel reception status", but for simplicity, we will use the terminology of P-tunnel "status" for all of these methods.

Depending on the criteria used to determine the status of a P-tunnel, there may be an interaction with another resiliency mechanism used 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 separate subsection below.

An implementation may support any combination of the methods described in this section and provide a network operator with control to choose which one to use in the particular deployment.

3.1.1. MVPN Tunnel Root Tracking​

When determining if the status of a P-tunnel is Up, a condition to consider is whether the root of the tunnel, as specified in the x-PMSI Tunnel attribute, is reachable through unicast routing tables. In this case, the downstream PE can immediately update its UMH when the reachability condition changes.

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 address in the x-PMSI Tunnel attribute. BGP next-hop tracking monitors BGP nexthops.

To determine the status of a P-tunnel, the downstream PE can check the status of the link that it uses to reach the Upstream PE. If the link is down, the P-tunnel status is considered Down.

3.1.3. P2MP RSVP-TE Tunnels​

For Point-to-Multipoint (P2MP) RSVP-TE tunnels, the status of the tunnel can be determined by the state of the RSVP-TE Label Switched Path (LSP). If the LSP is down, the P-tunnel status is considered Down.

3.1.4. Leaf-Initiated P-Tunnels​

For leaf-initiated P-tunnels, the status can be determined by the state of the signaling protocol used to set up the tunnel.

3.1.5. (C-S,C-G) Counter Information​

The status of a P-tunnel can also be inferred from the traffic statistics for a specific (C-S,C-G). If the traffic rate drops below a certain threshold, the P-tunnel status can be considered Down.

3.1.6. BFD Discriminator Attribute​

This document defines a new BGP Attribute, BFD Discriminator, which can be used to associate a BFD session with a P-tunnel. The status of the BFD session determines the status of the P-tunnel.

In some cases, it may be useful to associate a BFD discriminator with a specific PE-CE link. This allows the downstream PE to monitor the status of the link to the CE using BFD.

3.1.8. Operational Considerations for Monitoring a P-Tunnel's Status​

When monitoring the status of a P-tunnel, care must be taken to avoid false positives and to ensure that the monitoring mechanism does not introduce excessive overhead.

4. Standby C-Multicast Route​

This section describes an optional BGP extension, a new Standby PE Community, that can speed up failover by not requiring any Multicast VPN (MVPN) routing message exchange at recovery time.

4.1. Downstream PE Behavior​

A downstream PE that supports the Standby PE Community can advertise a C-multicast route to a Standby Upstream PE. This allows the Standby Upstream PE to be pre-programmed with the necessary state to forward traffic for the (C-S,C-G).

4.2. Upstream PE Behavior​

An Upstream PE that receives a C-multicast route with the Standby PE Community MUST install the state for the (C-S,C-G) but MUST NOT forward traffic until it is selected as the UMH.

4.3. Reachability Determination​

The downstream PE determines the reachability of the Upstream PE and the Standby Upstream PE using the mechanisms described in Section 3.

4.4. Inter-AS​

This section describes the procedures for Inter-AS scenarios.

4.4.1. Inter-AS Procedures for Downstream PEs, ASBR Fast Failover​

In Inter-AS scenarios, the downstream PE can use the Standby PE Community to advertise C-multicast routes to ASBRs.

4.4.2. Inter-AS Procedures for ASBRs​

ASBRs can use the Standby PE Community to advertise C-multicast routes to other ASBRs or to Upstream PEs.

5. Hot Root Standby​

This section describes a "hot root standby" mechanism that can be used to improve failover time in MVPN. The approach combines mechanisms defined in Sections 3 and 4 and has similarities with the solution described in [RFC7431] to improve failover times when PIM routing is used in a network given some topology and metric constraints.

6. Duplicate Packets​

When using the fast failover mechanisms described in this document, it is possible for duplicate packets to be delivered to the receiver. This section discusses the implications of duplicate packets and how to mitigate them.

7. IANA Considerations​

7.1. Standby PE Community​

IANA has assigned a BGP Community value for the Standby PE Community.

7.2. BFD Discriminator​

IANA has assigned a BGP Attribute type code for the BFD Discriminator Attribute.

7.3. BFD Discriminator Optional TLV Type​

IANA has assigned a Type value for the BFD Discriminator Optional TLV in the BGP Tunnel Encapsulation Attribute.

8. Security Considerations​

The security considerations for this document are similar to those for [RFC6513] and [RFC6514]. In addition, the use of BFD introduces new security considerations related to the authentication and integrity of BFD packets.

9. References​

9.1. Normative References​

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, https://www.rfc-editor.org/info/rfc2119.

[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, https://www.rfc-editor.org/info/rfc6513.

[RFC6514] Aggarwal, R., Ed., Rosen, E., Ed., Morin, T., Ed., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, https://www.rfc-editor.org/info/rfc6514.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, https://www.rfc-editor.org/info/rfc8174.

[RFC8562] Katz, D., Ward, D., and S. Pallagatti, Ed., "Bidirectional Forwarding Detection (BFD) for Multipoint Networks", RFC 8562, DOI 10.17487/RFC8562, April 2019, https://www.rfc-editor.org/info/rfc8562.

9.2. Informative References​

[RFC7431] Karan, A., Wijnands, IJ., Ed., and E. Rosen, "Multicast-Only Fast Reroute", RFC 7431, DOI 10.17487/RFC7431, August 2015, https://www.rfc-editor.org/info/rfc7431.

[RFC7841] Halpern, J., Ed., Resnick, P., Ed., and O. Kolkman, Ed., "RFC Streams, Headers, and Boilerplates", RFC 7841, DOI 10.17487/RFC7841, May 2016, https://www.rfc-editor.org/info/rfc7841.

Acknowledgments​

The authors would like to thank...

Contributors​

...

Authors' Addresses​

Thomas Morin (editor) Orange Email: [email protected]

Robert Kebler (editor) Juniper Networks Email: [email protected]

Greg Mirsky (editor) ZTE Corp. Email: [email protected]

Last updated on