Résumé

  • La RFC 7911 permet d’annoncer plusieurs chemins pour un préfixe en ajoutant à chaque NLRI un identifiant sur quatre octets, après négociation compatible d’envoi et de réception pour la famille concernée.
  • L’identifiant est opaque et local, jamais un signal de préférence. La visibilité augmente, mais le récepteur garde la décision de meilleur chemin et assume davantage de mémoire, de traitement et de complexité au redémarrage.

Un chemin était à la fois une réponse et une limite

Dans le BGP de base, un voisin reçoit au plus une route annoncée pour une NLRI. Une nouvelle annonce du même préfixe remplace implicitement l’ancienne. Ce modèle simplifie l’échange, mais lie aussi la visibilité au choix de l’émetteur : le récepteur ne peut exploiter une alternative qui ne lui a jamais été transmise.

ADD-PATH sépare ces deux fonctions. Dans l’UPDATE étendu, un identifiant de chemin sur quatre octets précède la NLRI. Le couple préfixe-identifiant désigne une annonce précise ; plusieurs chemins du même préfixe peuvent donc coexister. Une nouvelle annonce portant le même couple remplace ce chemin, et un retrait supprime ce couple. Le retrait d’un identifiant jamais annoncé doit être ignoré silencieusement.

L’identifiant reste volontairement modeste. Il est attribué par l’émetteur et n’a de sens que dans cette relation avec ce voisin. Si la route est réannoncée, le nouvel émetteur doit créer son propre identifiant. Le récepteur ne peut déduire qu’un nombre plus grand serait meilleur, plus ancien, plus sûr ou stable globalement. Il s’agit d’identité, non de jugement.

La décision demeure locale. L’émetteur choisit les alternatives qu’il expose selon sa politique ; le récepteur applique toujours sa propre sélection. La RFC recommande d’inclure la meilleure route de l’émetteur parmi les chemins multiples, sauf si elle vient du même voisin. Même alors, « meilleure » décrit un résultat local, pas une instruction adressée au pair.

Une autorisation asymétrique et propre à chaque famille

ADD-PATH utilise le code de capacité 69. Sa valeur contient un ou plusieurs triplets AFI, SAFI et Send/Receive. La valeur 1 signifie recevoir, 2 envoyer et 3 les deux ; les autres valeurs sont considérées comme non comprises.

Un locuteur ne peut envoyer plusieurs chemins pour une famille que s’il a annoncé la capacité d’envoi et reçu du voisin la capacité de réception pour le même couple AFI/SAFI. L’autre sens peut être différent. L’autorisation n’est donc ni un bouton global de session, ni une simple supposition tirée du logiciel : elle est l’intersection explicite du pair, du sens et de la famille.

Le pouvoir et le bénéficiaire sont ainsi distincts. L’émetteur peut exposer davantage d’alternatives. Le récepteur reçoit une information qu’il peut employer pour la convergence ou la diversité des réflecteurs de routes. Mais il supporte aussi une part du coût : chaque chemin accepté consomme de l’état et du calcul, et un pair qui envoie beaucoup de chemins pour beaucoup de préfixes peut créer une pression sur les ressources.

La norme n’impose ni nombre universel de chemins ni budget mémoire. Une négociation réussie autorise le codage ; elle ne prouve pas que la politique, l’installation dans le plan de transfert ou la reprise après incident sont correctes.

L’identité locale complique la preuve après redémarrage

Les identifiants ne doivent pas nécessairement survivre au redémarrage du plan de contrôle. Cette propriété correspond à leur portée locale, mais interdit d’assimiler automatiquement l’identifiant observé avant et après le redémarrage. Avec Graceful Restart, l’enjeu devient concret : l’état de transfert peut rester en place pendant que les annonces et les identifiants sont reconstruits.

La télémétrie doit aussi conserver le contexte de capacité. Les mêmes octets d’UPDATE se décodent différemment selon qu’ADD-PATH a été négocié pour la famille. Un analyseur passif qui n’a pas vu l’OPEN peut prendre l’identifiant pour une partie de la NLRI et produire une interprétation fausse mais assurée.

RFC 7911 définit le codage, les directions, les remplacements, les retraits et les risques de ressources. RFC 4271 fournit le modèle de base ; RFC 5492 le cadre de capacités ; l’IANA enregistre le code 69 ; RFC 4272 décrit les risques BGP sous-jacents. La lecture en termes de pouvoir, de bénéficiaire et de coût relève de l’analyse.

Les sources ne prouvent le déploiement par aucun opérateur nommé, ne prescrivent pas le nombre de chemins à recevoir et ne fixent aucun seuil universel de sécurité. Elles ne rendent pas les identifiants persistants ou globaux, et ne garantissent pas que plus d’alternatives améliorent toute topologie.

Sources