Résumé

  • Les algorithmes Highest-Preference et Lowest-Preference du RFC 9785 choisissent un ordre administratif parmi des candidats supposés déjà prêts.
  • L’éligibilité, la préférence annoncée, l’élection, la programmation BUM ou unicast, la convergence et l’expérience du client restent des preuves distinctes.
  • Le mode Don't Preempt évite un retour automatique potentiellement perturbateur, mais peut conserver un DF qui n’est plus le premier choix administratif.

L’élection ne fabrique pas la disponibilité

Le rôle du Designated Forwarder est concret. Selon le RFC 7432, il expédie le trafic broadcast, unknown unicast et multicast vers le segment multihomé en mode All-Active ; en Single-Active, il porte aussi l’unicast. Le RFC 8584 sépare la découverte des PE, la constitution de la liste des candidats et le calcul du gagnant.

Le RFC 9785 ajoute deux choix dirigés par l’opérateur. L’algorithme 2 préfère la valeur numérique la plus élevée ; l’algorithme 3, la plus faible. La préférence occupe deux octets, de 0 à 65535, avec 32767 par défaut. Le registre IANA fixe ces valeurs et le bit D de Don't Preempt.

Ce mécanisme répond à un besoin réel : préparer une maintenance sans reconfigurer tous les PE, ou faire varier la priorité selon une politique locale. Pourtant, la formulation normative est essentielle. L’ordre s’applique aux candidats « assuming they are all operationally ready ». La disponibilité est donc une condition d’entrée. Elle ne sort pas du champ Preference.

Une annonce à 500 ne vérifie pas l’Attachment Circuit, la table de commutation, les files de sortie ou le chemin du client. Elle classe un PE qui a déjà franchi les conditions de candidature. Confondre ces deux étapes revient à faire de l’intention de gestion une sonde de trafic.

Une liste de candidats a sa propre histoire

Avec AC-DF, un PE n’entre pas dans le calcul avant la réception de ses routes Ethernet A-D per ES et per EVI. Cette discipline du RFC 8584 évite qu’un port logique absent soit choisi seulement parce que l’ES route existe. Elle reste toutefois une preuve BGP : la réception des routes n’atteste pas que la programmation matérielle ou logicielle a terminé.

Les algorithmes doivent aussi être cohérents. Si les PE d’un même segment mélangent Highest-Preference et Lowest-Preference, le système revient à l’algorithme par défaut du RFC 7432. Un rapport d’exploitation doit donc conserver l’ensemble des algorithmes reçus, et pas seulement le nom du DF final.

Le même principe vaut pour les overrides par plage d’Ethernet Tags. Ils peuvent répartir les Tags entre deux DF, mais la politique doit être identique sur chaque PE. Le RFC avertit qu’une divergence peut produire des pertes ou des duplications. La préférence n’est utile que dans un calcul partagé dont les participants et les règles sont connus.

La non-réversion crée deux préférences légitimes

Le cas intéressant survient après une panne. Le PE préféré tombe, un second devient DF, puis le premier revient. Une réversion immédiate déclenche un deuxième déplacement de trafic. Le RFC 9785 décrit Don't Preempt pour l’éviter.

Après un boot-timer ou hold-timer, le PE revenu collecte les ES routes et choisit un PE de référence. Si sa préférence administrative le ferait reprendre le rôle, il peut annoncer une préférence opérationnelle « in-use » héritée du titulaire, avec DP=0. Le titulaire conserve DP=1 et gagne le départage à valeur égale.

Il ne s’agit pas d’une anomalie de configuration. La préférence administrative exprime l’ordre souhaité ; la préférence annoncée peut préserver l’état courant. Les deux doivent apparaître dans la preuve. Sinon, un outil de conformité corrigera peut-être précisément le décalage que le mode non révertif avait créé pour éviter une coupure.

Le bénéfice n’est pas gratuit. On supprime une transition de retour, donc une occasion de perte et de churn. En échange, le réseau peut maintenir comme DF un PE qui n’est plus le meilleur choix administratif. Une panne ultérieure du PE de référence, un retrait de route, une modification volontaire de préférence ou un conflit d’algorithme relance la décision.

Le pouvoir de choisir doit être attribuable

La section sécurité du RFC 9785 rappelle qu’une préférence configurable donne un contrôle direct sur le trafic passant par un PE. Un acteur ayant accès à la configuration peut modifier ce chemin. Il peut aussi annoncer un algorithme conflictuel, imposer le fallback et désactiver en pratique la non-réversion.

Le contrôle doit donc être traité comme une chaîne : identité de l’auteur, valeur administrative, valeur opérationnelle annoncée, état DP, cohérence de l’algorithme, candidature, résultat par Tag, programmation de sortie et observation du trafic. Une seule ligne « DF élu » ne suffit pas.

Le RFC 9784 étend l’applicabilité aux segments Ethernet virtuels. Son propre partage entre panne d’EVC et panne d’ENNI, ses vESI et ses retraits groupés ne sont pas l’objet de ce texte. Ici, la question reste celle de l’autorité exacte d’une préférence.

La fiche RFC Editor, le Datatracker et la recherche d’errata, sans résultat correspondant lors de la vérification, établissent le dossier du standard. Ils ne prouvent ni adoption ni performance réelle.