Resumo

  • draft-ietf-lisp-site-external-connectivity-05 permite devolver um conjunto não vazio de RLOCs pETR quando o destino é externo, desconhecido ou conhecido sem registro.
  • A resposta decide por onde tentar sair em determinado IID e versão de política. Ela não descobre o destino, não verifica a rota nativa do pETR e não confirma o resultado da aplicação.
  • Registro, decisão, cache, desencapsulamento, encaminhamento externo e conclusão do serviço precisam de evidências separadas.

No modelo básico de RFC 9301, a ausência de mapeamento pode gerar uma Negative Map-Reply sem locators e com uma ação limitada por TTL. A revisão 05 faz algo diferente: usa o procedimento negativo para calcular o “hole” não-LISP, mas exige um Loc-Count diferente de zero. Os localizadores representam pETRs capazes, segundo registro ou política, de levar o tráfego para fora.

O destino não virou EID registrado. A rede encontrou uma regra para a classe “externo ou desconhecido”. Essa distinção parece pequena até o primeiro incidente. A Map-Reply pode estar correta enquanto o pacote falha depois do pETR por falta de rota, filtro, congestionamento ou serviço remoto indisponível.

O hole ganhou um próximo passo, não uma identidade

Uma plataforma honesta mantém dois fatos: unknown_or_unregistered e external_exit_selected. Substituí-los por resolved=true apaga justamente a incerteza que acionou o mecanismo.

O encadeamento probatório tem etapas próprias. O registro mostra que um candidato se apresentou. A resposta mostra a escolha do servidor. O readback do map-cache mostra o estado pretendido no ITR. Um contador de decapsulation mostra chegada ao pETR. O encaminhamento nativo e a resposta da aplicação demonstram partes posteriores. Nenhum recibo assina o seguinte por inferência.

Refazer a consulta e receber o mesmo RLOC apenas reproduz a decisão de controle. Não testa a Internet externa. O diagnóstico precisa avançar até a primeira evidência ausente.

Registro é uma alegação de elegibilidade

O pETR pode se registrar por VPN Instance ID usando um Distinguished Name configurável, um conjunto de RLOCs e codificação de VPN. Dados LCAF de fornecedor podem acrescentar localização, disponibilidade de recursos e desempenho.

Autenticação indica quem enviou. A política de admissão deve dizer se esse principal podia anunciar saída para aquele IID e se controlava os RLOCs. Uma verificação operacional separada precisa dizer quando a conectividade externa foi observada e qual evento remove o candidato.

RFC 9306 oferece o recipiente para informação específica do fornecedor, não um vocabulário universal de medição. “Disponível” pode significar configuração habilitada, contador local, previsão do controlador ou observação antiga. Sem produtor, esquema, unidade, janela, método, confiança e validade, o valor é um sinal de política, não verdade comparável.

Esse limite cria um incentivo importante. Quando metadados controlam distribuição de tráfego, cada gateway ganha vantagem ao se descrever de forma otimista. Preservar a proveniência permite auditar o incentivo em vez de esconder uma decisão comercial atrás de um score técnico.

Priority e weight não medem o caminho

RFC 9300 prefere o menor priority e distribui entre RLOCs de mesma prioridade segundo weights relativos. Os campos instruem o ITR. Eles não provam capacidade, latência, custo, independência física ou divisão observada.

Dois RLOCs podem depender do mesmo roteador, operadora ou energia. Um peso 70/30 pode expressar contrato, não largura de banda. Por isso o recibo precisa guardar candidatos antes de filtros, exclusões, snapshot dos metadados, versão da política, desempate e divisão esperada. Contadores por pETR mostram depois o que realmente aconteceu.

Map-Notify-Ack termina no plano de controle

RFC 9437 permite publicar mudanças por Map-Notify com nonce, associação de segurança e Map-Notify-Ack. Sem pub/sub, o rascunho sugere TTL menor para atualizar o cache.

O ACK confirma a mensagem de controle; não confirma programação de hardware, correspondência do próximo pacote nem entrega. TTL curto reduz a idade máxima desejada do estado, mas não garante refresh bem-sucedido.

A cadeia operacional deve registrar: atualização autenticada, escopo aceito, escrita executada, readback correto, canário até o pETR, canário no trecho externo e conclusão da aplicação. Se o último falha com os anteriores saudáveis, a quebra está depois da seleção.

O default tem o maior raio de impacto

O ITR pode instalar um hole prefix ou uma entrada default. O texto recomenda manter blocos EID conhecidos como entradas mais específicas que sempre provoquem Map-Request. Isso evita que o default externo capture destinos que merecem resolução LISP normal.

Uma entrada ampla simplifica a operação, porém uma única alteração pode mover muitos fluxos. O ponto de observação, o custo, a jurisdição e o controle de segurança mudam mesmo que o endereço pedido pela aplicação permaneça igual. A implantação deveria começar por IID limitado, prefixos protegidos, ITRs canário e TTL controlado. O rollback deve retirar apenas o pETR afetado, não reiniciar mapas sem relação.

O Datatracker registra um Internet-Draft Experimental, não RFC, prova de implementação ou resultado de interoperabilidade. A infraestrutura de IA citada é um caso de uso, não comprovação de adoção.

As camadas de realidade de Lu Heng ajudam a nomear o limite: Distinguished Name é símbolo; Map-Reply é decisão; cache é estado; pacote é ação; resposta remota é resultado. O sistema confiável liga as camadas sem transformá-las em um único selo verde.

Fontes