Aller au contenu principal

RFC 9026 - Bascule amont rapide pour les VPN de multidiffusion (Multicast VPN Fast Upstream Failover)

Résumé (Abstract)​

Le présent document définit des extensions et des procédures pour les réseaux privés virtuels de multidiffusion (Multicast Virtual Private Networks, VPN) qui permettent une bascule rapide en cas de défaillance amont. À cette fin, les Provider Edges (PE) aval peuvent tenir compte de l'état des Provider Tunnels (P-tunnels) lorsqu'ils sélectionnent le PE amont d'un flux de multidiffusion VPN. La bascule rapide s'appuie sur « Bidirectional Forwarding Detection (BFD) for Multipoint Networks » (RFC 8562) et sur un nouvel attribut BGP, BFD Discriminator. Le document introduit également une nouvelle communauté BGP, Standby PE, qui étend le routage BGP Multicast VPN (MVPN) afin qu'une route C-multicast puisse être annoncée à un PE amont de secours.

Statut de ce mémo​

Le présent document appartient à la filière de normalisation Internet.

Il est produit par l'Internet Engineering Task Force (IETF), représente le consensus de la communauté IETF, a fait l'objet d'un examen public et a été approuvé pour publication par l'Internet Engineering Steering Group (IESG). Des informations supplémentaires sur les normes Internet figurent à la section 2 de la RFC 7841.

L'état actuel du document, les errata éventuels et les modalités de retour d'information sont disponibles à l'adresse https://www.rfc-editor.org/info/rfc9026.

Copyright (c) 2021 IETF Trust et les personnes identifiées comme auteurs du document. Tous droits réservés.

