Resumen

  • RFC 9884 amplía LSP Ping para comprobar en el egreso si un PSID está asociado a la SR Policy, al Candidate Path o a la Segment List descritos en la solicitud.
  • Un PSID puede abarcar varias listas. Cuando representa solo algunas, cada una exige un mensaje independiente; incluir varios sub-TLV en una sola solicitud no crea una validación conjunta.
  • El estándar no incluye LSP Traceroute para este mecanismo porque los nodos de tránsito no procesan el PSID. Además, con ECMP la etiqueta identifica la lista de SID, no el recorrido efectivo.

La utilidad del PSID nace de una pérdida de memoria. En SR-MPLS, el headend coloca instrucciones ordenadas en la pila de etiquetas. Los routers las intercambian o retiran durante el avance. Al llegar al extremo, la pila original puede haber desaparecido y el egreso ya no sabe, solo por ella, a qué camino SR atribuir el paquete.

RFC 9545 añadió una etiqueta local que sobrevive hasta ese punto. El egreso la asigna, el ingreso la coloca inmediatamente después de la última etiqueta del recorrido y el egreso la extrae. Ese PSID puede ayudar a correlacionar contadores, medidas, direcciones o mecanismos de protección. Antes de usarlo como referencia, hace falta comprobar su asociación.

La pregunta debe escoger su escala

RFC 9884 formula la comprobación mediante seis nuevos sub-TLV de Target FEC Stack: tres alcances, cada uno con formato IPv4 e IPv6. La solicitud puede preguntar por toda una SR Policy, por uno de sus Candidate Paths o por una Segment List concreta.

La llave se hace más detallada a medida que baja la escala. Para la Policy se comparan Headend, Color y Endpoint. Para el Candidate Path se suman Protocol-Origin, Originator y Discriminator. Para la lista se incorpora Segment-List-ID. El modelo procede de RFC 9256 y evita que el término genérico «ruta» borre las fronteras entre objetos.

Una respuesta positiva hereda el alcance de la pregunta, no uno mayor. Si la solicitud nombra la Policy, no demuestra qué lista utilizó un flujo. Si nombra el Candidate Path, no prueba automáticamente todos sus miembros. Si nombra una lista, no cubre a otra por parentesco.

La norma trata expresamente el caso incómodo. Un solo PSID puede representar algunas listas de uno o varios Candidate Paths. Entonces deben enviarse varios LSP Ping, uno por Segment List. Si se introducen varios sub-TLV PSID nuevos en el mismo mensaje, solo se procesa el primero. La economía de paquetes no puede cambiar la semántica del resultado.

Uno, diez y tres no son una escala de calidad

El código 1 indica que el Target FEC del PSID estaba mal formado. El 10 señala que la etiqueta no coincide con el FEC presentado en esa profundidad. El 3 declara que el router que responde es el egreso para ese FEC después de superar las comparaciones.

El 3 no es una nota máxima. Es una descripción de una relación concreta entre mensaje, etiqueta, profundidad, respondedor y estado provisionado o señalado. Detecta divergencias reales entre el controlador y el extremo. No confirma por sí mismo que la política estaba autorizada, que se instaló toda la programación, que un servicio llegó o que se cumplió un SLA.

Nadie interrogó a los nodos intermedios

RFC 9884 deja fuera LSP Traceroute porque el procesamiento del PSID ocurre en los extremos. Los transits no examinan esa etiqueta como objeto de este procedimiento. La sonda puede haber llegado correctamente sin producir una lista de testigos del trayecto.

La advertencia de RFC 9545 es todavía más directa. Con ECMP, una secuencia de SID puede distribuir paquetes por varios recorridos. El PSID identifica esa secuencia, no el camino físico que siguió cada paquete. Añadir la propia etiqueta puede alterar el hash y hacer que la sonda tome una opción distinta de un flujo anterior.

Por eso conviene separar seis hechos: intención de la Policy, Candidate Path seleccionado, lista asociada, mapeo del PSID, recorrido de la sonda y recorrido del tráfico real. RFC 8403 propone correlacionar sondas con topología IGP; RFC 8029 dispone de herramientas de ping y traceroute más amplias. Ninguna de esas observaciones aparece mágicamente en la respuesta del egreso.

La vuelta también puede ser rechazada

Los sub-TLV de RFC 9884 pueden viajar en estructuras de Reverse-Path Target FEC Stack o Reply Path. El endpoint los incluye en la respuesta y el headend vuelve a comprobarlos. Si no encajan, descarta la respuesta y debería registrar o comunicar el error, pero no cambia el código emitido por el extremo.

Esto obliga a distinguir silencio, solicitud malformada, mapeo fallido, respuesta recibida y respuesta descartada localmente. Un contador único de «timeout» borra la causa y desplaza la decisión desde el protocolo hacia una interpretación no documentada.

Fuentes