CIDR спас таблицу маршрутизации, но расширил полномочия администратора

Кратко

• Измерения, восстановленные по наблюдениям Merit в контексте NSFNET и по часовым данным SURFnet, показывают существенное облегчение маршрутизации в 1994–1995 годах, однако ряд меняет точку наблюдения, лишён знаменателя в масштабе всего Интернета и не раскрывает отдельно, как в нём учитывались более специфичные маршруты.
• Цепочка внедрения шла от изменений топологического распределения адресов в 1992–1993 годах через план NSFNET от июня 1993 года, спецификации CIDR от сентября 1993 года, вендорские тесты 1993 года, стандарт BGP-4 от июля 1994 года и развёртывание у провайдеров к наблюдённому перелому 1994–1995 годов.
• CIDR создал значимые точки принятия решений для IANA, Интернет-реестра, RIPE NCC, Merit, провайдеров, вендоров, операторов и соседних автономных систем, при этом сохранившиеся записи сильнее подтверждают структурную возможность, чем её реализованное применение в масштабе всей совокупности.
• Ограниченный вывод состоит в том, что CIDR дал крупные, зависящие от точки наблюдения выигрыши в маршрутизации, согласующиеся с агрегацией; AlterNet даёт единственную количественно измеренную сторону «после» у провайдера в доступных записях, тогда как второй реализованный случай и названный результат клиента отсутствуют.

Инженерная проблема была измеримой ещё до того, как прояснились институциональные последствия.RFC 1519, опубликованный в сентябре 1993 года, воспроизвёл предоставленный Merit ряд данных: 173 анонсированных маршрута в июле 1988 года и 8 561 маршрут в декабре 1992 года. Наблюдения относились к контексту маршрутизации NSFNET. Их единицей был анонсированный маршрут, зафиксированный в этом эксплуатационном ряду, а не распределение адресов, подключённая организация, автономная система или универсальный подсчёт всех маршрутов, видимых где бы то ни было. RFC 1519 называет источником Merit, но не указывает конкретного коллектора, не подтверждает неизменность аппаратуры сбора на всём протяжении периода и не уточняет, как учитывались более специфичные маршруты. К ряду не приложен какой-либо значимый знаменатель в масштабе всего Интернета.

Даже с учётом этих ограничений рост был серьёзным: за 53 месяца показатель декабря 1992 года превысил показатель июля 1988 года примерно в 49,5 раза. Собственный анализ RFC 1519 рассматривал отрезок 1988–1991 годов как удваивающийся в среднем каждые десять месяцев. Этот темп относится к тому определённому историческому интервалу и набору данных в контексте NSFNET. Его не следует переносить вперёд, как будто один монитор непрерывно измерял одну и ту же интернет-популяцию с тем же темпом до середины десятилетия.

Ранние свидетельства, полученные уже после начала развёртывания, выглядят совсем иначе. В практическом исследовании Geoff Huston от марта 2001 года«Анализ таблицы BGP-маршрутизации Интернета»более ранние, примерно ежемесячные наблюдения Merit были соединены с часовыми измерениями, которые в начале 1994 года начал Erik-Jan Bos в SURFnet в Нидерландах. Huston добавил третью точку измерения на границе AS 1221 в Австралии с 1997 года, хотя эта более поздняя точка наблюдения не входит в количественный вывод данной статьи. Поэтому часть, относящаяся к 1994 году, — это часовой обзор таблицы BGP без маршрута по умолчанию из точки SURFnet, встроенный в реконструкцию, более ранний отрезок которой получен от Merit. Это не один прибор, один коллектор и не одно место, работавшие без изменений с 1988 года.

Huston сообщил, что видимая таблица в течение 1994 года оставалась относительно постоянной — около 20 000 записей. Единицей была запись таблицы BGP, видимая в точке измерения SURFnet; базой сравнения служил похожий на экспоненциальный рост, продолжавшийся до начала 1994 года. Источник объясняет плато тем, что добавления от новых анонсируемых блоков провайдеров компенсировались удалением составляющих анонсов за счёт агрегации.

Он не сообщает отдельно, как исторический ряд тогда учитывал более специфичные маршруты, поэтому из одной только статьи приблизительный итог нельзя разложить на агрегаты, клиентские исключения, анонсы мультихоминга или другие частности.

Это ограничение меняет масштаб утверждения, но не его направление. Влиятельный ряд данных, предшествовавший CIDR, вырос от сотен до тысяч анонсированных маршрутов. Более поздняя реконструкция показывает вид из точки без маршрута по умолчанию, приближающийся примерно к 20 000 записей, а затем удерживающийся около этого уровня большую часть 1994 года, пока сеть продолжала расширяться. Наблюдение согласуется с тем самым механизмом, который CIDR и BGP-4 должны были обеспечить: заменой нескольких топологически согласованных анонсов одним более коротким агрегированным префиксом.

Результатом стало существенное инженерное облегчение. Но облегчение это было ограниченным. В записях нет одновременной переписи всех маршрутизаторов без маршрута по умолчанию, общего определения, охватывающего все наборы данных, или поштучного перечня анонсов, которые исчезли. Самый сильный количественный вывод ограничен наблюдениями 1994–1995 годов: рост маршрутизации в указанных точках наблюдения резко отклонился от прежней траектории в тот период, когда провайдеры разворачивали бесклассовую маршрутизацию и агрегацию.

Прежде чем измерения стали мифологией

Прогнозы кризиса требуют той же дисциплины в обращении с источниками, что и наблюдаемые числа. RFC 1519 говорил, что таблица без маршрута по умолчанию содержала примерно 4 700 записей в январе 1992 года, приводя в качестве примера магистральные маршрутизаторы NSFNET и называя это число размером базы данных маршрутизации NSFNET. В его подробной помесячной таблице для января указано 4 526 анонсированных маршрутов, для февраля — 4 740. Приблизительная цифра в тексте — это не ещё одно точное наблюдение, и её следует отличать от обеих помесячных строк.

Используя найденное для 1988–1991 годов среднее удвоение за десять месяцев, RFC 1519 прогнозировал примерно 30 000 записей в течение двух лет. Отдельно моделировалось дополнительное давление, которое могло возникнуть, если организации, не способные получить сеть класса B, вместо этого получали и анонсировали несколько сетей класса C. При таком допущении документ прогнозировал более 10 000 записей в течение шести месяцев и 20 000 в течение года. Это были прогнозные результаты модели, исходившие из стартовой точки января 1992 года и предполагавшие продолжение прежнего роста. Это не последующие измерения.

Трёхлетние сценарии были более амбициозными. RFC 1519 рассчитал примерно 75 000 маршрутов без корректирующих мер, 5 650 — при немедленном внедрении и полном участии и 13 145 — при 90-процентном участии провайдеров. Результат 5 650 предполагал, среди прочего, что начальных блоков провайдеров хватит на два года спроса, что провайдеров примерно 100, что мультихоминговых организаций на старте меньше 100 и что мультихоминг будет расти заданным темпом. В сценарий 13 145 добавлялась моделируемая доля неучаствующих. Каждый результат выражал то, что давали допущения авторов; ни один не был будущим наблюдением, ожидавшим подтверждения.

