Résumé

  • RFC 7911 associe au préfixe un Path Identifier local de quatre octets. Plusieurs annonces du même préfixe peuvent ainsi coexister dans un sens précisément négocié.
  • L’émetteur conserve le choix de l’ensemble exposé ; le récepteur garde le filtrage, la décision de meilleur chemin, l’éventuel multipath et l’installation en FIB. L’identifiant n’est ni un rang ni une identité mondiale durable.
  • Une mise en production défendable prouve le sens par AFI/SAFI, les ensembles réellement envoyés et reçus, le coût d’état, le retrait individuel et le résultat de forwarding. Compter davantage de routes ne suffit pas.

La réflexion de routes est une compression. Au lieu d’imposer un maillage complet entre tous les routeurs iBGP, elle confie à un réflecteur la distribution de la route qu’il juge la meilleure. Le client reçoit une conclusion exploitable, mais pas nécessairement les autres possibilités qui existaient au moment de la décision.

Ce compromis fonctionne tant que la conclusion du réflecteur convient aussi au client. Il devient fragile lorsque le chemin retenu sera rejeté par la politique du client, lorsque le chemin masqué aurait survécu à une panne, ou lorsque deux emplacements n’ont pas la même vision du coût IGP. La session BGP peut être stable et la décision pourtant reposer sur une information incomplète.

Dans BGP classique, une nouvelle annonce du même NLRI venant du même voisin remplace implicitement la précédente. Le préfixe sert de clé. La session ne peut pas conserver simultanément deux versions de ce préfixe et gérer séparément leur cycle de vie sans extension.

RFC 7911 insère un identifiant de chemin de quatre octets avant le NLRI. La clé devient le couple préfixe-identifiant. Une nouvelle annonce du même couple remplace seulement cette occurrence. Un retrait du couple supprime seulement ce chemin. Un retrait portant un identifiant jamais reçu doit être ignoré et ne doit surtout pas effacer toutes les alternatives du préfixe.

Le chiffre n’est pas un nom universel. Il est attribué localement par l’émetteur pour la relation considérée. Lorsqu’un routeur réannonce un chemin, il fabrique son propre identifiant ; il ne transmet pas un jeton de provenance de bout en bout. Après un redémarrage, les nombres peuvent changer. Leur valeur ne code ni préférence, ni qualité, ni âge, ni origine.

Cette limite doit atteindre les outils d’exploitation. Une corrélation qui suit « Path ID 12 » à travers plusieurs réflecteurs fabrique une relation qui n’existe pas. Un contrôle post-redémarrage qui exige le même numéro confond continuité fonctionnelle et continuité d’un jeton local. Il faut rapprocher les attributs, le rôle attendu et le next hop, puis constater le résultat de forwarding.

La capacité ADD-PATH, code 69, est elle aussi plus précise qu’un simple état activé ou désactivé. Chaque tuple indique une AFI, une SAFI et un mode : recevoir, envoyer ou les deux. L’encodage multiple n’est valide dans un sens que si l’émetteur a annoncé « send » et le récepteur « receive » pour la même famille.

Une session peut donc transporter plusieurs chemins en IPv4 unicast dans un seul sens, tout en restant à chemin unique dans l’autre sens ou pour IPv6. Cette asymétrie est utile. Un réflecteur peut donner plusieurs options à ses clients sans devoir absorber tous leurs candidats. Dire seulement « ADD-PATH est activé » masque la véritable autorisation négociée.

La capacité autorise le transport ; elle ne choisit pas le contenu. RFC 7911 recommande d’inclure le meilleur chemin, sauf lorsqu’il a été appris du voisin destinataire, mais n’ordonne pas l’envoi de tous les chemins. Un produit peut retenir les N meilleurs, le meilleur par AS voisin, les chemins admissibles au multipath, tous les chemins éligibles ou un sous-ensemble défini par politique.

