Zusammenfassung

  • Donald Eastlakes frühe Begutachtung für das Routing Area Directorate wurde am 27. September mit „Not ready“ abgeschlossen. Das ist keine Ablehnung durch die IESG; der Text bleibt ein aktiver Entwurf der IDR-Arbeitsgruppe.
  • Revision 13 empfiehlt mit SHOULD, den Next Hop in der Weiterleitungsdatenbank der gewählten Datenebene aufzulösen, und erlaubt mit MAY eine zusätzliche Verfügbarkeitsprüfung. Die Auswirkung einer fehlgeschlagenen Prüfung auf die Bestpfad-Auswahl bleibt unklar.
  • Für MPLS können LDP-Eintrag, SR-SID, Tunnel oder rekursiv aufgelöste Route unterschiedliche Zustände bezeichnen. Der Prüfer fordert einen Bezug zu dem Zustand, den die Pakete tatsächlich nutzen werden.

Eine Route kann bekannt sein und trotzdem ins Leere führen. Im erläuternden MPLS-VPN-Beispiel des IDR-Entwurfs sieht ein Provider-Edge-Router weiterhin eine IP-Route zum Next Hop. Der für den Verkehr vorgesehene Label-Switched Path funktioniert jedoch nicht. Eine alternative Route kann vorhanden sein, während BGP weiterhin den unbrauchbaren Pfad auswählt und ankündigt. Das Beispiel beschreibt eine mögliche Wirkung, keinen dokumentierten Ausfall bei einem bestimmten Netzbetreiber.

Der aktuelle Anlass ist eine Fachbegutachtung. Donald E. Eastlake III datierte seine Stellungnahme auf den 25. September; im IETF-Datatracker wurde sie am 27. September als abgeschlossen und „Not ready“ vermerkt. draft-ietf-idr-bgp-bestpath-selection-criteria-13 ist weiterhin ein aktiver Internet-Draft der IDR-Arbeitsgruppe, angestrebt als Proposed Standard. Bei der IESG lautet der Status „I-D Exists“, ohne angesetzten Telechat. Die angekündigte Aktualisierung von RFC 4271 gilt ausdrücklich nur im Fall einer Genehmigung. Eine Working-Group-Last-Call und eine AD-Begutachtung gab es schon 2020; die neue Stellungnahme ist weder der Beginn des gesamten Verfahrens noch sein Abschluss.

Die beiden Sätze mit normativer Wirkung in Abschnitt 3 lassen Spielraum. Nach der Wahl einer Datenebene durch die lokale Policy SHOULD die Erreichbarkeit des Next Hops in deren Weiterleitungsdatenbank geprüft werden. Eine Verfügbarkeitsprüfung des Pfades mittels OAM MAY hinzukommen. Auswahl der Ebene und konkrete Prüftechnik liegen außerhalb des Entwurfs. RFC 4271 schließt unauflösbare Routen bereits aus der Phase-2-Entscheidungsfunktion aus. Eastlake beanstandet jedoch, dass Revision 13 nicht ausdrücklich festlegt, ob eine Route nach Fehlschlag einer neuen Prüfung als unauflösbar gilt. Sein Vorschlag mit MUST wäre eine Verschärfung; er steht nicht als geltende Anforderung in Revision 13.

Der zweite Streitpunkt ist das Prüfobjekt. Ein MPLS-Next-Hop kann über einen von LDP abgeleiteten Label-Eintrag, einen Segment-Routing-Prefix-SID, einen RSVP-TE- oder SR-Policy-Tunnel oder eine rekursiv erreichte BGP-Labeled-Unicast-Route bedient werden. Bei direkter Nachbarschaft kann gerade ein unmarkierter Eintrag relevant sein. Diese Fälle sind nicht austauschbar. Eine vorhandene Tabellenzeile beweist nichts über den Pfad, den die Weiterleitung wirklich wählt.

Der Prüfer möchte Mechanismus und Rekursion an die tatsächliche Paketweiterleitung binden, damit identische Eingaben nicht allein wegen verschiedener Interpretationen zu unterschiedlichen Bestpfaden führen.

Auch das Verhältnis zu RFC 9012 muss geklärt werden. Dort gilt eine Route bereits als unauflösbar, wenn ihr Tunnel-Encapsulation-Attribut keinen realisierbaren Tunnel enthält. Eastlake fragt, was die neue Regel darüber hinaus leisten soll. Das ist eine Frage nach Überlappung, kein Nachweis eines Normwiderspruchs. Seine weiteren Warnungen betreffen flackernde OAM-Signale, falsche Verfügbarkeitsmeldungen und mögliche Schleifen, wenn Router im hop-by-hop-IP-Netz zu abweichenden Ergebnissen kommen. Sie belegen keine tatsächlichen Vorfälle oder Marktverbreitung.

Für den Betrieb wäre eine zusammenhängende Spur sinnvoll: gewählte Datenebene, verwendetes Label oder Tunnel, rekursiver Next Hop, Prüfergebnis und daraus folgende Auswahlentscheidung. Daniel Kade beschreibt damit eine überprüfbare lokale Praxis, keine von der IETF vorgeschriebene Protokollierung. Der Entwurf allein sagt nicht, welche Implementierung diese Praxis bereits beherrscht.

Quellen