Наблюдаемые значения в указанных точках наблюдения 1994 года и октября 1995 года оказались значительно ниже прогноза в 75 000 маршрутов при отсутствии мер. Это сравнение подтверждает практический успех агрегации, не делая вид, будто ненаблюдаемый контрфактический сценарий доказан. Модернизация маршрутизаторов, изменение спроса, маршруты по умолчанию, политические решения, реструктуризация сетей и другие события того времени тоже влияли на содержимое конкретной таблицы.

Каузальное обоснование CIDR опирается на сроки перелома, документированный механизм развёртывания и прямые свидетельства того, что провайдеры заменяли множество внутренних маршрутов меньшим числом внешних анонсов.

Вторая скорость роста появилась вRFC 1467, опубликованном в августе 1993 года. База данных политик маршрутизации NSFNET/ANSNET компании Merit росла тогда примерно на 8 % в месяц, что документ описывал как удвоение за девять-десять месяцев. Это была текущая скорость роста записей в той базе политик, а не продолжение анализа RFC 1519 за 1988–1991 годы. База ограничивалась политиками допустимого использования NSF и ANSNET и не была тождественна полной таблице пересылки.

RFC 1467 сообщал о более чем 13 000 сетей в этой базе, из которых более 10 000 были активны к концу июня 1993 года. Здесь первая единица — запись сети в базе данных; вторая — сеть, анонсированная магистрали NSFNET/ANSNET. Merit периодически публиковал эти данные, но RFC не содержит полной спецификации коллектора или описания более специфичных маршрутов на основе масок. В документе также оценивалось, что сети, известные другим провайдерам, но отсутствующие в базе политик допустимого использования, составляли менее 25 % от её наполнения, при этом признавалось, что скорость их роста не измерялась.

Эти цифры описывают важный, ограниченный политиками эксплуатационный набор данных, а не всю систему BGP.

Третье утверждение о десяти месяцах содержится в написанном участниками ретроспективном отчёте Merit —NSFNET: партнёрство для высокоскоростных сетей. Итоговый отчёт 1987–1995. В доступном экземпляре отчёта нет явной даты публикации. В нём говорится, что таблицы маршрутизации NSFNET удваивались примерно каждые десять месяцев, и зафиксировано развёртывание CIDR на магистральном сервисе NSFNET в 1994 году. Он даёт институциональную память людей, участвовавших в программе. Его статус — недатированное ретроспективное свидетельство, отличное от датированного ряда RFC 1519 и текущей скорости роста базы политик из RFC 1467.

Все три утверждения об удвоении указывают на кризис масштабирования, но их нельзя соединить в одно непрерывное измерение. RFC 1519 проанализировал наблюдения 1988–1991 годов из ряда в контексте NSFNET, предоставленного Merit. RFC 1467 описал рост базы политик NSFNET/ANSNET в 1993 году. Итоговый отчёт Merit позже обобщил опыт программы. Их определения, временны́е окна и доказательственный статус различаются.

Цепочка внедрения по порядку

CIDR появился не как одиночная публикация стандарта, за которой мгновенно последовало падение числа маршрутов. Администрирование адресов сдвинулось раньше, чем маршрутная техника была в целом готова, и такая последовательность поначалу грозила увеличением таблицы.

Хронология начинается в 1992 году. RFC 1467 фиксирует, что к 31 октября 1992 года IANA разработала критерии признания региональных адресных реестров и приняла заявки от будущих реестров. RIPE NCC получил в администрирование для Европы диапазон 194.0.0.0–195.255.255.255 и уже владел диапазоном 193.0.0.0–193.255.255.255. Получить выделение класса B становилось всё труднее, и там, где возможно, предпочитались блоки номеров класса C подходящего размера. В регионах без назначенного регионального реестра функцию распределения продолжал выполнять Интернет-реестр.

К 15 апреля 1993 года Интернет-реестр распределял адреса по топологическому плану блоками из номеров класса C, а провайдеры запрашивали блоки для последующего выделения клиентам. RIPE NCC или Интернет-реестр, действуя для соответствующих регионов, предоставляли эти блоки провайдерам. Это были подтверждённые изменения практики распределения. Они создавали смежные диапазоны, пригодные для последующей агрегации; сами по себе они не сжимали таблицу маршрутизации.

Запланированный рубеж общей доступности агрегации адресов 6 июня 1993 года не был достигнут. RFC 1467 объясняет срыв состоянием программного обеспечения маршрутизаторов. В его обзоре описаны реализации на стадии внутреннего тестирования, планы пре-беты или беты, намерения ограниченного релиза, отсутствие функций агрегации или дезагрегации и маршрутизаторы, которым всё ещё требовалось совместимое ПО. Приведённые даты были планами и прогнозами, сделанными в 1993 году, а не доказательством последующего завершения работ.

RFC 1482, опубликованный в июне 1993 года, излагал намерения Merit по поддержке агрегации в базе данных маршрутизации на основе политик NSFNET (Policy-Based Routing Database) и предлагал реестр агрегатов CIDR (CIDR Aggregate Registry). Лето 1993 года называлось в нём намеченным периодом включения BGP-4 и агрегации CIDR, при этом на каждого участника возлагалась ответственность за свою часть внедрения. Документ показателен с операционной точки зрения: в нём названы базы данных, отчёты, процессы конфигурации, регистрационные поля и проблемы координации, которые предстояло изменить. Это по-прежнему план, а не отчёт по итогам.

RFC 1518и RFC 1519 были опубликованы в сентябре 1993 года. RFC 1518 дал архитектуру согласования распределения адресов с топологией маршрутизации и рассмотрел баланс между абстракцией и децентрализованным администрированием. RFC 1519 дал стратегию назначения адресов и агрегации в статусе стандарта, включая пересылку по самому длинному префиксу, обработку дыр и мультихоминга, допущения о распределении и обязанности по агрегации. Документы описывали архитектуру и независимую от протокола семантику маршрутизации. Публикация не удостоверяла, что провайдеры развернули необходимое ПО.

В течение 1993 года вендоры и провайдеры тестировали или планировали код BGP-4. RFC 1467 фиксирует разные состояния у 3Com, ANS, BBN, Cisco, Proteon и Wellfleet. Какой-то код мог принимать бесклассовые маршруты, но не мог формировать агрегаты; где-то не хватало управляемой дезагрегации; что-то оставалось на стадии внутреннего тестирования; что-то зависело от перевода старых маршрутизаторов на GateD. Аппаратные и конфигурационные ограничения провайдеров тоже различались. Это было поле частичных возможностей, а не синхронизированный релиз.

