Résumé

  • Le texte du 28 octobre propose deux types de correspondance FlowSpec sous PCEP : l'un pour les champs d'un SID SRv6 classique, l'autre pour un conteneur de SID comprimés. Les deux pairs doivent annoncer la nouvelle capacité S avant de les utiliser.
  • Le client PCEP doit émettre une erreur de type 30 si cette capacité manque ou si la règle est mal formée. Le projet écrit TBD_EV à la place de la valeur d'erreur et n'en demande aucune dans sa section IANA ; le registre actuel distingue déjà « non pris en charge » et « mal formé ».

La commande est minutieuse, l'accusé de refus ne l'est pas

Le nouveau projet individuel donne au Path Computation Element, le PCE, une nouvelle façon de dicter au routeur ce qu'il doit regarder dans une adresse de destination IPv6. Le premier TLV décompose un SID SRv6 standard en locator, fonction et argument. Le second traite le bloc de locator, le nœud et la fonction d'un conteneur de SID comprimés. Le PCE choisit la condition ; le Path Computation Client, ou PCC, l'applique au trafic. On passe du contrôle d'une adresse entière à la lecture de sa structure interne.

Le texte prévoit une porte d'entrée claire. Le PCE et le PCC annoncent chacun un bit S pendant l'établissement de la session. Sans accord des deux côtés, ces nouveaux TLV n'ont pas leur place dans les messages. Le PCC vérifie aussi que les longueurs déclarées pour les composants ne dépassent pas 128 bits au total. Cette vérification est locale, mécanique et vérifiable : le routeur peut dire que le découpage demandé ne tient pas dans l'adresse.

Pour formuler ce non, la section 5.2 ordonne d'envoyer un PCErr, type 30, valeur TBD_EV, si le bit S n'a pas été négocié ou si le TLV est mal formé. Or la section 7 ne sollicite auprès de l'IANA qu'un bit de capacité et deux numéros de type TLV. Elle ne sollicite pas de valeur d'erreur. Dans le registre PCEP de l'IANA, le type 30 possède déjà les valeurs 1 à 5 ; 6 à 255 restent libres. TBD_EV n'est pas un numéro que deux routeurs peuvent échanger.

Le choix éditorial du projet est lui aussi en suspens. RFC 9168, sur lequel repose l'extension, attribue la valeur 1 à « Unsupported FlowSpec » et la valeur 2 à « Malformed FlowSpec ». Le nouveau texte veut une seule réponse pour les deux situations. Réutiliser 1 et 2 préserverait leur différence ; créer une nouvelle valeur regrouperait les cas. Les deux voies sont possibles dans un prochain texte. Aucune n'est écrite dans celui-ci.

Cette différence commande une action très pratique lors d'un déploiement automatisé. Si un routeur répond « fonction non prise en charge », le contrôleur peut arrêter l'envoi de ce type de règle à cet équipement. S'il répond « règle mal formée », c'est le calcul ou l'encodage de la règle qu'il faut corriger avant de la renvoyer. Un code ambigu peut transformer une erreur de fabrication en faux défaut du routeur, ou déclencher des tentatives répétées contre un équipement qui n'a jamais annoncé la capacité.

Le temps de diagnostic est payé par l'équipe qui exploite la session PCEP, pas par le paragraphe qui a laissé le champ vide.

L'obligation protocolaire et le registre chargé de la rendre commune se manquent au même endroit. Un constructeur peut coder la vérification des 128 bits aujourd'hui. Il ne peut pas déduire de TBD_EV quelle valeur numérique un autre constructeur attendra demain. Le problème se loge précisément dans le message censé expliquer pourquoi une commande n'a pas été exécutée.

La fiche IETF classe ce texte comme projet individuel. Le prochain dépôt peut résoudre l'affaire en nommant les valeurs existantes ou en demandant un nouveau numéro. À la lecture de la version 00, la question est simple : quelle valeur le PCC doit-il réellement mettre dans son PCErr ?

Sources