Resumen

  • RFC 9960 define la política SR P2MP mediante Raíz y Tree-ID, hojas, caminos candidatos e instancias PTI. Esos identificadores describen un estado de reenvío, no el derecho de un cliente o institución a recibir el servicio.
  • RFC 9961 dirige ping o traceroute a una PTI concreta dentro de un camino candidato. El propio texto dice que no prueba el camino candidato abstracto y limita el mecanismo a MPLS, no SRv6.
  • Un recibo de audiencia multipunto debe vincular membresía, política, camino, PTI, hojas, generación del controlador, alcance OAM y cierre de la transición. Es una propuesta editorial de Daniel Kade, no un requisito del IETF.

Alcanzar una hoja no explica por qué está allí

Un árbol punto a multipunto ahorra repetición. El paquete recorre una vez los tramos comunes y solo se copia donde las rutas se separan. La RFC 9960 da a Segment Routing una arquitectura para construir ese árbol en SR-MPLS y SRv6.

La política se identifica por <Root, Tree-ID>. Contiene un conjunto de hojas y uno o más caminos candidatos, cada uno con restricciones u objetivos de optimización. El controlador calcula las instancias de árbol P2MP y coloca los segmentos de replicación en la Raíz, los nodos intermedios y las hojas.

Esta estructura responde con precisión dónde debe duplicarse el tráfico. No responde por qué una hoja pertenece al servicio. El mismo nodo puede representar un cliente vigente, una sede cerrada, una función interna o una dirección reasignada. El estándar reutilizable no pretende conocer esos vínculos.

La audiencia nace en otro lugar. Puede proceder de contratos, identidades, permisos de un evento, roles administrativos o una lista de emergencia. Luego una cadena de automatización convierte esos sujetos en direcciones y contextos de servicio. Esa conversión es el punto donde se puede perder una baja, repetir una identidad o aplicar una versión antigua.

Un reenvío correcto no corrige ese error. Lo ejecuta con eficiencia.

La política no es una sola topología

Una política puede contener varios caminos candidatos. La Raíz selecciona el activo con las reglas de RFC 9256. Un camino puede carecer de PTI si el controlador no satisface las restricciones o puede conservar más de una mientras prepara un cambio.

RFC 9960 exige que solo una PTI esté activa por camino candidato. Si hay dos activas dentro del camino que lleva tráfico, las hojas pueden recibir duplicados. Por eso el Instance-ID no es un detalle ornamental. Durante make-before-break, la instancia nueva se instala y activa antes de retirar la anterior. Las dos comparten Tree-ID, pero no el mismo estado ni necesariamente la misma topología.

Un registro que diga solo «política operativa» borra la transición. Tampoco basta un resultado agregado por árbol. Hay que saber qué Instance-ID se probó, qué hojas formaban esa generación y cuánto duró la coexistencia.

El contexto del servicio complica aún más la lectura. Normalmente una PTI se asocia con un servicio multipunto, pero el RFC permite que varios servicios compartan el transporte cuando se diferencian en la Raíz y las hojas. Salud de la PTI y corrección de la audiencia son dos afirmaciones distintas.

El controlador materializa una decisión ajena

Una persona, un nodo o una máquina puede provisionar Raíz, hojas y caminos. El controlador calcula el árbol, asigna Replication-SIDs e instala el estado mediante PCEP, BGP, NETCONF/YANG u otro medio. También puede recibir una topología explícita.

Ese controlador posee poder operativo: puede hacer que el tráfico alcance nuevos nodos. Pero el poder no revela por sí solo la fuente de autorización. Una API válida demuestra que alguien pudo enviar una orden; no que tuviera derecho a modificar la audiencia.

El Policy Mirror de Heng Lu ayuda a mantener la distinción. La infraestructura refleja quién manda en la práctica. Precisamente por eso debe cotejarse con el mandato declarado, no presentarse como su prueba automática.

