Кратко

  • Рецензируемая работа 2026 года оценивает долю UPDATE вокруг реконструированных событий RPKI ниже 1% наблюдаемого объёма.
  • Метод относит к событию все обновления в выбранном окне сходимости, поэтому приписанный объём может быть завышен.
  • Доля не измеряет нагрузку на каждого соседа, изменения пути, Route Refresh или доступность для пользователей.

Небольшая доля отвечает на конкретный вопрос

Результат заслуживает внимания. Самуэле Куинци, Кристел Пелссер и Джузеппе Ди Баттиста в рецензируемой статье Proceedings of the ACM on Networking оценивают UPDATE в BGP вокруг изменений ROA. В аннотации сказано, что связанные обновления составляют менее 1% наблюдаемого объёма, несмотря на рост RPKI и таблицы маршрутизации. Вопрос конкретен: доминируют ли эти события в наблюдаемом потоке сообщений? В исследованном ряду — нет.

В гостевой публикации APNIC Куинци объясняет метод: события восстанавливаются по историческим данным, а все UPDATE в выбранном окне сходимости считаются связанными. Некоторые сообщения могли возникнуть по другим причинам; включение всех расширяет числитель. Поэтому доля ниже 1% — временная ассоциация по широкой схеме, а не доказательство, что каждое сообщение вызвано RPKI.

У устойчивости несколько измерений

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

RIPE RIS собирает маршрутизирующие данные через BGP-сеансы. RRC00 указан в Амстердаме как multihop-коллектор глобального охвата. «Глобальный» описывает охват коллектора, а не измерение каждого пути передачи, загрузки процессора каждого соседа или соединения каждого пользователя. Совокупная доля также не раскрывает возможную концентрацию сообщений на нескольких соседях.

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

Route Refresh создаёт отдельную нагрузку

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

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

Расширять данные, не смешивая показатели

Более широкий ответ потребует нескольких самостоятельных рядов: UPDATE по событию и соседу; запросы Route Refresh и повторно объявленные маршруты; время до устойчивого состояния; частота и длительность смены путей; при возможности — независимые сигналы доступности. Для каждого нужны точка наблюдения, период, знаменатель и правила обработки пропусков.

Исторический архив RPKI RIPE использует ежедневные снимки. APNIC отмечает, что кратковременные изменения могут остаться между ними. RPKI-Flutter наблюдает события чаще, но за более короткий недавний период; гостевая статья сообщает о похожих оценках UPDATE на общем отрезке. Это поддерживает реконструкцию сравниваемого объёма, но не измеряет автоматически нагрузку на соседей и опыт пользователей.

Справедливый вывод — не «у RPKI нет рисков» и не «RPKI расшатывает BGP». Работа даёт обнадёживающий ответ на узкий вопрос: в измеренном ряду события RPKI не составляют большую часть наблюдаемых UPDATE. Для общего суждения об устойчивости нужно сначала назвать ресурс, путь или сервис, о котором идёт речь.

Источники

Первичные источники и документы протокола: