Resumen

  • El servicio Ethernet Tree del MEF asigna a cada circuito de acceso un rol raíz u hoja. Una hoja puede comunicarse con raíces, pero no con otras hojas; el VPLS ordinario trata los circuitos como pares.
  • El ejemplo hipotético de dos equipos de borde de la RFC 7152 muestra por qué no bastaban la MAC de destino y la entrega de la trama: el equipo remoto desconocía el rol del acceso de origen.
  • El memorando de 2014 fijó requisitos —raíces múltiples, roles mixtos en un equipo y compatibilidad hacia atrás—, pero no acredita despliegue ni resultados de servicio. RFC posteriores definieron marcos y mecanismos.

Análisis

La regla pertenecía al circuito de acceso

Ethernet Tree es un servicio multipunto con raíz. Un circuito raíz puede comunicarse con raíces y hojas. Una hoja puede llegar a una raíz, pero el tráfico no debe pasar de una hoja a otra. Ethernet LAN funciona de otra manera: sus accesos pueden comunicarse entre sí.

La diferencia se vuelve operativa cuando el servicio atraviesa la red del proveedor. En el ejemplo de la RFC 7152, dos equipos de borde conectan cada uno una raíz y una hoja del cliente y se intercambian tramas mediante un pseudowire. Al recibirla, el segundo equipo sabe que la trama llegó desde el otro equipo de borde. No necesariamente sabe por qué circuito local entró en el primero ni si ese circuito era una hoja.

Conocer la MAC de destino no resuelve la duda. Esa dirección dice a dónde se dirige la trama, no qué rol tenía su circuito de entrada. Sin el rol, el equipo remoto no puede aplicar de forma fiable la restricción entre hojas a tráfico unicast conocido, unicast desconocido, broadcast y multicast. La RFC advierte expresamente que el esquema es hipotético y no representa un servicio típico.

VPLS transportaba conectividad, no esa política

El modelo VPLS existente trataba igual los circuitos de acceso y ofrecía conectividad de cualquiera a cualquiera dentro de una instancia. Eso servía para emular Ethernet LAN, pero no expresaba la relación raíz-hoja del servicio del MEF. La información que faltaba no era otra dirección de cliente: era una propiedad del acceso al servicio que debía seguir teniendo significado después de atravesar el núcleo del proveedor.

Por eso la RFC 7152 estableció requisitos en vez de presentar una solución terminada. Una alternativa debía prohibir la comunicación entre hojas, permitir varias raíces y admitir circuitos raíz y hoja en un mismo equipo de borde. También debía indicar a qué tecnología VPN de capa 2 se aplicaba y reducir el impacto en despliegues VPLS y EVPN existentes. Si solo algunos equipos admitían el nuevo comportamiento, la restricción se limitaba al ámbito compatible; el texto no prometía aislamiento de extremo a extremo a través de un tramo no compatible.

El memorando enumera entornos posibles: VPN de concentrador y sucursales, acceso mayorista, transporte móvil, distribución horaria, acceso a Internet, vídeo y administración de dispositivos. Son casos de uso en un documento de requisitos, no un censo de servicios Ethernet Tree desplegados. También distingue E-Tree del servicio multicast que entonces se discutía en el IETF: E-Tree permite patrones unicast y multicast sujetos a los roles de raíz y hoja; un servicio multicast no sustituye todos esos flujos.

La secuencia de RFC hizo explícito el contexto ausente

La RFC 7387, publicada después en 2014, propuso un modelo de arquitectura y nombró dos brechas: las VPN de capa 2 no distinguían los roles de los circuitos, y el equipo remoto no recibía una indicación de si una trama se originaba en raíz u hoja. La RFC 7796 especificó más tarde el soporte de E-Tree en VPLS mediante identificadores VLAN separados para las tramas originadas en raíces y hojas, para que el equipo pudiera filtrar en los puertos hoja. La RFC 8317 extendió el soporte a EVPN y PBB-EVPN.

Esta secuencia muestra cómo una regla del servicio se convirtió en requisito técnico y después en mecanismos de protocolo. No demuestra cuánto se adoptaron, si un proveedor concreto los configuró ni si el tráfico de un cliente quedó aislado en la práctica. La RFC 7152 es un registro informativo de requisitos, no un informe de incidente, un estudio de despliegue ni un estándar de Internet.

La lección histórica es más acotada que «la trama pierde su origen». La trama conserva direcciones y llega por un transporte. Lo que puede perderse al cruzar una frontera de capa es el conocimiento del proveedor sobre el circuito que daba a la trama su rol de reenvío. La red puede entregar los bits y aun así carecer del contexto necesario para cumplir el contrato de servicio.

Fuentes

La ficha de la RFC 7152 en el RFC Editor confirma su estado de publicación.

El registro principal es la RFC 7152, que define los requisitos y califica de hipotético su ejemplo entre dos equipos. Las RFC 7387, RFC 7796 y RFC 8317 documentan el marco y mecanismos posteriores para VPLS y EVPN. Estas fuentes prueban lo que especifican los documentos, no las tasas de adopción, las configuraciones de proveedores, las mediciones de tráfico ni un resultado operativo concreto.