Ketan Talaulikar e o Contrato Operacional por Trás da Política de Roteamento de Segmentos

Sumário

• O papel documentado de Ketan Talaulikar no trabalho colaborativo da IETF fornece uma via de nível pessoal para três temas operacionais conectados: a identidade e as regras de caminho candidato de uma Política de Roteamento de Segmentos (SR Policy) na RFC 9256, os limites de descritor e erro dos registros de topologia BGP-LS na RFC 9552 e a visibilidade OSPFv3 de localizadores e capacidades SRv6 na RFC 9513.
• As especificações definem diferentes tipos de evidência. Uma tupla de política identifica uma política pretendida em um headend; o estado de caminho candidato registra alternativas utilizáveis; o BGP-LS descreve objetos de topologia para consumidores; e o OSPFv3 expõe informações de roteamento sobre SRv6. Nenhum desses registros, por si só, prova o caminho do pacote que uma implementação em execução produziu.
• O contrato operacional é, portanto, em camadas: os padrões definem a semântica, as implementações as realizam, os operadores escolhem políticas, os planos de controle publicam registros atuais e as observações de encaminhamento mostram resultados. A automação confiável mantém essas camadas vinculadas sem fingir que qualquer uma delas é a rede inteira.

Um registro de nível pessoal organizado em torno do significado operacional

O perfil no IETF Datatracker de Ketan Talaulikar registra liderança na área de roteamento e trabalho contínuo em protocolos de roteamento. Os três padrões examinados aqui o listam em papéis editoriais, criando uma conexão clara de nível pessoal com seus temas técnicos. A RFC 9256 define a arquitetura da Política de Roteamento de Segmentos. A RFC 9552 define como o BGP-LS distribui informações de estado de enlace e de engenharia de tráfego. A RFC 9513 define extensões do OSPFv3 que tornam as informações de localizador e capacidades SRv6 visíveis no sistema de roteamento.

Essa atribuição requer limites cuidadosos. Cada RFC é um trabalho colaborativo da IETF moldado por vários autores ou editores, discussão do grupo de trabalho, revisão, experiência de implementação e o processo de padronização. O registro apoia o crédito pela participação documentada de Talaulikar. Ele não apoia a alegação de que ele sozinho inventou os mecanismos, selecionou a política de um operador, escreveu uma implementação específica ou controlou uma implantação. Também não fornece base para alegações sobre clientes, incidentes, resultados comerciais ou melhorias medidas.

Esta é uma história operacional, não uma biografia heroica. A automação pode agir com segurança apenas quando consegue distinguir em qual objeto está atuando, qual registro é atual, quais alternativas são válidas e o que aconteceu quando a entrada não pôde ser usada. O registro de padrões atribuído a Talaulikar é significativo aqui porque conecta política, topologia e capacidade nos pontos onde a intenção abstrata deve se tornar estado de protocolo.

Cinco camadas que não devem ser colapsadas

A primeira camada é o padrão. Um padrão define semântica compartilhada: como uma Política de Roteamento de Segmentos é identificada, como os caminhos candidatos se relacionam com ela, como os registros BGP-LS descrevem a topologia ou como o OSPFv3 transporta informações SRv6. Ele fornece um contrato entre implementações independentes. Ele não instancia uma política em uma rede específica, não escolhe um objetivo de negócio e não informa se um pacote chegou.

A segunda camada é a implementação. O software transforma a especificação em analisadores sintáticos, estruturas de dados, lógica de seleção, interfaces de programação e saída operacional. Uma implementação pode estar em conformidade com um padrão e ainda diferir em opções suportadas, capacidade, diagnóstico, comportamento de versão e defeitos. A existência de uma RFC não pode provar que uma determinada compilação de software suporta todos os mecanismos ou lida corretamente com todos os limites.

A terceira camada é a política do operador. Os operadores decidem quais cores têm significado em seu ambiente, quais endpoints são importantes, quais caminhos candidatos devem existir, quais preferências devem ser aplicadas, quais consumidores de topologia podem agir e como as falhas devem ser contidas. Essas decisões não são fornecidas pelo padrão. São escolhas de governança local expressas por meio de configuração e automação.

A quarta camada é o estado atual do plano de controle. Isso inclui a Política de Roteamento de Segmentos e os caminhos candidatos atualmente conhecidos em um headend, os registros BGP-LS atualmente disponíveis para um consumidor e os anúncios OSPFv3 atualmente instalados na base de dados de estado de enlace. Esses registros são sensíveis ao tempo. Um identificador corretamente definido anexado a um estado obsoleto ainda pode levar a automação na direção errada.

