Résumé

  • Le RFC 9784 attribue une identité propre à chaque segment Ethernet virtuel et demande de surveiller chaque EVC séparément : partager un port ne signifie pas partager chaque panne.
  • La perte d’un seul circuit doit rester circonscrite au vES ou au service concerné ; la perte avérée de l’ENNI peut, elle, justifier un retrait groupé de tous les vES rattachés au port.
  • Un retrait BGP est une instruction de contrôle, pas la preuve que la détection était bien dimensionnée, que les membres du groupe étaient à jour ou que le trafic client est revenu.

Une liaison virtuelle cesse de fonctionner. Le port physique reste actif et les autres clients continuent de l’utiliser. Pourtant, une procédure héritée raisonne au niveau du port, invalide les adresses de services sains et transforme une panne étroite en incident collectif.

Le problème central du RFC 9784 tient dans cet écart. Le texte normalise les Virtual Ethernet Segments dans EVPN et PBB-EVPN, mais il fournit surtout une discipline de pouvoir : l’alarme d’un circuit n’obtient pas le droit de déranger tout ce qui partage son support matériel.

L’erreur inverse existe aussi. Quand l’ENNI lui-même disparaît, des centaines ou des milliers de vES perdent réellement le même chemin. Exprimer ce fait par des milliers de messages indépendants peut retarder la convergence. Il faut alors parler une fois au nom d’un ensemble, sans faire de ce raccourci une vérité universelle.

Le contenant physique n’est pas l’unité de service

Dans l’EVPN de base, un Ethernet Segment est un ensemble de liens physiques entre un site client et des Provider Edge. Le RFC 9784 étend cette notion à un EVC, un groupe d’EVC, des pseudowires ou des LSP. Plusieurs segments logiques, éventuellement associés à des clients et à des domaines de diffusion différents, peuvent donc traverser le même ENNI.

Ce partage est économiquement normal. Une interface externe coûteuse agrège des services qui n’ont ni le même contrat, ni le même groupe de redondance, ni le même historique de panne. Le RFC évoque des milliers de vES single-homed et des centaines de vES Single-Active sur un seul accès. La corrélation physique est forte ; l’identité opérationnelle demeure séparée.

Chaque vES doit porter son propre vESI. L’élection du Designated Forwarder s’effectue à la granularité (vESI, Ethernet Tag), ce dernier correspondant au VID dans EVPN ou à l’I-SID dans PBB-EVPN. Cette identité délimite les PE autorisés à réagir pour un service donné.

Une détection fine ne doit pas recevoir une autorité grossière

Chaque EVC devrait être surveillé indépendamment. Si un EVC parmi beaucoup d’autres tombe, le RFC impose de relancer l’élection DF pour le vES auquel il appartient. Pour rendre cette décision explicable, il faut conserver le détecteur, l’objet observé, l’association EVC–vESI, l’instance de service et le groupe de redondance tels qu’ils existaient à cet instant.

L’état « up » du port ne réfute pas une panne logique. Mais l’état « down » d’un EVC ne prouve pas non plus une panne physique. Entre les deux se trouve la cartographie qui donne sa portée à l’observation.

Le texte limite ensuite les effets. La panne ou le rétablissement d’un EVC d’un vES single-homed ou All-Active ne doit toucher aucun autre EVC. En Single-Active, l’impact reste dans l’instance de service concernée. La purge des C-MAC doit se limiter à l’I-SID et aux adresses du réseau multihomé visé.

La preuve de bonne exécution comprend donc un résultat négatif : les voisins sains n’ont pas changé. Plus le port concentre de services, plus ce reçu de non-impact devient essentiel.

Une purge conçue pour le port peut fabriquer une panne

Dans PBB-EVPN, un B-MAC peut être partagé par de nombreux services d’un port. Si l’on applique à la perte d’un seul EVC le traitement MAC Mobility prévu pour un segment physique, les PE distants risquent de purger les C-MAC de tous les EVC du port. Les services sains doivent réapprendre leurs adresses ; le mécanisme de reprise élargit lui-même l’incident.

Le RFC 9784 rétrécit l’ordre au niveau de l’instance. Le route B-MAC/I-SID du RFC 9541 permet de demander la purge des C-MAC associés à un B-MAC uniquement dans l’I-SID annoncé. Un EVC comportant plusieurs VLAN et plusieurs I-SID peut nécessiter plusieurs routes. Si cet ensemble devient grand, attribuer un B-MAC par vES puis le retirer peut être préférable.

