Resumo

  • RFC 9968 registra a discussão NEMOPS sobre ferramentas utilizáveis, modelos de serviço, verificação e automação. É um relatório Informational do IAB, não uma especificação de operação nem uma procuração para um controlador.
  • Um modelo pode organizar intenção; telemetria pode registrar observação; um adaptador pode converter formatos. Nenhum deles decide, por si só, escopo de cliente, prioridade de negócio, aceitação de risco ou responsabilidade por uma reversão.
  • A automação precisa preservar quatro registros distintos: compromisso de serviço, evidência observada, proposta delimitada e autorização local. Quando esses registros são confundidos, a plataforma passa a aparentar uma autoridade que nunca recebeu.

Coordenação não é transferência de decisão

RFC 9968 documenta o workshop da IAB sobre a próxima era das operações de gestão de rede. Em vez de anunciar que uma pilha venceu, o relatório descreve trabalho ainda pendente: ferramentas e documentação difíceis de usar, modelos fragmentados, cobertura incompleta de NETCONF e YANG em muitos dispositivos, persistência de SNMP e CLI, e a necessidade de representar serviços, não só caixas isoladas. Também aponta verificação, observabilidade, adaptadores e colaboração entre operadores e fornecedores como caminhos de melhoria.

Esse diagnóstico é importante porque uma rede real não se torna homogênea quando um inventário ganha um formato comum. Uma operadora pode usar modelos de fornecedor, modelos IETF, OpenConfig, scripts e interfaces legadas ao mesmo tempo. Uma camada externa pode traduzir uma intenção de serviço em configurações distintas. Isso pode ampliar a escolha e reduzir dependência de uma única interface. Mas a camada de tradução não passa a possuir o serviço apenas porque consegue descrevê-lo.

O próprio RFC delimita a prova disponível. Ele é Informational, não Standards Track; relata apresentações e notas de discussão sem interpretação ou validação; não afirma consenso salvo quando declarado; e não torna cada posição de participante uma posição do IAB. Logo, o documento registra requisitos e tensões relevantes. Não entrega um direito de alterar a rede de outro operador, nem faz de uma recomendação uma autorização sobre clientes ausentes.

RFC 3535, o relatório anterior que NEMOPS amplia sem substituir, já exigia separar dados de configuração, estado operacional e estatísticas. Pedia minimizar efeitos ao passar da configuração A para B, aplicar privilégio mínimo e distinguir distribuir uma configuração de ativá-la. A diferença é decisiva: a distribuição pode ser uma preparação técnica; a ativação é um ato que produz consequências em uma rede viva.

Quatro registros para não fabricar uma “fonte única”

O primeiro é o compromisso de serviço: disponibilidade, latência, entrega ao cliente, tráfego protegido, janela de manutenção ou meta de restauração. Ele precisa de um responsável pela promessa. Configuração de equipamento é uma forma possível de executar essa promessa, não a promessa inteira.

O segundo é a evidência observada: sondas, telemetria, logs, alarmes, contadores e vistas de rota. Toda evidência deve carregar origem, horário, cobertura, perdas e lacunas. Uma ausência de evento pode indicar estabilidade, mas também uma assinatura interrompida, um coletor falho, filtragem ou uma condição que o modelo não representa.

O terceiro é a proposta de mudança: o delta exato, dispositivos, serviços, clientes, dependências, janela, efeito esperado e retorno. Quando um adaptador converte modelo de serviço em configuração de fornecedor, guardar entrada, saída e versão do adaptador é indispensável. Sem isso, uma falha posterior não permite separar intenção errada, tradução errada e execução inesperada.

O quarto é a autorização: quem aprova qual raio de ação, com que evidência, até quando e quem pode pausar ou reverter. Não é defesa de um clique cerimonial por comando. É defesa de políticas automáticas com proprietário local, limites, expiração e revogação. Velocidade de execução não cria direito de impor efeito.

RFC 8342 separa, na arquitetura NMDA, configuração pretendida, aplicada e estado operacional. A divisão é técnica, não uma constituição de responsabilidade. Ela não prova que o estado aplicado cumpre um contrato nem que o controlador pode mudá-lo. Ajuda, porém, a impedir a pergunta errada: antes de concluir que algo é verdade sobre o serviço, perguntar que espécie de registro está sendo mostrada.

RFC 6241 define mecanismos NETCONF, incluindo superfícies de configuração candidata, em execução e confirmed commit; RFC 8040 define RESTCONF. Eles podem estruturar, autenticar e recuperar uma operação em seu escopo. Não sabem quem aceitará a degradação de um cliente de trânsito ou de uma aplicação crítica. Poder escrever uma configuração não é poder decidir sua consequência.

Mais sinais não significam prova completa

RFC 8639, RFC 8641 e RFC 9196 oferecem vocabulários para assinaturas, atualizações de datastore e capacidades. Eles tornam sinais estruturados disponíveis. Não garantem que todo estado relevante esteja modelado, que uma conversão seja sem perda, que a corrente não tenha lacunas ou que uma correlação prove causa.

O salto indevido é: “o modelo aceita; portanto o modelo manda; portanto a mudança foi autorizada”. A primeira frase pode ser testada. A segunda exige delegação local, contrato, obrigações aplicáveis e a identificação de quem arca com a perda. Uma árvore de dados não gera essa autorização.

As notas de Heng Lu sobre primazia do código em execução, especificação inicial mínima e decisão localizada e camadas de realidade oferecem um teste editorial: a superfície comum deve servir à adoção e à interoperabilidade, não absorver decisões futuras; o efeito da rede rodando é o teste; o registro simbólico não substitui o resultado operacional.

Testar a passagem de evidência para ação

O ensaio deve unir compromisso de serviço, versão do modelo, capacidade do equipamento, idade de sinal, lacuna de notificação, delta, autorização e sonda independente. Depois deve falhar de propósito: perder uma fonte de telemetria, atrasar evento, recusar uma folha do modelo, introduzir recurso sem suporte no adaptador, alterar por CLI fora de banda, reiniciar o controlador entre distribuição e ativação ou ampliar escopo após aprovação. Cada caso mostra uma razão diferente para a automação interromper-se e pedir revisão.

Sources