Resumen

  • RFC 9831 permite que los tipos I, J y K incluyan un campo SRv6 SID a cero para expresar comportamiento o estructura deseados sin proporcionar la SID ejecutable.
  • La bandera S demuestra que llegaron los octetos del campo, no que el controlador haya resuelto el valor. El headend conserva la autoridad y la obligación de consultar su contexto SR, comparar y rechazar con una causa precisa.
  • Una cadena de prueba conserva banderas, valor bruto, referencia de nodo o adyacencia, fuentes locales, SID resuelta, verificación, selección, instalación y observación, en vez de resumir todo como “SID recibida”.

La presencia también puede ser una delegación

Un campo opcional suele plantear dos estados: está o no está. RFC 9831 introduce para SRv6 un tercer estado operativo que merece su propio nombre. La bandera S puede indicar que el campo SID está presente, mientras los 128 bits contienen la dirección IPv6 cero.

El controlador puede usar esa forma cuando quiere indicar el comportamiento de extremo o la estructura SID deseados, pero no especificar la SID. No faltan bytes. Falta deliberadamente la elección final. El mensaje entrega una referencia y restricciones suficientes para que el receptor complete el trabajo.

Si no hay campo SID, tampoco puede aparecer el bloque de comportamiento y estructura. Si el campo está y vale cero, dicho bloque sí puede viajar. Si el campo lleva una SID no nula, el emisor ya propone un valor concreto. Ausencia, cero presente y valor presente reparten de manera diferente la responsabilidad entre emisor y receptor.

Guardar los dos primeros como null elimina la decisión de delegar. Guardar los dos últimos como “SID presente” inventa equivalencia entre una solicitud de resolución y una instrucción ejecutable. La evidencia mínima necesita S, B, el valor completo y el contexto que identifica nodo o enlace.

Una ruta explícita puede contener nombres por resolver

La Segment List sub-TLV describe una ruta explícita hacia el extremo, y cada Segment sub-TLV representa una pieza ordenada. Explícito no significa que todas las piezas estén ya en la representación que usará el plano de reenvío.

Los tipos C y D nombran nodos IPv4 o IPv6 para obtener una etiqueta SR-MPLS. E a H describen adyacencias con direcciones e identificadores de interfaz. I a K llevan referencias equivalentes para SRv6. RFC 9256 asigna al headend la resolución de esos descriptores a una etiqueta o SID.

El controlador fija el sentido del camino sin tener que poseer cada asignación local en tiempo real. Eso desacopla la intención de ciertos cambios internos. Al mismo tiempo, convierte el estado del receptor en una dependencia ejecutiva. La misma referencia puede resolverse de forma distinta en dos equipos con vistas SR distintas.

Por eso no basta archivar el anuncio. Hay que conservar qué información consultó cada headend, su versión, la hora, el resultado y cualquier ambigüedad. El anuncio prueba una entrada común; no prueba una salida común.

El mismo cero no siempre significa lo mismo

La bandera A declara que el campo SR Algorithm tiene significado en los tipos a los que se aplica. Sin A, el emisor debe escribir cero y el receptor ignorar el campo. Ese cero no pide elegir un algoritmo local; simplemente no afirma ninguno.

En el campo SID de I/J/K, en cambio, el cero puede expresar que el controlador desea behavior o structure sin fijar SID. La superficie numérica coincide, pero la regla del tipo y de las banderas cambia su significado. Normalizar antes de interpretar el contexto borra esta diferencia.

S dice que el campo SID existe, no que sea utilizable. B anuncia el bloque de comportamiento y estructura para B, I, J y K; depende de la presencia del campo SID, aunque este pueda seguir a cero. V ordena a SRPM verificar la SID; no comunica que la comprobación haya terminado bien.

Una consola que une A, S, B y V en un único semáforo pierde cuatro preguntas: ¿se declaró algoritmo?, ¿vino un campo?, ¿se expresó una expectativa semántica?, ¿se pidió y completó una verificación? La trazabilidad empieza por no confundirlas.

El headend completa y también contradice

