Resumo

  • Os modos Push e Pull descritos em RFC 7067 e RFC 8171 podem reduzir unknown unicast, ARP e ND, mas “não encontrei” só autoriza uma ação forte quando a cobertura completa foi realmente estabelecida.
  • RFC 8302 e RFC 8380 mostram que confiança relativa, envelhecimento, atualização, mobilidade e proteção do canal precisam continuar separados. Um registro autenticado pode ser antigo; um registro completo por configuração pode estar incompleto na prática.

Análise

O custo escondido de não perguntar de novo

O flooding é barulhento, porém contém uma virtude: diante da ignorância, a rede volta a perguntar. Um diretório tenta eliminar parte desse custo ao oferecer a correspondência entre IP, MAC, Data Label e RBridge de saída. No modelo Push, o dado chega antes da necessidade. No modelo Pull, o cliente consulta e pode guardar a resposta.

O ganho surge justamente porque o cliente deixa de perguntar. A mesma propriedade prolonga o erro quando uma máquina virtual muda de rack ou desaparece. O endereço pode permanecer igual e o ponto de saída mudar. Enquanto a resposta anterior estiver em cache, a memória do sistema compete com a topologia atual.

RFC 7067 apresentou em novembro de 2013 o problema e o desenho de alto nível da assistência de diretório em TRILL. Linda Dunbar divide a autoria com Donald Eastlake, Radia Perlman e Igor Gashinsky. É um documento Informational, não uma especificação Internet Standards Track. RFC 8171, Standards Track de junho de 2017, foi escrito por Donald Eastlake 3rd, Linda Dunbar, Radia Perlman e Yizhou Li e define os mecanismos de Push e Pull.

Linda Dunbar também aparece entre os cinco autores de RFC 8302, ao lado de Yizhou Li, Donald Eastlake 3rd, Radia Perlman e Muhammad Umair, e entre os três autores de RFC 8380, com Donald Eastlake 3rd e Radia Perlman. São RFCs Standards Track de 2018. O perfil no IETF Datatracker sustenta essa atribuição coletiva; não prova autoria exclusiva, adoção de mercado nem resultado operacional.

A palavra completo altera o comportamento

Um diretório incompleto pode responder honestamente que não tem dados. Isso não prova que o endereço não exista. Um diretório completo para determinado Data Label faz uma afirmação mais forte: o conjunto deveria conter todas as correspondências relevantes.

RFC 8171 permite que um serviço Push anuncie essa condição. Quando um RBridge recebeu de fato todo o mapeamento, ele pode descartar um destino unicast ausente em vez de inundá-lo. Se a cobertura estiver incompleta apesar da declaração, o ganho de escala vira perda de tráfego.

Assim, completude não é adjetivo publicitário. Ela define a semântica da ausência e amplia o poder do receptor. “Desconhecido nesta fonte” pede outra evidência. “Ausente de um conjunto comprovadamente completo” pode encerrar a busca. Uma API que devolve o mesmo estado para os dois casos apaga a fronteira essencial.

O próprio RFC preserva outra fronteira. Um servidor primário obtém informação por um mecanismo confiável destinado a assegurar frescor, mas o modo de abastecê-lo está fora do escopo. Um secundário pode receber dados de primários. Distribuição consistente não cria observação correta: um orquestrador atrasado pode alimentar todo o sistema com o local anterior.

Resposta positiva e resposta negativa envelhecem

No modelo Pull, clientes mantêm respostas durante uma vida útil. Uma resposta positiva vira problema quando o endpoint muda. Uma resposta negativa vira problema quando um novo endpoint passa a existir. A segunda costuma ser menos visível: o cliente não envia para o lugar errado; simplesmente continua acreditando que não há para onde enviar.

RFC 8171 determina que servidores que usam vida útil maior que zero enviem atualizações para minimizar informação obsoleta. Três métodos controlam o quanto o servidor sabe sobre caches remotos. O método agregado acompanha expirações por Data Label e pode limpar muita coisa. O método mais específico registra quais clientes receberam quais dados positivos ou negativos e até quando. Há um método intermediário entre eles.