A quinta camada é o encaminhamento observado. É a evidência do que o sistema em execução fez: quais próximos saltos e instruções de segmento foram programados, quais pacotes seguiram qual caminho e como o comportamento mudou após uma atualização ou erro. A observação de encaminhamento não substitui padrões ou registros; ela testa se a cadeia pretendida alcançou a execução. Um sistema confiável preserva a distinção entre todas as cinco camadas, mantendo correlação suficiente para passar de uma para a próxima.

A RFC 9256 começa com uma identidade de política em três partes

A RFC 9256 identifica uma Política de Roteamento de Segmentos por meio de uma tupla composta pelo headend, cor e endpoint. A compactação dessa tupla é importante. Ela transforma uma frase como "use o caminho de baixa latência" em um objeto cujo escopo pode ser determinado. A política não é meramente uma propriedade desejada. É uma política em um headend específico, associada a uma cor específica, em direção a um endpoint específico.

Cada componente previne um tipo diferente de ambiguidade. O headend identifica onde a política é instanciada e onde ocorre o direcionamento para ela. A cor fornece uma associação entre informações de tráfego ou roteamento e um objetivo de política dentro de um contexto acordado. O endpoint ancora a política ao destino para o qual a lista de segmentos se destina a transportar o tráfego. Remover qualquer componente arrisca mesclar objetos que podem ter diferentes proprietários, entradas ou efeitos operacionais.

A tupla é uma identidade, não uma descrição completa do comportamento. Ela não revela qual caminho candidato está ativo, qual lista de segmentos foi programada, se a topologia usada para cálculo está atualizada ou se o encaminhamento corresponde ao caminho escolhido. Esses são registros relacionados. Tratar a tupla como prova de todo o sistema colapsaria a identidade em estado e o estado em resultado.

A unicidade com escopo definido é importante aqui. A automação não deve criar dois objetos de política indistinguíveis no mesmo escopo e depois confiar em um desempate não documentado. Também deve evitar presumir que uma cor tem significado idêntico em cada headend ou em cada ambiente administrativo. A identidade é útil porque suas partes são explícitas e porque seu escopo pode ser registrado. A RFC 9256 fornece a arquitetura compartilhada; implementações e operadores ainda precisam preservar essa identidade com precisão por meio de configuração, distribuição, seleção e observação.

O headend transforma a identidade em responsabilidade local

O headend é mais do que um rótulo na chave da política. Ele marca o ponto em que uma Política de Roteamento de Segmentos se torna um objeto local acionável. Esse nó mantém a política, resolve caminhos candidatos de acordo com as informações disponíveis para ele, instala listas de segmentos utilizáveis e direciona o tráfego qualificado. Outros nós podem encaminhar as instruções resultantes, mas não detêm, com isso, a mesma decisão de política.

Essa responsabilidade local evita que a frase "a rede tem uma política" se torne vaga demais para auditoria. Dois headends podem usar a mesma cor e endpoint, mas possuir visões de topologia diferentes, receber caminhos candidatos diferentes, suportar limites de lista de segmentos diferentes ou aplicar controles de operador diferentes. Suas identidades de política permanecem distintas porque o headend faz parte da tupla. Portanto, um sistema de automação precisa perguntar não apenas qual política é pretendida, mas onde ela deve existir.

A distinção se estende à evidência de encaminhamento. Um controlador pode relatar que uma política foi entregue. O headend pode relatar que um caminho candidato se tornou ativo. O plano de encaminhamento pode mostrar uma lista de segmentos programada. A observação do tráfego pode mostrar se os pacotes realmente a seguiram. Essas são peças sucessivas de evidência, não confirmações intercambiáveis. Ao colocar o headend na identidade, a RFC 9256 fornece aos operadores um ponto estável em torno do qual correlacioná-las, sem atribuir autoridade global a um único registro.

A cor cria uma associação, não uma instrução universal

A cor é frequentemente a parte mais tentadora da tupla para ser superinterpretada. Ela pode associar uma rota ou classe de tráfego a uma característica de política pretendida, mas o valor numérico não carrega um significado universal em linguagem natural por si só. Seu significado operacional vem do contexto de política e administrativo no qual é usada. A interpretação de um ambiente não pode ser importada com segurança para outro apenas porque o número coincide.

