Cogent-Level 3 2005: depeering y responsabilidad del tránsito

Resumen

Level 3 dejó de intercambiar tráfico directamente con Cogent el 5 de octubre de 2005. El registro público muestra que algunos clientes perdieron alcanzabilidad hacia destinos del otro lado de la división, mientras que el impacto completo en clientes y prefijos sigue sin conocerse. [1][21][22]
Cogent pidió públicamente a Level 3 que restableciera la conexión antes de seguir negociando. La posición pública preservada de Level 3 afirmaba que el acuerdo de prueba ya no cumplía sus condiciones. Se trata de posiciones comerciales atribuidas, no de conclusiones de que alguno de los operadores incumpliera un contrato o actuara de forma ilegal. [1][22]
Un prefijo registrado y un contrato de cliente no creaban una ruta operativa. La alcanzabilidad dependía de las rutas que AS174 y AS3356 intercambiaban, aceptaban y seleccionaban, junto con cualquier tránsito alternativo o multihoming que los clientes tuvieran realmente.
Merit utilizó observaciones seleccionadas de RouteViews para estudiar la alcanzabilidad del bloque 38.0.0.0/8 de Cogent. RouteViews y RIPE RIS pueden preservar anuncios y retiros de los coleccionistas participantes, pero no pueden revelar todas las políticas privadas, preferencias locales, rutas de clientes o términos comerciales. [8]-[10]
El multihoming reducía el riesgo solo cuando los proveedores alternativos, los anuncios aceptados, la capacidad y las dependencias de las aplicaciones eran genuinamente independientes. Un segundo contrato sin una ruta alternativa efectiva no era continuidad.
El 28 de octubre, los operadores anunciaron un acuerdo modificado de peering sin liquidación con obligaciones de tráfico, pagos condicionales y un proceso destinado a proteger a los clientes si la relación expiraba más tarde o las violaciones no se subsanaban. El comunicado público describe un diseño de control, no la prueba de que todo riesgo futuro de interconexión desapareciera. [2]
La orientación posterior de BGP, MANRS y NIST ayuda a definir controles medibles como política explícita, supervisión de rutas, límites max-prefix, coordinación y evidencia de incidentes. Es material comparativo, no ley retroactiva para el evento de 2005. [13]-[20]
El estándar de responsabilidad es operativo: mapear a los clientes dependientes, demostrar alcanzabilidad alternativa antes de la terminación, observar el impacto en rutas y transacciones durante el cambio, preservar un proceso de curación acotado y verificar la restauración desde fuera de ambas redes de operadores.

La alcanzabilidad de Internet suele venderse como si fuera una propiedad estable. Un cliente recibe una dirección, se conecta a un operador ascendente y ve rutas hacia destinos de todo el mundo. Desde esa perspectiva, «Internet» parece un servicio continuo. Sin embargo, en el plano de control, la alcanzabilidad no es una promesa institucional. Es el resultado actual de redes independientes que anuncian prefijos, aceptan o rechazan esos anuncios, seleccionan rutas y reenvían tráfico según sus propias políticas.

La disputa de octubre de 2005 entre Cogent Communications, operador de AS174, y Level 3 Communications, operador de AS3356, puso de manifiesto esa diferencia. El 5 de octubre, Level 3 dejó de intercambiar tráfico directamente con Cogent. Las declaraciones y noticias contemporáneas describían que clientes de ambas redes perdían acceso a algunos destinos al otro lado de la división resultante. Las empresas seguían conectadas a otras partes de Internet y el evento no dividió toda la red global.

Pero donde no había una ruta alternativa aceptable que uniera un destino alcanzable por Cogent con un origen alcanzable por Level 3, los registros y las expectativas de los clientes no podían hacer que los paquetes cruzaran la interconexión desaparecida.

Se trató de un depeering deliberado, no de una fuga de rutas, un secuestro de rutas ni un anuncio BGP accidental. La falla operativa provino de la eliminación de una ruta que previamente transportaba tráfico entre dos grandes redes. Esa distinción determina qué evidencia importa. Los investigadores deben examinar la decisión de interconexión, los cambios de rutas BGP, las rutas alternativas, la dependencia de los clientes, el multihoming, la comunicación y la restauración. Un relato genérico de un desacuerdo comercial omite el mecanismo que hizo que el desacuerdo tuviera consecuencias.

El episodio también pone a prueba un tipo particular de responsabilidad. El peering y el tránsito son acuerdos comerciales diferentes, y el registro público describe la relación restaurada como peering sin liquidación en lugar de tránsito pagado. Sin embargo, ambas empresas vendían conectividad dentro de un ecosistema cuyo valor dependía de la alcanzabilidad interdominio. La cuestión de responsabilidad, por tanto, no es si dos redes autónomas deben hacer peering gratuito.

Es si los operadores que controlan una interconexión con consecuencias pueden identificar la dependencia de los clientes, gestionar la terminación sin ocultar las consecuencias operativas, preservar evidencia y demostrar la restauración.

La alcanzabilidad existe en la ruta operativa

Una asignación de direcciones IP puede identificar al titular de un bloque. Un número de sistema autónomo puede identificar un dominio de enrutamiento. Un contrato puede indicar lo que un cliente compró, y un acuerdo de interconexión puede describir lo que dos operadores esperan el uno del otro. Ninguno de esos registros, por sí solo, instala una ruta en la tabla de reenvío de un enrutador.

Para que un paquete viajara desde un cliente detrás de AS174 hasta un destino detrás de AS3356, las redes relevantes necesitaban una secuencia de rutas aceptadas en ambas direcciones. Esa secuencia podía usar la interconexión directa Cogent-Level 3. También podía pasar por otro operador si las políticas de exportación, las relaciones comerciales, la capacidad y la selección de rutas lo permitían. Si ninguna red anunciaba una alternativa aceptable, el destino podía permanecer válidamente registrado y correctamente originado y, aun así, ser inalcanzable desde el otro lado.

Esto convierte la «alcanzabilidad total de Internet» en una abreviatura operativa más que en una garantía absoluta de que todo host responderá siempre. Los cortafuegos, los fallos de las aplicaciones y las políticas locales pueden hacer que un servicio concreto no esté disponible aunque exista una ruta de red. La cuestión relevante en la disputa de 2005 es más estrecha: ¿proporcionaba el enrutamiento interdominio ordinario rutas utilizables entre prefijos cuya conexión práctica dependía de la relación AS174-AS3356?

La etiqueta de mercado de un operador no puede responder a esa pregunta. Describir una red como una gran troncal o un operador Tier 1 puede indicar escala o posición comercial, pero no crea una obligación de enrutamiento impuesta globalmente. Cada sistema autónomo conserva el control sobre las rutas que exporta, las rutas que acepta y las rutas que prefiere. Internet no tiene un enrutador central que pueda ordenar a dos redes intercambiar tráfico después de que terminan una relación bilateral.

