Résumé

  • La révision 18 impose six niveaux : deux étiquettes explicites, une combinaison explicite avec any, une étiquette externe, priority-tagged, untagged, puis default. Deux règles du même niveau ne peuvent pas sélectionner la même trame.
  • Ce classement ferme une ambiguïté de configuration. Il faut encore rapprocher état appliqué, compteurs isolés, captures avant et après réécriture, état de transfert et constat au point distant.

Une trame S-VLAN 10/C-VLAN 21 arrive sur un trunk. Quatre sous-interfaces paraissent candidates : 10/21, 10/any, une règle portant seulement sur 10, et la règle par défaut. La question n’est pas académique. Une attribution différente peut placer le trafic dans un autre service, lui appliquer une autre réécriture ou le conduire vers une impasse.

La révision 18 donne une réponse normative. Deux correspondances explicites ou par plage passent en premier. Vient ensuite le couple où un côté est explicite et l’autre vaut any. La règle à une seule étiquette externe arrive troisième; priority-tagged, untagged et default ferment la marche. Au sein d’un niveau, tout chevauchement susceptible de capturer la même trame doit être refusé. Le modèle ne laisse donc pas l’ordre de création ou une préférence propriétaire départager deux concurrents égaux.

Une hiérarchie n’est pas une observation

Cette hiérarchie permet de prédire que 10/21 appartient à la règle à deux étiquettes. Elle ne démontre pas qu’un équipement a chargé le module, appliqué le jeu de règles au bon ASIC, sélectionné cette entrée pour la trame testée ou attaché la sous-interface au service attendu.

Le périmètre de lecture compte autant que l’ordre. Le modèle examine au plus deux étiquettes 802.1Q. Pour deux étiquettes, l’externe est une S-VLAN et la seconde une C-VLAN. match-exact-tags ne modifie jamais la priorité. Il exige seulement que les étiquettes lues constituent toute la pile. Sans cette option, des étiquettes supplémentaires peuvent suivre, mais deviennent un contenu opaque pour la classification et la réécriture du modèle.

Un essai 10/21 ne renseigne donc pas automatiquement sur 10/21/300. Il faut injecter les deux cas, avec et sans exigence d’exactitude, et capturer les octets réellement présentés au port.

Le cas par défaut dépend de ce qui l’entoure

default ne signifie pas « tout ». Il signifie « ce qu’aucune encapsulation plus précise d’une sous-interface sœur n’a pris ». Sa preuve exige le jeu complet de règles concurrentes. Une capture de configuration limitée à la sous-interface par défaut retire précisément le contexte qui explique sa décision.

De même, priority-tagged n’est pas untagged. La première trame porte encore une étiquette 802.1Q; la seconde n’en porte pas. Une capture d’entrée établit cette différence. Le nom d’un scénario dans un outil de test ne l’établit pas.

Le modèle sépare lui-même classification et service

Après la classification, la fonction flexible peut retirer ou ajouter jusqu’à deux étiquettes externes. Une traduction combine retrait et ajout; seules les étiquettes effectivement appariées peuvent être retirées. Les transformations peuvent être symétriques, ou distinctes par direction si les fonctions correspondantes existent.

L’intention est précise, mais elle reste une intention. L’exemple L2VPN du document montre une sous-interface qui reconnaît une trame et retire une étiquette, mais qui n’est liée à aucun service : le trafic classé est abandonné. On peut donc avoir raison sur le choix de la sous-interface et tort sur la réalité du transfert.

Une preuve en plusieurs points

Le premier reçu est l’identité exacte du module et des fonctions annoncées. Le deuxième est la transaction NETCONF ou RESTCONF acceptée. Le troisième compare l’intention à l’état réellement appliqué. RFC 8342 explique qu’une configuration peut rester dans l’intended sans apparaître dans l’operational lorsque des ressources manquent ou que l’application n’aboutit pas.

Vient ensuite l’essai de trafic. Relever les compteurs du parent et de toutes les sous-interfaces candidates, injecter une seule classe, puis relever les différences. Le projet d’extensions d’interface définit in-discard-unknown-encaps; RFC 8343 fournit les compteurs communs de paquets, d’octets et d’abandons. Une hausse sur la seule cible, accompagnée de l’immobilité des pairs, renforce la conclusion de classification.

Mais un compteur agrège. Il ne montre ni les octets, ni un abandon ultérieur. Une capture à l’entrée prouve la pile reçue; une capture après pop/push prouve la représentation observée à cet endroit. Pour un service L3, une route active issue de RFC 8349 reste un état du plan de contrôle. La FIB, l’adjacence, la sortie attendue et le point distant doivent encore être observés. Pour un L2VPN, il faut contrôler l’attachement local et distant.

La conclusion défendable est volontairement étroite : ce flux, à cet instant, a porté ces étiquettes, alimenté cette sous-interface, quitté ce point avec cette réécriture et été vu à cette destination. L’ordre déterministe rend l’expérience possible; il ne remplace pas l’expérience.

Sources primaires

Le corpus primaire fermé réunit les deux formes publiées de la révision 18, sa fiche Datatracker et son historique, les deux formes de la spécification complémentaire sur les extensions d’interface, ainsi que les RFC 6241, 7950, 7799, 8040, 8341, 8342, 8343 et 8349 : https://www.ietf.org/archive/id/draft-ietf-netmod-sub-intf-vlan-model-18.txt; https://www.ietf.org/archive/id/draft-ietf-netmod-sub-intf-vlan-model-18.html; https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/; https://datatracker.ietf.org/doc/draft-ietf-netmod-sub-intf-vlan-model/history/; https://www.ietf.org/archive/id/draft-ietf-netmod-intf-ext-yang-19.txt; https://www.ietf.org/archive/id/draft-ietf-netmod-intf-ext-yang-19.html; https://www.rfc-editor.org/rfc/rfc6241.html; https://www.rfc-editor.org/rfc/rfc7950.html; https://www.rfc-editor.org/rfc/rfc7799.html; https://www.rfc-editor.org/rfc/rfc8040.html; https://www.rfc-editor.org/rfc/rfc8341.html; https://www.rfc-editor.org/rfc/rfc8342.html; https://www.rfc-editor.org/rfc/rfc8343.html; https://www.rfc-editor.org/rfc/rfc8349.html.