Resumo

  • was-the-last-lie-accepted informa apenas se o Link Information Element recebido mais recentemente foi aceito naquela interface. Não comprova ThreeWay, nível ZTP, sincronização TIE, RIB/FIB ou entrega.
  • Um clear inicia a reconstrução de conexões. A recuperação só pode ser declarada depois de observar novamente a cadeia de estado, banco, rota, hardware e tráfego real.

Uma resposta precisa para uma pergunta pequena

O RFC 9719 define um modelo YANG 1.1 compatível com NMDA para RIFT e amplia o modelo de roteamento do IETF. was-the-last-lie-accepted é estado operacional somente de leitura. True significa que o último LIE recebido passou pela aceitação. Se houver rejeição, last-lie-reject-reason e a notificação neighbor-error oferecem contexto.

Nada nessa semântica afirma que o outro lado reconheceu este nó, que a adjacência alcançou ThreeWay, que o ZTP escolheu a hierarquia pretendida, que o banco topológico está íntegro, que rotas foram instaladas ou que um pacote chegou.

O RFC 9692 separa as etapas. TwoWay já inclui um LIE válido, mas ainda não um LIE ThreeWay válido. A adjacência só é anunciada em ThreeWay, e TIE, TIDE e TIRE dependem desse estado. Aceitação é um veredicto de entrada; reciprocidade é uma prova posterior.

O percurso da evidência

O modelo expõe muito mais do que o booleano: estado da interface e motivo de rejeição, FSM de adjacência, ofertas ZTP enviadas e recebidas, melhor oferta e remoções, contadores e filas LIE/TIE/TIDE/TIRE, banco TIE local, tempos de SPF e TIE disparador, além de erros de vizinho e TIE.

Se o LIE for rejeitado, o primeiro ato é preservar motivo, par, notificação e cronologia. Logs específicos continuam úteis, mas não substituem o estado estruturado que permite comparar implementações.

Se for aceito, verifica-se a chegada e a permanência em ThreeWay. Parar em TwoWay não invalida a aceitação; localiza uma falha entre mensagem válida e confirmação mútua.

Em seguida vêm as ofertas. Um LIE válido não garante que nível e direção correspondam ao desenho do fabric. Ofertas recebidas, melhor escolha e remoções precisam ser examinadas como decisões distintas.

Depois vem a sincronização: conteúdo do banco TIE, atividade TIDE/TIRE, filas, contagem de vizinhos e o evento que iniciou o SPF. Uma adjacência estável não transforma um banco incompleto em roteamento correto.

No fim, é preciso sair do modelo. O RFC 9692 não especifica como o encaminhamento é programado. RIB, FIB, contadores de ASIC e uma sonda de entrega são evidências independentes. O plano de controle mostra sua crença; o pacote mostra o resultado.

Por que limpar não é provar

clear-neighbor e clear-all-neighbors encerram uma ou todas as conexões vizinhas da interface. O sucesso da chamada comprova que o comando foi aceito, não que as conexões voltaram. O próprio RFC alerta que clears não autorizados podem provocar reconstruções repetidas e prejudicar a estabilidade.

Por isso, a sequência correta preserva o estado anterior, aplica a menor intervenção justificável e revalida LIE, ThreeWay, ofertas, TIE, SPF, instalação de rotas, hardware e entrega. Limpar pode remover estado obsoleto; também pode apagar a pista decisiva.

A capacidade mais importante

Com RFC 9719, automação pode alertar sobre rejeições repetidas, aguardar ThreeWay antes de validar o banco, correlacionar um TIE ao tempo de SPF e comparar ofertas operacionais com a intenção configurada.

Ela não deve elevar uma folha local ao status verde de todo o fabric. O padrão torna as fronteiras entre as respostas legíveis por máquina — um ganho maior do que qualquer indicador único.