Resumo

  • O registro atribuído a Susan Hares nas RFCs 1745, 4271, 8241 e 8242, somado à responsabilidade atual no IDR, conecta quatro superfícies de controle: seleção local de rotas, passagem entre protocolos, autorização de clientes programáticos e ciclo de vida do estado efêmero.
  • Esses documentos definem requisitos e comportamentos comuns, não resultados garantidos: consenso da IETF, coautores, implementadores, fornecedores e operadores mantêm responsabilidades distintas, enquanto seu valor duradouro está em tornar legível uma cadeia de evidências que inclui informação recebida, elegibilidade, preferência, resolução do próximo salto, seleção local, autorização de exportação, identidade de quem escreve, arbitragem de conflitos, retirada e reconciliação após falha parcial. Nenhuma assinatura individual controla o BGP, uma configuração local ou a continuidade observada de uma rede.

Atribuir uma contribuição sem personalizar um sistema distribuído

O perfil da IETF de Susan Hares, que também registra o nome Sue Hares, liga uma pessoa identificável a um conjunto coerente de documentos técnicos. A RFC 1745 a lista entre três autores. A RFC 4271 a lista entre três editores. A RFC 8241 é atribuída a Hares, Daniel Migault e Joel Halpern, enquanto a RFC 8242 é atribuída a Jeffrey Haas e Hares. A apresentação atual do grupo Inter-Domain Routing também a inclui entre os responsáveis.

Essa continuidade fornece uma base primária suficiente para uma análise técnica centrada em uma pessoa. Ela não transforma o sistema em propriedade pessoal. As RFCs examinadas são trabalhos coletivos, com coautores, editores, debate em grupo, revisão e dependência de experiência de implementação e operação. Um nome na autoria estabelece participação; não estabelece controle exclusivo sobre desenho, adoção ou resultado.

A fronteira é especialmente importante no BGP. O protocolo conecta sistemas autônomos justamente porque eles não compartilham uma única administração técnica. Uma RFC pode definir mensagens, atributos, estados de sessão e comportamento observável entre vizinhos. Ela não decide relações comerciais, filtros de importação, valores de LOCAL_PREF ou respostas operacionais a uma perda de conectividade.

Implementadores convertem requisitos em código. Fornecedores integram o código em produtos. Operadores escolhem configuração e implantação. A rede em execução expõe as consequências. Misturar essas camadas em uma narrativa pessoal transforma participação documentada em uma afirmação não comprovada de autoridade sobre resultados.

O cuidado oposto também importa. O caráter coletivo não elimina a contribuição individual. Hares pode ser associada com precisão aos documentos e aos problemas em que aparece. As decisões posteriores, porém, devem permanecer com os atores que realmente as tomam. Atribuição rigorosa preserva tanto o crédito quanto os limites.

O fio técnico que une o conjunto é específico. A RFC 4271 separa informação recebida, seleção local e anúncio de saída. A RFC 1745 limita redistribuição entre roteamento externo e interno. A RFC 8241 exige identidade, função, canal protegido e prioridade. A RFC 8242 define temporalidade, conflitos e ausência de rollback automático. O controle fica visível sem ser centralizado.

As fontes também limitam declarações de eficácia. Elas não provam que todos os fabricantes implementaram cada requisito, que operadores usam as mesmas políticas ou que um mecanismo reduziu incidentes. Essas conclusões exigiriam dados de implementação, configuração e observação. O registro de Hares ajuda a identificar quais evidências procurar.

RFC 4271: a política começa em um protocolo limitado

A RFC 4271 descreve o BGP como um protocolo de roteamento entre sistemas autônomos cuja função principal é trocar informações de alcançabilidade. Um anúncio associa destinos a atributos, incluindo a sequência de sistemas autônomos percorridos. O receptor pode detectar alguns ciclos no nível de AS e aplicar políticas compatíveis com encaminhamento baseado em destino.

Essa definição contém um limite importante. O BGP não é uma linguagem universal de intenção e não é um controlador central para a Internet. Ele oferece uma estrutura compartilhada para redes que continuam autônomas. A existência de um formato comum não elimina a decisão local.

O termo sistema autônomo define o local dessa decisão. Um AS pode operar diversos protocolos e métricas internamente, desde que apresente uma visão externa coerente sob uma administração técnica. Dois AS que recebem os mesmos candidatos podem escolher caminhos diferentes porque relações, capacidades, objetivos e filtros não são iguais.