Isso torna a cor uma superfície de governança. Os operadores precisam de um registro de quais valores estão em uso, onde são significativos, quais políticas selecionam, quem pode alterar o mapeamento e como um mapeamento alterado é propagado. O registro deve tornar colisões e associações obsoletas visíveis. Um valor que é único, mas mapeado incorretamente, não é seguro; um valor que é preciso, mas de escopo ambíguo, não é suficiente.

A automação deve, portanto, tratar a cor como uma entrada para uma decisão, não como uma ordem que anula todas as outras evidências. Se a política está ausente, inativa ou incompatível com o estado atual, um sistema responsável precisa de uma resposta limitada: recusar a ação de direcionamento, usar uma alternativa deliberadamente definida ou gerar uma exceção visível. Interpretar silenciosamente a cor como "faça algo próximo o suficiente" destruiria a associação precisa que a tupla foi projetada para fornecer.

O endpoint ancora a intenção em um destino de encaminhamento

O componente endpoint fornece à Política de Roteamento de Segmentos um contexto de destino. Uma cor sem um endpoint pode expressar um objetivo amplo, mas não identifica o destino para o qual um headend deve construir ou selecionar a política. O endpoint fecha essa lacuna. Juntos, headend, cor e endpoint identificam onde a política começa, qual associação ela representa e para onde é direcionada.

Um endpoint ainda é um valor do plano de controle, não uma prova de alcançabilidade. A topologia relevante pode mudar. Um caminho candidato pode se tornar inválido. Uma lista de segmentos pode não ser mais resolvida conforme o pretendido. Uma implementação pode ser incapaz de programar as instruções selecionadas. O endpoint permanece parte da identidade da política durante essas condições, enquanto o estado operacional da política muda ao seu redor.

Essa persistência é útil para a semântica de mudança registrada. Um operador pode distinguir "a mesma política tornou-se inativa" de "uma política diferente a substituiu". A automação pode preservar um histórico de eventos indexado à tupla: criação, adição de caminho candidato, alteração de preferência, transição de caminho ativo, retirada e recuperação. Sem uma identidade estável, esses eventos podem ser confundidos com instantâneos não relacionados, dificultando o estabelecimento de continuidade.

Caminhos candidatos tornam as alternativas explícitas

Uma Política de Roteamento de Segmentos pode ter vários caminhos candidatos. Esse design transforma alternativas em objetos nomeados do plano de controle, em vez de enterrá-las em um cálculo opaco. Dentro da arquitetura, um caminho candidato carrega sua própria identidade por meio de origem do protocolo, originador e discriminador. Esses elementos preservam de onde o candidato veio e o distinguem de outros candidatos associados à mesma política.

A proveniência é importante porque alternativas podem chegar por meio de diferentes mecanismos ou proprietários de decisão. Um candidato configurado localmente e um candidato fornecido por outro componente de controle podem descrever caminhos em direção ao mesmo endpoint, mas não são operacionalmente idênticos. Eles podem ter autoridade, timing de atualização, restrições e comportamento de reversão diferentes. Se a automação eliminar sua origem e mantiver apenas a lista de segmentos resultante, perderá a evidência necessária para explicar uma seleção ou retirada posterior.

Um caminho candidato pode levar a uma ou mais listas de segmentos que expressam instruções de encaminhamento utilizáveis. A arquitetura separa o candidato do resultado ativo porque um candidato pode existir sem ser utilizável em um determinado momento. A resolução pode depender de informações atuais e comportamento suportado. As listas de segmentos também podem carregar ponderação dentro do tratamento de encaminhamento do candidato, mas um peso configurado ou anunciado permanece como uma instrução para uma implementação, não uma medição da distribuição de tráfego que ocorreu.

As regras de seleção transformam alternativas em estado ativo

Os caminhos candidatos precisam de uma relação determinística com o estado ativo da política. A RFC 9256 usa preferência e validade para estruturar essa relação: um candidato elegível deve ser utilizável, e a preferência determina qual alternativa válida é selecionada. O ponto operacional crucial não é a existência de um número de preferência isolado. É a cadeia registrada desde a identidade do candidato, passando pela validade, até o caminho que o headend realmente tornou ativo.

