Depeering Cogent-Level 3 de 2005: teste de responsabilização

Resumo

A Level 3 deixou de trocar tráfego diretamente com a Cogent em 5 de outubro de 2005. O registro público mostra que alguns clientes perderam alcançabilidade para destinos do outro lado da divisão, enquanto o impacto completo sobre clientes e prefixos permanece desconhecido. [1][21][22]
A Cogent pediu publicamente à Level 3 que restaurasse a conexão antes de qualquer negociação adicional. A posição pública preservada da Level 3 afirmava que o arranjo experimental já não atendia às suas condições. São posições comerciais atribuídas, não conclusões de que alguma operadora descumpriu contrato ou agiu ilegalmente. [1][22]
Um prefixo registrado e um contrato de cliente não criavam um caminho funcional. A alcançabilidade dependia das rotas que AS174 e AS3356 trocavam, aceitavam e selecionavam, juntamente com qualquer trânsito alternativo ou multihoming que os clientes de fato possuíam.
A Merit usou observações selecionadas do RouteViews para estudar a alcançabilidade do bloco 38.0.0.0/8 da Cogent. RouteViews e RIPE RIS podem preservar anúncios e retiradas de coletores participantes, mas não revelam todas as políticas privadas, preferências locais, caminhos de clientes ou termos comerciais. [8]-[10]
O multihoming reduzia o risco apenas quando provedores alternativos, anúncios aceitos, capacidade e dependências de aplicações eram genuinamente independentes. Um segundo contrato sem uma rota alternativa efetiva não era continuidade.
Em 28 de outubro, as operadoras anunciaram um acordo de peering settlement-free modificado, com obrigações de tráfego, pagamentos condicionais e um processo destinado a proteger clientes caso a relação expirasse posteriormente ou as violações não fossem corrigidas. O comunicado público descreve um desenho de controle, não a prova de que todo risco futuro de interconexão desapareceu. [2]
Orientações posteriores de BGP, MANRS e NIST ajudam a definir controles mensuráveis, como política explícita, monitoramento de rotas, limites de prefixo máximo, coordenação e evidência de incidentes. Trata-se de material de comparação, não de lei retroativa para o evento de 2005. [13]-[20]
O padrão de responsabilização é operacional: mapear clientes dependentes, comprovar alcançabilidade alternativa antes da terminação, observar o impacto em rotas e transações durante a mudança, preservar um processo de correção limitado e verificar a restauração a partir de fora das redes das duas operadoras.

A alcançabilidade da internet costuma ser vendida como se fosse uma propriedade estável. Um cliente recebe um endereço, conecta-se a uma operadora de trânsito e vê rotas para destinos em todo o mundo. Dessa perspectiva, “a internet” parece ser um serviço contínuo. No plano de controle, porém, a alcançabilidade não é uma promessa institucional. É o resultado atual de redes independentes anunciando prefixos, aceitando ou recusando esses anúncios, selecionando caminhos e encaminhando tráfego sob suas próprias políticas.

A disputa de outubro de 2005 entre a Cogent Communications, operando AS174, e a Level 3 Communications, operando AS3356, expôs essa diferença. Em 5 de outubro, a Level 3 deixou de trocar tráfego diretamente com a Cogent. Declarações contemporâneas e reportagens descreveram clientes das duas redes perdendo acesso a alguns destinos através da divisão resultante. As empresas permaneceram conectadas a outras partes da internet, e o evento não particionou toda a rede global.

Mas onde nenhuma rota alternativa aceitável ligava um destino alcançável via Cogent a uma origem alcançável via Level 3, registros de alocação e expectativas de clientes não conseguiam fazer os pacotes atravessarem a interconexão ausente.

Foi um depeering deliberado, não um vazamento de rota, sequestro de rota ou anúncio BGP acidental. A falha operacional veio da remoção de um caminho que antes transportava tráfego entre duas grandes redes. Essa distinção determina quais evidências importam. Os investigadores precisam examinar a decisão de interconexão, as mudanças de rota BGP, os caminhos alternativos, a dependência de clientes, o multihoming, a comunicação e a restauração. Um relato genérico de desacordo comercial ignora o mecanismo que tornou o desacordo consequente.

O episódio também testa um tipo específico de responsabilização. Peering e trânsito são arranjos comerciais diferentes, e o registro público descreve a relação restaurada como peering settlement-free, não trânsito pago. Ainda assim, ambas as empresas vendiam conectividade dentro de um ecossistema cujo valor dependia da alcançabilidade entre domínios. A questão de responsabilização, portanto, não é se duas redes autônomas devem fazer peering gratuito.

É se operadoras que controlam uma interconexão consequente conseguem identificar a dependência de clientes, gerenciar a terminação sem obscurecer as consequências operacionais, preservar evidências e comprovar a restauração.

A alcançabilidade existe no caminho em execução

Uma alocação de endereço IP pode identificar o titular de um bloco. Um número de sistema autônomo pode identificar um domínio de roteamento. Um contrato pode declarar o que o cliente comprou, e um acordo de interconexão pode descrever o que duas operadoras esperam uma da outra. Nenhum desses registros, por si só, instala uma rota na tabela de encaminhamento de um roteador.

Para um pacote viajar de um cliente atrás do AS174 até um destino atrás do AS3356, as redes relevantes precisavam de uma sequência de rotas aceitas nas duas direções. Essa sequência poderia usar a interconexão direta Cogent-Level 3. Poderia, em vez disso, passar por outra operadora, se políticas de exportação, relações comerciais, capacidade e seleção de rota permitissem esse caminho. Se nenhuma rede anunciasse uma alternativa aceitável, o destino poderia permanecer validamente registrado e corretamente originado e ainda assim ficar inalcançável do outro lado.

Isso torna a “alcançabilidade total da internet” uma abreviação operacional, e não uma garantia absoluta de que todo host sempre responderá. Firewalls, falhas de aplicações e políticas locais podem tornar um serviço específico indisponível mesmo quando existe uma rota de rede. A pergunta relevante na disputa de 2005 é mais restrita: o roteamento interdomínio comum fornecia caminhos utilizáveis entre prefixos cuja conexão prática dependia da relação AS174-AS3356?

O rótulo de mercado de uma operadora não responde a essa pergunta. Descrever uma rede como backbone principal ou operadora Tier 1 pode indicar escala ou posição comercial, mas não cria uma obrigação de roteamento imposta globalmente. Cada sistema autônomo mantém controle sobre as rotas que exporta, as rotas que aceita e os caminhos que prefere. A internet não tem um roteador central que possa ordenar que duas redes troquem tráfego depois que encerram uma relação bilateral.

