Résumé
- L’annexe A.1 de RFC 9689 fait coexister des nœuds anciens utilisant LDP ou RSVP-TE et des nœuds nouveaux programmés directement par PCECC ; le contrôleur peut agir comme proxy entre eux.
- Cette continuité masque une couture de preuve : identités, accusés de réception, temporisations, propriétaire du basculement et nettoyage restent différents de part et d’autre.
Supposons qu’une équipe demande, le matin suivant la migration : « Quel système a installé cette étiquette ? » Pour Node2, la réponse se trouve dans une session LDP ou dans l’état RSVP-TE. Pour Node4, elle se trouve dans un PCInitiate, un CC-ID et un PCRpt. Pour Node3, frontière du scénario de RFC 9689, la réponse passe aussi par la fonction de proxy. Une ligne verte dans l’outil d’exploitation ne suffit donc pas à raconter l’histoire commune.
Le scénario est volontairement borné. RFC 9689 est un document informatif. Son annexe rassemble des usages qui n’étaient pas en développement actif lors de la publication. Elle décrit une architecture possible, pas le comportement d’un produit ni l’expérience d’un opérateur réel.
La couture porte trois récits
Le premier récit est celui de l’ancien plan de contrôle. RFC 5036 et RFC 3209 donnent à LDP et RSVP-TE leurs propres voisinages, messages, identifiants et durées de vie. Le deuxième récit est celui de PCECC : RFC 9050 envoie des instructions centrales à chaque PCC et reçoit des comptes rendus individuels. Le troisième est celui du proxy, qui associe une entrée du premier monde à une sortie du second.
Une preuve de migration doit conserver ces trois récits sans les confondre. Elle relie l’identité du service, l’ancienne identité du chemin, le nœud frontière, la session PCEP, l’identité du PCE, le PLSP-ID, la source et chacun des CC-ID. Pour le proxy, elle conserve l’état reçu, la règle appliquée et l’état émis. Sinon, une traduction correcte aujourd’hui devient demain une origine impossible à reconstruire.
Le risque n’est pas seulement documentaire. Une étiquette peut avoir été allouée localement par un PCC, une autre imposée par le PCE, tandis qu’une réservation ancienne attend encore son expiration. Le chemin fonctionne, mais personne ne sait quel système a le droit de modifier ou de supprimer chaque morceau.
Des accords locaux, pas un vote atomique
RFC 9050 prévoit un accusé PCRpt pour chaque instruction. Un PCC doit signaler une étiquette hors plage ou l’échec du téléchargement. Ces réponses sont précieuses, mais elles restent locales à un nœud et à une session. Le contrôleur doit encore vérifier qu’elles appartiennent à la même génération et que toutes les positions nécessaires — entrée, transit, sortie — sont couvertes.
La mise à jour montre clairement l’ordre des engagements : installer les nouvelles instructions, demander à l’entrée de commuter, attendre son compte rendu, puis nettoyer les anciennes instructions. Avant la commutation, le nouvel état peut exister sans transporter le service. Après la commutation, l’ancien et le nouveau peuvent coexister. Après un nettoyage PCECC, une réservation LDP ou RSVP-TE peut encore survivre sur l’autre moitié.
Le retour arrière doit donc être défini par étape. Un échec avant la commutation appelle l’effacement de la génération incomplète. Un échec après la commutation exige d’abord de rétablir une autorité de transfert. Si l’ancien état a déjà été retiré, « revenir » signifie parfois le reconstruire. Un bouton unique ne peut honnêtement représenter ces cas.
L’état orphelin reste de l’état actif
Lorsqu’un PCE tombe, RFC 9050 ne supprime pas immédiatement les instructions : elles peuvent subsister jusqu’à l’expiration du State Timeout Interval, et un autre PCE peut en reprendre le contrôle. Ce choix protège la continuité, mais il sépare encore l’existence de l’état et son propriétaire courant. RFC 8283 rappelle d’ailleurs que la synchronisation de contrôleurs parallèles est complexe et peut perdre des changements.
La reprise doit consigner la dernière génération complète, les nœuds qui ont répondu, l’état de l’entrée, le côté ancien, les suppressions en attente, les échéances et l’acte de reprise de l’orphelin. Une nouvelle session PCEP ne prouve pas que le nouveau contrôleur connaît la décision éditoriale ou commerciale qui justifiait la bascule.
Un reçu borné de migration peut alors répondre à dix questions : où est la frontière ; quels protocoles opèrent de chaque côté ; comment les identités se correspondent ; quels nœuds ont confirmé ; qui a autorisé la commutation ; quel chemin transporte réellement ; quel ancien état subsiste ; qui possède les orphelins ; quelle temporisation s’applique ; et quelles suppressions ont été vérifiées.
Le proxy a précisément de la valeur parce qu’il permet une adoption progressive. Lui attribuer une unité qu’il ne fournit pas détruirait cette valeur : la couture ne disparaît pas, elle devient invisible.
Sources
- RFC 9689 et sa notice de publication
- Texte brut, XML et recherche d’errata
- Historique IETF de RFC 9689
- RFC 9050, procédures PCECC
- RFC 8283, architecture PCECC
- RFC 8231, PCE avec état
- RFC 8281, LSP initiés par le PCE
- RFC 8741, demande de délégation
- RFC 5440, PCEP et RFC 8253, PCEP sur TLS
- RFC 5036, LDP et RFC 3209, RSVP-TE
- Spécification initiale minimale et décision locale
- Les couches de réalité
- La primauté du code en fonctionnement
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance

