Resumen

  • La IESG aprobó draft-ietf-bier-ping el 21 de septiembre de 2026. La revisión 29 está en la cola del RFC Editor; todavía no se presupone número RFC ni puerto definitivo.
  • Packet-Forward-Success es la afirmación local del BFER que contestó. No demuestra que todos los BFR-ID incluidos en una consulta múltiple hayan respondido.
  • La prueba completa necesita conservar el conjunto original, la secuencia de objetivos, cada respuesta o tiempo agotado, códigos, DDMAP, entropía y modo de retorno; la entrega de producción se mide aparte.

El verde de una salida no ilumina las demás

La arquitectura BIER representa destinatarios con posiciones de bit. Cada BFER ocupa una posición y un BitString puede señalar muchas salidas a la vez. BIER Ping usa esa gramática para consultar el plano de reenvío sin convertir al núcleo en un depósito de estado por flujo.

La aprobación es real y acotada. El registro de decisiones de la IESG da la fecha del 21 de septiembre. Datatracker muestra la revisión 29, del día 19, en proceso del RFC Editor. El texto puede cambiar y las asignaciones registrales no deben adelantarse. Tampoco hay en esas páginas evidencia de un despliegue concreto.

El borrador ofrece un código atractivo para los paneles: Packet-Forward-Success. El problema no está en el código, sino en hacerlo más grande que su sujeto. La respuesta describe la búsqueda y el tratamiento del BFER que la envía. Si la solicitud contenía cuatro BFR-ID y uno quedó en silencio, las tres respuestas positivas no constituyen la respuesta del cuarto.

La propia revisión 29 advierte que detectar un BFR-ID ausente resulta difícil cuando una solicitud incluye más de uno. Puede ser necesario volver a consultar con el BFER que no respondió como objetivo aislado. La completitud es, por tanto, una operación contable sobre un conjunto, no una propiedad mágica de la primera respuesta.

Dos BitString y una memoria obligatoria

El Original SI-BitString fija el universo que se pretendía alcanzar. El Target SI-BitString sirve para seleccionar quién debe responder en una etapa. Cuando llega una respuesta, el iniciador puede limpiar ese bit en las consultas siguientes. Sin el original inmutable y el historial de modificaciones, el último paquete ya no permite reconstruir el propósito de la prueba.

Cada bit debe terminar con respuesta identificada o vencimiento explícito. El silencio aislado abre la investigación, pero no la resuelve. Puede deberse al camino de ida, la selección, el análisis local, el punt al plano de control, un policer, la creación de la respuesta o el camino de vuelta.

También importa cómo volvió la respuesta. IP/UDP confirma un retorno por IP. El modo BIER puede comprobar un trayecto BIER en sentido inverso. Ninguno, sin telemetría adicional, acredita que una aplicación haya recibido el multicast real.

Los códigos preservan el lugar del fallo

No matching entry in the forwarding table señala que la búsqueda local no encontró la entrada esperada. Set-Identifier Mismatch descubre desacuerdo en el SI, capaz de alterar la frontera de subdominio. DDMAP Mismatch muestra que el mapa de reenvío no coincide con el esperado y hace razonables hipótesis de duplicación o bucle. Packet-Forward-Success permanece como confirmación local positiva.

Guardar solo “ok/error” borra precisamente la información que permite actuar. El registro debe unir código, BFR-ID, BitStrings de entrada y salida, interfaz, DDMAP, etiqueta y SI. Entonces se puede contrastar plano de control y plano de reenvío sin declarar que uno representa automáticamente al otro.

Un mismo BFER puede esconder varios caminos

La exploración multipath para BIER sobre MPLS exige una consulta referida a un solo BFER. La respuesta enumera por máscara los valores de entropía que seleccionan caminos aguas abajo. Una petición con varios BFER es inválida para esta operación.

Así, obtener una respuesta del destino y cubrir sus alternativas ECMP son obligaciones distintas. Para cada salida crítica se necesita una matriz de clases de entropía, ejecuciones y caminos observados. BFIR-id, BitString, BIFT-id, BSL, SI, entropía y DSCP forman además el contexto de comparabilidad. Cambiar uno puede hacer que la sonda reciba un tratamiento diferente del flujo vigilado.

RFC 10014 aporta método para OAM activo; RFC 9974 define requisitos para OAM en BIER. Son marcos para medir con rigor, no permisos para convertir una sonda en prueba de salud sostenida o resultado del cliente.

Proteger el plano de control cambia la observación

El borrador recomienda limitar la tasa de BIER Ping dirigida al plano de control y al puerto correspondiente. Es una defensa sensata. También implica que la ausencia puede ser causada por protección, no por la tabla de reenvío.

La tasa enviada, los contadores de punt y policer, los errores del parser y la carga deben acompañar al ensayo. Subir límites sin autoridad puede convertir la herramienta en vector de agotamiento; cambiar rutas sin mirar el policer puede “reparar” lo que no estaba roto.

La separación de capas de Heng Lu evita esa confusión. La aprobación es un hecho institucional; el borrador especifica símbolos; una configuración ofrece capacidad; el ensayo observa una ejecución; el tráfico real y la aplicación pertenecen a otras capas. La precisión aumenta cuando ninguna capa habla por todas.

Fuentes