Zusammenfassung

  • Der individuelle Entwurf vom 28. Oktober schlägt fünf allgemeine MPLS-Informationselemente vor, die in einer geordneten IPFIX-Vorlage wiederholt werden. Ist eine IPv4-Adresse, IPv6-Adresse oder Präfixlänge an Position K nicht verfügbar, darf der Exporteur dieses Element weder für K noch für tiefere Positionen ausgeben. Das Weglassen einer mittleren Stelle würde K+1 fälschlich zu K machen.
  • Die bestehenden positionsgebundenen Einträge im IANA-Register bleiben bestehen. Die neuen Felder brauchen den separaten Entwurf für geordnete Ausfuhr; ein alter Sammler kann ein neues geordnetes Set stillschweigend ganz verwerfen. Fünf neue IANA-IDs sind noch TBD.

Der Stapel ist länger als die Adressliste

Drei MPLS-Labels sind beobachtet. Zum ersten und zum dritten kennt die Messkomponente die Adresse des nächsten Hops, zum zweiten nicht. Sendet der Exporteur zwei Adressen ohne Lücke, liest der Sammler die zweite Adresse als Attribut des zweiten Labels. Sie gehört aber zum dritten. Der Zahlenwert bleibt richtig, die Beziehung zwischen Zahl und Label wird falsch. Ein automatischer Bericht könnte daraufhin eine Untersuchung an der falschen Stapelposition beginnen.

Abschnitt 4.7 des neuen Entwurfs legt deshalb eine harte Schnittkante fest. Für mplsLabelIPv4Address, mplsLabelIPv6Address und mplsLabelPrefixLength müssen die Vorkommen bei Position eins beginnen und ohne Sprung folgen. Fehlt ein Wert an K, darf dieselbe Eigenschaft für K und alle tieferen Positionen nicht mehr exportiert werden. Die dritte Label-Eintragung selbst kann weiter existieren; andere Eigenschaften mögen sie korrekt beschreiben. Nur die abgebrochene Adress- oder Präfixreihe darf ihre Tiefe nicht mehr behaupten. Sparse Teilmengen nimmt der Text ausdrücklich aus.

Für den Labeltyp erlaubt der Entwurf eine andere Antwort. Ist mplsLabelType an Position K unbekannt, sendet der Exporteur 0, Unknown. Das hält den Platz frei und macht die Unkenntnis sichtbar. Bei Adresse und Präfixlänge fehlt eine entsprechende Ersatzangabe, also endet dort die Reihe. „Typ unbekannt an Position zwei“ ist eine andere Lage als „diese Eigenschaft kann ab Position zwei keine tieferen Plätze mehr zuverlässig benennen“.

Die IANA-Liste der IPFIX-Elemente zeigt, wie die bisherige Sprache das Problem umgeht. IE 70 bis IE 79 bezeichnen zehn eigene Stapelpositionen, vom obersten Label bis zum zehnten. Der neue Text will mplsLabelStackEntry im geordneten Modell wiederholen und vier weitere allgemeine Attribute hinzufügen. Er streicht die alten Felder nicht. Solange ein Sammler die neue Ordnung nicht versteht, braucht er weiterhin die positionsgebundenen Felder.

Auch die Länge ändert sich. RFC 3032 definiert den vollständigen MPLS-Stapeleintrag mit vier Oktetten: Labelwert, Traffic Class, Kennzeichen für das Stapelende und TTL. Die alten positionsgebundenen Felder tragen drei Oktette ohne TTL. Das neue allgemeine Element trägt vier; dadurch lässt sich TTL auch tiefer im Stapel exportieren. Wer TTL gar nicht benötigt, zahlt dafür ein zusätzliches Oktett je Label. Mehr Sichtbarkeit braucht Platz.

Ordnung braucht drei Zeugen

RFC 7011 erlaubt, dass ein Informationselement in einer IPFIX-Vorlage mehrfach vorkommt. Aus einer gewöhnlichen Vorlage kann der Sammler jedoch keine Garantie für die Beobachtungsreihenfolge ableiten. Der Begleitentwurf schlägt geordnete Vorlagen-Sets vor: Die Messkomponente hält die beobachtete Folge fest, der Exporteur erhält und signalisiert sie, der Sammler deutet das n-te Vorkommen als n-te Beobachtung. Eine nachträglich hübsch sortierte Tabelle ist kein Ersatz für diese Kette.

Die Garantie gilt für jedes Informationselement für sich. Das zweite mplsLabelStackEntry und das zweite mplsLabelType beschreiben dieselbe Tiefe, weil beide Definitionen ihr zweites Vorkommen an Position zwei binden. Zwischen verschiedenen Elementen verspricht der Entwurf keine relative Reihenfolge im Paket. Wer aus ihrer Nachbarschaft eine zusätzliche Beziehung folgert, fügt dem Protokoll eine nicht zugesagte Aussage hinzu.

Bei der Einführung entscheidet auch der Empfänger. Abschnitt 7 rät, die geordneten Sets nur für Sammler einzuschalten, deren Unterstützung bekannt ist. Ein alter Sammler kann das komplette Set ohne Fehlermeldung verlieren. Beide Exportformen müssen während der Umstellung nebeneinander existieren. Ein aktualisierter Sender mit einem unveränderten Empfänger kann die Beobachtung verschlechtern.

Im Datatracker steht das Dokument als aktiver individueller Internet-Draft. Die fünf neuen IDs tragen im IANA-Antrag noch den Platzhalter TBD. Ein Interoperabilitätstest mit absichtlich fehlender Eigenschaft in der Mitte, samt gesendeter Vorlage und rekonstruierten Positionen, würde zeigen, ob Software die Grenze tatsächlich einhält.

Quellen