Zusammenfassung

  • RFC 9752 erlaubt das Vendor Information Object in PCRpt, PCUpd und PCInitiate und verweist Enterprise Numbers ausdrücklich auf die IANA Private Enterprise Numbers Registry.
  • Ein PEN bezeichnet einen privaten Namensraum, bestätigt aber weder Herausgeber und Semantikversion noch Empfänger-Support, Änderungsrecht, Geräteanwendung oder Dienstergebnis.
  • Belastbare Betriebsbelege verbinden Rohbytes und Decoder mit Capability-Vereinbarung, lokaler Autorisierung, SRP/PLSP-Korrelation, PCE/PCC-Abgleich, Gerät, Forwarding, Verkehr, Rollback und Fallback.

Ein Change-Fenster endet mit einem grünen PCRpt. Die Sitzung war verschlüsselt, der PEN war registriert und der PCC meldete den LSP zurück. Erst beim späteren Vergleich stellt sich heraus, dass niemand festgehalten hat, welche Fassung der privaten Semantik geladen war. Das Protokoll hat funktioniert; die Beweiskette nicht.

RFC 9752 ist ein IETF Proposed Standard vom April 2025. RFC Editor und Datatracker weisen RFC 7470 als aktualisiert aus. Die Norm erweitert den Transport von Vendor Information auf Stateful-PCE-Vorgänge. Sie standardisiert nicht den Inhalt hinter der Herstellerkennung.

Drei Nachrichtentypen, kein gemeinsames Ergebnis

RFC 7470 definiert VENDOR-INFORMATION als Object-Class 34, Type 1, sowie den TLV Type 7. Nach dem 32-Bit Enterprise Number folgen Enterprise-Specific Information. Format und Interpretation sind Sache des bezeichneten Unternehmens; eine Veröffentlichung kann als Informational RFC oder kommerzielle Dokumentation erfolgen. Weder Dokumentversion noch Hash oder Decoder-ID reisen standardmäßig mit.

RFC 9752 erlaubt das Objekt in PCRpt, wenn ein PCC den aktuellen LSP-Zustand meldet, in PCUpd, wenn ein PCE Attribute ändern will, und in PCInitiate, das LSP-Erzeugung oder -Löschung auslöst; die erweiterte Grammatik hängt die Vendor-Liste an die Instantiierung. Der TLV durfte bereits in Stateful-Objekten wie SRP und LSP verwendet werden, sofern diese TLVs aufnehmen.

Das sind verschiedene Wirkflächen. Eine private Messgröße im Report, eine proprietäre Constraint im Update und ein Parameter zur Instantiierung beweisen nicht dasselbe. Ein PCRpt darf mehrere Objekte mit unterschiedlichen PENs enthalten. RFC 9752 bestimmt keine allgemeine Priorität zwischen diesen privaten Aussagen und keine Konfliktregel gegenüber Standardobjekten.

Registry-Kontrolle endet vor dem Paket

RFC 9752 präzisiert den Bezug auf die Private Enterprise Numbers Registry nach RFC 9371. IANA vergibt PENs nach First Come First Served und prüft die Berechtigung bei Änderungen des Registry-Eintrags. Das schützt die Verwaltungsakte.

RFC 9371 hält zugleich fest, dass niemand die private Nutzung eines PEN kontrollieren oder einen Dritten daran hindern kann, einen fremden PEN in Daten einzusetzen. Der registrierte Name ist daher keine kryptografische Herkunftsaussage für die empfangenen Bytes. Auch belegt er nicht, dass ein aktuelles Produktteam, ein Käufer oder ein Fork dieselbe Semantik verwaltet.

Benötigt wird ein eigener Herkunftsbeleg: authentifizierter Herausgeber, exakte Fassung, Dokument- und Decoder-Hash, unterstützte Positionen, Veröffentlichungs- und Rücknahmedatum sowie Lifecycle-Regeln. Dieser Beleg darf bei Übernahme, Abspaltung oder Supportende nicht von einem alten Registry-Kontakt abhängen.

Erkennen, verstehen und erlauben

