Resumen

  • RFC 9856 define supresión aguas arriba mediante Warm Standby y supresión en cada PE receptor mediante Hot Standby.
  • Un Single Flow Group expresa qué fuentes deben tratarse como redundantes, pero no verifica carga útil, secuencias, sincronización, frescura ni estado de la aplicación.
  • Un recibo de redundancia debe unir siete pruebas distintas: equivalencia, autoridad de supresión, fuente aceptada, señalización BGP, observación del receptor, tiempo de conmutación y reversión.

El contador de duplicados de un receptor puede permanecer en cero y, aun así, dejar sin respuesta la pregunta principal: ¿funcionó la redundancia o solamente funcionó el filtro? RFC 9856, estándar del IETF publicado en septiembre de 2025, extiende los procedimientos multicast de RFC 9251 y RFC 9625 para varias fuentes que envían un flujo IP multicast supuestamente idéntico dentro de un dominio EVPN.

Su objetivo es concreto. El protocolo debe evitar que las copias redundantes lleguen duplicadas a los receptores. No intenta certificar toda la cadena del servicio. Por eso conviene leer cada señal de control por lo que realmente afirma, sin convertirla en una garantía de aplicación.

La equivalencia se configura antes de observarse

RFC 9856 agrupa las fuentes mediante un Single Flow Group, SFG. Puede definirse como (*,G), que incluye cualquier origen hacia el grupo G, o como (S,G), con S expresado incluso como prefijo. El indicador SFG en la comunidad extendida Multicast Flags señala esa condición en una ruta S-PMSI A-D.

La clasificación permite que equipos distintos compartan una intención. No compara el contenido. El RFC supone que las fuentes envían el mismo flujo y que no son ráfagas intermitentes, pero no especifica una prueba de números de secuencia, marcas de tiempo, estado del códec, generación de la aplicación o identidad editorial. Una señal atrasada puede estar correctamente clasificada y ganar correctamente una elección.

La operación debe registrar primero la base de equivalencia: inventario de fuentes, muestra examinada, tolerancias de secuencia y tiempo, control de frescura y responsable que acepta el resultado. El SFG es la representación interoperable de esa decisión, no su sustituto.

Warm Standby decide antes de cruzar la red

En Warm Standby, los PE conectados a las fuentes eligen un Single Forwarder. Los demás descartan localmente los paquetes del SFG. El SF acepta un único circuito de conexión; si recibe el grupo por varios circuitos, el criterio concreto es propio de la implementación.

La elección reutiliza el marco DF de RFC 8584. Una preferencia puede favorecer un PE y el RFC establece como desempate la dirección IP de PE más baja cuando hay incompatibilidad de algoritmo o capacidad. La decisión es reproducible, pero no mide calidad, actualidad ni preparación de la fuente.

La ruta S-PMSI A-D se anuncia al llegar el primer paquete del SFG configurado. Cuando cesa el tráfico, se retira; se recomienda un temporizador de inactividad sin imponer un valor universal. Si falla el SF, el retiro permite elegir otro. Al suprimir copias cerca del origen, Warm Standby ahorra ancho de banda, aunque el propio RFC señala un tiempo de conmutación mayor que Hot Standby.

No existe en el texto una promesa universal de cero pérdida ni un máximo de conmutación. Para demostrar continuidad hay que conservar el circuito elegido, el temporizador efectivo, el instante de detección, la propagación del retiro, la nueva elección y la experiencia de los receptores.

Hot Standby reparte la autoridad

Hot Standby lleva todas las copias a través de la red del inquilino y las distingue con etiquetas de Ethernet Segment de origen. Cada fuente, incluso si tiene una sola conexión, se asocia con un ES. Cada PE aguas abajo acepta su S-ESI primario y descarta los demás.

La alternativa queda cerca del receptor, a cambio de más ancho de banda y carga de control. Además, la ruta S-PMSI A-D nace de la configuración, no de la llegada de paquetes. Su presencia no prueba que la fuente produzca contenido útil. El BFD multipunto opcional observa los túneles de transporte, no la salud del codificador ni la integridad del flujo.

Tampoco hay necesariamente una única fuente física activa. RFC 9856 permite que distintos PE aguas abajo elijan S-ESI primarios diferentes mediante política local. Un receptor de una zona puede aceptar A mientras otro acepta B. Por tanto, el estado activo debe guardarse por punto de decisión.

El retiro de las últimas rutas A-D relevantes hace cambiar el primario. Un retiro masivo puede afectar varios dominios cuando comparten el ES. Si desaparece la última S-PMSI A-D del SFG, el PE debe eliminar la comprobación RPF basada en la etiqueta. El cambio del filtro es evidencia de una transición; no prueba por sí mismo que el servicio continuó correctamente.

Un recibo con siete preguntas

El recibo de redundancia propuesto no modifica el estándar. Obliga a responder siete preguntas operativas:

  1. Base de equivalencia: ¿qué fuentes, SFG, muestra, método y tolerancias justifican llamarlas iguales, y quién responde por ello?
  2. Autoridad de supresión: ¿se usa warm o hot, dónde se decide, qué elección o política rige y qué versión de configuración y capacidades estaban vigentes?
  3. Estado activo: ¿qué PE y circuito ganó en Warm Standby, o qué S-ESI aceptó cada PE receptor en Hot Standby?
  4. Señalización BGP: ¿qué rutas S-PMSI A-D y A-D por ES/EVI, RT, indicador SFG, preferencia DF, etiquetas y retiros vio cada decisor?
  5. Observación receptora: ¿qué origen o etiqueta se aceptó y qué contadores, huecos, duplicados, reordenamiento y frescura mostró una muestra limitada y respetuosa de la privacidad?
  6. Tiempo de conmutación: ¿cuándo ocurrió el fallo, la detección, el retiro, el nuevo estado, el último paquete anterior y el primero nuevo, y cuál fue el intervalo de pérdida o duplicación?
  7. Reversión: ¿cuál era la selección anterior, quién puede restaurarla, qué criterio obliga a abortar, cuándo vence la decisión y qué deuda queda?

Es una propuesta editorial de Daniel Kade, no un campo del RFC ni un certificado del IETF. Su utilidad está en no confundir pruebas: BGP describe control, una etiqueta describe filtrado, una muestra describe receptores y una comparación de aplicación describe equivalencia.

El estándar mínimo y la responsabilidad local

RFC 9856 no obliga a implementar ambos modos. Una red con equipos diversos necesita registrar las capacidades reales, no solo el diseño esperado. Las asignaciones IANA de los bits SFG y ESI-DCB dan significado común a las implementaciones, pero no prueban que una función esté soportada, configurada, propagada o programada en un equipo concreto.

Pedir al protocolo que certifique la aplicación ampliaría de forma incorrecta su promesa. Renunciar a la evidencia porque la norma es deliberadamente limitada sería igual de peligroso. La salida es mantener estrecha la afirmación interoperable y añadir pruebas locales con responsables claros.

Entonces la copia única deja de ser una fotografía tranquilizadora. Se convierte en una cadena auditable: equivalencia aceptada, selección identificada, rutas y filtros observados, receptores muestreados, conmutación medida y reversión disponible. Eso sí merece llamarse redundancia.

Fuentes