Resumen

  • El rol documentado de Ketan Talaulikar en el trabajo colaborativo del IETF proporciona una vía a nivel de persona hacia tres temas operativos conectados: la identidad y las reglas de ruta candidata de una SR Policy en el RFC 9256, los límites de descriptor y error de los registros de topología BGP-LS en el RFC 9552, y la visibilidad OSPFv3 de los localizadores y capacidades SRv6 en el RFC 9513.
  • Las especificaciones definen diferentes tipos de evidencia. Una tupla de política identifica una política prevista en un headend; el estado de ruta candidata registra alternativas utilizables; BGP-LS describe objetos de topología para los consumidores; y OSPFv3 expone información de enrutamiento sobre SRv6. Ninguno de esos registros, por sí solo, prueba la ruta de paquetes que produjo una implementación en ejecución.
  • El contrato operacional, por lo tanto, tiene capas: los estándares definen la semántica, las implementaciones los realizan, los operadores eligen la política, los planos de control publican registros actuales, y las observaciones de reenvío muestran resultados. La automatización confiable mantiene esas capas vinculadas sin pretender que una sola de ellas sea toda la red.

Un registro a nivel de persona organizado en torno al significado operativo

El perfil del IETF Datatracker de Ketan Talaulikar registra liderazgo en el área de enrutamiento y trabajo continuo en protocolos de enrutamiento. Los tres estándares examinados aquí lo mencionan en roles editoriales, creando una clara conexión a nivel de persona con sus temas técnicos. El RFC 9256 define la arquitectura de la Política de Segment Routing. El RFC 9552 define cómo BGP-LS distribuye información de estado de enlace e ingeniería de tráfico. El RFC 9513 define extensiones OSPFv3 que hacen visible la información de localizadores y capacidades SRv6 en el sistema de enrutamiento.

Esa atribución necesita límites cuidadosos. Cada RFC es trabajo colaborativo del IETF moldeado por múltiples autores o editores, discusión en grupos de trabajo, revisión, experiencia de implementación y el proceso de estandarización. El registro respalda el crédito por la participación documentada de Talaulikar. No respalda una afirmación de que él solo inventó los mecanismos, seleccionó la política de un operador, escribió una implementación particular o controló un despliegue. Tampoco proporciona base para afirmaciones sobre clientes, incidentes, resultados comerciales o mejoras medidas.

Esta es una historia operativa, no una biografía heroica. La automatización puede actuar de forma segura solo cuando puede saber sobre qué objeto está actuando, qué registro está vigente, qué alternativas son válidas y qué sucedió cuando no se pudo usar la entrada. El registro de estándares atribuidos a Talaulikar es significativo aquí porque conecta la política, la topología y la capacidad en los puntos donde la intención abstracta debe convertirse en estado de protocolo.

Cinco capas que no deben colapsarse

La primera capa es el estándar. Un estándar define una semántica compartida: cómo se identifica una SR Policy, cómo se relacionan las rutas candidatas con ella, cómo los registros BGP-LS describen la topología o cómo OSPFv3 transporta información SRv6. Proporciona un contrato entre implementaciones independientes. No instancia una política en una red particular, elige un objetivo de negocio o informa si llegó un paquete.

La segunda capa es la implementación. El software convierte la especificación en analizadores, estructuras de datos, lógica de selección, interfaces de programación y salida operativa. Una implementación puede ajustarse a un estándar y aún diferir en opciones admitidas, capacidad, diagnósticos, comportamiento de versión y defectos. La existencia de un RFC no puede probar que una determinada compilación de software admita todos los mecanismos o maneje correctamente todos los límites.

La tercera capa es la política del operador. Los operadores deciden qué colores tienen significado en su entorno, qué extremos importan, qué rutas candidatas deben existir, qué preferencias deben aplicarse, qué consumidores de topología pueden actuar y cómo deben contenerse los fallos. Esas decisiones no las proporciona el estándar. Son elecciones de gobernanza local expresadas a través de la configuración y la automatización.

La cuarta capa es el estado actual del plano de control. Esto incluye la SR Policy y las rutas candidatas actualmente conocidas en un headend, los registros BGP-LS actualmente disponibles para un consumidor y los anuncios OSPFv3 actualmente instalados en la base de datos de estado de enlace. Estos registros son sensibles al tiempo. Un identificador correctamente definido adjunto a un estado obsoleto puede seguir llevando a la automatización en la dirección equivocada.

