Résumé

  • Un PCRep positif prouve qu’un PCE a trouvé une solution dans un graphe, avec des contraintes, un objectif et une politique donnés. Il ne prouve ni l’acceptation par le PCC ni l’installation dans les équipements.
  • La réalité opérationnelle arrive par étapes distinctes : signalisation ou programmation, réservation, état RIB/FIB, rapport du PCC, observation des paquets, puis mesure du service.

Le résultat est déjà visible : une ERO relie l’entrée à la sortie, les métriques sont propres, l’interface du contrôleur affiche le vert. Pourtant, aucun routeur n’a confirmé l’installation. La contradiction n’est qu’apparente. L’écran montre la réponse à une question de calcul ; l’opérateur voudrait y lire la réponse à une question d’exécution.

Cette confusion explique une partie des faux succès de l’automatisation réseau. Une même ligne dessinée sur une carte peut signifier une intention, un chemin calculé, un LSP signalé, une politique installée ou un trafic réellement observé. Le graphisme gomme les transitions que le protocole conserve.

RFC 4655 constitue ici le point de départ. Adrian Farrel l’a cosigné avec Jean-Philippe Vasseur et Jerry Ash au sein du groupe de travail PCE de l’IETF. Le document définit le PCE comme une entité qui calcule une route à partir d’un graphe en appliquant des contraintes. Dans son schéma d’un PCE externe, le nœud de tête demande un calcul avant de lancer la signalisation. Le PCE consulte la TED sous l’effet d’une politique locale et renvoie une réponse. La signalisation reste une fonction séparée.

La topologie calculée n’est pas la topologie éternelle

La Traffic Engineering Database contient la topologie et les ressources que le PCE connaît. Cette connaissance peut venir de l’IGP, d’une synchronisation hors bande ou d’autres mécanismes. Elle peut être complète, partielle, récente ou déjà vieillissante.

RFC 4655 ne masque pas le problème. Une synchronisation hors bande imparfaite peut accroître les échecs ou produire des chemins sous-optimaux lorsque l’état du réseau change vite. Une réponse correcte doit donc être formulée ainsi : la solution satisfaisait le modèle disponible au moment du calcul.

RFC 5440, de Vasseur et Jean-Louis Le Roux, ajoute le contrat d’échange. Le PCReq décrit notamment les extrémités, la bande passante et les priorités. Les contraintes déterminent l’espace admissible. RFC 5541 permet d’indiquer une fonction objectif pour départager les solutions. La politique locale peut encore modifier ce qui est demandé, permis ou retourné.

Ces éléments devraient accompagner le chemin dans la piste d’audit. Une ERO sans version de TED, sans contraintes et sans objectif ressemble à une réponse privée de sa question.

« Calculé avec succès » n’est pas « exécuté avec succès »

Le scénario positif de RFC 5440 est précis : le PCE reçoit le PCReq, calcule le chemin avec succès, puis envoie les chemins calculés dans un PCRep. L’ERO encode le chemin du TE LSP. Le texte indique qu’elle est disponible pour une signalisation immédiate par le plan de contrôle MPLS ou GMPLS.

La disponibilité à la signalisation marque le début de l’étape suivante, pas son achèvement.

Dans RSVP-TE, RFC 3209 décrit la signalisation et la réservation. Chaque nœud peut encore rencontrer une condition qui empêche l’établissement. Avec Segment Routing, RFC 9256 distingue le chemin candidat, la liste de segments, l’instanciation de la SR Policy au headend et l’orientation effective du trafic. RFC 8664 transporte des informations SR par PCEP, sans transformer ce transport en preuve de programmation.

Il faut préserver la différence entre les deux familles : RSVP-TE et SR n’installent pas la même forme d’état. Elles partagent toutefois une exigence de preuve. Le résultat de calcul ne montre pas que le mécanisme d’exécution a réussi.

Le PCE stateful précise qui sait quoi

Les extensions stateful introduisent synchronisation d’état, mises à jour, délégation et initiation de LSP. Elles rapprochent le PCE de la boucle d’exploitation, mais elles n’abolissent pas le rôle du PCC.

RFC 8231 conserve au PCC la propriété de l’état du LSP. Les attributs reçus du PCE restent soumis à la politique locale du PCC. Une délégation autorise le PCE actif à mettre à jour certains attributs d’un LSP ; elle peut être retirée ou rendue. Ce droit borné n’est pas un certificat de transfert de paquets.

Le rapport PCRpt forme une preuve ultérieure. Le PCC doit signaler qu’un LSP est Up ou Active, ou qu’il est Down avec une cause si l’établissement échoue. Le RFC précise qu’il n’existe pas de corrélation directe entre PCRep et PCRpt : plusieurs états peuvent suivre une seule réponse de calcul. RFC 8281 autorise le PCE à initier un LSP, mais l’initiation reste une action de contrôle dont le résultat appartient au PCC et aux équipements.

Un reçu pour chaque couche

L’acceptation locale doit être constatée. La signalisation ou la programmation doit laisser sa trace. Les réservations nécessaires doivent être vérifiées. La RIB et la FIB doivent être lues séparément. Les compteurs, sondes et traces doivent ensuite montrer les paquets. Enfin, la perte, la latence, la gigue et la disponibilité doivent être mesurées sur une fenêtre définie pour parler de SLA.

Un PCRpt Up vaut davantage qu’un PCRep pour l’état du LSP, mais il ne décrit pas encore toute l’expérience du service. Une entrée FIB vaut davantage qu’une intention, mais elle ne prouve pas qu’un flux donné l’a utilisée. La hiérarchie ne dévalorise aucune preuve ; elle lui assigne la bonne question.

La pratique d’implémentation confirme cette lecture. La documentation PCEP de Juniper explique que le PCC re-signalise le LSP après une mise à jour et propose des commandes distinctes pour la session, les LSP, les détails SPRING-TE et les routes. Un guide de dépannage Paragon décrit même un ordre acquitté alors que le LSP reste Down, le PCC n’ayant pas réussi à le signaler. Il s’agit d’un exemple de produit, non d’une règle universelle, mais il montre bien la rupture entre acquittement et exploitation.

La contribution exacte de Farrel

Le profil IETF d’Adrian Farrel recense un travail bien plus large. Dans ce récit, son apport pertinent est partagé : avec Vasseur et Ash, il a aidé à formaliser une architecture qui rend les frontières vérifiables. Vasseur et Le Roux ont écrit le PCEP de base. Les auteurs ultérieurs, le groupe PCE, les communautés RSVP-TE et Segment Routing, les développeurs et les opérateurs ont construit les autres couches.

Attribuer le tout à Farrel serait aussi trompeur que de prendre l’ERO pour le réseau entier. Dans les deux cas, un objet visible effacerait le système coopératif qui lui donne effet.

Registre des sources