Résumé

  • Une annonce de capacité, une synchronisation, un PCUpd ou un PCInitiate décrivent des rôles de protocole distincts, pas une même preuve d’exploitation.
  • RFC 8231 laisse au PCC la propriété de l’état et son jugement de politique locale, même lorsqu’il délègue certains attributs d’un LSP au PCE.

Dans une salle d’exploitation, le mot délégation peut prendre la place d’un registre entier. On voit un indicateur de délégation dans un échange PCEP et l’on raconte déjà qu’un contrôleur « tient » le réseau. C’est une économie de langage coûteuse : elle confond ce qui a été inscrit dans un protocole, ce qui a été autorisé localement et ce qui s’est effectivement produit dans la fibre ou le paquet.

RFC 9504 apporte PCEP à état au contexte GMPLS. Le PCE et le PCC peuvent déclarer une capacité, synchroniser l’état des LSP, signaler un changement, demander une mise à jour ou demander l’établissement d’un LSP. Chaque opération est utile parce qu’elle est précisément bornée. La capacité requiert l’assistance et l’autorisation correspondantes des deux participants. Elle ne réserve pas une ressource et n’impose pas à un équipement d’accepter une action.

La séparation devient plus nette avec RFC 8231. Avant de calculer ou de modifier, le PCE à état doit apprendre l’état des LSP du PCC. Un PCRpt rend compte d’un état ; un PCUpd demande une modification. La délégation donne au PCE le droit de mettre à jour des attributs pour des LSP déterminés, tant que cette délégation subsiste. Mais le PCC conserve la propriété de l’état, applique sa politique locale et peut reprendre la délégation. Ce n’est pas une réserve de détails juridiques : c’est l’architecture de responsabilité du mécanisme.

Un LSP délégué reste donc un objet de portée définie. Il ne démontre pas qu’un responsable a cédé son pouvoir d’exploitation, qu’une fenêtre de maintenance a été validée, qu’un choix de ressources a été admis, ni qu’un chemin de transfert ou un cross-connect a été installé. Même l’expression « LSP initié par le PCE » de RFC 8281 doit être lue avec exactitude : le PCE fait une demande qui déclenche l’établissement par le nœud terminal. La demande est une preuve de demande. Elle n’est pas le journal d’acceptation, la preuve d’allocation ni la mesure du trafic.

L’erreur la plus fréquente n’est pas technique, mais grammaticale. Un rapport est lu comme une réalisation ; une intention, comme un état installé ; une capacité, comme un pouvoir. Or RFC 9504 distingue aussi l’information de chemin envisagée de l’information de chemin réel dans les rapports. Cette distinction ne permet pas d’inférer, à elle seule, une continuité de service. Pour cela, il faut encore des preuves de l’équipement, du plan de transfert et de l’observation du service.

La bonne lecture est séquentielle. D’abord, les participants et les capacités admises. Ensuite, l’état synchronisé et la délégation limitée. Puis le message qui demande une action. Après seulement viennent le contrôle de politique du PCC, l’action sur les ressources et la trace de l’état installé. Le trafic et l’effet client constituent une question indépendante. Une marche peut justifier la suivante ; aucune ne l’absorbe tacitement.

Cette discipline correspond à l’idée de Heng Lu d’une spécification initiale minimale : la couche commune doit exprimer l’interopérabilité sans confisquer la décision locale. Elle rejoint également sa primauté du code en fonctionnement, à une condition essentielle : du code qui fonctionne montre qu’un mécanisme fonctionne, non qu’il possède un mandat plus large que celui qui lui a été accordé.

Pour l’exploitant, la formulation utile n’est donc pas « le PCE contrôle-t-il le réseau ? ». Elle est : quels attributs du LSP ont été délégués, par quel PCC, sous quelle politique, et quelle preuve relie la demande au résultat observé ? Cette question rend l’automatisation plus solide, parce qu’elle lui interdit de raconter plus qu’elle ne sait.

Sources