Le bénéfice réside précisément dans ce choix. Deux chemins qui convergent vers le même next hop, le même site ou le même conduit optique produisent deux objets de contrôle sans créer deux issues indépendantes. Un meilleur chemin par AS voisin accroît une forme de diversité commerciale, mais ne garantit pas deux infrastructures physiques. Le nombre d’identifiants ne mesure pas le nombre de destins de panne.

RFC 7964 expose le compromis dans le cadre plus étroit des oscillations persistantes liées au MED. L’envoi de tous les chemins disponibles rapproche les clients de la cohérence d’un maillage complet, au prix de l’état. Le modèle Group Best limite l’ensemble au meilleur chemin de chaque AS voisin sous certaines contraintes de topologie. Cette réduction répond à un mécanisme précis ; elle n’est pas une politique universelle.

Le récepteur ne perd aucune de ses compétences parce qu’il voit plus. Il peut rejeter une annonce à l’import, choisir un seul meilleur chemin, construire un groupe multipath ou garder des routes de réserve hors FIB. RFC 7911 ne remplace pas le processus de décision de RFC 4271. Il ne commande ni ECMP ni installation matérielle.

Il faut donc résister aux raccourcis de tableau de bord. Quatre chemins dans l’Adj-RIB-In ne signifient pas quatre sorties utilisables. L’un peut être filtré, l’autre avoir un next hop non résolu, et deux autres se résoudre vers la même interface. Même un Loc-RIB multipath peut être réduit par les capacités de la plateforme. La preuve traverse la politique, la décision, la récursion et la FIB.

Le « path hiding » des route servers d’IXP fournit un cas concret. Selon RFC 7947, le serveur peut choisir un chemin qui sera ensuite refusé par la politique propre à un client, tandis qu’un autre candidat présent sur le serveur aurait été accepté. Si seul le premier est annoncé, le client n’obtient aucune route. Sa politique fonctionne, mais sur un univers inutilement rétréci.

ADD-PATH peut élargir cet univers. RFC 7947 recommande néanmoins, pour ce contexte, que le route server envoie plusieurs chemins sans en recevoir des clients, lesquels reçoivent sans envoyer. Le but est d’éviter que des chemins inactifs, invalides ou sous-optimaux soient propagés par une infrastructure qui ne transporte pas elle-même les paquets. Cette recommandation décrit une frontière de confiance d’IXP, pas une règle à copier mécaniquement dans tout réseau interne.

Dans un AS, certains clients peuvent légitimement recevoir plus d’alternatives que d’autres. Un routeur de bordure doté de ressources importantes n’a pas le même besoin qu’un équipement compact. Mais une telle asymétrie doit être explicite : rôle du client, familles concernées, nombre maximal, algorithme de sélection et scénario de convergence attendu.

Le coût augmente avec chaque chemin. RFC 7911 signale le risque d’épuisement de mémoire et d’instabilité à l’échelle du réseau. Chaque occurrence ajoute de l’état RIB, des attributs, du travail de politique, des mises à jour et de la télémétrie. Lors d’une panne, un stock silencieux d’alternatives peut se transformer en vague de décisions et de retraits.

RFC 6774, qui décrit une autre méthode de distribution diverse, met en lumière la même tension : réduire la famine de chemins demande davantage de copies et de traitement. La visibilité est une dépense contrôlée. Elle doit avoir un budget, une limite d’admission et un motif opérationnel mesurable.

Les implémentations rendent ces couches visibles. Cisco sépare activation de la capacité, sélection des chemins supplémentaires et annonce. Junos distingue la configuration send/receive de l’état effectivement négocié. FRRouting propose notamment all-paths, per-AS-best et N-best, avec des limites de réception. Ce ne sont pas des garanties interconstructeurs, mais la liste des décisions qu’un dossier de changement doit documenter.