A validade depende do tempo. Um candidato que se resolveu ontem pode falhar hoje porque suas entradas mudaram. Uma lista de segmentos pode se tornar indisponível, uma capacidade necessária pode não estar mais visível ou a topologia usada para derivar o caminho pode ter sido substituída. A tupla de política pode permanecer constante enquanto o candidato selecionado muda. A automação deve preservar tanto a identidade estável quanto a transição de estado, incluindo o motivo pelo qual o antigo candidato ativo deixou de se qualificar.

A preferência não deve ser confundida com qualidade observada. Um candidato de preferência mais alta representa uma ordenação configurada ou sinalizada. Isso não prova menor latência, maior capacidade, segurança aprimorada ou qualquer resultado medido. Essas propriedades exigem evidência separada e, quando relevante, observação atual. O mecanismo de seleção responde "qual candidato válido deve estar ativo sob essas regras", e não "qual caminho é objetivamente o melhor em todas as dimensões".

O caso de nenhum candidato válido é especialmente importante. Uma implementação não deve ocultá-lo por trás da existência continuada do objeto de política. Uma política pode ser conhecida, mas inativa. Esse estado precisa ser visível para a lógica de direcionamento, monitoramento e controle de mudanças. Um fallback limitado pode ser deliberadamente definido pelo operador, mas não deve ser inventado implicitamente por uma camada de automação. A inatividade explícita é mais segura do que uma equivalência presumida, porque preserva a diferença entre um caminho pretendido e um disponível.

O direcionamento permanece como uma decisão operacional separada

A seleção de política e o direcionamento de tráfego estão relacionados, mas são distintos. A lógica de caminho candidato determina o tratamento de encaminhamento ativo para uma Política de Roteamento de Segmentos identificada. O direcionamento determina qual tráfego é colocado nessa política. Uma política ativa e válida pode existir sem receber um fluxo de tráfego específico, e uma associação de direcionamento pode existir enquanto sua política pretendida está inativa. Combinar os dois em um único indicador verde oculta estados de falha importantes.

O direcionamento também pertence à política do operador, e não apenas ao padrão. A RFC 9256 fornece mecanismos e regras arquiteturais, mas um operador decide qual tráfego deve usar qual política e o que deve acontecer se a política estiver indisponível. Um fallback para encaminhamento baseado em destino comum, uma retenção ou outro caminho limitado pode ser apropriado em contextos diferentes. O requisito importante é que a escolha seja deliberada e observável.

É aqui que slogans sobre "rede baseada em intenção" podem ultrapassar a evidência. A intenção se torna operacional apenas por meio de objetos identificados, estado candidato atual, direcionamento explícito, suporte de implementação e encaminhamento observado. O trabalho atribuído a Talaulikar na arquitetura de política é útil precisamente porque expõe esses contratos intermediários. Ele não promete que os contratos sejam sempre satisfeitos; ele fornece a sistemas independentes uma maneira comum de representá-los e inspecioná-los.

A RFC 9552 torna a topologia consumível como registros

A RFC 9552 aborda um problema diferente, mas conectado: distribuir informações de estado de enlace e de engenharia de tráfego via BGP-LS para que aplicações externas possam consumir uma visão da topologia. O BGP-LS não substitui o protocolo de estado de enlace subjacente, não escolhe uma Política de Roteamento de Segmentos e não encaminha pacotes. Ele transporta registros derivados de informações de roteamento através de uma interface definida.

Essa distinção importa para a automação. Um componente de cálculo de caminho pode precisar de uma visão de nós, enlaces e prefixos além de um único dispositivo. O BGP-LS fornece uma representação padronizada por meio de informações de alcançabilidade de camada de rede e atributos associados. A representação permite que uma aplicação distinga objetos de topologia e interprete suas propriedades sem analisar saídas de dispositivos não relacionadas ou assumir um formato proprietário de um fornecedor.

O banco de dados resultante é uma visão derivada. Ele depende das informações coletadas pelo sistema de origem, da codificação dessas informações, da distribuição BGP, do comportamento de seleção e do processamento do consumidor. Um registro BGP-LS pode ser codificado corretamente, mas obsoleto em relação a um evento de topologia recente. Pode ser atual, mas incompleto para as restrições de uma aplicação. Pode descrever o conhecimento do plano de controle sem provar que as tabelas de encaminhamento correspondem a ele.

Os descritores dão aos objetos de topologia identidades estáveis

