Résumé

  • Selon la révision 34, un pair compatible qui reçoit une disponibilité physique de site de 0% doit rendre inéligibles au transfert toutes les routes associées au Site-ID, avec l'effet d'un retrait route par route mais sans émettre tous ces retraits.
  • Les routes peuvent rester valides dans BGP ordinaire. Il faut donc rapprocher l'origine du message, la génération des correspondances, les décisions de chaque routeur et les flux réels avant de conclure à l'indisponibilité du service.

À 9 h 14, le dernier serveur exploitable d'un site de périphérie disparaît. Le routeur de sortie envoie un unique UPDATE BGP avec un Site-ID et une disponibilité physique égale à zéro. Sur le routeur d'entrée, plusieurs dizaines de préfixes restent visibles dans la table BGP. Ils cessent pourtant d'être choisis pour le transfert tenant compte des métadonnées. Pour l'équipe de routage, les chemins existent encore ; pour le service, le site vient de s'effacer.

C'est la tension centrale de la révision 34 de BGP Extension for 5G Edge Service Metadata. Acceptée le 25 septembre 2026, avec une page de garde datée du 23 septembre, elle demeure un Internet-Draft du groupe IDR au stade I-D Exists. La page de garde vise Standards Track, alors que le champ correspondant du Datatracker est vide. Aucun shepherd, Area Director responsable ou telechat n'est indiqué ; une étape de juillet 2027 vise la dernière lecture du groupe. Ce n'est ni un RFC, ni un code IANA attribué, ni la preuve d'une implémentation ou d'un déploiement.

Une instruction brève, une portée héritée

Le texte définit un attribut Edge Metadata optionnel et non transitif. Une annonce de route peut associer un préfixe de service à un Site-ID sur 16 bits. Une annonce autonome transmet ensuite une propriété dynamique du site sans répéter l'information sur chaque route. Dans cette forme, le NLRI correspond à l'adresse de bouclage du routeur de sortie, RouteFlag-I vaut zéro et la valeur s'applique aux routes déjà associées. Lorsque RouteFlag-I vaut un, le message construit l'association et le pourcentage n'est pas interprété comme une mesure de disponibilité.

La révision 34 rend le cas zéro explicite : un locuteur compatible traite toutes les routes associées comme indisponibles pour le transfert. Le résultat est décrit comme équivalent à leur retrait individuel, sans envoyer chaque withdrawal. Pour un pair qui ne prend pas en charge les métadonnées, les retraits BGP ordinaires restent nécessaires.

Le mot « équivalent » concerne donc l'effet au sein du mécanisme, non l'identité des états. Ailleurs, le projet prévoit qu'une route écartée de la sélection par métadonnées puisse rester valable pour la joignabilité BGP ordinaire. Le préfixe demeure dans le RIB tout en étant exclu d'une catégorie de trafic. Cette séparation évite du churn et distingue santé du service et portée réseau. Elle rend aussi insuffisantes deux observations familières : la session est verte et le préfixe est présent.

Zéro ne contient pas sa propre liste de cibles

L'annonce autonome ne transporte pas la liste des préfixes touchés. Sa portée résulte de l'historique des associations route–Site-ID chez le destinataire. Si un ingress a rattaché 42 routes au Site-ID 711 et un autre seulement 41 après avoir manqué une annonce, tous deux peuvent appliquer correctement la même valeur nulle à des ensembles différents.

Un journal exploitable doit donc aller plus loin que « Site-ID 711 reçu à zéro ». Il faut une génération de correspondance : clés de routes, date d'effet, origine, décisions ayant acquitté cette génération. Un nombre de cibles et une empreinte permettent de comparer population attendue et population réellement résolue, sans imposer au protocole de publier chaque choix interne.

