Zusammenfassung

  • Bis 26. September bittet die IETF um letzte Stellungnahmen zu draft-ietf-ivy-network-inventory-topology-11, der als Proposed Standard vorgesehen ist. Das Dokument bleibt ein veränderlicher Internet-Draft, kein RFC und kein Nachweis eines Einsatzes.
  • ne-ref, port-ref und link-type sind schreibbar. Automatische Erkennung soll der Normalfall sein, manuelle Überschreibungen bleiben ausnahmsweise möglich; die hardwarebestimmte Fähigkeit port-breakout darf dagegen nie manuell konfiguriert werden.
  • Eine Zuordnung kann die Bereitstellung steuern, ohne aktuelle Kapazität, installierte Konfiguration oder Dienstergebnis zu beweisen. Daniel Kade schlägt dafür einen geschützten, befristeten Ausnahmebeleg vor; der Entwurf verlangt ihn nicht.

Der Last Call erreicht die Nahtstelle zweier Datenwelten

Die Datatracker-Historie zeigt Revision 11 nach der Prüfung durch den Area Director im IETF Last Call. Stellungnahmen sind bis 26. September erbeten, Zielstatus ist Proposed Standard. Das ist eine offene Entscheidung. Der aktuelle Datensatz beschreibt weder einen fertigen RFC noch eine betriebliche Umsetzung.

Der Text der Revision 11 verbindet zwei Modelle. RFC 8345 stellt Netze, Knoten, Verbindungen und Endpunkte dar. Der IVY-Basisentwurf zum Inventar erfasst Geräte und Komponenten, die einem Managementsystem als installiert bekannt sind. Die neue Erweiterung legt Referenzen zwischen beiden Ansichten an.

ne-ref führt von einem Topologieknoten zu einem Netzelement. port-ref verbindet einen Endpunkt mit einer physischen Portkomponente. link-type klassifiziert das Medium knapp, etwa als Glasfaser, Kupfer, Richtfunk oder WLAN. port-breakout beschreibt, welche logischen Kanäle eine physische Schnittstelle unterstützt.

Damit wird eine Modellverknüpfung zum betrieblichen Eingang. Sobald sie Kapazitätsplanung, Wartung oder einen Kundenauftrag beeinflusst, gehört ihre Herkunft zur Entscheidung.

Die Referenz ist nur ein Glied in der Kette

Im Bereitstellungsbeispiel erhält der Orchestrator mehrere mögliche Service Attachment Points. Über den übergeordneten Endpunkt und dessen port-ref findet er den physischen Port. Ein weiteres Topologiemodell kann anschließend Auskunft zur Kapazität geben. Reicht sie nicht, wird ein anderer Kandidat geprüft und das Inventar kann den Engpass genauer benennen.

Diese Schritte sind nicht derselbe Beweis. Der logische Endpunkt ist eine Option. Die Referenz ist die angenommene Zuordnung. Kapazität ist eine zeitgebundene Beobachtung. Eine Konfiguration muss danach noch installiert werden. Erst das beobachtete Verhalten sagt etwas über den laufenden Dienst. Ein grüner Schritt färbt die folgenden nicht automatisch grün.

Ein veralteter port-ref schickt einen korrekten Algorithmus zum falschen Bauteil. Eine richtige Referenz kann mit einer alten Kapazitätsmessung zusammentreffen. Ein akzeptierter Plan kann bei der Installation scheitern, und installierter Zustand garantiert keinen Ende-zu-Ende-Erfolg. Das Wort Inventar beseitigt diese Grenzen nicht.

Auch der Basisentwurf formuliert seine Sicht vorsichtig. Er enthält, was ein bestimmter Controller über tatsächlich installierte Komponenten weiß; Ersatzteile und inaktive Bestände liegen außerhalb. Ob ein Element nur vorübergehend unerreichbar oder bereits entfernt ist, hängt vom Erkennungsmechanismus ab. Inventar ist modelliertes Wissen mit Herkunft.

Manuelle Angaben schließen echte Lücken

Nach den Betriebshinweisen sollen ne-ref, port-ref und link-type üblicherweise automatisch entdeckt werden. Eine manuelle Überschreibung ist dennoch in Ausnahmen zulässig. Genannt werden Kundengeräte, gemietete Leitungen und geplante Ressourcen.

Das ist betriebsnah. Ein Controller kann ein fremd verwaltetes Gerät nicht immer beobachten. Angaben zur Mietfaser können nur vom Lieferanten kommen. Eine Planung muss künftige Hardware darstellen, bevor sie eingeschaltet wird. Ein vollständiges Verbot würde fehlende Telemetrie mit fehlendem Wissen verwechseln.

Aber die Behauptungsart wechselt. Entdeckte Daten stammen aus einem Verfahren, einer Softwareversion und einem Zeitpunkt. Manuelle Daten stützen sich auf institutionelle Befugnis und einen Grund. Beide können richtig sein, beide können veralten; ihre Eigentümer und Korrekturwege unterscheiden sich.

