Resumo

  • Na revisão 34, um par compatível que recebe disponibilidade física de 0% deve tratar todas as rotas associadas ao Site-ID como indisponíveis para encaminhamento, efeito equivalente a retirá-las individualmente sem transmitir cada retirada.
  • As mesmas rotas podem permanecer válidas no BGP comum. Origem, geração do mapa, aplicação local, RIB, FIB, fluxo e resultado do serviço são fatos diferentes e precisam de recibos próprios.

Às 09h14, um site de borda perde o último servidor capaz de atender. O roteador de saída envia um único UPDATE BGP com um Site-ID e disponibilidade física zero. Dezenas de prefixos continuam na tabela BGP do ingresso, mas deixam de ser candidatos ao tráfego guiado por metadados. Não há uma sequência de withdrawals. A equipe de routing enxerga caminhos presentes; a plataforma de serviço enxerga um site ausente.

Essa divergência é o ponto operacional da revisão 34 de BGP Extension for 5G Edge Service Metadata. O texto foi aceito em 25 de setembro de 2026 e traz 23 de setembro na capa. Ainda é um Internet-Draft do grupo IDR em I-D Exists. A capa indica Standards Track, mas o Datatracker não mostra Intended RFC status. Não há shepherd, Area Director responsável ou telechat; o marco de julho de 2027 prevê WGLC. Isso não equivale a RFC, código IANA atribuído, implementação, interoperabilidade ou implantação.

Uma atualização curta herda um conjunto grande

O rascunho define o Edge Metadata Path Attribute como opcional e não transitivo. Uma rota associa um prefixo de serviço a um Site-ID de 16 bits. Uma atualização autônoma anuncia propriedades dinâmicas do site sem repetir os dados em cada rota. Nessa forma, o NLRI é o loopback do roteador de saída, RouteFlag-I vale zero e o valor alcança rotas já vinculadas ao Site-ID. Quando RouteFlag-I vale um, a mensagem cria a associação e o percentual não é usado como disponibilidade.

A revisão 34 torna o zero incisivo: o speaker compatível deve considerar indisponíveis para encaminhamento todas as rotas associadas. O efeito é descrito como equivalente ao withdrawal de cada rota, embora as retiradas não sejam transmitidas. Para o par que não oferece suporte a Edge Metadata, ainda são necessárias retiradas BGP comuns.

Portanto, “equivalente” descreve o efeito de seleção dentro do mecanismo, não a identidade entre estados. O rascunho também permite que uma rota excluída pela seleção com metadados permaneça válida para alcance BGP ordinário. O prefixo segue no RIB, embora não possa atender uma classe de serviço. A separação reduz churn e não confunde saúde da aplicação com reachability; também significa que sessão verde e rota presente não provam disponibilidade do serviço.

O zero depende de associações anteriores

A mensagem autônoma não lista os prefixos atingidos. Seu fan-out vem do histórico de associações rota–Site-ID mantido no receptor. Se um ingresso mapeou 42 rotas ao Site-ID 711 e outro apenas 41 por ter perdido uma atualização antiga, ambos podem interpretar corretamente o mesmo zero e desabilitar populações diferentes.

O registro mínimo não pode ser apenas “Site-ID 711 = 0 recebido”. Ele deve identificar uma geração do mapa: chaves de rota incluídas, início de vigência, speaker que originou e pontos de decisão que reconheceram a geração. Uma contagem e um hash do conjunto resolvido permitem comparar intenção e execução sem publicar todas as escolhas internas no protocolo.

Geração, confirmação e hash são recomendações operacionais deste artigo, não exigências da revisão 34. O rascunho define comportamento do protocolo, não um sistema de recibos para toda a frota. Telemetria local, estado do controlador ou logs assinados podem cumprir a função. A escolha pode ser local; a pergunta “quais rotas este zero deveria atingir?” não pode ficar sem resposta.

Autorizar a origem evita um desligamento remoto

O receptor aceita a atualização autônoma somente do egress correspondente ou de um route reflector autorizado cujo Originator-ID identifique esse egress. É uma proteção decisiva: um zero forjado pode tornar indisponíveis todas as rotas associadas e causar negação de serviço.

Validade da sessão BGP e autorização da mensagem não são o mesmo recibo. Um reflector pode ser vizinho legítimo e carregar Originator-ID inesperado. O loopback de saída pode estar acessível, embora a sessão tenha outra função. O registro precisa preservar par autenticado, AFI/SAFI, Edge Metadata Processing Capability negociada, identidade do egress, Originator-ID quando houver, Site-ID, bytes do atributo e decisão da política.

A capacidade é bilateral por AFI/SAFI. O atributo é opcional e não transitivo; NO_ADVERTISE, o sub-TLV AS-Scope e filtros comuns delimitam propagação. Sub-TLVs desconhecidos são ignorados, e ausência jamais deve virar zero. Essas regras limitam erros, mas não demonstram que todo ingresso planejado negociou suporte nem que os pares incompatíveis receberam withdrawals convencionais.

Medição, anúncio e aplicação têm relógios próprios

Site Physical Availability aceita valores de zero a 100; valores fora da faixa são ignorados. O rascunho separa intervalo de medição e de anúncio, recomenda um mínimo padrão de 30 segundos salvo outra configuração e menciona dampening ou histerese. A afinidade de fluxo é específica da implementação: um fluxo já selecionado pode continuar no mesmo egress até que ele fique inalcançável.

O site pode medir zero às 09:14:00, anunciar às 09:14:12, ser aplicado em um ingresso às 09:14:13 e ainda manter um fluxo aderente até 09:15:00. Chamar tudo de “evento zero” elimina a linha do tempo capaz de explicar o que o cliente viu.

A atualização autônoma também não resolve next hop. Ela altera elegibilidade para seleção do serviço; não afirma que o loopback ficou inalcançável ou que houve convergência BGP. A cadeia de prova precisa separar medição, origem autorizada, geração do mapa, capacidade, recebimento, população resolvida, política, RIB, FIB, tratamento de fluxos e resultado do serviço.

Um mínimo comum pode preservar escolhas locais

A doutrina de Heng Lu para uma especificação inicial mínima recomenda padronizar somente o necessário à coordenação e manter escolhas futuras ou locais fora do núcleo. Aqui, identidade do site, semântica de disponibilidade, origem e escopo podem formar esse mínimo. O algoritmo de medição, o ranking e o fallback permanecem locais. A primazia do código em execução exige, então, evidência na fronteira onde significado de protocolo vira decisão de encaminhamento.

Na implantação, exija identificador da geração, contagem e hash das rotas afetadas, recibo de aplicação por ponto de decisão e fluxo canário na transição para zero. São controles propostos por esta análise, não requisitos escritos no draft. Eles permitem verificação independente sem impor arquitetura centralizada.

O zero é poderoso porque substitui muitas retiradas. Quanto mais compacto o comando, mais precisos devem ser os recibos. O RIB pode dizer a verdade, o mecanismo de metadados outra e o usuário perceber uma terceira. A operação só é confiável quando essas verdades podem ser reconciliadas.

Fontes