Esa independencia es una de las fortalezas de Internet. Permite que las redes tomen decisiones distintas de seguridad, ingeniería y comercio sin pedir permiso a una autoridad central. La misma independencia crea un problema de continuidad: una decisión bilateral puede tener efectos más allá de las dos partes cuando los clientes no tienen una ruta utilizable que la rodee. La responsabilidad debe, por tanto, seguir al control práctico y no a las etiquetas.

El operador que controla una sesión controla si esa sesión sigue disponible; un operador que vende conectividad controla qué resiliencia suministra o recomienda; un cliente controla su propia redundancia solo dentro de límites técnicos y financieros.

El evento de 2005 unió estas capas. Las empresas tenían un desacuerdo comercial, pero su efecto sobre los clientes se expresó a través de BGP. Los hechos decisivos no fueron simplemente lo que las partes creían que exigía el acuerdo. Fueron qué rutas dejaron de intercambiarse, qué rutas alternativas seguían siendo aceptables, qué clientes dependían de la ruta eliminada y cómo se restableció la relación directa.

Una cronología acotada de la disputa de octubre

La cronología defendible comienza el 5 de octubre de 2005, cuando Level 3 detuvo el intercambio directo de tráfico con Cogent. El material público describe la acción como la terminación de la relación directa de peering entre las empresas. La evidencia disponible no establece la disposición física completa de esa interconexión, el número de sesiones o puertos implicados, ni la capacidad en cada ubicación. Por tanto, «la conexión» no debe leerse como prueba de que un solo cable o un solo enrutador representaba toda la relación.

Las noticias contemporáneas pronto enmarcaron la consecuencia como un problema de alcanzabilidad. Algunos usuarios y empresas conectados a través de una red supuestamente no podían alcanzar destinos dependientes de la otra. Esos relatos respaldan la conclusión de que el depeering tuvo efectos reales sobre los clientes. No establecen una lista completa de prefijos afectados, una interrupción universal en ninguno de los operadores, un impacto igual en ambos lados ni un porcentaje preciso de Internet que quedó inalcanzable.

El 7 de octubre, Cogent pidió públicamente a Level 3 que restableciera la interconexión antes de que las empresas continuaran las negociaciones. Esa declaración es evidencia de la posición de Cogent y de la secuencia propuesta: restablecer primero la conectividad de los clientes y luego abordar la disputa. No establece de forma independiente las obligaciones confidenciales de ninguna de las partes, ni decide si el acuerdo anterior cumplía sus condiciones.

Level 3 ofreció una explicación pública diferente. Su declaración, preservada en la cobertura contemporánea, describía la relación interrumpida como un acuerdo de peering de prueba que ya no cumplía las condiciones aplicables. Eso es evidencia de la razón declarada por Level 3. El registro público no proporciona el acuerdo completo, las mediciones utilizadas para evaluarlo, las características precisas de tráfico en cuestión ni las deliberaciones internas que llevaron a la terminación. No puede respaldar la conclusión de que Cogent incumplió un término no publicado concreto ni de que la evaluación de Level 3 fuera incorrecta.

Las discusiones de operadores archivadas por NANOG documentaron preguntas contemporáneas sobre rutas y alcanzabilidad. Estos mensajes son valiosos porque muestran lo que los ingenieros de red observaban y probaban mientras se desarrollaba el evento. No son un censo controlado de Internet. Los participantes tenían diferentes puntos de vista, relaciones comerciales y acceso a la información de enrutamiento. El informe de una red podía describir con exactitud la ruta de esa red sin establecer lo que veían las demás.

El 28 de octubre, Cogent y Level 3 anunciaron conjuntamente que habían alcanzado un acuerdo modificado de peering sin liquidación. Su comunicado describía obligaciones relativas a las características y el volumen del tráfico, pagos si esas obligaciones no se cumplían y un proceso destinado a reducir el daño a los clientes si la relación expiraba más tarde o una violación quedaba sin corregir. El anuncio es la evidencia pública compartida más sólida sobre la estructura de la reparación, porque ambas empresas lo emitieron juntas.

El comunicado seguía sin ser el contrato completo. No revelaba públicamente todos los umbrales, métodos de medición, períodos de curación, procedimientos operativos ni derechos de decisión. Su existencia tampoco demuestra que todas las rutas de los clientes se restablecieran en el mismo momento ni que todos los riesgos posteriores de interconexión desaparecieran. Demuestra que las empresas restablecieron su relación en términos revisados e identificaron públicamente procedimientos de protección de clientes como parte de la solución.

Registros posteriores de la FCC analizaron el evento en estudios más amplios sobre interconexión de Internet, competencia de redes troncales y alcanzabilidad de los clientes. Esos registros ayudan a explicar por qué una disputa entre grandes redes podía afectar a partes que no eran signatarias del acuerdo de peering. No deben convertirse en un juicio legal sobre la conducta de 2005. Los materiales citados no establecen que ninguno de los operadores violara una ley, una regulación o un contrato.

Qué cambió en BGP

BGP permite que los sistemas autónomos intercambien información de alcanzabilidad. Un anuncio de ruta identifica un prefijo alcanzable y lleva atributos que ayudan a las redes receptoras a aplicar políticas y seleccionar rutas. La ruta AS registra los sistemas autónomos por los que se ha propagado el anuncio, mientras que otros atributos y preferencias configuradas localmente influyen en qué ruta instala una red.

El proceso de decisión es descentralizado. Cogent podía anunciar prefijos de clientes e internos a Level 3 según su política de exportación. Level 3 podía aceptar, filtrar o preferir esos anuncios según su política de importación y luego exponer las rutas seleccionadas a los clientes o pares apropiados. El proceso inverso se aplicaba a las rutas de Level 3 que llegaban a Cogent. Ninguna de las empresas controlaba todas las redes intermedias y ninguna podía obligar a un tercero a exportar una ruta alternativa.

Cuando se termina una relación BGP externa directa, las rutas aprendidas exclusivamente a través de esa relación dejan de ser utilizables tras los retiros, la pérdida de sesión o la eliminación de políticas. Los enrutadores reconsideran entonces otras rutas disponibles. Si un operador diferente anuncia una ruta aceptable, el tráfico puede pasar a esa ruta. Si no hay alternativas, están filtradas o no están disponibles comercialmente, el enrutador afectado no tiene ruta utilizable hacia el destino.

Por eso el mismo depeering puede producir resultados distintos para diferentes clientes. Una red puede tener otro ascendente que lleve una ruta entre los dos lados. Otra puede aprender solo las rutas que desaparecieron con la sesión directa. Una tercera puede ver una ruta alternativa pero rechazarla por políticas, reglas de longitud de prefijo o restricciones de relación. Una cuarta puede seleccionar una ruta alternativa cuya capacidad o ruta de retorno no soporte tráfico de aplicación fiable.

