Resumo

  • O RFC 4098 encerra a medição quando o DUT conclui as ações de plano de controle exigidas pelo evento declarado. O RFC 7747 espera todas as mudanças da FIB e exige que todo o tráfego encaminhado no ensaio passe a usar a rota proposta.
  • Susan Hares foi uma de cinco autoras e autores em cada RFC, ambos informativos. A ligação biográfica não transforma Hares na inventora exclusiva das metodologias nem atribui a ela controle sobre consenso, produtos ou redes.

A perda de pacotes é um registro, não um detalhe

Imagine uma retirada e uma rota alternativa já conhecida. O processo BGP recebe o UPDATE, aplica policy, escolhe um novo best path e o anuncia. A Loc-RIB fica estável. Um observador de controle pode marcar o fim dessa sequência com rigor.

Enquanto isso, o caminho de forwarding pode atravessar outra fila. Entradas descem para a FIB, adjacencies mudam, prefixos são atualizados em grupos. O tester ainda vê perda ou reordenação. O registro do BGP e o registro dos pacotes não se contradizem; apenas terminam em camadas diferentes.

O problema aparece quando o primeiro fim é usado como atestado do segundo. Uma mensagem recebida não prova decisão. Uma decisão na RIB não prova programação. Uma confirmação de programação não prova que a população de tráfego observada chegou sem dano.

O RFC 7747 faz do dano uma parte explícita do resultado. A tabela de relatório registra pacotes oferecidos e encaminhados, connectivity packet loss, convergence packet loss, pacotes fora de ordem e duplicados. Ela é preenchida para o evento inicial e para a reversão. O tempo interessa, mas divide o espaço com o efeito.

O relógio visto do lado de fora

Rajiv Papneja, Bill Parise, Susan Hares, David Lee e Ilya Varlashkin publicaram o RFC 7747 em 2016. O documento define FIB ou data-plane convergence como a conclusão de todas as alterações da FIB, de modo que todo o tráfego encaminhado passe a seguir a nova rota. Ele diferencia esse estado da convergência de plano de controle no mesmo nó e declara que metodologias de controle estão fora de seu escopo.

“Todo o tráfego” pertence ao conjunto do teste. Não é uma afirmação sobre todos os pacotes da Internet. O método usa um DUT BGP e topologias simples de três ou quatro nós para iBGP, eBGP e eBGP multihop. O desenho reduz variáveis para repetir a experiência. Não inclui automaticamente route reflectors, túneis, resolução recursiva, múltiplas placas ou a distribuição de fluxos de uma aplicação real.

O tester mantém tráfego durante o evento e deriva o tempo da perda observada. A distância entre dois pacotes sucessivos oferecidos a uma rota define a melhor precisão possível. Se a rota é sondada a cada 25 milissegundos, não existe evidência externa para localizar a recuperação em um intervalo menor. Mais casas decimais não criam os pacotes que não foram enviados.

O offered load também tem peso. Uma sonda muito esparsa perde transientes; uma carga intensa pode alterar a disputa por recursos no DUT. Por isso o tamanho, a taxa, o subconjunto de rotas e o sampling interval são dados da experiência, não decoração metodológica.

O outro relógio mede trabalho legítimo

O RFC 4098 foi publicado em 2005 por Howard Berkowitz, Elwyn Davies, Susan Hares, Prakash Krishnaswamy e Michael Lepp. Ele normaliza a linguagem para medir a convergência eBGP do plano de controle de um único dispositivo. Seu foco inicial é a chegada, o processamento e a propagação da informação de roteamento.

Sob uma condição de teste, o dispositivo converge quando conclui todas as ações de controle necessárias para reagir. Em um exemplo com troca da melhor rota de um prefixo, a conclusão pode ocorrer quando a rota é anunciada aos peers downstream. É um fim correto para a pergunta formulada.

O texto também marca o que não mede. iBGP, o início do forwarding baseado em informação de controle já convergida e vários dispositivos interagindo ficariam para trabalhos posteriores. Portanto, o RFC não prometeu que a última mensagem de controle coincidiria com o último pacote afetado.

Lido ao lado do RFC 7747, o documento não perde valor. Ele fornece a primeira timestamp da cadeia que interessa: quando chegou o evento, quando terminou a decisão e quando terminou a propagação. A etapa seguinte precisa de outra instrumentação.

Não existe uma “tabela BGP” sem demografia

