Résumé

  • Les RFC 9833–9836 donnent des modèles distincts au support sous-jacent, à l’AC commandé par le client, à l’AC réalisé par le fournisseur et aux références qui lient ces objets aux VPN de niveau 2 ou 3.
  • Une demande validée peut rester awaiting-processing. De plus, les identifiants de service et de réseau peuvent obéir à des conventions différentes : ni l’acceptation ni l’égalité des noms ne prouvent la réalisation.
  • La preuve utile se poursuit jusqu’au placement PE/SAP, à la liaison VPN, à la configuration prévue puis appliquée, à l’état opérationnel, à l’OAM et au trafic. Chaque étape a son autorité propre.

Le bon de commande existait. Le circuit que le réseau devait porter n’existait pas encore sous la forme que ce bon semblait promettre.

Cette situation n’est pas, à elle seule, un incident ni une tromperie. Elle est inscrite dans l’architecture des RFC 9833, RFC 9834, RFC 9835 et RFC 9836. Publiés en septembre 2025 sur la voie des normes, ces textes répartissent la commande et sa réalisation entre plusieurs modèles YANG reliés. Le découpage évite qu’un statut commercial devienne, sans preuve, un fait de réseau.

Les notices des RFC 9833, RFC 9834, RFC 9835 et RFC 9836 établissent le consensus de l’IETF et l’approbation de l’IESG. Elles n’établissent ni adoption par un opérateur, ni conformité d’un contrôleur, ni mise en service d’un accès particulier. La norme décrit les distinctions que le code devrait conserver ; elle ne remplace pas les traces produites par ce code.

Un support peut porter plusieurs réalités commerciales

Le bearer est le lien filaire ou radio sous-jacent. L’attachment circuit est l’agencement construit au-dessus de ce support pour permettre l’échange entre une terminaison client et le réseau du fournisseur. Un support peut porter plusieurs AC. Un AC peut concerner plusieurs équipements clients ou plusieurs SAP pairs. Un équipement client peut terminer plusieurs AC.

Cette multiplicité interdit un raccourci fréquent. Le support disponible ne garantit pas que l’AC demandé est lié au bon service. Inversement, la résiliation d’un AC ne donne pas l’autorité de supprimer le support partagé ou les services voisins.

Dans la RFC 9834, le fournisseur peut attribuer une référence de bearer, que le client récupère puis réutilise dans sa demande d’AC. Il peut accepter ou rejeter les identifiants proposés par le client. L’identifiant d’AC n’est unique que dans le domaine du fournisseur. Il faut donc conserver l’émetteur, la portée et la résolution actuelle de la référence ; le texte seul n’est pas une identité universelle.

Le modèle client ne décrit pas l’atelier du fournisseur

La RFC 8309 définit le modèle de service client comme la description de ce que le client demande ou perçoit, et non de la manière dont l’opérateur l’ingénierise. La RFC 9834 applique cette séparation aux AC. Le client peut exprimer son besoin sans connaître le PE, le SAP, l’interface ou la technologie retenus.

Cette ignorance est volontaire. Elle rend la demande portable entre des architectures internes différentes. Elle signifie aussi que l’objet client n’est pas une preuve du placement qu’il masque. Une réponse positive doit être conservée comme reçu de commande : principal authentifié, autorisation, référence de bearer ou de SAP pair, identifiant d’AC de service, paramètres et état administratif.

La RFC 9833 prévoit notamment awaiting-validation, awaiting-processing, admin-prohibited et rejected. awaiting-processing peut suivre l’approbation et la validation alors que le travail d’activation reste à faire. Une interface qui traduit cet état par « actif » produit une certitude que le modèle ne fournit pas.

Le réseau attribue sa propre identité

La RFC 9835 définit ietf-ac-ntw. Ce modèle interne associe la référence de service à l’AC effectivement géré dans le réseau et précise le placement PE/SAP. C’est le passage de la demande abstraite vers une ressource localisée.

La RFC dit explicitement que les conventions de nommage du service et du réseau dépendent du déploiement. Les deux noms peuvent coïncider ; aucune règle ne permet de le présumer. L’arête de référence, et non la ressemblance des chaînes, prouve la correspondance. Une jointure implicite par nom peut relier la télémétrie à la mauvaise commande après migration, renommage ou réutilisation.

Même l’existence de l’objet réseau ne prouve pas l’application. La RFC 8969 place les modèles réseau entre le service et les paramètres d’équipement. Elle demande aussi que l’état opérationnel et les statistiques remontent pour permettre la corrélation. Une intention d’orchestration reste une intention tant que le plan inférieur n’a pas répondu.

Le glue relie ; il ne livre pas

La RFC 9836 ajoute ietf-ac-glue pour relier les AC aux modèles VPN. Elle complète le modèle de service L3VPN de la RFC 8299, le modèle de service L2VPN de la RFC 8466 et le modèle réseau L3VPN de la RFC 9181. Les RFC 8345 et RFC 9543 éclairent les surfaces voisines de topologie et d’assurance.

La référence glue affirme une association modélisée entre un VPN et un AC. Elle n’affirme pas que les ressources existent, que la configuration a été posée, que le site est joignable ou que l’objectif de service est tenu. Sur un AC partagé, elle ne transforme pas l’autorité d’un service en droit d’agir sur tous les autres.

Le défaut le plus trompeur peut donc être un graphe cohérent en apparence : l’AC de service pointe vers l’AC réseau A, tandis que le VPN pointe vers B. Tous les objets sont présents. Tous les identifiants sont valides. Seule la relation est fausse, et un contrôle fondé sur la simple présence ne la verra pas.

La configuration prévue n’est pas l’état constaté

La RFC 8342 distingue les valeurs configurées, la configuration prévue et l’état opérationnel. Délais, matériel, protocoles et dépendances peuvent les séparer. La comparaison de <intended> et <operational> mesure ce qui est réellement en usage ; elle ne peut être remplacée par la date d’acceptation de la commande.

La chaîne de preuve complète authentifie et autorise le demandeur, résout le bearer, accepte l’AC de service, le mappe vers l’AC réseau, choisit PE/SAP/interface, lie le bon VPN, produit la configuration prévue, constate la configuration appliquée et l’état, puis mesure séparément OAM, accessibilité, trafic et résultat de service.

La RFC 7950 fournit YANG mais n’impose pas un orchestrateur unique. La diversité interne demeure possible à condition de conserver les références partagées. La RFC 9408 rappelle par ailleurs l’importance de l’analyse de sécurité des modules YANG. Ces sources ne signalent aucune fuite ni compromission particulière ; elles indiquent où l’autorisation doit être vérifiée.

La doctrine de Heng Lu sur la spécification initiale minimale et les décisions futures localisées se lit ici comme une règle d’exploitation : partager des références déterministes, sans uniformiser les choix internes. La primauté du code en fonctionnement déplace l’audit vers les traces réelles. Enfin, la réalité plutôt que le plaidoyer borne le constat : quatre normes donnent une grammaire de contrôle, pas un certificat de livraison.

Sources