La pérdida de la ruta directa tampoco tiene por qué producir síntomas simétricos. Las decisiones BGP se toman por separado en cada red, y el tráfico de datos requiere rutas de ida y vuelta viables. Un paquete puede llegar a un destino mientras su respuesta no encuentra una ruta utilizable de vuelta. Diferentes preferencias locales pueden enviar las dos direcciones a través de sistemas autónomos distintos. Por consiguiente, una observación de ruta exitosa en una dirección no demuestra un servicio bidireccional completo.

El registro público no expone las configuraciones completas de preferencia local de Cogent y Level 3. No revela todos los filtros de rutas, el tratamiento de comunidades, los pares privados ni los acuerdos de tránsito con terceros. Las rutas AS públicas pueden sugerir cómo pudo moverse el tráfico, pero no pueden revelar todas las políticas internas que determinaron la selección de rutas.

Las comunidades BGP añaden otra posible capa de evidencia. El RFC 1997, anterior al evento, define una forma de adjuntar etiquetas relevantes para políticas a las rutas. Las redes pueden usar comunidades para solicitar o señalar comportamientos de propagación. Sin embargo, el significado y la implementación de muchas comunidades son específicos de cada red. Incluso cuando una comunidad aparece en una actualización pública, no revela automáticamente el acuerdo privado que rige la ruta ni demuestra que todos los enrutadores aplicaran la política prevista.

Por tanto, el evento no puede reducirse a «las rutas desaparecieron en todas partes». AS174 y AS3356 siguieron operando, y los prefijos asociados a ellos podían seguir siendo visibles desde muchas ubicaciones. La cuestión más específica era si las rutas que cruzaban la antigua relación seguían disponibles a través de otras redes. Un prefijo visible en un coleccionista podía ser inalcanzable desde un cliente concreto. A la inversa, una ruta ausente en un coleccionista podía seguir siendo alcanzable en otro lugar a través de una ruta privada o seleccionada de forma diferente.

La validez de la ruta tampoco puede garantizar la conectividad. Un prefijo correctamente originado puede ser inalcanzable porque ninguna ruta aceptable llega a una red determinada. Los mecanismos modernos de validación de origen pueden ayudar a determinar si un origen está autorizado, pero no pueden obligar a dos sistemas autónomos a mantener una sesión de peering ni exigir a una tercera red que transporte tráfico entre ellos. La falla de 2005 fue de disponibilidad de rutas y de políticas, no simplemente de propiedad de direcciones o autenticidad del origen.

Por qué algunas redes pudieron enrutar alrededor de la división

El multihoming es el mecanismo de resiliencia más obvio en un evento de depeering. Un cliente conectado a más de un ascendente puede anunciar su prefijo a través de varias redes y aprender destinos por más de una ruta. Si un ascendente pierde alcanzabilidad hacia parte de Internet, el otro puede conservar una ruta utilizable.

Esa descripción es técnicamente sólida pero incompleta como respuesta de responsabilidad. El multihoming exige más que firmar un segundo contrato de acceso. El cliente puede necesitar espacio de direcciones que ambos ascendentes acepten, un número de sistema autónomo, equipos de enrutamiento compatibles, personal capaz de operar BGP, filtros de rutas, supervisión, controles de seguridad y capacidad suficiente en la conexión alternativa. La ruta de retorno también debe converger en una ruta funcional.

Las aplicaciones con cortafuegos con estado, dependencias de direcciones o sensibilidad a los cambios de ruta pueden requerir ingeniería adicional.

La política comercial también importa. Un operador alternativo debe estar dispuesto y ser capaz de exportar las rutas relevantes. Un cliente no puede asumir que dos conexiones cualesquiera crean una ruta a través de cada disputa entre redes ascendentes. Los filtros de longitud de prefijo pueden impedir que anuncios más específicos se propaguen. Un circuito alternativo dimensionado para tráfico de gestión de emergencias puede no soportar la carga de producción ordinaria. Una conexión nominalmente diversa puede compartir instalaciones físicas o una dependencia ascendente común.

Por esas razones, la existencia de multihoming no demuestra que todos los clientes multihomed conservaran el servicio. Establece un control posible cuya eficacia debe probarse. Del mismo modo, la ausencia de multihoming no establece por sí sola imprudencia. Los clientes pequeños pueden carecer de presupuesto, experiencia, recursos de direcciones o poder de negociación para operar conexiones enrutadas de forma independiente. Un servicio vendido como acceso ordinario a Internet puede consumirse razonablemente sin que el cliente construya una troncal en miniatura.

Los clientes con un solo ascendente se enfrentaban a una dependencia más aguda. Si su único ascendente carecía de una ruta aceptable hacia destinos del otro lado, no podían recrear una interconexión de troncal después del depeering. Podían buscar servicio de emergencia de otro operador, pero el aprovisionamiento, la aceptación de rutas, los equipos y los contratos llevan tiempo. La parte que controlaba la interconexión eliminada podía cambiar la disponibilidad de rutas mucho más rápido de lo que muchos clientes dependientes podían reemplazarla.

Los operadores terceros eran otra parte de la ruta. Una red alternativa podía tener relaciones tanto con Cogent como con Level 3 y, sin embargo, su política de exportación podía no permitirle actuar como intermediario entre ellos. El enrutamiento interdominio suele reflejar roles comerciales: un operador puede anunciar rutas de clientes ampliamente mientras se niega a proporcionar tránsito gratuito entre pares. Las rutas BGP públicas pueden respaldar inferencias sobre estas relaciones, pero la documentación de CAIDA subraya que los acuerdos comerciales subyacentes son generalmente confidenciales y a menudo deben inferirse.

Esto importa porque un dibujo topológico puede exagerar la resiliencia. Dos redes pueden conectarse ambas a un tercer sistema autónomo sin obtener una ruta utilizable a través de él. La cuestión relevante no es si existe una línea en un mapa. Es si las rutas se exportan, se aceptan y se seleccionan bajo políticas reales, con suficiente capacidad de reenvío para transportar el tráfico resultante.

Una evaluación de continuidad defendible clasificaría, por tanto, a los clientes según la dependencia observada y no según una simple etiqueta de multihomed o single-homed. Preguntaría qué prefijos tenían rutas alternativas verificadas, qué servicios tenían alcanzabilidad bidireccional, si la capacidad seguía siendo adecuada y cuánto tiempo experimentó deterioro cada cohorte de clientes. La evidencia pública congelada no proporciona esa matriz completa para octubre de 2005, por lo que las afirmaciones sobre la distribución del impacto deben permanecer limitadas.

Reconstruir el evento a partir de evidencia pública de rutas