Essa independência é uma das forças da internet. Permite que redes tomem decisões distintas de segurança, engenharia e negócios sem pedir permissão a uma autoridade central. A mesma independência cria um problema de continuidade: uma decisão bilateral pode ter efeitos além das duas partes quando os clientes não têm um caminho utilizável ao redor dela. A responsabilização, portanto, deve seguir o controle prático, não os rótulos.

O operador que controla uma sessão controla se ela permanece disponível; um operador que vende conectividade controla a resiliência que fornece ou recomenda; um cliente controla sua própria redundância apenas dentro de limites técnicos e financeiros.

O evento de 2005 uniu essas camadas. As empresas tinham um desacordo comercial, mas seu efeito voltado ao cliente se expressou por meio do BGP. Os fatos decisivos não eram simplesmente o que as partes acreditavam que o acordo exigia. Eram quais rotas deixaram de ser trocadas, quais rotas alternativas permaneceram aceitáveis, quais clientes dependiam do caminho removido e como a relação direta foi restaurada.

Uma cronologia limitada da disputa de outubro

A cronologia defensável começa em 5 de outubro de 2005, quando a Level 3 interrompeu a troca direta de tráfego com a Cogent. O material público descreve a ação como a terminação do relacionamento de peering direto das empresas. As evidências disponíveis não estabelecem o layout físico completo dessa interconexão, o número de sessões ou portas envolvidas, nem a capacidade em cada local. “A conexão” não deve, portanto, ser lida como prova de que um cabo ou um roteador representava toda a relação.

A cobertura contemporânea rapidamente enquadrou a consequência como um problema de alcançabilidade. Alguns usuários e empresas conectados por uma rede, segundo relatos, não conseguiam alcançar destinos dependentes da outra. Esses relatos sustentam a conclusão de que o depeering teve efeitos reais sobre clientes. Eles não estabelecem uma lista completa de prefixos afetados, uma interrupção universal em qualquer das operadoras, impacto igual nos dois lados ou um percentual preciso da internet que se tornou inalcançável.

Em 7 de outubro, a Cogent pediu publicamente que a Level 3 restaurasse a interconexão antes de as empresas continuarem as negociações. Essa declaração é evidência da posição da Cogent e da sequência proposta: primeiro restaurar a conectividade do cliente, depois tratar da disputa. Ela não estabelece de forma independente as obrigações confidenciais de nenhuma das partes, nem decide se o arranjo anterior cumpria seus termos.

A Level 3 ofereceu uma explicação pública diferente. Sua declaração, preservada na cobertura contemporânea, descreveu a relação descontinuada como um arranjo de peering experimental que não atendia mais às condições aplicáveis. Isso é evidência da razão declarada pela Level 3. O registro público não fornece o acordo completo, as medições usadas para avaliá-lo, as características de tráfego exatas em questão nem as deliberações internas que levaram à terminação. Ele não sustenta a conclusão de que a Cogent violou um termo não publicado específico ou que a avaliação da Level 3 estava incorreta.

Discussões de operadores arquivadas pela NANOG documentaram questionamentos contemporâneos sobre caminhos e alcançabilidade. Essas mensagens são valiosas porque mostram o que engenheiros de rede observavam e testavam enquanto o evento se desenrolava. Não são um censo controlado da internet. Os participantes tinham pontos de observação, relações comerciais e acesso a informações de roteamento diferentes. Um relato de uma rede podia descrever com precisão o caminho daquela rede sem estabelecer o que todas as outras redes viam.

Em 28 de outubro, Cogent e Level 3 anunciaram conjuntamente que haviam alcançado um acordo de peering settlement-free modificado. O comunicado descrevia obrigações relativas a características e volume de tráfego, pagamentos caso essas obrigações não fossem cumpridas e um processo destinado a reduzir danos a clientes se a relação expirasse posteriormente ou uma violação permanecesse sem correção. O anúncio é a evidência pública compartilhada mais forte para a estrutura da remediação, porque as duas empresas o emitiram juntas.

O comunicado ainda não era o contrato completo. Não divulgou publicamente todos os limites, métodos de medição, períodos de correção, procedimentos operacionais ou direitos de decisão. Sua existência também não prova que todos os caminhos de clientes foram restaurados no mesmo instante ou que todos os riscos posteriores de interconexão desapareceram. Ela mostra que as empresas restauraram a relação em termos revisados e identificaram publicamente procedimentos de proteção ao cliente como parte da solução.

Registros posteriores da FCC discutiram o evento em análises mais amplas de interconexão da internet, concorrência de backbone e alcançabilidade de clientes. Esses registros ajudam a explicar por que uma disputa entre grandes redes podia afetar partes que não eram signatárias do arranjo de peering. Eles não devem ser convertidos em um julgamento jurídico sobre a conduta de 2005. Os materiais citados não estabelecem que qualquer operadora tenha violado uma lei, regulamento ou contrato.

O que mudou no BGP

O BGP permite que sistemas autônomos troquem informações de alcançabilidade. Um anúncio de rota identifica um prefixo alcançável e carrega atributos que ajudam as redes receptoras a aplicar políticas e selecionar caminhos. O caminho AS registra os sistemas autônomos pelos quais o anúncio se propagou, enquanto outros atributos e preferências configuradas localmente influenciam qual rota a rede instala.

O processo de decisão é descentralizado. A Cogent podia anunciar prefixos de clientes e internos à Level 3 sob sua política de exportação. A Level 3 podia aceitar, filtrar ou preferir esses anúncios sob sua política de importação e, então, expor rotas selecionadas a clientes ou pares apropriados. O processo inverso se aplicava às rotas da Level 3 que chegavam à Cogent. Nenhuma empresa controlava todas as redes intermediárias, e nenhuma podia obrigar terceiros a exportar um caminho alternativo.

Quando uma relação BGP externa direta é encerrada, rotas aprendidas exclusivamente por meio dela deixam de ser utilizáveis após retiradas, perda de sessão ou remoção de política. Os roteadores então reconsideram outros caminhos disponíveis. Se outra operadora anuncia uma rota aceitável, o tráfego pode se mover para essa rota. Se as alternativas estão ausentes, filtradas ou indisponíveis comercialmente, o roteador afetado não tem caminho utilizável para o destino.

É por isso que o mesmo depeering pode produzir resultados diferentes para clientes diferentes. Uma rede pode ter outro upstream carregando um caminho entre os dois lados. Outra pode aprender apenas as rotas que desapareceram com a sessão direta. Uma terceira pode ver um caminho alternativo, mas rejeitá-lo por causa de políticas, regras de comprimento de prefixo ou restrições de relacionamento. Uma quarta pode selecionar uma rota alternativa cuja capacidade ou caminho de retorno não suporta tráfego de aplicação confiável.

