Résumé

  • RFC 5376 autorisait un PCE inter-AS à fournir un identifiant de segment opaque, afin qu'un domaine conserve ses sauts internes et ses choix commerciaux sans empêcher la composition d'un chemin.
  • Cette référence ne constatait ni la signalisation, ni la réservation, ni la mise en service d'un LSP; le domaine devait pouvoir vérifier que le développement ultérieur correspondait au segment réellement calculé par son PCE.
  • L'identité du pair, l'autorisation locale, la politique appliquée, le calcul, la conformité de la signalisation et l'acheminement sont des preuves distinctes; un coût cumulé n'est comparable qu'avec une politique de métrique commune.

La discrétion était une fonction du protocole

Dans un réseau multi-opérateurs, révéler la route complète n'est pas une formalité. La topologie peut indiquer les points de concentration, les capacités, les accords d'interconnexion ou les choix d'ingénierie d'un fournisseur. Elle peut faciliter une attaque et dévoiler un avantage commercial. RFC 5376 part donc d'une contrainte politique légitime: calculer ensemble sans constituer un contrôleur omniscient.

Le PCC d'origine peut interroger un PCE inter-AS. Celui-ci peut déléguer une partie du problème à un autre PCE inter-AS ou à des PCE internes. Le demandeur ne connaît pas nécessairement ces contributeurs. Même leur existence peut rester confidentielle au-delà du pair direct. La coopération se fait par segments et par messages, pas par transfert de souveraineté sur les graphes internes.

Le résultat peut nommer des AS ou des ASBR lorsque cela est permis. Pour un passage interne sensible, il peut fournir un identifiant de segment. Cet identifiant suffit à conserver une place dans le chemin composé et à demander plus tard son développement. Il représente une décision calculée, mais ne la rend pas observable au demandeur.

Ce dispositif crée un contrat de connaissance limité. Le client sait qu'une autorité de calcul a rendu une référence sous certains paramètres. Il ne sait pas quels liens internes elle recouvre. Il ne sait pas davantage si une signalisation postérieure a accepté la référence, si des ressources ont été réservées, si le LSP est actif ou si un paquet est arrivé. Une interface honnête doit afficher cette limite au lieu de transformer «segment calculé» en «service établi».

Le secret devait rester vérifiable

L'opacité ne peut pas signifier que n'importe quelle expansion ultérieure sera réputée conforme. RFC 5376 demande un mécanisme, reflété dans la signalisation correspondante, permettant à un AS de vérifier que le chemin signalé respecte le segment fourni par son PCE local. Ce point place la preuve chez l'acteur qui connaît à la fois le graphe caché et la décision initiale.

Imaginons que le PCE du domaine B rende la clé K pour un segment satisfaisant une bande passante, une protection et une sortie imposée. Lors de l'établissement, un composant développe K. Sans contrôle local, il pourrait choisir un autre parcours, ignorer une contrainte ou employer une version obsolète. Le PCC d'origine ne peut pas le découvrir en inspectant les sauts, puisque ceux-ci lui sont délibérément cachés. B doit donc comparer l'expansion avec son propre engagement, puis rendre un résultat de conformité suffisamment précis pour l'audit.

Cette preuve n'exige pas la publication du parcours. Elle peut lier la clé, le contexte de calcul, la version de politique, le moment de l'expansion et le verdict du domaine. La confidentialité demeure; la substitution devient détectable. Le contrôle est plus solide parce qu'il respecte la frontière d'autorité au lieu de demander à une partie extérieure de certifier des faits qu'elle ne peut voir.

Le principe général est celui d'une délégation minimale. Une référence opaque donne le droit de demander une opération définie; elle ne donne ni accès à tous les faits cachés ni pouvoir de les réécrire. Le domaine émetteur conserve le droit de révoquer, recalculer ou refuser la référence si l'état de son réseau change.

La politique locale pouvait changer la demande

Une requête inter-AS peut préciser des AS et ASBR souhaités ou exclus et marquer certains passages comme obligatoires. Elle peut demander de la protection, de la disjonction ou de la diversité entre AS, sur l'ensemble du chemin ou seulement dans un domaine. Elle transporte aussi le numéro d'AS du demandeur afin que le PCE récepteur applique sa politique locale.

Cette politique peut refuser la requête. Elle peut modifier la priorité, la bande passante, le comportement de reroutage rapide ou une classe DS-TE. Un paramètre né dans un contexte MPLS peut devoir être interprété autrement dans un domaine GMPLS. La continuité du champ sur le fil ne garantit donc pas la continuité de sa signification.

Un rejet explicite n'est pas une panne du protocole. Il prouve souvent que l'opérateur n'a pas abandonné son pouvoir sur ses ressources. À l'inverse, l'authentification du PCE demandeur ne lui accorde pas automatiquement le droit d'imposer toutes les contraintes qu'il sait encoder. Identité, juridiction et décision doivent rester séparées.

Pour l'audit, chaque réponse devrait conserver le demandeur, l'autorité ayant évalué la requête, les contraintes acceptées, celles qui ont été réécrites et la raison d'un refus. Sans cette provenance, un orchestrateur aval peut présenter comme engagement global ce qui n'était qu'une possibilité locale et conditionnelle.