La quinta capa es el reenvío observado. Es la evidencia de lo que hizo el sistema en ejecución: qué próximos saltos e instrucciones de segmento se programaron, qué paquetes siguieron qué ruta y cómo cambió el comportamiento después de una actualización o error. La observación del reenvío no reemplaza los estándares ni los registros; prueba si su cadena prevista llegó a la ejecución. Un sistema confiable conserva la distinción entre las cinco capas mientras retiene suficiente correlación para pasar de una a la siguiente.

El RFC 9256 comienza con una identidad de política de tres partes

El RFC 9256 identifica una SR Policy mediante una tupla compuesta por el headend, color y endpoint. La compacidad de esa tupla es importante. Convierte una frase como "usar la ruta de baja latencia" en un objeto cuyo alcance puede determinarse. La política no es simplemente una propiedad deseada. Es una política en un headend particular, asociada con un color particular, hacia un endpoint particular.

Cada componente evita un tipo diferente de ambigüedad. El headend identifica dónde se instancia la política y dónde ocurre la dirección hacia ella. El color proporciona una asociación entre el tráfico o la información de enrutamiento y un objetivo de política dentro de un contexto acordado. El endpoint ancla la política al destino hacia el cual se pretende que la lista de segmentos transporte el tráfico. Eliminar cualquier componente corre el riesgo de fusionar objetos que pueden tener diferentes propietarios, entradas o efectos operativos.

La tupla es una identidad, no una descripción completa del comportamiento. No revela qué ruta candidata está activa, qué lista de segmentos se ha programado, si la topología utilizada para el cálculo está actualizada o si el reenvío coincide con la ruta elegida. Esos son registros relacionados. Tratar la tupla como prueba de todo el sistema colapsaría la identidad en el estado y el estado en el resultado.

La unicidad del alcance es importante aquí. La automatización no debe crear dos objetos de política indistinguibles en el mismo ámbito y luego depender de un desempate no documentado. También debe evitar asumir que un color tiene un significado idéntico en cada headend o en cada entorno administrativo. La identidad es útil porque sus partes son explícitas y porque su alcance puede registrarse. El RFC 9256 proporciona la arquitectura compartida; las implementaciones y los operadores aún deben preservar esa identidad con precisión a través de la configuración, distribución, selección y observación.

El headend convierte la identidad en responsabilidad local

El headend es más que una etiqueta en la clave de política. Marca el punto en el que una SR Policy se convierte en un objeto local accionable. Ese nodo mantiene la política, resuelve las rutas candidatas de acuerdo con la información disponible para él, instala listas de segmentos utilizables y dirige el tráfico calificado. Otros nodos pueden reenviar las instrucciones resultantes, pero no poseen por ello la misma decisión de política.

Esta responsabilidad local evita que la frase "la red tiene una política" se vuelva demasiado vaga para ser auditada. Dos headends pueden usar el mismo color y endpoint mientras tienen diferentes vistas de topología, reciben diferentes rutas candidatas, admiten diferentes límites de lista de segmentos o aplican diferentes controles de operador. Sus identidades de política siguen siendo distintas porque el headend es parte de la tupla. Por lo tanto, un sistema de automatización necesita preguntar no solo qué política se pretende, sino dónde se pretende que exista.

La distinción se traslada a la evidencia de reenvío. Un controlador puede informar que se entregó una política. El headend puede informar que un candidato se activó. El plano de reenvío puede mostrar una lista de segmentos programada. La observación del tráfico puede mostrar si los paquetes realmente la siguieron. Estas son piezas sucesivas de evidencia, no confirmaciones intercambiables. Al poner el headend en la identidad, el RFC 9256 da a los operadores un punto estable alrededor del cual correlacionarlas sin atribuir autoridad global a un solo registro.

El color crea una asociación, no una instrucción universal

El color es a menudo la parte más tentadora de la tupla para sobreinterpretar. Puede asociar una ruta o clase de tráfico con una característica de política prevista, pero el valor numérico no conlleva un significado universal en lenguaje natural por sí mismo. Su significado operativo proviene de la política y el contexto administrativo en el que se utiliza. La interpretación de un entorno no puede importarse de forma segura a otro solo porque el número coincida.

Eso convierte al color en una superficie de gobernanza. Los operadores necesitan un registro de qué valores están en uso, dónde son significativos, qué políticas seleccionan, quién puede cambiar la asignación y cómo se propaga una asignación cambiada. El registro debe hacer visibles las colisiones y las asociaciones obsoletas. Un valor que es único pero está mal asignado no es seguro; un valor que es preciso pero tiene un alcance ambiguo no es suficiente.

La automatización debe, por lo tanto, tratar el color como una entrada a una decisión, no como una orden que anula toda otra evidencia. Si la política está ausente, inactiva o es incompatible con el estado actual, un sistema responsable necesita una respuesta acotada: rechazar la acción de dirección, usar una alternativa deliberadamente definida o generar una excepción visible. Interpretar silenciosamente el color como "hacer algo lo suficientemente cercano" destruiría la asociación precisa que la tupla fue diseñada para proporcionar.

El endpoint ancla la intención a un destino de reenvío

El componente endpoint da a la SR Policy un contexto de destino. Un color sin un endpoint puede expresar un objetivo amplio, pero no identifica el destino hacia el cual un headend debe construir o seleccionar la política. El endpoint cierra esa brecha. Juntos, headend, color y endpoint identifican dónde comienza la política, qué asociación representa y hacia dónde se dirige.

Un endpoint sigue siendo un valor del plano de control, no una prueba de alcanzabilidad. La topología relevante puede cambiar. Una ruta candidata puede volverse inválida. Una lista de segmentos puede ya no resolverse según lo previsto. Una implementación puede ser incapaz de programar las instrucciones seleccionadas. El endpoint sigue siendo parte de la identidad de la política a través de esas condiciones, mientras que el estado operativo de la política cambia a su alrededor.

Esta persistencia es útil para la semántica de cambios registrada. Un operador puede distinguir "la misma política se volvió inactiva" de "una política diferente la reemplazó". La automatización puede preservar un historial de eventos vinculado a la tupla: creación, adición de candidatos, cambio de preferencia, transición de ruta activa, retirada y recuperación. Sin una identidad estable, esos eventos pueden confundirse con instantáneas no relacionadas, lo que dificulta establecer la continuidad.

Las rutas candidatas hacen explícitas las alternativas

Una SR Policy puede tener múltiples rutas candidatas. Ese diseño convierte las alternativas en objetos del plano de control con nombre en lugar de enterrarlas en un cálculo opaco. Dentro de la arquitectura, una ruta candidata lleva su propia identidad a través del origen del protocolo, el originador y el discriminador. Esos elementos preservan de dónde vino el candidato y lo distinguen de otros candidatos asociados con la misma política.

La procedencia importa porque las alternativas pueden llegar a través de diferentes mecanismos o propietarios de decisiones. Un candidato configurado localmente y un candidato suministrado por otro componente de control pueden describir rutas hacia el mismo endpoint, pero no son operativamente idénticos. Pueden tener diferente autoridad, tiempo de actualización, restricciones y comportamiento de reversión. Si la automatización elimina su origen y conserva solo la lista de segmentos resultante, pierde la evidencia necesaria para explicar una selección o retirada posterior.

Una ruta candidata puede conducir a una o más listas de segmentos que expresan instrucciones de reenvío utilizables. La arquitectura separa el candidato del resultado activo porque un candidato puede existir sin ser utilizable en un momento dado. La resolución puede depender de la información actual y del comportamiento admitido. Las listas de segmentos también pueden llevar una ponderación dentro del tratamiento de reenvío del candidato, pero un peso configurado o anunciado sigue siendo una instrucción para una implementación, no una medición de la distribución de tráfico que ocurrió.

Las reglas de selección convierten las alternativas en estado activo

Las rutas candidatas necesitan una relación determinista con el estado activo de la política. El RFC 9256 utiliza la preferencia y la validez para estructurar esa relación: un candidato elegible debe ser utilizable, y la preferencia determina qué alternativa válida se selecciona. El punto operativo crucial no es solo la existencia de un número de preferencia. Es la cadena registrada desde la identidad del candidato, pasando por la validez, hasta la ruta que el headend realmente hizo activa.

