Resumen

  • RFC 10018 permite anunciar un P-tunnel SR P2MP mediante <Root, Tree-ID> y actualizar sus hojas con rutas Auto-Discovery de MVPN o EVPN. Es evidencia del estado de señalización, no un comprobante de que el controlador instaló el mismo PTI completo ni de que cada hoja recibió la carga correcta.
  • La unidad de cierre debe incluir el candidato, el Instance-ID, el contexto MVPN/EVI y la hoja: intención, A-D, aceptación del controlador, segmentos instalados, FIB, OAM y canario de carga tienen que referirse a la misma época. La retirada necesita una cadena inversa igualmente demostrable.

El fallo parcial es el estado que más se parece al éxito

En una sesión punto a punto, una caída total suele ser visible. En un árbol P2MP, una rama puede morir mientras la raíz sigue transmitiendo y el resto de las hojas mantiene los contadores. El volumen agregado cae poco; la topología conserva su color verde; el controlador responde que el objeto está activo. La experiencia de una sola región, cliente o aplicación queda reducida a una variación estadística.

Esa forma de fallo exige una disciplina distinta. No basta con preguntar si existe el árbol. Hay que preguntar si el conjunto observado en cada capa coincide con el conjunto contratado.

RFC 10018 proporciona una base precisa. Define cómo MVPN y EVPN pueden usar P-tunnels construidos con PTI de SR-MPLS o SRv6, cómo el PMSI Tunnel Attribute los identifica y cómo las rutas BGP A-D alimentan el conjunto de hojas de una SR P2MP Policy. También especifica ingress replication sobre SR como una opción separada.

El documento no afirma que la señalización sea la entrega. Sus propios límites dejan fuera los procedimientos concretos mediante los cuales el módulo de política habla con el controlador y este programa los nodos. Esa modestia es una ventaja: permite asignar la prueba correcta a cada actor.

Cuatro verbos que no deben compartir el mismo «OK»

Anunciar, descubrir, instalar y entregar son operaciones distintas.

El anuncio usa el PTA. Para un P-tunnel SR P2MP, el Tunnel Identifier contiene primero un Tree-ID de 32 bits y después la dirección de la Root. El par <Root, Tree-ID> identifica la política. IANA registra 0x0C para SR-MPLS P2MP Tree y 0x0D para SRv6 P2MP Tree.

El descubrimiento ocurre con las rutas A-D. En MVPN, una Intra-AS I-PMSI o Leaf A-D importada puede añadir un PE de salida al conjunto de hojas; su retirada lo elimina. La salida se incorpora como Leaf o Bud al importar el anuncio pertinente y, cuando el indicador Leaf Information Required lo exige, origina una Leaf A-D. EVPN realiza el ciclo equivalente con IMET, S-PMSI y Leaf A-D.

La instalación comienza después. El módulo MVPN/EVPN crea el candidate path, actualiza las hojas y entrega ese estado al módulo SR P2MP Policy. Este se comunica con un controlador mediante PCEP, BGP, NETCONF u otro mecanismo cuya operación concreta queda fuera de RFC 10018. El controlador calcula un PTI y cose Replication segments en Root, nodos intermedios y hojas.

La entrega es el último verbo: el Tree-SID conduce la carga al PTI, los nodos P generan copias y la hoja elimina el identificador para entregar en el contexto MVPN o EVPN correspondiente.

Una API que representa los cuatro verbos con status=success elimina la única información útil durante un incidente. El registro debe indicar qué actor completó qué transición, para qué versión y con qué evidencia posterior.

El Tree-ID persiste mientras cambian las encarnaciones

RFC 9960 diferencia la política, sus candidate paths y los PTI que realizan cada candidato. Un candidato puede tener cero PTI si el controlador no encuentra una topología que cumpla las restricciones. Puede tener más de uno durante make-before-break, pero solo uno debe estar activo. Si dos instancias del candidato activo permanecen activas, las hojas pueden recibir duplicados.