Los coleccionistas públicos de rutas proporcionan una ventana importante pero parcial al incidente. RouteViews archivó actualizaciones BGP de octubre de 2005, lo que permitió a los investigadores inspeccionar anuncios y retiros recibidos de pares participantes. RIPE RIS explica el papel comparable de los coleccionistas distribuidos: registran la información de enrutamiento visible desde redes que deciden hacer peering con ellos.

El estudio de caso de inspección BGP de Merit trata el evento Cogent-Level 3 como un ejercicio de análisis de rutas y examina la alcanzabilidad del bloque 38.0.0.0/8 de Cogent desde pares seleccionados de RouteViews. Es una investigación acotada y útil. No transforma un agregado y un conjunto de puntos de observación seleccionados en un inventario completo de clientes de Cogent, clientes de Level 3 o rutas afectadas globalmente.

Una reconstrucción rigurosa comienza separando los anclajes del evento de las observaciones de rutas. Las declaraciones de las empresas establecen que la relación directa fue terminada deliberadamente y luego restaurada. Los datos de los coleccionistas pueden mostrar cómo aparecían rutas particulares ante los pares participantes antes, durante y después de esos cambios. Los mensajes contemporáneos de operadores, los traceroutes y los informes de clientes pueden comprobar si los cambios observados en el plano de control correspondían a fallos de reenvío o de aplicación.

La alineación de marcas temporales importa. Los flujos de actualizaciones BGP contienen cambios ordinarios de enrutamiento además de cambios relacionados con el incidente. Las sesiones se reinician por muchas razones; los prefijos pueden retirarse y volver a anunciarse independientemente de una disputa de peering. Un investigador no debe etiquetar cada actualización cercana al 5 de octubre como causada por el depeering. La inferencia más sólida proviene de cambios repetidos que afectan rutas relevantes, tiempos consistentes en puntos de observación independientes y corroboración de observaciones operativas.

La diversidad de coleccionistas importa igualmente. Un par de RouteViews suministra las rutas que seleccionó y decidió exportar al coleccionista. No expone todas las rutas que ese par consideró, todas las rutas rechazadas por política ni todas las entradas de la tabla de reenvío dentro de la red. Un coleccionista RIS tiene la misma limitación básica. Añadir coleccionistas aumenta la visibilidad, pero ningún conjunto finito produce una visión omnisciente de cada interconexión privada y cada enrutador.

La evidencia de rutas AS también exige moderación. La ruta visible identifica los sistemas autónomos enumerados en el anuncio seleccionado. No revela saltos internos de enrutador, utilización de puertos, precios contractuales ni todo el tráfico realmente reenviado por esa ruta. La preferencia local normalmente no se propaga entre sistemas autónomos, por lo que un observador externo puede no saber por qué ganó una ruta. El peering privado puede permanecer ausente de los datos públicos de los coleccionistas.

Un retiro es igualmente ambiguo sin contexto. Puede significar que una ruta ya no está disponible para el par que anuncia, que la política de exportación cambió o que una sesión falló. No identifica por sí solo la decisión comercial detrás del cambio. En este caso, las declaraciones de las empresas proporcionan la intención que las actualizaciones brutas no pueden: la interconexión terminó deliberadamente.

Los traceroutes añaden pistas de reenvío pero no omnisciencia. Los enrutadores pueden suprimir respuestas, usar direcciones no relacionadas con la ruta aparente o reenviar tráfico de forma asimétrica. Un traceroute que se detiene no siempre identifica el punto exacto del fallo. Un traceroute exitoso desde una ubicación no establece la alcanzabilidad desde todas las ubicaciones. Aun así, las trazas repetidas desde redes independientes pueden ayudar a distinguir un problema local de aplicación de una ausencia más amplia de rutas interdominio.

Los informes de clientes añaden otra capa. Una empresa incapaz de llegar a un sitio al otro lado de la división proporciona evidencia de daño práctico. Sin embargo, el informe por sí solo puede no identificar qué ascendente, política de ruta o ruta de retorno causó el fallo. El relato más defendible alinea la queja con los prefijos de origen y destino, las marcas temporales, las observaciones BGP y, cuando están disponibles, las pruebas de ruta de ida y vuelta.

La evidencia resultante debe expresarse en niveles de confianza. Un anuncio directo de la empresa puede establecer que la relación fue terminada o restaurada. Un coleccionista puede establecer que un par participante anunció una ruta particular en un momento particular. Múltiples observaciones independientes de rutas y reenvío pueden respaldar una inferencia más amplia. Ninguna de ellas proporciona por sí sola la lista completa de clientes, el contrato privado o el impacto mundial preciso.

Los materiales de la FCC añaden contexto de mercado más que pruebas a nivel de paquete. Su análisis de la interconexión de redes troncales y los efectos de red ayuda a explicar por qué los clientes valoran el acceso a destinos fuera de su propio operador. Las referencias regulatorias posteriores a la disputa Cogent-Level 3 muestran su relevancia para la política de interconexión. No sustituyen la evidencia de rutas y no deciden la responsabilidad legal por pérdidas individuales de clientes.

Por qué esto no fue una fuga ni un secuestro de rutas

Una fuga de rutas implica generalmente la propagación de información de enrutamiento más allá del alcance previsto por las relaciones relevantes. El problema resultante suele ser la presencia o selección de una ruta no intencionada. Un secuestro de rutas implica generalmente un origen no autorizado u otra afirmación de enrutamiento falsa que desvía o intercepta tráfico. Ambos pueden crear fallos de alcanzabilidad y seguridad, pero sus mecanismos difieren del depeering deliberado.

El evento Cogent-Level 3 se refería a la eliminación del intercambio directo de rutas. Las declaraciones públicas describen una decisión intencional de interconexión. El fallo central fue que algunas rutas ya no estaban disponibles, no que un operador originara falsamente los prefijos del otro ni que se anunciara accidentalmente como tránsito para rutas que no debía propagar.

Esa diferencia cambia los controles apropiados. El filtrado de prefijos y la validación de origen pueden reducir la aceptación de anuncios no autorizados. La política de exportación consciente de las relaciones puede reducir las fugas de rutas. Esos mecanismos no obligan a un operador a continuar una relación de peering válida. Un enrutador perfectamente filtrado puede seguir sin tener ruta hacia un destino después de una terminación deliberada de la sesión.

Los datos BGP brutos no siempre pueden revelar la distinción por sí solos. Un coleccionista puede ver retiros, rutas de reemplazo o pérdida de visibilidad. La intención solo queda clara cuando esas observaciones se combinan con las explicaciones públicas de las empresas. Llamar al episodio fuga o secuestro tergiversaría tanto la evidencia como la superficie de control.

