Résumé

  • RFC 9983 réserve 0x10, l'AC-Flag du TLV Extended Prefix d'OSPFv2, à une affirmation précise : le préfixe est destiné à être annoncé par plusieurs nœuds.
  • Pour parler d'un service anycast qui fonctionne, il faut des preuves séparées de configuration, de route, de choix de chemin, d'état de réplique et de résultat applicatif.

Une carte de topologie montre un préfixe répété. Le collecteur BGP-LS affiche l'AC-Flag. Une équipe peut alors écrire « anycast disponible » dans une vue de service. La phrase paraît économique; elle mélange pourtant des faits qui ne se remplacent pas.

RFC 9983, RFC IETF Standards Track publiée en mai 2026, définit l'annonce de propriété anycast pour OSPFv2. Elle attribue 0x10 au drapeau Anycast dans le registre des flags du TLV Extended Prefix. Son sens est volontairement étroit : le préfixe est destiné à être annoncé par plusieurs nœuds. Un préfixe configuré anycast doit porter le drapeau; un préfixe qui ne l'est pas doit l'effacer.

La précision est importante. Plusieurs annonces d'un même préfixe ne révèlent pas toujours une intention anycast : elles peuvent refléter une transition, une erreur ou une autre propriété de topologie. Le drapeau crée donc un fait commun que les routeurs et outils peuvent interpréter. Lorsqu'une LSA Opaque Extended Prefix est réannoncée dans une autre zone, il doit être préservé; l'intention ne doit pas être perdue au passage de zone.

Mais préserver l'intention n'est pas prouver une exécution.

La chaîne qui manque entre l'étiquette et le résultat

Il faut distinguer au moins cinq observations. La première est l'intention de configuration. La deuxième est l'annonce effectivement reçue par les routeurs. La troisième est le calcul local de route et son installation dans la FIB. La quatrième est la sélection de chemin par le trafic réel, avec ECMP, filtrage, récursion et chemin retour. La cinquième est la capacité de la réplique sélectionnée à rendre le service attendu.

Une étape peut être vraie sans que la suivante le soit. Un routeur peut annoncer correctement l'AC-Flag, tandis qu'un autre ne reçoit pas la LSA pertinente. Une route peut être calculée mais refusée par une politique locale. Une route installée peut mener, pour certains flux ECMP, à une instance dégradée. Une instance peut répondre à une sonde de transport tout en refusant la requête métier ou en servant un état ancien.

Le RFC ne promet aucune de ces couches ultérieures. Lui attribuer cette promesse est plus dangereux que reconnaître une information incomplète : cela transforme un signal de plan de contrôle en certificat de réalité opérationnelle.

La lecture de Heng Lu est éclairante sans devenir une prescription IETF. Une spécification commune minimale doit porter ce qui doit vraiment être commun. Ici, c'est l'intention de partager un préfixe entre plusieurs nœuds. Les seuils de santé, la politique de distribution, la responsabilité du service et la réussite de l'action restent des décisions locales. Elles exigent leur propre preuve, car leurs conséquences sont locales.

Quand deux drapeaux se contredisent

RFC 9983 ne laisse pas tous les états ouverts à l'interprétation. L'AC-Flag et le N-flag de RFC 7684 ne doivent pas être positionnés ensemble. Si un routeur reçoit les deux, il doit traiter cela comme une anomalie de configuration, ignorer le N-flag et devrait journaliser le conflit, sous réserve de limitation de débit.

Ce détail est un test de gouvernance de l'automatisation. Un pipeline qui transforme tous les flags en une unique valeur « métadonnées valides » efface l'état contradictoire que la norme veut conserver. Un tableau de bord qui agrège ensuite les annonces peut devenir plus affirmatif que le routeur qui les a reçues.

La bonne réaction n'est pas de déduire automatiquement une panne de service. Le RFC ne l'ordonne pas. Il faut isoler le conflit de toute conclusion positive, retrouver les sources de configuration et d'annonce, puis décider selon le contexte local. Le point de contrôle est l'intégrité de l'inférence, non une alarme spectaculaire.

Une propriété peut se propager sans devenir une autorité

Pour un préfixe annoncé plusieurs fois, RFC 9983 indique qu'au moins une annonce avec AC-Flag suffit à considérer le préfixe comme anycast; un préfixe annoncé une seule fois sans le flag reste spécifique à un nœud. Le texte recommande une gestion cohérente et une surveillance stricte des configurations obsolètes, parce que le flag prime dans l'identification de la propriété.

La représentation BGP-LS de RFC 9085 peut transporter ces flags de préfixe. Cette visibilité est précieuse pour l'inventaire. Elle n'accorde pas au consommateur BGP-LS le pouvoir de certifier le calcul d'un ingress, la FIB, la réplique choisie ou le résultat de paquet. Répéter la même déclaration dans plusieurs systèmes n'est pas une corroboration indépendante.

RFC 9983 ajoute aussi des données anycast-flag modifiables aux modèles YANG d'OSPF et de gestion du routage, RFC 9129 et RFC 8349. Le plan de gestion peut donc changer une assertion dont dépendront d'autres outils. La norme demande un transport de gestion sûr, une authentification mutuelle et cite NACM pour restreindre l'accès. Si une organisation laisse ce bit influencer une décision de sécurité ou de forwarding, elle doit pouvoir établir qui l'a écrit, sous quelle revue, dans quelle version et avec quelle règle de contradiction.

Nommer exactement ce que l'on a observé

Un dossier d'incident solide relie : la configuration approuvée et son identité de gestion; les LSAs reçues, les zones et les conflits AC/N; le calcul et l'installation de route aux ingresses pertinents; la sélection réelle de chemin; la santé de chaque réplique; enfin le résultat applicatif. Ce n'est pas une obligation de tout mesurer avant chaque alerte. C'est une discipline de vocabulaire : « AC-Flag observé » est une affirmation forte et vérifiable; « service anycast sain » ne l'est pas à partir de ce seul fait.

La distinction protège aussi l'apprentissage opérationnel. Sinon l'équipe réseau corrige le flag, l'équipe plateforme corrige un tableau, et la décision locale qui a échoué — admission de santé, chemin ECMP, identité d'instance ou logique applicative — ne laisse aucune trace.