Zusammenfassung

  • Die am 1. Oktober abgeschlossene Telechat-Prüfung von Revision 20 des IVY-Basisinventars schlägt eine Klarstellung vor: Der obere Controller soll als Server des kombinierten Inventars die Eindeutigkeit seiner ne-id-Schlüssel sicherstellen.
  • Ein eindeutiger Schlüssel löst nur den Listen-Konflikt. Ob gleiche lokale IDs verschiedene Geräte oder verschiedene IDs dasselbe Gerät bezeichnen, bleibt eine eigene Beweisfrage.

Zwei untere Controller melden jeweils die 17. Im ersten Bereich steht sie für einen Edge-Router, im zweiten für ein optisches Chassis. Beide Inventare sind in sich korrekt. Erst der obere Controller erzeugt das Problem, wenn er beide zu einer Liste machen will.

Genau diesen Übergang markiert Linda Dunbars Routing-Area-Directorate-Review zu draft-ietf-ivy-network-inventory-yang-20 vom 1. Oktober. Das Ergebnis lautet Has nits: Das Dokument sei insgesamt klar, enthalte aber einen kleinen Punkt. Da der Server ne-id vergibt und das Feld der Schlüssel der network-element-Liste ist, solle der obere Controller als Server der kombinierten Sicht für eindeutige Werte verantwortlich sein.

Das ist kein Störungsbericht. Revision 20 ist ein aktiver IVY-Internet-Draft für den Standards Track, derzeit in IESG-Evaluierung und AD-Follow-up. Sie ist kein RFC. Weder Kollision im Betrieb noch Sicherheitslücke oder Herstellerfehler sind belegt. Sichtbar wird eine Zuständigkeit im Architekturmodell.

Der Entwurf beschreibt ein generisches, schreibgeschütztes Inventar der Netzwerkelemente und Komponenten, die ein Controller als installiert kennt. Lagerbestände, Beschaffung und kommerzielle Daten gehören nicht zum Basismodell. Innerhalb dieses Umfangs ist der liefernde Controller die Quelle der Wahrheit. Er verantwortet seine Darstellung; er erschafft dadurch nicht die physische Wirklichkeit.

Der Server vergibt ne-id, weil eine lokale Gerätekennung im gesamten Netz nicht zwingend eindeutig ist. Zugleich soll dasselbe Netzwerkelement seine ID auch während einer Trennung vom Controller behalten. Wie Gleichheit erkannt wird—über Hersteller, Produkt, Management-Adresse, physischen Standort oder andere Merkmale—bleibt implementierungsspezifisch.

Am Aggregationspunkt entstehen deshalb zwei verschiedene Aufgaben. Schlüssel-Eindeutigkeit verhindert zwei Listeneinträge mit demselben Namen. Identitätsabgleich entscheidet, ob zwei Beobachtungen dasselbe Objekt betreffen. Ein Präfix mit dem Namen des Quelldomains erledigt die erste Aufgabe. Es beantwortet die zweite nicht.

Wird ein Gerät fälschlich getrennt, können Kapazität, Alarme und Wartung doppelt gezählt werden. Werden zwei Geräte fälschlich verschmolzen, kann eine Aktion dem falschen Chassis zugerechnet werden. Management-Adressen ändern sich, Standorte veralten, Produktbezeichnungen wiederholen sich. Ein Konfliktstatus ist daher eine wertvolle Aussage und kein Datenmüll.

Auch die gemeinsame UUID ist ein Anker, aber kein Identitätsbeweis. Revision 20 beschreibt sie als serververgeben und global eindeutig; RFC 9562 definiert Format und Erzeugung. Dennoch können zwei Server demselben physischen Objekt zwei gültige UUIDs geben. Eine fehlerhafte Kopie kann zwei Objekte gleich erscheinen lassen. Eindeutigkeit des Wertes und Gleichheit der Sache sind verschiedene Sätze.

Die Betriebskette umfasst mindestens fünf Ebenen: physischer Vermögenswert, Beobachtung des unteren Controllers, lokale ne-id, Abgleichentscheidung des oberen Controllers und kombinierte Kennung für Alarm, Topologie, Auftrag oder Automatisierung. Eine formal gültige YANG-Liste beweist nur die Struktur der Ausgabe.

BTW schlägt deshalb einen reversiblen Identitäts-Übersetzungsbeleg vor. Er verbindet Quell-Controller und Quell-ne-id mit kombinierter ne-id, UUID und verfügbaren Hardware-Ankern. Er hält Abgleichregel, Vertrauen, Konflikt, erste und letzte Beobachtung, Ablösungen sowie wichtige nachgelagerte Entscheidungen fest.

Dieser Beleg ist weder Forderung des Drafts noch des Reviews. Er ist eine redaktionelle Kontrollidee. Wenn B-17 oben zu 18 wird, bleibt der Rückweg erhalten. Werden A-17 und B-42 später als dasselbe Chassis erkannt, löscht die Zusammenführung nicht die Geschichte der früheren Aussagen. Bei schwacher Evidenz ist ein offener Konflikt ehrlicher als eine saubere, aber erfundene Gewissheit.

Die Doktrin von Heng Lu liefert eine enge Lesart. Note 20 trennt ausführbare Realität von symbolischer Darstellung. Note 64 beschränkt die gemeinsame Schicht auf minimale, lokal prüfbare Invarianten für Eindeutigkeit und Interoperabilität. Note 19 trennt Koordination von Autorität. Hieraus folgt: Das gemeinsame Modell braucht einen gültigen Schlüssel; der lokale Aggregator trägt Methode und Beleg; keine Kennung verleiht Herrschaft über das Gerät. Das ist BTW-Analyse, keine IETF-Position.

Benachbarte Beiträge behalten ihren Gegenstand. Topologie-Zuordnung behandelt manuelle ne-ref- und port-ref-Überschreibungen, Entitlement-Inventar trennt Lizenz von Aktivierung und Dienst, passive Inventare benötigen Beobachtungsketten für stumme Objekte. Dieser Beitrag fragt früher: Welche Identität überquert die Domäne, und wie führt sie zurück?

Der Draft erlaubt ausdrücklich, dass ein hierarchischer Controller Daten aus unteren Controllern sammelt und die kombinierte Sicht an einen weiteren Controller, ein Inventory OSS oder eine Anwendung liefert; ACTN wird als möglicher Kontext genannt. Ein weltweiter Matching-Algorithmus ist dafür nicht nötig. Notwendig ist die sichtbare Servergrenze der Eindeutigkeit und eine prüfbare lokale Übersetzung.

Quellen