La bonne unité ne se déduit ni du mot « logique » ni du mot « physique ». Un EVC peut contenir plusieurs domaines ; un port peut contenir des milliers d’EVC. C’est la relation d’inventaire vérifiée qui autorise la portée.

Une panne réelle de port autorise une compression de l’ensemble

Quand l’ENNI tombe, tous les vES qui lui sont effectivement associés sont concernés. Le route coloring prépare alors une expression compacte de ce fait. Le PE peut joindre à chaque route de vES une couleur représentant le port physique, par défaut son adresse MAC, transportée dans l’EVPN Router’s MAC Extended Community du RFC 9135. Les PE récepteurs constituent la liste des vES associés à cette couleur.

Un route spécial Grouping Ethernet A-D per ES — ou un Grouping B-MAC route en PBB-EVPN — peut représenter le groupe. Son retrait lors de la panne du port permet de lancer rapidement les élections DF et le basculement pour l’ensemble mémorisé. Les retraits individuels suivent afin de nettoyer les états BGP.

La couleur n’est cependant pas un capteur. Elle atteste qu’une association a été annoncée. Le route de groupe atteste qu’un émetteur a décrit un ensemble. Son retrait atteste que cet émetteur retire cet ensemble. Aucun de ces reçus ne démontre la cause physique, la fraîcheur des listes sur tous les récepteurs ou l’issue du trafic.

C’est une spécification initiale minimale : la coordination transporte la relation indispensable, tandis que chaque PE garde la décision locale d’appliquer son état, d’élire et de modifier le forwarding. Le symbole partagé ne reçoit pas l’autorité de prononcer tous les résultats suivants.

Deux retraits, deux fonctions

Le retrait de groupe déclenche une action rapide à partir d’une appartenance préparée. Les retraits par vES suppriment ensuite les routes précises. Après réception du signal groupé, ils ne doivent pas déclencher une seconde fois la même élection.

Un audit limité à la table BGP finale perd cette chronologie. Il ne montre ni si le basculement rapide a démarré, ni s’il a été doublé, ni si un groupe périmé a inclus un vES étranger. La séquence des messages fait partie de la preuve.

La remontée suit encore d’autres étapes. Une annonce rend un chemin éligible ; une élection désigne un DF ; une mise à jour MAC modifie la joignabilité locale. Seule l’observation du plan de données peut montrer que les trames clientes passent et que les services voisins n’ont pas subi la reprise.

Une organisation sérieuse conserve donc séparément l’alarme et son objet, la cartographie contemporaine, le vESI, l’I-SID, la couleur, la composition du groupe chez chaque récepteur, le choix entre action individuelle et groupée, l’ordre des messages BGP, les résultats DF et MAC, puis les essais de trafic. La formule « EVPN a convergé » ne remplace aucun de ces reçus.

L’infrastructure partagée exige une autorité plus étroite

La virtualisation multiplie les promesses indépendantes installées dans un même équipement. Elle rend la visibilité physique nécessaire, mais elle rend la séparation logique tout aussi impérative. Plus un port est dense, plus une conclusion erronée au niveau du port coûte cher.

La primauté du code exécuté donne le test final. Le RFC prouve qu’une procédure est publiée. Une configuration prouve une intention d’adoption. Une trace BGP prouve un échange de messages. L’état d’un équipement prouve une action locale. Le trafic et le dossier client prouvent le résultat de service. Aucun étage ne peut emprunter l’autorité du suivant.

Le mérite du RFC 9784 n’est donc pas seulement d’accélérer la convergence. Il empêche la vitesse d’effacer le périmètre. Un circuit en panne peut rester un incident de circuit. Un port réellement en panne peut produire un signal collectif. Ce signal collectif, lui, ne devient jamais la preuve que le service est rétabli.

Sources

  1. RFC 9784 — Virtual Ethernet Segments pour EVPN et PBB-EVPN
  2. RFC 7432 — Ethernet VPN fondé sur BGP MPLS
  3. RFC 7623 — Provider Backbone Bridging avec EVPN
  4. RFC 8214 — Prise en charge de VPWS dans EVPN
  5. RFC 8584 — Extensibilité de l’élection DF EVPN
  6. RFC 7023 — Connectivity Fault Management Ethernet
  7. RFC 9135 — Routage et bridging intégrés dans EVPN
  8. RFC 9541 — Routes B-MAC et B-MAC/I-SID pour PBB-EVPN
  9. Lu Heng — Primauté du code exécuté
  10. Lu Heng — Spécification initiale minimale et décision future localisée
  11. Lu Heng — Couches de réalité, pouvoir symbolique et clarté