Zusammenfassung

  • RFC 9655 ergänzt optionales Egress TLV 32771 vor dem Target FEC Stack, damit ein vollständig durch Nil FEC dargestellter MPLS Ping/Traceroute sein beabsichtigtes Endziel nennt.
  • Bei Stack-Tiefe null belegt Code 36 den exakten lokalen Adress-Match, Code 10 dessen Scheitern; Legacy-Code 3 kann bedeuten, dass ein alter Egress gar nicht nach RFC 9655 geprüft hat.
  • Policy-Intent, Adressableitung, Request-Bytes, Capability, realer Forwardingweg, Offline-Verifikation und Servicewirkung benötigen getrennte Identitäten und Zeitpunkte.

Warum Nil FEC eine Lücke hinterlässt

Nil FEC aus RFC 8029 trägt keine zugehörige FEC-Information. Steht es außen im Target FEC Stack, entfällt dessen Validierung vollständig. Das hilft einem Headend, das zwar einen vom Controller gelieferten Labelstack besitzt, aber nicht die FEC-Bedeutung jedes Labels in fremden Domains kennt.

Repräsentiert ein Nil FEC jedoch den gesamten Stack, kann der Empfänger nicht sicher erkennen, ob er das beabsichtigte Ende ist. Ein fehlgeleiteter Probe kann an einem falschen Router eine scheinbar erfolgreiche Antwort erhalten.

RFC 9655 stellt eine Endidentität bereit. TLV 32771 trägt vier IPv4- oder sechzehn IPv6-Oktette und steht vor dem Target FEC Stack. Solange Tiefe verbleibt, meldet Code 8 Transit-Switching. Bei Tiefe null sucht der Router die Adresse exakt in lokalen Interfaces und Loopbacks. Match ergibt 36, Fehler 10.

Code 36 ist damit präzise: Der antwortende Router ist Egress für diese Adresse. Er bestätigt nicht jeden vorausgegangenen Labelvorgang.

Auch eine deterministische Ableitung hat eine Version

Normalerweise stammt die Adresse aus dem SR Policy Endpoint von RFC 9256. Fehlt er oder ist null, wird das Ende des letzten Segments verwendet. Bei Adj-SID ist dies der entfernte Nachbar, bei Binding SID der letzte Knoten des gebundenen Pfads.

Diese Berechnung hängt von Policy, Topologie und Binding-Auflösung ab. Nach einer Controller-Neuberechnung kann ein Headend noch eine alte Sicht serialisieren. Der Egress beantwortet dann eine veraltete, aber formal korrekte Frage.

Der Nachweis braucht Policy-ID, Candidate Path, Segmentliste, Endpoint-Quelle, Binding-Auflösung, Controller-Epoch, Headend-Build, Request-Hash und Sendezeit. RFC 8402 beschreibt Segmente als Instruktionen; das TLV prüft nur die daraus abgeleitete Endidentität.

Legacy-Erfolg ist kein validierter Erfolg

Ein Transitrouter ohne Unterstützung kann das TLV ignorieren, überspringen oder einen Fehler melden; das Headend darf mit höherem TTL fortfahren. Fehlt die Unterstützung am Egress, findet kein neuer Lookup statt und Legacy-Code 3 kann zurückkommen.

Verfügbarkeit bleibt erhalten, Assurance nicht. Ein Dashboard muss Code 3 und 36 auseinanderhalten und zusätzlich TLV-Sendung, bekannte Capability, ausgeführten Lookup, verglichene Adresse, Tiefe, Subcode und Softwareversion speichern.

Der IANA-Registry weist 32771 und 36 zu; RFC 9041 klärt Codepoint-Behandlung. Eine registrierte Zahl ist weder Installations- noch Aktivierungsnachweis.

Der Offline-Prüfer ist ein eigener Entscheidungsträger

Im Traceroute wird jeder Knoten Receiver. Zusammen mit den SR-Erweiterungen aus RFC 8287 kann eine Offline-Anwendung TTL, Responder, Tiefe und Codes zu einer Pfadbewertung verbinden.

Sie muss Lücken sichtbar lassen. Ein schweigender Legacy-Hop oder ein anderer ECMP-Zweig darf nicht aus dem Controller-Plan ergänzt und anschließend als Beobachtung ausgegeben werden. Eingabemenge, Missing-Hop-Regel, erwarteter Epoch und Verdict gehören in den Auditdatensatz.

Danach fehlt immer noch der Service. Probe und Nutzverkehr können andere Hashes, Zeiten und Steeringzustände haben. Produktionszähler, Empfang und Anwendungsresultat sind weitere Receipts.

Heng Lus Realitätsebenen trennen Absicht, Symbol, Ausführung und Wirkung. Die minimale Anfangsspezifikation standardisiert die gemeinsame Endidentität, nicht jede lokale Entscheidung. Der Vorrang laufenden Codes verlangt Belege aus dem tatsächlich eingesetzten Build und Forwardingzustand.

Quellen