Resumo

  • O RFC 10005 define uma Extended Community de BGP com quatro octetos em ponto flutuante, expressos em bytes por segundo, mas deixa a obtenção do valor e o algoritmo de balanceamento fora do escopo.
  • Zero, ausência, múltiplas cópias, transitividade e troca de next hop exigem decisões locais. O atributo válido não comprova capacidade disponível, pesos instalados nem vazão entregue.
  • Pradosh Mohapatra é um dos seis autores. A contribuição coletiva cria um portador interoperável e restrito; a operação precisa ligar proveniência, política receptora, FIB e resultado.

No início da janela, o operador recebe dois valores não nulos e calcula a proporção esperada. O comando do daemon mostra a mudança. O ticket ganha uma captura de tela verde. Só que a plataforma dispõe de um número limitado de buckets, preserva fluxos existentes e confirma a programação alguns minutos depois. Até lá, “2:1” descreve apenas a intenção de um componente.

Mesmo após a instalação, meia dúzia de fluxos grandes pode fazer a divisão de bytes divergir da proporção de buckets. E mesmo que os bytes sigam 2:1, os dois caminhos podem estar com filas e perda. A cada etapa, uma evidência correta responde a uma pergunta menor do que o relatório costuma sugerir.

Publicado no Standards Track do IETF em junho de 2026, o RFC 10005 especifica a BGP Link Bandwidth Extended Community. Pradosh Mohapatra, Reshma Das, Satya Mohanty, Serge Krier, Rafal Jan Szarecki e Akshay Gattani assinam o documento. Ele uniformiza formato e tratamento, mas não transforma o campo em medidor universal de capacidade.

O número chega sem a história que o produziu

A Community pode ser transitiva, tipo 0x00, ou não transitiva, tipo 0x40, sempre com subtipo 0x04. São dois octetos de Global Administrator e quatro de Local Administrator. Estes quatro codificam um IEEE 754 de precisão simples em bytes por segundo.

Bytes por segundo não são bits por segundo. Uma interface que mostra Gbit/s multiplicou por oito, ajustou a escala e provavelmente arredondou. O recibo deve conservar bytes brutos, valor decodificado, unidade original e transformação visual. Do contrário, a tela não pode ser reconciliada com a rota durante um incidente.

Mais importante, o campo não diz qual grandeza está sendo transportada. Pode ser taxa nominal de interface, agregado remoto, medição, configuração, preferência ou peso derivado da quantidade de servidores. O RFC declara fora de escopo o cálculo ou a determinação do valor.

Por isso, cada anúncio precisa de um registro paralelo: semântica controlada, sistema de origem, método, instante de observação, validade e responsável. Dois números na mesma unidade não são automaticamente somáveis. Um pode representar capacidade remota; outro, o gargalo local.

O Internet-Draft draft-ietf-bess-ebgp-dmz-10, de abril de 2026, ilustra a distinção, mas segue como trabalho em andamento. Um valor remoto de 70 Gbit/s pode chegar por um enlace local de 50 Gbit/s. A função do receptor limita a contribuição. O exemplo orienta perguntas operacionais; não acrescenta uma garantia normativa ao RFC 10005.

O administrador de dois octetos não autentica a origem

O Global Administrator deveria carregar o ASN do roteador que anexa a Community, mas pode conter qualquer valor de dois octetos. Um ASN de quatro octetos precisa aparecer como AS_TRANS. O campo não muda o uso ou a semântica do atributo.

Logo, ele não assina quem mediu, aprovou ou possui a suposta capacidade. A identidade precisa vir da sessão, do vizinho, da família de endereços, do domínio administrativo e do evento que aplicou a política. Promover dois octetos a prova de autoridade cria uma certeza que o protocolo não oferece.

A escolha entre transitiva e não transitiva também merece recibo. Em uma transição, implementações antigas podem entender apenas uma forma. Uma cópia recebe atualização; outra fica velha. Adiante, o receptor encontra valores diferentes e produz pesos inadequados. A observabilidade deve comparar tipo, valor bruto e idade das duas cópias, em vez de esconder uma delas no painel.

Informação de capacidade ainda pode ser sensível. O RFC recomenda filtragem quando a rota sai do domínio administrativo ou segue para rede não confiável. A política precisa deixar prova por fronteira: versão, rota atingida, valor removido ou mantido e exceção autorizada.

Trocar o next hop escolhe um novo verbo

Quando um speaker altera o next hop ao reanunciar a rota, pode remover, preservar ou regenerar a Community. A implementação deve mostrar o padrão e permitir override por sessão. Sem mudança de next hop, não deveria alterar o atributo.

Remover encerra a confiança no valor anterior. Preservar transporta a declaração de cima sem criar evidência local. Regenerar calcula uma nova declaração. O resultado pode ter os mesmos quatro octetos e, ainda assim, possuir origem, relógio e responsável diferentes.

Um registro de transformação deve guardar next hop antigo e novo, valor de entrada, ação, insumos locais, versão da política, saída, horário e operador. Sem isso, o último valor apaga as decisões intermediárias.

