Zusammenfassung

  • RFC 9722 transportiert eine absolute Service Carving Time (SCT) in der Ethernet-Segment-Route und koordiniert T-fähige PEs um diesen Zielzeitpunkt; ein gültiger SCT belegt nur die Erklärung des Senders.
  • Eine belastbare Aussage über synchronisierte Wiederherstellung braucht Uhr-, Empfangs-, Fähigkeits-, Timer-, DF/NDF-Programmier- und Verkehrsbelege aus derselben Wiederherstellungsgeneration.
  • „Verlustfrei“ ist ein Ergebnis auf Kundendatenebene. Es folgt weder aus einem erfolgreichen BGP-Update noch aus einer abgeschlossenen Wahl oder fehlenden Alarmen.

Ein Termin ist noch kein Übergang

Ein EVPN-PE kehrt nach einem Ausfall zurück, entdeckt seine Multihoming-Partner, addiert eine Wartefrist zu seiner lokalen Zeit und kündigt den SCT in der Ethernet Segment Route an. Damit haben die Peers einen gemeinsamen Termin für die DF-Wahl. Zu diesem Zeitpunkt kann jedoch ein ASIC noch Filter installieren, eine andere Uhr mehrere Millisekunden abweichen und ein dritter PE die Route noch nicht erhalten haben. Die Steuerungsebene kann schlüssig wirken, während Pakete verloren gehen, doppelt eintreffen oder kurz kreisen.

RFC 9722, seit Mai 2025 Standards Track, aktualisiert RFC 8584. Statt unabhängiger lokaler Timer soll ein künftiger absoluter Zeitpunkt die Wahl koordinieren. Das macht den Übergang planbar, aber weder zur verteilten Transaktion noch zur Serviceabnahme.

Zwei gefährliche Kanten bleiben. Leitet der neue DF weiter, bevor der alte stoppt, drohen Duplikate oder Schleifen. Stoppt der alte zuerst, entsteht ein Blackhole. Eine längere Entdeckungsfrist senkt das Risiko voreiligen Handelns und verlängert zugleich die Unterbrechung. RFC 9722 koordiniert das Wann; Bereitschaft misst es nicht.

Was der SCT tatsächlich enthält

Der SCT steht in einer BGP Extended Community der Ethernet Segment Route, RT-4. IANA weist der Service Carving Time den Subtype 0x0F der Transitive Opaque Extended Community zu. Der Wert ist ein verkürzter NTP-Zeitstempel: 32 Bit Sekunden und die oberen 16 Bit des Sekundenbruchteils, etwa 15 Mikrosekunden Darstellungsgranularität. Die NTP Era wird nicht übertragen.

Der wiederkehrende PE bildet SCT aus lokaler Gegenwart plus Partner-Entdeckungszeit. Ein gültiger Empfang zeigt daher nur, dass der Sender ein lokales „Jetzt“ und ein Wartefenster behauptet. Er beweist nicht die Richtigkeit seiner Uhr, gleiche Era und Abweichung aller Peers, rechtzeitige BGP-Verteilung oder abgeschlossene Hardwareprogrammierung.

Bit 3 in DF Election Capabilities ist die T-Fähigkeit. Alle PEs des Ethernet Segments müssen sie signalisieren. Wird ein nicht T-fähiger Peer erkannt, fallen die Teilnehmer sofort auf das Grundverfahren zurück und stornieren SCT-Verzögerungen. Die tatsächlich beobachtete Mitgliedschaft der jeweiligen Generation ist deshalb Beleg; eine ältere Inventarliste reicht nicht.

Empfang kann Verwerfen bedeuten

Der Empfänger vergleicht SCT mit seiner Uhr. Ein vergangener Wert wird verworfen; ebenso ein künftiger Abstand, der seinen lokalen peering timer überschreitet. In beiden Fällen gilt die Wahl des Peers als bereits erfolgt. Das begrenzt alte und ferne Angaben, lässt aber korrekt implementierte PEs bei abweichenden Uhren oder Konfigurationen unterschiedlich handeln.

