Resumen

  • RFC 9862 representa una política SR mediante una asociación PCEP y cada ruta candidata mediante un LSP. La ruta es la unidad de señalización, pero algunas decisiones solo pueden evaluarse sobre el conjunto entero.
  • El TLV INVALIDATION lleva la bandera D de configuración en una ruta candidata. Si una sola ruta la activa, Drop-Upon-Invalid queda habilitado para toda la política SR; el descarte comienza únicamente cuando todas las rutas candidatas son inválidas.
  • Un comprobante de descarte de alcance político debe relacionar capacidades, miembros completos, banderas configuradas y operativas, cruce del umbral, ruta elegida y resultado en paquetes. Es una propuesta editorial de Daniel Kade, no un campo de RFC 9862 ni una orden del IETF.

Una luz roja en la fila de una ruta invita a pensar en un problema local. El dato llegó dentro de un objeto LSP, lleva la identidad de una ruta candidata y cabe perfectamente en una columna asociada a esa ruta. El almacenamiento es fiel al protocolo. La conclusión de que el efecto también es local no lo es.

La configuración de Drop-Upon-Invalid se comunica en el TLV INVALIDATION de una ruta candidata, pero no habilita la función solo para esa ruta. Basta que cualquier ruta candidata tenga D configurada para que toda la política SR posea la función. Aún no hay descarte. Para activarlo, todas las rutas candidatas deben haberse vuelto inválidas. Entonces la política entra en estado de descarte, selecciona la ruta habilitada de mayor Preference y mantiene la atracción del tráfico para desecharlo en el headend, en vez de permitir que encuentre una salida ordinaria.

Un objeto lleva la intención, un conjunto cruza el umbral, una política cambia de estado y los paquetes soportan el efecto. Son cuatro ámbitos. Un único valor D puede ser correcto y, al mismo tiempo, incapaz de explicar la decisión.

El vocabulario es por ruta; la condición es de conjunto

Una política SR puede contener una o varias rutas candidatas. RFC 9862 crea la SR Policy Association, o SRPA, para representar la política dentro de PCEP, mientras cada LSP miembro representa una ruta candidata. La elección es coherente con PCEP: su unidad de señalización es el LSP y, por tanto, la ruta es lo que un hablante puede anunciar, actualizar o reportar.

La misma elección exige cuidado al producir evidencia. La información relativa a la política se transporta a nivel de ruta, incluso cuando su significado depende de todos los miembros. La SRPA ofrece la relación, pero un sistema que conserva solo el LSP que lanzó la alerta no conserva necesariamente el conjunto que existía al tomarse la decisión. Los reinicios de sesión, cambios de miembros y muestreo parcial pueden borrar la fotografía relevante.

El color y el endpoint identifican la política. El originador y el discriminador participan en la identidad de la ruta candidata. Una ruta solo puede pertenecer a una SRPA, su identidad permanece estable durante la sesión PCEP y no puede duplicarse dentro de la misma política. Estas reglas permiten unir los registros; no garantizan que alguien haya guardado la unión y su tiempo.

La negociación de capacidades también responde una pregunta limitada. Ambos pares deben anunciar apoyo para SRPA antes de usarla, y un hablante que lo anuncia debe incluir la asociación en todos los LSP de política SR que origine. El TLV SRPOLICY-CAPABILITY declara por separado soporte para prioridad de cálculo, Explicit NULL, invalidación y operación sin estado. Recibir una SRPA sin la capacidad negociada genera un error y cierra la sesión. Eso prueba que el lenguaje podía emplearse, no que todas las rutas fueran inválidas ni que un paquete haya sido descartado.

D configurada y D operativa no son sinónimos

El TLV INVALIDATION incluye campos Config y Oper. En Config, D significa que la ruta candidata tiene Drop-Upon-Invalid habilitado. En Oper, D significa que el LSP está descartando tráfico activamente como consecuencia de la función. La letra compartida simplifica el formato, pero no autoriza a mezclar intención y estado.

La dirección del mensaje añade otra diferencia. De PCE a PCC, el ajuste ordena activar o desactivar. De PCC a PCE, el informe devuelve el ajuste actual y si el LSP está en estado de descarte. Guardar «última D» sin emisor, receptor, dirección, sesión y hora puede convertir una instrucción en confirmación o un deseo en observación.

El comportamiento normal muestra lo que se ha elegido evitar. Cuando un LSP se vuelve inválido, deja de atraer tráfico y este puede pasar a otro LSP o al IGP. Drop-Upon-Invalid conserva la atracción y desecha el tráfico en el headend. Puede ser una decisión responsable si una ruta de escape no autorizada sería peor que interrumpir el servicio. También puede ampliar una caída si la configuración estaba caducada o se aplicó a una política equivocada. La RFC define una conducta interoperable; no decide qué riesgo comercial u operativo debe preferir cada red.

