Résumé

  • Le service Ethernet Tree du MEF attribue à chaque circuit d’accès un rôle de racine ou de feuille. Une feuille communique avec les racines, pas avec les autres feuilles ; le VPLS classique traite pourtant les circuits d’accès comme des pairs.
  • Dans son scénario hypothétique à deux équipements de périphérie, la RFC 7152 montre pourquoi l’adresse MAC de destination et la livraison de la trame ne suffisent pas : l’équipement distant ignore le rôle de l’accès d’origine.
  • Le mémo de 2014 formule des exigences — racines multiples, rôles mixtes sur un même équipement, compatibilité ascendante — sans attester un déploiement ni un résultat de service. Des RFC ultérieures décrivent des cadres et mécanismes.

Analyse

La règle était attachée au circuit

Ethernet Tree est un service multipoint à racines. Un circuit racine peut communiquer avec les racines et les feuilles. Une feuille peut joindre une racine, mais le trafic ne doit pas passer d’une feuille à une autre. Ethernet LAN suit une logique différente : ses accès peuvent communiquer entre eux.

La différence devient opérationnelle quand le service traverse le réseau d’un fournisseur. Dans l’exemple de la RFC 7152, deux équipements de périphérie relient chacun une racine et une feuille côté client, puis échangent les trames par un pseudowire. À la réception, le second équipement sait que la trame vient de l’autre équipement. Il ne sait pas nécessairement de quel circuit local elle est partie ni si ce circuit avait le rôle de feuille.

La destination MAC connue ne résout pas ce problème. Elle indique où la trame est adressée, pas le rôle de son circuit d’entrée. Sans cette information, l’équipement distant ne peut pas appliquer de façon fiable l’interdiction feuille-à-feuille aux trames unicast, unicast inconnu, broadcast ou multicast. La RFC précise que son schéma est hypothétique et ne décrit pas un service typique.

Le VPLS transportait la connectivité, pas cette politique

Le modèle VPLS existant traitait les circuits d’accès de façon équivalente et offrait une connectivité de chacun à chacun dans une même instance. C’était utile pour émuler un Ethernet LAN, mais cela ne représentait pas la relation racine-feuille demandée par le MEF. L’information manquante n’était pas une adresse client supplémentaire : c’était une propriété de l’accès au service qui devait rester interprétable après la traversée du cœur du fournisseur.

La RFC 7152 énonce donc des exigences au lieu de déclarer une solution achevée. Une approche conforme devait interdire le trafic entre feuilles, permettre plusieurs racines et autoriser des circuits racine et feuille sur une même périphérie. Elle devait aussi préciser la technologie VPN de couche 2 concernée et limiter les perturbations pour les déploiements VPLS et EVPN existants. Si seuls certains équipements de périphérie prenaient en charge le nouveau comportement, la restriction s’appliquait au périmètre conforme ; le texte ne promettait pas une isolation de bout en bout à travers une partie non compatible.

Le mémo cite des usages possibles : VPN en étoile, accès de gros, transport mobile, synchronisation d’horloges, accès Internet, vidéo et gestion d’équipements. Ce sont des cas d’usage dans un document d’exigences, pas un recensement de services effectivement déployés. Il distingue aussi Ethernet Tree du service multicast alors envisagé par l’IETF : E-Tree permet des flux unicast et multicast soumis aux rôles racine-feuille ; un service multicast ne remplace pas tous ces flux.

Les RFC suivantes ont nommé le contexte manquant

La RFC 7387, publiée plus tard en 2014, propose un modèle d’architecture et nomme deux lacunes : les VPN de couche 2 ne distinguaient pas les rôles des circuits d’accès, et l’équipement distant ne recevait aucune indication sur l’origine racine ou feuille d’une trame. La RFC 7796 a ensuite spécifié le support d’E-Tree dans VPLS au moyen d’identifiants VLAN distincts pour les trames issues d’une racine ou d’une feuille, afin que les équipements filtrent le trafic aux ports feuilles. La RFC 8317 a étendu ce travail à EVPN et PBB-EVPN.

Cette séquence montre le passage d’une règle de service à une exigence technique, puis à des mécanismes protocolaires. Elle ne mesure pas leur adoption, ne prouve pas qu’un fournisseur précis les configurait et ne démontre pas une isolation réelle du trafic client. La RFC 7152 est un document d’exigences informatif, pas un rapport d’incident, une étude de déploiement ou un standard Internet.

La leçon historique est plus précise que « la trame perd sa source ». Elle conserve ses adresses et arrive par un transport. Ce qui peut disparaître à une frontière de couche, c’est la connaissance du fournisseur sur le circuit de service qui donnait à la trame son rôle de transfert. Le réseau peut livrer les bits sans disposer du contexte nécessaire pour respecter le contrat de service.

Sources

La fiche de la RFC 7152 dans le RFC Editor confirme son statut de publication.

La source principale est la RFC 7152, qui définit les exigences et qualifie son scénario à deux équipements d’hypothétique. Les RFC 7387, RFC 7796 et RFC 8317 décrivent le cadre puis des mécanismes VPLS et EVPN. Ces textes établissent ce qu’ils spécifient ; ils ne fournissent ni taux d’adoption, ni configuration d’un fournisseur, ni mesures de trafic, ni preuve d’un résultat opérationnel nommé.