Resumo

  • RFC 9793 define o atributo BGP opcional e transitivo de código 41 para levar subdomínio, BFR-ID, encapsulamento e próximo salto BIER junto ao prefixo de host de um BFR.
  • O documento pressupõe um domínio BIER alinhado a um domínio administrativo, embora esse domínio possa reunir vários sistemas autônomos. Um roteador de borda compatível deve oferecer política por sessão/grupo EBGP, com BIER negado por padrão.
  • Quando negado, o atributo não pode ser exportado e, se recebido, deve ser ignorado silenciosamente e não propagado. A chegada não comprova permissão, compatibilidade de namespaces, instalação de forwarding nem resultado multicast.

A UPDATE passou na sintaxe; ainda não passou na autoridade

Uma leitura superficial procura um pacote quebrado. A situação mais instrutiva é a contrária: a UPDATE contém um /32 ou /128, o atributo 41, comprimentos corretos e um TLV BIER reconhecível. O roteador entende a declaração. Mesmo assim, na fronteira certa, deve recusá-la.

RFC 9793 usa o BGP para divulgar informação que cresce com a quantidade de BFRs, não com cada árvore multicast. O atributo BIER é opcional transitivo e aparece no registro de parâmetros BGP da IANA como código 41. Para as combinações AFI/SAFI definidas, ele acompanha um prefixo de host que identifica o BFR. O TLV liga um Sub-domain e BFR-ID a dados MPLS ou non-MPLS, e pode incluir um BIER Nexthop.

Dentro do perímetro pretendido, preservar a informação importa. Um non-BFR pode readvertise a rota sem processar BIER. Um BFR pode atualizar nexthop e encapsulamento para subdomínios e BitStringLengths que suporta, obedecendo à troca acoplada definida no RFC. TLVs desconhecidos ou não suportados devem ser preservados; só serem novos não torna a rota malformada.

Na borda administrativa, a lógica muda. O roteador que suporta o atributo precisa de uma política associada à sessão ou ao grupo EBGP. O valor padrão é não permitido. Se a política negar, o BIER attribute não sai. Se chegar do peer, recebe o mesmo destino de um atributo opcional não transitivo desconhecido: quiet ignore e nenhuma propagação posterior.

O bit transitivo não assina um acordo entre operadores

RFC 4271 normalmente permite que um atributo opcional transitivo desconhecido seja retido e levado adiante com o Partial bit. Um opcional não transitivo desconhecido é ignorado. RFC 9793 mantém o type 41 transitivo, mas manda aplicar o segundo resultado quando a política da fronteira não autoriza BIER.

Essa escolha separa três capacidades. O peer consegue codificar o atributo. O BGP consegue carregá-lo. O operador local consegue permitir seu uso. As duas primeiras não fabricam a terceira. Partial tampouco é comprovante de consentimento; ele fala sobre custódia semântica incompleta, não sobre quem aprovou o cruzamento.

A palavra EBGP também exige cuidado. RFC 9793 afirma que o Administrative Domain pode conter vários AS. RFC 8279 admite EBGP como routing underlay em certos cenários. Portanto, uma sessão EBGP pode estar dentro de uma única autoridade operacional ou ligar organizações independentes. O número do AS não resolve sozinho essa classificação.

É por isso que a exceção se prende à sessão ou ao grupo. O padrão fecha; a decisão local abre apenas o caso deliberado. Ainda assim, um allow não prova que os dois lados harmonizaram subdomínios, BFR-IDs, BitStringLengths, label ranges, BIFT-id ranges ou próximos saltos.

Da declaração ao pacote, os recibos são diferentes

O atributo contém material para um cálculo real. Para cada subdomínio, o BFR percorre BFR-prefixes cujo TLV BIER corresponde. Um BFR-ID não zero pode criar ou atualizar uma entrada BIFT. O BIER Nexthop, ou a regra de fallback quando ele falta, determina o BFR-NBR; a faixa de Label ou BIFT-id fornece o encapsulamento. A unicast FIB completa o caminho do underlay.

Mas a cadeia não é automática. Bytes recebidos formam estado declarado. Campos aceitos formam estado parseado. A política efetiva forma estado autorizado. A BIFT derivada é estado calculado. O que a plataforma programou é estado instalado. Captura, contador e receiver formam estado observado e outcome. Nenhum degrau anterior comprova o seguinte.

Os erros confirmam essa separação. Um problema de Length exige attribute discard conforme RFC 7606. TLVs repetidos para o mesmo Sub-domain podem invalidar o atributo inteiro; BitStringLengths repetidos ou ranges sobrepostos invalidam dados específicos. Dois prefixes com o mesmo BFR-ID não zero em um subdomínio não podem entrar no cálculo. Policy allow não corrige semântica conflitante.

Mesmo uma BIFT calculada deixa perguntas abertas. RFC 9793 não define como escolher ou estabelecer o tunnel para um BIER Nexthop não conectado diretamente. A tabela de controle não comprova hardware. A FIB não é packet trace. Um receiver count sem escopo não demonstra o serviço pretendido.

O domínio vizinho pode usar os mesmos números para outra realidade

Os BFR-prefixes costumam ser loopbacks distribuídos dentro do AD e não precisam sair para fins BIER. RFC 9793 alerta que, se saírem com o atributo e o AD vizinho também usar BIER, dois domínios que deveriam ser independentes podem ser unidos incorretamente, provavelmente com configuração conflitante e consequentes riscos de segurança e operação.

Não é evidência de um incidente real. O RFC não nomeia fabricante, rede, ataque, outage, packet loss ou cliente. Ele descreve um risco de composição: Sub-domain 0, BFR-ID e faixas de encapsulamento são locais. Igualdade numérica entre domínios não representa coordenação nem autorização.

O plano de dados em RFC 8279 preserva a mesma fronteira. Um pacote encapsulado BIER não passa diretamente de um domínio BIER a outro; precisa ser decapsulado e entregue ao multicast flow overlay, podendo o equipamento atuar como BFER de um lado e BFIR do outro. É uma passagem explícita entre contextos, não uma fusão silenciosa do plano de controle.

O erratum verificado 8463 corrige o exemplo da seção 6: quando a rota de BFER1 não traz BIER Nexthop, BFR2 usa o BFR-prefix de BFER1, não o de BFR1. A correção não altera a regra de borda. A página do RFC Editor e o Datatracker do IETF comprovam o status do documento, não uma implantação.