Cette génération, l'acquittement et l'empreinte sont des recommandations d'exploitation de cet article, pas des obligations de la révision 34. Le projet fixe un comportement de protocole, pas un système de reçus pour toute une flotte. La doctrine de spécification minimale autorise des journaux locaux, de la télémétrie ou un contrôleur différent chez chaque opérateur. Elle n'autorise pas l'ambiguïté sur l'objet auquel la commande devait s'appliquer.

L'autorisation d'origine protège contre un arrêt à distance

Le destinataire ne doit accepter l'annonce autonome que du routeur de sortie correspondant, ou d'un route reflector autorisé dont l'Originator-ID désigne ce routeur. Cette règle ferme une surface évidente : une valeur zéro forgée peut retirer du service toutes les routes associées et provoquer un déni de service.

La validité de la session BGP ne prouve pas cette autorisation. Un reflector peut être un voisin légitime tout en portant un Originator-ID inattendu. La bouclage de l'egress peut être joignable alors que la session n'a pas le rôle prévu. Le reçu devrait conserver le pair authentifié, l'AFI/SAFI, la capacité Edge Metadata négociée, l'identité de l'egress, l'Originator-ID éventuel, le Site-ID, les octets de l'attribut et le verdict de politique.

La capacité est bilatérale pour chaque AFI/SAFI. L'attribut reste optionnel et non transitif. Le projet propose NO_ADVERTISE, un sous-TLV AS-Scope et le filtrage habituel pour borner la diffusion. Les sous-TLV inconnus sont ignorés ; une valeur absente ne doit jamais devenir zéro par défaut. Ces limites réduisent la propagation involontaire. Elles ne prouvent pas que chaque ingress visé a négocié la capacité, ni que les pairs incompatibles ont reçu les retraits classiques dont ils dépendent.

Mesurer, annoncer et appliquer sont trois événements

La disponibilité physique est un pourcentage de zéro à 100 ; une valeur hors plage est ignorée. Le projet sépare l'intervalle de mesure de l'intervalle d'annonce et recommande, sauf configuration contraire, au moins 30 secondes entre annonces, avec amortissement ou hystérésis. L'affinité des flux reste propre à l'implémentation : un flux déjà attaché à une sortie peut y demeurer jusqu'à ce qu'elle devienne effectivement injoignable.

La chronologie compte. Le site mesure zéro à 9:14:00, l'egress l'annonce à 9:14:12, un ingress l'applique à 9:14:13, tandis qu'un flux persistant se termine à 9:15. Parler d'un seul « événement zéro » masque la latence entre vérité mesurée, contrôle distribué et expérience utilisateur.

L'annonce autonome ne sert pas non plus à résoudre le next hop. Elle modifie l'éligibilité du site ; elle ne dit pas que la bouclage de l'egress est tombée ni qu'une convergence BGP a eu lieu. La chaîne probante doit séparer mesure, origine autorisée, génération de correspondance, capacité, réception, résolution de la population, politique locale, RIB, FIB, traitement des flux et résultat de service.

Une norme étroite, des reçus précis

Les notes de Heng Lu proposent de normaliser le minimum qui permet l'action coordonnée tout en gardant les décisions futures et locales là où elles appartiennent. Ici, ce minimum peut couvrir l'identité du site, le sens de la disponibilité, l'origine acceptable et la portée. L'algorithme de mesure et le classement peuvent rester locaux. La primauté du code en fonctionnement impose ensuite de montrer le point où cette signification devient décision de transfert.

Pour un déploiement, exigeons un identifiant de génération, le nombre et l'empreinte des routes touchées, un reçu d'application par point de décision et un flux canari autour du passage à zéro. Il s'agit de contrôles proposés, non de texte du draft. Ils renforcent la preuve sans transformer une spécification initiale en architecture de contrôle centralisée.

La valeur zéro devient plus puissante parce qu'elle remplace une série de retraits. Cette économie de messages exige davantage de discipline probante. Le RIB peut dire vrai, le moteur de métadonnées aussi, et l'utilisateur vivre encore autre chose. La confiance commence lorsque ces trois récits peuvent être rapprochés.

Sources