A separação conceitual entre Adj-RIBs-In, Loc-RIB e Adj-RIBs-Out transforma o princípio em um mapa operacional. Adj-RIBs-In representa informação aprendida dos vizinhos antes da seleção local. Loc-RIB representa rotas escolhidas após política e viabilidade. Adj-RIBs-Out representa rotas preparadas para vizinhos específicos.

Uma implementação não precisa manter três cópias físicas. Pode usar estruturas compartilhadas, referências ou índices. O que deve permanecer é o comportamento visível e a capacidade de distinguir responsabilidades. Liberdade interna não autoriza alterar a semântica externa.

Com essa separação, a pergunta “a rota existe?” se divide. Ela foi recebida? Era elegível? Qual preferência recebeu? Seu próximo salto era resolvível? Foi escolhida localmente? A política permitiu anunciá-la para determinado vizinho? O vizinho a aceitou e escolheu? Uma resposta positiva em uma etapa não responde às demais.

A RFC também distingue bases BGP da tabela usada para construir o encaminhamento. Essa tabela pode reunir rotas conectadas, estáticas, internas e BGP. A decisão sobre qual origem prevalece pertence à política local, fora de uma prescrição uniforme. A especificação estrutura o intercâmbio; não escolhe por cada operador.

Mudanças de estado são explícitas. Um speaker pode retirar um prefixo, substituir um anúncio dos mesmos destinos com atributos diferentes ou fechar a sessão, removendo implicitamente as rotas aprendidas por ela. A retirada encerra validade naquele contexto, mas não prova convergência simultânea em toda a rede.

Os atributos também têm escopos diferentes. LOCAL_PREF expressa preferência interna. MULTI_EXIT_DISC fornece um sinal limitado entre múltiplas conexões. NEXT_HOP identifica um endereço a resolver. AS_PATH registra a sequência de AS. Nenhum desses campos constitui uma ordem global.

O papel editorial de Hares, compartilhado com Yakov Rekhter e Tony Li, pertence a esse contrato comum. A RFC torna etapas e comportamento interoperável discutíveis por todos. Ela não demonstra a estrutura interna de um produto nem atribui a um editor o resultado de uma rota real.

As três fases do processo de decisão BGP

Na primeira fase, cada rota viável recebe um grau de preferência. Uma rota aprendida de um vizinho interno pode carregar LOCAL_PREF. Uma rota externa recebe preferência calculada por política pré-configurada ou pode ser declarada inelegível. A função exata permanece local; a RFC não define relações comerciais nem metas de engenharia.

A preferência de uma rota não deve depender da existência ou dos atributos de outras rotas. Primeiro se determina elegibilidade e preferência individualmente; depois os candidatos são comparados. Essa separação reduz dependências escondidas e permite distinguir duas perguntas: por que a rota recebeu esse valor e por que venceu as alternativas?

Na segunda fase, o sistema escolhe a melhor rota elegível para cada destino e a instala em Loc-RIB. Preferência alta não basta. NEXT_HOP precisa ser resolvível e a instalação não pode criar resolução mutuamente recursiva. Mudanças na alcançabilidade do próximo salto ou no custo interior exigem nova seleção.

Uma rota sem resolução é removida de Loc-RIB e da tabela de roteamento, mas pode permanecer em Adj-RIBs-In para recuperar utilidade caso a precondição volte. O sistema pode conservar informação sem tratá-la como encaminhável. Recebimento, seleção e capacidade de forwarding são fatos relacionados, mas não idênticos.

Política e estado em execução precisam coincidir. Uma rota pode ser desejável segundo a política e impossível de encaminhar no momento. Um próximo salto disponível também não concede autorização política. Speakers dentro do mesmo AS devem evitar escolhas incompatíveis capazes de formar loops de encaminhamento.

Quando várias rotas mantêm a mesma preferência, uma ordem de critérios reduz o conjunto. Comprimento de AS_PATH, ORIGIN, uso aplicável de MULTI_EXIT_DISC, aprendizado externo ou interno, custo interior para o próximo salto, identificador BGP e endereço do vizinho podem participar. A ordem tem significado.

Uma implementação pode otimizar internamente o algoritmo desde que produza o resultado definido. Essa flexibilidade separa estrutura de software e semântica. É possível alterar armazenamento ou cálculo sem modificar o que os demais sistemas observam.