Der Vorfallsdatensatz muss rohe RT-4, Empfangszeit, dekodierten SCT, lokalen Abstand, Timergrenze und Annahme- oder Verwerfungsentscheidung pro PE enthalten. „BGP-Route empfangen“ löscht den entscheidenden Zweig. Ein formal richtiger Wert kann betrieblich verworfen werden; ein angenommener Wert kann auf einer später als unzuverlässig erkannten Uhr beruhen.

Bei gleichzeitiger Wiederkehr ordnet RFC 9722 die SCTs und führt nur am größten, also spätesten SCT eine Wahl aus. Frühere Aktionen müssen storniert oder verschoben werden. Das funktioniert nur, wenn alle rechtzeitig dieselbe Kandidatenmenge sahen. Kandidaten, Reihenfolge, ersetzter Timer und Begründung des Maximums gehören ins Protokoll; der Endwert allein deckt keine verspätete Route und keinen trotz Storno ausgelösten Timer auf.

Uhrvertrauen braucht eigene Belege

RFC 5905 beschreibt NTP-Qualität mit Offset, Verzögerung, Dispersion, Jitter und Root Distance statt mit einer Lampe „synchron“. RFC 8633 empfiehlt bei genauer Zeit mindestens vier unabhängige, vielfältige Quellen und laufende Überwachung. Mehrere Quellen können denselben Fehler teilen oder durch Leap Smear auseinanderlaufen. RFC 8915 authentifiziert bei NTS Server und Austausch und schützt gegen Replay; die objektive Richtigkeit des Zeitwertes bescheinigt es nicht.

Zu einer Vertrauensaussage gehören Quellenmenge, Auswahlstatus, Offset, Root Distance, Dispersion, Jitter, Leap-Zustand, letztes Update sowie Step oder Slew im Wiederherstellungsfenster. „NTP läuft“ ist Prozessstatus, keine Obergrenze für PE-Abweichung.

RFC 9722 verwendet einen konfigurierbaren skew, standardmäßig 10 ms. Ein PE von DF zu NDF wendet NDF bei SCT − skew an; bei SCT folgt das Wahlergebnis. Das Fenster soll Überlappung vermeiden, doch seine sichere Breite hängt von Maßstab, Hardware und Uhrgenauigkeit ab. Ein Default ist keine Messung. Benötigt werden beobachtete Verteilungen von Uhrfehler, Routenverarbeitung, Wahl und Datenebenenprogrammierung.

Die Rolle muss noch in die Hardware

Der Algorithmus liefert eine Rolle. Software muss daraus Regeln je VLAN oder Ethernet Tag erzeugen, an Karten senden und deren Aktivierung bestätigen. Eine API kann vor der Tabelle antworten, Linecards können unterschiedlich lange brauchen und Hunderte Dienste können eine Queue durchlaufen statt atomar zu wechseln.

Je beanspruchtem Dienst sind mindestens vier Zeiten nötig: Wahlentscheidung, Einreichung, Hardwarebestätigung und erster beobachteter Forwarding-Zustand. Alter und neuer DF, Segment, VLAN oder Tag, Generation und Fehlerpfad gehören dazu. Ein einziges „DF konvergiert“ verbirgt Nachzügler im Blackhole oder Doppelbetrieb.

Pakete schließen die Kette. Bidirektionale Tests oder Kundentelemetrie mit Sequenzen und Zeitstempeln zählen in einem erklärten Fenster Lücken, Umordnung, Duplikate und unerwartete Pfade. Wo Schleifen möglich sind, braucht es Ein- und Ausgangssicht. Keine Beschwerde bedeutet nicht null Verlust; eine Stichprobe gilt nur für ihren Fluss, ihre Messpunkte und ihre Zeit.

Quellen

Primärquellen: RFC 9722, RFC-Editor-Eintrag, IETF Datatracker, RFC 8584, RFC 7432, RFC 5905, RFC 8633, RFC 8915 und das IANA-Register.