Resumo

  • Na RFC 3970, um túnel estava ativo quando pelo menos um caminho estava ativo; o tempo do túnel e o tempo no caminho primário eram objetos separados.
  • Rota configurada, calculada e registrada pela sinalização não eram a mesma evidência. Notificações opcionais e limitadas, contadores descontínuos e TimeTicks cíclicos não compunham uma cronologia completa.

O painel podia dizer “ativo” e estar correto, embora incompleto. A RFC 3970, publicada em janeiro de 2005, modelou um túnel de engenharia de tráfego como entidade lógica formada por um ou mais caminhos. Se ao menos um caminho estivesse ativo, o túnel também estava. Um alternativo podia manter o serviço enquanto o primário deixava de transportar.

Por isso a MIB tinha tempos distintos: atividade total do túnel e atividade do caminho primário. O primeiro respondia se algum caminho sustentou o agregado; o segundo ajudava a medir quanto tempo a preferência original permaneceu operacional. A diferença era parte do contrato, não um detalhe de implementação.

O módulo empregava RFC 2119, a estrutura SMIv2 de RFC 2578, RFC 2579 e RFC 2580, além da arquitetura SNMP de RFC 3411 e do guia RFC 3410. Era uma projeção gerenciável de uma rede, não a própria execução.

Cada rota vinha de uma autoridade diferente

Túneis continham caminhos; caminhos continham listas ordenadas de saltos. Dentro do caminho, a rota configurada registrava o que a gestão solicitou. A rota calculada vinha de um algoritmo de restrições dependente da implementação. A rota registrada era o que o protocolo de sinalização afirmou ter utilizado. Zero significava ausência da rota calculada ou registrada.

Um pedido solto podia ser detalhado pelo cálculo, e a sinalização podia produzir outro percurso ou falhar. Os requisitos MPLS de RFC 2702, o RSVP-TE de RFC 3209 e o CR-LDP de RFC 3212 explicavam mecanismos vizinhos. Nenhum transformava configuração, cálculo e resultado de sinalização em sinônimos.

O estado do caminho distinguia down, quando a sinalização falhou; dormant, quando um backup não foi sinalizado; ready, quando estava sinalizado sem transportar; e operational, quando sinalizado e transportando. O plano de controle podia estar pronto antes de o plano de dados entrar em atividade.

O escopo ainda era o ingresso. Esse roteador deveria sinalizar aos demais pontos; a extensão da MIB para outros locais ficou para estudo. A visão do ingresso não era recibo de cada salto nem da aplicação final.

Medir exigia provar continuidade

Contadores de pacotes e octetos podiam sofrer descontinuidades na reinicialização da gestão ou em outras ocasiões. A MIB tinha um temporizador para a última ruptura. Comparar amostras sem verificá-lo podia fabricar um delta.

Idade, tempo ativo e tempo no primário usavam TimeTicks, que retornava após cerca de dezesseis meses. A RFC recomendava medições por intervalo e instruía a estação a tratar a volta. Uma taxa de disponibilidade precisava de amostras, horários e regra de continuidade, não apenas do número mais recente.

As notificações também tinham buracos deliberados. Subida, queda, troca de caminho e rerota eram limitadas a no máximo uma por minuto quando havia mudança rápida. O grupo de notificações era opcional e a geração vinha desativada por padrão. Ausência podia ser estabilidade, falta da função, configuração, perda ou contenção.

Troca e rerota não eram o mesmo evento. Na troca, mudou o caminho ativo. Na rerota, o mesmo caminho ganhou outra sequência de saltos. A identidade do caminho não fixava sua geometria.

Um índice disponível ainda podia ser disputado

A aplicação lia teNextTunnelIndex antes de criar uma linha. Duas aplicações podiam ler o mesmo candidato, e só o SET permitia ao agente arbitrar. Quem perdesse relia. A consulta não reservava o valor.

Algumas alterações pediam notInService, edição e retorno a active, com possível nova sinalização. Esse estado controlava a linha conceitual; não observava pacote entregue.

Conformidade mínima aceitava todos os objetos obrigatórios em modo somente leitura. A plena oferecia escrita conforme declarado. Notificações continuavam opcionais. Dizer que um equipamento seguia RFC 3970 não demonstrava capacidade de configuração ou entrega de alertas.

A associação com a MIB de interfaces, a MIB de túnel IP e as convenções MPLS de RFC 3811 permitia compartilhar índices e tipos. Não fazia interface, encapsulamento, caminho e serviço serem a mesma coisa.

Ver e alterar eram poderes diferentes

Uma escrita indevida em grupos administrativos mudava restrições; alterações em largura, estado ou saltos podiam desviar tráfego, causar oscilação ou interromper. Uma leitura indevida revelava pontas, volumes e rotas. A RFC recomendou autenticação e privacidade do SNMPv3 e desaconselhou versões anteriores.

Ainda assim, autenticar o principal não autorizava qualquer GET ou SET. A política precisava conceder operações específicas. Identidade, permissão e consequência continuavam separadas.

A página do RFC Editor, a busca de erratas e o IETF Datatracker mantêm o registro documental. A RFC 9141 atualizou depois uma referência de arquivo antiga nos contatos. Nada ali mede adoção, fabricante, disponibilidade ou incidente.

A contribuição histórica foi recusar uma verdade monolítica. Estado agregado, estado de caminho, linhagem da rota, continuidade do contador e fluxo de eventos tinham limites próprios. A observação só era segura quando preservava esses limites.

Fontes