Na terceira fase, a seleção local se transforma em anúncios por vizinho. Uma rota em Loc-RIB pode ser excluída por política de exportação. Uma rota antes anunciada deve ser retirada se deixar de ser permitida. As condições de alcançabilidade e encaminhamento continuam relevantes para a saída.

A agregação pode reduzir a quantidade de informação trocada. O ganho tem custo: o receptor perde distinções e talvez precise aplicar uma única política ao conjunto. Eficiência altera a granularidade da próxima decisão e precisa ser avaliada junto com essa perda.

As três fases formam uma cadeia que não deve ser reduzida a “o BGP escolhe”. Receber não é aceitar. Aceitar não é preferir. Preferir não é resolver. Selecionar localmente não é autorizar exportação. Anunciar não prova encaminhamento de ponta a ponta.

O trabalho editorial atribuído a Hares ajuda a tornar essa cadeia comum e auditável. Valores de preferência, disponibilidade de next hop, filtros e resultados continuam pertencendo às redes que os operam. O padrão ilumina responsabilidade, mas não a absorve.

Estado de sessão e limites de um modelo conceitual

A máquina de estados finitos do BGP organiza a relação com cada vizinho em estados como Idle, Connect, Active, OpenSent, OpenConfirm e Established. Eventos administrativos, eventos de transporte, mensagens e temporizadores provocam transições. Mensagens UPDATE só são válidas em Established.

Essa precisão divide uma aparente indisponibilidade em cenários diferentes. A conexão TCP pode não abrir. OPEN pode ser recusado. A confirmação pode não terminar. O Hold Timer pode expirar. Uma Notification pode encerrar a sessão. Cada cenário exige evidências e respostas próprias.

A RFC informa, porém, que a máquina e as RIBs são modelos conceituais. O software não precisa reproduzir literalmente cada estrutura na memória se oferecer a função esperada e o mesmo comportamento visível. A regra impede que um diagrama normativo seja confundido com a arquitetura interna de cada produto.

Temporizadores limitam espera e ajudam a detectar perda de relacionamento, mas não provam saúde do encaminhamento. Uma sessão pode permanecer Established enquanto política filtra as rotas esperadas. Pode ser restabelecida enquanto NEXT_HOP continua sem resolução. Estados de transporte, sessão, rota e forwarding precisam ser correlacionados.

Encerrar uma sessão remove implicitamente as rotas aprendidas por ela. A regra fornece um limite claro de validade, mas não promete tempo de convergência uniforme. Cada sistema reavalia alternativas e precondições. O registro do encerramento inicia uma verificação; não comprova que todos os efeitos terminaram.

A distinção entre modelo e execução é uma fronteira de responsabilidade. O padrão descreve quais fatos deveriam ser observáveis. Implementadores decidem como produzi-los. Operadores precisam manter logs, tabelas e medições que demonstrem o comportamento real.

Uma investigação disciplinada segue a cadeia: transporte, sessão, rotas recebidas, elegibilidade, seleção, instalação, exportação e resposta do vizinho. Saltar do primeiro ponto para o último cria causalidade que os dados não sustentam.

A atribuição pessoal permanece limitada da mesma maneira. Hares participou de uma especificação que explicita transições. Ela não controla cada sessão ou recuperação. A pessoa está ligada ao vocabulário comum; a operação segue distribuída.

RFC 1745: preservar significado entre BGP e OSPF

A RFC 1745 trata de um roteador de borda de AS que executa BGP-4 ou IDRP para fora e OSPF internamente. O problema não é apenas copiar rotas. Os protocolos usam atributos, métricas e ordens de decisão diferentes. A redistribuição precisa preservar contexto suficiente.

Kannan Varadhan, Susan Hares e Yakov Rekhter são os autores. Essa atribuição conecta Hares à formulação da fronteira, não a toda implementação nem a todo resultado. A RFC descreve requisitos e cenários; a configuração concreta continua local.

O ponto de partida é conservador. Ao exportar OSPF para BGP, o administrador deve poder filtrar por endereço e máscara e pela etiqueta de rota externa OSPF e seus subcampos. Por padrão, nenhuma rota OSPF é exportada. Mesmo uma configuração ampla para rotas internas e interárea não libera rotas externas sem decisão explícita.

A direção oposta também começa fechada. Por padrão, rotas BGP não são importadas para OSPF. O administrador precisa selecionar destinos, embora uma implementação possa oferecer uma opção deliberada de importação geral. O comportamento fail-closed não impede todos os erros, mas coloca autorização em um ponto identificável.

