Resumen
- En
draft-ietf-bier-source-protection-11, el BFIR de respaldo puede perder su camino hacia el BFIR seleccionado sin que se rompan los caminos que llevan el multicast desde el seleccionado hasta los BFER. Tomar el control en ese caso es innecesario y puede duplicar paquetes. - Un Ping de regreso tampoco representa automáticamente el trayecto de ida. Sin coencaminamiento, puede fallar con el flujo sano o responder mientras el flujo está cortado.
- Identidad de la observación, estado del detector, modo de reserva, autorización para cambiar, efecto de duplicado o pérdida, recepción y continuidad de la aplicación son comprobantes diferentes. La revisión 11 sigue siendo un Internet-Draft informativo.
El sistema de respaldo tenía un hecho verdadero: ya no recibía las señales esperadas del primario. Lo convirtió en otro hecho que no había medido: el primario ya no entregaba tráfico. Después ejecutó una tercera afirmación: “me corresponde sustituirlo”.
Solo la primera estaba demostrada.
El primario continuaba enviando el flujo hacia los receptores. Había fallado el camino lateral entre los dos routers de ingreso. Al activarse el respaldo, ambos comenzaron a alimentar la misma distribución. La automatización respondió correctamente a su propio sensor y equivocadamente a la red.
La revisión 11 de BIER Redundant Ingress Router Failover hace visible esa separación. Su valor para una dirección técnica no consiste en prometer alta disponibilidad. Consiste en mostrar dónde una señal de vida obtiene más autoridad de la que merece.
El servicio no vive en el mismo camino que el observador
En RFC 8279, un BFIR introduce el paquete en el dominio BIER y varios BFER lo reciben. Los routers intermedios usan el BitString del paquete, sin conservar estado multicast por flujo. Aun así, cada BFER elige un upstream multicast hop para un flujo. Protocolos de overlay intercambian esa información; el transporte BIER mueve los paquetes.
El borrador llama S-BFIR al ingreso seleccionado y B-BFIR al respaldo. El rol puede variar entre flujos e incluso entre subconjuntos de receptores. Dos BFER pueden tomar decisiones distintas sin que ninguno esté necesariamente mal.
Para razonar sobre una avería hay que nombrar, por lo menos, tres caminos dirigidos:
- B-BFIR hacia S-BFIR, usado por el respaldo para observar al seleccionado;
- S-BFIR hacia cada BFER, usado por el flujo protegido;
- BFER hacia S-BFIR, usado por una solicitud Ping de regreso.
La topología puede hacerlos coincidir, pero el control no puede presuponerlo. Cuando se rompe el primero, el respaldo sabe que ha perdido esa observación. No sabe todavía si murió el nodo ni si se rompió el segundo camino.
El ejemplo del borrador es explícito. En reserva templada, BFIR2 pierde el trayecto hacia BFIR1. Lo interpreta como caída de BFIR1 y adopta el rol seleccionado. Los caminos de BFIR1 hacia todos o algunos BFER siguen funcionando. El cambio fue innecesario y genera duplicados en la red y en los BFER.
También existe el error inverso: el enlace entre ingresos puede estar sano mientras un receptor pierde su camino desde el primario. Un indicador de salud puede ocultar una interrupción real.
“Down” no es una frase completa
RFC 5880 define BFD para detectar fallos en un camino concreto. RFC 8562 lo lleva a entornos multipunto. El borrador BIER BFD añade la iniciación de sesiones y la notificación desde colas activas. Ninguno transforma una sesión en un oráculo sobre todos los caminos relacionados.
| Dato disponible | Lectura precisa | Salto no justificado |
|---|---|---|
| BFD Down entre respaldo y seleccionado | Esa sesión superó su umbral de fallo | El seleccionado dejó de servir a todos los BFER |
| Ping de regreso sin respuesta | Esa sonda no completó el viaje | El flujo de ida se detuvo |
| Cola multipunto agotó Detection Time | Ese receptor no vio el control esperado | Ningún receptor conserva el flujo |
| BFER eligió otro UMH | Cambió su selección para ese flujo | La aplicación quedó restaurada |
| Respaldo empezó a enviar | Entró una segunda fuente | Todos los duplicados fueron descartados |
El evento debe conservar extremos, dirección, subdominio, tratamiento de tráfico, entropía, discriminador, intervalo y clase del flujo. Si se registra solo Down, el sistema pierde el sujeto de la oración y el operador posterior pierde la causa.
El Ping puede equivocarse al fallar y al responder
El BFER puede enviar un Ping hacia BFIR1 y, tras varias respuestas ausentes, considerarlo un UMH fallido. Pero el paquete multicast que interesa viaja de BFIR1 al BFER. La solicitud viaja al revés.
Con rutas asimétricas, el borrador reconoce dos resultados falsos. La sonda puede fallar mientras la distribución funciona. O puede responder mientras el camino de ida tiene una avería. Por eso exige coencaminar la solicitud con el camino del flujo monitorizado para mejorar la correspondencia.
Coencaminar no equivale a demostrar entrega. Solo alinea mejor la observación de red con el objeto que pretende describir. La continuidad, el orden y la ausencia de duplicados siguen necesitando medidas en el BFER y en la aplicación.
Frío, templado y caliente no son solo velocidades
El borrador general sobre respaldo de ingreso multicast distribuye el riesgo en tres modelos.
En reserva fría, el receptor pide el flujo al alternativo cuando decide que el seleccionado falló. Consume menos ancho de banda, pero la señalización y la convergencia pueden perder paquetes.
En reserva templada, seleccionado y respaldo ya conocen la demanda, aunque solo el primero envía. El arranque del segundo puede ser rápido. También puede ser injustificado si su monitor no representa el camino a los receptores.
En reserva caliente, ambos envían y el BFER descarta una copia. La transición puede ser corta, pero el dominio carga tráfico duplicado de forma deliberada y cada receptor asume la selección correcta.
Por tanto, pedir “el failover más rápido” no es una especificación suficiente. Hay que decidir quién paga el ancho de banda, quién guarda el estado, quién tolera la pérdida y quién posee la autoridad de declarar una caída.
No existe una única verdad global del primario
Los BFER pueden elegir primarios distintos y usar temporizadores diferentes. Uno puede cambiar a BFIR2 mientras otro conserva BFIR1. Un tercero puede estar en Detection Time. El identificador correcto de decisión incluye flujo, BFER o conjunto, S-BFIR, camino observado, mecanismo, umbral y estado anterior.
Después del cambio hacen falta dos series de pruebas. La primera describe control: quién cambió el UMH, cuándo y bajo qué regla. La segunda describe efecto: cuándo empezó BFIR2, cuándo dejó BFIR1, cuántos paquetes se perdieron o duplicaron, qué BFER aceptó cada fuente y qué vio la aplicación.
Si el sistema guarda solo failover_success, ya no puede distinguir recuperación de coexistencia accidental.
Una norma de trabajo no es un parte de operación
La revisión 11 es un documento del grupo BIER, con fecha 1 de octubre de 2026 e intención Informativa. No es un RFC. No solicita valores IANA. Su sección de seguridad remite a la arquitectura BIER, BFD multipunto, el failover MVPN y los borradores Ping/BFD.
El texto prueba que el diseño reconoce la discrepancia entre camino observado y camino protegido. No prueba que un fabricante la haya resuelto, que un operador la haya desplegado ni que una sesión real terminara sin pérdida.
Las capas de realidad de Lu Heng dan una regla útil: el estado simbólico del detector no debe apropiarse del estado físico de un camino que no observó. El espejo de políticas añade actor, regla, alcance y consecuencia cada vez que esa señal puede reconfigurar la red.
El recibo mínimo de cambio
Conserve identidad del flujo; S-BFIR y B-BFIR; BFER afectados; modo de reserva; overlay y estado de selección; detector y sesión; camino dirigido observado; equivalencia de tratamiento con el flujo; umbral, intervalos y paquetes ausentes; autoridad que ordenó el cambio; UMH anterior y nuevo; inicio y parada efectivos de ambas fuentes; contadores de pérdida, duplicado y reordenamiento; aceptación por receptor; y resultado de la aplicación.
Cuando no haya prueba de coencaminamiento, registre equivalencia_de_camino_no_verificada. Cuando el respaldo desconozca el camino del receptor, conserve ese desconocimiento. La evidencia incompleta debe limitar la acción, no ser rellenada por el nombre “protección”.
Fuentes
- Datatracker del borrador principal
- Historial del documento
- Revisión 11 en texto
- Revisión 11 en HTML
- Revisión 11 en XML
- Failover de ingreso multicast, revisión 10
- BIER BFD, revisión 12
- BIER Ping y Trace, revisión 29
- RFC 8279: arquitectura BIER
- RFC 8562: BFD multipunto
- RFC 5880: BFD
- RFC 9026: failover rápido MVPN
- RFC 8556: MVPN sobre BIER
- RFC 8029: MPLS LSP Ping
- Lu Heng: especificación inicial mínima
- Lu Heng: primacía del código en ejecución
- Lu Heng: el espejo de políticas
- Lu Heng: capas de realidad
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
