Кратко

  • Миграция RIPE NCC состояла из этапов: новая база заработала 23 апреля 2001 года, с 14 мая auto-dbm стал принимать только RPSL, а преобразование RIPE-181 завершилось 15 октября.
  • Публичные архивы связывают Andrei Robachevsky с этой работой в должности Database Group Manager: в 2000 году он описал новые функции запросов, а в апреле 2001-го подписал сообщение о завершении первой фазы.
  • Преобразование объекта меняет то, как его хранит и принимает реестр. Оно само по себе не доказывает право собственности на адресный ресурс, текущую BGP-анонсацию или фактический путь пакетов.

Миграция меняет и данные, и интерфейсы

Уведомление от 14 мая задавало простое правило: auto-dbm принимает только RPSL. Обновления RIPE-181 следовало отправлять на auto-181, где их преобразовывали до объявленного 15 октября. auto-rpsl продолжал принимать RPSL. Такое же разделение действовало для тестовой базы.

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

В сообщении от 23 апреля, подписанном Robachevsky, говорилось, что новая версия уже работает, а все объекты автоматически переведены в RPSL и загружены. Но это не означало, что все пути сразу перестали принимать старый формат. На первой фазе auto-dbm ещё допускал RIPE-181 с ограничениями: пустые и ошибочно написанные атрибуты запрещались, PGP-аутентификация по этому каналу не поддерживалась, а правила авторизации RPSL уже применялись. auto-rpsl принимал новый формат напрямую. Менялись не только записи, но и правила их публикации.

Запрос определяет, какой фрагмент записи увидит клиент

В августе 2000 года Robachevsky, указанный как Database Group Manager, описал изменения интерфейса запросов v3 и попросил сообщество поделиться замечаниями. Точный запрос возвращал объект, совпадающий с переданным диапазоном. Менее специфичный находил наименьший более широкий диапазон, который его включает. Опция -K оставляла только первичные ключи. Запрос источников показывал доступные базы и сведения о зеркалировании, в том числе диапазоны серийных номеров; обратный поиск позволял находить объекты по контактным атрибутам.

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

В черновике протокола Database WG для RIPE 38 зафиксировано, что Robachevsky провёл двадцатиминутное обсуждение миграции. В записи перечислены пользователи запросов и обновлений, скрипты и почти синхронные зеркала, а также RPSL, контроль доступа, формат базы и протокол зеркалирования. Документ помечен как черновик: он подтверждает содержание этой версии протокола о встрече, но сам по себе не доказывает, что последующие этапы прошли точно по плану. Для этого важнее официальные уведомления и годовой отчёт.

Совместимость распределяет издержки

В годовом отчёте RIPE NCC переход описан как шестимесячный процесс: с 23 апреля по 15 октября. Реестр поддерживал преобразование и объяснял правила; владельцы объектов должны были проверить генераторы обновлений; операторы зеркал — формат и синхронизацию; разработчики клиентов — новую семантику запросов. Источники не измеряют затраты каждого участника и не перечисляют все затронутые реализации. Но они показывают, чем управляла сама организация: допустимой грамматикой, авторизацией, адресами и датой отключения переходного канала.

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

RFC 2622 помогает не смешивать ещё одну роль. Документ описывает RPSL как язык для представления политик маршрутизации и рассматривает объект maintainer, связанный с авторизацией изменений. Среди авторов RFC указаны Alaettinoglu, Villamizar, Gerich, Kessens, Meyer, Bates, Karrenberg и Terpstra; Robachevsky в списке отсутствует. Из его задокументированной роли в миграции нельзя выводить авторство RPSL или RFC 2622.

Запись реестра и маршрут в сети

Объект RIPE Database, политика в Internet Routing Registry и наблюдение BGP отвечают на разные вопросы. Преобразованная запись показывает, что база хранила в тот момент. Объект RPSL описывает заявленную политику. Коллектор маршрутов может подтвердить, что конкретная точка наблюдения видела объявление в определённое время. Ни один источник не заменяет другой. Регистрация не доказывает текущую доступность, доставку пакетов, юридическое владение или соблюдение политики всеми маршрутизаторами.

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

Что архив позволяет сказать о Robachevsky

В августе 2000 года Robachevsky подписал письмо рабочей группы как Database Group Manager и описал функции запросов v3. В апреле следующего года он подписал уведомление о первой фазе, автоматическом преобразовании и временных ограничениях для RIPE-181. Черновик RIPE 38 называет его запланированным докладчиком. Это позволяет описать менеджера, который разъяснял переход и собирал обратную связь. Но источники не доказывают, что он написал программу преобразования, единолично определил все правила или лично проверил каждую запись.

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

Источники