Résumé

  • RFC 3020 proposait quatre classes d’activation : au moins une liaison, toutes les liaisons, un nombre défini par seuil, ou une règle propre à l’implémentation.
  • La transition du faisceau vers up prouvait que cette condition était satisfaite ; elle ne prouvait ni la capacité nominale, ni l’absence de pertes ou de désordre, ni le résultat observé par un destinataire.

La règle a changé, pas les circuits.

Avec trois liaisons actives sur quatre, un faisceau soumis à la classe B restait down. Le même ensemble de liaisons devenait up si l’opérateur passait en classe A, où une seule liaison suffisait, ou en classe C avec un seuil inférieur ou égal à trois. La transition pouvait être exacte sans qu’aucun câble, modem ou circuit distant ait changé d’état.

Cette possibilité donne à RFC 3020 sa portée historique. Le document, publié en décembre 2000, définissait les objets gérés de la fonction Multilink Frame Relay UNI/NNI issue de FRF.16. Son sujet paraît ancien. Sa leçon ne l’est pas : l’état d’un agrégat est le résultat d’un prédicat choisi, et non une propriété naturelle indépendante de toute politique.

L’agrégat avait une identité différente de ses membres

MFR regroupait une ou plusieurs liaisons physiques en un faisceau logique. Ce faisceau émulait une interface physique pour la couche Q.922 et devait conserver l’ordre des trames malgré leur répartition entre plusieurs chemins.

La gestion devait donc représenter les membres et l’ensemble. Chaque liaison figurait dans l’Interface MIB avec son ifIndex. Le faisceau y figurait aussi comme interface logique. Mais la table propre à MFR utilisait mfrBundleIndex, choisi par le manager lors de la création, tandis que l’agent attribuait l’ifIndex générique.

RFC 3020 prévoyait des tables de correspondance dans les deux sens. Deux indices différents pouvaient désigner le même faisceau vu depuis deux espaces de gestion. Omettre la correspondance rendait les journaux difficiles à relier et pouvait faire confondre un changement d’identifiant avec un changement d’objet.

La création restait une étape distincte. mfrBundleRowStatus=createAndGo demandait la création du faisceau et amenait l’agent à créer l’interface générique. createAndWait pouvait être proposé. Une liaison de faisceau utilisait l’ifIndex de son interface physique et devait référencer un faisceau existant. Sans mfrBundleLinkConfigBundleIndex valable, sa ligne restait notReady.

Une ligne créée attestait la présence de la configuration. Elle ne disait pas que le protocole de la liaison était monté, que le prédicat d’activation était vrai ou que les trames arrivaient.

Quatre classes, quatre sens du même vert

La classe A activait le faisceau dès qu’au moins une liaison était up. La classe B exigeait toutes les liaisons. La classe C utilisait le nombre indiqué par mfrBundleThreshold. La classe D laissait la règle à l’implémentation. La classe A était la valeur par défaut.

En classe C, atteindre le seuil faisait passer le faisceau à l’état opérationnel actif ; tomber en dessous le rendait inactif. Lorsque le seuil n’avait pas de sens, l’objet devait renvoyer -1. Pour la classe D, son emploi dépendait de l’implémentation.

Les notifications du faisceau suivaient exactement cette logique. Le trap linkUp était émis lorsque ifOperStatus passait de down à up parce qu’un nombre suffisant de membres était opérationnel. LinkDown signalait le passage inverse quand le nombre devenait insuffisant.

Un centre de supervision pouvait conserver le trap mais perdre son explication. Sans classe, seuil, nombre configuré et nombre actif au même instant, le mot up n’était plus reproductible.

Sur quatre liaisons, une classe A pouvait être verte avec un seul membre. Une classe B pouvait rester rouge avec trois. En classe C à deux, la deuxième liaison changeait le bit global ; les deux suivantes changeaient la capacité sans changer le bit. En classe D, l’observateur avait besoin du code ou de la documentation de l’implémentation.

Le statut était donc vrai relativement à une règle. Changer la règle changeait la vérité opérationnelle publiée.

La capacité et l’intégrité disposaient d’autres compteurs

RFC 3020 séparait le nombre de liaisons configurées, le nombre de liaisons actives et la bande passante disponible. Un faisceau up ne garantissait pas l’égalité entre les deux premiers nombres. La bande passante déclarée ne garantissait pas davantage le débit obtenu par une application.

