Zum Hauptinhalt springen

RFC 9026 - Multicast VPN Fast Upstream Failover

  • Status: Proposed Standard
  • Veröffentlicht: April 2021
  • Stream: IETF
  • Errata: Keine Errata

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.

Dieses Dokument definiert Erweiterungen und Verfahren für Multicast Virtual Private Network (VPN), die ein schnelles Failover bei Upstream-Ausfällen ermöglichen, indem sie Downstream-Provider-Edges (PEs) gestatten, den Status von Provider-Tunneln (P-Tunnels) bei der Auswahl des Upstream-PE für einen VPN-Multicast-Flow zu berücksichtigen. Das schnelle Failover wird durch die Verwendung von "Bidirectional Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562) und dem neuen BGP-Attribut BFD Discriminator ermöglicht. Außerdem führt dieses Dokument eine neue BGP-Community, Standby PE, ein, die das BGP Multicast VPN (MVPN)-Routing erweitert, sodass eine C-Multicast-Route zu einem Standby-Upstream-PE angekündigt werden kann.

Status of This Memo​

This is an Internet Standards Track document.

Dies ist ein Internet Standards Track-Dokument.

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.

Dieses Dokument ist ein Produkt der Internet Engineering Task Force (IETF). Es stellt den Konsens der IETF-Community dar. Es wurde öffentlich überprüft und von der Internet Engineering Steering Group (IESG) zur Veröffentlichung freigegeben. Weitere Informationen zu Internetstandards finden Sie in Abschnitt 2 von 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.

Informationen zum aktuellen Status dieses Dokuments, zu etwaigen Errata und zur Abgabe von Feedback finden Sie unter https://www.rfc-editor.org/info/rfc9026.

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

Copyright (c) 2021 IETF Trust und die als Dokumentautoren identifizierten Personen. Alle Rechte vorbehalten.

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.

Dieses Dokument unterliegt BCP 78 und den gesetzlichen Bestimmungen des IETF Trust in Bezug auf IETF-Dokumente (https://trustee.ietf.org/license-info), die zum Zeitpunkt der Veröffentlichung dieses Dokuments gelten. Bitte lesen Sie diese Dokumente sorgfältig durch, da sie Ihre Rechte und Einschränkungen in Bezug auf dieses Dokument beschreiben. Aus diesem Dokument extrahierte Codekomponenten müssen den vereinfachten BSD-Lizenztext enthalten, wie in Abschnitt 4.e der gesetzlichen Bestimmungen des Trust beschrieben, und werden ohne Gewährleistung bereitgestellt, wie in der vereinfachten BSD-Lizenz beschrieben.

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].

Es wird davon ausgegangen, dass der Leser mit der Funktionsweise von Multicast-MPLS/BGP-IP-VPNs vertraut ist, wie in [RFC6513] und [RFC6514] beschrieben.

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.

Im Kontext von Multicast in BGP/MPLS-VPNs [RFC6513] ist es wünschenswert, Mechanismen bereitzustellen, die eine schnelle Wiederherstellung der Konnektivität bei verschiedenen Arten von Ausfällen ermöglichen. Dieses Dokument befasst sich mit Ausfällen von Elementen im Provider-Netzwerk, die PEs vorgelagert sind, die mit VPN-Standorten mit Empfängern verbunden sind.

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.

Abschnitt 3 beschreibt lokale Verfahren, die es einem Egress-PE (einem mit einem Empfängerstandort verbundenen PE) ermöglichen, den Status von P-Tunneln zu berücksichtigen, um den Upstream Multicast Hop (UMH) für ein gegebenes (C-S,C-G) zu bestimmen. Eine der optionalen Methoden verwendet [RFC8562] und das neue BGP-Attribut BFD Discriminator. Keine dieser Methoden bietet eine "Fast Failover"-Lösung, wenn sie alleine verwendet wird, kann aber zusammen mit dem in Abschnitt 4 beschriebenen Mechanismus für eine "Fast Failover"-Lösung verwendet werden.

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.

Abschnitt 4 beschreibt eine optionale BGP-Erweiterung, eine neue Standby PE Community, die das Failover beschleunigen kann, indem zum Zeitpunkt der Wiederherstellung kein Austausch von Multicast VPN (MVPN)-Routingnachrichten erforderlich ist.

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.

Abschnitt 5 beschreibt einen "Hot Root Standby"-Mechanismus, der verwendet werden kann, um die Failover-Zeit in MVPN zu verbessern. Der Ansatz kombiniert die in den Abschnitten 3 und 4 definierten Mechanismen und weist Ähnlichkeiten mit der in [RFC7431] beschriebenen Lösung auf, um die Failover-Zeiten zu verbessern, wenn PIM-Routing in einem Netzwerk unter Berücksichtigung bestimmter Topologie- und Metrikbeschränkungen verwendet wird.

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.

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in BCP 14 [RFC2119] [RFC8174] beschrieben, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