La distinción también protege la comparación histórica de la retrospectiva. Las taxonomías posteriores de fugas de rutas y los mecanismos de roles de relación ayudan a los operadores actuales a expresar y comprobar la intención de enrutamiento. No demuestran que la terminación de 2005 fuera un escape accidental de políticas, ni crean obligaciones retroactivas que rijan la decisión comercial de las empresas.

Posiciones comerciales y responsabilidad operativa

Los términos confidenciales del peering importan para cualquier disputa contractual, pero no son necesarios para identificar el problema de continuidad de los clientes. Las dos empresas discreparon públicamente sobre si la relación de prueba seguía cumpliendo sus condiciones. Sin el acuerdo completo y las mediciones subyacentes, un relato externo no puede determinar qué interpretación comercial era correcta.

La responsabilidad operativa comienza en un punto diferente. Una vez que un operador sabe que terminar una interconexión puede eliminar la única ruta viable para algunos clientes, la decisión tiene consecuencias de continuidad medibles. Esas consecuencias pueden examinarse sin declarar que el operador carecía de derecho contractual para terminar.

Esta separación evita dos errores opuestos. El primero es asumir que cualquier impacto en los clientes demuestra mala conducta. Las redes deben conservar la capacidad de hacer cumplir acuerdos, proteger infraestructura y terminar relaciones. Un estándar de continuidad que en la práctica imponga el peering sin liquidación perpetuo borraría la autonomía operativa y comercial legítima.

El segundo error es tratar una disputa contractual bilateral como si solo tuviera efectos bilaterales. Los clientes no eran parte de la relación de peering, pero algunos dependían de rutas intercambiadas a través de ella. Si ninguno de los operadores había mapeado esa dependencia, probado alternativas o establecido un procedimiento acotado de terminación, la ausencia de esos controles seguiría siendo importante aunque la terminación fuera contractualmente permitida.

La responsabilidad, por tanto, no es sinónimo de culpa. Es una disciplina de evidencia que pregunta quién controlaba cada decisión, qué podía observar razonablemente cada parte, qué salvaguardas existían y si el resultado fue verificado. La responsabilidad legal exige hechos adicionales y derecho aplicable. El registro público aquí no establece incumplimiento, negligencia, mala fe, conducta monopolística ni violación regulatoria.

Las afirmaciones sobre desequilibrio de tráfico ilustran por qué la atribución es esencial. La explicación pública de Level 3 se refería a las condiciones del acuerdo de prueba, mientras que el comunicado conjunto posterior describía características de tráfico, obligaciones de volumen y pagos condicionales. Esas declaraciones muestran que criterios comerciales relacionados con el tráfico formaban parte de la disputa pública y de la reparación. No revelan las proporciones exactas, los umbrales, los intervalos de medición ni los precios.

Un coleccionista de rutas no puede llenar esa laguna. Las rutas AS muestran alcanzabilidad anunciada, no volumen de tráfico. Incluso los contadores de interfaz necesitarían contexto sobre ubicación, dirección, agregación y medición contractual. Inferir umbrales confidenciales de peering a partir de datos BGP públicos confundiría el plano de control de enrutamiento con la contabilidad comercial.

La conclusión adecuada es acotada: un desacuerdo comercial llevó a la eliminación deliberada del intercambio directo de rutas; algunos clientes supuestamente perdieron alcanzabilidad; las partes presentaron públicamente explicaciones diferentes; y luego restablecieron la interconexión en términos revisados que incluían procedimientos de protección de clientes. La evidencia no decide los méritos contractuales no publicados.

Un mapa de control para la falla

Level 3 controló su decisión de terminar la relación directa de peering y su lado de las sesiones BGP relevantes. También controló las rutas que aceptaba y exportaba, su escalamiento interno, su comunicación con los clientes y cualquier procedimiento de terminación escalonado o inmediato que utilizara. Esas áreas definen su responsabilidad operativa sin resolver si la terminación estaba justificada comercialmente.

Cogent controló sus propias sesiones, anuncios de rutas, políticas de importación y exportación, comunicaciones con clientes y ofertas de resiliencia. Su declaración del 7 de octubre propuso el restablecimiento inmediato antes de seguir negociando, pero la defensa pública no elimina sus propias responsabilidades. Cogent estaba en posición de entender qué clientes dependían de sus relaciones ascendentes y de peering, qué alternativas podía suministrar y qué limitaciones acompañaban a la conectividad que vendía.

Ambos operadores compartían el control de la restauración bilateral. Un lado podía ofrecer restablecer una sesión, pero la interconexión operativa requería acción compatible de ambos lados: sesiones activas, rutas aceptadas, política viable y reenvío funcional. El anuncio conjunto indica que la relación se restableció mediante acuerdo y no mediante una acción de enrutamiento unilateral.

Otros operadores controlaban posibles rutas alternativas. Sus políticas determinaban si transportarían rutas entre los dos lados y bajo qué relación comercial. También controlaban la capacidad, el filtrado y la comunicación de incidentes dentro de sus propias redes. Su presencia en la topología no garantizaba que proporcionarían una ruta aceptable.

Los clientes controlaban algunas opciones de resiliencia, como comprar conexiones diversas, operar BGP, distribuir servicios entre redes o supervisar la alcanzabilidad externa. Ese control estaba limitado por el costo, la capacidad técnica, los recursos de direcciones, la disponibilidad de contratos y el tiempo de aprovisionamiento. Sería inexacto tratar a todos los clientes afectados como capaces de multihoming instantáneo.

Los registros controlaban los registros relativos a los números de sistemas autónomos y los recursos de direcciones. Esos registros respaldaban la administración de identidad y enrutamiento, pero no imponían una ruta operativa entre AS174 y AS3356. Una entrada de registro correcta podía ayudar a un operador a saber quién originaba un prefijo o a quién contactar. No podía restablecer una relación BGP terminada.

Los operadores de coleccionistas de rutas controlaban la infraestructura de medición, no las rutas de producción. Sus archivos hacen posible el análisis posterior, pero un coleccionista no puede hacer que un operador acepte una ruta. La medición es un libro de responsabilidad: registra parte de lo que las redes participantes expusieron. No es un sustituto de la continuidad operativa.

Los reguladores podían examinar la estructura del mercado y ejercer poderes otorgados por la ley, pero no operaban los enrutadores. Los registros de la FCC proporcionan contexto sobre los incentivos de interconexión y los efectos de red. No establecen que la agencia dirigiera la restauración de 2005 ni que declarara legalmente culpable a alguna de las empresas.

Este mapa evita que la responsabilidad se derrumbe sobre un único actor conveniente. La decisión de terminación, la disputa comercial, el inventario de rutas alternativas, la resiliencia de los clientes y la restauración estaban controlados por partes diferentes. Una responsabilidad eficaz registra esas divisiones en lugar de asumir que el papel de un actor anula todos los demás.

El acuerdo del 28 de octubre como diseño de reparación

