Zusammenfassung

  • Die vom IESG genehmigte BGP-EPE-Erweiterung kann für ein physisches Mitglied unter einem Layer-2-Bündel einen PeerAdj SID oder End.X SID per BGP-LS bekanntgeben.
  • Die Meldung beschreibt ein betriebsbereites Mitglied und einen programmierten SID zu einem Kontrollzeitpunkt. Sie beweist weder aktuelle Kapazität noch Reihenfolge, MC-LAG-Sicherheit, Dataplane-Erfolg oder Berechtigung.

Die physische Kante unter dem logischen Link

Eine BGP-Sitzung über einem LAG erscheint als eine Layer-3-Schnittstelle. Der bisherige PeerAdj SID lenkt zum logischen Bündel; dessen Verteilungsmechanismus wählt anschließend ein Mitglied. Ein Controller kann damit den Ausgang, aber nicht gezielt die physische Leitung bestimmen.

Der am 6. August 2026 genehmigte Entwurf trennt beide Ebenen. Das übergeordnete BGP-LS Link NLRI bezeichnet das Bündel. Ein L2 Bundle Member Attributes TLV bezeichnet sein physisches Mitglied und enthält genau den zugehörigen SR-MPLS PeerAdj SID oder SRv6 End.X SID.

Die Aufnahme des TLV impliziert, dass das Mitglied operational up ist. Der enthaltene SID impliziert zusätzlich, dass er gültig und für die Weiterleitung über dieses Mitglied programmiert ist. Das ist eine zeitgebundene Aussage des Speakers, keine Reservierung.

Sichtbarkeit und Gültigkeit sind verschiedene Achsen

Ändert sich der SID, wird er ungültig oder administrativ deaktiviert, muss die Anzeige aktualisiert werden. Fällt das Mitglied aus oder verlässt das Bündel, muss sein gesamter TLV zurückgezogen werden. Der Rückzug begrenzt die Lebensdauer der Handlungsoption.

Kurzes Flapping darf mit einem Hold-off gedämpft werden. Nach stabilem Down darf der Rückzug nicht weiter warten. Verbraucher brauchen deshalb Speaker, Sitzung, Empfangszeit, Alter und Ablaufregel. Eine Topologiekopie ohne Uhr kann formal richtig und praktisch veraltet sein.

Der Betreiber muss Member-Anzeigen nach Peer, Sitzungsart oder Routing-Policy filtern und die Granularität unterdrücken können. Fehlende Daten sind daher kein negativer Existenzbeweis. Sie können eine bewusste Begrenzung der Offenlegung sein.

Präzision ersetzt keine Lastpolitik

Das Bündel verteilt Verkehr normalerweise selbst. Werden Flüsse auf einzelne Mitglieder fixiert, kann eine Leitung überlasten, während andere frei bleiben. Der Entwurf legt Überwachung und Neuzuweisung beim Controller oder Policy-System ab; das Protokoll liefert lediglich die adressierbare Aktion.

Verschiedene Latenzen erzeugen zudem Reihenfolgerisiken. Paketweises Verteilen oder ein Wechsel mit Paketen im Flug kann umsortieren. Ein stabiler Fünf-Tupel- oder anderer flow-invarianter Klassifikator soll einen Fluss zusammenhalten. Failover benötigt trotzdem Ergebnisbeobachtung.

Belastbare Evidenz verbindet SID und Policy-Version mit Auslastung, Queue, Verlust, Latenz, Klassifikation, realen Ausgangszählern und Rollback. Eine akzeptierte Programmierung ist nicht das Ende der Prüfung.

Vertrauen grenzt Verteilung ein

Member-Informationen gehören in vertrauenswürdige SR-Domänen oder zwischen ausdrücklich vertrauenswürdige Peering-Domänen. BGP-Filter verhindern ungewollte Weitergabe. Empfangsrecht ist dennoch kein Kapazitätsmandat.

Für MC-LAG definiert der Entwurf keine Schleifenvermeidung. Er setzt voraus, dass das darunterliegende L2/LAG-System bereits schleifenfrei arbeitet. Ein genauer SID kann diese fehlende Voraussetzung nicht herstellen.

Die robuste Ordnung bleibt dünn: Router meldet, Telemetrie misst, Controller schlägt vor, Policy autorisiert, Dataplane belegt und Betrieb rollt zurück. Gemeinsame Syntax verbessert Koordination, ohne die spätere Entscheidung zu zentralisieren.

Implementierung ist Reifeevidenz, kein Betriebsurteil

Der genehmigte Entwurf nennt zwei gemeldete Implementierungen. Gleichzeitig erklärt er, dass diese Angaben von Mitwirkenden stammen, nicht unabhängig geprüft wurden und keine IETF-Empfehlung eines Produkts darstellen. Genau diese Trennung sollte auch ein Käufer bewahren.

Laufender Code kann zeigen, dass TLV-Verschachtelung, Member-Identifikation und SID-Programmierung praktisch umsetzbar sind. Er zeigt nicht, dass die eingesetzte Softwareversion denselben Stand besitzt, dass ein Upgrade alle Rückzüge korrekt behandelt oder dass der lokale Controller Auslastung und Reihenfolge überwacht.

Vor Einführung braucht es daher eine versionsgebundene Capability-Prüfung, ein beobachtetes Up/Down- und Re-Advertisement-Verhalten, Dataplane-Canaries sowie einen belegten Weg zurück zum Parent-SID. Produktreife verkürzt die Prüfung nicht; sie macht deren Objekt nur konkreter.

Auch die zwei Datenebenen sind getrennt zu prüfen. SR-MPLS trägt den PeerAdj SID im Member-TLV, SRv6 den End.X SID mit den Regeln der SRv6-SID-Struktur. Gemeinsame Absicht bedeutet nicht automatisch identisches Fehlerverhalten.

Quellen