A perda do caminho direto também não precisa produzir sintomas simétricos. As decisões BGP são tomadas separadamente por cada rede, e o tráfego de dados exige caminhos de ida e volta funcionais. Um pacote pode alcançar um destino enquanto sua resposta não encontra rota utilizável de volta. Preferências locais diferentes podem enviar as duas direções por sistemas autônomos diferentes. Consequentemente, uma observação de rota bem-sucedida em uma direção não comprova serviço bidirecional completo.

O registro público não expõe as configurações completas de preferência local da Cogent e da Level 3. Não revela todos os filtros de rota, tratamentos por comunidade, pares privados ou arranjos de trânsito de terceiros. Caminhos AS públicos podem sugerir como o tráfego poderia ter se movido, mas não revelam todas as políticas internas que determinaram a seleção de rotas.

Comunidades BGP acrescentam outra camada potencial de evidência. A RFC 1997, anterior ao evento, define uma forma de anexar rótulos relevantes para política às rotas. As redes podem usar comunidades para solicitar ou sinalizar comportamento de propagação. O significado e a implementação de muitas comunidades, porém, são específicos de cada rede. Mesmo quando uma comunidade aparece em uma atualização pública, ela não revela automaticamente o acordo privado que rege a rota nem prova que todos os roteadores aplicaram a política pretendida.

O evento, portanto, não pode ser reduzido a “as rotas sumiram em todos os lugares”. AS174 e AS3356 continuaram operando, e prefixos associados a eles podiam permanecer visíveis em muitos locais. A questão mais restrita era se os caminhos que cruzavam a relação anterior permaneciam disponíveis por meio de outras redes. Um prefixo visível em um coletor podia estar inalcançável a partir de um cliente específico. Inversamente, uma rota ausente em um coletor podia permanecer alcançável em outro lugar por meio de um caminho privado ou selecionado de forma diferente.

Nem a validade da rota pode garantir conectividade. Um prefixo originado corretamente pode estar inalcançável porque nenhuma rota aceitável chega a uma determinada rede. Mecanismos modernos de validação de origem podem ajudar a determinar se uma origem é autorizada, mas não podem forçar dois sistemas autônomos a manter uma sessão de peering nem exigir que uma terceira rede transporte tráfego entre eles. A falha de 2005 foi sobre disponibilidade de caminho e política, não apenas propriedade de endereço ou autenticidade de origem.

Por que algumas redes conseguiram contornar a divisão

O multihoming é o mecanismo de resiliência mais óbvio em um evento de depeering. Um cliente conectado a mais de um upstream pode anunciar seu prefixo por várias redes e aprender destinos por mais de um caminho. Se um upstream perde alcançabilidade para parte da internet, o outro pode preservar uma rota utilizável.

Essa descrição é tecnicamente correta, mas incompleta como resposta de responsabilização. O multihoming exige mais do que assinar um segundo contrato de acesso. O cliente pode precisar de espaço de endereçamento aceito pelos dois upstreams, um número de sistema autônomo, equipamentos de roteamento compatíveis, equipe capaz de operar BGP, filtros de rota, monitoramento, controles de segurança e capacidade suficiente na conexão alternativa. O caminho de retorno também precisa convergir para uma rota funcional. Aplicações com firewalls stateful, dependências de endereço ou sensibilidade a mudanças de caminho podem exigir engenharia adicional.

A política comercial também importa. Uma operadora alternativa precisa estar disposta e apta a exportar as rotas relevantes. Um cliente não pode presumir que duas conexões quaisquer criam um caminho através de qualquer disputa entre redes upstream. Filtros de comprimento de prefixo podem impedir que anúncios mais específicos se propaguem. Um circuito alternativo dimensionado para tráfego de gerenciamento de emergência pode não suportar a carga normal de produção. Uma conexão nominalmente diversificada pode compartilhar instalações físicas ou uma dependência comum de upstream.

Por essas razões, a existência de multihoming não prova que todo cliente multihomed manteve o serviço. Ela estabelece um controle possível cuja eficácia precisa ser testada. Da mesma forma, a ausência de multihoming não estabelece por si só imprudência. Clientes pequenos podem não ter orçamento, conhecimento, recursos de endereço ou poder de barganha para operar conexões roteadas de forma independente. Um serviço vendido como acesso comum à internet pode ser razoavelmente consumido sem que o cliente construa um backbone em miniatura.

Clientes single-homed enfrentavam uma dependência mais acentuada. Se seu único upstream não tinha rota aceitável para destinos do outro lado, eles não podiam recriar uma interconexão de backbone após o depeering. Podiam buscar serviço de emergência de outra operadora, mas provisionamento, aceitação de roteamento, equipamentos e contratos levam tempo. A parte que controlava a interconexão removida podia alterar a disponibilidade de rotas muito mais rápido do que muitos clientes dependentes poderiam substituí-la.

Operadoras terceiras eram outra parte do caminho. Uma rede alternativa podia ter relacionamentos com Cogent e Level 3, mas sua política de exportação podia não permitir que atuasse como intermediária entre elas. O roteamento interdomínio costuma refletir papéis comerciais: uma operadora pode anunciar rotas de clientes amplamente enquanto recusa fornecer trânsito gratuito entre pares. Caminhos BGP públicos podem sustentar inferências sobre essas relações, mas a documentação da CAIDA enfatiza que os arranjos comerciais subjacentes são geralmente confidenciais e muitas vezes precisam ser inferidos.

Isso importa porque um desenho topológico pode superestimar a resiliência. Duas redes podem se conectar a um terceiro sistema autônomo sem obter um caminho utilizável através dele. A pergunta relevante não é se existe uma linha no mapa. É se as rotas são exportadas, aceitas e selecionadas sob políticas reais, com capacidade de encaminhamento suficiente para carregar o tráfego resultante.

Uma avaliação de continuidade defensável classificaria, portanto, os clientes pela dependência observada, e não por um rótulo simples de multihomed ou single-homed. Ela perguntaria quais prefixos tinham caminhos alternativos verificados, quais serviços tinham alcançabilidade bidirecional, se a capacidade permanecia adequada e por quanto tempo cada coorte de clientes experimentou prejuízo. As evidências públicas congeladas não fornecem essa matriz completa para outubro de 2005, de modo que alegações sobre a distribuição do impacto devem permanecer limitadas.

Reconstruindo o evento a partir de evidências públicas de rotas