Essa é uma fronteira de agência. A origem define um significado; o intermediário pode transportá-lo ou alterá-lo; o receptor combina valores; a plataforma programa pesos; a operação observa efeitos. Um dashboard que conserva só a saída desloca responsabilidade para ninguém.

Zero é um sinal, não um vazio

Zero é válido e pode ser anunciado durante manutenção. O receptor decide o efeito: excluir o caminho, voltar à divisão igual ou aplicar outra regra. Uma coleção em que todos os caminhos valem zero também não tem uma interpretação universal.

Ausência é outro estado. Se um dos multipaths não tiver Community válida, a divisão igual é o padrão, salvo configuração diferente. Valores negativos não deveriam ser originados e são ignorados. Um positivo fora da validade é stale, mesmo que continue bem formado.

Misturar zero, missing, inválido e stale em um mesmo unknown impede agir. Zero pode pedir drenagem. Missing pode indicar incompatibilidade. Inválido pode revelar defeito na origem. Stale pode apontar para um filtro de churn. Cada caso tem dono e rollback próprios.

Se a rota trouxer várias Link Bandwidth Communities, o padrão para balanceamento ponderado é usar a menor, inclusive zero, embora a configuração possa mudar a preferência. O registro precisa guardar todas as candidatas e a regra de seleção.

Peso calculado, FIB e tráfego são recibos diferentes

Quando todos os caminhos contribuintes têm valor válido e não nulo, os números ou suas razões podem orientar o balanceamento. O algoritmo fica fora do RFC, e o valor não deveria participar da seleção do best path BGP. Ele atua depois que os caminhos elegíveis foram definidos.

O software receptor pode calcular 3:7. A FIB pode aproximar a relação. O ASIC pode preservar flows. A distribuição real depende do hash e do tamanho dos fluxos. Por isso, quatro estados devem compartilhar uma geração: Communities aceitas, pesos calculados, pesos instalados e tráfego por caminho.

Depois entram os indicadores de serviço. Bytes e pacotes não substituem perda, latência, fila e congestão. Uma razão realizada pode estar perfeita em dois enlaces saturados. Interface line rate, gargalo alcançável, headroom atual e throughput entregue são substantivos distintos.

O princípio do código em funcionamento exige olhar a execução, não confiar apenas no rótulo do padrão. A configuração prova autorização; o processo prova seleção; o hardware prova instalação; a telemetria prova efeito. Nenhum recibo fala pelos demais.

Menos churn pode significar mais idade

Mudanças rápidas de valor afetam estabilidade e operações. O RFC recomenda limitar churn. Thresholds e timers protegem o protocolo, mas separam o relógio da fonte do relógio do anúncio.

Registre observação, decisão, envio, recebimento, cálculo e instalação. Preserve mudanças suprimidas. Caso contrário, um valor medido há dez minutos parece novo porque acabou de cruzar BGP.

O monitor deve comparar idade com validade e registrar a regra ao expirar: divisão igual, isolamento, último valor com alerta ou retirada. Estabilidade não pode significar que evidência antiga continua comandando o hardware sem dono.

A contribuição de Pradosh Mohapatra tem limite verificável

O RFC 10005 registra Pradosh Mohapatra na Google LLC e o coloca entre seis autores. Na captura de 1º de setembro de 2026, o perfil oficial do Datatracker ligado ao trabalho listava onze RFCs, mas usava a grafia anterior “Prodosh Mohapatra”. O RFC e a página pública do ipSpace usam “Pradosh Mohapatra”, mantido aqui como identidade canônica.

A biografia datada do ipSpace descreve passagens anteriores por software de roteamento na Cumulus Networks e na Cisco. Ela fornece contexto de identidade, não demonstra função atual além da afiliação do RFC, controle do consenso do IETF ou responsabilidade por uma rede em produção.

Uma análise centrada em pessoa não deve transformar seis autores em um herói. O valor de observar Mohapatra está no contorno da contribuição: ele e os coautores tornaram um campo interoperável sem fingir que sua semântica local fosse uma verdade global de capacidade.

Montar o recibo de ponta a ponta do valor

Comece por rota, família, vizinho, domínio, tipo, Global Administrator, bytes, valor em bytes por segundo e conversão. Una semântica, origem, método, tempo, validade e responsável. Em cada troca de next hop, guarde remover, manter ou regenerar com entrada e saída.

Para agregação, preserve componentes, fórmula e tratamento de zero, ausência e inválidos. Para recepção, preserve a política e a razão. Para execução, FIB, confirmação do hardware e tráfego. Feche com perda, latência, filas, alarmes, decisão, rollback e limpeza de stale.

Assim, o atributo continua pequeno e útil. BGP prova o anúncio; a política prova a interpretação; a FIB prova a instalação; o tráfego prova o resultado. Capacidade disponível passa a ser conclusão auditável, não apelido otimista para quatro octetos.

Fontes