BGP-4 был опубликован в статусе стандарта какRFC 1654в июле 1994 года. Он кодировал достижимость как префикс с явной длиной и задавал поведение при выборе маршрутов, их распространении, сокращении информации и агрегации. CIDR был стратегией распределения и агрегации; BGP-4 — междоменным протоколом, который переносил бесклассовую достижимость. Топологическое распределение адресов могло начаться без завершённого развёртывания BGP-4, но обещанное сокращение маршрутов зависело от того, установлены ли и используются ли бесклассовые протоколы.

Итоговый отчёт Merit относит развёртывание CIDR на магистрали NSFNET к 1994 году. Huston описывает согласованные усилия провайдеров по развёртыванию в 1994–1995 годах. Его восстановленный ряд показывает возникший в результате перелом в точке наблюдения SURFnet.RFC 4632, опубликованный значительно позже, в августе 2006 года, аналогично описывает резкое падение в 1994 году, когда развёртывание BGP-4 у провайдеров позволило агрегировать вновь выделенные блоки, и затем примерно линейный рост с середины 1994 года.

Эта хронология согласуетRFC 2008, опубликованный в октябре 1996 года, с современными записями о развёртывании. RFC 2008 в целом говорит, что CIDR разворачивался с конца 1992 года. Эта дата может охватывать раннее топологическое распределение и начальную переходную программу. Её нельзя разумно понимать так, будто к концу 1992 года у провайдеров существовал завершённый, оформленный в статусе стандарта запуск агрегации BGP-4. Пропущенный рубеж июня 1993 года, отчёты о состоянии вендоров, спецификация BGP-4 от июля 1994 года и записи о развёртывании 1994–1995 годов устанавливают слои, которые последовали дальше.

Последовательность «сначала распределение» объясняет временное ускорение, задним числом выявленное в RFC 4632. Реестры выдавали блоки, предназначенные для агрегации, пока провайдеры продолжали анонсировать свои составляющие сети класса C через устаревшие или неполные схемы маршрутизации. Пока провайдеры не могли анонсировать и обмениваться бесклассовыми агрегатами, блок, которому предстояло стать одним маршрутом, мог выглядеть как множество. Развёртывание закрыло этот разрыв.

Huston и RFC 4632 также связывают самые крупные движения вниз с периодами после заседаний Рабочей группы IETF по развёртыванию CIDR. Это ретроспективная интерпретация временно́го соответствия, а не контролируемая демонстрация того, что конкретное заседание вызвало определённое число отзывов маршрутов. Заседания были частью среды координации. Измеренный результат возник благодаря установке ПО у провайдеров, настройке агрегатов, изменению анонсов и их приёму соседними системами.

Что требовалось для одного агрегата

Техническое сжатие было концептуально простым. Бесклассовый маршрут задавал адресный префикс и его длину. Несколько смежных сетей, следующих по одному внешнему пути, можно было представить более коротким общим префиксом. Пересылка по самому длинному префиксу сохраняла механизм исключений: более специфичный маршрут внутри агрегата мог направлять трафик иначе — для мультихоминга, смены провайдера или другого политического исключения.

Институциональная последовательность была длиннее. Она начиналась с того, что уполномоченный орган резервировал или выделял подходяще выровненный блок. В ранний период к числу таких органов относились IANA, Интернет-реестр и RIPE NCC. Их инструментами были действовавшие тогда процедуры распределения. Их решения касались размера, выравнивания, получателя и регионального или провайдерского контекста блока. Непосредственным подтверждённым результатом было выделение, допускавшее иерархическое деление. Агрегация маршрутов по-прежнему зависела от более поздних участников.

Провайдер, получивший такой блок, мог выделять клиентам более длинные префиксы. Для клиента с единственным подключением адресация, взятая из блока провайдера, позволяла покрывать достижимость клиента агрегатом провайдера за пределами этой сети. Самому провайдеру по-прежнему была нужна детальная внутренняя достижимость для своих клиентов. Бо́льшая часть экономии доставалась удалённым операторам без маршрута по умолчанию, которым больше не нужно было держать каждую клиентскую составляющую как отдельный внешний маршрут.

Затем провайдер решал, какой диапазон агрегировать и где его анонсировать. RFC 1519 возлагал полномочия по агрегации на домен, которому выделен адресный диапазон, допуская при этом делегирование другому домену. Рекомендовались заранее настроенные диапазоны, а не выведение границ агрегата только из текущих видимых маршрутов. Иначе временно отсутствующую составляющую можно было принять за неиспользуемое пространство. Источнику агрегата также требовался путь сброса для адресов внутри агрегата, у которых нет достижимого составляющего маршрута, чтобы пакеты не возвращались по менее специфичному маршруту в петлю.

«Исключительные полномочия» по агрегации в RFC 1519 означали ответственность за суммаризацию выделенного диапазона. Они не давали источнику власти над соседними автономными системами, клиентским оборудованием, адресными регистрациями или глобальной обработкой более специфичных маршрутов. Источник мог анонсировать агрегат. Каждый сосед сохранял собственную политику импорта, выбора и экспорта.

Политическая машинерия Merit для NSFNET образовывала ещё одну поверхность принятия решений. До CIDR база данных маршрутизации на основе политик фиксировала номера сетей, принимаемых магистралью, и автономные системы, от которых ожидались их анонсы. Сети среднего уровня поставляли политическую информацию; Merit включал её в материалы, использовавшиеся для конфигурации магистрали. RFC 1482 предлагал расширить эту систему, чтобы она учитывала префиксы и агрегаты.

Предложенный реестр агрегатов CIDR должен был фиксировать префикс и его длину, домашнюю автономную систему, анонсирующие автономные системы, соседние системы и контакты. Merit намеревался определить процедуры регистрации и связать агрегаты, переносимые через NSFNET, с процессами обновления маршрутов. Реестр проектировался и для более широкого применения, а не только для маршрутов, принимаемых или анонсируемых NSFNET.

Зарегистрированный агрегат оставался политическим заявлением. Он не был ни выделенным адресным блоком, ни доказательством живого анонса. Он не показывал, что каждый сосед принял маршрут. Провайдер должен был анонсировать агрегат; транзитные системы — распространять его; операторы-получатели — разрешать и выбирать его. Имена, адресные выделения, источники маршрутов, делегирования обратного DNS, политические записи и живое состояние пересылки были связанными, но разными объектами.

Ещё одну предпосылку обеспечивали вендоры ПО. Маршрутизатор должен был кодировать произвольные префиксы, выполнять выбор по самому длинному префиксу, агрегировать совместимые маршруты, сохранять требуемую информацию о пути, фильтровать по префиксу и маске и сосуществовать со старыми системами. Вендоры выбирали графики релизов и наборы функций. Провайдеры решали, допустим ли в их сетях экспериментальный код или код ограниченного релиза. Операторы выполняли установку, конфигурацию, тестирование совместимости, мониторинг и исправление ошибок.

Приём у удалённых систем завершал путь. Синтаксически корректный агрегат всё же мог быть отклонён политикой соседа. Корректный более специфичный маршрут мог приниматься локально, но не экспортироваться, приниматься только от конкретного соседа или отфильтровываться удалённой системой. Орган распределения адресов не контролировал эти решения. Достижимость агрегата возникала из распределённого множества отношений маршрутизации.