Kennt eine Implementierung das Objekt, unterstützt aber den enthaltenen Enterprise Number nicht, muss sie es nach der geerbten Regel ignorieren. Ein Sprecher soll Vendor Information nicht senden, wenn er fehlenden Support vermutet. RFC 7470 lässt jedoch die Anzeige unterstützter PENs und Semantiken außerhalb seines Scopes und nennt eine Kooperationsvereinbarung als Voraussetzung funktionaler Interoperabilität zwischen Herstellern.

Support zerfällt damit in mindestens vier Zustände: Object Header parsbar; PEN bekannt; konkrete Semantikversion implementiert; Nutzung für Peer, Nachricht und LSP lokal freigegeben. Ein normgerechtes Ignore kann die Basisverbindung retten, aber die vom Sender erwartete Wirkung entfernen. Erfolgreiches Decoding wiederum ist keine Autorisierung.

Eine Capability-Quittung sollte beide Endpunkte, Version, Operationsumfang, Ablauf, Downgrade und Fallback nennen. Der Test muss dieselbe Dienstabsicht ohne private Daten und mit einer anderen Implementierung ausführen. Ändert sich dabei still die Bedeutung standardisierter Objekte, ist die Funktion nicht portabel.

Der PCC darf auch einem authentifizierten Peer widersprechen

RFC 9752 empfiehlt authentifizierte, verschlüsselte Sitzungen nach RFC 8253. TLS schützt Transportidentität und Bytes. Es authentifiziert nicht den Autor einer privaten Spezifikation und gibt keine fachliche Vollmacht für einen bestimmten LSP.

RFC 8231 setzt die lokale Grenze: Ein PCC handelt auf einen Update Request nur, wenn die vom Network Manager konfigurierte Policy dies erlaubt. Eine ausgeführte Anfrage startet ein LSP-Setup und wird mit dem resultierenden Zustand beantwortet. Delegation kann entzogen werden. RFC 8281 verlangt beidseitige PCE-Initiated Capability und kennt Ablehnungen für unzulässige Parameter, interne Fehler und Signalisierungsfehler.

Session, Delegation, lokale Entscheidung, Parser, semantische Prüfung und PCRpt bleiben getrennte Zeugnisse. SRP-ID und PLSP-ID korrelieren Vorgänge, doch ein PCRpt ist eine Meldung des PCC. Er ist keine unabhängige RIB-, FIB-, Label- oder Paketbeobachtung.

Eine Zeitachse statt eines grünen Zustands

Der Audit Record beginnt mit unveränderten Bytes, PEN, Nachrichtentyp, Objektposition, Peer und Session-Epoche. Dazu kommen signiertes Manifest, Version und Decoder-Hash, Parse-Ergebnis, Semantikprüfung, Standardobjekte, Konfliktentscheidung, Delegation und Autorisierung. Anfrage, Fehler und Report werden über SRP-ID, PLSP-ID und Zeit verknüpft.

Außerhalb PCEP folgen Gerätetransaktion, tatsächlich angewandte Konfiguration, programmierte Route oder Labels, Traffic Probe, Servicebeobachtung und Rollback. Nach Restart, Resynchronisierung und Timeout ist neu zu prüfen, ob Bedeutung und Zustand noch übereinstimmen. Ein FIB-Snapshot ist kein dauerhafter Liefernachweis; eine Probe ist kein SLA.

RFC 9752 fügt keine Liveness-Methode, keine neue Operationsprüfung und keine Anforderung an andere Protokolle hinzu. Standard-YANG kann Nutzung und PEN melden, nicht den privaten Inhalt. Die Norm warnt zudem vor einem Covert Channel und verlangt Kenntnis des Decoders sowie Inspektion. Ein Zähler „Vendor Object vorhanden“ verwischt genau die relevante Semantik.

Die IANA PCEP Registry bestätigt die Codepoints. Die Quellen belegen keinen benannten Rollout, Fehler, Angriff, Performancegewinn oder Dienstzustand. Heng Lus Running-Code Primacy, Minimum Initial Specification und Reality Layers dienen als offengelegte redaktionelle Perspektive: Dokument und Namespace koordinieren, erst Implementierung und Beobachtung begründen die nächste Realitätsschicht. Das ist keine IETF-Anforderung.