Uma aplicação de topologia não pode raciocinar com segurança sobre "um enlace" ou "um nó" de forma abstrata. Ela precisa de descritores suficientes para identificar o objeto específico dentro do contexto de roteamento relevante. A RFC 9552 organiza os registros BGP-LS em torno dessa necessidade. Descritores de nó identificam um nó em seu contexto de protocolo e domínio. Registros de enlace relacionam descrições de nós locais e remotos com descritores específicos de enlace. Registros de prefixo anexam informações de alcançabilidade ao contexto de origem apropriado.

Os descritores fazem mais do que tornar um registro legível. Eles determinam se dois anúncios se referem ao mesmo objeto de topologia ou a objetos diferentes. Se uma implementação omitir uma parte obrigatória da identidade, os registros podem colidir. Se adicionar um valor instável à identidade, um objeto pode aparecer como um fluxo de objetos não relacionados. Qualquer falha pode enganar um consumidor antes mesmo de qualquer cálculo de caminho começar.

O escopo dos identificadores é central. Um número de sistema autônomo, identificador de protocolo, identificador de domínio de roteamento, identificador de nó, endereço de interface ou prefixo tem significado dentro de fronteiras específicas. Nenhum campo isolado identifica necessariamente o objeto inteiro globalmente. A descrição composta fornece o contexto necessário. A automação deve reter esse contexto em vez de achatar cada nó ou enlace em um rótulo conveniente que pode não ser único.

Registros precisos também precisam de semântica de mudança. Um enlace retirado não é o mesmo que um enlace cujos atributos mudaram. Um nó visto através de um contexto de roteamento diferente não é automaticamente uma duplicata. Uma atualização de prefixo deve permanecer anexada aos seus descritores de origem. Os consumidores devem ser capazes de explicar se um objeto foi adicionado, modificado, substituído ou removido. Identidade estável mais transições registradas transformam um feed de topologia em uma entrada auditável, em vez de uma sequência de instantâneos desconectados.

A ordenação é uma regra de interoperabilidade, não formatação cosmética

A RFC 9552 torna a ordenação parte do contrato de registro. Os elementos descritores têm um arranjo definido, e a ordenação canônica impede que informações equivalentes sejam serializadas como objetos aparentemente diferentes apenas porque os campos chegaram em uma sequência diferente. Isso é especialmente importante quando as informações codificadas de alcançabilidade de camada de rede participam da identidade e comparação de rotas.

Sem a ordem canônica, dois falantes poderiam descrever o mesmo nó, enlace ou prefixo com os mesmos valores de descritor, mas produzir sequências de bytes diferentes. Um sistema receptor poderia reter ambos como rotas distintas, alternar entre eles ou forçar um consumidor a adivinhar se são duplicatas. A topologia subjacente não teria mudado, mas a representação poderia fabricar agitação. A ordenação remove um grau de liberdade que não tem valor operacional.

A regra ainda não garante correção semântica. Um registro perfeitamente ordenado pode conter o identificador errado ou informações de topologia antigas. Inversamente, um analisador que detecta entrada não canônica deve tratá-la dentro dos limites de compatibilidade e erro do padrão, em vez de abençoar silenciosamente cada permutação. A ordenação fornece sintaxe determinística. A precisão depende da origem e do estado atual do plano de controle, enquanto a utilidade depende da interpretação do consumidor e da evidência de encaminhamento contra a qual suas decisões são verificadas.

A compatibilidade precisa ser útil e limitada

Os padrões de roteamento evoluem em redes onde as implementações não mudam todas de uma vez. A RFC 9552, portanto, precisa abordar a compatibilidade com o comportamento anterior do BGP-LS enquanto restringe o contrato de registro atual. A compatibilidade é valiosa quando permite uma transição controlada entre representações conhecidas. Ela se torna perigosa quando é interpretada como permissão para aceitar qualquer codificação ambígua e adivinhar o objeto de topologia pretendido.

Uma abordagem limitada começa por separar a variação histórica reconhecida de dados malformados ou semanticamente conflitantes. Um receptor pode documentar quais formas aceita, como as normaliza e quais informações podem ser perdidas. Ele deve reter a origem do registro e expor quando o tratamento de compatibilidade foi invocado. Um consumidor não deve ver um objeto normalizado como se tivesse chegado na forma canônica atual quando essa diferença pudesse afetar a confiança.