O processo de exportação deve acompanhar alcançabilidade real. Um ASBR pode anunciar um conjunto quando ao menos um membro é alcançável via OSPF, mas deve parar quando nenhum é. Não deve exportar máscara não contígua. Deve permitir definir MULTI_EXIT_DISC e um atraso configurável.

Escopo, granularidade, tempo e estado entram assim no contrato. Uma rota não se torna exportável só por existir em um registro administrativo. A precondição operacional precisa continuar válida. Quando desaparece, o anúncio deve acompanhar a mudança.

A importação revela uma diferença numérica de direção. OSPF prefere custos menores. BGP LOCAL_PREF prefere valores maiores. As faixas também diferem. Construir custo OSPF a partir de LOCAL_PREF exige transformação consciente; copiar o valor pode inverter intenção ou apagar diferenças.

Em algumas correlações descritas, o custo OSPF determina o roteador de borda enquanto LOCAL_PREF deixa de governar essa etapa. Um atributo exerce autoridade dentro de sua fase e protocolo. Transferi-lo sem contrato cria uma aparência falsa de política.

A RFC não prova que um produto cumpra todos os requisitos nem que uma configuração esteja livre de loops. Ela define quais evidências procurar: filtros, tags, next hop, caminho externo, atraso, condição de retirada e observação das tabelas resultantes.

Metadados, caminhos de custo igual e um loop documentado

Tags de rotas externas OSPF podem preservar parte da origem. Um ASBR pode usá-las para distinguir fontes e aplicar política adequada ao redistribuir. O tag não escolhe o caminho sozinho; conserva contexto necessário a outra decisão.

Essa evidência pode ser incompleta. Se um ASBR não fornecer tags ou informação de caminho suficiente, outro roteador de borda talvez não consiga reconstruir a origem externa. O sistema pode recusar o anúncio ou seguir uma política explicitamente definida. Ausência de evidência não deve parecer atribuição completa.

Caminhos de custo igual tornam a composição mais delicada. BGP e OSPF podem produzir escolhas corretas segundo suas próprias regras, enquanto dois ASBR correlacionam de maneira diferente informações externas e internas. A RFC apresenta um cenário em que a combinação forma um loop de encaminhamento. É um exemplo normativo, não uma medição de incidente.

Evitar o loop exige manter NEXT_HOP, OSPF forwarding address e, quando necessário, informação de caminho externo. O objetivo não é dar supremacia a um protocolo. É garantir que o sistema de destino ainda possua as distinções necessárias para decidir corretamente.

O exemplo expõe uma propriedade geral: dois registros podem ser precisos em seus próprios contextos e produzir erro quando unidos sem semântica de conversão. Um tag descreve origem, uma tabela BGP descreve seleção e uma tabela OSPF descreve custo. Nenhuma representação deve ser ampliada sem prova adicional.

Essa fronteira combina com a ideia de registro como inventário de fatos, não como soberano. A autoridade de um dado vem de descrever com precisão um fato limitado, em um tempo e escopo. A formalidade não o transforma em ordem universal. O estado em execução testa a coerência entre camadas.

Para operadores, a consequência é prática. Devem ser mantidos tags, decisões de filtro, mudanças de next hop e motivos de redistribuição. Tabelas antes e depois devem ser comparadas. Caminhos de retorno e condições de retirada precisam ser testados.

Sem essas evidências, a fronteira entre protocolos se torna um ponto cego mesmo quando cada configuração isolada parece plausível. Os autores podem receber crédito por formalizar controles; o operador continua responsável por valores, exceções e consequências.

RFC 8241: autorização antes da escrita programática

A RFC 8241 define requisitos de segurança para I2RS, onde clientes externos podem ler ou alterar estado de roteamento por meio de um agente. Segurança inclui mais do que criptografia de transporte. Abrange identidade, funções, escopo, prioridade, atribuição secundária e auditoria.

Susan Hares compartilha a autoria com Daniel Migault e Joel Halpern. O documento distingue cliente e agente. Ambos precisam autenticar-se. O canal precisa fornecer integridade, confidencialidade e proteção apropriada contra replay.

Uma conexão autenticada não concede permissão ilimitada. Identidades se associam a funções, e funções limitam objetos legíveis ou graváveis. Um observador pode ter apenas leitura. Uma ferramenta de engenharia pode alterar um conjunto estreito. Um mecanismo de recuperação pode obter prioridade maior para objetos específicos.

