Résumé

  • La RFC 5654, document Standards Track de septembre 2009 dont Deborah Brungard est l'une des éditrices, dit que ses exigences MPLS-TP portent sur le comportement de mécanismes et de procédures formant des briques. Elle précise qu'il ne s'agit pas d'exigences d'implémentation et qu'elle ne décrit pas les fonctions qu'une implémentation MPLS-TP supporte.
  • Le texte permet l'établissement statique ou dynamique des chemins et indique qu'un réseau MPLS-TP peut fonctionner pleinement, OAM et protection compris, sans plan de contrôle. Ce sont des possibilités encadrées, non la preuve d'un choix actuel d'opérateur, d'un chemin installé, d'une protection déclenchée ou d'un résultat de SLA.

Le profil indique un outillage, pas une décision de réseau

Le mot « profil » peut faire croire qu'une forme finale a déjà été choisie : des équipements conformes, une topologie et peut-être un service prêt à être vendu. La RFC 5654 emploie un langage plus étroit. Son objet est d'identifier les exigences d'un MPLS Transport Profile. Ces exigences concernent le comportement des mécanismes et procédures de protocole qui constituent les briques à partir desquelles ce profil se construit. Elles ne sont pas des exigences d'implémentation.

La conséquence apparaît dans l'introduction : le document identifie les fonctions qui doivent être disponibles dans l'outillage MPLS ainsi que le nouveau travail de protocole nécessaire. Il ne dit pas quelles fonctions une implémentation MPLS-TP prend en charge. Il s'agit d'une spécification d'exigences, placée sur la voie Standards Track afin de pouvoir être citée de façon normative dans les travaux de l'UIT-T. Une référence commune peut donc être essentielle sans devenir l'inventaire d'un produit ni une instruction imposant à un opérateur un modèle d'exploitation donné.

Il faut distinguer au moins quatre choses. L'outillage décrit les possibilités prévues par un cadre commun. L'implémentation a sa version, son périmètre de support et ses limites d'interopérabilité. L'opérateur choisit ensuite la topologie, la méthode de provisioning, la politique de protection et le calendrier de migration. Enfin, le service doit être observé à sa frontière réelle. La présence d'une capacité dans un RFC ne fournit aucune de ces preuves ultérieures.

Statique, dynamique et sans plan de contrôle ne sont pas le même état

La RFC 5654 indique que les chemins de transport MPLS-TP peuvent être établis par configuration statique ou dynamique. Elle ajoute que le réseau et ses chemins peuvent toujours être exploités complètement, avec OAM et protection, en l'absence de tout plan de contrôle. Le document conserve ainsi plusieurs surfaces opérationnelles. Il ne désigne pas celle que doit prendre un réseau identifié.

La section sur le plan de contrôle maintient cette séparation. Il doit être possible d'exploiter un réseau MPLS-TP sans plan de contrôle. Lorsqu'il existe, le plan de contrôle doit permettre l'indépendance des topologies de contrôle et de données ; une panne du premier n'implique donc pas une panne du second. Il doit aussi pouvoir fonctionner indépendamment de plans de contrôle particuliers des couches client ou serveur.

Ces exigences interdisisent surtout les raccourcis. Une possibilité dynamique ne prouve pas qu'elle est activée. Une option de provisioning statique ne prouve pas qu'une configuration statique est présente. La distinction entre deux types de panne ne prouve pas l'état de santé de l'un ou l'autre. De même, une exigence relative à l'OAM ou à la protection ne montre ni qu'un basculement s'est produit, ni qu'il était correctement configuré, ni que le trafic client a été protégé. Chaque affirmation doit venir du système qui la possède.

Le texte conserve les limites entre responsabilités administratives

La RFC note que des groupes administratifs différents peuvent être responsables d'un même réseau de couche ou de réseaux de couches distincts. Elle exige qu'il soit possible de masquer aux couches clientes l'adressage et d'autres informations telles que la topologie. L'opérateur peut, à son choix, laisser passer une quantité limitée d'information résumée, par exemple sur des SRLG ou l'atteignabilité.

La règle commune est volontairement modeste. Elle rend une frontière possible sans la supprimer. Une couche cliente n'acquiert pas automatiquement le droit de connaître toute la topologie sous-jacente ; une implémentation ne révèle pas par elle-même le modèle administratif d'un opérateur. Si une synthèse est publiée, sa source, son périmètre, sa fraîcheur et sa politique restent des faits à établir. Si elle ne l'est pas, aucun lecteur ne peut reconstruire une topologie universelle fictive à partir des mécanismes possibles du RFC.

Les justificatifs doivent venir du système en exploitation

Une affirmation concrète sur un transport exige une chaîne plus longue que le document. L'éditeur ou l'intégrateur peut attester de la version et des fonctions supportées. Les systèmes de gestion ou de contrôle peuvent montrer la méthode de provisioning, l'intention de chemin et l'action de signalisation. Le plan de transfert peut montrer l'état installé et les compteurs. L'OAM peut préciser ce qui a été testé, quand et entre quels points. Les données de protection peuvent documenter le déclencheur et le résultat. Les mesures de service peuvent enfin établir un résultat du point de vue du client.

La RFC ne remplace aucune de ces pièces. Elle fournit le vocabulaire partagé avec lequel ces systèmes peuvent être conçus. Elle ne prouve ni matrice de support fournisseur, ni inventaire, ni topologie, ni chemin, ni flux, ni panne, ni événement de protection, ni expérience client. La traiter comme une telle preuve revient à faire de la norme l'opérateur et de la capacité disponible le déploiement.

La distinction rejoint l'idée de Heng Lu selon laquelle une spécification commune minimale coordonne ce qui doit être commun, tandis que les décisions ultérieures restent localisées chez ceux qui font fonctionner les systèmes. Un artefact de coordination ne devient pas une réalité opérationnelle parce qu'il a été publié. La prudence de la RFC 5654 — un outillage sans mandat d'implémentation universel — est donc une force.

Créditer Deborah Brungard sans lui prêter une autorité inexistante

La RFC cite Ben Niven-Jenkins, Deborah Brungard, Malcolm Betts, Nurit Sprecher et Shigeru Ueno comme éditeurs. Le profil IETF de Brungard permet son identification et fournit la provenance de la photo publique qui fonde le portrait éditorial. Cela soutient un crédit précis : elle a édité un document collaboratif d'exigences.

Ces sources ne prouvent pas qu'elle a écrit seule la RFC, choisi une implémentation ultérieure, dirige aujourd'hui l'IETF ou l'UIT-T, exploite le réseau d'un opérateur ou garantit un service de transport. Le crédit limité est plus solide : il reconnaît le travail sur une frontière commune tout en laissant aux personnes qui implémentent, configurent, observent et assument le réseau leur responsabilité propre.

Limites des preuves

Les sources établissent le contenu de la RFC 5654 et ses limites explicites. Elles n'établissent pas l'usage actuel de MPLS-TP par un opérateur donné, un lieu de déploiement, un chemin en service, une topologie, un état du plan de contrôle, un résultat OAM, une action de protection, un flux ou une expérience client. La chaîne de justificatifs proposée est une lecture opérationnelle de ces limites, non une obligation ajoutée au RFC.

Sources