Résumé

  • RFC 7570 définit des sous-objets génériques ERO et RRO Hop Attributes pour associer des attributs à un saut précis.
  • Le conteneur ERO est de type 35, de longueur variable, et transporte un ou plusieurs TLV Hop Attributes. Sa portée vise le sous-objet ERO identifiant immédiatement précédent, ou les sous-objets de label associés à ce saut.
  • Le placement fixe la portée. Le bit R importe les règles de traitement requis ou optionnel de RFC 5420 ; il ne définit pas le sens de l’attribut.

Le mécanisme est d’abord une règle d’adjacence. L’entrée place le sous-objet ERO Hop Attributes de type 35 après l’objet ERO qui nomme l’étape voulue, ou après les labels associés à ce saut. Le nœud concerné examine les TLV. Les autres sauts ne reçoivent pas pour autant la même instruction. Le mécanisme générique est un conteneur, non une autorisation universelle.

Chaque document qui définit un attribut doit préciser quels types de sous-objets ERO précédents sont valides, si l’ordre compte, comment l’interpréter et quelles modifications sont permises. Ces documents décident aussi si l’attribut est optionnel, requis, rapportable ou modifiable. Le bit R ne change que la politique de traitement : activé, le nœud examine les TLV selon les règles requises de la section 5.2 de RFC 5420 ; désactivé, il applique les règles optionnelles de la section 4.2. Il ne change pas le sens substantiel du TLV.

Un contenu non pris en charge ou mal formé peut interrompre l’établissement. Un nœud qui rencontre un sous-objet ERO Hop Attributes qu’il ne comprend pas renvoie une Routing Error / Bad EXPLICIT_ROUTE PathErr, avec l’ERO tronqué au sous-objet fautif. RFC 3209 précise séparément qu’un sous-objet ERO non reconnu, rencontré pendant le traitement normal, produit une erreur Bad Explicit Route Object, tandis qu’un sous-objet encore non rencontré est transmis.

Pour les indicateurs, seuls ceux déclarés valides dans ce contexte s’appliquent : les indicateurs invalides sont ignorés silencieusement, alors que les indicateurs inconnus devraient provoquer un Unknown Attributes Bit PathErr. La politique locale ou le contrôle d’admission peut encore refuser la demande ; le nœud peut aussi modifier l’attribut si la procédure du TLV le permet. Le pouvoir de l’entrée est donc un pouvoir de demande, limité par le RFC définissant l’attribut et par l’autorisation du nœud.

Le signalement comporte deux voies. RFC 5420 traite les attributs de tout le LSP portés par LSP_ATTRIBUTES ou LSP_REQUIRED_ATTRIBUTES, normalement rapportés dans les RRO Attributes. Un attribut signalé seulement dans ERO Hop Attributes est normalement rapporté dans RRO Hop Attributes, conteneur RRO optionnel de type 35. Un nœud peut indiquer qu’il a considéré l’attribut du saut ou en signaler un autre, mais l’exigence de conformité doit venir du document définissant l’attribut. Sans cette définition, la réussite de l’établissement ne prouve pas qu’un comportement optionnel a été exécuté.

Les RRO Hop Attributes sont des éléments de preuve, pas une preuve immuable. Les nœuds de transit les transmettent normalement sans modification, mais une frontière de domaine peut les élaguer ou les modifier pour des raisons de confidentialité ou de taille. Des nœuds d’entrée plus anciens peuvent aussi supprimer une information RRO inconnue. RFC 3209 décrit le RRO comme une information de route collectée utile au diagnostic et à la détection des boucles, pas comme un canal d’autorisation. RFC 7571 donne un exemple borné : une demande de loopback OAM peut viser un nœud précis et renvoyer l’état du loopback.

Cet exemple ne définit pas le sens générique de RFC 7570.

Le bénéficiaire est le service qui a besoin d’un comportement à une étape de transit donnée. Les coûts comprennent la compatibilité, l’espace ERO/RRO, le risque d’échec pour un contenu requis non pris en charge ou mal formé, les dépendances d’ordre et la divulgation possible de l’état des sauts. Les sources ne permettent d’affirmer ni fournisseurs, ni déploiements, ni prévalence, ni taux d’échec, ni mesures de croissance des messages, ni résultats clients.

Fixtures de vérification au niveau des paquets

  1. Construire un ERO nommant le saut A, puis un ERO Hop Attributes de type 35 contenant un TLV valide avec R désactivé. Vérifier que la portée est A, et non B, et que la réussite ne prouve pas l’exécution optionnelle.
  2. Recommencer avec R activé sur un sous-objet non pris en charge ou mal formé. Vérifier le PathErr Bad EXPLICIT_ROUTE et la troncature au sous-objet fautif ; ne pas en déduire un comportement de fournisseur.
  3. Placer le sous-objet avant l’objet ERO identifiant, ou l’associer à une mauvaise suite de labels. Vérifier les règles du document définissant l’attribut, sans supposer une validité générique.
  4. Envoyer séparément un indicateur invalide et un indicateur inconnu. Vérifier l’ignorance silencieuse du premier et le comportement Unknown Attributes Bit spécifié pour le second.
  5. Comparer les RRO Attributes de LSP_ATTRIBUTES/RFC 5420 aux RRO Hop Attributes d’un attribut ERO seulement. Tester ensuite une frontière qui élague le RRO : l’absence de preuve ne prouve pas la non-exécution.

Parcours de décision opérateur

Identifier d’abord l’objet ERO immédiatement précédent et le document de l’attribut. Confirmer ensuite placement, ordre, indicateurs valides et règles de modification. Décider si un traitement optionnel suffit ; activer R seulement lorsque le refus vaut mieux que la non-prise en charge silencieuse. Vérifier politique et admission du nœud, puis budgéter taille et divulgation. Enfin, définir le rapport RRO requis et le traitement de son absence, de son élagage ou de sa modification. Si le bénéficiaire exige une preuve sur un saut précis, ne pas remplacer cette preuve par le rapport de tout le LSP ou par une simple réussite du Path.

Sources