Résumé
- RFC 9160 définit cinq valeurs
mplsTopLabelType(46)afin qu’un export IPFIX distingue des contextes d’attribution Segment Routing plutôt que de faire parler seul un numéro de label. - Cette précision aide à instruire une observation limitée ; elle ne prouve ni une migration de réseau, ni un chemin actif, ni un résultat de service.
Un chiffre compact donne une impression trompeuse de certitude. Dans MPLS, le label au sommet de pile est observable ; dans IPFIX, il peut être compté, joint à d’autres champs et présenté comme une catégorie. Mais « observé » ne signifie pas « expliqué ». Le problème traité par RFC 9160 est exactement ce raccourci entre la valeur et la provenance.
Publié en décembre 2021 comme RFC IETF Informationnel, le texte a Thomas Graf, de Swisscom, pour auteur unique. Il ajoute cinq points de code au champ IPFIX déjà existant mplsTopLabelType(46) : Path Computation Element, Segment Routing OSPFv2, Segment Routing OSPFv3, Segment Routing IS-IS et BGP Segment Routing Prefix-SID. Ils permettent à un export de qualifier le trafic selon le contexte du protocole de plan de contrôle MPLS SR défini pour ce type de label.
Pourquoi cette qualification est-elle nécessaire ? RFC 9160 indique que les adjacency SIDs IGP, LDP et les labels BGP dynamiques peuvent partager une même plage d’attribution. La même valeur visible peut donc correspondre à plusieurs histoires de contrôle. Déduire le protocole de la seule valeur revient à attribuer au champ une sémantique que son encodage ne garantit pas.
Le RFC propose des usages de surveillance, non une déclaration de succès. Il cite la migration de LDP vers IS-IS ou OSPF Segment Routing, et celle de labels BGP dynamiques vers des BGP Prefix-SIDs. Si l’on associe le type de label à d’autres éléments IPFIX explicitement cités — adresses du label supérieur, section de pile, état de transfert — on peut inférer des volumes de paquets transférés ou abandonnés, des raisons possibles d’abandon, ainsi que l’adresse loopback de bord de fournisseur et le protocole de label. Cette possibilité est utile parce qu’elle ajoute d’abord la distinction que la question exige.
Elle ne transforme pas pour autant l’export en certificat d’exploitation. Le RFC ne dit pas qu’un exportateur particulier est activé, qu’un collecteur a reçu un jeu complet, qu’un enregistrement est authentique, ni que l’observation couvre le chemin qui intéresse l’enquête. Le champ typé ne démontre pas qu’une migration a commencé ou fini, qu’une politique a été installée, qu’un paquet est arrivé à destination ou qu’un client a subi — ou évité — un effet de service.
La séparation des deux valeurs BGP est particulièrement parlante. Le point de code BGP 4 existant désigne la valeur de label de l’attribut de chemin MP_REACH_NLRI. Le nouveau point de code 10, BGP Segment Routing Prefix-SID, désigne une valeur d’index de label dans un TLV Label-Index. Le mot BGP recouvre deux objets distincts ; RFC 9160 refuse que le nom commun les rende interchangeables. Le type de label indique quel objet l’export prétend décrire, pas tout ce qui s’est produit autour de lui.
La méthode de Lu Heng, reprise ici par Sofia Ren, invite à garder la plus petite proposition vérifiable. Une publication et un registre coordonnent les mots ; ils ne fabriquent pas une réalité d’exécution inconnue. Le fait défendable est qu’un exportateur a représenté un type d’attribution de label supérieur spécifié dans un enregistrement IPFIX, avec un point d’observation et un dispositif de collecte déterminés. Une conclusion sur la migration, le transfert ou le service doit avoir d’autres preuves et d’autres responsables.
Une enquête robuste conserve donc le fichier brut, l’identité de l’exportateur, le point d’observation, l’intervalle de collecte, le modèle, la frontière d’intégrité et les champs effectivement joints. La question du plan de contrôle demande une trace de plan de contrôle ; la question du transfert demande une preuve de transfert ; la question d’un résultat client demande une télémétrie de service. Le numéro n’est pas une économie de ces vérifications. Son type non plus.
La contribution de Graf est une discipline de vocabulaire opérationnel. Elle permet d’éviter qu’un observateur prête à un numéro nu une provenance qu’il ne contient pas. Le résultat n’est pas une affirmation plus vaste ; c’est un dossier dans lequel le fait d’export reste séparé de l’histoire de réseau qu’il faudrait encore établir.
Sources
- RFC 9160 — Informations de type de label Segment Routing MPLS dans IPFIX
- IANA — Éléments d’information IPFIX
- RFC 7012 — Modèle d’information IPFIX
- RFC 8660 — Segment Routing avec le plan de données MPLS
- IETF Datatracker — Thomas Graf
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
