Resumo

  • A revisão preliminar de Donald Eastlake para o Routing Area Directorate foi concluída em 27 de setembro com o resultado “Not ready”. É um parecer individual sobre um Internet-Draft ativo, não uma rejeição do IESG.
  • A revisão 13 do projeto usa SHOULD para resolver o próximo salto na base de encaminhamento do plano de dados escolhido e MAY para testar disponibilidade do caminho. O texto não liga explicitamente um resultado negativo à exclusão da rota da escolha do melhor caminho.
  • Para o revisor, a verificação deve alcançar o estado que os pacotes realmente usarão, inclusive o mecanismo de rótulos ou túnel e a resolução recursiva, e não qualquer entrada aparentemente compatível.

O problema começa quando duas respostas verdadeiras são confundidas. O roteador sabe chegar, pela tabela IP, ao endereço do próximo salto. Mas a VPN entrega o tráfego por um LSP MPLS que pode não funcionar. No exemplo do projeto do grupo IDR, o equipamento de borda continuaria atraindo tráfego para esse caminho enquanto outro percurso poderia estar disponível. Trata-se de uma topologia didática; os documentos não identificam um apagão real nem medem sua frequência.

Donald E. Eastlake III datou sua revisão em 25 de setembro, e o registro do IETF a marcou como concluída no dia 27. O resultado “Not ready” pede mais trabalho antes do envio ao IESG. A ficha do documento ainda mostra a versão 13, de 14 de setembro, como Internet-Draft ativo do grupo IDR, com estado “I-D Exists” no IESG e sem data de telechat. A pretensão de atualizar RFC 4271 depende de aprovação. O grupo havia realizado Last Call e revisão por diretor de área em 2020, mas o processo não terminou naquela ocasião. A notícia é a crítica técnica atual, não uma decisão final contra o projeto.

A crítica atinge o vínculo entre teste e decisão. A seção 3 afirma que a alcançabilidade do próximo salto SHOULD ser resolvida na base de encaminhamento do plano de dados que a política escolheu. Um teste de disponibilidade por OAM MAY ser feito no mesmo plano. Política e mecanismos ficam fora do escopo. RFC 4271 já impede que uma rota não resolúvel entre na função de decisão da fase 2. Porém, observa Eastlake, a nova redação não declara que falhar em qualquer um dos testes torna a rota não resolúvel para esse fim. A sugestão dele de usar MUST para explicitar a consequência não faz parte da redação atual.

É necessário definir o objeto do teste. Um próximo salto MPLS pode depender de rótulo distribuído por LDP, SID de Segment Routing, túnel RSVP-TE ou SR Policy, ou rota BGP etiquetada cuja resolução continua por outros passos. Em um vizinho diretamente conectado, uma entrada sem rótulo pode ser a correta. Consultar outra base não confirma o caminho que levará o pacote. Eastlake pede que a verificação acompanhe o mecanismo e a recursão efetivamente utilizados. Sem isso, dois equipamentos podem tomar decisões diferentes sobre as mesmas rotas anunciadas.

O projeto também precisa conviver com RFC 9012: quando o atributo Tunnel Encapsulation não oferece túnel viável, aquela especificação já trata a rota como não resolúvel sob RFC 4271. A revisão pergunta qual contribuição adicional restaria, sem afirmar que haja contradição. Quanto à checagem opcional de vida, sinais instáveis ou falsos podem provocar retiradas e novos anúncios, e decisões distintas entre roteadores IP podem criar loops. São riscos apontados para análise, não falhas comprovadas de produtos.

Uma operação auditável registraria o plano escolhido, a entrada de encaminhamento pertinente, a fonte do teste e a mudança concreta na elegibilidade da rota. Daniel Kade propõe essa cadeia como disciplina de responsabilidade, não como formato obrigatório criado pelo IETF. O parecer tampouco demonstra adoção da checagem em produção.

Fontes