Aller au contenu principal

RFC 9026 - Multicast VPN Fast Upstream Failover

  • Statut: Proposed Standard
  • Publié: April 2021
  • Stream: IETF
  • Errata: Pas d'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.

Ce document définit les extensions et procédures de réseau privé virtuel (VPN) multicast qui permettent un basculement rapide en cas de défaillance en amont en permettant aux routeurs de périphérie de fournisseur (PE) en aval de prendre en compte l'état des tunnels de fournisseur (P-tunnels) lors de la sélection du PE en amont pour un flux multicast VPN. Le basculement rapide est activé en utilisant "Bidirectional Forwarding Detection (BFD) for Multipoint Networks" (RFC 8562) et le nouvel attribut BGP, BFD Discriminator. De plus, ce document introduit une nouvelle communauté BGP, Standby PE, étendant le routage BGP Multicast VPN (MVPN) afin qu'une route C-multicast puisse être annoncée vers un PE en amont de secours (Standby Upstream PE).

Status of This Memo​

This is an Internet Standards Track document.

Ceci est un document de la voie de normalisation de l'Internet (Standards Track).

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.

Ce document est un produit de l'Internet Engineering Task Force (IETF). Il représente le consensus de la communauté IETF. Il a fait l'objet d'un examen public et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). De plus amples informations sur les normes Internet sont disponibles dans la section 2 de la 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.

Des informations sur l'état actuel de ce document, les éventuels errata et la manière de fournir des commentaires à son sujet peuvent être obtenues à l'adresse 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 et les personnes identifiées comme auteurs du document. Tous droits réservés.

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.

Ce document est soumis aux dispositions légales du BCP 78 et de l'IETF Trust relatives aux documents IETF (https://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Veuillez examiner attentivement ces documents, car ils décrivent vos droits et restrictions concernant ce document. Les composants de code extraits de ce document doivent inclure le texte de licence BSD simplifié tel que décrit dans la section 4.e des dispositions légales du Trust et sont fournis sans garantie telle que décrite dans la licence BSD simplifiée.

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