Выгода CIDR, следовательно, опиралась на несколько связанных действий: органы распределения создавали агрегируемое пространство; провайдеры согласовывали субвыделения с топологией; вендоры поставляли работоспособный код; провайдеры настраивали агрегаты; политические системы отражали ожидаемые анонсы; соседние операторы принимали и распространяли их. Сбой на одном этапе мог сохранить составляющие маршруты, дать неполную достижимость или задержать развёртывание.

Прогнозный расчёт для NSFNET

RFC 1482 дал современную оценку того, что агрегация могла удалить из анонсов магистрали NSFNET. Опубликованный в июне 1993 года, он исходил из входного множества из 12 348 анонсов, представленных магистрали. Его алгоритм искал самые длинные непрерывные адресные блоки и определил 4 135 анонсов как потенциально удаляемые — примерно 33 % этого входного множества.

В документе упражнение характеризовалось как оптимистичная оценка, полученная пессимистичным алгоритмом. Единицей было перспективное сокращение анонсов внутри названного входного множества магистрали NSFNET. Это не наблюдение завершённого соблюдения требований провайдерами, не подсчёт, собранный после запуска, и не измерение административной нагрузки. RFC не давал знаменателя в масштабе всего Интернета и последующего аудита, показывающего, что каждый кандидат в агрегаты был реализован.

Если вычесть заявленное потенциальное сокращение из входного множества, получится 8 213 оставшихся анонсов. Этот остаток — арифметика аналитика, а не число, которое RFC приводит как наблюдённую таблицу. Политические различия, отключённые сети, мультихоминг, дыры, ограничения ПО и выбор провайдеров могли изменить полученный результат.

Ценность расчёта — в его механизме. Он показал до полного запуска, что внутри одного важного множества анонсов существует значительное дублирование. Он также показал, почему важны изменения базы данных и конфигурации. Merit мог выявлять смежные анонсы в политических данных, но соответствующие провайдеры всё равно должны были формировать агрегаты, анонсировать их через ожидаемые отношения автономных систем и координировать переход.

RFC 1482 предусматривал изменения отчётов, инструментов, форматов конфигурации, практики регистрации и переход сrcp_routedна GateD. Провайдерам, разбирающим вывод Merit, пришлось бы адаптировать свои процессы. В документе также перечислены нерешённые вопросы: отладка, устойчивость при разных топологиях, решения о маршрутизации и трафик, направляемый в недостижимые дыры внутри агрегата. Его описание идущего внедрения следует читать вместе с этими открытыми задачами.

Это была административная работа в обычном эксплуатационном смысле: ведение корректных записей, распределение ответственности, изменение входных данных ПО, координация ожидаемых источников и диагностика сбоев. Она распространялась на Merit, ANS, региональных провайдеров и провайдеров среднего уровня, вендоров, реестры и операторов автономных систем. План не является свидетельством того, что один институт утверждал каждый маршрут или контролировал каждую реализацию.

AlterNet: количественно измеренная сторона «после» у провайдера

Самый сильный реализованный пример провайдера появляется в RFC 2008. В нём сообщается, что в октябре 1995 года AlterNet внутри держал 3 194 маршрута и анонсировал остальному Интернету 799 маршрутов. Разница — 2 395 анонсов, примерно 75 % внутреннего числа AlterNet.

У измерения чёткая граница провайдера. Первая единица — маршрут внутри AlterNet; вторая — внешне анонсированный маршрут после агрегации. Базой сравнения служит собственное внутреннее множество AlterNet. Это демонстрирует, что провайдер мог сохранять клиентскую или внутреннюю детализацию, экспортируя соседям гораздо более компактное представление.

Происхождение данных ограничено. RFC 2008 приписывает цифры частному сообщению Andrew Partan от октября 1995 года. В нём не названы конкретный маршрутизатор или коллектор, не приведён архивный дамп, не задокументирована команда сбора и не сказано, как более специфичные маршруты отдельно классифицировались в каждом из множеств. Результат — провайдерское свидетельство, воспроизведённое в документе стандартов, а не независимо воспроизводимое глобальное измерение.

Тем не менее наблюдённая реализация важна. AlterNet сформировал агрегаты, достаточные, чтобы превратить тысячи внутренних маршрутов в сотни внешних анонсов. Соседи, принимавшие эти анонсы, избегали необходимости держать 2 395 деталей AlterNet как отдельные записи. Это прямое состояние «после» для механизма сжатия, ограниченное одним провайдером и одним сообщённым наблюдением.

Действующим лицом был AlterNet. Инструментом — провайдерская агрегация, воплощённая в его конфигурации маршрутизации и экспортированных анонсах. Были затронуты внутреннее множество маршрутов AlterNet и внешние отношения маршрутизации, через которые отправлялись 799 анонсов. О реализации свидетельствуют числа до и после. Источник не раскрывает формального пути ревью, процедуры исключений, процесса исправления, записей о перенумерации клиентов или финальной проверки достижимости.

Эти отсутствующие элементы не позволяют этому случаю подкреплять широкий рассказ о реализованной власти. Цифры показывают, что AlterNet выбрал внешнюю абстракцию своей внутренней достижимости. Они не показывают, что AlterNet заставил 2 395 клиентов перенумероваться, что каждый сосед принял каждый анонс или что более специфичный маршрут названного клиента был отклонён. Случай устанавливает инженерную производительность и точку контроля провайдера.

RFC 2008 ставит цифру AlterNet рядом с двумя величинами октября 1995 года, которые нужно держать раздельно. Реестр маршрутизации Интернета содержал 61 430 уникальных префиксов, не считая записей, помеченных как отозванные. RFC также утверждал, что в части системы маршрутизации без маршрута по умолчанию появлялось менее 30 000 маршрутов. Первое множество состоит из уникальных зарегистрированных префиксов по заявленному в RFC правилу отзыва. Второе касается активных записей маршрутизации без маршрута по умолчанию, но цитируемое частное сообщение не называет коллектор или точку наблюдения и не сообщает об обработке более специфичных маршрутов.

Зарегистрированные намерения, выделения, внутренние маршруты и активные внешние анонсы — неэквивалентные совокупности. Реестр был неполным и мог содержать префиксы, неактивные в данной точке наблюдения. Таблица маршрутизации могла содержать активные маршруты, отсутствующие в реестре. Разницу между 61 430 и менее чем 30 000 нельзя превратить в глобальный процент сжатия.

AlterNet, следовательно, — единственная количественно измеренная сторона «после» у провайдера в доступных записях периода, используемых здесь. Этого достаточно, чтобы подтвердить: механизм работал в значимом масштабе внутри крупного провайдера. Этого недостаточно для репрезентативных выводов об операторах как классе.

Планы, состояние кода и незавершённые случаи