Coletores públicos de rotas fornecem uma janela importante, mas parcial, para o incidente. O RouteViews arquivou atualizações BGP de outubro de 2005, permitindo que investigadores inspecionem anúncios e retiradas recebidos de pares participantes. O RIPE RIS explica o papel comparável de coletores distribuídos: eles registram informações de roteamento visíveis a partir de redes que optam por fazer peering com eles.

O estudo de caso de inspeção BGP da Merit trata o evento Cogent-Level 3 como um exercício de análise de rotas e examina a alcançabilidade envolvendo o bloco 38.0.0.0/8 da Cogent a partir de pares selecionados do RouteViews. Essa é uma investigação limitada e útil. Ela não transforma um agregado e um conjunto de pontos de observação selecionados em um inventário completo de clientes da Cogent, clientes da Level 3 ou rotas globalmente afetadas.

Uma reconstrução rigorosa começa separando âncoras de evento de observações de rotas. As declarações das empresas estabelecem que a relação direta foi deliberadamente encerrada e posteriormente restaurada. Os dados do coletor podem então mostrar como rotas específicas apareceram para pares participantes antes, durante e depois dessas mudanças. Mensagens contemporâneas de operadores, traceroutes e relatos de clientes podem testar se as mudanças observadas no plano de controle corresponderam a falhas de encaminhamento ou de aplicação.

O alinhamento de timestamps importa. Fluxos de atualização BGP contêm mudanças ordinárias de roteamento, além de mudanças relacionadas a incidentes. Sessões são reiniciadas por muitos motivos; prefixos podem ser retirados e reanunciados independentemente de uma disputa de peering. Um investigador não deve rotular toda atualização próxima a 5 de outubro como causada pelo depeering. A inferência mais forte vem de mudanças repetidas envolvendo caminhos relevantes, timing consistente em pontos de observação independentes e corroboração de observações operacionais.

A diversidade de coletores importa igualmente. Um par do RouteViews fornece as rotas que selecionou e optou por exportar ao coletor. Ele não expõe todas as rotas que o par considerou, todas as rotas rejeitadas por política ou todas as entradas da tabela de encaminhamento dentro da rede. Um coletor RIS tem a mesma restrição básica. Adicionar coletores aumenta a visibilidade, mas nenhum conjunto finito produz uma visão onisciente de toda interconexão privada e de todo roteador.

Evidências de caminho AS também exigem contenção. O caminho visível identifica os sistemas autônomos listados no anúncio selecionado. Ele não revela saltos internos de roteadores, utilização de portas, preços contratuais ou todo o tráfego efetivamente encaminhado por aquele caminho. A preferência local normalmente não se propaga entre sistemas autônomos, de modo que um observador externo pode não saber por que um caminho venceu. Peering privado pode permanecer ausente dos dados públicos de coletores.

Uma retirada é igualmente ambígua sem contexto. Pode significar que uma rota não está mais disponível para o par anunciante, que a política de exportação mudou ou que uma sessão falhou. Ela não identifica por si só a decisão de negócio por trás da mudança. Neste caso, as declarações das empresas fornecem a intenção que as atualizações brutas não podem: a interconexão terminou deliberadamente.

Traceroutes acrescentam pistas de encaminhamento, não onisciência. Roteadores podem suprimir respostas, usar endereços não relacionados ao caminho aparente ou encaminhar tráfego de forma assimétrica. Um traceroute que para nem sempre identifica o ponto exato da falha. Um traceroute bem-sucedido a partir de um local não estabelece alcançabilidade a partir de todos os locais. Ainda assim, traços repetidos de redes independentes podem ajudar a distinguir um problema local de aplicação de uma ausência mais ampla de caminhos interdomínio.

Relatos de clientes fornecem outra camada. Uma empresa incapaz de alcançar um site do outro lado da divisão fornece evidência de dano prático. O relato isolado, porém, pode não identificar qual upstream, política de rota ou caminho de retorno causou a falha. O relato mais defensável alinha a reclamação com prefixos de origem e destino, timestamps, observações BGP e, quando disponíveis, testes de caminho de ida e volta.

A evidência resultante deve ser declarada em níveis de confiança. Um anúncio direto de empresa pode estabelecer que a relação foi encerrada ou restaurada. Um coletor pode estabelecer que um par participante anunciou um caminho específico em um momento específico. Múltiplas observações independentes de rotas e encaminhamento podem sustentar uma inferência mais ampla. Nenhuma delas, isoladamente, fornece a lista completa de clientes, o contrato privado ou o impacto global preciso.

Materiais da FCC acrescentam contexto de mercado, não prova em nível de pacote. A discussão sobre interconexão de backbone e efeitos de rede ajuda a explicar por que clientes valorizam acesso a destinos fora de sua própria operadora. Referências regulatórias posteriores à disputa Cogent-Level 3 mostram sua relevância para a política de interconexão. Elas não substituem a evidência de rotas e não decidem a responsabilidade jurídica por perdas individuais de clientes.

Por que isso não foi vazamento de rota nem sequestro

Um vazamento de rota geralmente envolve a propagação de informações de roteamento além do escopo pretendido pelas relações relevantes. O problema resultante costuma ser a presença ou seleção de um caminho não intencional. Um sequestro geralmente envolve uma origem não autorizada ou outra alegação falsa de roteamento que desvia ou intercepta tráfego. Ambos podem criar falhas de alcançabilidade e segurança, mas seus mecanismos diferem do depeering deliberado.

O evento Cogent-Level 3 dizia respeito à remoção da troca direta de rotas. As declarações públicas descrevem uma decisão intencional de interconexão. A falha central foi que alguns caminhos não estavam mais disponíveis, não que uma operadora tenha originado falsamente os prefixos da outra ou se anunciado acidentalmente como trânsito para rotas que não deveria propagar.

Essa diferença altera os controles apropriados. Filtragem de prefixo e validação de origem podem reduzir a aceitação de anúncios não autorizados. Política de exportação ciente de relacionamentos pode reduzir vazamentos de rota. Esses mecanismos não obrigam um operador a continuar uma relação de peering válida. Um roteador perfeitamente filtrado ainda pode não ter rota para um destino após o término deliberado de uma sessão.

Dados BGP brutos nem sempre revelam a distinção sozinhos. Um coletor pode ver retiradas, caminhos substitutos ou perda de visibilidade. A intenção só fica clara quando essas observações são combinadas com as explicações públicas das empresas. Chamar o episódio de vazamento ou sequestro distorceria tanto a evidência quanto a superfície de controle.

