Résumé

  • RFC 9835 conserve, dans le circuit d’attachement réseau, la référence du circuit exposé au niveau service. Cette jointure explique quel objet réalise quelle demande ; elle ne prouve ni le support, ni le transfert, ni le résultat client.
  • Le nom d’un AC réseau est local à un nœud. Les profils hérités, les dérogations locales, les relations parent-enfant et les états administratif et opérationnel doivent rester séparés pour reconstituer la configuration effective.
  • La preuve utile se poursuit après l’acceptation : cible correcte, configuration effective, état observé, OAM dans son périmètre, santé du service complet et trafic client.

Deux systèmes pouvaient avoir raison et le client rester hors ligne

Le portail d’un opérateur accepte une demande de raccordement et attribue une référence stable. Le contrôleur crée un circuit sur un routeur de bord. Les deux systèmes affichent la même référence ; chacun peut donc soutenir qu’il a traité le bon dossier. Pourtant le port physique peut être coupé, le VLAN erroné, le profil de routage ancien ou un autre accès du VPN défaillant.

La correspondance n’est pas inutile. Elle résout une question essentielle : de quel objet parle-t-on ? Mais elle ne répond pas à la question suivante : qu’a réellement exécuté le réseau ?

RFC 9835, dont le registre RFC Editor fixe l’identité et le statut, définit ietf-ac-ntw, un modèle réseau YANG pour les circuits d’attachement. Le modèle peut préparer un AC avant le service ou pendant son activation. Il conserve aussi une référence vers l’AC exposé au client. La norme organise donc une chaîne de responsabilité ; elle ne transforme pas une clé de jointure en accusé de livraison.

Le support et le circuit ne sont pas le même objet

RFC 9833 appelle « bearer » le lien physique ou logique qui relie le site au réseau du fournisseur. L’AC est la configuration qui permet les échanges sur ce support. Plusieurs AC peuvent partager un même bearer ; un AC peut rejoindre plusieurs points d’attachement homologues ; un point d’attachement de service peut terminer plusieurs AC.

Ces multiplicités sont des informations d’impact. Une rupture de fibre peut atteindre plusieurs AC à la fois. Une erreur propre à un AC ne condamne pas nécessairement le support. Le numéro du support indique où placer un service, pas que ce service existe déjà ni qu’il fonctionne.

RFC 9834 expose supports et AC comme services. RFC 9835 décrit l’objet réseau. RFC 9836 ajoute les références qui lient les modèles de services et de réseaux VPN L2/L3 à ces AC. L’architecture n’efface pas les frontières ; elle permet de les parcourir sans perdre l’identité de chaque étape.

Un inventaire explicable doit donc garder la référence de service, le réseau, le nœud, le nom local de l’AC, le SAP, le bearer et l’époque de la correspondance. Un identifiant global fabriqué après coup simplifie l’écran mais peut produire une fausse continuité.

Même nom ne veut pas dire même portée

RFC 9835 précise que le nom d’un AC réseau est unique dans le périmètre d’un nœud, et non dans tout le réseau. Il précise également que l’emploi de la même convention de nommage aux couches service et réseau dépend du déploiement.

Deux routeurs peuvent donc contenir chacun ac-17. Une référence client peut survivre au déplacement de sa réalisation. La comparaison de chaînes nues serait un rapprochement sans preuve. Le reçu doit contenir le tuple complet et daté : référence de service, réseau, nœud, AC, SAP, acteur qui a créé la correspondance et période de validité.

RFC 8969 situe les modèles de service client, les modèles réseau et les modèles d’équipement à des niveaux distincts. Le passage de l’un à l’autre reste une opération contrôlée. Un vocabulaire commun réduit l’ambiguïté ; il ne garantit pas la justesse de la traduction.

L’état effectif est composé

Pour éviter de répéter les mêmes paramètres, RFC 9835 permet à un AC d’hériter de profils définis au niveau du réseau. Si l’AC affine localement la même donnée, la valeur locale prévaut. L’état effectif résulte donc d’une résolution, pas d’un seul document.