RFC 1467 даёт необычно полезный обзор подготовки провайдеров и вендоров в 1993 году. Большинство записей фиксируют планирование, тестирование, установленные мощности или планируемый релиз, а не более поздний результат агрегации.

ESNET иллюстрирует эту подготовительную стадию. Объём конфигурационной информации, описывающей сети, которые он должен принимать от соседей, уже упирался в ограниченное энергонезависимое хранилище. ESNET ожидал, что агрегация поможет, решил дождаться полнорелизного ПО BGP-4 и заявил, что тем временем перейдёт на системы Cisco CSC-4. Запись, таким образом, называет конкретного оператора, определённое эксплуатационное ограничение, решение о программном риске и предполагаемый аппаратный ответ.

Его рассказ заканчивается этими намерениями — до завершения модернизации, развёртывания BGP-4, формирования агрегатов, изменения фильтров или измеренного последствия для ёмкости и достижимости. ESNET относится к контексту развёртывания, а не в ряд реализованных случаев рядом с AlterNet.

Другие записи раскрывают неоднородную среду, в которой происходило развёртывание. SprintLink и ICM установили маршрутизаторы CSC-4 и намеревались нести полную маршрутизацию, включая маршруты вне политических множеств NSFNET/ANSNET. ANSNET модернизировал маршрутизаторы до AIX 3.2 и тестировал код BGP-4, тогда как более старое ПО всё ещё ждало замены для последовательной поддержки. В других местах завершённые аппаратные модернизации или обновления операционных систем соседствовали с внутренними тестами кода, прогнозируемыми ёмкостями и планируемыми релизами.

В совокупности эти отчёты объясняют, почему общая архитектурная цель дала неравномерную операционную готовность.

Обзор вендоров даёт пропущенному рубежу июня 1993 года конкретную причину. Некоторые реализации могли принимать бесклассовую достижимость, но по-прежнему не имели агрегации; управляемая дезагрегация была ещё одной отдельной возможностью. Зрелость релизов определяла даты, когда провайдеры могли брать на себя риск развёртывания, а собственное железо и политические системы провайдеров определяли, чего каждый релиз мог добиться на месте.

Итоговый отчёт Merit добавляет подтверждение на уровне программы, что CIDR достиг магистрали NSFNET в 1994 году. Ряд Huston по данным SURFnet затем фиксирует перелом в масштабе таблицы, видимый из одной точки без маршрута по умолчанию. Эти источники описывают разные уровни перехода: развёртывание в рамках программы и внешний эффект на маршрутизацию. Только AlterNet даёт количественное сравнение внутреннего состояния провайдера с внешним.

Записи, соответственно, рисуют разнородную подготовку, а не репрезентативную выборку результатов провайдеров. Сети различались железом, базами политик, использованием маршрутов по умолчанию, зрелостью кода, внешними отношениями и подверженностью маршрутам вне среды NSFNET. Эти различия важны при интерпретации коэффициента сжатия AlterNet, который остаётся свидетельством реализации одного крупного провайдера, а не среднего по всему классу.

Перенумерация и граница протокольного разрешения

RFC 1519 учитывал ситуацию клиента, сменившего провайдера без немедленной перенумерации. Новый провайдер мог анонсировать более специфичный маршрут внутри агрегата старого провайдера. Выбор по самому длинному префиксу направлял бы трафик к новому подключению везде, где этот более специфичный маршрут принят. Документ поощрял дальнейший переход в адресный блок нового провайдера, потому что каждое сохранённое исключение ослабляло агрегацию.

Такое устройство создавало операционное давление без команды на перенумерацию на уровне протокола. Клиент мог сохранить свои адреса в формате пакета. Новый провайдер мог анонсировать специфичный маршрут. Старый провайдер мог продолжать анонсировать свой более широкий агрегат. Достижимость тогда зависела от того, примут ли удалённые операторы более длинный префикс и распространят ли его.

RFC 2008 описывает эту зависимость на схематичном примере смены провайдера. Даже при разрешении прежнего провайдера и анонсе со стороны нового удалённые системы могли отказаться принять более специфичный маршрут или не иметь такой возможности. Могла последовать частичная связность. Документ предлагает в качестве возможных ответов перенумерацию или обслуживание через провайдеров, готовых поддерживать маршрут.

Его прежний провайдер, новый провайдер, удалённые системы и затронутая организация иллюстративны, а не являются названными участниками наблюдённого случая, поэтому частота, ревью, исправление и финальная достижимость остаются за пределами сохранившихся записей.

RFC 1900, опубликованный в феврале 1996 года, даёт прямые свидетельства о состоянии практики перенумерации. В нём перенумерация характеризуется как дорогостоящая, утомительная и подверженная ошибкам, требующая экспертизы и заблаговременного планирования. Инструментов было мало, и они не были широко развёрнуты; документированных процедур и общего опыта не хватало.

Среди его конкретных технических проблем — конфигурационные файлы, поддерживаемые вручную, приложения, содержащие литеральные IP-адреса, соответствия, которые вместо этого должны разрешаться через DNS, и лицензирование, привязанное к адресам хостов. В нём рекомендуется больше полагаться на полностью определённые доменные имена, автоматическую генерацию конфигурационных данных, DHCP, динамические обновления DNS, обнаружение маршрутизаторов и инструменты для перенумерации хостов. Оценка IAB устанавливает, что инструменты переносимости отставали от маршрутного перехода.

Средняя стоимость, время миграции, частота сбоев и доля организаций, выполнивших перенумерацию, в документе не измерены.

RFC 2008 предложил политику «адресного займа», по которой адреса, связанные с отношениями с провайдером, возвращались бы после прекращения этих отношений. Опубликованный в октябре 1996 года как Best Current Practice, он рекомендовал льготный период не менее 30 дней и предлагал ограничить его шестью месяцами, чтобы снизить накладные расходы маршрутизации. Эти сроки выражали политические рекомендации, а не измеренные среднеотраслевые значения.

Рекомендация связывала непрерывность адресов с топологией обслуживания более явно, чем того требовал формат пакета CIDR. Интернет-реестр, связанный с провайдером, мог выделять адреса на условиях, привязанных к договору обслуживания; провайдер обеспечивал бы достаточную агрегацию; клиент перенумеровывался бы после смены провайдера. Предписанная модель обращена к абонентам, получающим такие выделения, тогда как фактическое принятие, порядок обжалования и результаты клиентов лежат за пределами доказательств документа.

Мультихоминг ещё больше усложнял картину. Сети, подключённой через нескольких провайдеров, мог понадобиться более специфичный маршрут, видимый более чем одним путём. RFC 1519 рассматривал мультихоминг как постоянный источник неагрегированного состояния и использовал допущения о его росте в прогнозной модели. Поэтому провайдерская агрегация проектировалась с исключениями, а не как абсолютное правило.

Удалённые операторы могли отличать обычные агрегаты от исключений с помощью политики маршрутов, сохраняя независимый контроль над приёмом и экспортом. Более специфичный маршрут, разрешённый BGP-4, мог не пройти локальную проверку политики; принятый префикс мог не распространиться дальше принимающего соседа. Протокольное разрешение, локальный выбор, коммерческие отношения и операционное давление оставались раздельными.

