Resumen

  • RFC 9784 identifica cada segmento Ethernet virtual con su propio vESI y pide vigilar cada EVC: compartir puerto físico no convierte todos los servicios en un único fallo.
  • Una avería de circuito debe limitarse al vES o instancia de servicio correspondiente; una avería real del ENNI sí puede activar una retirada agrupada de todos los vES asociados.
  • La retirada BGP no demuestra por sí sola que el detector eligió el alcance correcto, que el grupo estaba actualizado, que el forwarding convergió ni que volvió el tráfico del cliente.

Un EVC deja de pasar tráfico mientras la interfaz física sigue activa. Los demás servicios del puerto funcionan. Si la automatización conserva como verdad el modelo del puerto, puede invalidar direcciones de clientes ajenos y fabricar una caída mayor que la avería original.

RFC 9784 resuelve esa tensión mediante Virtual Ethernet Segments en EVPN y PBB-EVPN. Su lección operativa no consiste solo en añadir rutas. Distingue el alcance de la observación del alcance de la autoridad: una alarma lógica no representa al soporte físico entero por el mero hecho de vivir dentro de él.

Cuando el ENNI sí se pierde, el problema cambia. Miles de segmentos pueden necesitar conmutar a la vez y miles de mensajes individuales retrasarían el resultado. Entonces conviene comprimir el conjunto afectado. La recuperación segura depende de no confundir ambas situaciones.

Un puerto compartido contiene identidades distintas

EVPN definió originalmente el Ethernet Segment como enlaces físicos entre un sitio y varios PE. RFC 9784 permite asociar esa función a EVC, grupos de EVC, pseudowires o LSP. Así, muchos vES con clientes, VLAN, dominios de difusión y redundancias diferentes pueden agregarse sobre el mismo ENNI.

La concentración física no borra los compromisos de servicio. La propia especificación contempla miles de vES single-homed y cientos de Single-Active en una interfaz. Existe un riesgo físico común, pero cada circuito mantiene su historia operacional.

Por eso cada vES debe poseer un vESI propio. La elección del Designated Forwarder se calcula sobre (vESI, Ethernet Tag): el tag es VID en EVPN e I-SID en PBB-EVPN. La identidad establece qué grupo de PE puede reaccionar para qué servicio.

La granularidad del sensor debe sostener la de la acción

Cada EVC debería vigilarse de forma independiente. Si falla uno de los muchos EVC de un ENNI, debe ejecutarse la elección DF de su vES asociado. Para justificarla hay que conservar qué monitor observó qué objeto y cuál era entonces la relación EVC–vESI–instancia–grupo.

El bit «port up» es demasiado amplio para certificar el EVC. La alarma «EVC down» es demasiado estrecha para declarar muerto el puerto. El inventario temporal une ambos niveles y limita lo que puede decidirse.

El RFC impone además que el fallo o recuperación de un EVC single-homed o All-Active no afecte a otros EVC. En Single-Active, el impacto se mantiene en su instancia; la limpieza de C-MAC se restringe al I-SID y al cliente o red multihomed correspondiente.

Una buena validación cuenta también los objetos sanos que no cambiaron. Esa evidencia negativa evita que la recuperación se convierta en causa de interrupción.

La limpieza física puede ser excesiva

PBB-EVPN hace visible el peligro. Muchos servicios de un puerto pueden compartir B-MAC. Reutilizar para un solo EVC el procedimiento MAC Mobility del segmento físico puede ordenar a los PE remotos que limpien C-MAC de todos los EVC del puerto. Los servicios intactos pierden estado y deben reaprenderlo.

RFC 9784 aprovecha la ruta B-MAC/I-SID de RFC 9541 para reducir la instrucción. El receptor limpia los C-MAC del B-MAC anunciado únicamente dentro del I-SID anunciado. Si un EVC lleva varios VLAN/I-SID, puede requerir varias rutas; si el conjunto es grande, puede resultar mejor un B-MAC por vES y retirar ese B-MAC.

