Resumen

  • XRO limita toda la ruta; EXRS, dentro de un ERO, limita un segmento durante la expansión de esa ruta explícita.
  • L despejado significa MUST excluir. L activado significa SHOULD evitar: la política local todavía puede usar el recurso.
  • La diversidad es un resultado que debe verificarse, no una promesa transportada por una bandera.

El mecanismo y sus límites

El originador aporta restricciones negativas. El nodo que calcula la ruta las aplica al elegir el siguiente salto o al expandir una ruta suelta. RFC 3209 ofrece el modelo ERO para incluir nodos abstractos; RFC 4874 añade señalización de exclusiones explícitas cuando el ingreso no necesita calcular la ruta completa. Un XRO puede identificar prefijos IPv4 o IPv6, interfaces sin numerar, sistemas autónomos y SRLG; las formas de prefijo e interfaz permiten distinguir los atributos pertinentes de interfaz, nodo y riesgo.

El alcance es la diferencia esencial. XRO afecta a toda la ruta calculada. EXRS, el Explicit Exclusion Route Subobject, está dentro de un ERO y queda limitado por el segmento de esa ruta explícita. Si L está despejado, el recurso identificado MUST excluirse: el nodo no debe introducirlo. Si L está activado, SHOULD evitarse; aun así, una política local puede atravesarlo. La exclusión concede veto sobre recursos nombrados, no autoría sobre la ruta restante.

Cuando un ERO incluye una resource que el XRO excluye obligatoriamente, prevalece la exclusión. La implementación debe rechazar el mensaje Path y devolver el error Routing Problem definido. Si las reglas dejan sin opciones de reenvío, el nodo debería enviar un PathErr que indique que la ruta fue bloqueada por Exclude Route. Un XRO demasiado complejo para la implementación o la política también puede rechazarse con el PathErr específico. Un nodo sin soporte XRO puede reenviar el objeto sin inspeccionarlo; los subobjetos o atributos no soportados pueden ignorarse. Por eso la compatibilidad no sustituye a la verificación.

Fixtures concretos de verificación

Enviar un Path cuyo XRO, con L despejado, prohíba una interfaz, un prefijo de nodo, un sistema autónomo y un SRLG. El resultado esperado es retirar cada elemento del conjunto factible antes de decidir el siguiente salto, sin imponer cuál será ese salto. Repetir con L activado: el tránsito sigue siendo posible y debe clasificarse como recomendación de evitar, no como incumplimiento de un MUST.

Añadir al ERO un recurso que el XRO marque también como exclusión obligatoria. El resultado esperado es rechazo con Routing Problem, no una preferencia silenciosa por el ERO. Construir una topología donde todo siguiente salto esté excluido; esperar un PathErr de ruta bloqueada por Exclude Route. Enviar un XRO que supere la complejidad aceptada; esperar el PathErr definido para XRO-too-complex.

Pasar el objeto por un nodo que no soporte XRO y enviar un subobjeto o atributo no soportado; registrar que puede reenviarse o ignorarse y después inspeccionar Record Route para detectar un recurso prohibido e intentar un nuevo cálculo cuando la implementación lo permita.

Registrar una primera ruta y pedir una segunda excluyendo sus nodos o SRLG. Verificar el Record Route resultante en vez de inferir diversidad de la petición. Probar un límite de dominio donde se elimine el detalle ERO ordinario pero deba conservarse un subobjeto de diversidad RFC 8390. Usar identificadores de ruta de referencia asignados por el cliente, el PCE o la red, y probar identificadores incoherentes o no soportados con sus errores definidos. Estos fixtures comprueban el protocolo; las fuentes congeladas no demuestran topología viva, calidad medida ni separación física.

GMPLS multicapa e identificadores de diversidad

RFC 6001 actualiza el modelo para GMPLS multicapa y multirregión. Los subobjetos de capacidad de conmutación y de etiquetas pueden excluir una capacidad de capa o un rango de etiquetas, manteniendo la diferencia entre MUST excluir y SHOULD evitar. El conjunto factible puede reducirse entre capas, no solo entre enlaces. RFC 8390 añade subobjetos XRO y EXRS de diversidad que pueden referirse, mediante un identificador asignado por el cliente, el PCE o la red, a un LSP o camino de referencia cuyas recursos detallados no conoce por completo quien solicita.

La diversidad obligatoria y la consultiva siguen siendo autoridades distintas; los subobjetos de diversidad especificados deben conservarse a través de una frontera aunque una política de seguridad elimine información ERO ordinaria. La corrección depende de quien resuelva y verifique la referencia.

Fronteras entre hecho, análisis y desconocido

Los hechos anteriores proceden de los textos RFC del RFC Editor congelados y del registro de erratas de RFC 4874. Análisis de Elias Ward: la exclusión obligatoria beneficia a servicios que necesitan separación, pero reduce el conjunto factible y puede convertir el establecimiento en un fallo; la evitación consultiva conserva disponibilidad a cambio de una separación más débil. Siguen desconocidos la topología real, el soporte de cada implementación, los despliegues, la latencia de establecimiento, las tasas de fallo, la diversidad medida y el impacto en clientes. No se formula ninguna alegación.

Una señal de diversidad no es prueba de diversidad física en las rutas activas.

Fuentes