Расширившаяся административная поверхность

«Администратора» из заголовка лучше всего понимать как распределённую административную поверхность. CIDR повысил значимость решений, согласующих адресацию, топологию, политику маршрутизации и ПО. Возникшая власть была разделена между институтами и операционными уровнями, а не сосредоточена в едином командном пункте.

На уровне распределения IANA признавала региональные реестры и назначала крупные диапазоны; Интернет-реестр обслуживал регионы без сформировавшегося регионального реестра; RIPE NCC администрировал европейские блоки в рамках складывавшегося плана. Затем провайдеры делили смежные диапазоны для подключённых клиентов. Эти специфичные для того периода роли образовывали иерархию адресного администрирования, но каждая роль не доходила до определения того, как будет анонсирован или принят каждый нижестоящий маршрут.

RFC 1518 объяснял сделку, стоящую за этой иерархией. Администрирование могло оставаться децентрализованным, тогда как эффективная абстракция требовала, чтобы выделения нижнего уровня следовали топологии, по которой идёт достижимость. Детализация наиболее эффективно исчезала у листьев: непосредственный провайдер сохранял клиентские маршруты, а удалённые системы без маршрута по умолчанию получали сводку. Это распределяло работу по назначению адресов наружу и делало связь между субвыделением и топологией у провайдера более значимой.

Агрегация вводила второй уровень ответственности. Провайдер выбирал диапазон, анонсировал агрегат сам или делегировал это, сохранял достижимость составляющих и устанавливал защитные меры для дыр. Множество направлений могло затем зависеть от точности одного внешнего заявления. Абстракция сокращала удалённое состояние, концентрируя конфигурационную ответственность в его источнике.

Merit занимал смежную, но отдельную политическую роль в сервисе NSFNET. Он фиксировал ожидаемые источники, получал информацию от участвующих сетей, переводил политику в конфигурацию магистрали и предлагал распространить эти процессы на агрегаты. Эта роль формировала регистрацию и конфигурацию NSFNET, не заменяя распределение адресов и не отменяя маршрутные политики других автономных систем.

Цепочку завершали ПО и межсоединения. Вендоры определяли, когда функции, работающие с префиксами, достаточно зрелы для выпуска; провайдеры решали, когда их устанавливать и доверять им; операторы конфигурировали, тестировали и наблюдали за получившимися системами. Соседние автономные системы затем применяли собственные политики импорта, выбора и экспорта. Практическая достижимость агрегата собиралась из этих отношений.

Конечные сети сохраняли собственные решения о связности, мультихоминге, локальной конфигурации и перенумерации. Эти выборы действовали в рамках ограничений, заданных условиями выделения у провайдера, приёмом маршрутов удалёнными системами, доступными инструментами и операционным бременем, описанным в RFC 1900. Они были участниками системы, хотя их свобода сохранить адрес при смене провайдера зависела от решений за пределами прямых отношений.

Роль IETF была архитектурной и координационной. Его документы определяли совместимое поведение и давали площадки для развёртывания; распределение, установка ПО, анонсирование агрегатов и приём маршрутов оставались за соответствующими операционными участниками. Авторитет стандартов создавал общую рамку, через которую эти решения взаимодействовали.

CIDR, таким образом, перераспределил ответственность вокруг границы абстракции. Органы распределения определяли, будет ли пространство агрегируемым. Провайдеры группировали направления и поддерживали скрытую детализацию. Merit адаптировал политическую машинерию для одной крупной магистральной среды. Вендоры контролировали готовность функций. Соседи принимали или отклоняли анонсы и исключения. Конечные сети управляли последствиями для подключения и переносимости. Общий выигрыш зависел от всех них, хотя ни один не администрировал систему маршрутизации в одиночку.

Издержки, которые переместились, а не исчезли

Общий выигрыш проявлялся в удалённых таблицах маршрутизации. Провайдер мог скрыть множество клиентских маршрутов внутри одного внешнего анонса, сокращая память, обработку, конфигурацию и работу по обновлениям в других местах. Сообщённое сравнение AlterNet даёт конкретный пример.

Непосредственный провайдер продолжал держать внутреннюю детализацию. Ему приходилось достигать отдельных клиентов, поддерживать субвыделения, настраивать агрегаты, сохранять маршруты-исключения, обновлять записи и диагностировать дыры. Агрегация перемещала информацию и ответственность к сетям, создающим абстракцию.

Органы распределения адресов снизили давление от централизованной обработки каждого выделения, делегировав функции регионального и провайдерского уровня. Региональные реестры и провайдеры затем выполняли больше работы по распределению и регистрации ближе к топологии. Административная нагрузка сместилась наружу от центрального органа.

Предложенный Merit реестр агрегатов иллюстрирует новые координационные издержки. Когда множество маршрутов можно было представить одним префиксом, операторам требовалась надёжная информация о том, кто создал эту абстракцию, какие соседи её получили и как следует синхронизировать политические изменения. Сжатие сокращало состояние пересылки, повышая важность метаданных и корректности конфигурации.

Вендоры несли работу по разработке и обеспечению совместимости. Провайдеры несли риск развёртывания. Операторы переводили политику в фильтры, учитывающие префиксы, и следили за непреднамеренными изменениями достижимости. Клиенты получали доступ к адресным блокам, лучше соответствующим их потребностям, и — при единственном подключении — избегали добавления отдельных глобальных маршрутов. Последующая смена провайдера могла подвергнуть их перенумерации или зависимости от исключений.

Распределение включало несколько одновременных эффектов. Удалённые операторы получили облегчение таблиц. Непосредственные провайдеры приняли на себя обязанности по абстракции. Функции распределения стали более распределёнными. Вендоры писали новый код. Одни клиенты получали эффективное обслуживание без глобального маршрута; другие сталкивались с будущими вопросами переносимости. Доступные записи устанавливают эти категории работы яснее, чем их финансовое распределение.

Экономию адресного пространства нужно отделять от агрегации. Выдача набора сетей класса C подходящего размера вместо одной сети класса B могла экономить дефицитное адресное пространство. Независимый анонс каждой составляющей всё равно мог увеличивать состояние маршрутизации. Агрегация сокращала внешние анонсы только тогда, когда адресные составляющие разделяли общий топологический путь, а операторы использовали бесклассовый механизм.

Обратный DNS был ещё одной отдельной функцией. Выровненные по битам выделения не всегда совпадали с октетными границами существующей структуры делегирования обратного DNS, создавая дополнительные вопросы обслуживания. Решение этих вопросов не создавало маршрут BGP, а маршрутный агрегат не настраивал DNS автоматически.

Точно так же запись в базе данных политик маршрутизации отличалась от живого анонса. Зарегистрированный префикс выражал предполагаемую политику или контекст авторизации. Активная запись BGP отражала то, что коллектор получил и выбрал. Отношение к ним как к взаимозаменяемым превратило бы числа IRR и счётчики без маршрута по умолчанию из RFC 2008 в вводящий в заблуждение процент.

