Résumé

  • RFC 5152 distribue le calcul d’un LSP TE interdomaine quand la tête ne possède pas le chemin complet.
  • Chaque ABR ou ASBR calcule la section suivante avec sa TED, sa politique, ses capacités et sa visibilité propres.
  • L’ERO peut mêler des sauts stricts et lâches, donc fixer certaines décisions et en déléguer d’autres aux frontières.
  • La sortie suivante peut être configurée ou découverte par IGP, BGP ou routage de politique ; sa joignabilité ne prouve pas sa qualité globale.
  • Un échec aval produit un PathErr ; le crankback peut essayer une autre sortie, sinon l’erreur remonte à la tête.
  • La tête peut changer la séquence lâche, retenter après soupçon de TED périmée ou relâcher une contrainte.
  • Ces actions n’ont pas le même sens et aucune ne prouve à elle seule une exploration exhaustive.
  • RFC 5152 précise que le calcul par domaine ne garantit pas le chemin interdomaine optimal.
  • Son problème de trapping montre qu’un premier chemin faisable peut empêcher de trouver un second chemin diversifié alors qu’une paire existe.
  • Une réoptimisation locale peut améliorer les sections tout en conservant la même mauvaise séquence de frontières.
  • Une autre technique, dont PCE, peut convenir aux objectifs globaux, sans devenir pour autant une garantie universelle.
  • La preuve doit relier objectif de paire, méthode, versions de topologie, choix de sorties, exclusions, essais, réservations et trafic observé.

La joignabilité ne classe pas les sorties

Lorsque le prochain saut n’apparaît pas dans la base TE locale, la frontière vérifie qu’il se trouve hors du domaine, que les hypothèses de commutation et de contrôle s’appliquent, puis qu’une route IP existe. Si l’adresse n’est pas joignable, un PathErr de type Routing Problem remonte. Sans mécanisme de découverte ni autre source de points de sortie, le calcul s’arrête.

Ce test protège une étape essentielle : ne pas envoyer le signal vers une frontière inexistante. Il ne compare pas la valeur de cette frontière pour l’ensemble du service. Une sortie peut être joignable, disposer d’un segment local admissible et néanmoins engager le premier LSP dans une combinaison qui rend la paire diversifiée introuvable.

Le registre d’exploitation doit donc séparer trois décisions : « cette sortie répond », « cette sortie satisfait le LSP courant » et « cette sortie préserve l’objectif du jeu de LSP ». Les deux premières peuvent être prouvées localement. La troisième dépend d’une vue et d’un objectif qui dépassent souvent le domaine.

Le chemin se décide pendant que le message avance

Le calcul par domaine s’applique quand la tête du LSP ne connaît pas, ou ne signale pas, tout le chemin interdomaine. Le Path transporte la destination et les nœuds jusqu’à la prochaine frontière ; il peut aussi nommer des frontières ultérieures ou des identifiants de domaine.

À chaque étape, le nœud chargé du calcul se trouve lui-même sur le LSP résultant. Il choisit une section, éventuellement une sortie, puis remet un problème déjà transformé au domaine suivant. Si un AS contient plusieurs aires ou sous-AS, la même délégation peut se répéter récursivement.

Cette construction protège la topologie privée. Elle rend aussi l’ordre causal. Le premier choix n’est pas une simple recommandation que l’on pourra neutraliser plus tard : il consomme des ressources et réduit l’ensemble des compositions encore disponibles.

L’ERO distribue le droit de choisir

Un ERO peut contenir un chemin strict complet, un chemin strict dans le domaine source suivi de frontières, la liste des frontières ou seulement la frontière courante et la destination. Les sauts stricts et lâches peuvent cohabiter dans le même objet.

Un saut strict applique les procédures RSVP-TE ordinaires. Un saut lâche ou un nœud abstrait représentant plusieurs LSR oblige la frontière à développer le chemin selon ses informations locales et RFC 5151. L’opérateur peut ainsi contrôler précisément un territoire visible et déléguer les parties qui ne le sont pas.

L’ERO final prouve quelle description a été acceptée. Il ne constitue pas le journal des branches écartées. Sans la liste des sorties candidates, l’algorithme, la version de TED et l’objectif employé, il est impossible de savoir si la sortie retenue était seulement faisable ou si elle protégeait vraiment la diversité future.

Le piège se révèle au deuxième calcul

RFC 5152 dessine quatre points. Le calcul sériel choisit d’abord A-B-C-D. Ensuite, aucun chemin ne peut être diversifié par rapport à cette référence. Pourtant A-C-D et A-B-D forment ensemble une paire diversifiée.

Le premier chemin n’est pas invalide. C’est même ce qui rend l’exemple important. Un contrôleur peut produire une série de reçus positifs — lien disponible, contrainte respectée, réservation établie, destination atteinte — tout en ayant détruit la solution du problème réellement acheté.

