Resumo

  • A revisão de telechat concluída em 1º de outubro sugere esclarecer que o controlador superior, ao servir uma visão combinada, deve garantir a unicidade dos valores ne-id expostos.
  • Tornar a chave única resolve a validade da lista, mas não decide se dois registros são equipamentos diferentes com o mesmo ID ou o mesmo equipamento com IDs diferentes.

O inventário de um domínio chama um roteador de 17. O inventário de outro domínio chama um equipamento óptico pelo mesmo número. Separadamente, ambos são válidos. O conflito nasce no instante em que uma camada superior promete entregar uma única lista.

Linda Dunbar registrou esse limite na revisão do Routing Area Directorate sobre a revisão 20 de draft-ietf-ivy-network-inventory-yang, concluída em 1º de outubro. O resultado foi Has nits: o documento é considerado claro, com uma questão menor. Como o servidor atribui ne-id e esse campo é a chave da lista network-element, o controlador superior que combina dados de controladores inferiores deveria responder pela unicidade na visão que oferece.

Não se trata de um relato de falha. A revisão 20 é um Internet-Draft ativo do grupo IVY, destinado ao Standards Track e em avaliação do IESG com acompanhamento do Area Director. Ainda não é RFC. A observação não demonstra colisão em produção, vulnerabilidade ou defeito de fornecedor; ela torna visível uma obrigação arquitetural.

O modelo descreve, em modo somente leitura, elementos e componentes que um controlador sabe estarem instalados. Estoque, compras e metadados comerciais ficam fora da base. No escopo do modelo, o controlador que fornece os dados é a fonte de verdade. Isso lhe dá responsabilidade pela representação, não poder para transformar a representação na realidade física.

O texto já diz por que ne-id vem do servidor: o identificador local do equipamento pode não ser único na rede. Também espera que o mesmo elemento conserve o mesmo ID durante uma desconexão. Os meios para reconhecer continuidade—fabricante, produto, endereço de gestão, localização ou outro sinal—são específicos da implementação.

Na agregação, portanto, aparecem dois trabalhos. Um é garantir que a estrutura YANG não tenha duas entradas com a mesma chave. O outro é reconciliar identidade. Acrescentar o nome do domínio à chave executa o primeiro. Não informa se A-17 e B-42 representam o mesmo chassi.

Separar demais pode duplicar ativos, capacidade, alarmes e manutenção. Unir demais pode confundir dois equipamentos reais e transferir uma ação de um para outro. Endereços mudam, localizações ficam desatualizadas e modelos se repetem. A incerteza precisa de estado próprio; não deve ser apagada para que o painel pareça limpo.

O UUID comum é uma referência importante, mas não uma prova completa. A revisão 20 o descreve como globalmente único e atribuído pelo servidor; a especificação de UUID define formato e propriedades. Mesmo assim, dois servidores podem gerar UUIDs válidos distintos para o mesmo objeto, e uma cópia errada pode dar o mesmo UUID a objetos diferentes. Unicidade do valor e identidade do ativo são proposições separadas.

Uma operação segura distingue o ativo físico, a observação de cada controlador inferior, o ne-id local, a decisão de reconciliação superior e o ne-id combinado consumido por alarmes, topologia, ordens de serviço e automação. A validação da lista prova apenas que a saída respeita sua estrutura.

A proposta editorial da BTW é um recibo reversível de tradução de identidade. Ele liga controlador e ne-id de origem ao ne-id combinado, UUID e âncoras de hardware disponíveis. Registra regra de correspondência, confiança, conflito, primeira e última observações, substituições e decisões relevantes que utilizaram o vínculo.

Esse recibo não está exigido no draft nem na revisão. Serve para que renomear não signifique esquecer. Se B-17 vira 18 na visão superior, o caminho inverso permanece. Se novas evidências indicam que A-17 e B-42 são um só chassi, a fusão preserva as afirmações anteriores. Quando a evidência não basta, um conflito aberto é melhor que uma falsa certeza.

As notas de Heng Lu oferecem a disciplina, sem serem atribuídas à IETF. A Nota 20 separa realidade executável e representação simbólica. A Nota 64 limita a camada comum a invariantes mínimos e verificáveis de unicidade e interoperabilidade, deixando decisões futuras com quem executa o sistema. A Nota 19 separa coordenação de autoridade. Aplicado aqui: o modelo comum precisa de chave única; o agregador local responde pela reconciliação e pela prova; nenhum ID concede autoridade sobre o equipamento físico.

O recorte também evita repetir trabalhos próximos. O mapeamento de topologia trata de substituições manuais de ne-ref e port-ref; o inventário de direitos separa licença, ativação e serviço; o inventário passivo trata da custódia de evidência para objetos que não falam. Aqui, a questão vem antes: como uma identidade atravessa domínios sem perder origem.

O draft permite explicitamente que um controlador hierárquico recolha inventários inferiores e exponha uma visão combinada a outro controlador, a um Inventory OSS ou a outra aplicação, citando ACTN como contexto possível. A norma não precisa impor um algoritmo universal de matching. Precisa deixar claro qual servidor garante a unicidade; a implementação, por sua vez, deve tornar auditáveis prefixos, remapeamentos, fusões, separações e conflitos.

Fontes