Résumé

  • RFC 9753 négocie l’emploi des indicateurs P et I de l’en-tête d’objet dans les messages PCEP stateful ; un objet inconnu dont P vaut zéro peut être ignoré sans interrompre le traitement du message.
  • La poursuite de l’échange, un indicateur I ou un état PCRpt sont des reçus protocolaires limités. Ils ne démontrent ni l’équivalence du chemin ni la réalisation dans le plan de transfert.

Le cas le plus délicat n’est pas toujours une erreur. Un PCC envoie un rapport d’état comprenant un objet que le pair ne connaît pas. La politique locale a rendu cet objet facultatif en effaçant P. Le destinataire le saute, traite les autres objets et conserve la session. Le protocole a suivi exactement le chemin autorisé. Pourtant, une limite de délai, une préférence, une protection ou un autre élément de sens peut avoir cessé de participer à la décision.

RFC 9753, publié en avril 2025 sur la voie Standards Track de l’IETF, met à jour RFC 8231. La notice RFC Editor et la fiche Datatracker fixent son identité et son statut. Le texte étend aux messages PCRpt, PCUpd et PCInitiate une idée déjà présente dans le PCEP de base : certains objets peuvent être obligatoires à traiter, d’autres peuvent être ignorés.

Une capacité commune ne crée pas une politique commune

Dans RFC 5440, P indique la règle de traitement et I signale qu’un objet facultatif a été ignoré. RFC 8231 demandait que ces deux bits restent à zéro pour ses objets stateful. RFC 9753 introduit donc R, le bit RELAX du STATEFUL-PCE-CAPABILITY TLV. Le registre PCEP de l’IANA l’inscrit au bit 17.

R doit être annoncé par le PCE et le PCC. Si un pair n’a pas annoncé R, il ignore P et I conformément au comportement antérieur. Le reçu est précis mais étroit : les deux extrémités acceptent la grammaire pendant cette session. Il ne dit pas quels objets chaque organisation juge relaxables, ni si les deux politiques donnent la même importance à la contrainte.

Le texte recommande P=1 par défaut. P ne devrait être effacé que si une configuration ou une politique locale considère la contrainte correspondante comme facultative, ou l’objet comme purement informatif et sûr à ignorer. Le protocole ne découvre donc pas que l’objet est sans conséquence ; une autorité locale prend cette décision.

L’unité de risque est l’objet entier

P et I portent sur l’objet PCEP complet, pas sur un TLV facultatif inclus dans cet objet. Un journal exploitable doit conserver la classe, le type, le message, le sens, l’identité SRP ou de requête, la version de politique et le LSP concerné. Sans cela, l’opérateur ne peut pas savoir si seule une décoration inconnue a disparu ou si tout l’objet qui portait une exigence a été écarté.

Les objets obligatoires restent protégés. Dans PCRpt, RFC 9753 cite LSP et l’ERO du chemin prévu ; dans PCUpd et RFC 8281 PCInitiate, il cite SRP, LSP et ERO. Un bit P incorrectement effacé sur ces objets impose PCErr de type 10, valeur 1. Pour un objet non obligatoire, P=1 et l’incompréhension conduisent au rejet complet avec Unknown Object ou Not supported object. P=0 autorise l’ignorance et la poursuite.

L’absence d’erreur admet donc deux histoires : tout a été compris, ou un objet inconnu mais facultatif a été perdu proprement. Un simple compteur de messages réussis ne les sépare pas.

La délégation modifie qui peut changer P

Dans PCRpt, P dit au PCE ce qui doit compter pour l’entretien d’état, le calcul ou la réoptimisation. Dans PCUpd et PCInitiate, P dit au PCC ce qui doit compter pour l’établissement du chemin. RFC 8051 décrit le contexte d’emploi ; RFC 8231 laisse la propriété de l’état du LSP au PCC et soumet les attributs reçus à sa politique locale.

Pendant une délégation, RFC 9753 permet néanmoins au PCE de marquer un objet comme ignoré alors que le PCC avait mis P, ou de le rendre obligatoire alors que le PCC l’avait effacé. Le PCC doit accuser réception de cette attente dans PCRpt ou appliquer la procédure de mise à jour inacceptable. La photographie finale ne suffit pas : il faut l’autorité de délégation, la génération de session, la requête, les valeurs avant/après et l’acquittement.

I ne certifie pas la satisfaction

Un PCE peut remettre l’objet facultatif ignoré dans PCUpd et positionner I. Un PCC peut faire de même dans un PCRpt répondant à PCUpd ou PCInitiate. I effacé signifie que le pair déclare avoir traité l’objet. Mais I n’a aucun sens dans un PCRpt sans SRP corrélant la réponse, et il doit rester nul dans PCInitiate.

Même valide, « traité » ne signifie pas « satisfait ». L’analyseur peut reconnaître l’objet ; la politique peut le lire ; une autre contrainte peut gagner ; le chemin réel peut différer du chemin prévu. Le rapport d’un PCC n’est pas une lecture indépendante du matériel de transfert.

L’exemple du RFC est parlant. PCRpt peut porter des listes d’attributs prévus et réels. Un objet METRIC peut borner la variation de délai selon RFC 8233. Le rendre facultatif peut éviter l’échec lorsqu’aucun chemin ne respecte la borne. Mais la réussite qui suit ne conserve pas la borne. Il faut enregistrer valeur et unité, décision d’ignorer, nouveau calcul, chemin réalisé, puis mesurer le trafic.

Le contrôle et le transfert restent deux témoins

RFC 8231 décrit la synchronisation initiale comme une réplique à un instant donné de l’état du PCC. PCRpt peut exposer chemin, bande passante et états. Entre cette représentation et le paquet se trouvent politique locale, signalisation, admission de ressources, sélection RIB ou table de labels, résolution de prochain saut et programmation matérielle.

Cette frontière distingue aussi cette analyse de RFC 9757, consacré aux instructions centrales Native IP, et de RFC 9826, qui standardise une projection YANG de PCEP. Aucun de ces plans de contrôle ou de gestion ne devient, par sa complétude, un observateur du transfert.

RFC 9753 recommande des sessions authentifiées et chiffrées sous une même autorité administrative, avec PCEPS selon RFC 8253 et les pratiques TLS de RFC 9325. Cela protège l’identité du pair et le transport. Cela n’authentifie pas le sens de la politique d’optionalité.

Le document demande aussi que la capacité et les contraintes facultatives soient configurables et visibles. Il n’ajoute pas de nouvelle exigence de vérification opérationnelle. Cette phrase borne la norme ; elle n’abolit pas les preuves externes requises par un service.

La grille des couches de réalité de Heng Lu sert ici de méthode éditoriale déclarée : un symbole négocié, un objet accepté, un état de contrôleur, une programmation et un résultat observé ne sont pas le même fait. Le registre fiable relie onze reçus : pairs et session, R mutuel, message et objet, politique d’émission, analyse, décision d’ignorer ou d’émettre une erreur, sens perdu, recalcul, réconciliation PCE/PCC, état du dispositif, paquets et retour arrière.

Registre des sources

Le dossier technique réunit le texte RFC 9753, sa notice, le Datatracker, le registre IANA, RFC 5440, RFC 8231, RFC 8281, RFC 8051, RFC 8233, RFC 8253, RFC 9325, le voisin RFC 9757 et le voisin RFC 9826. Aucun déploiement, fournisseur, incident, test d’interopérabilité ou taux d’adoption n’est affirmé.