Résumé

  • L’opération OR de RFC 9252 reste correcte lorsque les deux types de routes annoncent une structure SID identique ; RFC 9819 traite le cas où cette hypothèse ne tient plus.
  • La route Inclusive Multicast fournit LOC:FUNC et la frontière d’insertion, tandis que la route Ethernet A-D per ES fournit Arg.FE2. L’égalité d’AL autorise la taille, pas une équivalence générale des structures.
  • Le SID construit demeure un résultat du plan de contrôle. La sélection locale, la programmation du dataplane, l’exécution End.DT2M et la livraison BUM doivent être observées séparément.

Le piège opérationnel ressemble à une addition. Une valeur arrive par une route de type 3, une autre par une route de type 1, et le logiciel possède une instruction qui combine des bits. Pourtant, la question décisive n’est pas de savoir si les deux opérandes existent. Il faut savoir si le second entre dans la case définie par le propriétaire du premier.

RFC 9819 actualise RFC 9252 après que des travaux d’implémentation et d’interopérabilité ont révélé une ambiguïté. RFC 9252 proposait un OR logique entre l’argument de filtrage ESI de la route Ethernet A-D per ES et le SID End.DT2M de la route Inclusive Multicast Ethernet Tag. Cette opération suppose que les parties utiles occupent les mêmes positions. Or plusieurs domaines de diffusion peuvent utiliser des longueurs de Function différentes.

RFC 9819 ne condamne donc pas l’OR. Il en fixe la condition de validité. Si les structures sont identiques, l’ancien calcul reste compatible. Si elles diffèrent, l’ingress PE doit extraire l’argument et l’insérer à l’offset annoncé par la structure de LOC:FUNC.

La structure appartient au SID de service

Selon RFC 8986, un SID SRv6 comprend Locator, Function et, si le comportement le permet, Argument. End.DT2M décapsule une charge Ethernet, utilise une table L2 et applique Arg.FE2 pour exclure du flooding les interfaces associées à un ESI. La valeur de cet argument est allouée localement par le nœud qui instancie le comportement.

Cette localité interdit de traiter Arg.FE2 comme un identifiant universel. Sa valeur n’a de sens qu’avec le nœud, le SID, le comportement et l’Ethernet Segment correspondants. La publicité de l’argument doit donc indiquer sa taille, sa valeur, End.DT2M et son association avec les SIDs concernés.

La route de type 3 porte LOC:FUNC pour le domaine de diffusion. Son SRv6 SID Structure Sub-Sub-TLV précise LBL, LNL, FL et AL. La somme des trois premières longueurs donne le début de l’argument. La route de type 1 porte l’argument de filtrage. Lorsque le filtrage ESI est utilisé, les deux AL doivent être non nuls et égaux.

L’exemple multi-BD du RFC est la démonstration la plus utile : un argument de 16 bits est associé à deux SIDs dont FL vaut respectivement 32 et 16 bits. L’argument ne peut pas occuper la même position dans les deux adresses finales. Une égalité de longueur n’efface pas cette différence d’offset.

Zéro, absence et incohérence produisent des décisions différentes

Lorsque la route Inclusive Multicast annonce AL=0, l’ingress forme le SID avec LOC:FUNC seulement, met à zéro les bits suivants et ignore la valeur ainsi que la structure de la route A-D. Le zéro indique ici que ce SID n’attend pas l’argument de filtrage.

Lorsque la route de type 3 annonce un AL non nul, l’ingress recherche la route A-D per ES correspondante et vérifie la présence d’End.DT2M. Si elle manque ou annonce AL=0, aucun argument utilisable n’existe. Le SID LOC:FUNC-only est formé et une situation où le filtrage était attendu mérite un journal de diagnostic.

Lorsque les deux AL non nuls diffèrent, la configuration est incohérente. Le trafic BUM provenant de l’Ethernet Segment concerné ne doit pas être transmis, afin d’éviter une boucle potentielle. Lorsque les longueurs concordent, l’argument de type 1 est inséré à LBL + LNL + FL selon la structure de type 3, puis les bits au-delà de la structure déclarée sont remis à zéro.

Ces branches ne doivent pas devenir un seul badge « attribut valide ». Elles correspondent à une absence volontaire de filtrage, une protection attendue mais sans argument utilisable, une erreur bloquante ou une construction admissible.

La bonne paire est aussi une question de temps

RFC 7432 donne aux routes EVPN leur identité : RD, RT, Ethernet Tag, ESI, origine, next hop et retraits. Le moteur de composition doit conserver ces coordonnées. Sinon, un LOC:FUNC actuel peut rencontrer un argument appartenant à un autre segment ou à une génération retirée.

La fraîcheur ne se déduit pas de la présence dans une table. Un dossier solide relie les deux chemins sélectionnés, leur instant d’observation, les withdrawals antérieurs et la politique de split horizon. Si le déploiement utilise le local bias de RFC 8365, l’argument ESI ne doit pas être fusionné.

RFC 9819 couvre aussi les flavors End.DT2M de RFC 9800. Des formes compressées et non compressées peuvent coexister si les contrôles AL réussissent. Cette permission n’autorise pas à oublier le flavor. Le RFC ne modifie pas non plus la Transposition Scheme de RFC 9252 : TPOS-O, TPOS-L et la capacité du champ label restent des preuves distinctes.

La dernière frontière reste physique

Un calcul correct n’atteste pas que la route a été choisie, que l’encapsulation a été écrite dans le matériel ou que l’egress possède le local SID attendu. Le PE de sortie doit encore associer le SID à la bonne table L2 et Arg.FE2 au bon ensemble d’interfaces exclues.

Il faut donc relier huit reçus : identité et fraîcheur des annonces ; behavior et structure ; association inter-routes ; adresse finale et méthode de construction ; politique et sélection locales ; état programmé à l’ingress et à l’egress ; exécution sur paquet ; résultat du service. Un compteur End.DT2M peut montrer un passage dans le comportement sans prouver que tous les destinataires légitimes ont reçu la charge ni qu’aucune copie interdite n’est revenue vers le segment d’origine.

Cette portée ne reprend pas l’article RFC 10018 sur l’arbre P2MP et la livraison feuille par feuille. Elle ne reprend pas RFC 9830 sur l’activation d’un candidat SR Policy, RFC 9863 sur la Color PCEP ni RFC 10039 sur D-PATH. Elle s’arrête au point de composition propre à RFC 9819 : les composants annoncés forment-ils le SID de service visé selon la structure réellement déclarée ?

La spécification initiale minimale de Lu Heng offre ici une règle éditoriale : le socle commun doit rester déterministe et vérifiable localement. Running-Code Primacy rappelle qu’un document ne prouve pas son exécution, tandis que Reality Layers interdit de confondre déclaration symbolique et effet physique. Ce cadre est celui de l’auteur, pas une intention attribuée à l’IETF.

Sources