Résumé

  • Un label attribué en amont est consulté dans l’espace propre à la racine du tunnel. Le protocole qui distribue le label doit identifier l’assignateur par la même adresse IP que le protocole qui établit le tunnel.
  • Sur un tunnel MPLS, les labels extérieurs fournissent ce contexte. Le PHP doit être désactivé lorsque son retrait ferait disparaître le sélecteur de table avant le lookup.

Deux identités exactes ne forment pas une identité commune

Un routeur possède plusieurs adresses. La signalisation de tunnel nomme son head-end par X ; la distribution du label utilise Y. L’inventaire sait que X et Y appartiennent au même équipement et les fusionne.

RFC 5331 ne demande pas une identité de châssis. Le routeur aval maintient un espace distinct pour chaque racine unique, identifiée par l’adresse head-end. Si la racine de deux tunnels est annoncée avec des adresses différentes, les espaces restent différents.

Le protocole de distribution doit employer la même adresse pour l’assignateur que celle utilisée par l’établissement du tunnel. Cette règle vaut même si les deux protocoles sont différents. L’équivalence administrative des adresses n’est pas un remplacement implicite.

La preuve utile conserve X, Y, leurs sources, leurs instants et le verdict de correspondance. Une table CMDB peut proposer un alias, mais ne doit pas effacer la distinction avant que la règle du protocole l’autorise.

Le PHP peut retirer l’identité avant la décision

Le label amont au sommet de la pile n’est pas consulté dans l’espace global de la plate-forme. Il appartient à un espace contextuel sélectionné par le tunnel, la racine ou un label de contexte.

Sur un tunnel MPLS, les labels placés au-dessus du label amont permettent au récepteur de reconnaître le tunnel. Si l’avant-dernier saut retire ce label extérieur, le numéro intérieur demeure intact mais son sélecteur disparaît. RFC 5331 impose alors de désactiver le PHP.

Il ne s'agit pas d’une condamnation générale de l’optimisation. La condition est sémantique : le label retiré n’est éliminable que s’il ne reste plus nécessaire pour choisir l’espace de lookup.

Une capture prise après le pop ne peut retrouver cette racine à partir du seul nombre intérieur. Une recherche par défaut dans la table de plate-forme peut rencontrer le même nombre lié à un autre FEC. Ce résultat serait valide dans une autre réalité et faux pour ce paquet.

Un nombre peut être attribué deux fois sans collision

Les valeurs amont et aval ne nécessitent pas de coordination. Une même valeur peut être liée à des FEC différents selon le sens d’attribution et l’espace. Des racines différentes peuvent également réutiliser le nombre.

La collision ne se juge donc pas globalement. Elle se juge dans la clé de lookup effective. Enregistrer seulement le numéro donne l’illusion d’un conflit ou d’une unicité qui n’existe pas.

Cette enquête se distingue du contrat RFC 9573 sur les labels communs. Ici, la question n’est pas de prouver un sens commun sur plusieurs PE, mais de préserver le contexte précis qui permet au prochain LSR de choisir une table avant tout sens.

GRE transforme l’adresse source en racine

Un tunnel peut être signalé, configuré ou simplement créé par encapsulation GRE. Dans ce dernier cas, RFC 5331 considère l’adresse IP source comme racine.

L’adresse observée entre ainsi dans l’autorité de lookup. Une réécriture, une asymétrie ou un choix d’adresse différent peut déplacer le même label vers un autre espace. Cela ne prouve pas que la source était autorisée ; cela explique la table que la procédure sélectionne.

Il faut conserver séparément origine du paquet, identité de racine, authenticité du tunnel et autorisation de distribution. Une adresse correcte pour le lookup n’est pas une preuve complète de confiance.

L’EtherType ne choisit pas le voisin

Sur un LAN, un EtherType distinct peut indiquer que le label est attribué en amont. Plusieurs voisins amont partagent pourtant le média. L’EtherType répond au type d’attribution, pas à la question « par qui ? ».

RFC 5331 ajoute un tunnel MPLS d’un saut. Le label supérieur sélectionne le contexte du voisin ; le label suivant porte la liaison au FEC. Le récepteur consulte le label de contexte avec l’interface LAN d’entrée.

Le pipeline d’observation doit conserver EtherType, interface, label supérieur, second label et table retenue. En perdre un peut laisser un paquet syntaxiquement lisible et décisionnellement incomplet.

La portée décide si deux contextes entrent en collision

Un label de contexte doit être unique sur le même LAN. Une procédure peut le provisionner ou le dériver de la partie hôte IPv4 sous contraintes. Deux interfaces dont les vingt bits faibles coïncident sur le même LAN peuvent conduire les autres LSR à mal acheminer les paquets.

La même valeur sur deux LAN différents n’est pas ambiguë, car l’interface d’entrée participe à la recherche. Un registre global qui omet l’interface invente un conflit ; un allocateur local qui omet les autres participants manque un conflit réel.

La méthode automatique suppose IPv4 et ne s’applique pas aux interfaces exclusivement IPv6. La présence d’un algorithme ne prouve donc pas que la valeur a été produite sous ses préconditions.

La capacité optionnelle demande une preuve de pair

L’attribution amont est facultative et ne doit pas être utilisée sans savoir que le LSR aval la prend en charge. RFC 5331 laisse le mécanisme de cette connaissance à l’application et au protocole de distribution.

Un binaire compatible, un registre ou un bouton de configuration n’atteste pas l’accord du pair. Conservez la source, la portée, l’application et l’expiration de la connaissance.

Sources et limite des preuves

Ces sources établissent règles, historique et registres. Elles ne prouvent aucun équipement, tunnel, état PHP, racine, table, collision, mauvais acheminement, arbre multicast, transfert ou résultat actuel.