Résumé

  • La révision 03 du projet du groupe PCE propose de négocier S-BFD dans OPEN, puis de porter son état par chemin dans LSPA. Le PCE initie ou met à jour; le PCC rapporte.
  • Le bit B activé exige un discriminateur distant. Pour l'arrêt, le texte hésite entre plusieurs traitements des paramètres et présente une suppression par absence du champ comme simple piste éditoriale.

La première preuve est une conversation, pas un détecteur

Un élément de calcul de chemin, le PCE, peut décider du trajet qu'il veut voir établi. Le client de ce calcul, le PCC, possède l'équipement qui porte le chemin. Le projet « PCEP Extensions to support BFD parameters » rapproche ces deux rôles pour configurer Seamless Bidirectional Forwarding Detection, S-BFD, sur un chemin à commutation d'étiquettes. La commodité est évidente pour un réseau piloté depuis un contrôleur. Le piège l'est moins : une instruction émise depuis le centre ressemble trop facilement à une fonction qui tourne déjà sur le routeur.

Avant de toucher un chemin, les deux interlocuteurs doivent établir s'ils parlent le même dialecte. Le projet place un LSP-S-BFD-Capability TLV dans l'objet OPEN. Avec B=1, le correspondant annonce sa capacité à échanger les nouveaux champs. Sans ce champ, ou avec B=0, l'autre interlocuteur ne doit pas lui envoyer de champs S-BFD dans LSPA. La liste des types d'établissement de chemin admis pour S-BFD doit aussi figurer parmi ceux que la session PCEP prend en charge. Une liste incohérente provoque l'erreur PCErr de type 21, valeur 2, puis la fermeture de la session. S'il n'existe aucun type commun, le PCEP de cette proposition ne peut configurer S-BFD sur les LSP créés entre ces pairs.

Cette porte d'entrée ne retire rien aux choix locaux du PCC. Le projet laisse la configuration locale de S-BFD à sa politique. Il sépare ainsi la possibilité de régler un détecteur par PCEP de la possibilité de le faire fonctionner sur place. À l'autre extrême, une capacité annoncée dans OPEN ne règle encore aucun LSP. Elle atteste qu'un message pourra être compris, pas qu'une session de détection a été mise en marche. La distinction paraît scolaire jusqu'au jour où un tableau de bord imprime « compatible S-BFD » à côté d'un chemin dont personne n'a vérifié l'état effectif.

Le champ par LSP passe ensuite dans l'objet LSPA. Le projet prévoit que le PCC l'envoie dans PCRpt, tandis que le PCE l'envoie dans PCInit ou PCUpd. Voilà trois gestes différents : initialiser ou modifier depuis le contrôleur, puis rapporter depuis le routeur. Le B de ce champ ne joue pas le rôle du B annoncé dans OPEN. Dans OPEN, il ouvre le droit de parler. Dans LSPA, il demande l'application de S-BFD au chemin concerné. Confondre ces deux bits parce qu'ils portent la même lettre ferait d'une négociation générale une preuve de configuration particulière.

Allumer exige plus qu'un voyant vert

Quand le B du champ par LSP vaut 1, le projet exige le sous-champ du discriminateur distant. Il prévoit une erreur spécifique si ce discriminateur manque. Un autre sous-champ, facultatif, porte l'intervalle minimal d'émission et un multiplicateur compris entre 1 et 255. Le PCE peut donc envoyer une demande détaillée; le PCC dispose de critères concrets pour l'accepter, la rejeter ou signaler un problème. Un journal qui ne retient que « activation demandée » efface les valeurs dont dépend justement la validité de la demande.

Le projet ajoute des erreurs pour certaines frontières. Recevoir un champ S-BFD d'un pair qui n'avait pas annoncé la capacité oblige à ignorer son contenu et à renvoyer une erreur de type 19. Un multiplicateur hors de la plage entraîne une erreur de type 23. Les valeurs nouvelles proposées pour ces erreurs et pour les TLV sont encore TBD dans la section IANA. Les types d'erreur existants permettent de situer la faute; le projet n'autorise pas à présenter ses futures valeurs comme des numéros déjà attribués.