Cada PTI posee un Instance-ID de 16 bits. En el plano de control, sus Replication segments se identifican con Root, Tree-ID, Instance-ID y Node-ID. Así, una política estable puede atravesar muchas topologías y muchos estados de forwarding sin cambiar su <Root, Tree-ID>.

Esta distinción evita tres errores. Primero, que un ping de la instancia antigua certifique la nueva. Segundo, que una confirmación retrasada de un nodo se atribuya al despliegue equivocado. Tercero, que una retirada incompleta se pierda cuando el mismo identificador se reutilice.

No es suficiente guardar la configuración final. Hay que conservar la época: revisión del conjunto de hojas, identidad del candidato, Instance-ID, topología calculada, versión de programación por nodo, momento de activación y momento de retirada.

«Calculado» no significa «programado en todos»

RFC 9960 contempla el fallo de instalación de un Replication segment. Un conflicto de SID es un ejemplo. El nodo debería informar del éxito o del error, idealmente con la causa. El controlador debería reintentar con un límite, alertar tras el fallo terminal y puede desmantelar el PTI si faltan algunos segmentos. Si falla la Root, se recomienda retirar la instancia.

Por tanto, un PTI puede estar calculado y ser inutilizable; parcialmente programado y mantener la Root cerrada; o ser activado bajo una política local que acepta un subconjunto. El estándar no decide qué contrato de servicio debe asumir ese riesgo.

Una estrategia descrita instala primero hojas y nodos intermedios y deja la Root para el final. Solo cuando lo anterior está confirmado se abre la inyección. El orden es una defensa contra el árbol incompleto, no una garantía universal de producto.

La pregunta de control es concreta: ¿qué condición convierte el estado del controlador en ACTIVE? Si la respuesta es «se enviaron todas las solicitudes», la etiqueta no prueba aceptación. Si significa «todos los nodos respondieron», aún falta comprobar FIB. Si significa «la Root está activa», aún falta OAM y carga por hoja.

Los contratos con controladores deberían exigir las pruebas por Node-ID: Replication-SID, versión solicitada, respuesta, causa de rechazo, número de reintentos, estado terminal y hora. El resumen debe ser una función transparente de esos datos.

El último salto tiene semántica de servicio

El Tree-SID identifica el PTI en el forwarding. No siempre identifica por sí solo el servicio al que se entregará la carga. En un P-tunnel exclusivo de una MVPN puede bastar. Cuando varias MVPN comparten el árbol, un label MPLS asignado por el upstream o un SRv6 Multicast Service SID proporciona el contexto.

RFC 10018 registra los comportamientos End.DTMC4, End.DTMC6 y End.DTMC46, con valores IANA 76, 77 y 78. También establece reglas para la transposición en algunos formatos SRv6. La hoja puede recibir por la rama adecuada y aun así consultar la tabla errónea, formar mal el service SID o entregar a otro contexto.

EVPN añade el split horizon en Ethernet Segments con multihoming. Su objetivo es impedir copias BUM duplicadas. SR-MPLS usa la posición del label ESI; SRv6 emplea Arg.FE2 con End.DT2M. Una prueba que solo confirma «llegó un paquete» no distingue la copia legítima de una duplicación que debió filtrarse.

La evidencia final necesita Tree-ID, Instance-ID, hoja, MVPN/EVI, identificador de servicio, estado de split horizon y resultado de carga. El Tree-SID es autoridad para encaminar dentro del PTI; no es una autorización de tenant ni un recibo de aplicación.

Ingress replication no pasa por el mismo sistema

Con ingress replication, el PE de entrada crea una copia para cada salida y usa forwarding unicast. RFC 10018 dice expresamente que el módulo SR P2MP Policy y el controlador no intervienen.

Eso cambia la prueba. Para IR se revisan la membresía de cada salida, el identificador de servicio, la política unicast o SR-TE seleccionada y la copia individual. Para P2MP se revisan el PTI, los segmentos cosidos, la instancia activa y el OAM del árbol.