Le premier artefact de preuve est une matrice par voisin et AFI/SAFI. Elle montre les modes annoncés localement, reçus du voisin et donc effectifs dans chaque sens. Elle nomme ensuite l’algorithme côté émetteur, le plafond, les filtres d’export et la règle qui assure ou non la présence du meilleur chemin habituel.

Il faut capturer les ensembles, pas seulement les totaux. Dans l’Adj-RIB-Out : préfixe, Path Identifier local, next hop, AS_PATH, origine, MED, communautés et raison d’éligibilité. Dans l’Adj-RIB-In : objets correspondants, résultat des filtres et motif du choix. Les identifiants ne sont comparables ni entre deux émetteurs ni nécessairement avant et après un redémarrage.

Les essais de cycle de vie doivent utiliser la clé complète. Réannoncer le même couple avec de nouveaux attributs ne doit modifier que ce chemin. Retirer un identifiant doit préserver ses frères. Retirer un identifiant inconnu ne doit rien détruire. Ces tests détectent les collecteurs et automatismes qui reviennent par erreur à une identité fondée sur le seul préfixe.

Après redémarrage, on n’exige pas la stabilité du nombre. On vérifie que les anciens objets disparaissent, que les routes attendues reviennent avec des attributs cohérents et qu’aucun résidu ne survit dans la FIB. L’identité probante est la relation entre route, politique et forwarding, pas la conservation d’un entier.

La diversité doit être qualifiée par domaine de panne : next hop, AS voisin, site, carte, lien, fournisseur, conduit et dépendance de politique. Lorsque cette information est indisponible, la conclusion correcte est « diversité inconnue ». Deux jetons ne transforment pas une inconnue en redondance.

Un test de panne retire ensuite la sortie préférée. L’équipe observe si une alternative déjà reçue devient meilleure sans découverte distante supplémentaire, combien de mises à jour sont traitées, quand le next hop se résout, quand la FIB change et ce que vivent les paquets. L’essai doit inclure une alternative filtrée, une récursion cassée et un destin partagé.

Le budget de capacité appartient au contrat d’admission. Nombre maximal par préfixe et voisin, mémoire, taux d’updates, durée de conservation télémétrique et comportement en dépassement doivent être connus avant le déploiement. Jeter silencieusement des chemins arbitraires recréerait le masquage derrière un écran affichant pourtant une capacité réussie.

Le retour arrière mérite son propre scénario. La suppression de la commande doit réduire proprement l’ensemble, éliminer les identifiants obsolètes et restaurer la sémantique classique. Si une renégociation ou une réinitialisation de session est nécessaire, le risque de portée réseau fait partie de la décision initiale et ne peut être découvert au moment de l’incident.

Le principe de spécification initiale minimale de Heng Lu correspond à cette architecture. Le standard commun reste étroit : une capacité directionnelle et un discriminateur local. La composition de l’ensemble, les limites de ressources et la décision de forwarding restent locales. L’interopérabilité n’oblige pas à centraliser la politique future.

La primauté du code en fonctionnement définit la hiérarchie de preuve. La configuration exprime une intention. Le tuple négocié, l’annonce réellement transmise, la route acceptée, le motif de sélection, le next hop programmé et le paquet observé sont les faits. Si l’alternative n’atteint jamais ces étapes, elle n’est pas une option opérationnelle.

La souveraineté des données est ici une souveraineté sur la visibilité. L’émetteur décide ce qu’il expose ; le récepteur décide ce qu’il utilise. Le résultat physique dépend encore du réseau. ADD-PATH ne supprime pas cette pluralité d’autorités : il la rend inspectable, à condition de mesurer les ensembles plutôt que de célébrer une capacité.

ADD-PATH n’est donc ni une injonction à tout annoncer ni une assurance de résilience. Il empêche qu’une identité fondée uniquement sur le préfixe écrase systématiquement les alternatives d’une session. Son succès se mesure à un ensemble utile, borné, compréhensible et capable de devenir du forwarding lorsque le choix préféré disparaît.

Sources