Кратко

  • Предложенный в RFC 1482 реестр фиксировал префикс, Home AS, каждый Announcing AS, его соседей и контакты. Это была заявленная политика распространения, а не наблюдение живого обновления.
  • При proxy-агрегации получение любого одного компонента могло вызвать создание более крупного префикса. Такая запись в удалённой таблице не подтверждала доступность всех адресов внутри покрытия.

Между заявкой и пакетом лежала цепочка преобразований

RFC 1482 задумывал сведения об агрегатах как электронно доступный координационный ресурс, полезный не только сообществу NSFNET. Обновление могло прийти письмом или через онлайн-инструмент регистрации.

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

Поэтому запись, сгенерированный файл, установленный файл и работающее состояние были связанными, но самостоятельными артефактами. Новая строка могла сосуществовать со старой конфигурацией. Корректно созданный файл мог не загрузиться. Загруженная политика могла не встретить ожидаемого объявления.

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

Старая база хранила ожидаемых говорящих

Policy-Based Routing Database NSFNET уже связывала номер сети с AS, от которых backbone ожидал её объявления. Для сети 35 RFC показывал основной, вторичные и дополнительные источники.

Этот список описывал допустимость. Он не был журналом обновлений. Наличие AS в записи не подтверждало, что AS говорил в данный момент. Полученное обновление не обязательно становилось выбранным маршрутом, а выбранный маршрут — записью пересылки.

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

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

Home AS не заменял транзит

В новом Aggregate Registry указывались CIDR-префикс, Home AS, Announcing AS, Neighbor AS и контакты. Home AS первоначально объединял достижимость компонентов. Announcing AS получал агрегат и передавал его собственным соседям.

В примере AS 100 выступал домом. Тот же префикс повторялся для AS 690, AS 200 и AS 201, причём у каждого был свой набор адресатов. Повторение сохраняло роли распространения.

Наблюдатель за AS 690 мог получить маршрут именно от AS 690. Это не делало транзит Home AS. Но и запись AS 100 как дома не означала прямой связи AS 100 со всеми наблюдателями.

Поздний RFC 1771 подробно описывает атрибуты BGP-4 и AS_PATH, помогая различать непосредственного соседа и предшествующие AS. Он не превращает проектную строку 1993 года в доказательство реально отправленного обновления.

Один компонент мог породить видимость целого

Региональная сеть с поддержкой CIDR могла объявить агрегат напрямую. Для сети без такой возможности backbone мог выполнить агрегацию по доверенности.

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

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

RFC отдельно упоминал «дыры»: трафик к непокрытой части мог пересечь AS, прежде чем его отбросят. Агрегат сокращал описание направления. Он не выдавал квитанцию о доставке каждому адресу.

Детализация не обещалась всем соседям

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

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

RFC 1338 и RFC 1519 описывают архитектурную необходимость бесклассового распределения и агрегации. RFC 1786 позже предлагает более богатое представление политик в routing registry. Эти документы поясняют эволюцию, но не подтверждают задним числом выполнение каждой детали RFC 1482.

Реестр не имел телеметрии, которой от него иногда ждут

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

Это не позволяет назвать весь замысел недостоверным. Оно лишь ограничивает вывод: строка отвечала на вопрос, кто намеревался объявлять агрегат каким соседям. Для ответа о том, что произошло, нужны были наблюдения протокола и пересылки с собственным временем.

33 процента оставались оценкой

Документ рассчитал возможное сокращение на 4.135 объявлений из 12.348, или 33 процента. Он назвал результат оптимистичной оценкой на основе пессимистического алгоритма и предупредил, что реальная экономия может отличаться.

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

Страница RFC Editor относит документ к Historic. Текст говорил, что реализация началась, но оставлял на будущее планирование, обсуждение, отладку, устойчивость, алгоритмы решений и обработку дыр. Состояние проекта не является актом ввода конкретного устройства.

История агрегата должна быть подробнее самого агрегата

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

Следует хранить компоненты и границу, Home AS, каждый транзит и его соседей, версию реестра, сгенерированную и установленную конфигурации, принятое обновление, выбор, экспорт, next hop и ответ назначения.

Если оставить только конечный агрегат, будет известно, что покрытие существовало. Но исчезнет ответ, кто его вызвал, какой компонент сработал, кому оно предназначалось и где скрывалась дыра. RFC 1482 напоминает: сокращать таблицу можно, сокращать происхождение доказательства нельзя.

Источники