También cambia el tratamiento de tráfico. IR puede asociar tratamiento por egress en los casos definidos. En P2MP, la replicación ocurre dentro del PTI, de modo que la entrada impone un tratamiento común al árbol y no uno diferente para cada hoja.

Un fallback de P2MP a IR debe verse como una migración entre dos cadenas de autoridad. El cierre debe indicar cuándo dejó de inyectar la Root, cuándo empezaron las copias individuales, si hubo solapamiento y cuándo desapareció el estado antiguo. De otro modo, la recuperación puede crear duplicados sin que ningún contador global los denuncie.

OAM separa el PTI que funciona del que solo comparte nombre

RFC 9961 define ping y traceroute para una SR P2MP Policy. La prueba identifica un candidate path y un PTI concretos, atraviesa sus Replication segments y recoge respuestas de las hojas. Las implementaciones deberían poder probar incluso una instancia que no es la activa.

La precisión es esencial durante make-before-break. Root y Tree-ID pueden ser iguales mientras la topología y los segmentos de la nueva instancia son diferentes. Solo el Instance-ID evita que la salud de una encarnación se transfiera a otra.

Cuando los Replication segments no son adyacentes, el OAM P2MP verifica la estructura de replicación y el OAM unicast debe comprobar el tramo que los conecta. RFC 9961 deja la detección del fallo unicast fuera de su propio ámbito. Un resultado no cubre automáticamente al otro.

Y el eco todavía no es la carga. Puede demostrar que el contexto de forwarding procesó una sonda; no que la producción utilizó el service SID correcto, que la pérdida fue aceptable, que el split horizon actuó ni que el receptor consumió el contenido. Por eso hace falta un canario por hoja, con secuencia o marca verificable y ligado a la misma época del PTI.

Una ecuación de conjuntos produce incidentes accionables

Conviene mantener ocho conjuntos:

  • E: egress exigidos por el servicio;
  • A: egress presentes en A-D/Leaf A-D;
  • C: hojas aceptadas por el controlador para el candidato actual;
  • I: hojas con todos los segmentos necesarios instalados para el PTI;
  • F: hojas incluidas en el forwarding de la instancia activa;
  • O: hojas que responden al OAM de ese candidato e Instance-ID;
  • D: hojas que reciben la carga correcta en su MVPN/EVI;
  • W: hojas retiradas con desprogramación y quietud probadas.

Un servicio puede requerir E = A = C = I = F = O = D. Si tolera un subconjunto, debe nombrarlo y añadir propietario, motivo, impacto, caducidad y condición de recuperación. La retirada se completa cuando la hoja desaparece de los conjuntos activos y entra en W.

Las diferencias localizan el control: E − A apunta a provisión o descubrimiento; A − C, a la ingestión del controlador; C − I, a la instalación; I − F, a la correspondencia entre respuesta y FIB; F − O, al camino; O − D, al contexto de servicio o a la aplicación.

Hay que comparar miembros y versiones, no solo cantidades. Doce respuestas que incluyen una hoja antigua no cubren doce destinos actuales.

Hasta dónde llega la fuente pública

Las fuentes técnicas permiten afirmar cómo se identifican y actualizan las piezas. No permiten afirmar que un operador concreto las usa, que un proveedor soporta todos los comportamientos ni que ocurrió un incidente real como el ejemplo de doce hojas.

IANA prueba que existen asignaciones de código; no que una imagen de software las implemente. La condición Standards Track tampoco obliga a desplegar. El IETF mantiene semántica común, no el forwarding de una empresa.

La separación encaja con la primacía del código en ejecución formulada por Lu Heng: un documento no puede declarar un efecto que la red no muestra. La especificación inicial mínima y decisión futura localizada añade el límite complementario: la interoperabilidad común no elimina la decisión local de adopción, activación y riesgo.

El estado ejecutado tampoco es automáticamente legítimo. Una hoja retirada que sigue recibiendo es una realidad observable y, precisamente por ello, una violación demostrable del contrato.

Fuentes