Résumé

  • RFC 9722 transporte un Service Carving Time (SCT) absolu dans la route Ethernet Segment et coordonne les PE capables autour de cette échéance ; un SCT valide atteste seulement la déclaration de l’émetteur.
  • Une reprise dite synchronisée exige des preuves d’horloge, de réception, de capacités, de temporisateurs, de programmation DF/NDF et de trafic, toutes rattachées à la même génération de reprise.
  • L’absence de perte est un résultat du plan de données. Elle ne découle ni d’une mise à jour BGP réussie, ni d’une élection terminée, ni du silence des alarmes.

Un rendez-vous n’est pas une bascule

Un PE EVPN revient après une panne. Il découvre ses partenaires de multihoming, ajoute à son heure locale une période d’attente et annonce le SCT dans sa route Ethernet Segment. Les pairs disposent désormais d’une heure commune pour relancer l’élection DF. Pourtant, à cet instant, un ASIC peut encore charger ses filtres, une autre horloge peut être décalée de quelques millisecondes et un troisième PE peut ne pas avoir reçu la route. Le plan de contrôle peut paraître cohérent alors que des paquets sont perdus, dupliqués ou bouclés.

RFC 9722, publié sur la voie des normes en mai 2025, met à jour RFC 8584. Il remplace la course entre expirations locales par un instant absolu partagé. Cette avancée rend la transition planifiable ; elle ne la transforme ni en transaction distribuée ni en test d’acceptation du service.

Les deux bords du transfert restent dangereux. Si le nouveau DF transmet avant l’arrêt de l’ancien, des doublons ou une boucle peuvent apparaître. Si l’ancien s’arrête avant que le nouveau soit prêt, le trafic tombe dans un trou noir. Allonger le délai de découverte limite une action prématurée mais prolonge l’interruption. RFC 9722 coordonne l’heure ; il n’observe pas l’état de préparation.

Ce que contient vraiment le SCT

Le SCT figure dans une communauté étendue BGP de la route Ethernet Segment, RT-4. Le registre IANA lui attribue le sous-type 0x0F de la Transitive Opaque Extended Community. Sa valeur reprend un horodatage NTP réduit : 32 bits pour les secondes et les 16 bits de poids fort pour la fraction, soit une granularité d’environ 15 microsecondes. L’ère NTP n’est pas transmise.

Le PE en reprise calcule l’échéance avec son heure courante locale et sa période de découverte des partenaires. La réception valide donc deux affirmations : l’émetteur a déclaré son « maintenant » et une fenêtre d’attente. Elle ne prouve pas que son horloge est juste, que tous les pairs partagent la même ère ou le même décalage, que BGP arrivera à temps, ni que le matériel finira sa programmation.

Le bit 3 du champ DF Election Capabilities porte la capacité T. Tous les PE du segment doivent la déclarer. Dès qu’un pair non-T est détecté, les autres reviennent immédiatement à la procédure de base et annulent le délai SCT. La composition du groupe devient ainsi une pièce de preuve : un inventaire antérieur ne suffit pas ; il faut les capacités effectivement observées sur ce segment et pour cette génération.

Recevoir peut conduire à rejeter

Le récepteur compare le SCT à son horloge. Une valeur passée est écartée. Une valeur dont l’écart futur dépasse son peering timer local l’est aussi ; dans les deux cas, l’élection du pair est traitée comme déjà survenue. Cette borne protège contre des dates obsolètes ou très lointaines, mais deux implémentations correctes peuvent décider différemment si leurs horloges ou leurs réglages divergent.

Le dossier d’incident doit donc conserver la RT-4 brute, l’heure de réception, le SCT décodé, l’écart calculé, la borne locale et la décision d’accepter ou de rejeter, PE par PE. « Route BGP reçue » efface précisément la branche importante. Un champ peut être bien formé mais refusé, ou accepté à l’aide d’une horloge ensuite jugée peu fiable.

Les reprises simultanées ajoutent une autre bifurcation. RFC 9722 ordonne les SCT connus et ne lance qu’une élection au plus grand, donc au plus tardif. Les actions plus précoces doivent être annulées ou déplacées. Cette règle ne converge que si les participants ont vu le même ensemble à temps. Il faut enregistrer les candidats, l’ordre, le temporisateur remplacé et la raison du maximum final ; la seule heure gagnante ne révèle ni une route tardive ni un ancien temporisateur qui s’est déclenché.

La confiance temporelle a ses propres reçus

RFC 5905 décrit la qualité NTP par l’offset, le délai, la dispersion, la gigue et la distance racine, plutôt que par un voyant « synchronisé ». RFC 8633 recommande au moins quatre sources indépendantes et diverses lorsque l’heure exacte compte, ainsi qu’une surveillance continue. Plusieurs sources peuvent encore partager une panne ou diverger à cause du leap smear. RFC 8915 authentifie le serveur et l’échange NTS et protège contre le rejeu ; il ne certifie pas l’exactitude objective de l’heure.

Pour associer une confiance au SCT, il faut garder les sources, l’état de sélection, l’offset, la distance racine, la dispersion, la gigue, l’état leap, la dernière mise à jour et tout step ou slew pendant la reprise. « NTP actif » est un état de processus, pas une borne d’écart entre PE.

RFC 9722 prévoit un skew configurable, fixé par défaut à 10 ms. Un PE passant de DF à NDF applique NDF à SCT − skew, puis le résultat d’élection à SCT. Cette fenêtre cherche à éviter le chevauchement, mais sa valeur sûre dépend de l’échelle, du matériel et de la précision des horloges. Une valeur par défaut n’est pas une mesure. Il faut connaître les distributions réelles d’erreur temporelle, de traitement BGP, de calcul et de programmation.

Le rôle doit encore atteindre le silicium

L’algorithme produit un rôle. Le logiciel doit ensuite créer les règles par VLAN ou Ethernet Tag, les soumettre aux cartes et obtenir une confirmation. Un appel peut réussir avant l’activation de la table ; des cartes d’un même châssis peuvent finir à des instants différents ; des centaines de services peuvent passer par une file, sans atomicité.

Pour chaque service revendiqué, conserver quatre heures : décision d’élection, soumission, acquittement matériel et premier état de transfert observé. Ajouter ancien et nouveau DF, segment, VLAN ou tag, génération et erreur. Un unique « DF convergé » masque la longue traîne de clients encore en black-hole ou en double transfert.

Le paquet ferme la chaîne. Sur une fenêtre annoncée, une sonde bidirectionnelle ou une télémétrie client numérotée doit compter trous, réordonnancement, doublons et chemins inattendus. Lorsque la boucle est possible, il faut les points d’entrée et de sortie. Pas de plainte ne signifie pas zéro perte ; un flux échantillonné ne prouve que ce flux, ces points et cette période.

Sources

Références primaires : RFC 9722, fiche RFC Editor, IETF Datatracker, RFC 8584, RFC 7432, RFC 5905, RFC 8633, RFC 8915 et le registre IANA.