A distinção também protege a comparação histórica da retrospectiva. Taxonomias posteriores de vazamento de rota e mecanismos de papéis de relacionamento ajudam operadores atuais a expressar e verificar a intenção de roteamento. Elas não provam que o término de 2005 foi uma fuga acidental de política e não criam deveres retroativos que governem a decisão comercial das empresas.

Posições comerciais e responsabilização operacional

Os termos confidenciais de peering importam para qualquer disputa contratual, mas não são necessários para identificar o problema de continuidade do cliente. As duas empresas divergiram publicamente sobre se a relação experimental continuava a cumprir suas condições. Sem o acordo completo e as medições subjacentes, um relato externo não pode determinar qual interpretação comercial estava correta.

A responsabilização operacional começa em outro ponto. Uma vez que um operador sabe que encerrar uma interconexão pode remover o único caminho viável para alguns clientes, a decisão tem consequências de continuidade mensuráveis. Essas consequências podem ser examinadas sem declarar que o operador não tinha direito contratual de encerrar.

Essa separação evita dois erros opostos. O primeiro é presumir que qualquer impacto ao cliente comprova má conduta. As redes precisam manter a capacidade de fazer cumprir acordos, proteger infraestrutura e encerrar relações. Um padrão de continuidade que efetivamente impusesse peering settlement-free perpétuo apagaria a autonomia operacional e comercial legítima.

O segundo erro é tratar uma disputa contratual bilateral como tendo apenas efeitos bilaterais. Clientes não eram partes da relação de peering, mas alguns dependiam das rotas trocadas por meio dela. Se nenhuma operadora tivesse mapeado essa dependência, testado alternativas ou estabelecido um procedimento de terminação limitado, a ausência desses controles continuaria importante mesmo que a terminação fosse contratualmente permitida.

Responsabilização, portanto, não é sinônimo de culpa. É uma disciplina de evidência que pergunta quem controlava cada decisão, o que cada parte podia razoavelmente observar, quais salvaguardas existiam e se o resultado foi verificado. A responsabilidade jurídica exige fatos adicionais e a lei aplicável. O registro público aqui não estabelece quebra de contrato, negligência, má-fé, conduta monopolista ou violação regulatória.

Alegações de desequilíbrio de tráfego ilustram por que a atribuição é essencial. A explicação pública da Level 3 se referia a condições para o arranjo experimental, enquanto o comunicado conjunto posterior descreveu características de tráfego, obrigações de volume e pagamentos condicionais. Essas declarações mostram que critérios comerciais relacionados a tráfego fizeram parte da disputa pública e da remediação. Elas não divulgam as proporções exatas, limites, intervalos de medição ou preços.

Um coletor de rotas não pode preencher essa lacuna. Caminhos AS mostram alcançabilidade anunciada, não volume de tráfego. Até contadores de interface precisariam de contexto sobre localização, direção, agregação e medição contratual. Inferir limites confidenciais de peering a partir de dados BGP públicos confundiria o plano de controle de roteamento com a contabilidade comercial.

A conclusão apropriada é limitada: um desacordo comercial levou à remoção deliberada da troca direta de rotas; alguns clientes, segundo relatos, perderam alcançabilidade; as partes apresentaram publicamente explicações diferentes; e depois restauraram a interconexão em termos revisados que incluíam procedimentos de proteção ao cliente. A evidência não decide o mérito contratual não publicado.

Um mapa de controle para a falha

A Level 3 controlava sua decisão de encerrar a relação de peering direta e seu lado das sessões BGP relevantes. Também controlava as rotas que aceitava e exportava, sua escalação interna, sua comunicação com clientes e qualquer procedimento de terminação escalonada ou imediata que usasse. Essas áreas definem sua responsabilização operacional sem resolver se a terminação era comercialmente justificada.

A Cogent controlava suas próprias sessões, anúncios de rota, políticas de importação e exportação, comunicações com clientes e ofertas de resiliência. Sua declaração de 7 de outubro propôs restauração imediata antes de nova negociação, mas a defesa pública não elimina suas próprias responsabilidades. A Cogent estava posicionada para entender quais clientes dependiam de seus relacionamentos de upstream e peering, quais alternativas podia fornecer e quais limitações acompanhavam a conectividade que vendia.

Ambas as operadoras compartilhavam o controle sobre a restauração bilateral. Um lado podia oferecer restaurar uma sessão, mas a interconexão funcional exigia ação compatível dos dois lados: sessões ativas, rotas aceitas, política viável e encaminhamento funcional. O anúncio conjunto indica que a relação foi restaurada por acordo, não por ação de roteamento unilateral.

Outras operadoras controlavam caminhos alternativos potenciais. Suas políticas determinavam se transportariam rotas entre os dois lados e sob qual relação comercial. Também controlavam capacidade, filtragem e comunicação de incidentes dentro de suas próprias redes. Sua presença na topologia não garantia que forneceriam um caminho aceitável.

Clientes controlavam algumas escolhas de resiliência, incluindo comprar conexões diversificadas, operar BGP, distribuir serviços entre redes ou monitorar alcançabilidade externa. Esse controle era limitado por custo, capacidade técnica, recursos de endereço, disponibilidade contratual e tempo de provisionamento. Seria impreciso tratar todo cliente afetado como capaz de multihoming instantâneo.

Registros controlavam informações sobre números de sistema autônomo e recursos de endereço. Esses registros apoiavam a identidade e a administração de roteamento, mas não impunham um caminho funcional entre AS174 e AS3356. Uma entrada de registro correta podia ajudar um operador a saber quem originou um prefixo ou a quem contatar. Não podia restaurar uma relação BGP encerrada.

Operadores de coletores de rota controlavam a infraestrutura de medição, não os caminhos de produção. Seus arquivos possibilitam análises posteriores, mas um coletor não pode fazer uma operadora aceitar uma rota. A medição é um livro-razão de responsabilização: registra parte do que as redes participantes expuseram. Não substitui a continuidade operacional.

Reguladores podiam examinar a estrutura de mercado e exercer poderes conferidos por lei, mas não operavam os roteadores. Registros da FCC fornecem contexto sobre incentivos de interconexão e efeitos de rede. Eles não estabelecem que a agência dirigiu a restauração de 2005 nem que considerou qualquer empresa legalmente culpada.

Esse mapa impede que a responsabilidade desabe sobre um único ator conveniente. A decisão de terminação, a disputa comercial, o inventário de caminhos alternativos, a resiliência do cliente e a restauração eram controlados por partes diferentes. A responsabilização eficaz registra essas divisões em vez de presumir que o papel de um ator anula todos os outros.

O acordo de 28 de outubro como desenho de remediação