Essa separação evita concentrar toda automação em uma identidade privilegiada. A concentração simplifica credenciais, mas destrói atribuição e revogação seletiva. Escopos claros permitem conter uma anomalia sem retirar todo controle programático.

O documento também exige comportamento determinístico quando clientes competem. Identidade, identidade secundária e prioridade ajudam a determinar proprietário e vencedor. Prioridade resolve uma colisão de autoridade; não prova que o valor escrito está correto.

Um cliente de prioridade alta pode escrever um valor indesejado. Validação de entrada, limites do modelo de dados, leitura posterior e observação continuam necessárias. Autorizar uma operação e comprovar um estado correto são etapas diferentes.

Identidade secundária preserva o ator representado por trás de uma conta técnica ou serviço. Melhora rastreabilidade, mas não certifica intenção nem conteúdo. Como metadado de decisão, precisa ficar junto da solicitação e da resposta.

Canais de escrita exigem proteção especial porque uma mudança aceita pode alterar seleção e forwarding. Logs devem mostrar quem pediu o quê, quando, sob qual função e com qual resposta. Auditoria não impede todo erro, mas permite investigação, revogação e compensação.

A RFC continua sendo uma especificação de requisitos. Não demonstra que um fornecedor implementou tudo, que um operador configurou privilégio mínimo ou que automação melhorou continuidade. Essas afirmações exigem testes locais.

A conclusão é que programabilidade não reduz a necessidade de autoridade explícita. Quanto mais rápido se escreve estado, mais importantes se tornam identidade, escopo, prioridade, precondições e verificação posterior.

RFC 8242: estado efêmero, conflito e ausência de rollback automático

A RFC 8242 concentra-se no estado efêmero de I2RS. Efêmero não significa irrelevante. Significa que o ciclo de vida difere da configuração persistente e que o estado pode desaparecer no reinício do agente ou processo de roteamento. O cliente responsável precisa detectar a perda e restabelecer a intenção quando necessário.

Jeffrey Haas e Susan Hares são os autores. O documento descreve criação, alteração e remoção, além de propriedade e conflito entre clientes. Identidade e prioridade participam do arbitramento. Um cliente deslocado precisa receber notificação para reconciliar sua visão.

O reinício é uma fronteira de responsabilidade. Se continuidade depende de estado temporário, o cliente precisa de reconexão, replay e verificação. Presumir restauração automática confunde estado corrente com configuração durável. A RFC nomeia a fronteira; a arquitetura operacional constrói a recuperação.

Operações múltiplas acrescentam outra limitação. A RFC não garante que uma falha parcial desfaça automaticamente alterações anteriores. Algumas operações podem ter sido aplicadas antes de outra falhar. O cliente precisa reler, identificar o estado efetivo e executar compensações.

Uma resposta de erro não comprova que nada mudou. Antes de escrever, convém registrar snapshot, resultado esperado, escopo limitado e operações inversas. Depois, o estado precisa ser lido. Reversibilidade é uma propriedade projetada, não uma suposição.

Conflitos devem ser tratados por escopo. Um cliente de prioridade maior pode substituir outro dentro da área permitida. Prioridades iguais ou sobreposição ambígua exigem comportamento estável e notificação. Mesmo um arbitramento correto pode selecionar conteúdo operacionalmente errado.

Estado efêmero é útil quando uma intenção deve desaparecer com o processo ou não deve virar configuração permanente. Ele transfere responsabilidade ao cliente: manter sessão, reconstruir estado e reconhecer perda de propriedade.

Velocidade não muda essa responsabilidade. Escrita rápida sem snapshot, validação ou compensação cria divergência mais rápido que uma operação manual. A interface deve reduzir ambiguidade, não esconder efeitos.

O documento também não prova adoção ou resultado. Fornece um contrato a ser testado por perda do cliente, reinício, colisão, falha parcial, notificação e recuperação.

A participação de Hares conecta esse contrato ao restante do registro. Estado e proprietário ficam explícitos, mas nenhum autor controla o uso em uma rede. A especificação define observabilidade; a operação demonstra o que ocorreu.

A responsabilidade atual do IDR como manutenção limitada

A descrição atual do grupo Inter-Domain Routing inclui Susan Hares entre os responsáveis pela manutenção do BGP e trabalhos relacionados. A função conecta contribuições históricas a responsabilidade contínua por escopo, revisão e consenso. Não cria autoridade unilateral.