Альтернатива с более крупными маршрутизаторами и более свободными специфичными маршрутами

Правдоподобная контрфактическая альтернатива того периода больше опиралась бы на более крупные маршрутизаторы, свободнее принимала бы более специфичные маршруты и выделяла бы больше независимого от провайдера пространства. Она, возможно, снизила бы непосредственное давление перенумерации и позволила бы клиентам сохранять адреса при смене провайдеров. Её издержки проявились бы в состоянии маршрутизации, обработке обновлений, конфигурации и обработке сбоев.

Больше памяти могло увеличить число записей, которые держит маршрутизатор. Более быстрые процессоры могли улучшить выбор маршрутов и обработку обновлений. Более крупные хранилища конфигурации могли вместить больше фильтров. Лежащая в основе информация осталась бы несжатой: каждый независимо видимый клиентский префикс требовал бы хранения и политической обработки в каждой системе без маршрута по умолчанию, которая его принимает.

Отчёты провайдеров 1993 года показывают, почему ёмкость нельзя было считать единым однородным потолком. Разные сети были ограничены памятью таблиц пересылки, информацией о путях, мощностью процессоров, хранилищем конфигурации или их взаимодействием. Аппаратная модернизация, решавшая один локальный предел, могла оставить нетронутым другое операционное узкое место.

Более крупная таблица также меняла сходимость и работу с обновлениями. Больше маршрутов означало больше записей для сравнения, установки, отзыва и анонсирования при изменении топологии. Поэтому более детализированная система без маршрута по умолчанию обрабатывала больше состояния после каждого изменения, хотя свидетельства того периода не дают полной численной оценки возникшей задержки сходимости, издержек благосостояния или подверженности сбоям.

Более свободный приём более специфичных маршрутов помог бы переносимости и мультихомингу. Клиент, сохранивший префикс старого провайдера, мог анонсировать его через нового провайдера. Мультихоминговая сеть могла раскрывать разные пути. Удалённые операторы платили бы повторяющуюся стоимость хранения и обновления такого исключения.

Если бы независимое от провайдера пространство стало обычным на уровне конечных площадок, система маршрутизации приблизилась бы к более плоскому перечислению подключённых площадок. Это распределило бы подверженность сбоям по множеству отдельных анонсов и распределило бы работу по конфигурации и поддержке политик между операторами без маршрута по умолчанию.

Агрегация создавала иную форму риска. Агрегат, анонсированный провайдером, представлял множество направлений. Ошибка конфигурации, отзыв или неверное поведение при сбросе в источнике могли разом затронуть более крупный адресный диапазон. Сбой потенциально концентрировался в точке абстракции. Поэтому операторам требовались точная достижимость составляющих и защита от петель и чёрных дыр.

Путь множества более специфичных маршрутов предлагал независимые анонсы для отдельных направлений. Его сбои были более распределёнными, как и бремя обычного состояния: каждая удалённая таблица, каждый набор политик и каждый процесс обновлений несли больше деталей. Инженерный выбор уравновешивал меньшее множество значимых абстракций против большего множества независимо поддерживаемых фактов.

Хранилище конфигурации тоже имело значение. Описанная трудность ESNET касалась политической информации о том, какие сети принимать, а не только памяти пересылки. Более свободный приём мог уменьшить некоторые явные ограничения, но оператору, озабоченному источником маршрутов или клиентской политикой, всё равно требовалось бы конфигурационное состояние. Более многочисленная и более динамичная популяция префиксов делала эту задачу обслуживания труднее ограничиваемой.

Более массовое выделение независимых от провайдера адресов могло улучшить переносимость при смене провайдера. Оно ослабило бы согласованность иерархии адресов с провайдерской топологией, уменьшив долю направлений, скрытых внутри провайдерских агрегатов. В источниках того периода нет развёрнутой замещающей иерархии со сравнимой продемонстрированной компрессией.

Контрфактическая альтернатива, следовательно, выглядит технически возможной на какое-то время, особенно при продолжающейся модернизации оборудования и избирательном использовании маршрутов по умолчанию. Её возможная продолжительность, полная стоимость и эффекты для благосостояния клиентов остаются за пределами доступных измерений. Тем не менее задокументированные ограничения ёмкости объясняют, почему инженеры стремились изменить зависимость роста, а не раз за разом поднимать потолки оборудования.

Более сильный вариант пути CIDR

Более убедительной альтернативой был CIDR в сочетании с лучшей поддержкой переносимости, документированными исключениями и более ясным ревью. Этот путь сохранял топологическую агрегацию, одновременно решая операционное бремя, ставшее заметным к 1996 году.

Условия выделения могли бы явно указывать, связан ли адресный блок с отношениями с провайдером, что произойдёт после их прекращения и как долго может длиться перекрытие. Провайдер, теряющий клиента, мог бы указать, продолжит ли он покрывать адресный диапазон внутри своего агрегата. Новый провайдер мог бы заявить, будет ли он анонсировать более специфичный маршрут.

Крупные транзитные операторы могли бы публиковать условия по префиксу и источнику, которые они применяют к временным исключениям. Такая публикация показала бы, есть ли у предлагаемого перехода правдоподобный путь достижимости, при этом каждый удалённый оператор сохранял бы собственную независимую политику. Клиент мог бы проверить план до смены обслуживания, а не обнаруживать фильтрацию задним числом.

Процесс ревью мог бы назвать ответственного за отказ, техническую причину, срок действия и доступное исправление. Одни случаи могли оправдывать временный приём; другие — требовать перенумерации. Решение оставалось бы операционным, но его масштаб и последствия были бы видны.

Рекомендации RFC 1900 указывают на необходимые инструменты на стороне клиента: конфигурацию на основе DNS, меньше литеральных адресов, DHCP, динамические обновления, автоматизацию и общие процедуры. Более раннее и более широкое внедрение этих практик могло бы снизить трудность перенумерации. Вероятное направление этой выгоды ясно, тогда как её величина остаётся неизмеренной.

Временный более специфичный маршрут также зависел от систем за пределами прямых отношений с провайдером. Двустороннее соглашение могло обеспечить анонс и локальную обработку, тогда как распространение в масштабе всего Интернета по-прежнему зависело от других автономных систем. Документирование и ревью могли бы сделать эту зависимость видимой, не превращая ни один орган в гаранта универсальной достижимости.

Самая сильная контрфактическая альтернатива, таким образом, — более подотчётный переход внутри системы маршрутизации, которая по-прежнему агрегирует. Цель сжатия CIDR оставалась убедительной. Лучшие инструменты и явная обработка исключений могли бы сделать издержки, которые несут переходящие сети, более предсказуемыми и оспоримыми.

Сохранившиеся записи того периода легче выявляют отсутствовавшие гарантии, чем их распространённость. В них нет полных клиентских дел, по которым можно было бы измерить, как часто существовала такая рамка и как провайдеры обрабатывали разумные исключения по всей совокупности.