2.2. Terminology​

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

Die in diesem Dokument verwendete Terminologie ist die in [RFC6513] und [RFC6514] definierte Terminologie.

2.3. Abbreviations​

This document uses the following abbreviations:

Dieses Dokument verwendet die folgenden Abkürzungen:

  • BFD: Bidirectional Forwarding Detection (Bidirektionale Weiterleitungserkennung)
  • MVPN: Multicast Virtual Private Network (Virtuelles privates Multicast-Netzwerk)
  • NLRI: Network Layer Reachability Information (Erreichbarkeitsinformationen der Vermittlungsschicht)
  • PE: Provider Edge (Provider-Rand)
  • PMSI: Provider Multicast Service Interface (Provider-Multicast-Service-Schnittstelle)
  • RPT: Rendezvous Point Tree (Rendezvous-Point-Baum)
  • SPT: Shortest Path Tree (Kürzester-Pfad-Baum)
  • UMH: Upstream Multicast Hop (Upstream-Multicast-Hop)
  • VPN: Virtual Private Network (Virtuelles privates Netzwerk)
  • VRF: VPN Routing and Forwarding (VPN-Routing und -Weiterleitung)

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).

Abschnitt 5.1 von RFC 6513 beschreibt Verfahren, die von einem MVPN-Downstream-PE verwendet werden, um den Upstream Multicast Hop (UMH) für ein gegebenes (C-S,C-G) zu bestimmen.

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.

Für einen gegebenen Downstream-PE und einen gegebenen VRF ist der P-Tunnel, der einem gegebenen Upstream-PE für einen gegebenen (C-S,C-G)-Zustand entspricht, der S-PMSI-Tunnel, der von diesem Upstream-PE für dieses (C-S,C-G) angekündigt und in diesen VRF importiert wurde, oder, wenn kein solcher S-PMSI vorhanden ist, der I-PMSI-Tunnel, der von diesem PE angekündigt und in diesen VRF importiert wurde.

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.

Das hier beschriebene Verfahren ist optional und basiert darauf, dass ein Downstream-PE den Status von P-Tunneln berücksichtigt, die an jedem möglichen Upstream-PE verwurzelt sind, um jeden gegebenen PE in die Liste der Kandidaten-UMHs für einen gegebenen (C-S,C-G)-Zustand aufzunehmen oder nicht. Wenn nicht festgestellt werden kann, ob der aktuelle Status eines P-Tunnels "Up" ist, gilt der Status als "nicht als Down bekannt" und kann so behandelt werden, als wäre er "Up", sodass Versuche, den Tunnel zu verwenden, akzeptabel sind. Das Ergebnis ist, dass, wenn ein P-Tunnel "Down" ist (siehe Abschnitt 3.1), der PE, der die Wurzel des P-Tunnels ist, nicht für die UMH-Auswahl berücksichtigt wird. Dies führt dazu, dass der Downstream-PE auf den nächsten Upstream-PE in der Kandidatenliste umschaltet. Einige Downstream-PEs könnten zu einer anderen Schlussfolgerung bezüglich des Tunnelstatus kommen, da der Ausfall nur eine Teilmenge von Zweigen betrifft. Aus diesem Grund sind die Verfahren von Abschnitt 9.1.1 von RFC 6513 anwendbar, wenn I-PMSI-P-Tunnel verwendet werden. Dieses Dokument ist eine Grundlage für dieses Dokument, und seine Prozesse gelten alle hier.

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

In Abschnitt 5.1 von RFC 6513 sind drei Optionen für einen Downstream-PE zur Auswahl eines Upstream-PE angegeben.

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:

Die ersten beiden Optionen wählen den Upstream-PE aus einem Kandidaten-PE-Satz basierend entweder auf einer IP-Adresse oder einem Hashing-Algorithmus aus. Bei Verwendung zusammen mit dem optionalen Verfahren zur Berücksichtigung des P-Tunnel-Status wie in diesem Dokument wird ein Kandidaten-Upstream-PE in den Satz aufgenommen, wenn er entweder:

  • advertises an x-PMSI bound to a tunnel, where the specified tunnel's state is not known to be Down, or,
  • ein an einen Tunnel gebundenes x-PMSI ankündigt, wobei der Status des angegebenen Tunnels nicht als "Down" bekannt ist, oder,
  • 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.
  • kein für das gegebene (C-S,C-G) anwendbares x-PMSI ankündigt, aber der Unicast-VPN-Route für S eine VRF Route Import BGP Extended Community zugeordnet hat. Dies ist notwendig, um zu vermeiden, dass fälschlicherweise ein UMH-PE ungültig gemacht wird, der eine Richtlinie verwenden würde, bei der kein I-PMSI für einen gegebenen VRF angekündigt wird und bei der nur S-PMSIs verwendet werden. Das S-PMSI kann erst angekündigt werden, nachdem der Upstream-PE eine C-Multicast-Route für (C-S,C-G) / (C-*,C-G) erhalten hat, die über das angekündigte S-PMSI übertragen werden soll.

