Résumé

  • RFC 5195 organise la découverte automatique des membres et des ports d’un VPN de couche 1 afin d’alimenter une phase ultérieure de signalisation. Une entrée découverte n’est ni une autorisation, ni une réservation, ni une connexion.
  • Dès qu’une annonce passe par des locuteurs intermédiaires, l’identité du voisin immédiat et l’autorité de l’origine deviennent deux preuves différentes. Le protocole repose alors sur une confiance transitive que l’exploitation doit rendre visible.

La chaîne de confiance cachée dans une ligne

Une table d’information des ports paraît locale. Elle se consulte sur un PE, associe un identifiant de port client à un identifiant de port fournisseur et ressemble à un inventaire maîtrisé. Mais sa ligne distante peut être le dernier état d’une chaîne que l’écran ne montre plus.

RFC 5195 sépare explicitement les informations locales des informations distantes. Les premières proviennent des ports CE rattachés au PE ou de sa configuration. Les secondes arrivent par la découverte automatique BGP. Les réunir dans une PIT facilite la signalisation, mais n’abolit pas la différence de provenance.

Le document est tout aussi précis sur la finalité. Les données découvertes sont nécessaires pour terminer la phase de signalisation. Elles permettent la résolution d’adresse et soutiennent le modèle de provisionnement par une seule extrémité. Elles ne réalisent pas, par leur seule présence, l’admission, la réservation des ressources, le brassage optique ou la vérification du trafic.

Une identité adjacente n’est pas un mandat d’origine

Pour un PE distant directement appairé, RFC 5195 recommande la protection d’authentification BGP de RFC 2385. RFC 5925 décrit ensuite une option d’authentification TCP plus générale. Ces mécanismes ont une valeur réelle : ils empêchent de traiter n’importe quelle connexion comme le voisin attendu.

La preuve s’arrête cependant au bon endroit. Elle identifie le pair qui tient la session. Elle ne certifie pas, annonce par annonce, que ce pair possède le mandat commercial ou opérationnel d’associer un CPI et un PPI au L1VPN concerné.

Lorsque le PE d’origine n’est pas le pair direct, le problème devient structurel. RFC 5195 indique que l’information peut traverser une chaîne de locuteurs BGP. Le PE local doit croire que son voisin ne reçoit que de voisins dignes de confiance, lesquels ont fait le même choix en amont. La confiance doit être transitive.

Le texte reconnaît alors la limite décisive : BGP ne permet pas de déterminer qu’un élément particulier provient d’un locuteur autorisé à annoncer précisément cet élément. Le protocole doit donc être employé dans un environnement où les relations de confiance sont adéquates, par exemple au sein d’un même fournisseur.

Cet exemple ne transforme pas l’organigramme du fournisseur en preuve. Une erreur interne d’habilitation, de rattachement ou de politique reste possible. Le périmètre rend la confiance plausible ; il ne documente pas chaque mandat.

Le Route Target trie, il ne consent pas

Les communautés Route Target limitent la circulation des informations. Les cibles d’export marquent les annonces locales ; les cibles d’import déterminent celles qu’une PIT peut accepter. Cette séparation permet d’éviter qu’un PE conserve toutes les routes de tous les L1VPN.

Une correspondance réussie prouve qu’une politique locale a sélectionné une annonce. Elle ne prouve pas que la politique était juste, que le site avait consenti au rattachement, ni que le port physique existe encore. Si une cible est mal attribuée, l’erreur traverse exactement les mécanismes prévus et acquiert l’apparence de la normalité.

Le cycle Join/Prune montre pourquoi le temps compte. Lors d’un VPN Join, une nouvelle cible d’import oblige le PE à récupérer les informations qu’il avait rejetées auparavant. RFC 5195 impose le mécanisme Route Refresh pour ce cas. Il faut donc distinguer la modification de politique, la demande de rafraîchissement, les annonces récupérées et la reconstruction de la PIT.

Lors d’un VPN Prune, les routes qui ne correspondent plus à aucune cible peuvent être supprimées. La session BGP peut rester intacte. L’absence de coupure est une propriété de continuité, pas la preuve que toutes les projections secondaires ont retiré le couple devenu obsolète.

Le nombre d’ingénierie de trafic n’est pas la capacité vendue

La découverte peut transporter une capacité de commutation et une bande passante LSP maximale afin d’aider au choix d’une sortie. Cette donnée décrit ce qu’une interface distante annonce. Elle ne dit pas nécessairement ce qui est libre maintenant, et encore moins ce qui a été réservé pour une demande donnée.

Une plate-forme commet une première promotion en renommant le maximum capacité disponible, puis une seconde en affichant la demande comme réservée. Une trace saine conserve l’auteur et l’horodatage de l’annonce, puis ajoute séparément la mesure, la décision d’admission et l’identifiant de réservation.

Plusieurs systèmes, plusieurs univers visibles

RFC 5195 autorise le partitionnement des réflecteurs de routes et même plusieurs systèmes BGP indépendants pour distribuer les données VPN. Cette architecture évite qu’un équipement doive connaître toutes les routes. Elle définit aussi des frontières d’observation.

Deux partitions peuvent produire des vues cohérentes et différentes. Le mot complet n’a donc de sens qu’avec un univers déclaré : producteurs attendus, L1VPN concernés, version de politique, état des rafraîchissements et point de rapprochement. Une PIT complète dans son périmètre ne devient pas l’inventaire global par simple présentation graphique.

Un reçu qui respecte les compétences

Le reçu minimal commence avant la PIT. Il conserve l’identité du VPN, le CPI, le PPI, la nature locale ou distante, le pair immédiat, l’origine observée, les Route Targets et la décision d’import. Il lie surtout le PE et le port à une preuve d’autorité explicite pour ce VPN.

La suite appartient à d’autres acteurs. La signalisation enregistre la requête et sa réponse. Le contrôle d’admission enregistre la décision. Le système de réservation fournit une référence. L’équipement optique atteste le brassage. Un test de continuité puis de trafic atteste le chemin utile. Les retraits et changements de politique doivent atteindre les caches consommateurs.

Ce reçu est une déduction opérationnelle, non un nouveau format imposé par RFC 5195. Il maintient chaque énoncé dans sa couche de réalité. L’annonce dit ce qui a été proclamé ; la politique dit ce qui a été admis ; la PIT dit ce qui a été projeté ; le matériel dit ce qui a été exécuté.

La discipline de Heng Lu s’applique directement : une représentation ne doit pas obtenir le pouvoir de contredire le système en fonctionnement. Le provisionnement par une seule extrémité peut rester rapide sans devenir opaque. Il suffit que l’automatisation transporte aussi la provenance, l’autorité et les reçus d’exécution qu’elle serait tentée d’effacer.

Sources

  1. RFC 5195 en HTML
  2. RFC 5195 en texte
  3. Fiche RFC 5195
  4. Datatracker IETF : RFC 5195
  5. Historique de RFC 5195
  6. Références de RFC 5195
  7. Errata de RFC 5195
  8. RFC 4847
  9. RFC 5251
  10. RFC 4760
  11. RFC 4360
  12. RFC 4684
  13. RFC 2918
  14. RFC 5291
  15. RFC 2385
  16. RFC 4271
  17. RFC 5925
  18. Heng Lu — couches de réalité et pouvoir symbolique
  19. Heng Lu — spécification initiale minimale
  20. Heng Lu — primauté du code en fonctionnement