La validez depende del tiempo. Un candidato que se resolvió ayer puede fallar hoy porque sus entradas cambiaron. Una lista de segmentos puede volverse indisponible, una capacidad requerida puede ya no ser visible o la topología utilizada para derivar la ruta puede haber sido reemplazada. La tupla de política puede permanecer constante mientras el candidato seleccionado cambia. La automatización debe preservar tanto la identidad estable como la transición de estado, incluida la razón por la que el antiguo candidato activo dejó de calificar.

La preferencia no debe confundirse con la calidad observada. Un candidato de mayor preferencia representa un orden configurado o señalizado. No prueba menor retraso, mayor capacidad, seguridad mejorada o cualquier resultado medido. Esas propiedades requieren evidencia separada y, cuando sea relevante, observación actual. El mecanismo de selección responde "qué candidato válido debe estar activo bajo estas reglas", no "qué ruta es objetivamente mejor en todas las dimensiones".

El caso de ningún candidato válido es especialmente importante. Una implementación no debe ocultarlo detrás de la existencia continua del objeto de política. Una política puede ser conocida pero inactiva. Ese estado debe ser visible para la lógica de dirección, la monitorización y el control de cambios. Un fallback acotado puede ser definido deliberadamente por el operador, pero no debe ser inventado implícitamente por una capa de automatización. La inactividad explícita es más segura que una equivalencia adivinada porque preserva la diferencia entre una ruta prevista y una disponible.

La dirección sigue siendo una decisión operativa separada

La selección de política y la dirección del tráfico están relacionadas pero son distintas. La lógica de ruta candidata determina el tratamiento de reenvío activo para una SR Policy identificada. La dirección determina qué tráfico se coloca en esa política. Una política activa válida puede existir sin recibir un flujo de tráfico particular, y una asociación de dirección puede existir mientras su política prevista está inactiva. Combinar ambas en un solo indicador verde oculta estados de falla importantes.

La dirección también pertenece a la política del operador más que al estándar solo. El RFC 9256 proporciona mecanismos y reglas arquitectónicas, pero un operador decide qué tráfico debe usar qué política y qué debe suceder si la política no está disponible. Un fallback al reenvío ordinario basado en destino, una retención u otra ruta acotada puede ser apropiado en diferentes contextos. El requisito importante es que la elección sea deliberada y observable.

Aquí es donde los eslóganes sobre "redes basadas en intención" pueden superar a la evidencia. La intención se vuelve operativa solo a través de objetos identificados, estado candidato actual, dirección explícita, soporte de implementación y reenvío observado. El trabajo atribuido a Talaulikar sobre la arquitectura de políticas es útil precisamente porque expone esos contratos intermedios. No promete que los contratos se cumplan siempre; da a los sistemas independientes una forma común de representarlos e inspeccionarlos.

El RFC 9552 hace que la topología sea consumible como registros

El RFC 9552 aborda un problema diferente pero conectado: distribuir información de estado de enlace e ingeniería de tráfico a través de BGP-LS para que las aplicaciones externas puedan consumir una vista de topología. BGP-LS no reemplaza el protocolo de estado de enlace subyacente, elige una SR Policy ni reenvía paquetes. Transporta registros derivados de la información de enrutamiento a través de una interfaz definida.

Esa distinción importa para la automatización. Un componente de cálculo de ruta puede necesitar una vista de nodos, enlaces y prefijos más allá de un solo dispositivo. BGP-LS proporciona una representación estandarizada a través de información de alcanzabilidad de capa de red y atributos asociados. La representación permite a una aplicación distinguir objetos de topología e interpretar sus propiedades sin tener que raspar salidas de dispositivos no relacionadas o asumir el formato privado de un proveedor.

La base de datos resultante es una vista derivada. Depende de la información recopilada por el sistema originador, la codificación de esa información, la distribución BGP, el comportamiento de selección y el procesamiento del consumidor. Un registro BGP-LS puede estar correctamente codificado pero obsoleto en relación con un evento de topología reciente. Puede estar actual pero incompleto para las restricciones de una aplicación. Puede describir el conocimiento del plano de control sin probar que las tablas de reenvío coincidan con él.

Los descriptores dan a los objetos de topología identidades estables

Una aplicación de topología no puede razonar de manera segura sobre "un enlace" o "un nodo" en abstracto. Necesita suficientes descriptores para identificar el objeto específico dentro del contexto de enrutamiento relevante. El RFC 9552 organiza los registros BGP-LS en torno a esa necesidad. Los descriptores de nodo identifican un nodo en su contexto de protocolo y dominio. Los registros de enlace relacionan las descripciones de nodo local y remoto con descriptores específicos del enlace. Los registros de prefijo adjuntan información de alcanzabilidad al contexto originador apropiado.

