Resumen

  • La revisión 12 de draft-ietf-bier-bfd, todavía Internet-Draft del grupo BIER en última llamada interna, precisa que la notificación espontánea de la cola se basa en el mecanismo de RFC 9780 para este uso de BIER y no en el procedimiento solicitado de RFC 8563. La versión 11 ya hablaba de notificaciones no solicitadas; no se trata de una función nacida ahora.
  • Tras detectar la pérdida de continuidad, el BFER envía el aviso por una ruta unicast separada del árbol multicast, identifica la sesión P2MP BFD afectada y espera una respuesta Final válida o la desaparición del defecto. La confirmación del aviso no equivale a comprobar que el árbol volvió a funcionar.

El lugar donde se detecta un fallo no siempre es el lugar donde se toman las decisiones. En BIER, el router de entrada, BFIR, transmite paquetes de control BFD a varios routers de salida, BFER. Cada salida observa si siguen llegando. Si una deja de recibirlos, conoce el problema en su extremo; el BFIR todavía puede carecer de una noticia utilizable. La revisión reciente no se limita a repetir que BFD comprueba conectividad: examina la entrega de esa noticia.

El Datatracker fecha el texto el 29 de septiembre y lo muestra como borrador activo del grupo de trabajo BIER, en WG Last Call, con estado IESG I-D Exists. Eso no es una RFC ni certifica que haya equipos desplegados siguiendo la revisión. Tampoco permite hablar de una interrupción medida. La importancia editorial está en las obligaciones que el texto propone para que una observación local llegue a la cabecera y se asocie a la sesión correcta.

RFC 8562 describe la vigilancia punto a multipunto desde la cabecera hacia las colas, pero no proporciona por sí sola un inventario de las colas que han visto una pérdida. La sección 6 de la revisión 12 remite expresamente a la notificación no solicitada de RFC 9780 para BIER, diferenciándola del método solicitado de RFC 8563. Hay que evitar una lectura exagerada del cambio: la revisión anterior contenía una sección de avisos espontáneos y la propia RFC 8563 también los menciona. Lo que se consolida aquí es la referencia operativa, junto con campos y tiempos redactados como requisitos más claros.

Un BFER que detecta el fallo debe marcar Poll, poner el estado en Down y usar el diagnóstico Control Detection Time Expired. En Your Discriminator coloca el My Discriminator de la sesión P2MP averiada. El aviso se encapsula en IP/UDP hacia la dirección del BFIR y el puerto de destino 4784. El camino de regreso por unicast debe ser distinto del árbol de distribución multicast. Esa separación evita depender, para avisar, de la misma rama cuya continuidad está en duda.

El borrador exige enviar un paquete por segundo hasta obtener un paquete Final válido para la sesión o hasta que desaparezca el defecto; también recomienda tres envíos con intervalos seudoaleatorios dentro de un segundo. En la cabecera, el BFIR usa Your Discriminator para desmultiplexar el aviso y, tras encontrar la sesión, devuelve un paquete BFD unicast con Final. Para los paquetes en sentido de distribución, la cola identifica su sesión con BFIR-id y el My Discriminator asignado por la cabecera. Son dos planos de asociación distintos: omitir el identificador en los registros haría más difícil demostrar a qué trayectoria corresponde el aviso.

Una respuesta Final indica que hubo intercambio de notificación con una sesión reconocida. No indica que el tráfico multicast haya vuelto a llegar a la cola. El proyecto advierte además que fallos correlacionados pueden provocar una ráfaga de avisos hacia el plano de control y trata la limitación de tasa. Por ello, que la cabecera no muestre alarmas no prueba que todas las salidas estén sanas: la ruta de retorno o la capacidad de recepción también podrían ser el cuello de botella. Es una inferencia para la operación, no un dato de incidencia real.

El artículo anterior sobre BIER Ping analizaba la fidelidad de las pruebas diagnósticas y su aprobación; este examina el flujo continuo de evidencia de fallo.

Fuentes