Résumé
- RFC 9856 propose deux lieux de suppression : en amont avec Warm Standby, ou près des récepteurs avec Hot Standby.
- Un Single Flow Group est une déclaration configurée et signalée. Il ne compare pas le contenu, les horloges, les séquences ou l’état applicatif des sources.
- Une preuve exploitable doit distinguer l’équivalence déclarée, l’autorité de suppression, la source réellement acceptée, l’état BGP, l’expérience des récepteurs, la durée de bascule et le retour arrière.
L’absence de doublon à l’écran est une bonne nouvelle, mais c’est une preuve étroite. Elle dit qu’à cet instant ce récepteur a accepté une copie. Elle ne dit pas pourquoi deux sources ont été jugées interchangeables, si tous les récepteurs ont fait le même choix, ni ce qui s’est passé pendant la bascule.
RFC 9856, publié comme norme IETF en septembre 2025, complète les mécanismes multicast EVPN de RFC 9251 et RFC 9625. Son problème est précis : plusieurs sources alimentent un même domaine locataire avec un flux IP multicast supposé identique et les récepteurs ne doivent pas recevoir de paquets en double. Le texte fournit une classification commune et deux méthodes de suppression. Cette précision est sa force; elle marque aussi la limite de ce qu’il prouve.
Le SFG nomme une intention commune
Le Single Flow Group, ou SFG, peut prendre la forme (*,G), qui regroupe toute source envoyant vers le groupe G, ou (S,G), où S peut être un préfixe de longueur quelconque. Le bit SFG de la communauté étendue Multicast Flags indique qu’une route S-PMSI A-D transporte cette sémantique.
Rien dans cette indication ne compare les charges utiles. Le RFC suppose des sources redondantes non rafaleuses et transmettant le même flux; il ne définit ni test de séquence, ni alignement d’horloge, ni validation du codec, ni identité de génération applicative. Deux flux peuvent donc appartenir au même SFG tout en divergeant dans le contenu utile. Le réseau sait alors quoi filtrer, mais il ne sait pas si son choix est le bon pour le service.
La première pièce d’une preuve ne devrait donc pas être la route BGP. Elle devrait être la règle d’équivalence : quelles sources, quelle fenêtre d’observation, quelles tolérances de temps et de séquence, quel contrôle de fraîcheur, et quel responsable applicatif accepte le résultat. Le signalement SFG vient ensuite, comme traduction réseau d’une décision déjà explicite.
Warm Standby : une autorité concentrée en amont
En Warm Standby, les PE reliés aux sources élisent un Single Forwarder. Les PE qui ne sont pas SF rejettent les paquets du SFG reçus sur leurs circuits d’attachement locaux. Le SF n’en transmet qu’un seul; s’il reçoit le SFG sur plusieurs circuits locaux, son choix relève de l’implémentation locale.
L’élection réutilise le cadre DF de RFC 8584. Une préférence peut désigner le PE favori et, en cas de divergence d’algorithme ou de capacité, RFC 9856 prévoit le plus petit identifiant IP de PE comme départage. C’est un moyen déterministe de décider. Ce n’est pas une mesure de qualité du flux choisi.
La route S-PMSI A-D apparaît à l’arrivée du premier paquet du SFG configuré et disparaît lorsque le trafic cesse. Un temporisateur d’inactivité est recommandé, sans valeur universelle imposée. Lorsqu’un SF tombe et que la route est retirée, un autre PE peut prendre le rôle. La duplication est arrêtée près des sources, ce qui économise la bande passante du réseau locataire; le RFC reconnaît en contrepartie une bascule plus lente que Hot Standby.
Le dossier d’exploitation doit conserver ce que le contrôle commun ne dit pas : le circuit effectivement retenu par le SF, la valeur du temporisateur, l’heure de détection, la réception du retrait, la nouvelle élection et le premier paquet utile observé. Le texte ne promet ni zéro perte, ni délai maximal universel, ni validation récepteur par récepteur.
Hot Standby : plusieurs décisions proches des récepteurs
Hot Standby transporte les copies redondantes à travers le réseau locataire. Chaque source est associée à un Ethernet Segment, y compris une source à rattachement unique. Les paquets portent un label lié au S-ESI; chaque PE aval accepte son S-ESI primaire et rejette les autres.
Ce placement peut accélérer la réaction locale, mais consomme davantage de bande passante et d’état de contrôle. En outre, l’annonce S-PMSI A-D est déclenchée par la configuration du SFG, pas par la réception de trafic. Une route présente prouve donc une configuration signalée, pas l’arrivée d’un contenu utile. Un BFD multipoint peut surveiller les tunnels de transport, mais il ne contrôle ni l’encodeur, ni l’horloge, ni l’intégrité sémantique du programme.
Surtout, chaque PE aval applique sa propre politique de choix. Le RFC autorise explicitement des S-ESI primaires différents selon les PE. Il peut ainsi n’exister aucune source physique active à l’échelle globale, même si chaque récepteur ne reçoit qu’une copie. Un inventaire qui ne conserverait qu’un champ « source active » effacerait cette topologie réelle de décision.
Le retrait de la dernière route A-D per-EVI ou per-ES pertinente conduit un PE aval à changer de primaire. Le retrait massif d’un ES partagé peut toucher plusieurs domaines locataires. Lorsque la dernière route S-PMSI A-D d’un SFG disparaît, le contrôle RPF fondé sur le label S-ESI doit être retiré. Ce changement de filtre est un événement observable, pas une garantie de continuité.
Une quittance en sept champs
Une quittance de redondance utile n’ajoute pas un protocole. Elle relie sept catégories de preuves sans les confondre :
- Base d’équivalence : locataire, expression SFG, inventaire des sources, méthode de comparaison du contenu, des séquences et du temps, tolérances, échantillon et propriétaire applicatif.
- Autorité de suppression : mode warm ou hot, lieu de décision, identifiant de l’élection ou de la politique locale, version de configuration et capacités disponibles.
- État de la source active : PE SF et circuit choisi en Warm Standby; S-ESI primaire pour chaque PE aval pertinent en Hot Standby.
- Signalisation BGP : routes S-PMSI A-D et A-D per-ES/EVI, RT, bit SFG, préférence DF, labels ESI/DCB et génération des retraits vus par chaque décideur.
- Observation des récepteurs : source ou label accepté, compteurs, trous, doublons, réordonnancement, fraîcheur applicative et échantillon respectueux de la vie privée.
- Chronologie de bascule : déclencheur, détection, arrivée du retrait, nouvelle élection ou nouveau S-ESI, dernier ancien paquet, premier nouveau paquet et intervalle mesuré de perte ou de duplication.
- Retour arrière : choix précédent, configuration réversible, autorité de restauration, critères d’abandon, motif de clôture et dette restante.
Cette quittance est une proposition d’exploitation de Daniel Kade, pas un champ défini par RFC 9856 ni un certificat IETF. Elle maintient simplement chaque preuve dans son domaine. Une route décrit un état de contrôle. Un label décrit une règle de filtrage. Un échantillon de récepteurs décrit un résultat observé. Un test applicatif décrit l’équivalence.
Préserver la limite utile de la norme
RFC 9856 n’exige pas qu’une implémentation prenne en charge les deux modes. Un parc hétérogène doit donc documenter son intersection réelle de capacités. De même, les allocations IANA des bits SFG et ESI-DCB créent un vocabulaire partagé; elles ne prouvent ni le support d’un équipement, ni la propagation d’une route, ni la programmation d’un filtre.
Chercher à faire prouver l’application par le protocole serait une erreur. Accepter l’absence de preuve parce que le protocole reste volontairement étroit en serait une autre. La bonne gouvernance consiste à conserver la spécification minimale commune, puis à lui attacher les faits locaux dont dépend le service.
Une copie nette devient alors un résultat vérifiable : les sources ont été comparées selon une règle connue; l’autorité de sélection est identifiée; le plan de contrôle et les filtres sont enregistrés; les récepteurs ont été observés; la durée et les pertes ont été mesurées; une voie de retour existe. Sans cet enchaînement, la sérénité du récepteur ne prouve que la suppression.
Sources
- RFC 9856 — Multicast Source Redundancy in EVPNs
- RFC 9625 — Optimized Inter-Subnet Multicast in EVPN
- RFC 9251 — EVPN Optimized Ingress Replication
- RFC 8584 — Extensibilité de l’élection DF EVPN
- RFC 9572 — Mises à jour des procédures BUM EVPN
- RFC 9573 — Extensions multi-attachement EVPN
- RFC 9746 — Filtrage split-horizon EVPN
- RFC 9780 — Procédures BFD pour la redondance de source multicast
- RFC 7432 — Architecture Ethernet VPN
- Registre IANA des communautés étendues BGP
- Statut de RFC 9856
- Recherche d’errata RFC 9856
- RFC 3935 — Mission de l’IETF
- Minimum Initial Specification — Lu Heng
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
