Resumo

  • O rascunho atual de multicast no LISP diz que a perda do ITR que funciona como raiz exige criar estado rumo ao novo encapsulador e informá-lo novamente sobre os fluxos (S-EID,G) esperados.
  • Anycast pode manter o RLOC alcançável e reduzir a mudança do underlay a uma reconvergência RPF. Porém, o ETR talvez não saiba que a máquina mudou; o sucessor pode esperar o próximo Join/Prune periódico.
  • Daniel Kade propõe um recibo de sucessão da raiz e uma dívida explícita de reenvio de joins. São controles operacionais, não novos campos do LISP ou do PIM.

Um endereço verde pode esconder uma árvore muda

Considere uma transmissão enviada de um site de origem para receptores em várias redes. O Ingress Tunnel Router do site falha. O roteamento atrai o RLOC anycast para outro ITR. As sondas voltam a alcançar o endereço e, em um underlay multicast, a interface de caminho reverso muda. A equipe de routing pode registrar corretamente que o endereço se recuperou rápido.

Ela ainda não demonstrou a recuperação do serviço. O ITR antigo guardava quais ETRs remotos tinham aderido a quais pares de origem e grupo. A nova instância pode receber tráfego destinado ao mesmo RLOC sem possuir esse inventário. O nome da raiz permanece, mas a memória pertencia ao processo que desapareceu. Até que os sites receptores repitam sua intenção, o substituto pode não saber o que encapsular nem para quem.

Isso não significa que o anycast esteja quebrado. Seu compromisso é permitir que vários locais anunciem o mesmo endereço e deixar o roteamento escolher uma instância. Ele não promete replicação do estado interno de um protocolo. O erro de governança surge quando a restauração do endereço é apresentada como certificado de continuidade de todos os serviços com estado por trás dele.

O draft-ietf-lisp-rfc6831bis-07 está ativo, em IESG Evaluation, e busca o nível Proposed Standard. Se aprovado, substituirá o RFC 6831 experimental. A revisão 07 foi publicada em 11 de setembro de 2026. A comparação com a revisão 06 mostra principalmente linguagem normativa, referências atualizadas de IGMP e MLD e manutenção editorial. Este artigo usa a arquitetura completa do texto atual; não trata o número 07 como se tivesse criado o mecanismo de failover.

A intenção usa EID; o transporte usa RLOC

O LISP separa Endpoint Identifiers de Routing Locators. Dentro dos sites, origem e receptores tratam do EID da origem e do grupo multicast. O underlay encaminha com RLOCs. A separação mantém a identidade estável quando o ponto de conexão muda, mas distribui o estado multicast entre dois espaços de nomes.

Um receptor adere a (S-EID,G) por IGMPv3 ou MLDv2. Seu ETR consulta o EID da origem e escolhe um RLOC de ITR usando prioridade e peso do mapping. Em um underlay multicast, o ETR produz dois sinais. Um PIM Join/Prune encapsulado em unicast carrega (S-EID,G) até o ITR escolhido. Outro Join/Prune cria (S-RLOC,G) no underlay. O primeiro informa qual fluxo interno o encapsulador deve atender; o segundo constrói a árvore baseada no locator.

No underlay unicast, o ITR mantém uma lista explícita dos RLOCs dos ETRs receptores e realiza replicação na origem, uma cópia externa por destino. No recebimento, o ETR remove o cabeçalho LISP e consulta sua FIB multicast interna (S-EID,G) antes de encaminhar aos receptores locais.

Essas evidências não são intercambiáveis. Um Map-Reply indica locators, não instalação de fluxo em uma instância física. Um RPF válido mostra o caminho do underlay, não o conhecimento do S-EID na raiz. Um join local ainda presente não prova que o encapsulador remoto se lembre dele. Um pacote pode chegar por uma árvore (RLOC,G) compartilhada e ser descartado porque não existe estado interno correspondente.

O objeto operacional, portanto, não é uma única “rota multicast”. É a cadeia composta por intenção do receptor, estado de fronteira no ETR, raiz física selecionada, estado EID no ITR, replicação no underlay ou na origem, aceitação pelo ETR e observação final. Cada etapa tem dono e relógio distintos.

A troca física cria uma obrigação de sucessão

A seção 6 do rascunho mostra por que a falha de um ITR vai além de uma alteração RPF comum. No unicast, a alcançabilidade local pode permitir outra escolha de locator com pouca coordenação. No multicast LISP, o ITR selecionado é a raiz encapsuladora da árvore. Quando ele fica inalcançável, os ETRs associados precisam construir estado (S-RLOC,G) em direção à nova raiz e enviar um Join/Prune encapsulado que revele o (S-EID,G) desejado.

A obrigação tem uma população: todos os ETRs afetados. Tem também um objeto: o conjunto de estados origem-grupo que cada um espera no sucessor. Detecção, seleção e reenvio ocorrem em momentos diferentes. Um único carimbo “failover concluído” não representa essa distribuição, sobretudo sua cauda mais lenta.

Anycast reduz a visibilidade da mudança. Se vários ITRs usam o mesmo RLOC, o roteamento move o endereço e o underlay pode ver apenas uma nova interface RPF. Para o ETR remoto, o endereço não mudou. Talvez não exista um evento que provoque imediatamente o reenvio unicast de (S-EID,G). O texto afirma que o novo ITR anycast pode receber esse estado só quando chegar a próxima transmissão periódica do ETR.

Não há um número universal para esse intervalo. Implementação, temporizadores PIM, perda, convergência, política de refresh e tipo de underlay interferem. Também não se pode concluir que toda troca causará perda. A conclusão segura é menor e mais útil: o retorno do endereço e o retorno do estado são fatos separados.

Dívida de reenvio de joins