Los fallos de instalación también forman parte de esa historia. Un conflicto de SID puede impedir un segmento. RFC 9960 recomienda informar la causa, limitar reintentos y alertar; incluso contempla desmontar una PTI parcial. Si cada reintento sobrescribe el anterior, el éxito final oculta durante cuánto tiempo existió una configuración incompleta.

Un ping con apellido y límites

La RFC 9961 extiende las herramientas OAM para una política SR P2MP con encapsulado MPLS. La solicitud identifica camino candidato y PTI, e incluye Raíz, Tree-ID e Instance-ID. Así evita una frase ambigua como «probamos el multicast».

Su cautela es tan útil como su mecanismo. El sub-TLV prueba una PTI concreta dentro de un camino; no prueba el camino candidato entero. La especificación no cubre SRv6. Una respuesta positiva corresponde a ese plano de datos MPLS, esa instancia, ese alcance de respuesta y ese momento.

No prueba la recepción de la aplicación, el derecho contractual, la actualidad del sistema de membresía, la ausencia de duplicados en la transición ni la seguridad total del dominio. Tampoco convierte un backup probado hoy en continuidad futura.

La honestidad de alcance hace posible una cadena de evidencia. El resultado OAM se puede unir a la configuración y a la decisión de audiencia sin obligarlo a decir más de lo que observó.

El recibo debe empezar en la fuente de membresía

Primero se congela la decisión: identificador del servicio, fuente autorizada, versión, vigencia, responsable, miembros y exclusiones. Después se registra el mapeo entre identidades estables y hojas o Buds de red. Un Bud merece atención particular porque recibe el servicio y además lo replica.

El recibo añade la identidad técnica: <Root, Tree-ID>, tupla de origen del camino candidato, restricciones, objetivo y motivo de selección. Luego incorpora Instance-ID viejo y nuevo, hojas exactas, generación del controlador, asignación de SID y resultado por nodo.

La observación debe nombrar el protocolo, el límite MPLS de RFC 9961, la PTI objetivo, los respondedores solicitados, hora y resultados. La transición registra el orden de activación, el intervalo con dos instancias, cualquier evidencia de duplicación, el disparador de reversión y la retirada de la PTI antigua.

Finalmente se reconcilian todas las instancias activas y de respaldo con la población autorizada. El recibo expira y enumera lo que no demuestra. No guarda secretos ni necesita publicar nombres de clientes: una vista de transparencia puede usar cantidades, fechas, motivos y excepciones.

Los hashes detectan sustituciones entre versiones. No certifican la legitimidad del registro de miembros ni la veracidad del sensor. El recibo multipunto es una propuesta local, no una estructura creada por RFC 9960 o 9961.

La retirada es una acción positiva

Los sistemas suelen conservar buena evidencia de las altas: solicitud, instalación y prueba. Las bajas se degradan a ausencia. Sin embargo, quitar una audiencia exige llegar a la instancia activa, a las de respaldo y a cualquier instalación parcial.

El cierre debe probar que la antigua PTI ya no recibe tráfico dirigido desde la Raíz y que sus estados de replicación fueron retirados. «Inactiva» no significa necesariamente «eliminada»; ambas afirmaciones deben distinguirse.

La seguridad añade condiciones. RFC 9960 advierte que una frontera SR mal configurada puede admitir inyección externa y que un controlador puede formar un bucle de replicación que cause una tormenta hasta agotarse TTL o Hop Limit. Un conjunto de respuestas verdes no evalúa por sí solo esos controles.

Límites y fuentes

Las fuentes no demuestran un despliegue de ningún operador, una inclusión incorrecta, una duplicación real ni una ventaja medida. El análisis une mecanismos publicados con una obligación local de evidencia. MPLS, SRv6, árboles estáticos y controladores diferentes requieren observaciones ajustadas a su realidad.

La conclusión no necesita más alcance: Tree-ID identifica una política de transporte; Instance-ID identifica una realización; el ping observa una parte del reenvío. El mandato de audiencia tiene que venir de otra autoridad y conservarse junto al árbol que lo ejecutó.