La commande d'arrêt demande davantage d'attention. Selon la section 4.3.2.1, B=0 supprime S-BFD lors d'une mise à jour par le PCE ou empêche son application dans une initiation. La section 4.2 précise qu'un PCC ignore une mise à jour B=0 si aucun S-BFD n'était appliqué à ce LSP. Le PCE peut ignorer le même état pour un chemin initié par le PCC. Dans ces cas, demander de retirer un détecteur absent ne démontre pas qu'un détecteur a été retiré. L'accusé de réception doit montrer ce qui existait avant et ce qui reste après.

Les paramètres joints au message de désactivation révèlent un désaccord plus net. La section 4.2 dit qu'un interlocuteur peut ignorer le sous-champ des paramètres avec B=0; elle laisse à l'implémentation le choix d'ignorer ou de sauvegarder la configuration. La section 4.3.2.2 dit que ce sous-champ doit être ignoré. Une note de l'éditeur propose encore une autre méthode : l'absence complète du LSP-S-BFD TLV pourrait signifier qu'il faut retirer S-BFD d'un chemin qui en disposait. Ce dernier scénario figure comme alternative à discuter. Un B=0 explicite et un champ absent ne sont pas les deux orthographes d'une même commande. L'un est un message, l'autre peut n'être que le silence.

Le contrôleur ne peut pas résoudre ce désaccord en redessinant son interface. Son écran peut afficher « off » après l'envoi de B=0. Pour savoir si le PCC a supprimé une configuration active, conservé des paramètres ou ignoré un ordre redondant, il faut la réponse du PCC et son état local. Pour décider ce que devrait faire tout PCC conforme, il faut que les éditeurs choisissent une règle commune. Le texte actuel laisse à la mise en œuvre une partie de ce conflit, puis lui demande d'interopérer.

La note sur les groupes d'association montre une autre limite du contrôle central. Certaines implémentations, dit le projet, ne peuvent avoir des valeurs S-BFD différentes pour les LSP d'un même groupe. Dans cette situation, une différence d'intervalle, de multiplicateur ou de discriminateur devrait produire une erreur d'association de type 26. Le qualificatif « certaines » mérite de survivre à la présentation commerciale. Le PCE peut proposer une combinaison; le PCC peut rencontrer une contrainte locale. Le rapport d'erreur raconte cette rencontre. Il ne transforme pas la contrainte d'un produit en loi pour tous les réseaux.

RFC 7880 expose le fonctionnement de S-BFD. RFC 8231 et RFC 8281 donnent le cadre du PCEP avec état et des LSP initiés par le PCE; RFC 9050 décrit l'architecture du PCE comme contrôleur central. Ces textes donnent son contexte à la proposition. Ils ne remplacent pas un essai de cette extension précise sur un PCC nommé. La révision 02 et la révision 03 modifient la date et l'échéance du document; le conflit sur l'arrêt y demeure. Une nouvelle couverture ne referme pas le circuit.

Pour un essai réel, la chaîne de preuves tiendrait sur une ligne par LSP : capacité échangée dans OPEN, type de chemin commun, ordre PCInit ou PCUpd, rapport PCRpt, configuration effective et état de la session S-BFD. Chaque colonne répond à une question différente. L'ordre montre l'intention du PCE; le rapport montre ce que le PCC déclare; la configuration et la session montrent ce que la machine exécute. Une panne de chemin ajoute encore une question sur ce que le détecteur a observé. Le bouton du contrôleur ne peut parler à la place de ces autres colonnes.

Les sources officielles réunies ici décrivent les règles proposées et les RFC sur lesquelles elles s'appuient. Elles ne contiennent pas de trace d'interopérabilité reliant un B=0 ou B=1 de ce projet à l'état effectif d'un PCC identifié. Une telle trace, accompagnée du rapport et de la session de détection, trancherait le comportement pour cette implémentation. En attendant, le détail décisif reste imprimé entre deux sections du projet : que fait exactement la machine quand le contrôleur dit d'arrêter ?

Sources