Chamo de dívida de reenvio de joins o conjunto de intenções receptoras ainda não demonstradas no novo ITR. No instante da troca física, cada ETR cujo (S-EID,G) necessário não esteja comprovadamente instalado abre um item. “Dívida” não é acusação moral nem contador simples de pacotes; é uma forma de impedir que uma transição distribuída suma atrás de um indicador agregado.

Um item mínimo liga ETR, S-EID, grupo, ITR anterior, sucessor esperado, geração do último join, hora do refresh, modo do underlay e condição de encerramento. Se a implementação expuser confirmação de instalação, ela ajuda. Caso contrário, será preciso unir inspeção limitada do estado na raiz a observação no ETR ou em um receptor canário controlado.

Ping bem-sucedido ao RLOC anycast, rota na RIB, entrada no cache de mapping, adjacência PIM ou processo ativo não quitam essa dívida. Nenhum mostra que a intenção daquele receptor entrou naquela instância física. A volta de um receptor também não quita os demais, que podem aguardar outros ciclos.

Um item pode ser encerrado por retirada legítima. O receptor saiu, a origem parou ou a política moveu o fluxo. O recibo deve dizer se houve “instalação e observação”, “retirada explícita”, “expiração segundo regra declarada” ou “degradação aceita por responsável nomeado”. Desaparecimento sem evidência não é recuperação.

Recibo de sucessão da raiz

O recibo de sucessão da raiz reúne as peças. É uma proposta de Daniel Kade para governança operacional, não um campo novo em pacotes LISP, PIM, IGMP ou MLD. Ele impede que uma equipe encerre o incidente usando apenas a camada que controla.

O recibo identifica as instâncias físicas antiga e nova, seus RLOCs individuais ou compartilhados, fonte e hora da detecção, confiança, versão de mapping e responsável pela decisão. Anotar apenas o endereço compartilhado omitiria precisamente o evento que precisa ser auditado: a sucessão escondida por trás dele.

Depois, acompanha o controle por escopo afetado: último (S-EID,G) conhecido na raiz anterior, nova seleção, convergência RPF, geração do join no ETR, reenvio encapsulado e estado instalado no sucessor quando observável. Ponto de coleta e fonte de relógio devem permanecer ligados aos eventos; horários não comparáveis não formam uma causalidade segura.

Por fim, registra a consequência: primeiro pacote aceito pela nova raiz, primeira recepção válida em cada ETR amostrado, continuidade de sequência ou da aplicação quando disponível, janela de perda ou duplicação, tráfego não solicitado descartado na consulta interna e idade da dívida restante. Evidência de roteador não deve ser rotulada como saúde da aplicação.

A autoridade de rollback pertence ao mesmo recibo. Conforme a implementação, pode-se restaurar um locator unicast específico, drenar o sucessor, provocar refresh controlado, deslocar o fluxo ou aceitar temporariamente replicação na origem. Este texto não inventa um comando universal; exige que ação, escopo, decisor e validação sejam explícitos.

O lugar da replicação muda o lugar da prova

O rascunho permite replicação dentro do site, em um roteador do underlay, em ETRs ou em ITRs. O underlay multicast mantém mais estado intermediário. O unicast desloca o custo para cópias e banda no site de origem. Prioridade e peso de Map-Reply também podem fazer receptores distintos escolherem ITRs distintos.

A auditoria deve seguir a topologia. A lista de ETRs no ITR é um plano de replicação, não recibo de entrega. Uma árvore (S-RLOC,G) saudável pode combinar várias origens internas. O rascunho observa que um site pode receber tráfego de um fluxo que não solicitou por compartilhar a árvore e descartá-lo por falta de (S-EID,G). O descarte está correto, mas a capacidade comum já foi gasta.

Segurança e resiliência se encontram aqui. Um site malicioso pode provocar tráfego indesejado em sites legítimos da mesma árvore. “O pacote chegou ao ETR” pode significar sucesso, desperdício ou ataque. O estado interno e o conjunto esperado de receptores definem o sentido.

A lacuna de diagnóstico permanece

O detalhamento de locator reachability, certos comportamentos mPITR e o desenho de mtrace para multicast LISP ficam fora do escopo. O rascunho diz que o último ainda deve ser definido com base no Mtrace Version 2. Um diagnóstico genérico de caminho não atravessa sozinho os espaços EID e RLOC.

Cada métrica precisa nomear sua camada. O teste do underlay mostra o caminho RLOC; a inspeção no ITR mostra (S-EID,G); o ETR mostra desencapsulamento e consulta interna; o receptor comprova a chegada útil. Correlacionar tudo pode sustentar uma afirmação de serviço. Usar uma medida no lugar de todas as outras, não.

Cabe ao IETF especificar mecanismo e fronteiras, não produzir uma plataforma universal de observabilidade. Cabe ao operador dizer exatamente o que sua evidência cobre. “O failover anycast funcionou” é uma conclusão sobre o endereço. Recuperação multicast precisa também do estado e do receptor.

Fontes

  1. Rascunho atual de multicast LISP
  2. Histórico do rascunho
  3. Registro da API do Datatracker
  4. Revisão 07 em HTML
  5. Revisão 07 em texto
  6. Diferenças entre as revisões 06 e 07
  7. Grupo de Trabalho LISP
  8. RFC 6831
  9. RFC 9300: plano de dados LISP
  10. RFC 9301: plano de controle LISP
  11. RFC 8059: atributos PIM Join para LISP
  12. RFC 7761: PIM
  13. RFC 8487: Mtrace Version 2
  14. RFC 9776: IGMPv3
  15. RFC 9777: MLDv2
  16. RFC 7799: terminologia de medição
  17. Fonte XML da revisão 07