O anúncio conjunto de 28 de outubro importa porque foi além de declarações públicas concorrentes. Cogent e Level 3 disseram ter alcançado um arranjo de peering settlement-free modificado. O comunicado descrevia obrigações ligadas a características e volume de tráfego, pagamentos quando as obrigações não fossem cumpridas e um processo destinado a proteger a conectividade de clientes caso a relação expirasse ou as violações permanecessem sem solução.

Esses elementos abordam várias pressões de falha distintas. Obrigações mensuráveis de tráfego podem tornar os critérios comerciais menos ambíguos entre as partes. Pagamentos condicionais podem fornecer uma alternativa à terminação imediata quando o serviço operacional continua apesar de um desequilíbrio comercial. Um procedimento definido para expiração ou violação não corrigida pode criar tempo para notificar clientes e arranjar caminhos alternativos.

A descrição pública não mostra exatamente como esses mecanismos funcionavam. Não revela limites, fórmulas, prazos, responsáveis pela escalação ou as evidências exigidas para estabelecer conformidade. Também não prova que o pagamento condicional estava disponível em todas as circunstâncias. Qualquer descrição mais forte reconstruiria termos privados que nunca foram publicados.

A provisão de proteção ao cliente é, ainda assim, significativa. Sua inclusão indica que as partes trataram o impacto na conectividade como algo que um acordo de interconexão podia abordar processualmente. Isso é diferente de dizer que o acordo garantia alcançabilidade global ininterrupta. Um procedimento pode reduzir o risco e ainda falhar sob condições imprevistas, capacidade inadequada ou implementação incompleta.

A restauração também exige mais do que assinar termos ou colocar uma sessão BGP em estado estabelecido. As rotas precisam ser trocadas, aceitas e selecionadas. O encaminhamento precisa funcionar nas duas direções. Caminhos alternativos que se tornaram ativos durante a interrupção podem precisar convergir de volta sem causar nova instabilidade. Pontos de extremidade de clientes precisam se tornar alcançáveis a partir das redes relevantes.

O anúncio público estabelece o arranjo restaurado, mas não fornece um registro completo de restauração por cliente. Um relato limitado deve, portanto, dizer que as empresas restauraram a interconexão direta sob termos revisados, não que toda aplicação afetada se recuperou simultaneamente ou que todas as consequências terminaram em um único momento universal.

Orientações posteriores como comparação, não lei retroativa

A RFC 4271 formaliza a estrutura de troca de rotas e decisão do BGP-4. Foi publicada depois da disputa de outubro de 2005, embora documente a família de protocolos já em operação na internet. Ajuda a explicar como rotas são anunciadas, retiradas e selecionadas. Não impõe uma obrigação comercial para que dois sistemas autônomos mantenham peering settlement-free.

A RFC 7454, publicada muito depois, reúne práticas de segurança operacional para sessões BGP. Discute filtragem, proteção de sessão, limites de prefixo e controles de política. Essas práticas são úteis para avaliar como um operador pode tornar o comportamento de interconexão mais previsível e observável. Elas não decidem se qualquer empresa atendeu aos padrões razoavelmente aplicáveis em 2005 e não garantem continuidade após o encerramento intencional de uma sessão.

A RFC 8212 estabelece política explícita de importação e exportação como padrão mais seguro para BGP externo. Essa abordagem reduz a propagação acidental causada por política ausente. O evento Cogent-Level 3 não foi um exemplo de rotas exportadas acidentalmente porque uma configuração vazia adotou comportamento permissivo por padrão. Política explícita pode documentar a intenção, mas ainda permitiria uma decisão deliberada de não trocar rotas.

A RFC 7908 classifica vazamentos de rota. Sua taxonomia ajuda a distinguir propagação não intencional de relações legítimas de cliente, par e trânsito. O evento de 2005 fica fora do modo de falha central dessa taxonomia porque a evidência diz respeito a depeering deliberado. Aplicar a terminologia com cuidado evita que um caminho ausente seja rotulado erroneamente como caminho excessivo ou não autorizado.

A RFC 9234 introduziu posteriormente BGP Roles e mecanismos para expressar a intenção de relacionamento entre sistemas autônomos vizinhos. Expressar melhor os papéis pode ajudar a identificar configurações incompatíveis e restringir a propagação de rotas. Ela não codifica todas as condições comerciais privadas e não obriga duas redes a permanecerem interconectadas após o fim de uma relação.

A RFC 1997 é historicamente diferente porque comunidades BGP já estavam padronizadas antes da disputa. Comunidades podiam ajudar redes a sinalizar preferências de tratamento de rotas. Sua disponibilidade não prova como AS174 ou AS3356 as usaram em outubro de 2005. Nem transforma um valor de comunidade observado em um coletor em uma declaração completa de intenção contratual.

A orientação da MANRS articulou posteriormente ações de operadores envolvendo filtragem, coordenação, validação global e anti-spoofing. A orientação posterior do NIST sobre roteamento interdomínio enfatiza igualmente configuração resiliente, monitoramento e resposta a incidentes. Esses materiais fornecem pontos de comparação contemporâneos úteis: operadores podem manter informações de contato, observar mudanças de rota, validar políticas e preparar procedimentos de resposta.

Nenhum deles é lei retroativa. Nenhum fornece o contrato de 2005 ausente, as medições de tráfego ou os registros internos de escalação. Nenhum prova negligência apenas porque a conduta histórica de um operador difere de uma recomendação posterior. Seu uso adequado é prospectivo: ajudam a traduzir o episódio em controles que as redes atuais podem medir.

A validação de origem moderna baseada em RPKI merece a mesma cautela. Ela pode ajudar uma rede a rejeitar um anúncio de origem inválida. Não estabelece se um par deve carregar uma rota válida, se existe capacidade ou se uma relação comercial precisa continuar. Uma rota pode ser criptograficamente consistente com uma origem autorizada e ainda assim estar inalcançável porque nenhum caminho aceitável cruza a fronteira de rede relevante.

A lição posterior mais transferível, portanto, não é que um mecanismo de segurança teria resolvido a disputa. É que intenção de relacionamento, política de rota, monitoramento, coordenação e planejamento de continuidade precisam estar conectados. Uma rede precisa saber o que pretende trocar, o que está de fato trocando, quais clientes dependem desse estado e como verificará uma saída controlada.

Um padrão mensurável de terminação e restauração

Um padrão útil de responsabilização precisa permanecer neutro em relação ao resultado comercial. Não deve exigir peering indefinido, ditar termos de settlement ou presumir que qualquer participante tem direito a trânsito gratuito. Deve exigir que os operadores tornem as consequências de continuidade de uma terminação planejada observáveis e limitadas.