Un total n'établissait pas une mesure commune

RFC 5376 permet de retourner un coût inter-AS cumulé, mais laisse hors périmètre la normalisation des coûts entre domaines. Cette phrase empêche de donner au nombre plus d'autorité qu'il n'en a. Chaque AS peut employer une échelle, une fonction d'objectif ou une préférence administrative différente. Additionner les valeurs ne fabrique pas automatiquement une unité commune.

Un chemin affiché à 42 n'est donc pas nécessairement meilleur qu'un chemin affiché à 51. Le premier total peut combiner des poids de trafic, le second des préférences commerciales, ou les deux peuvent intégrer des traductions de contraintes différentes. Le calcul est peut-être exact selon ses règles; le classement comparatif reste indémontré.

Les méthodes par domaine ne garantissent pas non plus l'optimum global d'un chemin contraint. Employer le mot «optimal» exige de déclarer l'objectif, les métriques comparables, les domaines couverts et les contraintes omises. À défaut, la formulation défendable est plus étroite: un chemin admissible a été trouvé par les autorités participantes sous leurs politiques du moment.

Il faut donc conserver les contributions et transformations, pas seulement le total. Si une politique commune est adoptée plus tard, les données peuvent être réinterprétées. Si seul le score final subsiste, l'incertitude initiale disparaît du registre alors qu'elle demeure dans la décision.

La sécurité du canal ne décidait pas du fond

Les pairs PCE doivent authentifier leurs identités, valider les données et protéger les échanges sensibles. Le chiffrement et la distribution de clés doivent tenir compte des frontières entre AS et des principes de RFC 4107. PCEP, puis sa protection par TLS, ont fourni des mécanismes plus concrets. Ils n'ont pas supprimé la politique locale.

Une session protégée établit qui contrôle un justificatif auprès du pair direct. Elle ne garantit pas que chaque PCE aval est connu du PCC d'origine. Elle ne prouve pas non plus qu'une requête authentifiée est autorisée, qu'un algorithme a employé des données fraîches ou que la réponse sera suivie pendant la signalisation.

Les objets de politique illustrent cette limite. Le protocole de transport peut les porter comme blocs opaques vers un composant qui comprend leur sémantique. Si leur origine ou leur mandat exige une protection plus forte, ce composant doit la vérifier. Une enveloppe sûre ne peut juger une règle qu'elle ne sait pas lire.

Le registre doit donc nommer le pair de transport et l'autorité de décision. Il doit également indiquer les contributions aval lorsqu'elles peuvent être divulguées, ou au moins constater qu'une chaîne coopérative a existé avec un niveau de confiance donné. «Canal authentifié» ne doit jamais devenir le raccourci de «chemin autorisé et exécuté».

Un dossier de preuve en étapes

Une exploitation rigoureuse peut relier plusieurs reçus sous un même identifiant d'intention sans les fusionner:

  1. la requête, ses extrémités, son AS d'origine, ses ASBR obligatoires ou exclus et ses contraintes;
  2. la décision de politique locale, y compris les modifications et refus;
  3. le calcul, ses versions d'état, ses segments explicites ou ses clés opaques;
  4. la vérification locale que la signalisation a développé exactement le segment calculé;
  5. l'établissement du LSP, les ressources, étiquettes et états opérationnels;
  6. l'observation de l'acheminement, de la livraison et de la réponse applicative.

Une réponse PCE positive couvre au mieux les premières étapes. Elle ne crée pas rétroactivement les reçus suivants. Cette séparation donne aussi une histoire intelligible en cas de changement: un calcul peut avoir été valable avant une panne, une politique peut être révisée sans nier la décision antérieure, et un LSP peut échouer malgré une bonne réponse de calcul.

La traçabilité doit être temporelle. Une clé de segment calculée sur une topologie de 10 h 00 ne vaut pas automatiquement après une rupture de lien à 10 h 03. L'âge de la référence, la version de politique et l'état utilisé par le PCE sont des éléments de sens, pas de simples métadonnées.

Ce que les extensions ultérieures n'ont pas effacé

RFC 5440 a spécifié PCEP et RFC 5520 les clés de chemin pour préserver la confidentialité. L'architecture PCE hiérarchique, les extensions stateful et TLS ont ensuite accru les capacités de coordination, de mémoire et de protection. Aucune de ces évolutions ne transforme une réponse de calcul en preuve universelle d'exécution.

Un PCE stateful peut connaître davantage de LSP; cela ne le rend pas propriétaire de toutes les politiques des domaines. Une hiérarchie peut améliorer la vue d'ensemble; elle ne rend pas comparables des métriques qui ne le sont pas. TLS protège un canal; il ne valide pas la conformité d'une expansion cachée. Chaque amélioration doit produire une preuve à la hauteur de son propre rôle.

Enfin, ces textes ne démontrent aucun déploiement actuel, aucune performance commerciale et aucun résultat utilisateur. Ils fournissent une architecture de responsabilités. La valeur de RFC 5376 réside précisément dans cette modestie: rendre la coopération possible tout en laissant à chaque opérateur la maîtrise des faits internes qu'il est seul à pouvoir vérifier.