O grupo trabalha por propostas públicas, discussão técnica, revisão e experiência de implementação. Seus responsáveis organizam o processo e avaliam consenso. Não substituem os participantes, não obrigam um fornecedor a implementar e não configuram a política de um operador.

Legitimidade vem do processo verificável e da relação com código em execução. Um documento ganha utilidade quando implementações independentes interoperam e operadores entendem condições e falhas. A função de coordenação facilita esse caminho, mas não garante resultado.

O limite também protege o BGP contra expansão indiscriminada. Nem todo problema de rede deve virar extensão do protocolo. Um mecanismo novo precisa justificar compatibilidade, implantação incremental, observabilidade, tratamento de erros e custo de estado adicional.

Manutenção inclui reconhecer quando um tema pertence a prática local, modelo de dados, outro protocolo ou interface comum. Recusar uma generalização pode ser tão importante quanto publicar uma extensão. Estabilidade depende de fronteiras.

O registro de Hares mostra preocupação consistente com essas fronteiras: fases de decisão, redistribuição, autorização e temporalidade. A coerência sustenta uma análise centrada na pessoa sem atribuir o sistema inteiro.

Consenso pertence ao grupo, código aos implementadores, integração aos fornecedores e configuração aos operadores. Medidas de convergência, segurança ou continuidade pertencem ao ambiente observado. Uma presidência não funde essas responsabilidades.

A descrição precisa é participação documentada na formulação e manutenção de contratos de roteamento. Uma biografia genérica ou uma narrativa de efeitos não comprovados não é necessária nem sustentada pelas fontes.

Requisitos, alternativas e perguntas pendentes para operadores

Em conjunto, as RFCs formam três superfícies conectadas. A primeira é a decisão BGP, do recebimento à exportação. A segunda é a fronteira de redistribuição, onde atributos e métricas podem perder significado. A terceira é o estado programável, controlado por identidade, prioridade, duração e falha parcial.

O principal indicador é a capacidade de localizar cada decisão nesse mapa. Uma rota recebida e não selecionada exige investigação diferente de uma rota selecionada e não exportada. Um prefixo BGP redistribuído em OSPF apresenta outra superfície em relação a um cliente I2RS que altera estado efêmero.

Vários eventos devem aumentar a revisão. Mudança no next hop pode executar nova seleção sem alteração da política. Nova redistribuição pode revelar conflito entre preferência e custo. Um segundo escritor cria colisão mesmo com autenticação. Reinício altera estado temporário. Falha intermediária exige reconciliação.

Operadores podem manter controle manual local, usar um escritor em escopo estreito ou permitir vários sob prioridade explícita. Podem negar redistribuição por padrão, abrir apenas destinos selecionados ou aceitar intercâmbio amplo com maior carga de revisão.

Também podem escolher estado efêmero quando o desaparecimento no reinício é desejado ou configuração persistente quando sobrevivência é requisito. Nenhuma opção é universal. Cada uma desloca custo e responsabilidade de recuperação.

Controle manual pode ser lento ou inconsistente. Um escritor concentra risco. Vários escritores exigem governança de conflitos. Redistribuição facilita integração e pode criar loops. Persistência conserva intenção e pode conservar intenção obsoleta. Estado efêmero limita duração e exige replay.

Os testes devem cobrir perda de next hop, encerramento de sessão, falta de tags, caminhos de retorno, colisão de clientes, reinício e falha parcial. Rotas recebidas, selecionadas, instaladas e anunciadas precisam ser observadas separadamente. Resposta bem-sucedida da interface não basta.

Perguntas locais permanecem. O produto respeita casos extremos? Funções são estreitas? A identidade secundária é registrada? Notificações chegam a tempo? Compensações foram testadas? Filtros cobrem exceções? A agregação oculta informação necessária?

As RFCs não respondem por uma rede específica. Elas indicam evidências. A contribuição atribuída a Hares torna o mapa mais claro; operadores precisam completá-lo com seu estado.

Fontes

  1. Perfil de Susan Hares no IETF Datatracker
  2. RFC 4271: A Border Gateway Protocol 4
  3. RFC 1745: interação entre BGP4/IDRP e OSPF
  4. RFC 8241: requisitos de segurança de I2RS
  5. RFC 8242: requisitos de estado efêmero de I2RS
  6. Descrição da carta do grupo IETF Inter-Domain Routing