Resumen

  • El 25 de agosto de 2026, la IESG aprobó draft-ietf-idr-sr-policy-seglist-id-14 como Proposed Standard. En la fecha de corte seguía siendo un Internet-Draft activo en la cola del RFC Editor, y la IANA aún mostraba el valor 19 como registro temporal.
  • El Segment List ID de 32 bits es único únicamente dentro de un Candidate Path. No es una identidad global ni vuelve inmutable la secuencia: el controlador puede conservar el ID después de cambiar los SID. La prueba operativa debe unir alcance, contenido, validación SRPM, instalación y tráfico.

Una continuidad que solo existía en la pantalla

Un controlador entra en una ventana de cambio con la lista 42 formada por tres instrucciones. El mismo 42 aparece en la telemetría, en una configuración NETCONF y en el panel de aseguramiento. Durante la intervención se sustituye la secuencia de SID, pero el identificador permanece.

La gráfica no se corta. El objeto sigue verde. Sin conservar el contenido anterior, la organización puede concluir que la ruta fue estable cuando lo único estable fue la etiqueta.

La escena es ilustrativa, no un incidente atribuido a un fabricante. Sirve para delimitar la noticia: el estándar añade una referencia útil, no una declaración de que dos apariciones del mismo número representan el mismo recorrido ni el mismo momento.

La aprobación todavía no es un RFC

El anuncio oficial de la IESG, fechado el 25 de agosto, aprueba la revisión 14 de «BGP SR Policy Extensions for Segment List Identifier» como Proposed Standard. El trabajo procede del grupo Inter-Domain Routing.

Al cerrar la evidencia el 28 de agosto, el Datatracker mostraba la revisión como Internet-Draft activo, con estado RFC Ed Queue y pendiente de comprobación de referencias y formato. La acción de la IANA seguía en curso después de un cambio de versión. El texto es del 24 de agosto, fue actualizado en el Datatracker el 26 y expira el 25 de febrero de 2027.

La tabla pública de la IANA todavía situaba el valor 19 como asignación temporal: registro del 19 de diciembre de 2025, vencimiento el 19 de diciembre de 2026 y referencia a una revisión anterior. La aprobación, la edición final y la asignación permanente son etapas separadas. Ninguna demuestra uso en producción.

El problema que resuelve sí es concreto

Una SR Policy contiene uno o varios Candidate Paths, y cada uno puede contener varias listas de segmentos. RFC 9830 define la distribución por BGP hacia el headend, que escribe las instrucciones en los paquetes.

Sin ID, un nodo que informa estadísticas por lista puede repetir todos los SID. El controlador compara secuencias completas para reconocer la lista. La especificación también plantea configuraciones YANG/NETCONF que deben señalar una lista aprendida por BGP. Un entero reduce octetos y trabajo de correlación.

El sub-TLV opcional se anida dentro del Segment List de tipo 128, bajo el Tunnel Type SR Policy de tipo 15. El nuevo tipo es 19 y la longitud correcta es seis octetos. Cuatro octetos guardan el entero sin signo; banderas y reservado viajan a cero. Los valores entre 1 y 0xffffffff son IDs; cero equivale a no asignar ninguno.

Es una solución mínima. Precisamente por eso no incorpora un ciclo de vida global ni un sistema de versiones.

Candidate Path e instante forman parte de la clave

Un ID distinto de cero debe ser diferente para cada lista dentro del mismo Candidate Path. Fuera de ese ámbito puede repetirse en otra política o en otro headend. Cualquier referencia externa tiene que incluir el Candidate Path.

Pero ese par tampoco identifica un contenido histórico. El borrador permite conservar el ID cuando cambia la secuencia de SID. Dos registros con el mismo Candidate Path e ID pueden describir instrucciones diferentes si pertenecen a revisiones distintas.

La evidencia mínima debe guardar el NLRI —Distinguisher, Color y Endpoint—, el Candidate Path, el ID, la secuencia ordenada y una revisión, hora o huella de contenido. Así se evita que una acción NETCONF y una serie de métricas se unan por número aunque hayan observado estados distintos.

RFC 9857 ya usa un identificador de lista en BGP-LS. Esa afinidad semántica facilita la correlación, pero no crea un espacio de nombres universal. Cada consumidor conserva ámbito, tipo, origen y frescura.

Tres fallos con tres consecuencias distintas

Una longitud que no sea seis hace que el NLRI de BGP SR Policy sea malformado y obliga a aplicar treat-as-withdraw según RFC 7606. Retirar la información no prueba que el tráfico tenga una alternativa sana.

Varias instancias del sub-TLV dentro de una sola lista se resuelven usando la primera e ignorando las demás. En cambio, si varias listas del mismo Candidate Path comparten un ID no nulo, la colisión es semántica y la gestiona SRPM; el receptor puede eliminar la asociación de ID en todas ellas.

Un headend antiguo crea el tercer caso. RFC 9830 establece por defecto que un Candidate Path con un sub-TLV desconocido no se considera utilizable. Añadir el ID opcional puede, por tanto, inutilizar el camino en un despliegue mixto. La recomendación es anunciarlo selectivamente solo a nodos compatibles.

La palabra «opcional» describe el formato, no garantiza neutralidad operacional.

La autoridad termina en los paquetes observados

BGP transporta la descripción, pero no valida el túnel. SRPM analiza la política; después hay que saber si el Candidate Path quedó utilizable, si fue seleccionado, si el headend programó las instrucciones y si el tráfico siguió el resultado esperado.

La cadena auditable separa versión y registro; capacidad por par; UPDATE recibido; tuple de política, Candidate Path, ID y contenido; validación; selección; programación; telemetría de la misma revisión; y resultado de los paquetes. El valor 19 no sustituye ninguno de esos pasos.

También existe un límite de confianza. El borrador advierte que los IDs pueden revelar información crítica o comercialmente sensible y deja su gestión por YANG/NETCONF fuera de alcance. La organización debe definir asignación entre controladores, colisiones, reutilización, versiones, retención y acceso.

Las implementaciones declaradas por H3C y ZTE se basan en la revisión 3 y fueron actualizadas en febrero de 2025. El propio texto señala que no son aval de la IETF ni verificación independiente. No permiten estimar adopción actual.

Fuentes