Ce document est soumis au BCP 78 et aux dispositions juridiques de l'IETF Trust relatives aux documents de l'IETF (https://trustee.ietf.org/license-info) en vigueur à sa date de publication. Veuillez les lire attentivement, car elles décrivent vos droits et les restrictions applicables au présent document. Les composants de code extraits de ce document doivent inclure le texte de la licence BSD simplifiée décrit à la section 4.e de ces dispositions et sont fournis sans garantie, conformément à cette licence.

Table des matières​

    1. Introduction
    1. Conventions employées dans ce document
    • 2.1. Langage des exigences
    • 2.2. Terminologie
    • 2.3. Abréviations
    1. Sélection de l'UMH fondée sur l'état du tunnel
    • 3.1. Détermination de l'état d'un tunnel
      • 3.1.1. Suivi de la racine du tunnel MVPN
      • 3.1.2. État de la liaison amont PE-P
      • 3.1.3. Tunnels P2MP RSVP-TE
      • 3.1.4. P-tunnels initiés par les feuilles
      • 3.1.5. Informations de compteur (C-S,C-G)
      • 3.1.6. Attribut BFD Discriminator
      • 3.1.7. BFD Discriminator par liaison PE-CE
      • 3.1.8. Considérations opérationnelles pour la surveillance d'un P-tunnel
    1. Route C-multicast de secours
    • 4.1. Comportement du PE aval
    • 4.2. Comportement du PE amont
    • 4.3. Détermination de la joignabilité
    • 4.4. Inter-AS
      • 4.4.1. Procédures Inter-AS pour les PE aval et bascule rapide des ASBR
      • 4.4.2. Procédures Inter-AS pour les ASBR
    1. Racine de secours active (Hot Root Standby)
    1. Paquets dupliqués
    1. Considérations relatives à l'IANA
    1. Considérations de sécurité
    1. Références
  • Remerciements
  • Contributeurs
  • Adresses des auteurs

1. Introduction​

Le lecteur est supposé connaître le fonctionnement de la multidiffusion dans les VPN IP MPLS/BGP décrit dans [RFC6513] et [RFC6514].

Dans le contexte de la multidiffusion au sein des VPN BGP/MPLS [RFC6513], il est souhaitable de disposer de mécanismes permettant de rétablir rapidement la connectivité après différents types de défaillances. Le présent document traite des défaillances d'éléments du réseau du fournisseur qui se trouvent en amont des PE reliés à des sites VPN comportant des récepteurs.

La section 3 décrit des procédures locales qui permettent à un PE de sortie, c'est-à-dire un PE relié à un site récepteur, de prendre en compte l'état des P-tunnels pour déterminer l'Upstream Multicast Hop (UMH) d'un état (C-S,C-G) donné. L'une des méthodes facultatives utilise [RFC8562] et le nouvel attribut BGP BFD Discriminator. Aucune de ces méthodes n'offre à elle seule une solution de « bascule rapide », mais elles peuvent être combinées au mécanisme de la section 4 pour en constituer une.

La section 4 décrit une extension BGP facultative, la nouvelle communauté Standby PE. Elle peut accélérer la bascule en supprimant la nécessité d'échanger des messages de routage Multicast VPN (MVPN) au moment du rétablissement.

La section 5 décrit un mécanisme de « hot root standby » qui améliore le délai de bascule dans un MVPN. Cette approche combine les mécanismes des sections 3 et 4 et présente des similitudes avec la solution de [RFC7431], destinée à améliorer les délais de bascule lorsque le routage PIM est utilisé dans un réseau respectant certaines contraintes de topologie et de métrique.

2. Conventions employées dans ce document​

2.1. Langage des exigences​

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

2.2. Terminologie​

Le présent document emploie la terminologie définie dans [RFC6513] et [RFC6514].

2.3. Abréviations​

  • 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. Sélection de l'UMH fondée sur l'état du tunnel​

La section 5.1 de la RFC 6513 décrit les procédures qu'un PE aval MVPN utilise pour déterminer l'Upstream Multicast Hop (UMH) d'un (C-S,C-G) donné.

Pour un PE aval et une VRF donnés, le P-tunnel correspondant à un PE amont pour un état (C-S,C-G) donné est le tunnel S-PMSI annoncé par ce PE amont pour (C-S,C-G) et importé dans cette VRF. En l'absence de ce S-PMSI, il s'agit du tunnel I-PMSI annoncé par le PE et importé dans la VRF.

La procédure facultative décrite ici permet au PE aval de tenir compte de l'état des P-tunnels enracinés sur chaque PE amont possible afin d'inclure ou non chacun de ces PE dans la liste des UMH candidats à un état (C-S,C-G). S'il est impossible de déterminer si l'état courant d'un P-tunnel est Up, celui-ci est considéré comme « non connu comme Down » et peut être traité comme Up, de sorte qu'il reste acceptable d'essayer d'utiliser le tunnel. Lorsqu'un P-tunnel est Down (voir la section 3.1), le PE qui en constitue la racine n'est pas retenu dans la sélection de l'UMH. Le PE aval bascule alors vers le PE amont suivant dans la liste des candidats.

Certains PE aval peuvent tirer des conclusions différentes au sujet de l'état du tunnel lorsqu'une défaillance ne touche qu'un sous-ensemble de ses branches. Les procédures de la section 9.1.1 de la RFC 6513 s'appliquent donc en cas d'utilisation de P-tunnels I-PMSI. La RFC 6513 constitue le fondement du présent document et toutes ses procédures restent applicables.

La section 5.1 de la RFC 6513 spécifie trois options permettant à un PE aval de sélectionner un PE amont.

Les deux premières choisissent le PE amont dans un ensemble de PE candidats en fonction d'une adresse IP ou d'un algorithme de hachage. Lorsqu'elles sont utilisées avec la procédure facultative du présent document qui tient compte de l'état du P-tunnel, un PE amont candidat est inclus dans l'ensemble s'il satisfait l'une des conditions suivantes:

  • il annonce un x-PMSI lié à un tunnel dont l'état n'est pas connu comme Down;
  • il n'annonce aucun x-PMSI applicable au (C-S,C-G) donné, mais a associé une VRF Route Import BGP Extended Community à la route VPN unicast de S. Cette condition évite d'invalider par erreur un PE UMH appliquant une politique dans laquelle aucun I-PMSI n'est annoncé pour une VRF et seuls des S-PMSI sont employés. Le S-PMSI ne peut être annoncé qu'après que le PE amont a reçu une route C-multicast pour (C-S,C-G) ou (C-*,C-G), destinée à être transportée sur le S-PMSI annoncé.

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

La troisième option utilise la route UMH installée, c'est-à-dire la « meilleure » route vers la racine C, comme Selected UMH Route; le PE qui en est à l'origine devient le PE amont sélectionné. Avec la procédure facultative du présent document, la Selected UMH Route est la meilleure route parmi celles dont le P-tunnel du PE d'origine n'est pas Down. S'il n'en existe aucune, la route UMH installée est sélectionnée indépendamment de l'état du P-tunnel.

3.1. Détermination de l'état d'un tunnel​

Différents facteurs peuvent être pris en compte pour déterminer l'« état » d'un P-tunnel; ils sont décrits dans les sous-sections suivantes. Les procédures facultatives de cette section couvrent aussi le cas où tous les PE aval n'appliquent pas les mêmes règles de détermination de l'état (voir la section 6), ainsi que les méthodes susceptibles de donner des résultats différents selon le PE aval.

Dans cette section, l'« état » d'un P-tunnel n'est donc pas une propriété intrinsèque du tunnel, mais l'état du tunnel vu par un PE aval donné. En outre, certaines méthodes déterminent la capacité du PE aval à recevoir du trafic sur le P-tunnel plutôt que l'état propre du tunnel. On pourrait parler d'« état de réception du P-tunnel », mais, par simplicité, le terme « état du P-tunnel » couvre ici toutes ces méthodes.

Selon le critère utilisé, un autre mécanisme de résilience propre au P-tunnel peut interagir avec cette détermination. La mise à jour de l'UMH peut alors être immédiate ou devoir être retardée. Chaque cas particulier est traité dans la sous-section correspondante.

Une implémentation peut prendre en charge toute combinaison des méthodes décrites ci-dessous et permettre à l'opérateur de choisir celles à employer pour un déploiement donné.

3.1.1. Suivi de la racine du tunnel MVPN​

Pour déterminer si un P-tunnel est Up, il convient notamment de vérifier si la racine du tunnel indiquée par l'attribut x-PMSI Tunnel est joignable par les tables de routage unicast. Le PE aval peut alors mettre immédiatement à jour son UMH lorsque cette condition de joignabilité change.

Cette méthode est analogue au suivi du prochain saut BGP pour les routes VPN, sauf que l'adresse examinée n'est pas celle du prochain saut BGP mais l'adresse racine portée par l'attribut x-PMSI Tunnel. Le suivi BGP classique, lui, surveille les prochains sauts BGP.

3.1.2. État de la liaison amont PE-P​

Pour déterminer l'état d'un P-tunnel, le PE aval peut vérifier l'état de la liaison qu'il utilise pour atteindre le PE amont. Si cette liaison est défaillante, le P-tunnel est considéré comme Down.

3.1.3. Tunnels P2MP RSVP-TE​

Pour un tunnel RSVP-TE point-à-multipoint (P2MP), l'état peut être déterminé à partir de celui du Label Switched Path (LSP) RSVP-TE. Si le LSP est Down, le P-tunnel est considéré comme Down.

3.1.4. P-tunnels initiés par les feuilles​

Pour un P-tunnel initié par les feuilles, l'état peut être déterminé à partir du protocole de signalisation utilisé pour établir le tunnel.

3.1.5. Informations de compteur (C-S,C-G)​

L'état d'un P-tunnel peut également être déduit des statistiques de trafic propres à un (C-S,C-G). Si le débit descend sous un seuil déterminé, le P-tunnel peut être considéré comme Down.

3.1.6. Attribut BFD Discriminator​

Le présent document définit un nouvel attribut BGP, BFD Discriminator, qui permet d'associer une session BFD à un P-tunnel. L'état de cette session BFD détermine celui du P-tunnel.

3.1.7. BFD Discriminator par liaison PE-CE​

Dans certains cas, il peut être utile d'associer un discriminant BFD à une liaison PE-CE particulière. Le PE aval peut ainsi surveiller par BFD l'état de la liaison vers le CE.

3.1.8. Considérations opérationnelles pour la surveillance de l'état d'un P-tunnel​

La surveillance de l'état d'un P-tunnel doit éviter les faux positifs et veiller à ce que son mécanisme n'introduise pas une surcharge excessive.

4. Route C-multicast de secours​

Cette section décrit une extension BGP facultative, la nouvelle communauté Standby PE, qui accélère la bascule en évitant tout échange de messages de routage Multicast VPN (MVPN) au moment du rétablissement.

4.1. Comportement du PE aval​

Un PE aval prenant en charge la communauté Standby PE peut annoncer une route C-multicast à un PE amont de secours. Celui-ci peut ainsi préinstaller l'état nécessaire pour transférer le trafic du (C-S,C-G).

4.2. Comportement du PE amont​

Un PE amont qui reçoit une route C-multicast portant la communauté Standby PE MUST installer l'état du (C-S,C-G), mais MUST NOT transférer le trafic tant qu'il n'est pas sélectionné comme UMH.

4.3. Détermination de la joignabilité​

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

4.4. Inter-AS​

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

4.4.1. Procédures Inter-AS pour les PE aval et bascule rapide des ASBR​

Dans un scénario Inter-AS, le PE aval peut utiliser la communauté Standby PE pour annoncer des routes C-multicast aux Autonomous System Border Routers (ASBR).

4.4.2. Procédures Inter-AS pour les ASBR​

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

5. Racine de secours active (Hot Root Standby)​

Cette section décrit un mécanisme de « hot root standby » qui améliore le délai de bascule dans un MVPN. Il combine les mécanismes des sections 3 et 4 et présente des similitudes avec la solution de [RFC7431], destinée à réduire les délais de bascule lorsque le routage PIM est utilisé dans un réseau qui respecte certaines contraintes de topologie et de métrique.

6. Paquets dupliqués​

Les mécanismes de bascule rapide décrits dans ce document peuvent entraîner la remise de paquets dupliqués au récepteur. Cette section signale les conséquences possibles de ces doublons et la nécessité de les atténuer.

7. Considérations relatives à l'IANA​

7.1. Communauté Standby PE​

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

7.2. BFD Discriminator​

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

7.3. Type de TLV facultatif BFD Discriminator​

L'IANA a attribué une valeur Type au TLV facultatif BFD Discriminator de l'attribut BGP Tunnel Encapsulation.

8. Considérations de sécurité​

Les considérations de sécurité du présent document sont comparables à celles de [RFC6513] et [RFC6514]. En outre, l'utilisation de BFD introduit des considérations nouvelles concernant l'authentification et l'intégrité des paquets BFD.

9. Références​

9.1. Références normatives​

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

[RFC6513] Rosen, E., Ed. et R. Aggarwal, Ed., « Multicast in MPLS/BGP IP VPNs », RFC 6513, DOI 10.17487/RFC6513, février 2012, https://www.rfc-editor.org/info/rfc6513.

[RFC6514] Aggarwal, R., Ed., Rosen, E., Ed., Morin, T., Ed. et Y. Rekhter, « BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs », RFC 6514, DOI 10.17487/RFC6514, février 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, mai 2017, https://www.rfc-editor.org/info/rfc8174.

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

9.2. Références informatives​

[RFC7431] Karan, A., Wijnands, IJ., Ed. et E. Rosen, « Multicast-Only Fast Reroute », RFC 7431, DOI 10.17487/RFC7431, août 2015, https://www.rfc-editor.org/info/rfc7431.

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

Remerciements​

Les auteurs remercient les personnes ayant contribué à l'élaboration et à la révision de ce document.

Contributeurs​

Les contributions techniques sont reconnues dans le document RFC publié.

Adresses des auteurs​

Thomas Morin (éditeur), Orange
E-mail: [email protected]

Robert Kebler (éditeur), Juniper Networks
E-mail: [email protected]

Greg Mirsky (éditeur), ZTE Corp.
E-mail: [email protected]