Los descriptores hacen más que hacer un registro legible. Determinan si dos anuncios se refieren al mismo objeto de topología o a objetos diferentes. Si una implementación omite una parte requerida de la identidad, los registros pueden colisionar. Si agrega un valor inestable a la identidad, un objeto puede aparecer como una corriente de objetos no relacionados. Cualquier falla puede engañar a un consumidor antes de que comience cualquier cálculo de ruta.

El alcance de los identificadores es central. Un número de sistema autónomo, un identificador de protocolo, un identificador de dominio de enrutamiento, un identificador de nodo, una dirección de interfaz o un prefijo tienen significado dentro de límites particulares. Ningún campo por sí solo identifica necesariamente todo el objeto de forma global. La descripción compuesta proporciona el contexto necesario. La automatización debe retener ese contexto en lugar de aplanar cada nodo o enlace en una etiqueta conveniente que puede no ser única.

Los registros precisos también necesitan semántica de cambios. Un enlace retirado no es lo mismo que un enlace cuyos atributos cambiaron. Un nodo visto a través de un contexto de enrutamiento diferente no es automáticamente un duplicado. Una actualización de prefijo debe permanecer adjunta a sus descriptores originadores. Los consumidores deben poder explicar si un objeto fue añadido, modificado, reemplazado o eliminado. La identidad estable más las transiciones registradas convierte una alimentación de topología en una entrada auditable en lugar de una secuencia de instantáneas desconectadas.

El orden es una regla de interoperabilidad, no un formato cosmético

El RFC 9552 hace que el orden sea parte del contrato de registro. Los elementos descriptores tienen una disposición definida, y el orden canónico evita que información equivalente sea serializada como objetos aparentemente diferentes solo porque los campos llegaron en una secuencia diferente. Esto es especialmente importante cuando la información de alcanzabilidad de capa de red codificada participa en la identidad y comparación de rutas.

Sin un orden canónico, dos hablantes podrían describir el mismo nodo, enlace o prefijo con los mismos valores de descriptor pero producir secuencias de bytes diferentes. Un sistema receptor podría retener ambos como rutas distintas, alternar entre ellas o forzar a un consumidor a adivinar si son duplicados. La topología subyacente no habría cambiado, pero la representación podría fabricar agitación. El orden elimina un grado de libertad que no tiene valor operativo.

La regla aún no garantiza la corrección semántica. Un registro perfectamente ordenado puede contener el identificador incorrecto o información de topología antigua. Por el contrario, un analizador que detecta una entrada no canónica debe manejarla dentro de los límites de compatibilidad y error del estándar en lugar de bendecir silenciosamente cada permutación. El orden proporciona una sintaxis determinista. La precisión depende de la fuente y del estado actual del plano de control, mientras que la utilidad depende de la interpretación del consumidor y de la evidencia de reenvío contra la cual se verifican sus decisiones.

La compatibilidad tiene que ser útil y acotada

Los estándares de enrutamiento evolucionan en redes donde las implementaciones no cambian todas a la vez. El RFC 9552, por lo tanto, tiene que abordar la compatibilidad con el comportamiento anterior de BGP-LS mientras ajusta el contrato de registro actual. La compatibilidad es valiosa cuando permite una transición controlada entre representaciones conocidas. Se vuelve peligrosa cuando se interpreta como permiso para aceptar cualquier codificación ambigua y adivinar el objeto de topología previsto.

Un enfoque acotado comienza por separar la variación histórica reconocida de los datos malformados o semánticamente conflictivos. Un receptor puede documentar qué formas acepta, cómo las normaliza y qué información puede perderse. Debe retener el origen del registro y exponer cuándo se invocó el manejo de compatibilidad. Un consumidor no debe ver un objeto normalizado como si hubiera llegado en la forma canónica actual cuando esa diferencia podría afectar la confianza.

Nada de esto significa que un RFC dicte el plan de actualización de un producto particular. El estándar define un comportamiento interoperable y límites. Las implementaciones eligen diagnósticos concretos y soporte de versiones. Los operadores deciden la secuencia de despliegue y la tolerancia al riesgo. Los registros BGP-LS actuales muestran lo que se recibió, y el comportamiento descendente muestra cómo actuaron los consumidores. Mantener esas capas separadas permite que la compatibilidad preserve la continuidad sin permitir que la ambigüedad de ayer se convierta en la fuente permanente de error de topología de mañana.

