Resumen

  • RFC 9624 combina rutas EVPN y réplica BIER para que el PE de entrada calcule los BFER que deberían recibir una trama BUM sin mantener estado multicast por flujo en cada router intermedio.
  • IMET, SMET, S-PMSI, Leaf A-D y el PTA fijan un conjunto y un contexto previstos; no prueban que la membresía estuviera vigente o que las copias llegaran a esas salidas.
  • La evidencia completa separa época de rutas, clasificación, hojas elegidas, BitString impuesto, réplica del núcleo, relevo de segmentación, disposición, split horizon, transmisión local y recepción del cliente.

Una lista completa puede terminar en una entrega incompleta

El PE de entrada ve todas las rutas IMET del dominio. Las rutas selectivas correspondientes están presentes y el PMSI Tunnel Attribute anuncia BIER. El cálculo activa una posición para cada BFER esperado. La pantalla de control no muestra ninguna ausencia.

Sin embargo, un sitio no recibe la trama. Ese cálculo no aclara si la ruta de interés estaba atrasada, si la trama coincidió con la regla prevista, si se perdió una rama, si un punto de segmentación reconstruyó el contexto correcto, si el PE de salida recuperó el dominio adecuado o si split horizon eliminó una copia legítima.

La aportación de RFC 9624 es expresar el plan de manera interoperable. Convertirlo en resultado dañaría esa precisión. El BitString debe conservarse como lo que es: solicitud de réplica en un instante y ámbito concretos.

Menos estado en el núcleo no significa más certeza

BIER evita que los routers intermedios mantengan estado multicast por flujo o ejecuten un protocolo explícito de construcción de árboles. El BFIR codifica los egresos y los BFR replican conforme al header y a la tabla de reenvío por índices.

La simplificación reduce carga y acoplamiento. No elimina pérdida, congestión, tablas incoherentes, fallos de enlace o errores de próxima salida. Un equipo sin estado de flujo puede interpretar bien una posición y fallar al emitir la copia. La propiedad de arquitectura no es una observación de ejecución.

Las pruebas necesitan una época de forwarding y una correlación de paquete o muestra. Los contadores deben mostrar qué ramas nacieron y qué BFER las vio. La ausencia de un árbol explícito no responde por sí sola a ninguna de esas preguntas.

El PTA delimita el contexto, no lo ejecuta

El PTA emplea el tipo 0x0B y porta sub-domain ID, BFR-id y BFR-Prefix. Su label es un MPLS asignado aguas arriba o un VNI/VSID global para encapsulados IP. Las banderas LIR y LIR-pF intervienen en el seguimiento de hojas.

Esos campos permiten asociar anuncio y P-tunnel. Aun así, el BFR-Prefix puede diferir de otras direcciones de la ruta, los Route Targets deciden distribución y el PTA BIER debe quedar dentro del dominio donde identifica de forma única al originador. Que todos los octetos sean válidos no prueba que el anuncio haya conservado la frontera correcta.

Por eso conviene guardar anuncio, vecino, origen, Route Targets, PTA exacto, dominio y hora efectiva. Una interfaz que resume «BIER activo» borra precisamente la evidencia necesaria para investigar un cruce de dominio o de época.

Las hojas describen interés, no presencia final

En un PMSI inclusivo, los originadores de las otras rutas IMET del dominio forman el conjunto BFER. En selección, las rutas SMET coincidentes o S-PMSI y Leaf A-D aportan las hojas. La decisión cambia con fuente, grupo, LIR, LIR-pF y la posibilidad de usar SMET en lugar de Leaf A-D.

Una baja puede tardar en converger y mantener un receptor antiguo. Una alta tardía puede faltar. La ruta indica interés anunciado conforme al protocolo, pero no prueba que el puerto de cliente conserve un receptor. Tampoco una vista actual reconstruye con autoridad la selección aplicada minutos antes.

El recibo debe congelar la clave del paquete, la ruta de transmisión realmente elegida y el conjunto exacto de hojas. Solo entonces puede compararse el BFER previsto con el observado.