A primeira medida é cobertura de dependência. Antes de encerrar uma interconexão consequente, cada operadora deve identificar os prefixos de clientes, grupos de destinos ou classes de serviço para os quais a relação direta é o único caminho verificado. O resultado mensurável não é uma alegação de conhecer a internet inteira. É a proporção do inventário de clientes no escopo da operadora para o qual a dependência foi avaliada e registrada com timestamp.

Um registro de dependência deve distinguir observação direta de inferência. Uma rota vista através da interconexão não é necessariamente dependente dela se existir outro caminho aceitável. Um caminho alternativo mostrado em uma topologia não é verificado se o operador nunca testou se ele é exportado, aceito e utilizável. O registro deve, portanto, declarar os pontos de observação, políticas de rota e testes de encaminhamento que sustentam cada classificação.

A segunda medida é verificação de caminhos alternativos. Para cada grupo de dependência, a operadora deve registrar se existe pelo menos uma rota alternativa testada, se os caminhos de ida e volta funcionam e se o caminho tem capacidade operacional suficiente para o serviço pretendido. A métrica relevante é cobertura verificada: unidades alcançáveis testadas divididas por todas as unidades que se espera precisar de alternativa.

Essa proporção precisa carregar informações de escopo. Um resultado alto medido apenas a partir dos roteadores da própria operadora não estabelece alcançabilidade externa. Os testes devem incluir redes independentes que representem caminhos materialmente diferentes. O padrão não precisa prescrever um número universal de pontos de observação; deve exigir que a operadora declare por que o conjunto escolhido representa os clientes e regiões em risco.

A terceira medida é prontidão de política. O operador deve preservar a política de importação e exportação pretendida antes, durante e depois da terminação, juntamente com o responsável e o tempo de ativação. Essa evidência permite distinguir uma retirada planejada de um vazamento acidental, erro de configuração ou falha de sessão não relacionada.

A prontidão de política também inclui uma simulação ou teste controlado quando viável. Um operador pode reduzir a preferência pela rota direta ou testar prefixos de clientes selecionados por alternativas antes de encerrar a relação. Esse teste pode não ser possível em toda arquitetura e pode, ele próprio, criar risco. O requisito responsável é documentar se foi realizado, o que cobriu e por que qualquer dependência não testada foi aceita.

A quarta medida é prontidão de capacidade. Um caminho BGP alternativo não é um controle de continuidade se colapsa sob o tráfego redirecionado comum. Os operadores devem registrar a capacidade testada das alternativas relevantes, as classes de tráfego incluídas e o momento do teste. Isso não exige publicar volumes confidenciais. Exige evidência interna suficiente para estabelecer que rotear ao redor da interconexão era mais do que uma possibilidade teórica.

A quinta medida é aviso e escalação. Um plano de terminação deve identificar o responsável pela decisão, o responsável pelas operações de rede, o responsável pela comunicação com clientes e o contato da contraparte. Deve registrar quando cada um foi notificado e quando clientes em grupos de dependência identificados receberam informações acionáveis.

Aviso acionável deve explicar o risco operacional, em vez de apenas descrever uma disputa comercial. O cliente precisa saber quais serviços podem perder alcançabilidade, que conectividade alternativa está disponível, quais testes deve realizar e onde relatar uma falha. A métrica é cobertura e tempo decorrido: quantos clientes dependentes identificados receberam aviso e quanto tempo antes ou depois da mudança de roteamento esse aviso ocorreu.

O padrão deve permitir uma exceção de emergência. Incidentes de segurança, falhas não controladas ou riscos contratuais imediatos podem tornar o aviso prévio impossível. Uma exceção não deve apagar a evidência. Deve registrar o motivo da ação imediata, a pessoa que a autorizou, as salvaguardas consideradas e o primeiro momento em que clientes e contraparte foram informados.

A sexta medida é observabilidade do evento. Na terminação, ambas as operadoras devem preservar estado de sessão, contagens de rotas, anúncios e retiradas relevantes, mudanças de caminhos aceitos e resultados de testes de encaminhamento. Uma única entrada “sessão fora do ar” é insuficiente porque o efeito sobre o cliente depende das rotas e caminhos que desaparecem com ela.

A observabilidade deve produzir uma matriz de alcançabilidade, não um único percentual global. As linhas podem representar redes de origem testadas ou coortes de clientes; as colunas podem representar prefixos de destino ou serviços relevantes. Cada célula pode registrar alcançável, inalcançável, degradado ou não verificado, com timestamp e ponto de observação. Isso expõe a incerteza em vez de converter espaço não medido em sucesso presumido.

A sétima medida é desempenho de detecção. Um operador deve saber quanto tempo o monitoramento levou para identificar a perda de alcançabilidade após a mudança de roteamento. O relógio não deve parar quando a sessão BGP muda de estado. Deve parar quando o sistema identifica a consequência voltada ao cliente com especificidade suficiente para agir.

A detecção deve separar sinais de plano de controle e plano de dados. Uma retirada de rota pode prever dano, enquanto sondas ativas estabelecem se pacotes ainda viajam por um caminho alternativo. Verificações de aplicação podem mostrar se um serviço funciona após a convergência do roteamento. Manter essas medidas separadas evita que uma entrada da tabela de rotas seja confundida com serviço ao cliente concluído.

A oitava medida é comunicação de incidente. Durante a interrupção, declarações de status devem distinguir fatos verificados de hipóteses e posições comerciais atribuídas. Uma operadora deve relatar o que mudou, que escopo mediu, o que permanece desconhecido e quando fornecerá outra atualização. Declarações como “a internet continua disponível” são inadequadas se ocultam partições conhecidas entre grupos de clientes.

A nona medida é restauração limitada. A restauração começa quando as partes tomam ação corretiva, mas não está completa apenas porque uma sessão retorna a um estado estabelecido. Uma operadora deve verificar que os prefixos esperados estão sendo trocados, as políticas os estão aceitando, os caminhos selecionados estão estáveis e o encaminhamento tem sucesso a partir de redes externas representativas.

Um registro de restauração deve preservar timestamps separados para estabelecimento de sessão, aceitação de rota, primeiros testes bem-sucedidos de plano de dados, recuperação de cada coorte de clientes e encerramento de reclamações pendentes. Esses timestamps impedem que um evento tecnicamente conveniente — como o primeiro keepalive BGP — seja apresentado como o fim universal do dano ao cliente.