If the resulting candidate set is empty, then the procedure is repeated without considering the P-tunnel status.

Wenn der resultierende Kandidatensatz leer ist, wird das Verfahren wiederholt, ohne den P-Tunnel-Status zu berücksichtigen.

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.

Die dritte Option verwendet die installierte UMH-Route (d. h. die "beste" Route zum C-Root) als ausgewählte UMH-Route, und ihr Ursprungs-PE ist der ausgewählte Upstream-PE. Mit dem optionalen Verfahren zur Berücksichtigung des P-Tunnel-Status wie in diesem Dokument ist die ausgewählte UMH-Route die beste unter denen, deren Ursprungs-PE-P-Tunnel nicht "down" ist. Wenn dies nicht existiert, wird die installierte UMH-Route unabhängig vom P-Tunnel-Status ausgewählt.

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.

Verschiedene Faktoren können berücksichtigt werden, um den "Status" eines P-Tunnels zu bestimmen, und werden in den folgenden Unterabschnitten beschrieben. Die in diesem Abschnitt beschriebenen optionalen Verfahren behandeln auch den Fall, dass die Downstream-PEs nicht alle dieselben Regeln anwenden, um zu definieren, was der Status eines P-Tunnels ist (siehe Abschnitt 6), und einige von ihnen führen zu einem Ergebnis, das für verschiedene Downstream-PEs unterschiedlich sein kann. Somit ist der "Status" eines P-Tunnels in diesem Abschnitt kein Merkmal des Tunnels an sich, sondern der Tunnelstatus, wie er von einem bestimmten Downstream-PE gesehen wird. Darüber hinaus bestimmen einige der folgenden Methoden die Fähigkeit eines Downstream-PEs, Verkehr auf dem P-Tunnel zu empfangen, und nicht speziell den Status des P-Tunnels selbst. Dies könnte als "P-Tunnel-Empfangsstatus" bezeichnet werden, aber der Einfachheit halber verwenden wir für alle diese Methoden die Terminologie des P-Tunnel-"Status".

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.

Abhängig von den Kriterien, die zur Bestimmung des Status eines P-Tunnels verwendet werden, kann es zu einer Interaktion mit einem anderen Ausfallsicherheitsmechanismus kommen, der für den P-Tunnel selbst verwendet wird, und die UMH-Aktualisierung kann sofort erfolgen oder muss möglicherweise verzögert werden. Jeder Einzelfall wird in jedem separaten Unterabschnitt unten behandelt.

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.

Eine Implementierung kann jede Kombination der in diesem Abschnitt beschriebenen Methoden unterstützen und einem Netzwerkbetreiber die Kontrolle geben, welche in der jeweiligen Bereitstellung verwendet werden soll.

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.

Bei der Bestimmung, ob der Status eines P-Tunnels "Up" ist, ist zu berücksichtigen, ob die Wurzel des Tunnels, wie im x-PMSI Tunnel-Attribut angegeben, über Unicast-Routingtabellen erreichbar ist. In diesem Fall kann der Downstream-PE seinen UMH sofort aktualisieren, wenn sich die Erreichbarkeitsbedingung ändert.

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.

Dies ähnelt dem BGP-Next-Hop-Tracking für VPN-Routen, außer dass die betrachtete Adresse nicht die BGP-Next-Hop-Adresse ist, sondern die Root-Adresse im x-PMSI-Tunnel-Attribut. BGP-Next-Hop-Tracking überwacht BGP-Next-Hops.

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.

Um den Status eines P-Tunnels zu bestimmen, kann der Downstream-PE den Status der Verbindung überprüfen, die er verwendet, um den Upstream-PE zu erreichen. Wenn die Verbindung unterbrochen ist, gilt der P-Tunnel-Status als "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.

Für Point-to-Multipoint (P2MP) RSVP-TE-Tunnel kann der Status des Tunnels durch den Zustand des RSVP-TE Label Switched Path (LSP) bestimmt werden. Wenn der LSP ausgefallen ist, gilt der P-Tunnel-Status als "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.