« Aucun second chemin n’a été trouvé » signifie donc : aucun chemin satisfaisant les exclusions dérivées de ce premier chemin n’a été trouvé dans la vue et par la méthode utilisées. La phrase ne signifie pas que la topologie ne possède aucune paire. Supprimer ce conditionnel transforme un résultat algorithmique en fausse vérité physique.

Crankback ouvre une branche, pas tout l’arbre

Une frontière aval incapable de satisfaire les contraintes renvoie PathErr. Si le crankback est autorisé et activé, la frontière précédente peut sélectionner un autre egress. Sinon, elle abandonne et fait remonter l’erreur à la tête.

La tête peut disposer d’une autre séquence de sauts lâches. Elle peut aussi retenter la même séquence si elle soupçonne une base IGP-TE périmée, ou relâcher une contrainte. Un succès après chacune de ces actions possède une portée différente : autre branche locale, état devenu plus récent, ou service redéfini.

Pour garder la décision intelligible, chaque tentative doit conserver l’objectif inchangé ou déclarer sa modification. Un « succès » obtenu après réduction de bande passante ou abandon d’une exclusion ne répare pas l’échec de la demande originale. Un crankback réussi ne prouve pas non plus que toutes les autres combinaisons ont été comparées.

La diversité doit être calculée comme relation

La diversité nomme ce que deux chemins ne doivent pas partager : liens, nœuds, sites, SRLG ou domaines. Elle n’est pas une propriété autonome du tunnel de secours. Elle existe dans la relation entre une paire et un ensemble de risques.

Si le contrat demande une paire, le problème doit être formulé avant de choisir le premier chemin. « Meilleur LSP individuel puis tout chemin disjoint » n’équivaut pas à « meilleure paire diversifiée ». L’exemple A-B-C-D en est une preuve compacte.

Le RFC autorise le fournisseur à sélectionner une méthode par LSP et cite les calculs PCE lorsque l’optimalité ou des chemins diversifiés l’exigent. Cette orientation ne dispense pas de qualifier le résultat. Un PCE ne peut exploiter que les graphes, contraintes et informations qu’il reçoit ; il faut encore enregistrer sa portée et non brandir son nom comme preuve.

Une réoptimisation locale peut conserver le mauvais cadre

Pour un LSP contigu, la tête contrôle le make-before-break ; une notification RFC 4736 peut lui signaler une route aval meilleure. Pour un LSP stitched ou nested, chaque domaine peut réoptimiser localement son S-LSP ou H-LSP, avec des critères et fréquences différents, parfois sans signalisation interdomaine supplémentaire.

Si l’opérateur refuse cette transparence pour certains LSP, les événements doivent être signalés à la tête selon une politique configurable. Cette visibilité est utile, mais elle ne change pas automatiquement les frontières.

Quand celles-ci restent des sauts lâches fixés, chaque domaine peut réduire son coût intérieur tandis que le LSP conserve la même séquence interdomaine. La route devient meilleure à l’intérieur du cadre qui l’a piégée. Le reçu doit donc préciser si l’action a modifié un segment, le choix des frontières ou la composition globale de la paire.

Préserver la confidentialité sans inventer un optimum

Le mécanisme n’augmente pas les informations topologiques échangées entre AS. Chaque administration conserve son graphe et calcule sa portion. Ce compromis respecte l’autonomie et limite l’exposition.

Les frontières qui calculent deviennent néanmoins une surface d’attaque. Il faut pouvoir rejeter une expansion ERO non autorisée, appliquer les contrats de bande passante et de priorité, limiter les requêtes et erreurs, filtrer les messages sortants et coordonner l’authentification RSVP. Une protection FRR peut élargir le groupe qui partage les clés.

Ces mesures prouvent l’identité et la permission du travail effectué. Elles ne prouvent pas que toutes les sorties utiles ont été comparées, qu’une paire impossible l’est physiquement, que la protection a commuté ou que le trafic client a été livré.

Sources

  1. RFC 5152, HTML
  2. RFC 5152, texte
  3. Fiche RFC Editor
  4. Fiche IETF Datatracker
  5. Historique RFC 5152
  6. Références RFC 5152
  7. Errata RFC 5152
  8. RFC 3209
  9. RFC 3473
  10. RFC 5151
  11. RFC 5150
  12. RFC 4920
  13. RFC 4655
  14. RFC 4726
  15. RFC 4105
  16. RFC 4216
  17. RFC 4736
  18. RFC 2747
  19. RFC 3097
  20. RFC 3630
  21. RFC 4203
  22. RFC 4205
  23. RFC 6805
  24. RFC 8694
  25. Minimum Initial Specification
  26. On Reality Layers
  27. Running-Code Primacy