Cero hojas puede significar cero transmisión correcta

Si no hay ruta que coincida para transmitir, RFC 9624 ordena no enviar la trama a un P-tunnel. Si el túnel requiere seguimiento de hojas y el conjunto está vacío, tampoco se envía.

Por eso un contador BIER en cero no demuestra ausencia de tráfico. Puede esconder un fallo de clasificación, una ruta inexistente, un conjunto de hojas vacío o un descarte previo. Del lado contrario, una ruta presente no acredita que esta trama la haya seleccionado.

La entrada debe registrar identidad de trama, dominio, clase BUM, fuente y grupo si corresponden, match de ruta, hojas, elección de interworking, labels o VNI, header BIER y resultado de transmisión.

El bit acredita inclusión en la orden

Una vez derivadas las hojas, el BFIR construye el header. Los valores de protocolo distinguen MPLS, VXLAN, NVGRE y GENEVE. Una posición activa significa que el BFER fue solicitado en ese subdominio, set identifier y longitud.

No significa que el mapping posición-destino fuera coherente en todo el dominio, que la lista reflejara la membresía más reciente o que la rama terminara. Una representación impecable también puede transportar una decisión obsoleta.

La evidencia debe mantener dos hechos: el BFIR incluyó el bit y el BFER acusó llegada. Su correlación es valiosa; su fusión en una sola marca de “entregado” es falsa.

Segmentar es volver a decidir

El punto de segmentación recibe un contexto aguas arriba y había reanunciado la ruta a regiones posteriores. Para una región BIER elimina la encapsulación anterior, cambia el label al asignado en el PTA posterior, calcula sus hojas e impone otro header.

El paquete puede llegar correctamente y perder significado en esa transición. Un label equivocado puede elegir otro dominio; hojas atrasadas pueden omitir una salida; un nuevo BitString puede ser válido localmente y divergente del servicio original.

Trátese como relevo de custodia: paquete y contexto recibidos, ruta asociada, campos retirados, región y época nuevas, label reemplazado, hojas, header nuevo y emisiones. Observar un solo lado no prueba el relevo.

La disposición separa BFER y cliente

El PE de salida usa el label aguas arriba o VNI/VSID para recuperar el dominio EVPN. A continuación, las reglas ordinarias deciden la réplica local. El paquete puede haber llegado al BFER y no haber salido por un circuito de acceso.

Puede faltar el mapping, fallar la forma de payload, no existir un puerto elegible o perderse la cola. El recibo local incluye decapsulación, protocolo, lookup, dominio, lista de puertos y resultado por cola. Así se entiende por qué un contador BIER correcto no invalida la queja del cliente.

Split horizon necesita explicar cada ausencia

En EVPN-MPLS, el label ESI aguas arriba marca el segmento de origen para impedir el retorno. En VXLAN, NVGRE y GENEVE, local bias usa el BFIR-id para no duplicar sobre segmentos multihomed que la entrada ya atendió.

Una supresión puede ser la acción correcta. Pero una identidad, label o estado multihoming incorrecto puede suprimir servicio real. Y acertar con un segmento no prueba que los demás recibieran su copia.

Registre segmento, identidad de entrada, ESI o dato de local bias, motivo, puertos suprimidos y puertos enviados. Un total no separa prevención de bucle y pérdida accidental.

La escalera termina fuera del P-tunnel

Primero se preservan rutas, PTA, Route Targets y época BIER. Después se une la trama a su regla, hojas, subdominio, BFIR-id, BitString, protocolo y contexto EVPN. El núcleo aporta observaciones de rama y cada segmentación renueva la cadena.

El BFER prueba llegada y decapsulación. La disposición prueba dominio, réplica local y split horizon. El circuito de acceso y el equipo cliente prueban la entrega de red. El uso de la aplicación y el resultado del servicio todavía son hechos posteriores.

Esta separación conserva la sencillez de BIER: no reintroduce estado por flujo en el núcleo. Solo evita que un plan compacto se presente como una experiencia que nunca observó.

Fuentes