Nada disso significa que uma RFC dita o plano de atualização de um produto específico. O padrão define comportamento e limites interoperáveis. As implementações escolhem diagnósticos concretos e suporte a versões. Os operadores decidem a sequência de implantação e a tolerância ao risco. Os registros BGP-LS atuais mostram o que foi recebido, e o comportamento downstream mostra como os consumidores agiram. Manter essas camadas separadas permite que a compatibilidade preserve a continuidade sem permitir que a ambiguidade de ontem se torne a fonte permanente de erro de topologia de amanhã.

O tratamento de erros converte entrada ruim em estado observável

A automação de topologia é exposta a entradas que podem ser incompletas, malformadas, inconsistentes, não suportadas ou obsoletas. Os limites de tratamento de erros da RFC 9552 são importantes porque um consumidor de topologia não deve transformar silenciosamente entradas inutilizáveis em estado autoritativo. Um comprimento de descritor malformado, contexto de identidade ausente, descrição conflitante ou elemento não suportado não é equivalente a um registro de topologia atual e saudável.

A resposta precisa do protocolo depende da classe de erro e dos procedimentos BGP aplicáveis, enquanto a resposta operacional visível também depende da implementação. Essa é outra razão para não colapsar um padrão em uma alegação de produto. O padrão pode definir quando as informações não podem ser processadas com segurança. Uma implementação deve aplicar essa regra e expor diagnósticos úteis. Um operador deve decidir se a perda de um registro invalida um cálculo ou aciona uma alternativa limitada.

A observabilidade deve preservar vários fatos: qual par ou origem forneceu o registro, qual objeto de topologia foi afetado, se a rota foi rejeitada ou retirada, se apenas um atributo era inutilizável, quando o evento ocorreu e quais aplicações consumiram a versão anterior. Um contador genérico de "erro BGP-LS" raramente é suficiente para determinar o impacto. A identidade do objeto e a transição de estado são parte da evidência.

A RFC 9513 expõe localizadores e capacidades SRv6 através do OSPFv3

A RFC 9513 traz a análise de volta ao domínio de roteamento de origem. Ela define extensões do OSPFv3 para SRv6, incluindo o anúncio de informações sobre capacidades SRv6 e localizadores. O objetivo é a visibilidade: os sistemas de roteamento precisam de registros de protocolo que indiquem quais funções SRv6 ou informações de localizador relevantes um nó disponibiliza dentro do contexto OSPFv3.

Um localizador fornece estrutura de roteamento para identificadores SRv6. Anunciar informações de localizador permite que outros componentes de roteamento construam uma visão atual de onde essa estrutura é alcançável e como se relaciona com o sistema anunciante. As informações de capacidade informam aos pares e consumidores que determinado comportamento relacionado ao SRv6 é representado como suportado. Juntos, esses registros podem se tornar entradas para cálculo, validação e resolução de políticas.

Os anúncios permanecem como informações de estado de enlace com escopo definido. Eles são originados, inundados, instalados, atualizados e retirados de acordo com os mecanismos e limites do protocolo de roteamento. A automação deve saber qual roteador anunciante e contexto de área forneceram um registro, quando ele entrou na base de dados e se uma instância mais nova o substituiu. Um inventário copiado desvinculado desse contexto é evidência mais fraca do que o registro de estado de enlace atual.

A visibilidade do localizador é necessária, mas não é prova de encaminhamento

Um anúncio de localizador SRv6 pode informar a um sistema de roteamento que um localizador está presente na visão atual do protocolo. Ele não pode, por si só, provar que cada comportamento associado está programado, que um pacote pode atravessar o caminho pretendido completo ou que uma Política de Roteamento de Segmentos usando a informação está ativa. A visibilidade é um pré-requisito para o controle informado, não um substituto para a evidência de execução.

O mesmo cuidado se aplica às capacidades. Um anúncio de capacidade representa o estado de protocolo fornecido por um nó. Ele não mede a capacidade, valida todas as opções ou certifica todas as combinações com implementações vizinhas. Os operadores precisam comparar a capacidade anunciada com a intenção configurada, o suporte da implementação, a programação de encaminhamento e a observação controlada. As incompatibilidades devem ser visíveis em vez de resolvidas por meio de suposições otimistas.

A obsolescência é um limite importante. Se um localizador ou capacidade for retirado ou substituído, um cálculo de política baseado no registro mais antigo pode não ser mais seguro. Os consumidores precisam de tratamento de atualização e retirada que alcance cálculos em cache e a validade do caminho candidato. Não é suficiente atualizar a base de dados de topologia enquanto deixa os caminhos derivados anteriormente intocados sem revisão.