Resumen

  • draft-ietf-pim-pfm-forwarding-enhancements-08 obliga a usar GSH en una interfaz si algún vecino no admite GSI; al convertir, se mantienen (S,G) y holdtime, pero se ignoran los Sub-TLV específicos del flujo.
  • La optimización Relaxed-RPF escoge una sola de varias rutas punto a punto elegibles, de modo que capacidad, conversión, estado PFM_OPT_IF, recepción inicial, refresco posterior y resultado multicast necesitan comprobantes distintos.

El octavo vecino

El plan de migración parecía casi completo. Siete equipos anunciaban la nueva opción Hello de GSI. El octavo seguía en una versión anterior. El operador esperaba que los siete modernos intercambiaran el formato rico y que el antiguo recibiera una copia reducida.

En un medio compartido, esa no es la regla. Si hay un vecino sin soporte, el FHR debe originar GSH en la interfaz. El denominador común se aplica al segmento, no a cada destinatario individual. Los equipos modernos también ven la representación pequeña.

La revisión 08 de PIM Flooding Mechanism and Source Discovery Enhancements fue publicada el 25 de agosto de 2026 y vence el 26 de febrero de 2027. Datatracker la identifica como Internet-Draft activo del grupo PIM con estado previsto Experimental; la página del grupo la sitúa en la cola del RFC Editor, a la espera de asignación. Todavía no es un RFC, una encuesta de despliegue ni una prueba de interoperabilidad.

El documento añade valor real: más información por fuente y menos mensajes redundantes en enlaces paralelos. Pero su compatibilidad tiene una geometría concreta. Cada interfaz puede conservar una versión distinta del mismo anuncio, y una tabla basada solo en los campos comunes no puede mostrar la diferencia.

Dos recipientes para una fuente

RFC 8364 definió Group Source Holdtime. GSH transporta grupo, fuente y tiempo de retención. La revisión 08 añade Group Source Info, un TLV para una sola pareja (S,G) que admite Sub-TLV con información adicional asociada al flujo.

El núcleo común permite la convivencia. Los atributos crean la diferencia. Si un router no reconoce un tipo de Sub-TLV, debe ignorarlo y seguir procesando el GSI y los demás atributos. Una extensión desconocida no debe inutilizar el descubrimiento básico.

Por eso, “procesado correctamente” tiene dos lecturas. Puede significar que el encuadre era válido y que la fuente fue aprendida. No significa necesariamente que el receptor entendiera el atributo en que se basaba una política, una clasificación o una decisión posterior.

Un comprobante completo conserva el GSI original y el inventario de tipos comprendidos. Sin ese inventario, un contador de mensajes válidos mide transporte sintáctico, no conservación semántica.

La capacidad no es una propiedad de la versión

El soporte GSI se anuncia mediante una opción PIM Hello. Además, toda implementación debe ofrecer un mando para desactivar su uso. Cuando está desactivado, el router no puede anunciar la opción ni originar GSI.

Así, el número de versión del software no basta. La capacidad efectiva depende del vecino observado, la interfaz, el momento y la configuración local. Una captura de Hello de ayer no autoriza una conclusión sobre el estado después de una actualización o un rollback.

Si todos los vecinos de salida admiten GSI, el FHR habilitado debe originarlo. Si cualquiera no lo admite, debe originar GSH. Un router intermedio reenvía GSI sin cambios hacia interfaces completamente capaces; hacia una interfaz mixta lo convierte en GSH, preserva grupo, fuente y holdtime e ignora los Sub-TLV.

El mismo evento se ramifica: forma completa por una salida, forma reducida por otra. No existe un único “estado de la red” salvo que el sistema de observación conserve la decisión por interfaz.

La conversión elimina información a propósito

GSI y GSH pueden coexistir en el mismo mensaje. Para una pareja (S,G), GSI tiene precedencia y GSH actúa como respaldo. Esta coexistencia mantiene el servicio durante una migración, pero no certifica que cada receptor haya elegido la forma rica.

Al convertir GSI en GSH, los Sub-TLV no se encapsulan ni se resumen: se ignoran. Es una pérdida permitida, no un error de checksum. La continuidad del descubrimiento tiene prioridad sobre atributos que el vecino antiguo no puede consumir.

La decisión puede ser razonable, siempre que la operación no la describa como equivalencia. Un registro downstream idéntico en grupo, fuente y vigencia solo demuestra igualdad del núcleo. Para probar fidelidad hacen falta los bytes de entrada, la interfaz, el conjunto de capacidades, el GSH de salida y la lista de atributos retirados.

La agregación de varias entradas del mismo grupo en un GSH es recomendable, no obligatoria. Dos implementaciones conformes pueden generar cantidades diferentes de TLV. Comparar números de paquetes sin reconstruir el estado lógico produce falsos positivos de pérdida o duplicación.

Un Router-ID reúne varios caminos

