Resumo

  • A RFC 9617 padroniza, em YANG, a intenção de habilitar IOAM e de ligar perfis a filtros, protocolos e tipos de dados; ela não produz um veredito sobre o que ocorreu com um pacote.
  • Entre a configuração e a evidência ficam a seleção pelo ACE, a ação accept, a inserção do cabeçalho, a participação de cada nó, os limites de espaço, a exportação e a custódia no coletor.
  • Operação confiável exige recibos separados de estado ativo, correspondência do tráfego, execução, contribuição por nó, continuidade de exportação, análise, autorização, instalação da mudança e resultado de serviço.

Uma tela verde não testemunha um pacote

O controlador leu o datastore ativo. admin-config/enabled estava verdadeiro, o perfil existia e o filtro apontava para o ACE esperado. O protocolo indicava IPv6 e o subperfil de rastreamento enumerava os campos desejados. Para o painel de configuração, todos os objetos necessários estavam presentes.

Depois, um pacote percorreu a rede sem gerar o registro esperado. A mesma tela não dizia se ele havia correspondido ao ACE, se uma regra anterior o capturara, se a ação de encaminhamento era accept, se o nó de entrada inserira a opção, se havia espaço para todos os dados, se um equipamento intermediário apoiava aquela função ou se a exportação se perdera antes do coletor.

É justamente aí que a precisão da RFC 9617 precisa ser preservada. O modelo torna a intenção administrável e interoperável. Convertê-lo em testemunho retrospectivo retiraria a precisão que lhe dá valor. Configuração e observação são duas camadas de realidade, e a ligação entre elas deve ser demonstrada.

O que a árvore YANG realmente controla

O módulo ietf-ioam segue a Network Management Datastore Architecture. Ele expõe informações operacionais somente de leitura, uma habilitação administrativa e uma lista de perfis. Um perfil pode indicar filtro, protocolo portador e subperfis para rastreamento incremental, rastreamento pré-alocado, exportação direta, Proof of Transit ou dados Edge-to-Edge.

Esse desenho elimina gramáticas proprietárias para atos básicos de configuração. Tipos importados de ACL, interface e tempo restringem valores. Declarações de feature informam ao cliente quais ramos opcionais a implementação anuncia. A referência a uma interface pode ser validada como referência, não tratada como texto livre.

Mesmo assim, conformidade com o esquema não é captura de tráfego. Feature anunciada não é contribuição de cada nó. Leitura do datastore não é prova de que o valor estava vigente no instante do pacote. A árvore é o plano de controle de um mecanismo de observação; ela não é o histórico produzido por esse mecanismo.

enabled=true abre uma possibilidade, não encerra uma investigação

A habilitação administrativa torna disponíveis a configuração e as funções de plano de dados de IOAM no sistema. Ela é necessária para que os perfis operem, mas não afirma que todos os pacotes, nem sequer um pacote específico, tenham levado dados IOAM.

Filtros, protocolo, interfaces, suporte local e papel de cada nó continuam delimitando o alcance. O valor se parece mais com uma instalação energizada do que com um recibo de acionamento: informa que uma capacidade pôde ser usada, não qual evento a usou nem qual consequência se seguiu.

Também há uma questão de tempo. Uma leitura feita agora não prova o estado de horas atrás. Para associar configuração a tráfego histórico, o operador precisa preservar revisões ou épocas de configuração e registrar quando cada uma se tornou efetiva. Sem essa junção temporal, verdade atual não pode substituir verdade passada.

O ACE é a dobradiça entre política e execução

A RFC 9617 permite que o perfil se refira a uma entrada de controle de acesso e determina que as ações IOAM sejam provocadas por pacotes aceitos quando a ação de encaminhamento do ACE correspondente é accept. Essa condição é mais forte do que uma simples referência nominal.

Listas têm ordem, escopo de interface, direção, família de endereços e detalhes de implementação. Uma regra anterior pode corresponder primeiro. O pacote pode nem alcançar a ACL imaginada. Um ACE que parece adequado em revisão offline pode estar inativo, ter outra ação ou pertencer a uma revisão diferente da que processou o tráfego.

Um recibo de seleção deve guardar a identidade do pacote ou fluxo, o identificador do ACE efetivamente correspondente, a revisão da ACL, interface, direção, resultado e ação. “O perfil aponta para ACE-7” documenta intenção. “Este pacote correspondeu a ACE-7 na revisão X, foi aceito e acionou IOAM” documenta execução.

O protocolo configura o envelope, não prova que ele existiu

