Zusammenfassung

  • Das TLV-Length-Feld in IS-IS ist ein Oktett breit. Eine einzelne TLV-Wertkomponente kann daher höchstens 255 Oktette enthalten.
  • Mehrere TLVs desselben Typs und, soweit anwendbar, desselben Schlüssels bilden in einem IIH oder in der level-spezifischen LSP-Menge ein Multi-Part TLV.
  • Ein MP-TLV-fähiger Empfänger verarbeitet die Information aus allen Vorkommen. Ein nicht unterstützender Empfänger wählt dagegen ein Vorkommen zur Verarbeitung und ignoriert die übrigen.

RFC 9885 ändert die TLV-Kodierung nicht. Ebenso definiert der RFC den Schlüssel nicht neu; maßgeblich bleibt der Schlüssel, den die jeweilige TLV-Spezifikation vorgibt. Das verhindert eine scheinbar naheliegende, aber falsche Zusammenfassung aller Vorkommen mit gleichem Typ, wenn ihre Schlüssel verschieden sind. Ein formal akzeptiertes LSP ist deshalb kein Beweis, dass der Empfänger das vollständige Objekt besitzt.

Der RFC beschreibt Empfangsverfahren, Anwendbarkeitserklärungen, Capability Advertisement, Einsatzkontrollen, Alarme und Einschränkungen für die Erzeugung. Daraus folgt nicht, dass bestimmte Hersteller, Versionen oder Netze MP-TLV unterstützen. Der eingefrorene Quellenbestand belegt weder Implementierungsabdeckung noch Verbreitung, Produktionsfehlerquoten oder einen gemessenen Performance- beziehungsweise Konvergenzeffekt in einem benannten Netz.

Entscheidungspfad für Betreiber:

  1. Die Spezifikation des TLV und ihren Schlüssel bestimmen; anschließend zwischen IIH und LSP sowie zwischen L1 und L2 unterscheiden.
  2. Prüfen, ob die Information 255 Oktette überschreitet, und alle Vorkommen mit gleichem Typ und gleichem Schlüssel erfassen.
  3. Anwendbarkeitserklärung und Capability Advertisement der Empfänger prüfen; außerdem kontrollieren, ob die Erzeugung an den vorgesehenen Stellen erlaubt ist.
  4. Bei gemischter Unterstützung die bloße LSP-Annahme nicht als Vollständigkeitsnachweis werten. Die Erzeugung begrenzen oder aussetzen, bis die notwendige Unterstützung bekannt ist.
  5. Alarme, Teilanzahl und Vollständigkeitsnachweis in die Änderungskontrolle aufnehmen und vor einer Ausweitung dokumentiert testen.

Präzises Test-Fixture: Erzeuge ein IIH oder ein LSP mit zwei Vorkommen desselben Typs und desselben Schlüssels. Gib dem ersten Wert 200 Oktette und dem zweiten 100 Oktette; jedes Vorkommen bleibt unter 255, zusammen werden jedoch 300 Oktette übertragen. Ein unterstützender Empfänger muss beide Vorkommen verarbeiten. Ein nicht unterstützender Empfänger muss ein Vorkommen auswählen und das andere ignorieren; genau dieses Verhalten ist zu protokollieren. Wiederhole den Test mit gleichem Typ und verschiedenem Schlüssel und verifiziere, dass daraus nicht ein gemeinsames Objekt entsteht. Das Fixture weist keine Produktunterstützung außerhalb des getesteten Empfängers nach.

Quellen