No existe un tamaño correcto por vocabulario. Un EVC puede incluir varios dominios y un puerto innumerables circuitos. La topología y su versión temporal son parte de la prueba.

El fallo de ENNI sí permite hablar por el conjunto

Cuando cae el puerto, todos sus EVC pierden el camino físico. El route coloring registra qué rutas de vES pertenecen a ese contenedor. Normalmente se usa la MAC del puerto como color, transmitida mediante la EVPN Router’s MAC Extended Community de RFC 9135. Los receptores crean una lista de vES por color.

El PE puede anunciar además una Grouping Ethernet A-D per ES route, o una Grouping B-MAC route en PBB-EVPN, para representar ese conjunto. Al retirar la ruta agrupadora tras el fallo de ENNI, los demás PE pueden iniciar elección DF y failover para todos los miembros conocidos. Después llegan las retiradas individuales para limpiar las tablas BGP.

La compresión no crea conocimiento. El color prueba una asociación anunciada, no observa el puerto. La ruta agrupadora prueba que se describió un conjunto, no que todos los receptores tengan la misma versión. Su retirada prueba una declaración del emisor, no la causa ni la recuperación.

Este diseño mantiene local la decisión futura. La señal compartida transporta solo la asociación necesaria; cada PE conserva la responsabilidad de interpretar su estado, elegir, actualizar MAC y cambiar forwarding. El identificador común no recibe autoridad sobre los resultados posteriores.

Las retiradas no son intercambiables

La retirada agrupada busca velocidad usando membresía preparada. Las retiradas por vES eliminan rutas concretas. Si la primera ya inició la elección, las segundas no deben volver a dispararla. Una captura que muestre únicamente la tabla final no permite saber si hubo acción rápida, doble ejecución o inclusión de un miembro obsoleto.

La restitución también se divide. Una ruta anunciada hace elegible un camino. Una elección DF atribuye una función. Una actualización MAC cambia alcance local. Solo una observación de datos muestra que las tramas cruzaron el camino y que los servicios vecinos permanecieron sanos.

Por ello, el expediente debería retener detector, objeto, tiempo, mapa EVC–vESI–servicio–color, membresía observada por cada receptor, motivo de elegir recuperación individual o agrupada, orden de mensajes, resultado DF, operación MAC, forwarding y pruebas de tráfico. «EVPN convergió» es una conclusión; no es el conjunto de recibos.

La infraestructura compartida necesita autoridad acotada

La virtualización multiplica las promesas independientes dentro de un solo activo físico. Cuantos más servicios agrega un puerto, más cara es una inferencia física falsa y más necesaria la identidad lógica.

La primacía del código en ejecución separa las capas. El RFC prueba que el mecanismo fue publicado. La configuración, que alguien decidió activarlo. La traza BGP, que hubo mensajes. El estado del equipo, que aplicó una elección o limpieza. El tráfico, que el servicio obtuvo un resultado. Ninguna capa habla con la autoridad de la siguiente.

RFC 9784 no solo acelera convergencia. Hace que la velocidad rinda cuentas al alcance. Si falló un circuito, el puerto no debe caer por asociación retórica. Si falló el puerto, una señal agrupada puede coordinar sus circuitos, pero no declarar por sí misma que el servicio volvió.

Fuentes

  1. RFC 9784 — Segmentos Ethernet virtuales para EVPN y PBB-EVPN
  2. RFC 7432 — Ethernet VPN sobre BGP MPLS
  3. RFC 7623 — Provider Backbone Bridging combinado con EVPN
  4. RFC 8214 — Soporte de VPWS en EVPN
  5. RFC 8584 — Extensibilidad de elección DF en EVPN
  6. RFC 7023 — Gestión de fallos de conectividad Ethernet
  7. RFC 9135 — Routing y bridging integrados en EVPN
  8. RFC 9541 — Rutas B-MAC y B-MAC/I-SID para PBB-EVPN
  9. Lu Heng — Primacía del código en ejecución
  10. Lu Heng — Especificación inicial mínima y decisión futura localizada
  11. Lu Heng — Capas de realidad, poder simbólico y claridad