O RFC 4098 chama route mixture de demografia do conjunto de rotas. Distribuições de AS path, atributos e tamanhos de prefixo, route packing e intervalos de UPDATE moldam o estímulo. Um conjunto simples pode revelar limite de processamento. Uma mistura semelhante à Internet pode melhorar a relevância operacional, mas modelá-la fielmente era reconhecido como problema de pesquisa.

Policy transforma a pergunta. Minimal policy que aceita tudo não equivale a filtros longos, reescrita de atributos ou muitas rotas descartadas. Número de peers, routes por peer, churn, flap damping, interação com outros protocolos, forwarded traffic, timers, TCP e autenticação também influenciam.

O RFC 7747 converte essa lista em disciplina. A linha de base usa minimal policy; qualquer outra configuração deve ser descrita. Opções devem ser desligadas e defaults preservados salvo exceção documentada. Interface media e throughput permanecem iguais entre iterações do mesmo caso.

O relatório inclui topologia, evento, sessões e vizinhos, rotas únicas e repetidas, IGP, mixture, packing, policy e recursos de segurança. Acrescenta packet size, load, sampling, failure detection, hold time, MRAI, MAOI, keepalive, ConnectRetry e parâmetros TCP. Um resultado separado de tudo isso não pode ser reproduzido.

Repetir várias vezes é recomendado porque expiração de timers, CPU scheduling e outros fatores variam. Para fazer média, os parâmetros devem continuar idênticos. A média precisa viajar com número de trials, dispersão e limite de resolução. Caso contrário, ela apenas torna a incerteza menos visível.

A disciplina de caixa-preta veio de outra família

O RFC 7747 usa o rate-derived method do RFC 6412. Os RFCs 6412 e 6413 tratam a convergência de data plane de IGPs link-state e organizam observações externas black-box, além de métodos baseados em perda, taxa e rota. Eles não prescrevem BGP. O que fornecem é uma herança de mensuração: observar fora do DUT o efeito que se afirma ter ocorrido fora.

O RFC 1242 oferece terminologia geral de benchmarking; o RFC 2544 descreve uma bancada em que o tester envia tráfego pelo DUT e verifica os pacotes recebidos. Essas referências dão forma ao laboratório. Não autorizam transformar seu número em SLA nem dizer que o RFC 2544, sozinho, prova convergência BGP.

O RFC 4271 define o substrato do protocolo: BGP troca reachability information, processa UPDATEs e organiza Adj-RIB-In, Loc-RIB e Adj-RIB-Out sob policy do AS. Essas estruturas provam estado e decisão de controle. FIB e packets continuam sendo afirmações distintas.

Susan Hares dentro da medida certa

O perfil atual do IETF Datatracker identifica Susan Hares, também chamada Sue Hares, e oferece uma fotografia pública. A página a lista como chair de IDR e secretária do BGP Directorate, além de relacionar dezessete RFCs, entre eles 4098 e 7747.

Isso sustenta uma afirmação humana limitada: Hares contribuiu para dois documentos coletivos, separados por onze anos, que permitem diferenciar o término do controle e o término do forwarding. Não sustenta autoria exclusiva, intenção individual contínua nem autoridade sobre o consenso, implementações ou decisões locais de rede.

Autores e comunidade publicam o método. Fabricantes escolhem como software e hardware trocam estado. Laboratórios escolhem inputs. Operadores definem policy. Responsáveis de serviço decidem qual perda é aceitável. O mérito do método está justamente em não permitir que uma dessas autoridades fale por todas as outras.

Como guardar a transição para poder explicá-la

Um event ID comum precisa ligar withdrawal, anúncio, falha ou reset às rotas recebidas, à versão de policy e à razão do best path. A mesma linha temporal registra o fim do processamento e da propagação, a mudança da FIB por grupo de prefixos e a sequência externa de packets. A reversão repete o caminho.

Se o gap entre controle e tráfego for menor que a cadence, o resultado correto é “não distinguível nesta resolução”. Se for grande, a investigação ainda não deve culpar automaticamente BGP; programação, recursive resolution, hardware e o tester continuam candidatos. A separação de relógios melhora a causalidade porque impede um nome de fechar o caso cedo demais.

Uma coluna única convergence_time perde informação de forma permanente. Melhor preservar o evento, as condições e cada fim. O UPDATE prova o que chegou; a RIB prova o que foi escolhido; a FIB prova o estado que a implementação declara; os pacotes provam apenas o que foi observado na população oferecida. A cadeia é confiável quando ninguém excede essa autoridade.

Fontes