Conserver uniquement le nom du profil rend l’audit aveugle aux exceptions. Conserver uniquement les exceptions fait disparaître l’héritage. Il faut figer la révision du profil, les valeurs héritées, les substitutions locales et l’empreinte de la configuration effective envoyée à la cible. Sans cela, une modification ultérieure du profil peut réécrire l’apparence du passé.

RFC 9836 établit aussi une priorité : lorsque des informations AC référencées recouvrent des paramètres VPN saisis directement, les informations de l’AC l’emportent. Cette règle tranche le conflit d’intention. Elle ne prouve pas que le contrôleur a appliqué la décision de façon atomique ni que tous les équipements l’ont interprétée pareillement.

RFC 8342 distingue notamment la configuration voulue de l’état opérationnel. RFC 8345 fournit le modèle de réseau que RFC 9835 augmente. La présence d’un objet devient alors le début de l’enquête : quelle intention, quelle configuration effective, quelle observation ?

Supprimer le parent étend l’acte

Un AC parent peut porter les propriétés communes à plusieurs AC enfants associés à des SAP homologues particuliers. Les enfants héritent. Quand le parent est supprimé, RFC 9835 exige que tous ses enfants le soient aussi.

La règle évite des objets orphelins, mais elle confère un pouvoir de cascade. Une seule action administrative peut modifier plusieurs accès et services. Le schéma ne démontre ni que l’outil a énuméré les bons enfants, ni que les équipements ont retiré tout état, ni que la facturation et les dépendances clientes ont suivi.

Avant l’acte, un reçu d’impact devrait lister parent, enfants, SAP, services, supports, profils effectifs et état observé. Après l’acte, il devrait comparer l’ensemble attendu aux configurations et au trafic. La disparition de la ligne parente prouve un changement dans le modèle, pas la fin sans dommage du service.

L’administratif doit pouvoir contredire l’opérationnel

RFC 9835 conserve séparément l’état administratif et l’état opérationnel ; leur divergence peut déclencher la détection d’une anomalie. RFC 9833 prévoit notamment des états d’attente de validation, d’attente de traitement, d’interdiction administrative ou de rejet. Aucun ne décrit un paquet.

Une demande approuvée peut attendre. Un AC configuré peut rester hors service. Un port opérationnel peut transporter le mauvais VLAN. Et un AC sain localement ne prouve pas la santé du VPN entier.

RFC 9408 décrit le SAP, point de référence côté fournisseur. Il avertit que l’état d’un service observé à un SAP n’est pas l’état réseau global d’un service reliant plusieurs SAP. Les types communs de RFC 9181, le modèle L3VPN de RFC 9182, le modèle L2VPN de RFC 9291 et le cadre de tranches de RFC 9543 fournissent des contextes plus larges. Aucun état local ne peut les résumer à lui seul.

La chaîne de preuve doit donc distinguer : demande, acceptation et référence ; correspondance vers réseau/nœud/SAP/AC ; calcul des héritages ; soumission aux cibles ; état opérationnel ; test OAM limité ; état de bout en bout ; trafic ou sonde applicative du client.

Les sources ne démontrent aucun déploiement nommé, conformité produit, incident, taux d’adoption, gain financier ni résultat SLA. Elles définissent des mécanismes et des limites. Les pratiques proposées ici sont une analyse opérationnelle, pas une exigence supplémentaire de l’IETF.

Lire la jointure est déjà un pouvoir

Les considérations de sécurité de RFC 9835 signalent que la lecture non autorisée peut révéler l’identité de SAP homologues de clients. Les écritures peuvent toucher routage, chiffrement, clés, filtres et rattachement du service. Celui qui peut modifier la correspondance entre demande et AC réseau peut déplacer plus que des métadonnées.

L’identité commerciale, l’intention réseau et l’état observé devraient donc avoir des droits distincts. Le journal doit nommer l’acteur authentifié, la portée, l’ancienne valeur et la nouvelle. « API réussie » ne suffit pas.

Le mérite durable de RFC 9835 est d’ouvrir une couture contrôlable entre promesse et exécution. La référence devient un outil de responsabilité si elle mène jusqu’à l’observation et au résultat client. Elle devient un décor si elle clôt le dossier à leur place.

Sources