Resumen
- RFC 9800 permite reunir varios SID comprimidos en menos contenedores de 128 bits, pero obliga al origen a validar sus longitudes y a conservar la lista de segmentos que ya había decidido.
- Clarence Filsfils figura entre los cinco autores. El ahorro de cabecera no elimina complejidad: la desplaza hacia inventarios, anuncios, asignación de identificadores, pruebas y acuerdos de frontera.
El paquete corto y el paquete testigo
Una política SRv6 puede ordenar que un paquete atraviese varios nodos o funciones. Si cada instrucción viaja como una dirección IPv6 completa, muchos SID repiten el mismo Locator-Block y añaden ceros de relleno. La repetición es segura, pero encarece la encapsulación de listas largas.
RFC 9800, publicado en junio de 2025, define cómo eliminar esos bits comunes. Un CSID conserva Locator-Node y Function. Un contenedor de 128 bits puede guardar varios CSID y, cuando corresponde, el Argument del último. La lista final puede mezclar secuencias comprimidas con SID completos.
La norma no permite confundir “más pequeño” con “equivalente”. El origen debe expresar exactamente la misma lista de segmentos que la versión sin comprimir. Por eso conviene mantener durante el despliegue un paquete testigo sin compresión: muestra no solo que existe alcance, sino qué adjacency, tabla o función debería ejecutar cada paso.
Si la versión corta toma otro camino, el problema no es una métrica de eficiencia. Es una alteración de intención. La compresión es aceptable porque su transformación tiene reglas comprobables y un retorno visible a la representación completa.
Dos mecanismos para encontrar el siguiente SID
NEXT-CSID coloca el primer SID en forma completa y usa su espacio Argument para los CSID posteriores. Al terminar una instrucción, el punto final desplaza el siguiente CSID a la posición activa de la dirección de destino, limpia los bits inferiores que sobran, reduce el Hop Limit y vuelve a consultar la FIB IPv6.
REPLACE-CSID emplea entradas compactas de la Segment List del SRH. El primer elemento de la secuencia es un SID completo; los siguientes se almacenan en posiciones de tamaño fijo dentro de contenedores de 128 bits. Un índice en Argument señala qué posición se procesa. Cuando se agota el contenedor, el mecanismo avanza al siguiente elemento de la Segment List y construye una nueva dirección válida.
Ambos son sabores de comportamientos existentes. No convierten una instrucción End.X en otra cosa ni modifican el significado de un servicio. RFC 9800 lo delimita en su análisis de seguridad: cambia la codificación y el modo de obtener el próximo SID, no la semántica de la secuencia.
La coexistencia es posible, incluso dentro de una lista. Aun así, la norma aconseja evitar en general sabores distintos dentro del mismo dominio de encaminamiento o Locator-Block. La heterogeneidad consume conocimiento operativo: tablas de compatibilidad, contadores, casos de error y procedimientos de retirada diferentes.
La validación pertenece al origen
El nodo de origen puede recibir la lista de un controlador, calcularla o cargarla desde configuración. En los tres casos debe validar la estructura antes de comprimir. LBL no puede ser cero; la suma de Locator-Node y Function tampoco; y AL debe ocupar exactamente lo que queda de los 128 bits.
Una estructura que no supera el cálculo se considera desconocida. El origen no inventa un valor ni da por buena la autoridad del controlador. Simplemente deja ese SID sin comprimir. Esta salida parcial es importante: permite conservar una política útil sin convertir la optimización en una condición de disponibilidad.
La norma tampoco decide la ruta original. Restricciones, métricas, enlaces excluidos, protección o necesidades del servicio se resuelven antes. El origen comprime el resultado, no reinterpreta la intención. Así, el algoritmo común se mantiene estrecho y cada operador conserva sus decisiones locales.
Anunciar estructura no equivale a demostrar ejecución
Los SID de RFC 9800 deben anunciar su estructura, con longitudes que coincidan con la instanciación local y los bits Argument a cero. Las extensiones de IS-IS, OSPFv3, BGP, BGP-LS y procesos apoyados en PCEP pueden distribuir esos datos.
El anuncio permite decidir si la compresión es válida; no prueba que el plano de reenvío esté sincronizado. Un controlador puede guardar una versión antigua. Un equipo puede cambiar de software sin retirar una capacidad. Una FIB puede no aceptar el comportamiento que la base de datos todavía anuncia.
La evidencia operativa surge al reconciliar cuatro estados: instanciación del endpoint, anuncio del plano de control, inventario del controlador y decisión del origen. La aritmética de la norma hace localmente verificable la estructura, pero la organización sigue siendo responsable de la actualidad de cada registro.
Cambiar de bloque en la frontera
Una secuencia CSID suele compartir Locator-Block. Al atravesar dominios, ese prefijo común puede cambiar. End.LBS realiza el cambio cuando la frontera coincide con el nodo; End.XLBS lo asocia además a una conexión de capa 3 adyacente.
El bloque de destino es una propiedad local del SID. RFC 9800 no fija cómo lo conoce el origen: puede configurarse o llegar desde un controlador. Ese espacio fuera de alcance debe llenarse con un acuerdo operativo explícito, no con una suposición. Alguien debe ser responsable de la asignación, versión, prueba y retirada del mapeo.
La frontera muestra la virtud del diseño. La transformación tiene una regla portátil, pero la autoridad sobre el bloque sigue en el dominio que lo opera. No hace falta una institución global que apruebe cada transición; sí hace falta que ambos lados describan y prueben el mismo contrato técnico.
Elegir longitudes es elegir futuro
Un CSID más corto mejora la densidad del contenedor y reduce el espacio de numeración. Uno más largo ofrece más identificadores, pero repite menos instrucciones por cada 128 bits. La norma recomienda coherencia dentro de cada dominio para que esa elección siga siendo calculable.
También separa GIB y LIB. Los identificadores del GIB se comparten entre nodos de un bloque; los del LIB son locales a cada nodo. El uso recomendado guarda el recurso global para segmentos globales y coloca servicios, adjacencies y conexiones locales en el espacio local.
Una mala asignación puede tardar en hacerse visible. La cabecera de hoy funciona, mientras el espacio compartido se consume o las longitudes elegidas impiden crecer. El beneficio inmediato debe evaluarse junto con la duración del plan de direcciones.
La contribución de Filsfils, sin relato de autor único
El registro del RFC Editor acredita a Weiqiang Cheng, Clarence Filsfils, Zhenbin Li, Bruno Decraene y Francois Clad. El trabajo pasó por el grupo SPRING de la IETF, actualiza RFC 8754 y tiene codepoints registrados por IANA.
La página de autor de Cisco presenta a Filsfils como Cisco Fellow y describe su trayectoria en Segment Routing. Es contexto corporativo fechado, no una licencia para atribuirle en solitario el RFC, sus implementaciones o los resultados de redes que no se han medido aquí.
Su presencia en esta secuencia de especificaciones sí permite una lectura precisa: de la arquitectura y el SRH a la pregunta posterior de cómo transportar instrucciones largas sin desperdiciar el prefijo común. La respuesta no oculta la complejidad. La organiza en estructuras, negativas, codepoints, fronteras y responsabilidades que otro participante puede verificar.
Fuentes
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
