Resumen

  • RFC 9902 es una especificación IETF Standards Track que define el módulo YANG ietf-isis-sr-mpls para Segment Routing IS-IS sobre el plano de datos MPLS.
  • Amplía el modelo IS-IS de RFC 9130 y depende del modelo SR independiente del protocolo de RFC 9020.
  • Separa activación, anuncio y recepción del Mapping Server, funciones opcionales de protección, configuración y estado operativo, en lugar de presentarlos como un único interruptor.

El contrato operativo comienza con enable. Al establecer ese leaf en true se activa IS-IS SR-MPLS y se anuncian las extensiones correspondientes con los parámetros configurados en el modelo SR base. El leaf no asigna etiquetas, no calcula rutas y no realiza el reenvío. Antes de modificarlo, el operador debe revisar el SRGB, el SRLB, los algoritmos y los demás recursos del modelo RFC 9020, y compararlos con el estado IS-IS previsto.

RFC 9902 amplía RFC 9130, mientras RFC 9020 proporciona la base SR común. Esta separación es relevante para la revisión: un cambio específico de IS-IS puede depender de recursos configurados en otra rama. La comprobación previa debe leer ambas capas, las capacidades anunciadas y el estado operativo esperado.

El intercambio con el Mapping Server tiene dos controles distintos. bindings/advertise/policies selecciona las políticas cuyos bindings pueden anunciarse. bindings/receive controla la recepción y el procesamiento. De forma predeterminada, IS-IS no anuncia ni procesa entradas del Mapping Server. Activar una dirección no activa silenciosamente la otra, y la existencia de recursos SR no permite deducir una política de intercambio.

El modelo también amplía el Fast Reroute de las interfaces. TI-LFA puede habilitarse cuando exista soporte, y Remote LFA puede usar una ruta SR en lugar de una ruta LDP cuando la opción esté soportada y Remote LFA esté habilitado. Son declaraciones de funciones y elecciones de configuración opcionales; RFC 9902 no las impone. La selección de TI-LFA puede incluir protección de nodo y disjunción SRLG; sus prioridades son configurables y un valor menor tiene mayor preferencia.

El estado observable incluye indicadores de capacidad SR, algoritmos, información SRGB y SRLB, preferencia del Mapping Server, Prefix-SID, Adj-SID y TLV de vinculación SID/etiqueta. Las ampliaciones de configuración y del estado operativo de la LSDB permiten revisar esos elementos. Sin embargo, el modelo no garantiza que una implementación reenvíe tráfico, calcule rutas, asigne etiquetas o sea segura e interoperable simplemente porque el modelo esté estandarizado.

Comprobaciones concretas de conformidad

  1. Confirmar que la implementación anuncia soporte para ietf-isis-sr-mpls y para las funciones opcionales previstas antes de escribir sus controles.
  2. Leer los recursos SR de RFC 9020 y comparar SRGB, SRLB, algoritmos, Prefix-SID, Adj-SID y bindings esperados con el estado IS-IS planificado.
  3. Mantener enable en false durante la preparación y activarlo únicamente después de aprobar la comparación.
  4. Verificar que no haya políticas de anuncio del Mapping Server seleccionadas sin autorización expresa y que la recepción permanezca desactivada cuando no se pretenda procesar bindings entrantes.
  5. Revisar después de la activación las capacidades, algoritmos, rangos, SID, bindings y resultados de la LSDB.
  6. Escribir controles de TI-LFA o Remote LFA basado en SR solo cuando las funciones estén soportadas; para SR-based Remote LFA, comprobar también que Remote LFA esté habilitado.
  7. Usar NETCONF o RESTCONF mediante transporte seguro y autenticación mutua, y aplicar NACM para limitar operaciones y contenido según el rol.

RFC 9902 identifica dos clases de seguridad. Los cambios no autorizados en Segment Routing, bindings del Mapping Server o TI-LFA pueden descartar o desviar tráfico y crear una denegación de servicio. El acceso de lectura puede revelar capacidades del router, algoritmos, SRGB, SRLB, preferencia del Mapping Server y ampliaciones de la LSDB. El estado operativo no es, por tanto, una información inocua.

En el análisis de Theo March, los controladores deberían validar las dos capas, detectar deriva en rangos y estado anunciado, aplicar un despliegue gradual y separar los roles de autorización para escrituras, intercambio de políticas y lecturas sensibles. Esto es análisis, no un mandato RFC. Las RFC no aportan aquí pruebas sobre proveedores, controladores, rendimiento, adopción, incidentes, costes de migración ni umbrales de reversión.

Ruta de decisión del operador: si capacidades, recursos, autorizaciones y políticas coinciden, desplegar el modelo en un ámbito controlado, guardar el estado previo, activar y comparar el estado operativo con el inventario aprobado. Si aparece una discrepancia, un anuncio inesperado, un cambio de binding o una protección no prevista, retirar la nueva configuración en orden inverso, restaurar los valores guardados, desactivar enable si corresponde y comprobar la LSDB y el estado de control del tráfico. Es un procedimiento local, no una garantía de seguridad ni de ausencia de interrupciones.

Fuentes