Resumo

  • A RFC 9722 leva um Service Carving Time (SCT) absoluto na rota Ethernet Segment e coordena PEs com capacidade T em torno desse alvo; um SCT válido comprova apenas a declaração do emissor.
  • Uma recuperação dita sincronizada requer evidências de relógio, recebimento, capacidades, timers, programação DF/NDF e tráfego, todas ligadas à mesma geração.
  • “Sem perda” é resultado do plano de dados do cliente. Não decorre de uma atualização BGP, de uma eleição concluída nem de um painel sem alarmes.

Um horário combinado não é o resultado

Um PE EVPN volta de uma falha, descobre os parceiros de multihoming, soma um período de espera à hora local e anuncia o SCT na Ethernet Segment Route. Os pares ganham um horário comum para a eleição DF. Naquele instante, porém, um ASIC pode continuar instalando filtros, outro relógio pode estar alguns milissegundos distante e um terceiro PE talvez ainda não tenha recebido a rota. O controle pode parecer coerente enquanto pacotes são perdidos, duplicados ou entram num laço breve.

Publicada como Standards Track em maio de 2025, a RFC 9722 atualiza a RFC 8584. Ela troca a corrida entre expirações locais por um instante futuro compartilhado. Torna a transição programável, mas não a converte em transação distribuída nem em teste de aceitação do serviço.

As duas bordas perigosas permanecem. Se o novo DF encaminha antes de o antigo parar, surgem duplicação ou loop. Se o antigo para primeiro, surge um black hole. Aumentar a descoberta reduz precipitação e prolonga a indisponibilidade. A RFC 9722 coordena quando; não observa prontidão.

O conteúdo real do SCT

O SCT fica numa BGP Extended Community da Ethernet Segment Route, RT-4. A IANA atribui à Service Carving Time o subtipo 0x0F da Transitive Opaque Extended Community. O valor é um timestamp NTP abreviado: 32 bits de segundos e os 16 bits superiores da fração, com granularidade de aproximadamente 15 microssegundos. A era NTP não é transportada.

O PE calcula SCT a partir da sua hora atual mais o período de descoberta. Portanto, o recebimento válido mostra apenas que o emissor declarou um “agora” local e uma janela. Não prova correção do relógio, era e offset comuns, chegada tempestiva do BGP ou conclusão da programação do hardware.

O bit 3 de DF Election Capabilities é a capacidade T. Todos os PEs do segmento precisam anunciá-la. Ao detectar um par sem T, os participantes retornam imediatamente ao processo básico e cancelam o atraso SCT. Assim, membresia é evidência: vale o conjunto observado naquele segmento e naquela geração, não um inventário anterior.

Receber pode resultar em descartar

O receptor compara SCT com sua hora. Descarta um valor passado e também um deslocamento futuro maior que seu peering timer local; nos dois casos considera que a eleição do par já ocorreu. A regra limita datas obsoletas ou distantes, mas implementações corretas podem agir de modo diferente se seus relógios ou parâmetros divergirem.

O registro de incidente deve guardar RT-4 bruta, hora de chegada, SCT interpretado, offset calculado, limite local e decisão de aceitar ou rejeitar para cada PE. “Rota BGP recebida” apaga a bifurcação central. Um campo bem formado pode ser rejeitado; um aceito pode depender de um relógio depois considerado ruim.

Em recuperações concorrentes, a RFC 9722 ordena os SCTs e faz uma única eleição no maior, isto é, no mais tardio. Ações anteriores são canceladas ou movidas. A regra depende de todos verem o mesmo conjunto a tempo. Candidatos, ordem, timer substituído e razão do máximo devem permanecer; o valor final sozinho não revela rota atrasada nem timer cancelado que disparou.

Confiança no relógio exige recibos

A RFC 5905 descreve qualidade NTP por offset, delay, dispersão, jitter e root distance, não por uma luz “sincronizado”. A RFC 8633 recomenda ao menos quatro fontes independentes e diversas quando a hora exata importa, além de monitoramento contínuo. Fontes múltiplas ainda podem compartilhar falhas ou divergir por leap smear. A RFC 8915 autentica servidor e troca NTS e resiste a replay; não certifica a correção objetiva da hora.

Uma declaração de confiança precisa das fontes, estado de seleção, offset, root distance, dispersão, jitter, estado leap, última atualização e qualquer step ou slew no intervalo. “NTP ativo” é condição do processo, não limite de diferença entre PEs.

A RFC 9722 adota skew configurável, 10 ms por padrão. Um PE que vai de DF a NDF aplica NDF em SCT − skew; o resultado da eleição é aplicado em SCT. A janela busca evitar sobreposição, mas a largura segura depende de escala, hardware e precisão. Padrão não é medição. São necessárias distribuições observadas do erro do relógio, processamento de rota, cálculo e programação.

A função ainda precisa chegar ao silício

O algoritmo gera um papel. O software precisa transformá-lo em regras por VLAN ou Ethernet Tag, enviá-las às placas e confirmar a ativação. Uma API pode responder antes da tabela; line cards podem terminar em momentos diferentes; centenas de serviços podem atravessar uma fila sem atomicidade.

Para cada serviço, guardem-se decisão, envio da programação, confirmação de hardware e primeiro estado de encaminhamento observado, além de DF antigo e novo, segmento, VLAN ou tag, geração e erro. Um único “DF convergiu” esconde a cauda de clientes em black hole ou envio duplo.

Os pacotes fecham a cadeia. Numa janela declarada, sondas bidirecionais ou telemetria numerada contam lacunas, reordenação, duplicatas e caminhos imprevistos. Onde loop é possível, observam-se entrada e saída. Ausência de reclamação não é perda zero; uma amostra só sustenta afirmações sobre seu fluxo, seus pontos e seu período.

Fontes

Fontes primárias: RFC 9722, registro RFC Editor, IETF Datatracker, RFC 8584, RFC 7432, RFC 5905, RFC 8633, RFC 8915 e registro IANA.