El manejo de errores convierte la entrada incorrecta en estado observable

La automatización de topología está expuesta a entradas que pueden ser incompletas, malformadas, inconsistentes, no admitidas u obsoletas. Los límites de manejo de errores del RFC 9552 importan porque un consumidor de topología no debe convertir silenciosamente una entrada inutilizable en estado autoritativo. Una longitud de descriptor malformada, un contexto de identidad faltante, una descripción conflictiva o un elemento no admitido no es equivalente a un registro de topología actual y saludable.

La respuesta precisa del protocolo depende de la clase de error y de los procedimientos BGP aplicables, mientras que la respuesta operativa visible también depende de la implementación. Esa es otra razón para no colapsar un estándar en una afirmación de producto. El estándar puede definir cuándo la información no puede procesarse de manera segura. Una implementación debe aplicar esa regla y exponer diagnósticos útiles. Un operador debe decidir si la pérdida de un registro invalida un cálculo o desencadena una alternativa acotada.

La observabilidad debe preservar varios hechos: qué par u origen suministró el registro, qué objeto de topología fue afectado, si la ruta fue rechazada o retirada, si solo un atributo era inutilizable, cuándo ocurrió el evento y qué aplicaciones consumieron la versión anterior. Un contador genérico de "error BGP-LS" rara vez es suficiente para determinar el impacto. La identidad del objeto y la transición de estado son parte de la evidencia.

El RFC 9513 expone localizadores y capacidades SRv6 a través de OSPFv3

El RFC 9513 devuelve el análisis al dominio de enrutamiento originador. Define extensiones OSPFv3 para SRv6, incluida la publicidad de información sobre capacidades y localizadores SRv6. El propósito es la visibilidad: los sistemas de enrutamiento necesitan registros de protocolo que digan qué funciones SRv6 relevantes o información de localizador pone a disposición un nodo dentro del contexto OSPFv3.

Un localizador proporciona estructura de enrutamiento para los identificadores SRv6. Anunciar información de localizador permite a otros componentes de enrutamiento construir una vista actual de dónde es alcanzable esa estructura y cómo se relaciona con el sistema anunciante. La información de capacidad dice a los pares y consumidores que se representa como admitido un comportamiento particular relacionado con SRv6. Juntos, estos registros pueden convertirse en entradas para el cálculo, la validación y la resolución de políticas.

Los anuncios siguen siendo información de estado de enlace con alcance. Se originan, inundan, instalan, actualizan y retiran de acuerdo con los mecanismos y límites del protocolo de enrutamiento. La automatización debe saber qué enrutador anunciante y contexto de área suministró un registro, cuándo entró en la base de datos y si una instancia más reciente lo reemplazó. Un inventario copiado desvinculado de ese contexto es una evidencia más débil que el registro de estado de enlace actual.

La visibilidad del localizador es necesaria pero no es prueba de reenvío

Un anuncio de localizador SRv6 puede decir a un sistema de enrutamiento que un localizador está presente en la vista de protocolo actual. No puede por sí mismo probar que todo comportamiento asociado está programado, que un paquete puede recorrer la ruta prevista completa o que una SR Policy que utiliza la información está activa. La visibilidad es un prerrequisito para un control informado, no un sustituto de la evidencia de ejecución.

La misma precaución se aplica a las capacidades. Un anuncio de capacidad representa un estado de protocolo suministrado por un nodo. No mide la capacidad, valida cada opción ni certifica todas las combinaciones con implementaciones vecinas. Los operadores necesitan comparar la capacidad anunciada con la intención configurada, el soporte de implementación, la programación de reenvío y la observación controlada. Las discrepancias deben ser visibles en lugar de resolverse mediante suposiciones optimistas.

La obsolescencia es un límite importante. Si un localizador o capacidad se retira o se reemplaza, un cálculo de política basado en el registro anterior puede ya no ser seguro. Los consumidores necesitan un manejo de actualización y retirada que alcance los cálculos en caché y la validez de la ruta candidata. No basta con actualizar la base de datos de topología mientras se dejan las rutas previamente derivadas sin revisión.