Summary

  • El 21 de septiembre la IESG aprobó draft-ietf-bier-ping-29 como Proposed Standard. La aprobación no equivale a la publicación de un RFC.
  • Para vigilar un flujo, la solicitud Echo debe reproducir BIFT-id, BSL, Entropy y DSCP. El traceroute descrito está acotado a BIER sobre MPLS; el ping no comparte esa restricción.
  • Al cierre de esta revisión, IANA sigue en curso y RFC Editor espera información de los autores. La evidencia pública de implementación habla únicamente de «una parte» del mecanismo.

BIER distribuye un paquete a los routers de salida indicados en una cadena de bits. Esa economía de estado en los routers intermedios complica la lectura de una avería: una entrada y varias ramas no producen una sola respuesta sobre el servicio. El nuevo borrador establece mensajes OAM propios de BIER para detectar y aislar fallos sin depender de una prueba situada en otra capa.

La IESG aprobó la versión -29 el 21 de septiembre. Eso fija una decisión sobre la especificación; no verifica todos los productos que la anuncien. Para un operador, el punto decisivo está en la relación entre el paquete de diagnóstico y el flujo observado. El borrador exige repetir el identificador de tabla BIFT-id, la longitud BSL, la entropía usada en la elección de camino y el DSCP. Si alguno cambia, puede cambiar la ruta o el trato recibido. Guardar solo «éxito» o «fallo» destruye el contexto necesario para interpretar la medición.

Un mismo nombre no garantiza las mismas funciones

Hay una asimetría fácil de perder en la compra de equipos. El traceroute que especifica este texto se limita a BIER sobre MPLS; el ping no. Una ficha que promete «BIER Ping and Trace» sin decir encapsulación, modos de respuesta, BFER de destino y versión de software ofrece menos información de la que parece.

También importa lo que una respuesta no prueba. Puede acreditar que un paquete OAM recorrió determinadas condiciones de reenvío y obtuvo contestación. No mide por sí sola la entrega a cada receptor ni las pérdidas o la latencia de una aplicación. Y la falta de respuesta tampoco diagnostica automáticamente una rotura del plano de datos: la ruta de vuelta, los límites de tasa o una función ausente pueden producir el mismo síntoma.

El protocolo todavía debe cruzar una frontera institucional concreta. El borrador solicita un puerto UDP para Echo Reply encapsulado en IP/UDP y varios registros e identificadores BIER OAM. Los comentarios de los expertos de IANA aclaran que el puerto se destina a respuestas unicast en un entorno controlado, no a transportar tráfico multicast de uso general. Esa precisión afecta reglas de cortafuegos y expectativas de exposición; no autoriza a inventar un número final antes de la asignación.

El Datatracker sitúa el texto en la cola de RFC Editor, con la acción de IANA en curso y el estado editorial bloqueado a la espera de los autores. El anuncio de la IESG también señala preguntas de IANA pendientes. No es una desaprobación tardía: son tareas distintas que sobreviven a la decisión de la IESG. Tampoco hay una demostración pública de interoperabilidad completa. La propia nota oficial solo afirma que proveedores con algún soporte BIER han implementado parte del mecanismo.

La idea de Lu Heng de subordinar la autoridad procedimental a las redes que funcionan ayuda a formular la prueba, pero no aporta datos sobre despliegues BIER. Esta pieza se refiere al nuevo acto protocolario y a su tránsito hacia una herramienta verificable. La cobertura anterior sobre una sonda de CoS alta analizaba otra inferencia, no este trámite.

Sources