Zusammenfassung

  • RFC 9160 ergänzt mplsTopLabelType(46) um fünf Werte, damit ein IPFIX-Datensatz bestimmte MPLS-Segment-Routing-Zuteilungskontexte ausdrücken kann, statt Herkunft aus einer Nummer zu erraten.
  • Ein typisierter Export kann eine begrenzte Untersuchung stützen; er beweist weder eine vollzogene Migration noch einen aktiven Pfad, eine installierte Richtlinie oder ein Dienstergebnis.

Die oberste MPLS-Labelnummer ist ein beobachtbarer Wert, aber keine vollständige Herkunftserklärung. Sie kann exportiert, gruppiert und mit anderen Feldern verknüpft werden. Problematisch wird es, wenn ein Bericht aus der Zahl unmittelbar auf das Zuteilungsprotokoll schließt. Genau diese Verkürzung behandelt RFC 9160: nicht indem das Dokument eine reale Netzgeschichte behauptet, sondern indem es dem Export eine ausdrückliche Typunterscheidung gibt.

Der IETF Informational RFC erschien im Dezember 2021; Thomas Graf von Swisscom ist der einzige aufgeführte Autor. Er definiert fünf neue Codepunkte für das vorhandene IPFIX Information Element mplsTopLabelType(46): Path Computation Element, OSPFv2 Segment Routing, OSPFv3 Segment Routing, IS-IS Segment Routing und BGP Segment Routing Prefix-SID. Damit kann ein Export den spezifizierten MPLS-SR-Control-Plane-Kontext des Labeltyps angeben.

Diese Angabe ist nötig, weil Labelwerte nicht selbstbeschreibend sind. RFC 9160 hält fest, dass IGP-Adjacency-SIDs, LDP und dynamische BGP-Labels denselben Zuteilungsbereich teilen können. Derselbe sichtbare Zahlenwert kann damit zu mehreren Zuteilungsgeschichten passen. Wer das Protokoll aus der Zahl ableitet, verwandelt eine numerische Koinzidenz in Herkunft, die der Wert nicht nachweist.

Die im RFC genannten Fälle sind Monitoring-Aufgaben, keine Erfolgsbescheinigungen. Ein Betreiber kann Migrationen von LDP zu IS-IS oder OSPF Segment Routing sowie von dynamischen BGP-Labels zu BGP Prefix-SIDs beobachten. Wird der Labeltyp mit den weiteren ausdrücklich genannten IPFIX-Elementen — Top-Label-Adressen, Stack-Abschnitt und Forwarding Status — verbunden, kann der Datensatz Schlüsse über weitergeleitete oder verworfene Pakete, mögliche Verwerfungsgründe, die Provider-Edge-Loopback-Adresse und das Labelprotokoll unterstützen.

Das ist eine Hilfe bei einer genau abgegrenzten Schlussfolgerung, kein Ersatz für ihre übrigen Voraussetzungen.

Der Export ist deshalb kein Betriebszertifikat. Weder RFC noch Registry-Wert belegen, dass ein bestimmter Exporter aktiviert ist, ein Collector einen vollständigen Satz gesehen hat, ein Eintrag authentisch ist oder die Beobachtung den fraglichen Pfad abdeckt. Ein typisiertes Feld zeigt auch nicht, wann eine Migration begann oder endete, weshalb eine Policy gewählt wurde, ob ein Paket sein Ziel erreichte oder was ein Kunde erlebte. Präzisere Semantik überwindet keine Lücken von Beobachtung, Sammlung und Geltungsbereich.

Besonders deutlich wird das an den zwei BGP-Bedeutungen. Der bestehende BGP-Codepunkt 4 bezieht sich auf den Labelwert im MP_REACH_NLRI Path Attribute. Der neue Codepunkt 10 für BGP Segment Routing Prefix-SID bezieht sich auf einen Label-Index-Wert in einem Label-Index TLV. Beide heißen im Alltag leicht „BGP-Label“, doch sie bezeichnen verschiedene technische Objekte. RFC 9160 bewahrt diese Trennung, bevor ein gemeinsamer Name sie verwischt.

Sofia Ren liest Lu Hengs Running-Code Primacy hier als Prüfdisziplin: Ein Koordinierungsdokument oder Registry-Eintrag kann eine überprüfbare Semantik liefern, aber keine unbeobachtete Laufzeitrealität erzeugen. Die kleinste belastbare Aussage lautet: Ein Exporter hat unter benannten Beobachtungs- und Sammelbedingungen einen definierten Top-Label-Zuteilungstyp in einem IPFIX-Datensatz dargestellt. Für eine Aussage über Control Plane, Forwarding oder Service braucht es jeweils eigene Belege.

Eine Untersuchung sollte daher den Roh-Export, die Exporter-Identität, den Beobachtungspunkt, das Sammelintervall, das Template, die Integritätsgrenze und die tatsächlich korrelierten Felder bewahren. Eine Behauptung zur Control Plane wird gegen Control-Plane-Nachweise geprüft, eine zur Weiterleitung gegen Forwarding-Nachweise, eine zum Service gegen Service-Telemetrie. Weder die Nummer noch ihr Typ erspart diese Trennung.

Grafs Beitrag macht einen Record nicht allwissend. Er verhindert, dass ein nackter Zahlenwert für eine Herkunft bürgt, die er nicht trägt. Der Gewinn ist eine sauberere Kette zwischen einem typisierten Exportfakt und der Netzgeschichte, die weiterhin durch tatsächliche Laufzeitbelege zu zeigen ist.

Quellen