A décima medida é reconciliação do estado de rotas. Caminhos usados durante a interrupção podem continuar preferidos após o retorno do peering direto, ou o tráfego pode oscilar enquanto as políticas reconvergem. Os operadores devem comparar o estado pós-restauração pretendido com as rotas observadas e investigar diferenças materiais. O objetivo não é forçar todas as rotas de volta ao caminho anterior; é garantir que o estado resultante seja compreendido e utilizável.

A décima primeira medida é exposição não verificada. Todo registro de terminação deve declarar quantos prefixos, grupos de clientes ou regiões externas no escopo não foram testados. Cobertura desconhecida é um fato de responsabilização, não um campo vazio. Relatá-la impede que uma amostra limitada bem-sucedida se torne uma alegação insustentável de recuperação universal.

A décima segunda medida é retenção de evidências. Observações de rotas, mudanças de configuração, avisos, mensagens de incidente e testes de restauração devem ser retidos sob uma linha do tempo consistente. Coletores públicos continuam sendo referências independentes valiosas, mas as evidências das próprias operadoras devem ser mais completas, pois elas podem ver preferência local, rotas rejeitadas, topologia interna e associação de clientes.

Essas medidas podem ser resumidas como uma cadeia de continuidade:

Identificar quem depende da interconexão.
Verificar quais caminhos alternativos realmente funcionam.
Registrar política, capacidade e responsabilidade pela decisão.
Notificar a contraparte e os clientes afetados sob um procedimento declarado.
Observar tanto o estado das rotas quanto a entrega de pacotes durante a mudança.
Medir o dano por coortes limitadas e pontos de observação independentes.
Restaurar sessões, rotas aceitas e encaminhamento.
Reconciliar o estado resultante e preservar a incerteza não resolvida.

Nenhuma evidência pública mostra que essa cadeia completa existia para qualquer operadora em 2005. O padrão não deve ser apresentado como uma obrigação histórica que as empresas necessariamente violaram. É uma forma de converter as pressões de falha demonstradas pelo evento em prática atual mensurável.

Ele também evita impor uma garantia impossível. Nenhum operador pode provar alcançabilidade de todas as redes para todos os terminais em todos os momentos. O que um operador pode provar é o escopo que avaliou, as alternativas que testou, as observações que reteve, os clientes que avisou e as condições sob as quais declarou restauração.

O que o registro público ainda não consegue estabelecer

O contrato de peering completo permanece indisponível. As declarações públicas não revelam todas as proporções de tráfego, janelas de medição, capacidades de porta, preços, períodos de correção ou direitos de terminação. Sem esses fatos, um relato externo não pode determinar se qualquer empresa cumpriu ou violou suas obrigações privadas.

O estado de roteamento completo também é desconhecido. RouteViews, RIPE RIS e Merit fornecem observações valiosas, mas não expõem todos os pares privados, preferências locais, rotas rejeitadas ou decisões de encaminhamento. Os dados públicos sobreviventes não podem identificar todos os prefixos ou clientes afetados.

O dano ao cliente não pode ser quantificado com precisão a partir do registro congelado. A cobertura contemporânea sustenta a conclusão de que algumas empresas e usuários experimentaram falhas de alcançabilidade. Ela não estabelece a receita total perdida, a duração para cada cliente, consequências em nível de aplicação em todos os serviços ou efeitos iguais nas duas redes.

A responsabilidade interna pela decisão não é pública. A Level 3 controlou sua ação de terminação, mas o material disponível não identifica todos os executivos ou aprovadores operacionais, a sequência de escalação ou os testes internos realizados antes da mudança. O processo de resposta interno e a avaliação de resiliência da Cogent são igualmente incompletos.

O acordo revisado é evidência de um desenho de remediação, não prova completa de implementação. Sua descrição pública indica obrigações de tráfego, pagamentos condicionais e um processo de proteção ao cliente. Não mostra como cada controle foi posteriormente testado ou se teria abordado todos os cenários futuros de falha.

A alocação jurídica permanece não resolvida aqui. Discussões posteriores da FCC fornecem contexto regulatório, mas os registros citados não estabelecem conclusão de ilegalidade, quebra contratual, negligência ou má-fé neste evento. O controle operacional e a responsabilização mensurável podem ser analisados sem convertê-los em conclusões jurídicas.

Continuidade é comprovada por rotas que funcionam

O depeering Cogent-Level 3 de 2005 continua instrutivo porque desfez a suposição de que o status de rede principal garante alcançabilidade universal. AS174 e AS3356 permaneceram, cada um, redes identificáveis com recursos registrados, clientes e conexões em outros lugares. Ainda assim, alguns caminhos através da antiga relação pararam de funcionar, e alguns clientes, segundo relatos, não conseguiram rotear ao redor da divisão.

O fato central do evento não foi apenas que duas empresas discordaram. Foi que uma decisão comercial bilateral alterou a disponibilidade de rotas interdomínio. Retiradas BGP, propagação alternativa, políticas de importação e exportação, multihoming e restauração determinaram o resultado prático.

As evidências públicas sustentam uma conclusão cautelosa. A Level 3 encerrou deliberadamente o peering direto em 5 de outubro. A Cogent buscou publicamente a restauração antes de nova negociação. A Level 3 disse que o arranjo experimental não atendia mais às suas condições. Parte da alcançabilidade de clientes foi interrompida, embora o escopo completo seja desconhecido. Em 28 de outubro, as empresas anunciaram peering settlement-free restaurado sob termos revisados que incluíam um processo destinado a proteger clientes durante uma expiração futura ou violação não resolvida.

Nada nessa conclusão exige decidir o mérito contratual privado. Nem exige peering obrigatório. Exige reconhecer que o controle autônomo carrega um dever probatório quando seu exercício pode isolar clientes dependentes.

Um registro pode registrar quem detém um bloco de endereços. Um contrato pode registrar obrigações comerciais. Uma declaração de status pode registrar a posição de uma parte. A alcançabilidade total da internet é comprovada em outro lugar: em rotas que são de fato anunciadas, aceitas, selecionadas e encaminhadas, com alternativas observáveis quando uma relação direta termina.

Esse é o teste duradouro de responsabilização. Antes de encerrar uma interconexão consequente, saiba quais clientes dependem dela. Durante a mudança, meça o que desaparece em vez de presumir que o resto da internet contornará o problema. Após a restauração, verifique os caminhos dos clientes em vez de parar na assinatura do contrato ou no estado da sessão BGP. O registro é útil apenas quando corresponde a um caminho em execução.

O depeering Cogent-Level 3 de 2005 transformou a alcançabilidade total da internet em um teste de responsabilização do trânsito

Por que isso importa