Resumo

  • O draft-ietf-nmop-simap-concept-13 organiza a navegação do serviço até seus suportes lógicos e físicos e o caminho inverso, do recurso aos serviços afetados.
  • A resposta registra o que um servidor expôs sob determinada autorização, abstração, fonte e época; completude, sincronização, causa, poder de decisão, execução e efeito precisam de provas próprias.

Uma equipe de operações seleciona um serviço e pede à ferramenta todos os recursos que o sustentam. O caminho passa por componentes do serviço, nós e enlaces lógicos, camadas inferiores e equipamentos físicos. Minutos depois, a equipe escolhe um recurso suspeito e percorre a mesma estrutura de baixo para cima, procurando todos os serviços que dependem dele. É exatamente esse tipo de navegação que torna uma Service & Infrastructure Map atraente.

O resultado, porém, não é um inventário juramentado da rede. Ele é a representação que um servidor SIMAP montou e decidiu expor àquele cliente. A visão pode estar abstraída, filtrada por autorização, alimentada por fontes externas em horários diferentes ou associada a uma topologia pretendida, passiva ou histórica.

O documento atual é a revisão 13 de draft-ietf-nmop-simap-concept, de 4 de setembro de 2026. O IETF Datatracker o classifica como Internet-Draft ativo do grupo NMOP, com status pretendido Informational. O histórico registra IETF Last Call até 26 de setembro. Portanto, não é um RFC final e ainda pode mudar.

O percurso do serviço ao equipamento

O núcleo conceitual usa redes, nós, enlaces e pontos de terminação. As relações de suporte ligam elementos dentro de uma camada ou entre camadas. No sentido descendente, o cliente começa no serviço, identifica os recursos lógicos usados e chega aos recursos físicos. No sentido ascendente, começa em um recurso físico, de camada 2 ou de camada 3 e encontra serviços, nós, enlaces e terminações que se apoiam nele.

RFC 8345 já define, em YANG, redes, nós, enlaces e pontos de terminação de suporte. O conceito SIMAP amplia o uso operacional ao conectar a topologia a inventário, assurance, configuração, telemetria e outras fontes.

Esses dados externos continuam sendo externos. Uma referência para um ativo de inventário não garante que o identificador seja equivalente em ambos os sistemas. Um sintoma de assurance pode ter sido medido depois do snapshot topológico. Uma métrica pode valer para um intervalo, enquanto a relação representa uma intenção. A união técnica dos registros não elimina as diferenças de identidade, tempo e natureza da evidência.

A autorização desenha a visão

A revisão 13 diz que a recuperação de camadas depende do que o cliente está autorizado a ver. O servidor pode esconder uma camada ou entregar uma abstração da topologia nativa por motivos de segurança, administração ou negócio. Essa resposta pode ser correta para o contrato de acesso e incompleta como descrição da infraestrutura.

Por isso, ausência na resposta não significa ausência na rede. Um nó abstrato pode reunir vários nós nativos. Um enlace lógico pode esconder dois caminhos físicos com riscos compartilhados distintos. Um cliente pode conhecer a dependência necessária ao serviço sem receber detalhes da planta interna do fornecedor.

Há ainda dois movimentos diferentes. Navegar entre camadas mostra, por exemplo, qual caminho de camada 2 sustenta um enlace de camada 3. Navegar entre níveis de abstração mostra quais nós nativos foram agregados em um nó abstrato. Um registro que cita apenas a camada não informa a granularidade da visão.

“Live” é uma afirmação com horário

O draft define live topology como o snapshot mais recente da rede real e exige descoberta e sincronização para fornecer topologia atualizada. Essas são obrigações de projeto para futuras implementações. O simples sucesso de uma chamada não prova, de forma independente, que aquela instância estava sincronizada e completa.

O modelo também precisa acomodar snapshots, topologia potencial, topologia pretendida e topologia passiva. A pretendida descreve o resultado desejado e pode omitir saltos ou dispositivos intermediários. A passiva inclui infraestrutura que não pode ser descoberta pelos protocolos e precisa ser registrada ou obtida de outro sistema. Estado e histórico podem residir na própria SIMAP ou ser apenas acessíveis por meio dela.

Uma análise deve registrar qual instância foi consultada, qual tipo de visão, qual fonte, qual momento e qual condição de sincronização. Sem isso, a palavra live é uma categoria, não uma garantia de frescor.

Dependência modelada não é causa comprovada

Se uma consulta recurso-serviço retorna quatro produtos, ela demonstra que os quatro estavam modelados como dependentes daquele recurso naquela visão. Não demonstra que o recurso causou quatro incidentes. Ele pode compor um caminho de backup, participar de balanceamento, ter uma relação desatualizada ou ter mudado após o snapshot. Um serviço também pode falhar por razão independente.

A causalidade exige uma sequência observável: mudança no recurso, mudança compatível no tráfego ou serviço, exame de causas alternativas e recuperação após uma intervenção. O mapa ajuda a selecionar hipóteses e evidências. Não transforma proximidade no grafo em explicação causal.

Escrever no mapa não muda a rede

O texto separa explicitamente a escrita em SIMAP da configuração da rede em produção. As operações de escrita atendem a análises what-if e ao registro de topologias pretendidas ou passivas. Mudanças reais seguem as operações normais do controlador.

Assim, uma automação precisa de recibos distintos para a visão ou proposta, a decisão e sua autoridade, a operação enviada ao controlador ou equipamento e a observação posterior. Aceitar uma escrita no modelo não prova que o equipamento recebeu uma ação. Aceitar uma ação não prova que o serviço melhorou.

O mesmo vale para closed loop. O SIMAP pode sustentar monitoramento e análise, mas o ciclo ainda inclui decisão, correção autorizada e feedback. Sem observação independente depois da atuação, o sistema conhece o avanço do fluxo, não o estado final da rede.

A resposta precisa carregar seus limites

Consultas usadas para decidir devem preservar servidor, instância, versão do modelo, papel e escopo do cliente, camada, nível de abstração, fontes externas, horários de captura, sentido da relação, filtros e condição de sincronização. Se houver ação, aprovação, atuação, observação e rollback permanecem separados.

Essa disciplina aumenta, e não reduz, a utilidade do SIMAP. Uma conclusão rigorosa ainda pode orientar operações: sob estas fontes, permissões e datas, este servidor representou esta dependência. O que vier depois será uma nova afirmação, com nova prova.

Fontes

Texto e andamento: SIMAP, revisão 13 e histórico no Datatracker. Especificações relacionadas: RFC 8345, RFC 8341, RFC 8040, RFC 9417 e RFC 9408. O draft YANG para SIMAP é um Internet-Draft individual, sem posição formal no processo do IETF. Texto-fonte congelado: arquivo da revisão 13. Contexto de engenharia de tráfego: RFC 9522.