Zusammenfassung

  • RFC 8966 von Juliusz Chroboczek und David Schinazi behandelt die Metrikberechnung in Babel als lokale Policy. Ein unendlicher lokaler Kostenwert muss zu einer unendlichen Metrik führen; andernfalls muss das Ergebnis strikt größer sein als die vom Nachbarn angekündigte Metrik.
  • Diese Bedingung dient der Schleifenvermeidung. Sie macht aus einem Routenwert weder eine globale Kennzahl für Kapazität, Preis oder Latenz noch einen Beleg für aktuelle Erreichbarkeit oder ein geliefertetes Serviceergebnis. RFC 9616 zeigt, dass selbst genaue RTT-Proben für direkte Auswahl zu verrauscht sein können.

Streng dort, wo die Sicherheit es verlangt

In einer Routingtabelle sieht ein kleiner Wert schnell wie ein Urteil aus. Doch Babel verlangt keine einheitliche Messformel. Unterschiedliche Knoten und Schnittstellentypen dürfen verschiedene Strategien verwenden. Der gemeinsame Kern ist nicht eine zentrale Rangordnung, sondern die prüfbare Regel, dass ein zusätzlicher lokaler Schritt die Metrik nicht besser machen darf.

So wird eine Route daran gehindert, einen Kreis zu durchlaufen und innerhalb derselben Rechenlogik als Verbesserung zurückzukehren. Das ist ein technischer Sicherheitsinvariant. Eine ausgewählte Route sagt damit nur etwas über eine lokale Wahl unter ihren bekannten Eingaben aus. Sie beweist weder aktuellen Verkehr noch die Antwort eines Ziels, eine bestimmte wirtschaftliche Kostenlage oder die Erfahrung eines Nutzers.

Schleifenfrei ist nicht automatisch optimal

RFC 8966 trennt strikte Monotonie von Linksdistributivität. Erstere ist für die Vermeidung persistenter Schleifen wesentlich. Letztere wird empfohlen, ist aber für schleifenfreie Konvergenz nicht erforderlich. Fehlt sie, kann Babel konvergieren, ohne ein globales Optimum zu erreichen; ein solches Optimum kann sogar fehlen.

Damit bleibt Raum für unterschiedliche lokale Präferenzen, ohne den Sicherheitskern aufzugeben. Unendliche oder nicht zulässige Routen dürfen nicht ausgewählt werden. Eine höhere Sequenznummer darf nicht allein wegen ihrer Neuheit bevorzugt werden, weil dies laut RFC Oszillation und bei bestimmten Metriken dauerhafte Blackholes erzeugen kann. Bei schwankenden Metriken empfiehlt die RFC Hysterese. Sie verlangt anhaltende lokale Evidenz vor dem Wechsel, nicht eine Servicezusage.

Ein RTT-Wert braucht erst eine Übersetzung

RFC 9616 von Baptiste Jonglez und Chroboczek knüpft daran an: RFC 8966 schreibt keinen bestimmten Metrikalgorithmus vor. Die RTT-Erweiterung behandelt Fälle, in denen Hop Count oder Verlustmessung in Tunnel- oder VPN-Topologien unpassende Wege wählen kann. Doch genaue RTT-Proben sind nicht unmittelbar eine Auswahlregel; sie können verrauscht sein und Rückkopplung oder häufige Oszillation auslösen. Deshalb definiert das Dokument die Abbildung auf Linkkosten und Hysterese und beschränkt die Anwendung auf Umgebungen, in denen symmetrische Verzögerung die relevante Wahl vorhersagt.

RFC 8965, von Chroboczek verfasst, beschreibt Robustheit gegenüber neuartigen und schwankenden Metriken, nennt aber auch die Grenzen periodischer Updates und der Annahme einer vollständigen Routingtabelle. Sein IETF-Profil dokumentiert die RFCs 8965, 8966 und 9616; es belegt keine Kontrolle über ein laufendes Netz oder dessen Policy.

Evidenzgrenzen

Die Quellen zeigen kein heute aktives Babel-Domain, keinen laufenden Tunnel, keinen aktuellen RTT-Wert, keine Kapazität, keinen Preis, keine Sicherheitslage und kein Serviceergebnis. Ein prüfbarer Metrikbeleg hält daher Algorithmus und Version, lokalen Geltungsbereich, Beobachtungsfenster, Umrechnung, Zulässigkeit, Hysterese und Auswahlbedingung fest.

Quellen