protocol-type informa onde os dados IOAM devem ser transportados, como IPv6 ou Network Service Header. O campo permite que um perfil comum escolha as regras de encapsulamento apropriadas.

Um valor armazenado de IPv6, porém, não mostra o cabeçalho real de um pacote nomeado. O tráfego pode ter entrado por outro ponto, adquirido um novo envelope em um túnel, excedido uma política de tamanho ou encontrado um nó que não reconhecia a opção. Nenhum desses acontecimentos altera retroativamente a validade da configuração.

O recibo de entrada precisa ligar a identidade original do pacote ao perfil correspondente e registrar ação de encapsulamento, tipo e tamanho da opção resultante, namespace, bitmap de trace-type e um correlator estável quando disponível. Sem esse recibo, o perfil descreve um caminho para obter evidência, não a evidência obtida.

Recursos suportados ainda permitem rastros incompletos

Os subperfis incremental e pré-alocado escolhem ação do nó, namespace, tipos de rastreamento e comprimento máximo. A forma de reservar espaço difere, mas ambas dependem de nós reais contribuindo com os dados solicitados.

O suporte anunciado é local. Um equipamento pode implementar o rastreamento incremental e outro não. Um campo pode ser tecnicamente suportado mas indisponível naquele instante. No modo pré-alocado, o espaço finito limita quantas entradas cabem. Portanto, um registro com quatro contribuições não prova, só pelo comprimento, que o caminho teve quatro nós.

A ausência de um nó admite várias hipóteses: ele não estava no caminho, não participou, não tinha suporte, encontrou o espaço esgotado, removeu ou ignorou a opção, ou seu registro se perdeu ou não foi decodificado. Operação honesta mantém essas hipóteses abertas até que recibos adicionais as separem.

A exportação direta abre uma segunda cadeia de custódia

O perfil de Direct Export pode usar um flow ID e habilitar números de sequência. O primeiro ajuda a correlacionar registros, e o segundo torna certas lacunas visíveis. São mecanismos úteis, mas não garantias de totalidade.

O coletor pode começar depois dos primeiros envios, deixando um prefixo perdido sem lacuna interna. Reinício e rollover exigem uma época. Vários exportadores podem manter espaços de sequência locais. O registro pode ser criado e descartado antes da transmissão ou recebido e rejeitado pelo decodificador. Flow ID é correlator dentro de um escopo definido, não identidade universal do fluxo.

Por isso o recibo de exportação inclui identidade do exportador, época de boot ou configuração, escopo do flow ID, regra de sequência, horário de envio, resultado do transporte, horário de recepção, decodificação e retenção. Só então um número ausente sustenta uma inferência limitada sobre perda.

O nome Proof of Transit não cria a prova

O modelo contém um perfil Proof of Transit, mas a RFC 9617 fornece um tipo-base e prevê aumentos para variantes específicas. A existência do ramo na configuração não cria prova criptográfica nem demonstra que um verificador tenha aceitado uma sequência concreta.

De modo semelhante, o perfil Edge-to-Edge define dados inseridos no encapsulamento e interpretados no desencapsulamento. Sua presença não prova que as duas pontas processaram o mesmo pacote, que o conteúdo permaneceu íntegro ou que o serviço entre elas atingiu o resultado esperado.

Essa fronteira também impede confusão com a questão de integridade IOAM já tratada em outra análise. Um verificador pode dizer se campos protegidos foram alterados sob seu método declarado. A RFC 9617 diz como configurar o comportamento. Nenhuma resposta, isoladamente, demonstra a cadeia inteira da outra.

Uma escada de recibos que possa falhar com clareza

O primeiro degrau registra configuração ativa: revisão do módulo, datastore, features, interface, perfil, referência de ACL, protocolo e campos de subperfil. O segundo prova seleção: o pacote encontrou o ACE desejado e foi aceito. O terceiro prova execução: a entrada inseriu a opção configurada ou acionou a exportação direta.

Depois vêm as observações: cada nó participante escreveu o campo esperado sob o namespace correto; limites, truncamento e funções sem suporte ficaram explícitos; exportador e coletor preservaram escopo, sequência, decodificação e retenção. A análise transforma esses dados em hipótese ou decisão. Uma autoridade distinta aprova eventual ação. Instalação e efeito de serviço ainda precisam de recibos próprios.

Nenhum estado verde deveria falar em nome dessa escada. A contribuição da RFC 9617 é tornar o primeiro degrau comum entre implementações. A verdade operacional surge quando os degraus seguintes permanecem distinguíveis e auditáveis.

Fontes