Resumen

  • draft-ietf-bier-bfd-12 lleva BFD punto a multipunto sobre BIER. Si un BFER deja de oír al BFIR, envía una notificación espontánea por IP/UDP unicast sobre una ruta que debe ser disjunta del árbol multicast.
  • El paquete Final confirma que la cabecera recibió y asoció el aviso. No ubica la avería, no representa a todas las colas y no acredita recuperación del árbol ni recepción de la aplicación.

El último control BFD llegó hace demasiado tiempo. La cola marca Down y no aguarda a que la raíz pregunte. Envía el aviso por UDP 4784, fuera del árbol que está midiendo. La raíz responde Final. Esa respuesta cierra una conversación, no el fallo.

La revisión 12 de BIER BFD, publicada el 29 de septiembre de 2026, formaliza esta separación. Es un Internet-Draft activo del grupo BIER, con intención de Standards Track y vencimiento el 2 de abril de 2027. No es un RFC, una decisión final del IETF, una asignación ni evidencia de despliegue. Sus tipos propuestos siguen como TBD1, TBD2 y TBD3.

La cola observa una sola dirección

El BFIR funciona como MultipointHead y envía controles BFD encapsulados en BIER a un conjunto de BFER. Cada cola mide la continuidad que llega desde la cabecera. Cuando vence el tiempo de detección, puede declarar pérdida.

El dato exacto es «esta cola dejó de recibir lo esperado de esta cabecera en esta sesión». No señala un enlace físico, un nodo intermedio ni una entrada de reenvío. Tampoco describe el estado de las demás colas. Algunas pueden seguir recibiendo el flujo completo.

El arranque de la sesión puede utilizar BIER Ping, un atributo BGP o configuración estática. BIER Ping transporta el conjunto objetivo en Target SI-BitString y el discriminador en un TLV propuesto. Si cambia My Discriminator, debe repetirse el arranque. Esa configuración no demuestra que todas las colas instalaron bien la sesión ni que los controles posteriores siguieron el camino deseado.

La identidad es una pareja, no un número

En BFD convencional, Your Discriminator permite escoger la sesión local. En P2MP, la cola recibe el My Discriminator elegido por la cabecera y necesita contexto adicional. Ese valor puede repetirse bajo otra raíz.

BIER aporta el BFIR-id. Por eso el borrador exige que la cola use (BFIR-id, My Discriminator) como clave. Guardar solo los cuatro octetos del discriminador elimina el alcance y puede atribuir un aviso a la sesión equivocada.

Un registro útil conserva además subdominio, conjunto objetivo, BFER local, origen del arranque y cambios. Al modificar el discriminador, las observaciones anteriores no deben mezclarse silenciosamente con la nueva identidad.

El retorno no comparte el destino del árbol

Al detectar el defecto, el BFER construye un control con Poll activo, estado Down y diagnóstico Control Detection Time Expired. Coloca en Your Discriminator el My Discriminator de la sesión fallida y lo envía a la dirección del BFIR por IP/UDP unicast, puerto 4784.

La ruta de regreso debe ser disjunta del árbol multicast. Si el aviso dependiera del mismo componente que acaba de fallar, su ausencia no informaría a la cabecera. La diversidad ofrece una observación externa.

Pero la recepción del aviso solo prueba ese retorno unicast para ese paquete. No convierte la ruta inversa sana en una localización de la rotura directa. Hay que retener por separado la procedencia del flujo BIER que expiró y la del aviso unicast que llegó.

Además, disjunción lógica no garantiza diversidad física. Dos caminos pueden compartir energía, conducto, tarjeta o cuello de botella del plano de control. El protocolo formula la condición; la topología real y sus dominios de fallo siguen siendo decisión y prueba del operador.

Final es un acuse, no una recuperación

El BFER transmite una notificación por segundo hasta que recibe un Final válido o desaparece el defecto. También debería enviar tres paquetes en intervalos pseudoaleatorios dentro de un segundo para aumentar la probabilidad de aviso.

El BFIR asocia el paquete mediante Your Discriminator y contesta por unicast con Final. La cola ya sabe que la cabecera recibió su declaración. No sabe que el árbol fue reparado, que una ruta cambió o que los datos multicast volvieron a una aplicación.

La repetición también puede terminar porque el defecto desapareció antes de Final. Por eso el historial debe registrar la causa concreta. Una automatización prudente separa el permiso para reconocer un aviso de la autoridad para modificar la red o declarar cierre.

La ausencia de alarma no equivale a salud

Una avería común puede afectar a muchos BFER a la vez y producir una ráfaga de avisos hacia un solo BFIR. El borrador obliga a controlar cuántos paquetes llegan al plano de control para procesamiento.

Esa protección es necesaria y, a la vez, puede ocultar observaciones. Una cola silenciosa quizá esté sana; quizá perdió la dirección descendente y también el retorno; quizá no instaló la sesión; quizá su paquete fue limitado antes de asociarse. La primera alarma no clasifica a toda la población.

La explotación necesita cuadrar colas activas previstas, parejas instaladas, declaraciones Down, descartes de entrada, paquetes admitidos, asociaciones, Final y continuidad posterior. Los contadores de protección explican qué evidencia negativa podía llegar al sistema.

La cadena queda así: revisión exacta; autoridad de arranque; pareja de identidad; último control válido; vencimiento; aviso construido; custodia de la ruta inversa; asociación en la cabecera; Final o limpieza local; conciliación de colas; diagnóstico; reparación; BFD renovado; resultado de aplicación. Ninguna fila demuestra la siguiente.

La especificación inicial mínima de Heng Lu encaja con esa disciplina. La capa común define identidad, señal, repetición y acuse. La selección de colas, la diversidad física, la protección, el diagnóstico y la acción pertenecen a quienes operan el riesgo. La adopción se prueba con código en marcha y resultados, no con la publicación del borrador.

Fuentes