Resumo

  • RFC 9962 permite que xTR participantes mantenham o mapeamento EID-para-RLOC do LISP. No push, os registros são replicados por multicast; no pull, uma transformação consistente e DNS localizam o conjunto de Map-Servers.
  • Um mapa, um registro autenticado e uma confirmação de processamento são provas delimitadas do plano de controle. RFC 9301 diz que o estado de um RLOC não informa a alcançabilidade do caminho na perspectiva de quem requisita.

O LISP separa o Endpoint Identifier, que nomeia uma extremidade na sobreposição, do Routing Locator que carrega o tráfego encapsulado. A associação entre ambos requer um sistema de mapeamento. No arranjo usual, um Mapping System Provider opera o Map-Resolver e o Map-Server, e os xTR do plano de dados registram ou consultam relações ali. RFC 9962 não transforma a relação em um fato sem responsável. Ele muda quem participa de guardar e servir esse registro limitado. Um xTR que consome o mapa pode ser também um par que o sustenta.

Trata-se de uma mudança de dependência, não de uma prova integral sobre o resultado. Em RFC 9301, um ETR envia ao Map-Server um Map-Register com um prefixo EID e um conjunto de RLOCs. Ao solicitar um Map-Notify, recebe a confirmação de que o servidor recebeu e processou o registro. Receber, processar e confirmar são ações de controle específicas. Não significam que todo solicitante alcança aquele RLOC, que o caminho de volta funciona ou que o serviço atrás do endereço permanece adequado à obrigação operacional.

RFC 9301 fixa a fronteira de modo explícito: o estado do RLOC pode comunicar alcançabilidade, mas não a alcançabilidade do caminho vista pelo solicitante; ainda é preciso testar o caminho de forma independente. Origem, encapsulamento, filtros, retorno, congestionamento, failover e política de serviço podem alterar o resultado da mesma entrada. Um mapa correto pode, portanto, apontar para um caminho inutilizável. E chegar a um endereço não resolve identidade, autorização comercial ou aceitação operacional.

Os dois desenhos de RFC 9962 destacam isso. No modelo push, xTRs entram no mesmo grupo multicast e um Map-Register pode chegar a todos os Map-Servers do grupo, que mantêm estado registrado replicado. Há redundância, mas depende de uma base multicast efetiva. No pull, uma transformação determinística converte o EID em nome DNS, encontrando o conjunto específico de Map-Servers. Replica-se menos estado, mas é necessário acordo duradouro sobre função, nomes, módulo e condições de escala.

Não são dois complementos que se misturam livremente: RFC 9962 pede a escolha de um; quando coexistem, continuam sistemas discretos, sem promessa de compatibilidade.

Autenticação também tem limites. RFC 9962 remete a RFC 9301 e ECDSA-AUTH para a confiança entre xTRs. RFC 9301 protege origem e integridade do Map-Register, usa nonce contra repetição e permite que o Map-Server recuse registros que não obedecem a chaves ou política. Isso torna atribuível a pergunta: quem apresentou qual registro e o que o sistema fez? Não demonstra a identidade da ponta, o direito de atender um cliente, a qualidade do trajeto ou a entrega futura. A prova de chave cobre um ato de protocolo, não todas as suas consequências.

Sob a lente de Lu Heng — mecanismo inicial mínimo e decisão futura próxima de quem responde pelo resultado — RFC 9962 vale porque aproxima uma função de coordenação dos participantes sem lhe dar poder de decidir por eles. Um mapa compartilhado pode reduzir custo de descoberta e registro. Ele não deveria ganhar, só por existir, poder de escolher tráfego, exposição de clientes, tolerância a falhas ou saída. A questão para a liderança não é se «descentralizado» parece atraente; é qual dependência mudou, que registro é auditável e quem mantém o julgamento final.

Fontes