Résumé

  • RFC 10039 ajoute D-PATH, un attribut BGP optionnel et transitif de code 36, afin d’enregistrer la succession déclarée des domaines de passerelles dans certaines interconnexions EVPN/IPVPN.
  • Cette succession aide à détecter les boucles de domaine et, après Local Preference, à préférer le D-PATH le plus court ; elle ne constitue toutefois ni une attestation cryptographique ni une preuve de livraison.
  • L’autorité opérationnelle doit donc être répartie entre quatre contrôles : configuration des DOMAIN-ID, conservation de l’attribut, réalisation RIB/FIB et test de service côté locataire.

Une trace utile apparaît enfin dans la route

Une frontière inter-domaine masque souvent le détail qui intéresse l’exploitant au moment d’un incident : par quels domaines de passerelles la route affirme-t-elle être passée ? RFC 10039 répond à cette lacune par D-PATH. Chaque segment associe un type de famille de service à une séquence de DOMAIN-ID. Une passerelle qui exporte une route vers une autre domaine ajoute son identité déclarée ; à la réception, la présence de son propre DOMAIN-ID signale une boucle.

Le mécanisme est volontairement étroit. Il est désactivé par défaut et vise les scénarios d’interconnexion EVPN/IPVPN explicitement configurés. Un DOMAIN-ID est une valeur opaque administrée localement. Les passerelles d’un même domaine doivent partager la même valeur, tandis que des domaines distincts doivent employer des valeurs distinctes. Le verbe important est « doivent » : D-PATH transporte le résultat de cette discipline, il ne la vérifie pas.

L’endroit précis où l’autorité s’arrête

Une route portant A → B → C fournit une preuve de protocole : les locuteurs BGP concernés ont annoncé cette séquence, et un récepteur conforme peut l’utiliser pour rejeter un retour vers son propre domaine. Elle ne prouve pas que toutes les passerelles de B utilisent réellement le même identifiant, qu’une passerelle oubliée n’usurpe pas celui de C, ou que la frontière a conservé chaque attribut nécessaire au service.

L’attribut est optionnel et transitif, ce qui facilite sa propagation au-delà d’un voisin qui ne l’interprète pas. Cette propriété n’est pas une signature. Une mauvaise configuration, une politique de réécriture ou une implémentation défectueuse peut toujours produire une histoire plausible mais fausse. RFC 10039 avertit d’ailleurs qu’une attribution incorrecte des DOMAIN-ID peut annuler la protection contre les boucles.

La distinction entre les modèles d’interconnexion renforce ce point. Dans le modèle « No Propagate », la route transmise à l’autre domaine ne transporte pas D-PATH. Dans le modèle uniforme, les attributs sont davantage conservés et D-PATH peut exercer son rôle. Lire l’absence de D-PATH comme la preuve d’une anomalie serait donc aussi erroné que lire sa présence comme la preuve d’un service sain : il faut d’abord connaître le contrat de la frontière.

Le meilleur chemin ne descend pas jusqu’au locataire

RFC 10039 place la longueur du D-PATH dans la sélection après Local Preference : à préférence locale égale, le chemin comportant le moins de DOMAIN-ID est préféré. Un D-PATH absent compte comme une longueur nulle. C’est une règle déterministe pour choisir entre routes candidates, pas une mesure de latence, de capacité ou de fidélité de transfert.

Entre cette décision et le paquet du client demeurent plusieurs états indépendants. La route peut être reçue mais écartée du meilleur chemin. Elle peut être sélectionnée dans la RIB sans être programmée dans la FIB. La FIB peut être correcte alors qu’un label, un VNI, une cible de route, une résolution de next-hop ou une politique de données ne l’est pas. Enfin, le plan de données peut acheminer un sens du trafic tout en rompant le retour, l’isolation ou les exigences du locataire.

Cette séparation explique pourquoi « D-PATH est propre » ne clôt pas un incident. Elle rétrécit l’enquête : la boucle déclarée n’est probablement pas le premier suspect. Elle ne remplace pas les preuves situées après le protocole.

Un incident lu en quatre colonnes

Imaginons une interconnexion où le domaine C reçoit une route dont le D-PATH indique A puis B. C n’y trouve pas son propre identifiant, accepte la route et l’annonce à ses équipements. Pourtant, le locataire ne joint pas le préfixe.

La première colonne demande si A, B et C possèdent des identités administratives cohérentes sur toutes leurs passerelles. La deuxième compare les mises à jour BGP capturées de part et d’autre de chaque frontière : la séquence, la famille de service et les attributs associés ont-ils été conservés ? La troisième confronte la route sélectionnée à l’entrée FIB effective et à la résolution du next-hop. La quatrième exécute un test de livraison depuis le contexte du locataire, avec le bon VRF, le bon sens retour et les mêmes politiques que le trafic réel.

Le défaut peut alors apparaître là où il se trouve. Une divergence de DOMAIN-ID relève du plan de contrôle administratif. Une disparition d’attribut relève de la frontière de propagation. Une absence d’adjacence relève de la réalisation. Un blackhole limité à un VRF relève de la prestation au locataire. Aucun de ces verdicts ne peut être déduit du seul texte de D-PATH.