Summary

  • Am 21. September billigte die IESG draft-ietf-bier-ping-29 als Proposed Standard. Ein veröffentlichter RFC ist das noch nicht.
  • Eine Echo Request für einen überwachten Datenstrom muss dessen BIFT-id, BSL, Entropy und DSCP übernehmen. Der hier definierte Traceroute-Modus gilt nur für BIER über MPLS; Ping ist nicht so beschränkt.
  • Bei der Prüfung am 24. September arbeitete IANA noch an den Zuweisungen, während der RFC Editor auf Angaben der Autoren wartete. Der Implementierungshinweis der IESG betrifft nur nicht näher bezeichnete Teile.

BIER bezeichnet mit einem Bitstring die Ausgangsrouter, zu denen ein Multicast-Paket gelangen soll. Zwischenrouter müssen dafür keinen Multicast-Zustand je Datenstrom führen. Für die Fehlersuche bedeutet das jedoch: Eine Antwort von einem Ausgang ist kein Befund für alle im Bitstring gesetzten Ziele. Das neue OAM-Verfahren soll Störungen im BIER-Datenpfad selbst erkennen und eingrenzen, statt Ergebnisse einer anderen Protokollschicht stellvertretend zu deuten.

Die IESG hat die Version -29 des Entwurfs angenommen. Der Vorgang verleiht dem Nachrichtenformat normatives Gewicht, nicht jedem am Markt angebotenen Gerät dieselben Fähigkeiten. Besonders wichtig ist deshalb die Bindung der Sonde an den untersuchten Datenstrom. Laut Entwurf soll die Echo Request dieselbe BIFT-id, Bitstring-Länge, Entropy und DSCP-Kennzeichnung tragen. Wer diese Parameter ändert, kann einen anderen Weiterleitungspfad oder eine andere Behandlung prüfen. Wer sie in der Messakte nicht aufbewahrt, kann später eine grüne Anzeige kaum noch einordnen.

Ping und Trace sind nicht deckungsgleich

Der Traceroute-Modus dieses Dokuments ist auf BIER über MPLS begrenzt; Ping hat diese Einschränkung nicht. Eine Beschaffungszusage über „BIER Ping and Trace“ sollte daher die unterstützte Kapselung, Antwortarten, Ziel-BFER und Softwarestände nennen. Ein Echo belegt zunächst, dass ein bestimmtes OAM-Paket unter bestimmten Bedingungen beantwortet wurde. Ob alle Empfänger ihren Anwendungsstrom erhalten und welche Verluste oder Laufzeiten sie sehen, muss gesondert erfasst werden.

Auch ein Timeout ist mehrdeutig. Neben einem Fehler in der Weiterleitung kommen ein gestörter Rückweg, Antwortbegrenzung oder fehlende Implementierung infrage. Eine saubere Ereignisakte trennt diese Möglichkeiten, statt aus dem Fehlen einer Antwort sofort eine defekte Multicast-Domäne zu machen.

Der Entwurf verlangt unter anderem einen UDP-Port für eine über IP/UDP versandte Echo Reply sowie BIER-OAM-Kennungen und Register. Kommentare der IANA-Fachprüfung präzisieren den Zweck: Unicast-Antworten in einer kontrollierten Umgebung, nicht ein allgemeiner Transportport für Multicast-Nutzdaten. Für Firewall-Regeln ist das erheblich. Einen endgültigen Port aus dem Beschluss abzuleiten, wäre verfrüht.

Der Datatracker führt das Dokument derzeit in der RFC-Editor-Warteschlange, die IANA-Aktion als laufend und den redaktionellen Status als durch fehlende Autoreneingabe blockiert. Auch die IESG-Mitteilung verlangt Antworten auf IANA-Fragen. Die Billigung ist damit nicht zurückgenommen; sie ist nur nicht das Ende der Übergabe. Beim Implementierungsstand bleibt die amtliche Aussage vorsichtig: Anbieter mit BIER-Unterstützung haben „einen Teil“ umgesetzt. Namen, getestete Funktionspaare und umfassende Interoperabilität folgen daraus nicht.

Lu Hengs Vorrang funktionsfähiger Netze dient hier als redaktioneller Maßstab, nicht als Quelle über BIER-Installationen. Diese Nachricht behandelt die neue Protokollentscheidung und ihren Weg zum überprüfbaren Werkzeug. Der frühere Beitrag zur höchsten CoS-Sonde untersuchte dagegen, welche Schlüsse aus einem bestimmten Kontinuitätstest zulässig sind.

Sources