La D operativa tampoco demuestra por sí sola el resultado de datos. Hacen falta contadores y observación de reenvío para saber si los paquetes llegaron al headend, cuánto se descartó y durante cuánto tiempo. Control, estado interpretado y consecuencia son fuentes distintas.

La transición decisiva es la última ruta válida

Según RFC 9256, una política SR es inválida cuando todas sus rutas candidatas son inválidas. Es una condición del conjunto. La primera pérdida reduce redundancia; otra puede cambiar la ruta activa; solo la desaparición de la última ruta válida cruza el umbral de la política.

Una vez cruzado, se comprueba si alguna ruta tenía Drop-Upon-Invalid habilitado. Si la respuesta es sí, la política entra en estado de descarte y activa la ruta habilitada de mayor Preference. RFC 9862 permite reportar al PCE una sola ruta candidata con D operativa. Es una señal suficiente para el protocolo, pero no una genealogía de la causa.

Pensemos en tres rutas. Una ruta antigua y poco preferida conserva D desde una decisión anterior. Las dos rutas principales no la tienen. Cuando estas dos fallan, todavía no hay descarte mientras quede una ruta válida. Al caer la última, aquella configuración antigua habilita la consecuencia para toda la política. El LSP que finalmente exhibe D operativa indica quién porta el estado presente, pero no quién autorizó la configuración, por qué seguía vigente ni qué cambio completó la condición colectiva.

Preference y computation priority exigen nombres distintos. La Preference de una ruta candidata escoge la mejor ruta: un número mayor gana y el valor predeterminado de RFC 9256 es 100. La prioridad de cálculo de RFC 9862 ordena la recomputación tras un cambio de topología: un número menor va primero y su valor predeterminado condicional es 128. Un campo genérico «prioridad» puede invertir la historia sin producir un error de tipo.

Un TLV ausente puede transferir la decisión a otro sitio

RFC 9862 define ausencias con significado. Si existe la capacidad y falta el TLV de prioridad de cálculo, se usa 128. Si falta la política de Explicit NULL, decide la configuración local. Ese TLV solo corresponde a SR-MPLS, debe ignorarse para SRv6, también se ignoran valores desconocidos y el operador puede anular lo señalado mediante configuración local.

Un vacío puede ser un valor por defecto, una delegación, algo no aplicable o un resultado reemplazado. Una columna nula no distingue esos casos. Para explicar un descarte, interesa el valor efectivo, su fuente, su precedencia, el software que lo interpretó y la sesión donde existió.

RFC 9862 exige que el operador pueda ver el identificador de política y el identificador de ruta candidata anunciados en la SRPA. Recomienda además mostrar capacidades de cada par y los LSP asociados a una política. Es la visibilidad mínima para investigar. El relato durable necesita convertir esas vistas en una transición enlazada.

Un comprobante para la ampliación de alcance

El comprobante de descarte de alcance político propuesto aquí comienza con color, endpoint, identidad SRPA, sesión PCEP y capacidades observadas en cada extremo. Luego congela el conjunto completo de rutas utilizado en la decisión, con originador, discriminador, Preference, D configurada y validez de cada una.

Después conserva la secuencia: cuándo y según qué fuente cada ruta pasó a inválida; cuál fue la última válida; en qué instante se volvió verdadero «todas inválidas»; qué rutas tenían D; cuál de ellas fue elegida; y en qué dirección apareció el informe D operativo. Cualquier diferencia entre intención PCE y reporte PCC debe quedar explícita.

Por último se vincula el resultado. ¿El tráfico siguió entrando en la política? ¿Qué contadores muestran descarte en el headend? ¿Cuándo se observó el primer y el último paquete desechado? ¿La recuperación vino de una ruta válida, un cambio de ajuste, una nueva membresía o la retirada de la política? Deben figurar el responsable, el servicio protegido, la fecha de revisión, la excepción y la reversión.

No se propone exportar la topología a una autoridad central. La SRPA y sus TLV pueden exponer información adicional. RFC 9862 hereda por ello la recomendación de sesiones PCEP autenticadas y cifradas con TLS entre PCE y PCC bajo la misma autoridad administrativa. El comprobante debe ser local, de acceso restringido y mínimo.

Tampoco es una extensión del estándar. Es una herramienta editorial para no confundir la ubicación de una bandera con el ámbito donde se ejerce la decisión.

Sources