Zusammenfassung

  • Das IESG billigte draft-ietf-bier-ping am 21. September 2026 als Proposed Standard. Revision 29 liegt beim RFC Editor; eine endgültige RFC-Nummer oder Portzuweisung wird nicht vorweggenommen.
  • Packet-Forward-Success ist die lokale Aussage des antwortenden BFER. Bei mehreren BFR-IDs im Request beweist sie nicht, dass die gesamte Zielmenge geantwortet hat.
  • Ein belastbarer Lauf gleicht den unveränderlichen Original-BitString mit jedem Ziel, Reply oder Timeout, Return Code, DDMAP, jeder Entropieklasse und dem Reply Mode ab; Produktionszustellung bleibt ein eigener Befund.

Ein Erfolg mit engem Absender

BIER weist jedem Bit-Forwarding Egress Router eine Bitposition zu. Ein BitString kann so mehrere Empfänger nennen, ohne im Kern pro Multicast-Flow einen Baumzustand zu halten. BIER Ping nutzt diese Adressierung für aktive Prüfungen der Weiterleitung.

Die IESG-Entscheidung nennt den 21. September als Genehmigungsdatum. Der Datatracker führt Revision 29 vom 19. September in der RFC-Editor-Warteschlange. Das ist ein Normungsfortschritt, aber kein Implementierungs- oder Betriebsnachweis. Bis die Redaktion und Registrierungen abgeschlossen sind, dürfen RFC-Nummer und endgültiger UDP-Port nicht erfunden werden.

Die praktische Fehlinterpretation entsteht, wenn ein Mehrziel-Request als eine grüne Kachel endet. Ein BFER darf nach erfolgreicher lokaler Verarbeitung Packet-Forward-Success melden. Die Aussage betrifft diesen BFER und diesen Probe. Ein anderer gesetzter Bit, zu dem keine Antwort kam, wird dadurch nicht erklärt.

Revision 29 benennt die Lücke: Enthält der Request mehr als eine BFR-ID, ist das Fehlen einer einzelnen ID schwer zu erkennen. Ein weiterer Request, der den nicht antwortenden BFER isoliert, kann nötig sein. Vollständigkeit entsteht aus dem Abgleich der Menge, nicht aus der Ausweitung eines positiven Codes.

Original und Target machen den Lauf zustandsbehaftet

Der Original SI-BitString hält die beabsichtigte Empfängermenge fest. Der Target SI-BitString bestimmt, wer in einem Schritt antworten soll. Nach einer Antwort kann der Initiator den entsprechenden Bit aus späteren Requests entfernen. Wer nur das letzte Paket speichert, verliert die ursprüngliche Fragestellung.

Jeder erforderliche Bit braucht deshalb eine zugeordnete Antwort oder einen expliziten Timeout. Auch ein isolierter Timeout ist noch keine Ursachenangabe. Hinweg, Zielauswahl, Parser, Control-Plane-Punt, Policer, Reply-Erzeugung und Rückweg bleiben mögliche Fehlerflächen.

Der Reply Mode begrenzt die Behauptung weiter. IP/UDP zeigt, dass die Antwort über IP zurückkam; ein BIER-Rückweg ist damit nicht geprüft. Eine BIER-Antwort kann diese Richtung testen. Beide bleiben getrennt von der Frage, ob eine Anwendung die produktive Multicast-Nutzlast empfangen hat.

Return Codes sind typisierte lokale Belege

No matching entry in the forwarding table bezeichnet einen fehlgeschlagenen lokalen Lookup. Set-Identifier Mismatch macht eine SI-Abweichung sichtbar, die Verkehr über eine falsche Subdomänengrenze tragen kann. DDMAP Mismatch zeigt eine Differenz zwischen erwarteter Downstream-Abbildung und Forwarding und begründet die Suche nach Schleifen oder Duplikaten. Packet-Forward-Success bleibt der positive lokale Fall.

Eine Speicherung als bloßes pass/fail vernichtet diese Diagnose. Code, BFR-ID, ein- und ausgehende BitStrings, Downstream-Interface, DDMAP, Label und SI gehören zusammen. Erst dann lässt sich die Control-Plane-Erwartung mit der beobachteten Weiterleitung vergleichen.

ECMP erzeugt je Ausgang eine eigene Prüfmatrix

Für BIER über MPLS muss ein Multipath-Entropy-Request genau einen BFER benennen. Die Antwort liefert eine Bitmaske der Entropiewerte für nachgelagerte Pfade. Ein Multipath-Request mit mehreren BFER ist ungültig.

Eine Antwort vom Ausgang und die Abdeckung seiner relevanten ECMP-Zweige sind daher verschiedene Aussagen. Jeder kritische BFER benötigt eine Matrix aus Entropieklassen, Läufen und beobachteten Pfaden. BFIR-id, BitString, BIFT-id, BSL, SI, Entropy und DSCP müssen zudem die behauptete Behandlung abbilden; sonst kann der Probe anders laufen als der Produktionsverkehr.

RFC 10014 strukturiert aktive OAM-Methodik, RFC 9974 die BIER-OAM-Anforderungen. Sie stärken eine saubere Messung, verwandeln aber keinen konstruierten Probe in einen Anwendungs- oder Kundennachweis.

Ein Schutzmechanismus kann wie Verlust aussehen

BIER Ping erreicht die Control Plane. Der Sicherheitsabschnitt empfiehlt deshalb Rate Limits für diesen Verkehr und den zugehörigen Port. Das schützt die Plattform, schafft aber einen weiteren Grund für ausbleibende Antworten.

Angebotene Rate, Punt- und Policer-Zähler, Parserfehler und Auslastung des Responders müssen im selben Zeitfenster erfasst werden. Andernfalls wird womöglich funktionierende Weiterleitung geändert oder ein Limit gefährlich erhöht, nur um den Test grün zu bekommen.

Heng Lus Realitätsebenen halten die Belege auseinander: Genehmigung ist Prozess, der Entwurf ist symbolische Beschreibung, Konfiguration ist Fähigkeit, ein Lauf ist Beobachtung. Produktionsverkehr und Anwendungsergebnis folgen als weitere Ebenen. BIER Ping ist stark, wenn keine Ebene für alle anderen sprechen muss.

Quellen