El anuncio conjunto del 28 de octubre importa porque superó las declaraciones públicas enfrentadas. Cogent y Level 3 dijeron que habían alcanzado un acuerdo modificado de peering sin liquidación. El comunicado describía obligaciones vinculadas a las características y el volumen del tráfico, pagos cuando no se cumplían las obligaciones y un proceso destinado a proteger la conectividad de los clientes si la relación expiraba o las violaciones quedaban sin resolver.

Esos elementos abordan varias presiones de fallo distintas. Las obligaciones de tráfico medibles pueden hacer que los criterios comerciales sean menos ambiguos entre las partes. Los pagos condicionales pueden ofrecer una alternativa a la terminación inmediata cuando el servicio operativo continúa a pesar de un desequilibrio comercial. Un procedimiento definido de expiración o violación no corregida puede crear tiempo para avisar a los clientes y organizar rutas alternativas.

La descripción pública no muestra exactamente cómo funcionaban esos mecanismos. No revela umbrales, fórmulas, plazos, responsables de escalamiento ni la evidencia requerida para establecer el cumplimiento. Tampoco demuestra que el pago condicional estuviera disponible en todas las circunstancias. Cualquier descripción más fuerte reconstruiría términos privados que nunca se publicaron.

La disposición de protección de clientes es, no obstante, significativa. Su inclusión indica que las partes trataron el impacto sobre la conectividad como algo que un acuerdo de interconexión podía abordar procedimentalmente. Eso es diferente de decir que el acuerdo garantizaba una alcanzabilidad global ininterrumpida. Un procedimiento puede reducir el riesgo y aun así fallar en condiciones imprevistas, capacidad inadecuada o implementación incompleta.

La restauración también exige más que firmar términos o llevar una sesión BGP a un estado establecido. Las rutas deben intercambiarse, aceptarse y seleccionarse. El reenvío debe funcionar en ambas direcciones. Las rutas alternativas que se activaron durante la interrupción pueden necesitar reconverger sin causar inestabilidad nueva. Los puntos finales de los clientes deben volver a ser alcanzables desde las redes relevantes.

El anuncio público establece el acuerdo restaurado, pero no proporciona un registro completo de restauración cliente por cliente. Un relato acotado debe decir, por tanto, que las empresas restablecieron la interconexión directa en términos revisados, no que todas las aplicaciones afectadas se recuperaran simultáneamente ni que todas las consecuencias terminaran en un momento universal.

Orientación posterior como comparación, no como ley retroactiva

El RFC 4271 formaliza el marco de intercambio y decisión de rutas BGP-4. Se publicó después de la disputa de octubre de 2005, aunque documenta la familia de protocolos que ya operaba en Internet. Ayuda a explicar cómo se anuncian, retiran y seleccionan las rutas. No impone una obligación comercial a dos sistemas autónomos de mantener peering sin liquidación.

El RFC 7454, publicado mucho más tarde, recoge prácticas de seguridad operativa para sesiones BGP. Trata el filtrado, la protección de sesiones, los límites de prefijos y los controles de políticas. Esas prácticas son útiles para evaluar cómo un operador puede hacer que el comportamiento de interconexión sea más predecible y observable. No deciden si alguna de las empresas cumplió los estándares razonablemente aplicables en 2005, y no garantizan la continuidad después de un apagado intencional de sesión.

El RFC 8212 establece la política explícita de importación y exportación como un valor predeterminado más seguro para BGP externo. Ese enfoque reduce la propagación accidental causada por políticas ausentes. El evento Cogent-Level 3 no fue un ejemplo de rutas exportadas accidentalmente porque una configuración vacía predeterminara un comportamiento permisivo. La política explícita podría documentar la intención, pero seguiría permitiendo una decisión deliberada de no intercambiar rutas.

El RFC 7908 clasifica las fugas de rutas. Su taxonomía ayuda a distinguir la propagación no intencionada de las relaciones legítimas de cliente, par y tránsito. El evento de 2005 queda fuera del modo de fallo central de esa taxonomía porque la evidencia se refiere a un depeering deliberado. Aplicar la terminología con cuidado evita que una ruta ausente se etiquete erróneamente como una ruta excesiva o no autorizada.

El RFC 9234 introdujo más tarde los Roles BGP y mecanismos para expresar la intención de relación entre sistemas autónomos vecinos. Una mejor expresión de roles puede ayudar a identificar configuraciones incompatibles y limitar la propagación de rutas. No puede codificar todas las condiciones comerciales privadas, y no obliga a dos redes a permanecer interconectadas después de que termina una relación.

El RFC 1997 es históricamente diferente porque las comunidades BGP ya estaban estandarizadas antes de la disputa. Las comunidades podían ayudar a las redes a señalar preferencias de tratamiento de rutas. Su disponibilidad no demuestra cómo AS174 o AS3356 las usaron en octubre de 2005. Tampoco convierte un valor de comunidad observado en un coleccionista en una declaración completa de intención contractual.

La orientación de MANRS articuló más tarde acciones de operadores que incluían filtrado, coordinación, validación global y prevención de suplantación. La orientación posterior de NIST sobre enrutamiento interdominio destaca de manera similar la configuración resiliente, la supervisión y la respuesta a incidentes. Estos materiales proporcionan puntos de comparación contemporáneos útiles: los operadores pueden mantener información de contacto, observar cambios de rutas, validar políticas y preparar procedimientos de respuesta.

Ninguno es ley retroactiva. Ninguno proporciona el contrato de 2005, las mediciones de tráfico ni los registros internos de escalamiento que faltan. Ninguno demuestra negligencia solo porque la conducta histórica de un operador difiera de una recomendación posterior. Su uso adecuado es prospectivo: ayudan a traducir el episodio en controles que las redes actuales pueden medir.

La validación de origen basada en RPKI moderna merece la misma cautela. Puede ayudar a una red a rechazar un anuncio de origen no válido. No establece si un par debe transportar una ruta válida, si existe capacidad o si una relación comercial debe continuar. Una ruta puede ser criptográficamente consistente con un origen autorizado y, aun así, ser inalcanzable porque ninguna ruta aceptable cruza el límite de red relevante.

La lección posterior más transferible no es, por tanto, que un mecanismo de seguridad habría resuelto la disputa. Es que la intención de relación, la política de rutas, la supervisión, la coordinación y la planificación de continuidad deben estar conectadas. Una red necesita saber qué pretende intercambiar, qué está intercambiando realmente, qué clientes dependen de ese estado y cómo verificará una salida controlada.

Un estándar medible de terminación y restauración

Un estándar útil de responsabilidad debe permanecer neutral respecto al resultado comercial. No debe exigir peering indefinido, dictar términos de liquidación ni presumir que alguno de los participantes tiene derecho a tránsito gratuito. Debe exigir que los operadores hagan observables y acotadas las consecuencias de continuidad de una terminación planificada.