La MIB décrivait aussi la fragmentation, la taille maximale des fragments, la taille du numéro de séquence et le différentiel maximal de délai. Chaque liaison pouvait rapporter son délai aller-retour. Ces valeurs répondaient au travail propre à l’agrégation : répartir, transporter puis remettre en ordre.

mfrBundleResequencingErrors comptait des événements de réordonnancement. Le RFC avertissait qu’un événement pouvait correspondre à plusieurs trames perdues. Dans son exemple, recevoir 56, 59 et 60 et conclure à la perte de 57 et 58 augmentait le compteur d’une unité, pas de deux.

La différence est essentielle pour l’audit. Une hausse d’une unité prouvait un événement enregistré ; elle ne donnait pas un nombre de trames perdues. Une valeur stable ne prouvait pas non plus une livraison parfaite sans connaître les remises à zéro, les discontinuités, les périodes de collecte et les pannes non couvertes.

D’autres compteurs suivaient les trames de contrôle invalides, les expirations de timer, les boucles soupçonnées, les séquences inattendues et les incohérences de nom de faisceau. Le trap de mismatch rapprochait noms configurés et noms annoncés par l’autre extrémité. Même les valeurs dites configurées pouvaient avoir été produites automatiquement.

L’alarme prouvait un désaccord entre vues. Elle n’attribuait pas, à elle seule, la faute au manager local, à l’extrémité distante, à l’automatisation ou à un état périmé.

Assouplir le seuil pouvait ressembler à une réparation

La classe d’activation, le seuil, plusieurs timers, la fragmentation et la taille de séquence étaient déclarés read-create. Les lignes de faisceau et de liaison pouvaient aussi être créées, changées ou supprimées, et un manager pouvait choisir l’appartenance d’une liaison.

Le maximum d’accès de la MIB ne prouvait cependant pas l’existence de l’écriture sur chaque produit. Les clauses de conformité autorisaient un accès minimal en lecture seule pour plusieurs objets, tout en exigeant que la valeur appliquée soit publiée. Déclaration du schéma, capacité de l’agent et autorisation du principal restaient distinctes.

Quand l’écriture existait, abaisser le seuil de trois à deux pouvait transformer le même état physique en état suffisant. Passer de la classe B à la classe A avait un effet similaire. Dire ensuite que « le réseau est revenu » aurait confondu réparation et redéfinition du minimum acceptable.

La section sécurité signalait le danger des SET non protégés. SNMPv1 ne permettait pas, à lui seul, de déterminer qui pouvait lire, changer, créer ou supprimer ces objets, même sur un réseau protégé autrement. Le texte recommandait USM et VACM de SNMPv3 et rendait l’opérateur responsable de l’autorisation correcte.

Authentifier le manager ne décidait pas si son nouveau seuil respectait un engagement de capacité. L’autoriser à écrire ne fournissait pas un reçu de livraison.

Le document définissait un vocabulaire, pas un déploiement

RFC 3020 a le statut Proposed Standard. RFC 9141 l’a ensuite mis à jour uniquement pour remplacer des références au service FTP de l’IETF retiré. Les classes et la signification de l’état opérationnel n’ont pas été réécrites par cette mise à jour.

Les sources établissent donc une architecture de gestion. Elles n’établissent ni implémentation particulière, ni déploiement, ni disponibilité mesurée, ni incident, ni succès commercial. Cet article ne transforme pas une spécification en recensement d’usage.

Les Reality Layers de Lu Heng séparent la ligne de configuration, la règle d’activation, l’état des membres, la projection du faisceau, les erreurs de trame et le résultat chez le destinataire. Running-Code Primacy est décisif pour la classe D, explicitement propre à l’implémentation. Minimum Initial Specification rappelle qu’une MIB bornée pouvait coordonner l’exploitation sans prétendre couvrir le service de bout en bout.

Ces lectures sont déclarées comme telles. Lu Heng n’a ni écrit ni approuvé RFC 3020.

Le bon compte rendu n’était pas « le faisceau est opérationnel ». C’était : « selon cette règle, sur cette population de liaisons, le minimum choisi est atteint ». Le reste exigeait d’autres preuves.

Sources