Das endgültige Blatt enthält diese Biografie nicht. Es zeigt nicht, welches Erkennungsergebnis verdrängt wurde, wer die Ausnahme genehmigte, wie lange sie gelten sollte oder welche spätere Beobachtung sie bestätigte. Nach Export oder Zwischenspeicherung kann die Ausnahme wie normal entdeckter Zustand wirken.

Hardwarefähigkeit hat kein Genehmigungsverfahren

Bei port-breakout zieht der Entwurf eine andere Grenze. Der Container ist schreibgeschützt, weil er durch die Hardware bestimmt wird, und darf niemals manuell konfiguriert werden. Widerspricht die gemeldete Fähigkeit dem Plan, müssen Erkennung, Geräteidentität oder Plan korrigiert werden. Eine organisatorische Freigabe erzeugt keinen zusätzlichen Kanal.

Der Presence-Container inventory-topology liegt dazwischen. Ein Controller setzt ihn normalerweise, wenn er eine Instanz der physischen Ebene entdeckt oder bereitstellt. Fehlt die Erkennung, darf die Instanz manuell so bezeichnet werden. Die Deklaration kann berechtigt sein, sollte aber als Deklaration erkennbar bleiben.

Diese feldweise Politik ist eine Stärke. Planungswissen kann eine begrenzte Annahme benötigen. Physisch bestimmte Fähigkeit muss sich einer bequemen Überschreibung entziehen. Eine einzige Regel für alle Datenarten wäre weniger belastbar.

Der Lesezugriff ist ebenfalls eine Governance-Frage

Der Sicherheitsabschnitt nennt die Folgen falscher oder veralteter Zuordnungen: Fehlbereitstellung, gescheiterte Aktivierung, unerwartete Verkehrswege und ungenaue Kapazitätsplanung. Für NETCONF und RESTCONF verweist er auf geschützten Transport, gegenseitige Authentisierung und die Zugriffskontrolle aus RFC 8341. Der Aufbau orientiert sich an der YANG-Leitlinie RFC 9907.

Auch Lesen verrät Betriebswissen. ne-ref kann den Gerätebestand sichtbar machen, port-ref interne Komponentennamen, link-type Eigentumsverhältnisse. Die Identität leased-fiber unterscheidet Transport eines Dritten von eigener Infrastruktur. Ein öffentliches Protokoll mit vollständiger Topologie wäre daher keine verantwortliche Transparenz.

Der Nachweis muss sparsam und geschützt sein. Eine externe Bestätigung kann mit einer undurchsichtigen Kennung, Ausnahmeklasse, Zeit und Ergebnis auskommen. Port, Kunde und genaue Strecke bleiben hinter Zugriffskontrollen.

Die Ausnahme braucht eine Uhr

Daniel Kade schlägt für jede entscheidungsrelevante manuelle Zuordnung einen Mapping-Ausnahmebeleg vor. Er verbindet Objekt und Wert mit dem letzten Erkennungsergebnis, dessen Quelle, Controller- und Modellversion, Genehmigungsbefugnis, eng begründetem Anlass, Beginn, Ablauf oder Neubewertungsauslöser sowie dem erlaubten Verwendungszweck.

Wird der Wert bei einer Bereitstellung genutzt, kommen ausgewählter Kandidat, Kapazitätsbeobachtung, Konfigurationsergebnis und nachträgliche Beobachtung hinzu. Keine Zeile gilt als Ersatz für die nächste. Bei geplanter Hardware kann die Inbetriebnahme den Beleg beenden; bei Mietleitungen eine Lieferantenbestätigung; bei Kundengeräten eine Prüfung oder ein Verantwortungswechsel.

IVY, RFC 8345, RFC 8341 und RFC 9907 schreiben diesen Beleg nicht vor. Er ist Daniel Kades redaktioneller Vorschlag für den organisatorischen Kontext eines technischen Modells. Er erklärt auch automatische Erkennung nicht für unfehlbar. Er verhindert nur, dass Beobachtung und autorisierte Behauptung gleich aussehen, wenn eine Entscheidung fällt.

Die Trennung folgt Heng Lus Policy Mirror: Befugnis, Regel und Evidenz erfüllen unterschiedliche Aufgaben. Die Minimum Initial Specification lässt über einem kleinen gemeinsamen Mechanismus stärkere lokale Kontrollen zu. Why BTW Media Exists begrenzt den Befund: Der Last Call ist real; ein Vorfall oder eine Wahrheitsgarantie sind es nicht.

Quellen

  1. Inventory Topology Mapping, Revision 11
  2. Aktueller Datatracker-Eintrag
  3. Datatracker-Historie
  4. Eintrag zum Basis-Inventarmodell
  5. Basis-Inventarmodell, Revision 18
  6. RFC 8345 — YANG-Datenmodell für Topologien
  7. RFC 8341 — NACM
  8. RFC 9907 — Leitlinie für YANG-Autoren
  9. Heng Lu — The Policy Mirror
  10. Heng Lu — Minimum Initial Specification
  11. Heng Lu — Why BTW Media Exists