Resumen

  • RFC 8362 exige el bit U en sus LSA extendidas. Así, un router que no reconoce la función puede almacenarlas y propagarlas con el alcance indicado; la entrada en la LSDB es un recibo de transporte, no un certificado de capacidad.
  • Una estructura nueva y bien formada puede circular aunque sea opaca. Una LSA extendida con longitudes incoherentes u otro error de codificación no debe instalarse, reconocerse ni inundarse, y el rechazo debería contarse y registrarse.

El nodo que repite sin interpretar

El LS Type de OSPFv3 combina un código de función con un bit U y bits de alcance. RFC 5340 define la conducta ante una función desconocida. Si U vale cero, el router trata la LSA como si su alcance fuera local al enlace. Si U vale uno, la guarda y la inunda según el alcance codificado en el propio tipo.

RFC 8362 asigna a las versiones extendidas de varias LSA un nuevo código: suma 32 decimal, o 0x20, a la función base correspondiente, y ordena activar U. Esto permite que dos routers capaces intercambien información a través de uno antiguo. El intermediario sostiene la continuidad del protocolo, aunque no comprenda la semántica nueva.

No es trabajo ficticio. El router recibe una estructura aceptable, conserva su instancia en la base de estado de enlace y participa en la inundación fiable. Pero su autoridad probatoria termina ahí. Para afirmar que soporta la extensión hacen falta datos de versión y capacidad; para afirmar que la usa hace falta configuración y salida del cálculo; para afirmar que cambió el servicio hacen falta RIB, FIB y paquetes.

Una consola que marque todo eso como «presente» elimina cuatro preguntas diferentes: ¿llegó la LSA?, ¿el software reconoce su gramática?, ¿la función está habilitada?, ¿la decisión llegó al plano de reenvío? RFC 8362 permite expresamente que la primera respuesta sea sí y las demás no.

La envoltura que puede sobrevivir a su lector

Las LSA históricas de OSPFv3 tienen cuerpos fijos. Las extendidas llevan la información variable en estructuras de tipo, longitud y valor, con sub-TLV cuando hace falta. La envoltura deja de estar atada a todos los significados futuros. Un router puede reconocer que la LSA es estructuralmente válida sin conocer cada elemento contenido.

La flexibilidad no decide por sí sola si una función funciona con despliegue parcial. RFC 8362 exige que cada especificación nueva describa qué ocurre cuando solo parte de la topología conoce su TLV o sub-TLV. Algunas funciones pueden tolerar nodos de tránsito opacos; otras necesitan extremos compatibles o una cadena completa. Inundar el dato no satisface automáticamente esa condición.

Dentro de una LSA extendida conocida, los TLV y sub-TLV desconocidos se ignoran durante el análisis y el procesamiento. Ignorar no es borrar ni apoyar. El registro exterior puede seguir circulando mientras un componente permanece sin interpretar. RFC 9492 ofrece un ejemplo posterior con atributos de enlace específicos de una aplicación: anunciar atributos para una aplicación no es lo mismo que habilitarla en el enlace.

Lo desconocido no es lo roto

La compatibilidad futura necesita tolerancia frente a significados nuevos, no frente a estructuras defectuosas. RFC 8362 establece que una LSA extendida con información de longitud incoherente u otro fallo de codificación no se instale en la LSDB, no reciba acuse y no se inunde. El error debería aparecer en contadores y registros.

La operación necesita tres clases:

  1. Conocida y válida: se analiza y solo se usa conforme a la extensión y la configuración.
  2. Desconocida pero válida: se conserva como contenido opaco y se propaga dentro del alcance cuando lo exige U.
  3. Malformada: queda fuera de la base y de la inundación, con evidencia del rechazo.

Si un equipo descarta todo lo desconocido, rompe el puente que permite convivir a versiones distintas. Si trata cualquier error como una novedad aceptable, amplía el dominio de un defecto. La frontera útil está entre novedad válida e invalidez, y debe ser visible para el operador.