La primera medida es la cobertura de dependencia. Antes de terminar una interconexión con consecuencias, cada operador debe identificar los prefijos de clientes, grupos de destinos o clases de servicio para los cuales la relación directa es la única ruta verificada. El resultado medible no es la pretensión de conocer todo Internet. Es la proporción del inventario de clientes dentro del alcance del operador para el cual se ha evaluado y sellado temporalmente la dependencia.

Un registro de dependencia debe distinguir la observación directa de la inferencia. Una ruta vista a través de la interconexión no depende necesariamente de ella si existe otra ruta aceptable. Una ruta alternativa mostrada en una topología no está verificada si el operador nunca ha probado si se exporta, se acepta y es utilizable. El registro debe indicar, por tanto, los puntos de observación, las políticas de rutas y las pruebas de reenvío que respaldan cada clasificación.

La segunda medida es la verificación de rutas alternativas. Para cada grupo de dependencia, el operador debe registrar si existe al menos una ruta alternativa probada, si las rutas de ida y vuelta funcionan y si la ruta tiene capacidad operativa suficiente para el servicio previsto. La métrica relevante es la cobertura verificada: unidades alcanzables probadas divididas entre todas las unidades que se espera necesiten una alternativa.

Esa proporción debe llevar información de alcance. Un resultado alto medido solo desde los propios enrutadores del operador no establece alcanzabilidad externa. Las pruebas deben incluir redes independientes que representen rutas materialmente diferentes. El estándar no necesita prescribir un número universal de puntos de observación; debe exigir que el operador declare por qué su conjunto elegido representa a los clientes y regiones en riesgo.

La tercera medida es la preparación de políticas. El operador debe preservar la política de importación y exportación prevista antes, durante y después de la terminación, junto con el propietario responsable y el tiempo de activación. Esa evidencia permite distinguir un retiro planificado de una fuga accidental, un error de configuración o una falla de sesión no relacionada.

La preparación de políticas también incluye una simulación o prueba controlada cuando sea factible. Un operador puede reducir la preferencia por la ruta directa o probar prefijos de clientes seleccionados a través de alternativas antes de terminar la relación. Estas pruebas pueden no ser posibles en todas las arquitecturas y pueden crear por sí mismas un riesgo. El requisito responsable es documentar si se realizaron, qué cubrieron y por qué se aceptó cualquier dependencia no probada.

La cuarta medida es la preparación de capacidad. Una ruta BGP alternativa no es un control de continuidad si colapsa bajo el tráfico redirigido ordinario. Los operadores deben registrar la capacidad probada de las alternativas relevantes, las clases de tráfico incluidas y el momento de la prueba. Esto no exige publicar volúmenes confidenciales. Exige evidencia interna suficiente para establecer que enrutar alrededor de la interconexión era más que una posibilidad teórica.

La quinta medida es el aviso y el escalamiento. Un plan de terminación debe identificar al propietario de la decisión, al propietario de operaciones de red, al propietario de comunicación con clientes y al contacto de la contraparte. Debe registrar cuándo se notificó a cada uno y cuándo los clientes de los grupos de dependencia identificados recibieron información procesable.

Un aviso procesable debe explicar el riesgo operativo en lugar de limitarse a describir una disputa comercial. Un cliente necesita saber qué servicios pueden perder alcanzabilidad, qué conectividad alternativa está disponible, qué pruebas debe realizar y dónde informar de una falla. La métrica es la cobertura y el tiempo transcurrido: cuántos clientes dependientes identificados recibieron aviso y cuánto tiempo antes o después del cambio de enrutamiento se produjo ese aviso.

El estándar debe permitir una excepción de emergencia. Los incidentes de seguridad, las fallas no controladas o los riesgos contractuales inmediatos pueden hacer imposible un aviso previo. Una excepción no debe borrar la evidencia. Debe registrar la razón de la acción inmediata, la persona que la autorizó, las salvaguardas consideradas y el momento más temprano en que se informó a los clientes y a la contraparte.

La sexta medida es la observabilidad del evento. En la terminación, ambos operadores deben preservar el estado de la sesión, los recuentos de rutas, los anuncios y retiros relevantes, los cambios de rutas aceptadas y los resultados de las pruebas de reenvío. Una única entrada de «sesión caída» es insuficiente porque el efecto sobre el cliente depende de las rutas y caminos que desaparecen con ella.

La observabilidad debe producir una matriz de alcanzabilidad en lugar de un porcentaje global único. Las filas pueden representar redes de origen probadas o cohortes de clientes; las columnas pueden representar prefijos o servicios de destino relevantes. Cada celda puede registrar alcanzable, inalcanzable, degradado o no verificado, con una marca temporal y un punto de observación. Esto expone la incertidumbre en lugar de convertir el espacio no medido en éxito asumido.

La séptima medida es el rendimiento de detección. Un operador debe saber cuánto tardó la supervisión en identificar la pérdida de alcanzabilidad después del cambio de enrutamiento. El reloj no debe detenerse cuando la sesión BGP cambia de estado. Debe detenerse cuando el sistema identifica la consecuencia para el cliente con suficiente especificidad para actuar.

La detección debe separar las señales del plano de control y del plano de datos. Un retiro de ruta puede predecir daño, mientras que las sondas activas establecen si los paquetes aún viajan por una ruta alternativa. Las comprobaciones de aplicación pueden mostrar si un servicio funciona después de la convergencia del enrutamiento. Mantener estas medidas separadas evita que una entrada de tabla de rutas se confunda con un servicio de cliente completado.

La octava medida es la comunicación de incidentes. Durante la interrupción, los estados deben distinguir los hechos verificados de las hipótesis y de las posiciones comerciales atribuidas. Un operador debe informar qué cambió, qué alcance ha medido, qué sigue sin conocerse y cuándo proporcionará otra actualización. Declaraciones como «Internet sigue disponible» son inadecuadas si ocultan particiones conocidas entre grupos de clientes.

La novena medida es la restauración acotada. La restauración comienza cuando las partes toman medidas correctivas, pero no está completa simplemente porque una sesión vuelva a un estado establecido. Un operador debe verificar que los prefijos esperados se están intercambiando, que las políticas los aceptan, que las rutas seleccionadas son estables y que el reenvío tiene éxito desde redes externas representativas.

Un registro de restauración debe preservar marcas temporales separadas para el establecimiento de la sesión, la aceptación de rutas, las primeras pruebas exitosas del plano de datos, la recuperación de cada cohorte de clientes y el cierre de quejas pendientes. Estas marcas temporales evitan que un evento técnicamente conveniente —como el primer keepalive BGP— se presente como el fin universal del daño al cliente.