RFC 9256 llama SR-DB al conjunto conceptual de información que ayuda a calcular y validar. No obliga a una aplicación concreta a crear una base con ese nombre. Sí exige, en la práctica de estos tipos, disponer de contexto local para relacionar prefijos, nodos, interfaces y adyacencias con etiquetas o SID.

La verificación puede fallar porque una SID suministrada no aparece en ese contexto. Puede fallar porque la referencia C–K resuelve a una SID diferente de la anunciada. Puede fallar porque un segmento no inicial no se resuelve en absoluto. Un contador único de “ruta mala” no diferencia falta de conocimiento, contradicción ni hueco de resolución.

La limitación multidominio evita atribuir omnisciencia al receptor. Cuando el headend no puede verificar la alcanzabilidad de una SID remota, RFC 9256 dispone usar tipos A o B para esas SID; la primera SID debe ser siempre alcanzable. La representación cambia al llegar al límite de lo que el contexto local puede demostrar.

El receptor decide, por tanto, más que la validez de los octetos. Interpreta qué campos cuentan, consulta evidencia local, completa el valor, compara la versión recibida y juzga la lista. La autenticación del vecino BGP protege el origen de la sesión; no certifica que una dirección, una interfaz, un comportamiento o una vista topológica sean correctos.

Analizar bien no equivale a poder ejecutar

RFC 9831 fija longitudes concretas para cada combinación de campos. La regla evita que una implementación desplace los límites y lea mal el siguiente sub-TLV. La sintaxis correcta cierra ese riesgo, no los restantes.

El tipo identifica el significado estructural; las banderas seleccionan campos; SRPM valida la ruta en conjunto. Una lista que mezcla segmentos SR-MPLS y SRv6 es inválida según RFC 9256, aunque cada elemento aislado tenga longitud y banderas perfectas.

RFC 9830 ya deja fuera de BGP la validación semántica de la ruta. RFC 9831 afirma que sus extensiones no cambian las operaciones ni la gestión de fallos de SR Policy. El caso de RFC 9830 publicado antes trató la distancia entre transporte BGP e instalación. Este caso es diferente: dentro del dato transportado, la aparente presencia de SID puede ser una referencia todavía incompleta.

IANA asigna números; la red asigna capacidad

El registro IANA coordina los códigos de los tipos C–H e I–K y los bits A y S. Sin esa coordinación, dos implementaciones podrían leer el mismo número como estructuras diferentes. Con ella, comparten gramática.

No comparten automáticamente topología, soporte, datos recientes ni resultado. El código Type J no demuestra que un router lo implemente; un identificador de interfaz no demuestra que el enlace siga siendo el mismo; una SID resuelta no demuestra programación; una programación no demuestra el paso de un paquete. El carácter Experimental de RFC 9831 tampoco prueba adopción.

“Compatible” puede referirse solo al parseo. “Resuelta” pertenece a la consulta local. “Verificada” pertenece a la comparación. “Activa” pertenece a la selección de candidato. “Instalada” pertenece al plano de reenvío. “Observada” pertenece a una prueba controlada. La calidad de un sistema de operación se mide también por su resistencia a juntar esos verbos.

Escribir recibos que permitan devolver el fallo

El registro del controlador debe incluir intención, orden, tipo, referencias, A/S/B/V, longitudes, valores sin transformar, versión y hora. Tiene que distinguir explícitamente SID no nula suministrada, SID cero para delegar y campo omitido.

El registro del headend agrega fuentes SR, versión, valor resuelto, tiempo y ambigüedad. La verificación agrega presencia, coincidencia, mezcla tecnológica y motivo de rechazo. Después vienen la validez del candidato, la elección activa, la escritura de reenvío, el paquete y el resultado de servicio.

Con esa separación, una delegación que no encuentra correspondencia vuelve al propietario de la información local. Una SID suministrada que contradice el contexto vuelve a la relación emisor-receptor. Un fallo de programación posterior no se adjudica al resolutor. La utilidad está en dirigir la reparación, no en producir más casillas.

Fuentes