Il est supposé que le lecteur est familier avec le fonctionnement des VPN IP MPLS/BGP multicast tels que décrits dans [RFC6513] et [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.

Dans le contexte du multicast dans les VPN BGP/MPLS [RFC6513], il est souhaitable de fournir des mécanismes permettant une récupération rapide de la connectivité sur différents types de pannes. Ce document traite des pannes d'éléments du réseau fournisseur qui sont en amont des PE connectés aux sites VPN avec des récepteurs.

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.

La section 3 décrit les procédures locales permettant à un PE de sortie (un PE connecté à un site récepteur) de prendre en compte l'état des P-tunnels pour déterminer le saut multicast en amont (UMH) pour un (C-S,C-G) donné. L'une des méthodes optionnelles utilise [RFC8562] et le nouvel attribut BGP, BFD Discriminator. Aucune de ces méthodes ne fournit une solution de "basculement rapide" lorsqu'elle est utilisée seule, mais peut être utilisée conjointement avec le mécanisme décrit dans la section 4 pour une solution de "basculement rapide".

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.

La section 4 décrit une extension BGP optionnelle, une nouvelle communauté Standby PE, qui peut accélérer le basculement en ne nécessitant aucun échange de message de routage Multicast VPN (MVPN) au moment de la récupération.

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.

La section 5 décrit un mécanisme de "hot root standby" qui peut être utilisé pour améliorer le temps de basculement dans MVPN. L'approche combine les mécanismes définis dans les sections 3 et 4 et présente des similitudes avec la solution décrite dans [RFC7431] pour améliorer les temps de basculement lorsque le routage PIM est utilisé dans un réseau compte tenu de certaines contraintes de topologie et de métrique.

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.

Les mots-clés "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", et "OPTIONAL" dans ce document doivent être interprétés comme décrit dans BCP 14 [RFC2119] [RFC8174] lorsque, et seulement lorsque, ils apparaissent en majuscules, comme indiqué ici.

2.2. Terminology​

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

La terminologie utilisée dans ce document est la terminologie définie dans [RFC6513] et [RFC6514].

2.3. Abbreviations​

This document uses the following abbreviations:

Ce document utilise les abréviations suivantes :

  • BFD: Bidirectional Forwarding Detection (Détection de transfert bidirectionnel)
  • MVPN: Multicast Virtual Private Network (Réseau privé virtuel multicast)
  • NLRI: Network Layer Reachability Information (Informations d'accessibilité de la couche réseau)
  • PE: Provider Edge (Périphérie du fournisseur)
  • PMSI: Provider Multicast Service Interface (Interface de service multicast du fournisseur)
  • RPT: Rendezvous Point Tree (Arbre de point de rendez-vous)
  • SPT: Shortest Path Tree (Arbre du chemin le plus court)
  • UMH: Upstream Multicast Hop (Saut multicast en amont)
  • VPN: Virtual Private Network (Réseau privé virtuel)
  • VRF: VPN Routing and Forwarding (Routage et transfert VPN)

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

La section 5.1 de la RFC 6513 décrit les procédures utilisées par un PE MVPN en aval pour déterminer le saut multicast en amont (UMH) pour un (C-S,C-G) donné.

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.

Pour un PE en aval donné et un VRF donné, le P-tunnel correspondant à un PE en amont donné pour un état (C-S,C-G) donné est le tunnel S-PMSI annoncé par ce PE en amont pour ce (C-S,C-G) et importé dans ce VRF ou, s'il n'y a pas de tel S-PMSI, le tunnel I-PMSI annoncé par ce PE et importé dans ce 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.

La procédure décrite ici est facultative, basée sur un PE en aval prenant en compte l'état des P-tunnels enracinés à chaque PE en amont possible, pour inclure ou ne pas inclure chaque PE donné dans la liste des candidats UMH pour un état (C-S,C-G) donné. S'il n'est pas possible de déterminer si l'état actuel d'un P-tunnel est Up, l'état doit être considéré comme "non connu comme étant Down", et il peut être traité comme s'il était Up afin que les tentatives d'utilisation du tunnel soient acceptables. Le résultat est que, si un P-tunnel est Down (voir la section 3.1), le PE qui est la racine du P-tunnel ne sera pas pris en compte pour la sélection UMH. Cela entraînera le basculement du PE en aval pour utiliser le PE en amont suivant dans la liste des candidats. Certains PE en aval pourraient arriver à une conclusion différente concernant l'état du tunnel car la défaillance n'affecte qu'un sous-ensemble de branches. Pour cette raison, les procédures de la section 9.1.1 de la RFC 6513 sont applicables lors de l'utilisation de P-tunnels I-PMSI. Ce document est une base pour ce document, et ses processus s'appliquent tous ici.

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

Trois options sont spécifiées dans la section 5.1 de la RFC 6513 pour qu'un PE en aval sélectionne un PE en amont.

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:

Les deux premières options sélectionnent le PE en amont à partir d'un ensemble de PE candidats basé soit sur une adresse IP, soit sur un algorithme de hachage. Lorsqu'il est utilisé conjointement avec la procédure facultative de prise en compte de l'état du P-tunnel comme dans ce document, un PE en amont candidat est inclus dans l'ensemble si :

  • advertises an x-PMSI bound to a tunnel, where the specified tunnel's state is not known to be Down, or,
  • il annonce un x-PMSI lié à un tunnel, où l'état du tunnel spécifié n'est pas connu pour être Down, ou,
  • 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.
  • il n'annonce aucun x-PMSI applicable au (C-S,C-G) donné mais a associé une communauté étendue BGP VRF Route Import à la route VPN unicast pour S. Cela est nécessaire pour éviter d'invalider incorrectement un PE UMH qui utiliserait une politique où aucun I-PMSI n'est annoncé pour un VRF donné et où seuls les S-PMSI sont utilisés. Le S-PMSI ne peut être annoncé qu'après que le PE en amont a reçu une route C-multicast pour (C-S,C-G) / (C-*,C-G) à transporter sur le S-PMSI annoncé.

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

Si l'ensemble de candidats résultant est vide, la procédure est répétée sans tenir compte de l'état du P-tunnel.

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.

La troisième option utilise la route UMH installée (c'est-à-dire la "meilleure" route vers la racine C) comme route UMH sélectionnée, et son PE d'origine est le PE en amont sélectionné. Avec la procédure facultative de prise en compte de l'état du P-tunnel comme dans ce document, la route UMH sélectionnée est la meilleure parmi celles dont le P-tunnel du PE d'origine n'est pas "down". Si cela n'existe pas, la route UMH installée est sélectionnée quel que soit l'état du P-tunnel.

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.

Différents facteurs peuvent être pris en compte pour déterminer le "statut" d'un P-tunnel et sont décrits dans les sous-sections suivantes. Les procédures facultatives décrites dans cette section traitent également du cas où les PE en aval n'appliquent pas tous les mêmes règles pour définir quel est le statut d'un P-tunnel (veuillez consulter la section 6), et certaines d'entre elles produiront un résultat qui peut être différent pour différents PE en aval. Ainsi, le "statut" d'un P-tunnel dans cette section n'est pas une caractéristique du tunnel en soi mais est le statut du tunnel, tel qu'il est vu par un PE en aval particulier. De plus, certaines des méthodes suivantes déterminent la capacité d'un PE en aval à recevoir du trafic sur le P-tunnel et non spécifiquement sur le statut du P-tunnel lui-même. Cela pourrait être appelé "statut de réception du P-tunnel", mais pour simplifier, nous utiliserons la terminologie de "statut" du P-tunnel pour toutes ces méthodes.

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.

En fonction des critères utilisés pour déterminer le statut d'un P-tunnel, il peut y avoir une interaction avec un autre mécanisme de résilience utilisé pour le P-tunnel lui-même, et la mise à jour de l'UMH peut se produire immédiatement ou peut devoir être retardée. Chaque cas particulier est couvert dans chaque sous-section distincte ci-dessous.

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.

Une implémentation peut prendre en charge n'importe quelle combinaison des méthodes décrites dans cette section et fournir à un opérateur réseau le contrôle pour choisir celle à utiliser dans le déploiement particulier.

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.

Lors de la détermination si le statut d'un P-tunnel est Up, une condition à prendre en compte est de savoir si la racine du tunnel, telle que spécifiée dans l'attribut x-PMSI Tunnel, est accessible via les tables de routage unicast. Dans ce cas, le PE en aval peut immédiatement mettre à jour son UMH lorsque la condition d'accessibilité change.

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.

C'est similaire au suivi du prochain saut BGP pour les routes VPN, sauf que l'adresse considérée n'est pas l'adresse du prochain saut BGP mais l'adresse racine dans l'attribut x-PMSI Tunnel. Le suivi du prochain saut BGP surveille les prochains sauts BGP.

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.

Pour déterminer le statut d'un P-tunnel, le PE en aval peut vérifier le statut du lien qu'il utilise pour atteindre le PE en amont. Si le lien est en panne, le statut du P-tunnel est considéré comme 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.

Pour les tunnels RSVP-TE point à multipoint (P2MP), le statut du tunnel peut être déterminé par l'état du chemin commuté par étiquette RSVP-TE (LSP). Si le LSP est en panne, le statut du P-tunnel est considéré comme 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.

Pour les P-tunnels initiés par la feuille, le statut peut être déterminé par l'état du protocole de signalisation utilisé pour établir le 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.

Le statut d'un P-tunnel peut également être déduit des statistiques de trafic pour un (C-S,C-G) spécifique. Si le débit du trafic tombe en dessous d'un certain seuil, le statut du P-tunnel peut être considéré comme 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.

Ce document définit un nouvel attribut BGP, BFD Discriminator, qui peut être utilisé pour associer une session BFD à un P-tunnel. Le statut de la session BFD détermine le statut du 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.

Dans certains cas, il peut être utile d'associer un discriminateur BFD à un lien PE-CE spécifique. Cela permet au PE en aval de surveiller le statut du lien vers le CE à l'aide de 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.

Lors de la surveillance du statut d'un P-tunnel, il faut veiller à éviter les faux positifs et à s'assurer que le mécanisme de surveillance n'introduit pas de surcharge excessive.

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.

Cette section décrit une extension BGP facultative, une nouvelle communauté Standby PE, qui peut accélérer le basculement en ne nécessitant aucun échange de message de routage Multicast VPN (MVPN) au moment de la récupération.

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

Un PE en aval qui prend en charge la communauté Standby PE peut annoncer une route C-multicast vers un PE en amont de secours. Cela permet au PE en amont de secours d'être préprogrammé avec l'état nécessaire pour transférer le trafic pour le (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.

Un PE en amont qui reçoit une route C-multicast avec la communauté Standby PE DOIT installer l'état pour le (C-S,C-G) mais NE DOIT PAS transférer le trafic tant qu'il n'est pas sélectionné comme 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.

Le PE en aval détermine l'accessibilité du PE en amont et du PE en amont de secours à l'aide des mécanismes décrits dans la section 3.

4.4. Inter-AS​

This section describes the procedures for Inter-AS scenarios.

Cette section décrit les procédures pour les scénarios Inter-AS.

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.

Dans les scénarios Inter-AS, le PE en aval peut utiliser la communauté Standby PE pour annoncer des routes C-multicast aux ASBR.

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.

Les ASBR peuvent utiliser la communauté Standby PE pour annoncer des routes C-multicast à d'autres ASBR ou à des PE en amont.

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.

Cette section décrit un mécanisme de "hot root standby" qui peut être utilisé pour améliorer le temps de basculement dans MVPN. L'approche combine les mécanismes définis dans les sections 3 et 4 et présente des similitudes avec la solution décrite dans [RFC7431] pour améliorer les temps de basculement lorsque le routage PIM est utilisé dans un réseau compte tenu de certaines contraintes de topologie et de métrique.

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.

Lors de l'utilisation des mécanismes de basculement rapide décrits dans ce document, il est possible que des paquets en double soient livrés au récepteur. Cette section discute des implications des paquets en double et de la manière de les atténuer.

7. IANA Considerations​

7.1. Standby PE Community​

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

L'IANA a attribué une valeur de communauté BGP pour la communauté Standby PE.

7.2. BFD Discriminator​

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

L'IANA a attribué un code de type d'attribut BGP pour l'attribut BFD Discriminator.

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.

L'IANA a attribué une valeur de type pour le TLV optionnel BFD Discriminator dans l'attribut d'encapsulation de tunnel BGP.

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.

Les considérations de sécurité pour ce document sont similaires à celles de [RFC6513] et [RFC6514]. De plus, l'utilisation de BFD introduit de nouvelles considérations de sécurité liées à l'authentification et à l'intégrité des paquets BFD.

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

Les auteurs tiennent à remercier...

Contributors​

...

Contributeurs...

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]

Dernière mise à jour le