Что позволяют доказательства

Инженерные доказательства образуют связную, хотя и несовершенную цепь. RFC 1519 даёт ряд маршрутов 1988–1992 годов из источника Merit и явные прогнозы. RFC 1467 фиксирует скорость роста базы политик в 1993 году, изменения в распределении, пропущенный рубеж, состояния вендоров и ограничения провайдеров. RFC 1482 документирует намеченные операционные изменения Merit и прогнозный расчёт агрегации. Итоговый отчёт Merit, в доступном экземпляре которого нет явной даты публикации, относит развёртывание CIDR на NSFNET к 1994 году. Huston восстанавливает перелом 1994–1995 годов по измерениям SURFnet.

RFC 2008 даёт сравнение внутреннего и внешнего состояния AlterNet. RFC 4632 даёт более позднее подтверждение со стороны сообщества стандартов.

Ранние числа относятся к контекстам NSFNET или NSFNET/ANSNET, а не к переписи в масштабе всего Интернета. RFC 1482 фиксирует прогнозную конструкцию и расчёт. История Huston сшивает коллекторов и не раскрывает обработку более специфичных маршрутов в суммарном числе за 1994 год. RFC 2008 существенно опирается на частные сообщения и оставляет коллектора за числом без маршрута по умолчанию неуказанным. RFC 4632 — ретроспективный рассказ сообщества стандартов, а не современный административный аудит. Эти ограничения сужают масштаб и воспроизводимость количественного вывода.

В этих границах источники подтверждают существенное облегчение маршрутизации, согласующееся с агрегацией CIDR в наблюдённых точках. Они не подтверждают ни универсального числа таблиц, ни точной каузальной оценки против ненаблюдаемого будущего без мер из RFC 1519. Плато 1994 года и прогноз также относятся к разным датам: трёхлетний горизонт RFC 1519 начинается с его базовой линии января 1992 года.

Административные записи сильнее всего на уровне структуры и рабочих процессов. Они выявляют решения по распределению, субвыделению, агрегации, регистрации, выпуску ПО, приёму маршрутов, исключениям и перенумерации. Записи провайдеров в RFC 1467 большей частью останавливаются на ёмкости, состоянии кода, оценке риска или плане. ESNET фиксирует прогнозный ответ на конфигурационное давление. Отчёт Merit даёт свидетельство о развёртывании на уровне программы. AlterNet даёт единственную количественно измеренную сторону «после» у провайдера в доступном множестве.

Ни один второй названный случай провайдера не завершает полную цепь — от решения и инструмента через реализацию до измеренного последствия. В источниках также нет названного клиентского дела, прослеживающего отклонение более специфичного маршрута через ревью, исправление, завершённую перенумерацию или восстановленную достижимость. RFC 1900 характеризует тогдашнее бремя перенумерации, но не даёт знаменателя совокупности, средней стоимости, продолжительности или частоты сбоев. RFC 2008 излагает политические рекомендации и структурные механизмы, не устанавливая универсального внедрения или репрезентативных клиентских результатов.

Контрфактические записи столь же качественны. Они устанавливают неоднородные аппаратные и конфигурационные ограничения, повторяющееся состояние, требуемое более специфичными маршрутами, и концентрацию риска в источниках агрегатов. Они не дают полного альтернативного развёртывания, по которому можно было бы рассчитать задержку сходимости, полную стоимость, частоту сбоев, возможную продолжительность или благосостояние клиентов. Утверждения о более подтверждённом направлении этих эффектов должны оставаться отдельными от численных оценок.

Сохранившегося достаточно, чтобы выявить значимые возможности. Органы распределения определяли, можно ли агрегировать блоки. Провайдеры выбирали абстракцию, экспортируемую из их внутренней детализации. Merit формировал политические записи и конфигурацию для среды NSFNET. Вендоры влияли на сроки развёртывания. Соседние автономные системы решали, что принимать и распространять. Конечные сети несли издержки, связанные с выделением, мультихомингом, переносимостью и локальной перенумерацией.

Частота и распределение остаются невыясненными. Источники не показывают, как часто провайдеры отказывали в исключениях, сколько клиентов перенумеровалось, как работало ревью и какие участники в итоге несли наибольшие издержки. «Расширенный администратор» из заголовка, следовательно, описывает расширенное поле операционной ответственности, подкреплённое архитектурой, планами, свидетельствами реализации и одним количественно измеренным случаем провайдера. Это не популяционная мера реализованного влияния и не утверждение, что некий единоличный правитель получил контроль.

Соразмерный вердикт

CIDR дал существенное облегчение маршрутизации в наблюдённых точках 1994–1995 годов. Реконструкция Huston на основе SURFnet удерживалась около 20 000 записей в течение 1994 года, а отчёт AlterNet за октябрь 1995 года показывает механизм напрямую: 3 194 внутренних маршрута представлены 799 внешними анонсами, разница — 2 395.

Прогноз RFC 1519 в 75 000 маршрутов при отсутствии мер даёт исторический контекст, а не совпадающий по датам тест прогноза. Его трёхлетний горизонт начинался от базовой линии января 1992 года, тогда как плато Huston примерно в 20 000 записей описывает наблюдения 1994 года. Поэтому даты не совпадают точно. Сравнение показывает, что наблюдённый путь эпохи развёртывания был гораздо менее суровым, чем смоделированное будущее без мер; оно не превращает это будущее в наблюдённую контрфактическую ситуацию.

Сроки и механизм согласуются с ретроспективным описанием резкого спада в 1994 году и примерно линейного роста после середины того года. Практика распределения изменилась, появились блоки провайдеров, бесклассовое ПО дошло до сетей, агрегаты заменили составляющие, а AlterNet демонстрирует доступное провайдеру сжатие внутреннего состояния во внешнее.

Для получения такого результата требовались распределённые, характерные для того периода действия. IANA, Интернет-реестр и RIPE NCC изменили практику распределения. Merit перепроектировал политическую машинерию. Вендоры создали и выпустили код бесклассовой маршрутизации. Провайдеры установили его, сформировали агрегаты и сохранили внутреннюю детализацию. Соседние автономные системы применяли собственные маршрутные политики. Конечные сети действовали в рамках возникших ограничений переносимости и мультихоминга.

Эти действия создали значимые точки решений, чья структурная власть задокументирована лучше, чем их осуществление в масштабе совокупности. AlterNet остаётся единственной количественно измеренной стороной «после» у провайдера в доступном множестве; ESNET фиксирует план; в сохранившихся источниках нет названного клиентского случая, проходящего путь от исключения или отклонения через ревью и исправление до финальной достижимости.

CIDR спас таблицу в защитимом, ограниченном смысле: он остановил видимую траекторию роста 1994 года и позволил представить множество маршрутов меньшим числом анонсов. Он расширил администратора в столь же ограниченном смысле: успешная абстракция потребовала более явной ответственности за выделения, границы агрегатов, политические записи, ПО, исключения и приём.