Résumé

  • Le nouveau projet individuel définit cinq éléments d'information MPLS génériques destinés à se répéter dans un modèle IPFIX ordonné. Si l'adresse IPv4, l'adresse IPv6 ou la longueur de préfixe manque à la position K, l'exportateur ne doit envoyer aucune occurrence de ce même attribut pour K ni pour les positions plus profondes. Le relevé ne peut pas faire passer la position K+1 pour K.
  • Le texte maintient les anciens éléments positionnels du registre IANA, s'appuie sur un autre projet consacré à l'ordre et avertit qu'un collecteur ignorant les nouveaux ensembles peut les perdre sans alerte. Les cinq nouveaux numéros IANA restent à déterminer.

La pile garde sa profondeur malgré le blanc

Prenons trois étiquettes MPLS. Le dispositif de mesure voit trois entrées de pile et connaît l'adresse de prochain saut de la première et de la troisième, mais pas celle de la deuxième. Un export naïf enverrait deux adresses. Le collecteur lirait la première occurrence comme position un, la deuxième comme position deux. L'adresse de la troisième étiquette serait attachée à la deuxième. Les deux valeurs exportées pourraient être exactes; leur association à la pile serait fausse.

La section 4.7 du projet du 28 octobre interdit cette compression. Pour mplsLabelIPv4Address, mplsLabelIPv6Address ou mplsLabelPrefixLength, une valeur indisponible à la position K coupe la suite de ce champ à K et en dessous. Les occurrences doivent former une séquence continue depuis le sommet. Le projet exclut les sous-ensembles clairsemés. La troisième étiquette reste dans la pile, et un autre élément peut toujours la décrire correctement; l'attribut tronqué, lui, n'a plus le droit de prétendre la situer.

Le type d'étiquette obéit à une autre règle. Quand mplsLabelType n'est pas connu à la position K, l'exportateur envoie 0, Unknown. La place reste occupée par un aveu précis d'ignorance. Pour l'adresse et le préfixe, le projet ne donne pas de valeur de remplacement comparable. Il arrête la série. Cette différence est capitale pour quiconque transforme un flux IPFIX en graphique: « inconnu à la deuxième position » et « plus de positions exportables pour ce champ » ne sont pas la même information.

Pourquoi ajouter une grammaire aussi exigeante? Le registre IPFIX de l'IANA compte déjà dix éléments distincts pour les sections de pile MPLS, les numéros 70 à 79. Chacun porte sa position dans son nom: étiquette du haut, deuxième, puis jusqu'à la dixième. Le nouveau projet propose de répéter mplsLabelStackEntry et quatre attributs génériques dans un ensemble ordonné. Il ne retire pas les éléments existants. Un collecteur ancien a encore besoin de l'ancien vocabulaire.

Le contenu de l'entrée change aussi de taille. RFC 3032 définit une entrée MPLS complète sur quatre octets: valeur d'étiquette, classe de trafic, bit de fin de pile et TTL. Les éléments positionnels actuels n'exportent que trois octets et omettent le TTL. Le nouvel élément générique en prend quatre; on peut donc lire le TTL d'une étiquette profonde, au prix d'un octet de plus par étiquette lorsqu'on n'en a pas besoin. Le gain d'observation doit payer sa place dans le flux.

L'ordre n'est pas un souhait du collecteur

RFC 7011 permet de répéter un élément d'information dans un modèle IPFIX. Un modèle ordinaire ne donne toutefois pas au collecteur la garantie que ces occurrences suivent l'ordre des observations. Le projet compagnon crée des ensembles de modèles ordonnés: le processus de mesure conserve la succession observée, le processus d'export la préserve et la signale, puis le collecteur lit la n-ième occurrence comme la n-ième observation. Ce contrat traverse trois processus; le nom d'un champ seul ne suffit pas.

Chaque élément reçoit sa propre garantie d'ordre. La deuxième occurrence de mplsLabelStackEntry et la deuxième de mplsLabelType correspondent à la même profondeur parce que leurs définitions rattachent chacune le rang deux à la deuxième étiquette. Aucun ordre relatif entre deux éléments différents n'est promis. Reconstituer le reste d'après leur voisinage matériel dans le message ajouterait une relation que le texte ne garantit pas.

Le passage aux nouveaux ensembles pose enfin un problème de destinataire. La section 7 recommande de n'activer l'export ordonné que vers des collecteurs qui savent le lire. Les autres peuvent éliminer silencieusement l'ensemble entier. Pendant la migration, les anciens champs positionnels et les nouveaux champs génériques doivent cohabiter. Un exportateur enrichi associé à un collecteur sourd peut produire un inventaire plus pauvre qu'avant la mise à jour.

Le Datatracker classe le texte comme projet individuel actif. Ses cinq identifiants d'éléments sont encore TBD dans la demande à l'IANA. Il manque une trace d'essai où l'attribut de la deuxième étiquette est volontairement absent, montrant le modèle émis et la profondeur reconstruite par le collecteur. Cette trace dira si le refus de « combler le trou » tient dans le logiciel.

Sources