Resumen
- Transport Class ID es un Color privado de 32 bits definido por el operador; identifica una clase local, pero no codifica una promesa universal.
- Si hay Color en TEA, en un Transport Class RT de BGP CT y en la ruta de servicio, RFC 9832 da prioridad al ámbito más específico en ese orden.
- La importación, la resolución del siguiente salto, el uso de respaldo, la instalación en FIB, el envío de paquetes y el cumplimiento del SLA son pruebas distintas.
La clase nace de una decisión humana
Una Transport Class agrupa túneles que ofrecen características de ingeniería suficientemente parecidas dentro de un dominio administrativo o entre dominios muy coordinados. Pueden coexistir RSVP-TE, SR-TE o Flex-Algo; puede buscarse baja latencia, protección o evitar ciertos nodos. RFC 9832 deja la clasificación exacta fuera de su alcance. El operador decide qué semejanza basta.
Después asigna un identificador de 32 bits, también llamado Color. Los valores no nulos son Private Use; cero representa Best Effort. Nada impide que dos dominios usen 100 para compromisos diferentes. Tampoco obliga a que “Gold” tenga idéntico presupuesto de pérdida, latencia o disponibilidad. El número funciona porque una configuración local le presta significado.
Guardar Color sin dominio, definición, propietario y versión es guardar media ruta. La igualdad sintáctica no acredita equivalencia operacional.
Tres colores que no son el mismo dato
El Color sub-TLV de Tunnel Encapsulation Attribute selecciona dentro del ámbito de una encapsulación. El Transport Class RT de una ruta BGP CT sirve como Route Target para la importación y puede actuar como Mapping Community. La Color Extended Community de una ruta de servicio expresa la intención del overlay.
La sección 7.10 resuelve su convivencia: primero el Color sub-TLV de TEA; después el Transport Class RT; al final, el Color de la ruta de servicio. Es una jerarquía de especificidad. No es licencia para colapsar los campos después de tomar la decisión.
Una bitácora reproducible conserva cada valor, su atributo, el par de origen, la política ejecutada y el resultado efectivo. Si sólo presenta “Color 100”, no puede explicar por qué una modificación de encapsulación venció la selección de clase del servicio.
La TRDB no es una tabla de resultados
Cada clase tiene una Transport Route Database. Una ruta BGP CT lleva RD:endpoint, Transport Class RT y un identificador de reenvío. Cuando la clase existe localmente, el RT determina la TRDB que importa la ruta. Esa es una acción de control.
RFC 9832 aclara que una TRDB puede existir únicamente para resolver siguientes saltos y que sus rutas no requieren presencia en el plano de reenvío salvo cuando resuelven uno. Por eso, “ruta importada” no significa “ruta usada”. Puede faltar la selección del overlay, la entrada de hardware o una encapsulación compatible.
El papel de Mapping Community enlaza la ruta con un Resolution Scheme. El esquema contiene una TRDB o varias en orden. Se busca por prefijo más largo y sólo se consulta una base de respaldo cuando las anteriores no encuentran el endpoint. Un administrador puede cambiar el orden. Si no existe un esquema para la clase, se usa Best Effort; si no hay Mapping Community, también se usa Best Effort y la ruta BGP CT no se añade a una TRDB de clase.
La compatibilidad mantiene tráfico, pero puede ocultar que el servicio abandonó su clase contratada.
Un respaldo exige contexto
Que la segunda TRDB haya resuelto el endpoint no dice por qué falló la primera. La causa puede estar en el túnel, la política de importación, Route Target Constraint, el endpoint, la configuración local o la tecnología de reenvío. El algoritmo ordena la búsqueda; no diagnostica el fallo.
El comprobante de resolución debe reunir ruta y par recibidos, todos los campos Color, Mapping Community efectiva, versión del esquema, lista ordenada de TRDB, coincidencia encontrada, túnel elegido y condición de respaldo. Si no aparece coincidencia en ninguna base, la ruta de servicio o BGP CT es no resoluble. Una ruta BGP CT de Best Effort inutilizable no debe propagarse.
RTC introduce otra frontera. Para construir el filtro de salida deben considerarse varios caminos EBGP RTC de un prefijo, no sólo el mejor. Antes de llamar “caído” a un túnel, hay que demostrar que la ruta debía haber llegado.
La traducción termina en la frontera
El ejemplo de namespaces no concordantes conserva color:0:100500 en el servicio y lo enlaza con TRDB 500, 300 y 100 en tres dominios. Los bordes reescriben el Transport Class RT de 500 a 300 y de 300 a 100. Así, cada pareja vecina coordina su tramo sin imponer un diccionario mundial.
La ventaja también marca el límite probatorio. El RT local acredita una instrucción de importación, no que ambos operadores definieran el mismo SLA. Hay que conservar RT recibido y emitido, definiciones de ambos lados, acuerdo, versión de política, ejecutor, hora y reversión. Si sólo queda 300, la historia de 500 y la autorización de la equivalencia desaparecen.
Del control al paquete
Cuando un borde MPLS anuncia una ruta BGP CT con next hop self, asigna un label e instala una ruta que intercambia o retira el label recibido antes de empujar el tráfico al túnel resuelto. Una implementación puede instalar selectivamente BGP CT en el FIB para reachability del control. Son pasos comprobables, no consecuencias automáticas de la importación.
Los ejemplos de interoperabilidad del RFC muestran el límite: un nodo sólo MPLS y otro sólo SRv6 no pueden comunicarse directamente; las rutas recibidas siguen inutilizables sin tecnología común. Después del FIB todavía faltan el paquete y la medición del servicio. Latencia, pérdida, disponibilidad y ventana contractual cierran la afirmación de SLA.
RFC 9832 es Experimental. Publicación no equivale a adopción ni rendimiento. Su errata verificada actual es editorial y cambia tres SN1 por SN11. La seguridad de sesión y los filtros limitan transporte y alcance, pero no autentican la semántica asignada por el operador.
La idea de Heng Lu de que Internet es “incoloro” devuelve la evaluación a lo que funciona y reduce fricción para los operadores. En este contexto, Color debe seguir siendo un índice sometido a prueba. Running-Code Primacy pide atributos, política y FIB reproducibles; Reality Layers separa identidad, significado, control, forwarding y resultado. Son criterios editoriales de BTW, no requisitos nuevos del IETF.
Fuentes
- https://www.rfc-editor.org/info/rfc9832/
- https://www.rfc-editor.org/rfc/rfc9832.html
- https://www.rfc-editor.org/errata_search.php?rfc=9832
- https://www.rfc-editor.org/info/rfc9012/
- https://www.rfc-editor.org/info/rfc9256/
- https://www.rfc-editor.org/info/rfc4364/
- https://www.rfc-editor.org/info/rfc4684/
- https://heng.lu/on-why-the-internet-is-colorless-because-efficiency-is-colorless/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
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