Relaxed-RPF busca otra economía. Dos routers pueden mantener varias adyacencias punto a punto. El PFM ordinario transmite copias que después se filtran por RPF; la extensión permite escoger una.

Para ello, los routers anuncian el Router-ID de RFC 6395, usan el mismo valor de cuatro octetos en todas las interfaces de una VRF PIM y memorizan los identificadores vecinos. La unicidad dentro del dominio se presupone. Si dos routers comparten identificador, la base lógica de la optimización deja de ser válida.

Una opción Hello separada anuncia el soporte de optimización. Por cada Router-ID, PFM_OPT_IF contiene las interfaces donde ese vecino es el único vecino PIM y anuncia la opción. Una LAN compartida queda excluida.

Con Relaxed-RPF, el emisor elige una interfaz del conjunto mediante un método propio de la implementación. El receptor calcula el RPF estándar y puede aceptar por cualquier interfaz elegible cuando ambos soportan la función. El mensaje recibido demuestra qué copia llegó, no qué alternativas existían ni por qué se escogió ese enlace.

El refresco repara el presente, no el pasado

Reducir tres copias a una disminuye tráfico y procesamiento. También hace que la exactitud del conjunto elegible y la detección de fallo tengan más peso. El documento reconoce que el enlace seleccionado puede caer antes de que el emisor actualice PFM_OPT_IF; el mensaje se pierde o se retrasa.

Los anuncios periódicos actualizan el estado blando. Cuando llega el siguiente, la tabla vuelve a estar correcta. Pero un refresco posterior no prueba que el anuncio disparado por la aparición de la fuente llegara a tiempo. Si los primeros paquetes importaban, la pérdida temporal no desaparece porque el estado final sea verde.

El conjunto debe cambiar con altas y bajas de vecinos, cambios de capacidad, configuración, topología, upgrades y downgrades. Esos eventos deben abrir épocas de observación nuevas. Conservar solo el estado final elimina la explicación de la transición.

Dos formas de no enviar

La revisión también impide devolver un mensaje al originador por un enlace con un único vecino cuyo Router-ID coincide con el del origen. Para esa supresión basta el Router-ID; el vecino no necesita anunciar la opción de optimización.

No es la misma decisión que seleccionar una interfaz en Relaxed-RPF. La primera evita el retorno al origen. La segunda reduce copias entre dos pares capaces. Un único indicador operativo no permite distinguirlas.

Tampoco debe confundirse Router-ID con identidad criptográfica. Es un identificador de protocolo cuya unicidad depende de la operación. Un Hello íntegro puede contener un valor duplicado o asociado a estado obsoleto.

La cadena de confianza termina en cada salto

El documento depende de anuncios correctos y de la integridad de los Hello. RFC 8364 señala que un mensaje PFM link-local puede autenticarse entre vecinos, pero validar lo que dice sobre el originador exige confiar en cada router intermedio y en su autenticación del salto anterior.

Todos los saltos pueden ser legítimos y, aun así, perderse los Sub-TLV por una conversión autorizada. La autenticación demuestra custodia local; no demuestra que los mismos bytes o el mismo significado atravesaran el dominio.

La asignación IANA de tipos tampoco cierra la brecha. Un número estable permite reconocer un campo. No demuestra que el software lo implemente, que esté habilitado o que el consumidor lo use correctamente.

Nueve comprobantes para una afirmación rica

Una conclusión profesional separa:

  1. revisión y estado del documento;
  2. VRF, originador, Router-ID, interfaz y época;
  3. opciones Hello y configuración efectiva;
  4. GSI original con todos los Sub-TLV;
  5. conversión por interfaz y semántica eliminada;
  6. PFM_OPT_IF, RPF normal y enlace elegido;
  7. recepción del mensaje disparado frente al refresco posterior;
  8. comprensión e instalación en el consumidor;
  9. unión al SPT, replicación, paquete observado y resultado de aplicación.

El GSH fresco prueba un anuncio GSH fresco. No prueba que los atributos GSI sobrevivieran. La recepción periódica prueba convergencia posterior. No prueba entrega inicial. La autenticación del vecino prueba el salto. No prueba la fidelidad de extremo a extremo.

Límites del expediente

Las fuentes congeladas sustentan las reglas propuestas, el repliegue, los supuestos de Router-ID, la selección de una interfaz y la reparación periódica. No prueban adopción, producto, mejora de rendimiento, incidente, ataque ni entrega a usuarios.

RFC 8364 describe un prototipo y pruebas de campo limitadas del PFM original. No evaluaron el GSI/Sub-TLV ni Relaxed-RPF de esta revisión; citarlas como validación de la nueva extensión sería exceder la evidencia.

La lectura de Heng Lu obliga a mantener el alcance. Que el registro básico sobreviva no le concede autoridad sobre el significado eliminado. Esa autoridad permanece en el punto de conversión y en la red en ejecución que pueda mostrar el efecto.

Fuentes