Résumé

  • RFC 9752 autorise l’objet Vendor Information dans PCRpt, PCUpd et PCInitiate, tout en rattachant explicitement Enterprise Number au registre IANA des Private Enterprise Numbers.
  • Un PEN exact localise un espace privé ; il ne signe ni le dictionnaire, ni sa version, ni l’autorité du pair, ni l’état effectivement programmé.
  • Une preuve exploitable doit relier octets, décodeur, capacité, décision locale, SRP/PLSP, réconciliation PCE/PCC, équipement, trafic, retour arrière et solution interopérable.

Le risque n’apparaît pas forcément sous la forme d’une erreur. Il peut prendre la forme d’un PCRpt parfaitement valide. Le PCC a reçu une mise à jour, reconnu l’objet 34, lu un PEN connu, exécuté son décodeur et renvoyé un état. Chaque étape peut être conforme à son propre instrument. Rien n’établit encore que le document sémantique venait du titulaire du PEN, que ce document était la bonne version ou que l’état signalé correspondait au forwarding.

RFC 9752 est un Proposed Standard IETF d’avril 2025. Sa fiche RFC Editor et son historique Datatracker confirment qu’il met à jour RFC 7470. Son apport est précis : étendre aux opérations stateful le transport d’informations propres à un fournisseur. Il ne normalise pas leur signification.

Un contenant plus proche de la commande

RFC 7470 avait créé l’objet VENDOR-INFORMATION, classe 34 type 1, et le VENDOR-INFORMATION-TLV, type 7. Après le champ Enterprise Number viennent des informations dont le format et l’interprétation relèvent de l’entreprise désignée. Leur publication est encouragée, mais peut rester dans une documentation commerciale. Le protocole ne possède donc pas, pour ces octets, de version sémantique universelle.

RFC 9752 ajoute l’objet à trois échanges. Dans PCRpt, le PCC décrit l’état d’un LSP au PCE. Dans PCUpd, le PCE demande une modification d’attributs. Dans PCInitiate, il peut demander une création ou une suppression ; la grammaire étendue place la liste privée dans la forme d’instanciation. Le TLV pouvait déjà entrer dans SRP, LSP et tout objet stateful acceptant des TLV.

Ces positions n’ont pas le même poids opérationnel. Une mesure privée rapportée n’est pas une contrainte privée appliquée ; une contrainte décodée n’est pas un ordre autorisé. Plusieurs objets peuvent figurer dans un même PCRpt, avec des PEN différents. RFC 9752 ne fixe ni ordre de priorité entre eux, ni règle générale lorsqu’un contenu privé contredit un objet normalisé.

Le registre conserve un nom, pas l’origine de chaque paquet

RFC 9752 remplace l’ancienne référence imprécise par le registre Private Enterprise Numbers décrit dans RFC 9371. C’est une correction de registre, non une chaîne de confiance.

RFC 9371 précise qu’IANA attribue les PEN selon First Come First Served et vérifie l’autorisation d’une modification du dossier. Mais ni IANA ni l’IETF ne contrôlent l’usage privé du nombre, et personne ne peut empêcher un tiers de placer le PEN d’autrui dans ses propres données. La ligne du registre prouve donc une attribution administrative observée à une date. Elle ne prouve pas l’auteur des octets reçus.

Il faut lui joindre un manifeste sémantique authentifié : éditeur, version, hachage du document, hachage du décodeur, positions PCEP couvertes, date de retrait et matrice de compatibilité. Cette séparation doit survivre aux acquisitions, forks, fins de support et transferts d’équipe, dont le calendrier ne coïncide pas nécessairement avec celui du contact IANA.

L’ignorance peut être conforme et néanmoins dangereuse

Une implémentation qui connaît l’objet mais pas le PEN doit l’ignorer selon la procédure héritée. Un émetteur ne devrait pas joindre l’information s’il pense que le destinataire ne la prend pas en charge. Or RFC 7470 laisse hors périmètre le mécanisme de découverte ou d’annonce de cette prise en charge et reconnaît qu’une coopération entre fournisseurs est nécessaire à l’interopérabilité fonctionnelle.

Il existe donc au moins quatre capacités : reconnaître l’enveloppe ; reconnaître le PEN ; implémenter une version déterminée ; l’autoriser pour ce pair, ce message et ce LSP. L’ignorance d’un objet inconnu peut préserver le protocole de base tout en supprimant silencieusement l’effet attendu. À l’inverse, décoder correctement un champ ne confère aucune autorité pour modifier l’état.

Un accord de capacité défendable identifie les deux parties, la version, les opérations admises, l’échéance, le comportement en cas de downgrade et le fallback. Le test interopérable consiste aussi à retirer l’extension : les objets normalisés doivent garder le même sens ou l’échec doit être explicite.

Le chiffrement protège le trajet, pas le mandat

RFC 9752 recommande les sessions authentifiées et chiffrées de RFC 8253. Cela protège le pair et les octets en transit. Cela ne signe pas le dictionnaire privé et ne dit pas si ce pair peut agir sur ce LSP.

RFC 8231 exige que le PCC ne donne suite à une requête de mise à jour que si la politique locale du gestionnaire l’autorise. Une requête traitée lance une opération de setup ; le PCC renvoie ensuite un état. RFC 8281 impose une capacité d’instanciation annoncée des deux côtés et distingue paramètres inacceptables, erreur interne et échec de signalisation.

La session, la délégation, la politique locale, le résultat du parseur et le PCRpt sont cinq pièces. Un rapport corrélé par SRP-ID et PLSP-ID aide à réconcilier PCE et PCC. Il ne lit pas directement la RIB, la FIB, la table d’étiquettes ou les paquets. La télémétrie de l’équipement et l’observation du service restent en aval.

Conserver les coutures de la preuve

Le journal utile commence par les octets bruts, le PEN, le type de message, la position de l’objet, le contexte de session et le résultat de parsing. Il ajoute la version et le hachage du décodeur, la décision d’autorisation, les valeurs normalisées voisines et la règle de conflit. Puis il relie demande, rapport ou erreur par SRP-ID, PLSP-ID, pair et époque de session.

Après PCEP viennent la transaction d’équipement, la configuration réellement appliquée, l’état de forwarding, la sonde de trafic, le résultat de service et le rollback. Chacun est daté et conserve son propre auteur. Une lecture FIB n’est pas une preuve permanente de livraison ; une sonde n’est pas un SLA.

RFC 9752 n’ajoute justement aucun mécanisme de liveness, aucune nouvelle méthode de vérification et aucune exigence pour un autre protocole. Un module YANG standard peut signaler l’usage et le PEN, non le détail privé. Le RFC alerte aussi sur le canal covert que peut fournir ce champ. L’opérateur doit connaître le décodeur et inspecter l’usage, pas seulement compter les occurrences.

Le registre PCEP IANA confirme les codepoints. Les RFC citées établissent les règles, pas une implémentation, un incident, un déploiement ou un gain mesuré. Running-Code Primacy, Minimum Initial Specification et Reality Layers de Heng Lu sont ici une grille éditoriale déclarée : le contenant commun reste mince ; l’adoption, le sens et l’effet doivent être démontrés par les participants. Ce n’est pas une prescription de l’IETF.