A precisão custa estado. Menos acompanhamento no servidor significa mais invalidação ampla e mais trabalho para clientes. Mais acompanhamento permite corrigir exatamente quem ainda pode lembrar a resposta velha. Mesmo assim, o documento admite intervalos curtos em que o servidor já mudou e o cliente ainda não recebeu ou processou a correção.

Por isso, a vida útil é um prazo de confiança, não garantia de estabilidade. Um valor longo maximiza reaproveitamento e aumenta a exposição à mobilidade. Um valor curto obriga novas perguntas e reduz a janela. A escolha precisa ser confrontada com a frequência real de mudanças e com o custo de errar cada tipo de resposta.

Confiança organiza fontes em conflito

RFC 8302 descreve a otimização de ARP e ND com um cache de ligações IP/MAC/Data Label. Os dados podem vir de gestão, diretório ou plano de controle, ou de aprendizado no plano de dados. Essas fontes têm falhas diferentes: ARP e ND sem SEND podem ser forjados; uma base administrativa pode estar atrasada ou mal configurada.

O recurso de nível de confiança dá ao RBridge uma maneira de arbitrar. Dados completos e confiáveis de diretório podem limitar o dano de mensagens forjadas. Dados incompletos ou menos confiáveis podem coexistir com observação local. A implementação define a importância relativa; o RFC não impõe uma verdade universal.

O campo não mede o mundo. Ele registra uma política sobre as fontes. Para ser auditável, essa política deve explicar por que o diretório supera uma observação, quando a observação pode corrigir o diretório e quanto tempo a preferência dura. Caso contrário, “confiança” apenas esconde uma decisão fixa.

A mobilidade revela a qualidade da decisão. RFC 8302 exige remoção da entrada dinâmica local quando o link falha e recomenda envelhecimento sem renovação. Quando a estação migra de um RBridge para outro, o local antigo deve ser substituído e os demais bordes atualizados. A verdade operacional está na transição observada, não no prestígio da fonte.

Quanto mais cedo o dado age, maior o dano possível

RFC 8380 leva a assistência a nós não-RBridge capazes de pré-encapsular tráfego TRILL. Sabendo o RBridge de saída, eles evitam uma etapa de descoberta e reduzem flooding. Também ganham meios de agir como borda antes que a borda normal examine o quadro.

O texto alerta que nós não confiáveis podem forjar nicknames de entrada e saída e endereços MAC, além de aprender informação de topologia. Um ataque entre diretório e nó pode entregar mapeamentos falsos, desviar pacotes e violar políticas sobre destinatários. Autenticação e criptografia são recomendadas, junto com correções, configuração adequada e acesso mínimo.

Essas proteções respondem a perguntas diferentes. Autenticação identifica a contraparte. Criptografia protege o trânsito. Completude descreve cobertura. Confiança ordena fontes. Expiração limita memória. Atualização acompanha mudanças. Nenhuma converte automaticamente um registro antigo em posição atual.

Coordenação fina, verificação forte

A ideia posterior de Lu Heng sobre especificação inicial mínima, decisão futura localizada e adoção voluntária funciona aqui como lente de Sofia Ren. O formato comum deve conter o necessário para interoperar. Política de confiança, cache, fallback e risco permanece com quem opera e arca com o resultado. Não é uma filosofia atribuída aos autores dos RFCs.

A primazia do código em execução oferece o teste final. Se link, tráfego ou mobilidade contradizem o registro, o registro precisa perder prioridade, expirar ou ser corrigido. Um diretório coordena a descrição de reachability; não se torna proprietário dela.

Os documentos não medem adoção, queda efetiva de flooding, perda, convergência ou prevenção de incidentes. Eles tornam mensuráveis as perguntas que vêm antes: a fonte é completa? Quem a abasteceu? Que cliente ainda guarda a resposta? Qual evidência vence um conflito? Quanto tempo levou para uma mudança chegar ao encaminhamento?

O diretório mais perigoso não é o que diz “não sei”. É o que não permite que a rede prove que ele está errado.

Fontes