Resumen

  • El borrador de PIM usa multidifusión IPv6 nativa dentro de una red SRv6: PIM o un controlador instala estados (S,G)/(*,G) con interfaces de entrada y salida, no una lista de SID para cada rama.
  • Flex-Algo puede alterar la ruta unicast que alimenta la decisión RPF, pero RFC 9502 exige anunciar por separado la participación del plano IP y la del plano SR.
  • La entrega debe probar anuncio de fuente, definición y participantes del algoritmo, RPF, propiedad y aplicación del estado, mapeo del overlay, replicación y resultado del receptor.

Una frase de entrega no es una descripción del flujo

En una reunión de traspaso, «hemos activado multicast sobre SRv6» funciona como resumen. La dificultad aparece cuando se usa el resumen como evidencia. El locator SRv6 puede estar activo, los SIDs unicast pueden responder y la fuente puede ser alcanzable por una ruta restringida. Ninguno de esos hechos enumera las interfaces por las que un router debe copiar el siguiente paquete multicast.

RFC 8402 define Segment Routing como source routing para unicast y deja fuera de alcance su aplicación a multicast. RFC 8986 aporta la programación de red SRv6. El borrador multicast-over-SRv6 declara, en cambio, que la distribución multicast es ortogonal a SR. Las versiones HTML y XML conservan el mismo diseño: reutilizar las funciones IPv6 nativas de una red solo IPv6.

La entrada real se parece a (S,G), una interfaz entrante elegida por RPF y un conjunto saliente. No lleva una secuencia de segmentos que ordene las bifurcaciones. La red y el árbol pueden pertenecer a vocabularios distintos sin contradicción: SRv6 describe el underlay; PIM y la tabla multicast describen la distribución.

El número 128 necesita apellidos

PIM-SM deriva el lado upstream de la tabla unicast: acepta tráfico por la interfaz que el router usaría para llegar a la fuente. Si el prefijo de la fuente se anuncia para Flex-Algo 128, el borrador permite que ese cálculo IP restringido determine el RPF. Así se puede alinear la topología multicast con una política de latencia o exclusión sin convertir el paquete en SR.

RFC 9350 demuestra por qué el número no basta. La definición incluye cálculo, métrica y restricciones; debe ser coherente dentro de su ámbito. Un nodo que no soporte la definición puede dejar de participar y retirar estado. RFC 9502 añade la separación decisiva: IP Flex-Algo es un plano independiente y su participación se anuncia separadamente de SR-MPLS o SRv6.

Por ello, dos equipos pueden decir correctamente «soportamos algoritmo 128» y hablar de capacidades distintas. Para PIM importa la participación IP que produce la ruta hacia la fuente. Un indicador de participación SR no puede prestarle esa prueba. El cambio de ruta también tiene tiempo: si la tabla unicast converge antes que el join/prune, el nuevo RPF y el árbol anterior pueden discrepar durante la transición.

El conflicto más peligroso es una propiedad implícita

El borrador contempla un controlador que calcula e instala estado multicast IPv6 nativo. Sirve para árboles específicos o para una operación que no desea depender de los mensajes de PIM. Pero el dispositivo sigue necesitando una interfaz entrante exacta y una lista de réplicas aplicadas. Que el controlador acepte una operación no acredita que todos los nodos la hayan programado ni que el paquete haya llegado.

PIM y el controlador pueden coexistir si operan sobre fuentes y grupos diferentes. La palabra «diferentes» es el contrato de propiedad. Si coinciden en un (S,G), un temporizador de PIM puede retirar lo que el controlador considera permanente, o una reconciliación central puede reemplazar el estado distribuido. El borrador deja la instanciación northbound detallada para otro documento. No especifica aquí autorización, atomicidad ni rollback; tampoco permite suponerlos.

La telemetría útil debe nombrar al propietario, la versión de intención, el resultado por nodo y el estado del plano de reenvío. Sin esas columnas, dos sistemas saludables pueden producir juntos un árbol roto.

Encapsular no demuestra la pertenencia

La ruta se hace aún más larga con MVPN o Global Table Multicast. RFC 6513 establece la arquitectura MVPN y RFC 6514 sus procedimientos BGP. RFC 6515 admite direcciones de infraestructura de proveedor IPv4 o IPv6; RFC 7716 extiende el modelo a GTM; RFC 8950 permite anunciar NLRI IPv4 con next hop IPv6.

El ejemplo del borrador usa PIM-SSM para el árbol proveedor, MP-BGP para PMSI y rutas multicast del cliente, e IP-in-IPv6 para el transporte. El valor 4 de Next Header solo indica que el paquete interno es IPv4; 41, que es IPv6. No identifica la VPN correcta, no enumera miembros y no confirma la decapsulación. El propio borrador dice que no hay procedimiento específico de SRv6. La prueba debe conservar la cadena flujo del cliente → PMSI → (S,G) proveedor → interfaces de rama → PE de salida → receptor autorizado.

El estado editorial del borrador también tiene límites

La API del Datatracker, la ficha y el historial congelados lo sitúan como Internet-Draft activo del grupo PIM. La cabecera propone Informational, sin AD responsable, shepherd ni telechat registrados. No es RFC, informe de implementación ni medición de producción.

La comparación con la revisión 00 muestra que la revisión 01 actualizó fecha, vencimiento, número de versión y cabeceras de página, no el mecanismo. Su afirmación de no añadir problemas de seguridad más allá de las referencias es una delimitación de alcance. No autentica la escritura del controlador, no valida el FAD y no detecta una asociación PMSI equivocada.

Fuentes y frontera de lo conocido

El conjunto congelado incluye el texto 01, sus representaciones HTML y XML, el texto 00, la API, la página y el historial. Las referencias técnicas son RFC 7761, RFC 6513, RFC 6514, RFC 6515, RFC 7716, RFC 8402, RFC 8950, RFC 9350, RFC 9502 y RFC 8986. Ninguna aporta un despliegue identificado, matriz de fabricante, tiempo de convergencia, tasa de pérdida o SLA.