También cambia el vocabulario del informe. La vista de LSA desconocidas demuestra custodia. Un decodificador de TLV demuestra reconocimiento. Un contador de malformed demuestra rechazo. Ninguno demuestra por sí mismo selección de ruta o entrega de paquetes.

El recibo de lo que circuló

RFC 5340 identifica una LSA mediante LS Type, Link State ID y Advertising Router. El número de secuencia, el checksum y la edad distinguen instancias y actualidad. La suma de comprobación excluye la edad, que cambia mientras la LSA permanece y se inunda. Por eso no conviene prometer identidad byte a byte entre todos los saltos.

Un recibo más preciso anota tipo y alcance, router anunciante, identificador de estado de enlace, secuencia, checksum, área o interfaz y momento de observación. Esa clave permite correlacionar la propagación. Después se añaden, como pruebas separadas, la versión capaz, la configuración activa, el resultado SPF o de la aplicación, las entradas RIB/FIB y la observación del tráfico.

El método evita que una copia persistente se convierta en una afirmación atemporal. Una herramienta de gestión puede sondear tarde, conservar un valor antiguo o normalizar los bits de alcance. La procedencia de la muestra es parte de su significado.

Migrar no consiste en llenar la LSDB

Para una migración completa, RFC 8362 propone instancias OSPFv3 separadas para LSA heredadas y extendidas. La instancia nueva comienza con mayor distancia administrativa, es decir, menor preferencia. Se comparan las RIB, se cambia la preferencia cuando las diferencias están explicadas, se verifica de nuevo y solo después se retira lo heredado. La decisión se apoya en resultados de rutas, no en el simple éxito de la inundación.

El modo disperso mantiene las LSA antiguas como fuente del SPF normal y utiliza las extendidas solo para funcionalidad nueva. Ahorra dos instancias completas, pero exige conocer la capacidad de los nodos relevantes y las reglas de soporte parcial de cada extensión. Ver algunas LSA extendidas no dice si la topología capaz está completa.

RFC 9587, también cofirmada por Lindem, define un modelo YANG de OSPF. Incluye un control de soporte de LSA extendidas cuyo valor predeterminado es falso, y estado operativo para TLV desconocidos con tipo, longitud y valor hexadecimal. Es una buena separación: la gestión puede conservar la opacidad como dato sin fingir que la convirtió en significado.

Una atribución limitada para Acee Lindem

Acee Lindem, Abhay Roy, Dirk Goethals, Veerendranatha Reddy Vallem y Fred Baker publicaron RFC 8362 en abril de 2018. El documento actualiza RFC 5340 y RFC 5838. La página vigente del grupo Link State Routing enumera a Lindem entre sus responsables; es un cargo fechado, no propiedad de la norma ni autoridad sobre las redes que la aplican.

La evidencia permite decir que Lindem participó en un consenso que hizo extensible OSPFv3 sin obligar a que cada portador entienda el contenido, y que más tarde ayudó a describir su representación operativa. No permite atribuirle en solitario las LSA extendidas, cada TLV posterior o la conducta de un fabricante.

La autoría acotada coincide con una arquitectura de autoridad distribuida. El originador decide qué anuncia. El protocolo decide cómo viaja una envoltura válida. La implementación decide qué reconoce. La configuración decide qué puede actuar. El sistema de rutas y reenvío materializa consecuencias. El operador decide qué conserva como prueba.

Siete enlaces para una afirmación completa

Un registro defendible une, sin sustituirlos, siete datos: identidad y alcance de la LSA; gramáticas reconocidas por cada versión; función habilitada; salida del cálculo; instalación en RIB y FIB; efecto observado sobre tráfico; y rechazos de estructuras malformadas.

El primer dato no es una versión pobre del último. Describe otra responsabilidad. A veces, la conducta más correcta de un router frente a información que no entiende consiste en llevarla fielmente hasta quien sí puede leerla. La disciplina está en reconocer ese servicio y detener la afirmación exactamente donde se detiene su evidencia.

Fuentes