Resumo

  • Highest-Preference e Lowest-Preference definem a ordem administrativa dos candidatos, partindo da suposição de que eles já podem assumir o papel.
  • Elegibilidade, valor anunciado, DF eleito, programação de BUM/unicast, convergência e experiência do cliente são estados diferentes.
  • Don't Preempt reduz uma segunda troca durante a recuperação, mas pode preservar como DF um PE que deixou de ser a preferência administrativa.

O segundo movimento é uma decisão

No RFC 7432, o DF envia tráfego BUM para o lado multihomed em All-Active e BUM mais unicast em Single-Active. O RFC 8584 trata eleição como descoberta, manutenção da lista de candidatos e cálculo após DF_WAIT. Ser escolhido atribui responsabilidade; não prova sua execução.

O RFC 9785 acrescenta Alg 2, Highest-Preference, e Alg 3, Lowest-Preference. Preference ocupa dois octetos, vai de 0 a 65535 e tem 32767 como padrão. O registro da IANA fixa os dois algoritmos e o bit D de Don't Preempt.

A limitação aparece no próprio requisito: o operador ordena candidatos supondo que todos estejam operationally ready. Portanto, prontidão é uma condição anterior ao número. A Preference não inspeciona Attachment Circuit, instalação de tabela, fila de saída nem entrega na aplicação.

A lista vem antes da preferência

Com AC-DF, um PE só entra como candidato quando suas rotas Ethernet A-D per ES e per EVI são recebidas. Esse passo de elegibilidade impede que uma preferência alta, isolada, autorize um PE sem a sinalização necessária. Ainda assim, a rota recebida não comprova que o data plane terminou de programar o caminho.

Os algoritmos também precisam ser iguais em todo o segmento. Se um PE anuncia Highest e outro Lowest, a operação cai para o algoritmo padrão do RFC 7432. Um inventário que guarda apenas o vencedor perde a explicação do resultado e pode atribuir a Preference uma eleição produzida pelo fallback.

Políticas locais podem variar Preference com largura de banda ou portas operacionais, mas a definição dessas políticas está fora do escopo do RFC 9785. O campo publica uma conclusão local; não audita o detector que a produziu.

Dois valores contam duas verdades

Considere PE3 como DF de maior Preference. Ele falha e PE2 assume. Quando PE3 retorna, uma eleição reversiva devolve a função e cria uma segunda transição. Com Don't Preempt, PE2 pode permanecer.

Depois de boot-timer ou hold-timer, PE3 recebe as Ethernet Segment routes e escolhe um PE de referência. Se sua Preference administrativa superaria o incumbente, PE3 pode anunciar uma Preference operacional in-use igual à do referente e DP=0. PE2 mantém DP=1 e vence o desempate entre valores iguais.

O valor configurado continua correto como intenção. O valor in-use continua correto como estado. Ferramentas de compliance não devem “consertar” automaticamente essa diferença; fazê-lo pode reintroduzir a troca que o modo não reversivo tentou evitar. Mas também não devem apagar a intenção administrativa, pois ela explica a ordem futura.

A troca evita churn, não elimina risco. O incumbente pode já não ser o PE desejado por capacidade ou política. Se o referente falhar, sua rota for retirada, a Preference for mudada de propósito ou surgir Alg conflitante, a eleição muda de novo. Don't Preempt não impede o fallback obrigatório para RFC 7432.

Controle configurável exige prova de autoridade

Overrides por faixa de Ethernet Tag podem dividir o trabalho entre PEs, mas devem ser consistentes em todos eles. Divergência pode causar perda ou duplicação. A configuração de Don't Preempt também deveria coincidir; o RFC não a força e não garante comportamento não reversivo quando ela diverge.

Na segurança, a consequência é direta: quem obtém acesso à configuração pode alterar Preference e influenciar por onde passa a responsabilidade de tráfego. Um Alg conflitante também pode desabilitar a não reversão na prática. Identidade do operador e autorização da mudança pertencem ao recibo técnico.

O RFC 9784 permite usar esses algoritmos em virtual Ethernet Segments. Seus domínios de falha EVC/ENNI, vESI e agrupamentos são outra matéria. Este texto não transforma esse contexto, nem redundância de fontes multicast, em parte do contrato de Preference.

O registro do RFC Editor, o Datatracker e a consulta de errata, sem ocorrência correspondente na data da verificação, documentam o padrão. Não comprovam adoção ou desempenho.