Resumo

  • A revisão 07 propõe módulos YANG para testes OAM unitários e sequências ordenadas pelo usuário, combinando período, recorrência, estado e modelos de dispositivo montados no esquema.
  • Uma sequência em success não comprova sozinha qual versão rodou, se todas as etapas foram completas e comparáveis, se a causa é única, se a mudança foi autorizada ou se o serviço se recuperou.

A agenda é o começo da investigação

Diagnóstico de rede costuma ser uma cadeia: testar continuidade, rastrear caminho, medir perda e atraso, reduzir a área suspeita e repetir na janela em que a falha aparece. draft-ietf-opsawg-scheduling-oam-tests-07 procura tornar essa cadeia declarativa. Um módulo descreve o teste, os elementos de rede e o modelo OAM aplicável; o outro reúne testes em ordem definida pelo usuário e acrescenta regras de período ou recorrência.

O ganho é real: uma equipe pode revisar o plano antes da execução e comparar ocorrências. O risco também é real: a interface mostra uma lista, um contador e um estado final, e a organização passa a enxergar uma conclusão causal que o registro nunca afirmou.

Segundo o Datatracker, a revisão 07 continua sendo um Internet-Draft ativo do OPSAWG, pretendido para Standards Track, sem número RFC e sem processamento iniciado pelo IESG. O histórico registra avaliações antecipadas de OPSDIR e PERFMETRDIR como Has Issues; a análise de YANG Doctors permanece incompleta. Portanto, o documento não comprova implementação, implantação ou conformidade.

1. Comprovante do plano

O rascunho reutiliza de RFC 9922 estado, versão, horário local, última e próxima ocorrência e contadores. Cada teste pode apontar para vários nós e para um modelo OAM montado sob root.

O comprovante precisa congelar digest da configuração, ordem dos testes, nós, parâmetros, regra de tempo, fuso, identidade da biblioteca YANG e responsável pela aprovação. RFC 9922 permite que a entidade consumidora cuide de version e admite que o campo não seja usado. Um número de versão, sem conteúdo associado, não prova o que foi aprovado. A ocorrência deve apontar para a configuração exata que disparou.

2. Comprovante de aplicação

Os estados propostos incluem planned, configured, ready, on-going, stop, error e success; a sequência também tem failure. Eles descrevem o entendimento local do servidor.

Uma edição aceita por NETCONF ou RESTCONF não prova aplicação em todos os equipamentos. RFC 8342 separa running, intended, configuração aplicada e operational. Conteúdo pretendido pode não estar ativo. É preciso comparar intended e operational por nó, guardar capacidades e versão do esquema e registrar falhas parciais.

A avaliação OPSDIR também observa que o texto fala em uso sob demanda, mas não define RPC nem action normativa. Operações existentes em modelos inferiores não devem ser atribuídas ao rascunho.

3. Comprovante da ocorrência

Recorrência é uma regra, não a identidade de uma execução. Reinicialização, atraso de fila, repetição, sobreposição, failover e ajuste de relógio podem tornar last-occurrence insuficiente.

Cada execução precisa de ID próprio, horário previsto, início e término reais, versão do plano, orquestrador, fonte e erro máximo do relógio, linhagem de novas tentativas e nós realmente alcançados. Um teste que terminou fora da janela do incidente pode ser tecnicamente bem-sucedido e ainda assim irrelevante para a condição investigada.

4. Comprovante de etapas completas

A lista é ordered-by user, e uma etapa com erro não impede necessariamente as próximas. Isso preserva observações, mas separa “terminou de percorrer a lista” de “completou o procedimento diagnóstico”.

A avaliação PERFMETRDIR questiona por que stop leva a sucesso no teste unitário e a falha na sequência. OPSDIR pede clareza sobre erro, falha, notificação, correlação, consistência e rollback entre nós. O comprovante deve listar etapas obrigatórias, dependências, nó, horário, resultado, omissão e decisão de continuar, além das hipóteses que a lacuna deixa abertas.

5. Comprovante da medição

O modelo de agenda não redefine entradas e resultados detalhados. Ele recorre a modelos OAM de dispositivo, como o TWAMP de RFC 8913. RFC 8528 permite montar um modelo sob outro, mas não pressupõe a origem dos dados da instância nem como o ponto foi criado.

O registro de medição deve nomear tipo e revisão, parâmetros, origem e destino, direção, população de pacotes, classe, tamanho, taxa, janela, unidade, relógio, dispositivo, valor bruto ou digest e custódia. Uma referência para uma folha montada não carrega toda essa semântica.

RFC 7799 distingue medição ativa, passiva e híbrida. Pacotes criados pela sonda e tráfego de produção não são a mesma população por padrão.

6. Comprovante de comparabilidade

RFC 10014 separa congruência topológica de tratamento de encaminhamento igual. A sonda pode cruzar os mesmos links e nós, mas usar outra fila, QoS, perna ECMP, policer ou carga.

O comprovante precisa declarar o que sonda e serviço compartilharam: topologia, encapsulamento, classe, hash, domínio de manutenção, janela, carga e modo de falha. Se só o caminho é comum, a conclusão deve ficar limitada ao caminho. Agendar um teste não cria equivalência com o tráfego afetado.

7. Comprovante da hipótese e da autoridade

O rascunho fala corretamente em causas candidatas. RFC 9940 distingue evento, falha, problema, sintoma, causa, alerta, alarme e incidente. RFC 8632 trata recursos candidatos à causa como dicas para o cliente.

O diagnóstico deve guardar observações, explicações concorrentes, hipóteses excluídas, confiança, escopo e condição de refutação. Depois vem outra decisão: quem pode mudar a rede. A permissão de criar testes não autoriza alterar roteamento ou QoS. RFC 8341 mantém controle de acesso separado; a mudança precisa de dono, política, conteúdo exato, raio de impacto, janela e rollback.

8. Comprovante do resultado

A mudança pode ser aceita e a sonda pode voltar ao verde enquanto o cliente continua afetado. O tráfego talvez tenha mudado de caminho, um sintoma tenha sido ocultado ou outra degradação tenha surgido.

O resultado deve vir da superfície responsável pela promessa: população do serviço, condição de SLA, janela posterior, sinais independentes, alarmes residuais, rollback e duração da estabilidade. Repetir a mesma sonda ajuda, mas não é independente quando a comparabilidade da sonda era o ponto em disputa.

OAM agendado cria uma linguagem para coordenar as primeiras etapas. A operação responsável preserva os limites: plano, aplicação, ocorrência, passos, medição, comparação, causa, autoridade e resultado podem se conectar sem virar uma única luz verde.