Resumo
- A RFC 3139 mostrou que “serviço gold” precisava de topologia, estado e capacidade para se tornar configuração local diferente em cada plataforma.
- Vários tradutores podiam formar uma cadeia, mas apenas um podia operar em um dispositivo por instante. Política, candidato, escrita, confirmação e resultado eram recibos distintos.
Gold era uma promessa antes de ser estado
Uma operadora consegue declarar o objetivo em poucas palavras. O roteador precisa saber interface, classificador, fila, scheduler, banda e caminho de contingência. Fabricantes diferentes pedem parâmetros e sequências diferentes.
A abstração torna o objetivo administrável; também prova que ele não é a configuração. Política aprovada, modelo salvo e compilação sem erro não demonstram que caixas aceitaram estado coerente nem que clientes receberam tratamento.
Publicada como Informational em junho de 2001, a RFC 3139 não escolheu protocolo. Ela surgiu do temor de que soluções COPS/PIB, SNMP/MIB e específicas de tecnologia fragmentassem a gestão. Após uma reunião sem consenso total em 1999, um grupo reuniu requisitos comuns.
Seus MUST descrevem o que uma solução deveria fazer, não que uma solução existente já o fazia.
Três representações exigiam tradução
O documento separou política de alto nível, configuração network-wide e configuração device-local. A primeira expressava comportamento; a segunda permitia derivar várias caixas; a terceira continha o detalhe de uma máquina.
O configuration-data translator cruzava as camadas. Podia ser humano, software central, intermediário ou função no equipamento. A localização não era prescrita.
Traduzir exigia topologia, capacidade, status, desempenho e monitoramento. Um candidato pode ser sintaticamente perfeito e nascer de mapa antigo. Se faltasse informação necessária à conversão sem erro, o sistema tinha de detectar e agir; não podia fingir certeza.
Uma cadeia de tradutores, um writer na caixa
Vários translators podiam trabalhar em tandem: objetivo para modelo, modelo para tecnologia, tecnologia para comandos. Porém só um podia operar em um dispositivo em dado instante.
Isso não era algoritmo de lock, eleição ou lease. Era uma invariante. Dois controladores com revisões diferentes podem produzir candidatos razoáveis e um estado híbrido incoerente quando escrevem intercalados.
Um reduz a fila enquanto outro restaura o perfil anterior. Sobram classificador novo, scheduler antigo e expiry ausente. Dois sucessos de comando não provam configuração final.
Por isso o RFC também exigia eliminar misconfiguration por shared write concorrente. Writer, revisão, inputs e janela de exclusão precisam ficar no recibo. Last-write-wins ordena bytes, não recupera intenção.
A falha podia morar entre caixas corretas
Adicionar, modificar, remover, dump ou restore deveria ocorrer simultaneamente ou de modo sincronizado quando necessário. Nem todo partial é ruim; o perigo depende da relação.
Route antes de filtro pode expor tráfego. Marcação antes do core pode perder classe. Metade de migração pode gerar loop ou blackhole. O sistema precisava detectar erro e impedir partial inadequado, mas RFC 3139 não garantiu commit distribuído nem rollback universal.
Separe batch do orquestrador, respostas, estado armazenado, estado efetivo e tráfego. Nenhum desses atores possui todos os fatos.
O failover rápido era preparado antes
Múltiplas configurações locais poderiam ser pré-carregadas para evitar download maciço durante falha. Preload não é ativação; ativação não prova atualidade. Topologia e capacidade podem mudar.
Redundância de controladores cria ownership: qual writer herdou o snapshot e como o antigo ficou fenced? Duas instâncias vivas sem exclusão produzem exatamente a concorrência que o requisito rejeitava.
Feedback não era experiência do cliente
Dispositivos deviam enviar confirmação, status, monitoramento e eventos. Mas confirmar o quê—parse, validate, candidate, commit, effective, persistência ou forwarding?
O estado local tinha de ser interpretado no contexto network-wide. Uma fila instalada pode estar no caminho errado; uma diferença local pode ser a tradução correta para outro hardware.
Mesmo todas as caixas confirmando não provam o serviço. O tráfego pode usar outra rota ou falhar no classifier. Gold installed e gold experienced pertencem a testemunhas diferentes.
Configuração tinha relógio
Effective time e expiration time eram requisitos. Valor futuro pode estar armazenado e inativo; valor expirado pode permanecer presente e sem autoridade.
Clock skew e restore agravam o risco. Uma exceção acabou no controller e continua na caixa; snapshot antigo ressuscita regra vencida. O recibo precisa de base temporal, vigência e intervalo observado.
Provisionamento por eventos também exige event ID, policy revision, writer e lifetime. Sem isso, automação rápida oscila.
Segurança fazia parte do significado
Controle de acesso, autenticação, integridade, replay protection, privacidade e rastreabilidade por host/usuário eram requisitos. Configuração bem formada por ator sem autoridade continua inválida.
Replay de policy antes legítima pode aplicar topologia obsoleta. Autenticação identifica; integridade protege; frescor e autorização respondem se pode escrever agora.
Para investigar drift, preserve policy, projeção, snapshot, translator, candidato, comandos, erros e feedback antes do próximo writer.
Evolução precisava mostrar perdas
Modelos, mensagens e tipos deviam evoluir sem trocar a frota, aproveitando experiência MIB/SMI. Um campo novo pode ser desconhecido, uma capacidade parcial ou omitida. Syntax válida pode carregar intenção incompleta.
Capability discovery, tratamento explícito do desconhecido e degradação visível são necessários. O RFC não prometeu que dispositivo antigo executaria policy futura.
O workshop descrito em RFC 3535, NETCONF e NMDA depois concretizaram datastore, lock, validate, commit e intended/applied/operational. São contexto posterior, não recursos já implementados pela RFC 3139.
A política dizia o que deveria ser verdade. Tradução disciplinada, writer exclusivo, aplicação coordenada, feedback e medição diziam o que se tornou verdade.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