Für Leaf-Initiated P-Tunnel kann der Status durch den Zustand des Signalisierungsprotokolls bestimmt werden, das zum Einrichten des Tunnels verwendet wird.

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.

Der Status eines P-Tunnels kann auch aus den Verkehrsstatistiken für ein bestimmtes (C-S,C-G) abgeleitet werden. Wenn die Verkehrsrate unter einen bestimmten Schwellenwert fällt, kann der P-Tunnel-Status als "Down" betrachtet werden.

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.

Dieses Dokument definiert ein neues BGP-Attribut, BFD Discriminator, mit dem eine BFD-Sitzung einem P-Tunnel zugeordnet werden kann. Der Status der BFD-Sitzung bestimmt den Status des P-Tunnels.

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.

In einigen Fällen kann es nützlich sein, einen BFD-Diskriminator einer bestimmten PE-CE-Verbindung zuzuordnen. Dies ermöglicht dem Downstream-PE, den Status der Verbindung zum CE mithilfe von BFD zu überwachen.

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.

Bei der Überwachung des Status eines P-Tunnels muss darauf geachtet werden, Fehlalarme zu vermeiden und sicherzustellen, dass der Überwachungsmechanismus keinen übermäßigen Overhead verursacht.

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.

Dieser Abschnitt beschreibt eine optionale BGP-Erweiterung, eine neue Standby PE Community, die das Failover beschleunigen kann, indem zum Zeitpunkt der Wiederherstellung kein Austausch von Multicast VPN (MVPN)-Routingnachrichten erforderlich ist.

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).

Ein Downstream-PE, der die Standby PE Community unterstützt, kann eine C-Multicast-Route zu einem Standby-Upstream-PE ankündigen. Dies ermöglicht es dem Standby-Upstream-PE, mit dem notwendigen Zustand vorprogrammiert zu werden, um Verkehr für das (C-S,C-G) weiterzuleiten.

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.

Ein Upstream-PE, der eine C-Multicast-Route mit der Standby PE Community empfängt, MUSS den Status für das (C-S,C-G) installieren, darf jedoch KEINEN Verkehr weiterleiten, bis er als UMH ausgewählt wurde.

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.

Der Downstream-PE bestimmt die Erreichbarkeit des Upstream-PE und des Standby-Upstream-PE unter Verwendung der in Abschnitt 3 beschriebenen Mechanismen.

4.4. Inter-AS​

This section describes the procedures for Inter-AS scenarios.

Dieser Abschnitt beschreibt die Verfahren für Inter-AS-Szenarien.

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.

In Inter-AS-Szenarien kann der Downstream-PE die Standby PE Community verwenden, um C-Multicast-Routen an ASBRs anzukündigen.

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.

ASBRs können die Standby PE Community verwenden, um C-Multicast-Routen an andere ASBRs oder an Upstream-PEs anzukündigen.

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.

Dieser Abschnitt beschreibt einen "Hot Root Standby"-Mechanismus, der verwendet werden kann, um die Failover-Zeit in MVPN zu verbessern. Der Ansatz kombiniert die in den Abschnitten 3 und 4 definierten Mechanismen und weist Ähnlichkeiten mit der in [RFC7431] beschriebenen Lösung auf, um die Failover-Zeiten zu verbessern, wenn PIM-Routing in einem Netzwerk unter Berücksichtigung bestimmter Topologie- und Metrikbeschränkungen verwendet wird.

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.

Bei der Verwendung der in diesem Dokument beschriebenen Fast-Failover-Mechanismen ist es möglich, dass doppelte Pakete an den Empfänger zugestellt werden. In diesem Abschnitt werden die Auswirkungen doppelter Pakete und deren Abschwächung erörtert.

7. IANA Considerations​

7.1. Standby PE Community​

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

Die IANA hat der Standby PE Community einen BGP-Community-Wert zugewiesen.

7.2. BFD Discriminator​

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

Die IANA hat dem BFD Discriminator-Attribut einen BGP-Attributtypcode zugewiesen.

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.

Die IANA hat dem BFD Discriminator Optional TLV im BGP Tunnel Encapsulation Attribute einen Typwert zugewiesen.

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.

Die Sicherheitsüberlegungen für dieses Dokument ähneln denen für [RFC6513] und [RFC6514]. Darüber hinaus führt die Verwendung von BFD neue Sicherheitsüberlegungen in Bezug auf die Authentifizierung und Integrität von BFD-Paketen ein.

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

Die Autoren möchten danken...

Contributors​

...

Mitwirkende...

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]

Letztes Update am