La décima medida es la reconciliación del estado de rutas. Las rutas utilizadas durante la interrupción pueden seguir siendo preferidas después de que regrese el peering directo, o el tráfico puede oscilar mientras las políticas reconvergen. Los operadores deben comparar el estado previsto posterior a la restauración con las rutas observadas e investigar diferencias materiales. El objetivo no es forzar que todas las rutas vuelvan a su camino anterior; es asegurar que el estado resultante se entienda y sea utilizable.

La undécima medida es la exposición no verificada. Todo registro de terminación debe indicar cuántos prefijos, grupos de clientes o regiones externas dentro del alcance no se probaron. La cobertura desconocida es un hecho de responsabilidad, no un campo vacío. Informarla evita que una muestra limitada exitosa se convierta en una afirmación no respaldada de recuperación universal.

La duodécima medida es la conservación de evidencia. Las observaciones de rutas, los cambios de configuración, los avisos, los mensajes de incidentes y las pruebas de restauración deben conservarse en una línea temporal consistente. Los coleccionistas públicos siguen siendo referencias independientes valiosas, pero la evidencia propia de los operadores debe ser más completa porque pueden ver la preferencia local, las rutas rechazadas, la topología interna y la asociación de clientes.

Estas medidas pueden resumirse como una cadena de continuidad:

Identificar quién depende de la interconexión.
Verificar qué rutas alternativas funcionan realmente.
Registrar la política, la capacidad y la propiedad de la decisión.
Notificar a la contraparte y a los clientes afectados según un procedimiento declarado.
Observar tanto el estado de las rutas como la entrega de paquetes durante el cambio.
Medir el daño por cohortes acotadas y puntos de observación independientes.
Restablecer sesiones, rutas aceptadas y reenvío.
Reconciliar el estado resultante y preservar la incertidumbre no resuelta.

Ninguna evidencia pública muestra que esta cadena completa existiera para alguno de los operadores en 2005. El estándar no debe presentarse como una obligación histórica que las empresas necesariamente violaron. Es una forma de convertir las presiones de fallo demostradas del evento en prácticas actuales medibles.

También evita imponer una garantía imposible. Ningún operador puede demostrar alcanzabilidad desde todas las redes hacia todos los puntos finales en todo momento. Lo que un operador puede demostrar es el alcance que evaluó, las alternativas que probó, las observaciones que conservó, los clientes a los que avisó y las condiciones bajo las cuales declaró la restauración.

Lo que el registro público aún no puede establecer

El contrato completo de peering sigue sin estar disponible. Las declaraciones públicas no revelan todas las proporciones de tráfico, ventanas de medición, capacidades de puerto, precios, períodos de curación ni derechos de terminación. Sin esos hechos, un relato externo no puede determinar si alguna de las empresas cumplió o violó sus obligaciones privadas.

El estado completo de enrutamiento también es desconocido. RouteViews, RIPE RIS y Merit proporcionan observaciones valiosas, pero no exponen todos los pares privados, preferencias locales, rutas rechazadas ni decisiones de reenvío. Los datos públicos supervivientes no pueden identificar todos los prefijos o clientes afectados.

El daño al cliente no puede cuantificarse con precisión a partir del registro congelado. La cobertura contemporánea respalda la conclusión de que algunas empresas y usuarios experimentaron fallos de alcanzabilidad. No establece la pérdida total de ingresos, la duración para cada cliente, las consecuencias a nivel de aplicación en todos los servicios ni efectos iguales en ambas redes.

La propiedad de las decisiones internas no es pública. Level 3 controló su acción de terminación, pero el material disponible no identifica a todos los aprobadores ejecutivos u operativos, la secuencia de escalamiento ni las pruebas internas realizadas antes del cambio. El proceso de respuesta interna y la evaluación de resiliencia de Cogent están igualmente incompletos.

El acuerdo revisado es evidencia de diseño de reparación, no prueba completa de implementación. Su descripción pública indica obligaciones de tráfico, pagos condicionales y un proceso de protección de clientes. No muestra cómo se probó posteriormente cada control ni si habría abordado todos los escenarios futuros de fallo.

La asignación legal queda sin resolver aquí. Las discusiones posteriores de la FCC proporcionan contexto regulatorio, pero los registros citados no establecen una conclusión de ilegalidad, incumplimiento contractual, negligencia o mala fe en este evento. El control operativo y la responsabilidad medible pueden analizarse sin convertirlos en conclusiones legales.

La continuidad se demuestra con rutas que funcionan

El depeering Cogent-Level 3 de 2005 sigue siendo instructivo porque eliminó la suposición de que el estatus de red importante garantiza alcanzabilidad universal. AS174 y AS3356 siguieron siendo redes identificables con recursos registrados, clientes y conexiones en otros lugares. Sin embargo, algunas rutas que cruzaban su antigua relación dejaron de funcionar, y algunos clientes supuestamente no pudieron enrutar alrededor de la división.

El hecho central del evento no fue simplemente que dos empresas discreparan. Fue que una decisión comercial bilateral cambió la disponibilidad de rutas interdominio. Los retiros BGP, la propagación alternativa, las políticas de importación y exportación, el multihoming y la restauración determinaron el resultado práctico.

La evidencia pública respalda una conclusión cuidadosa. Level 3 terminó deliberadamente el peering directo el 5 de octubre. Cogent pidió públicamente la restauración antes de seguir negociando. Level 3 dijo que el acuerdo de prueba ya no cumplía sus condiciones. Se interrumpió la alcanzabilidad de algunos clientes, aunque se desconoce el alcance completo. El 28 de octubre, las empresas anunciaron el restablecimiento del peering sin liquidación en términos revisados que incluían un proceso destinado a proteger a los clientes durante una futura expiración o violación no resuelta.

Nada en esa conclusión exige decidir los méritos contractuales privados. Tampoco exige un peering obligatorio. Exige reconocer que el control autónomo conlleva un deber probatorio cuando su ejercicio puede aislar a clientes dependientes.

Un registro puede documentar quién posee un bloque de direcciones. Un contrato puede documentar obligaciones comerciales. Un estado puede documentar la posición de una parte. La alcanzabilidad total de Internet se demuestra en otro lugar: en rutas que realmente se anuncian, aceptan, seleccionan y reenvían, con alternativas observables cuando termina una relación directa.

Esa es la prueba duradera de responsabilidad. Antes de terminar una interconexión con consecuencias, saber qué clientes dependen de ella. Durante el cambio, medir lo que desaparece en lugar de asumir que el resto de Internet enrutará alrededor. Después de la restauración, verificar las rutas de los clientes en lugar de detenerse en la firma del contrato o el estado de la sesión BGP. El registro solo es útil cuando corresponde a una ruta operativa.

El depeering de Cogent-Level 3 de 2005 convirtió la alcanzabilidad total de Internet en una prueba de responsabilidad del tránsito