Кратко

  • Индивидуальный проект методики ROV от 2 ноября отсчитывает полное время от отправки первого относящегося к изменению PDU RTR до стабилизации BGP RIB и FIB. Второй отсчёт начинается после установки соответствующего обновления VRP и заканчивается там же.
  • Первый интервал включает доставку RTR, установку VRP, повторную проверку маршрутов и сходимость BGP. Второй оставляет только работу после установки. При публикации одной цифры проект требует назвать выбранный интервал.
  • Размеры таблиц задают нагрузку; приложение B отдельно публикует измерения системы BIRD/Linux, которые нельзя переносить на другие маршрутизаторы. Сравнение требует отметок старта и финиша, нагрузки и серии запусков.

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

RFC 8210 определяет обмен RPKI-to-Router между кешем и маршрутизатором. RFC 6811 задаёт статусы Valid, Invalid и NotFound для происхождения маршрута BGP; решение о политике остаётся за сетью. Проверочный статус и таблица пересылки — разные состояния. Между ними находятся доставка данных, пересчёт, выбор маршрута и запись в FIB. Без подписи «задержка ROV» не говорит, какой этап попал в число.

В тесте сходимости при изменении VRP проект версии 00 ставит начало полного интервала на отправку RTR-эмулятором первого значимого PDU обновления. Конец наступает, когда стабилизировались и BGP RIB, и FIB. Второй интервал начинается после завершения установки нужного обновления VRP на испытуемом устройстве, а заканчивается в той же точке. Первый показывает время от нового свидетельства до устойчивой пересылки. Второй локализует затраты BGP после установки.

Рыночная ловушка — в простой арифметике. Пусть два устройства завершили стабилизацию FIB одновременно. Устройство с более поздним стартом секундомера покажет меньшее время. Это свойство измерения, а не утверждение о нечестности какого-либо производителя. Чтобы оценить конкретный продукт, нужны две отметки начала и общий конец одного и того же прогона.

Документ разбивает путь на более мелкие контрольные точки. В опыте по установке VRP отмечают первую RTR PDU и момент, когда изменение видно в локальной таблице. При наличии телеметрии разделяют установку первого и последнего VRP и обработку всей пачки. Отдельный опыт отслеживает изменение статуса затронутых BGP-префиксов. Полный тест наблюдает выбор лучших путей, отзыв или замену маршрутов и окончательную стабильность RIB и FIB. Фраза «проверка занимает миллисекунды» может быть точной для одного пункта и бесполезной для планирования всей цепочки.

Условия нагрузки должны быть видны рядом с результатом. Проект предлагает примеры таблиц на 50 тысяч, 100 тысяч, 500 тысяч и миллион VRP. Возможная базовая таблица BGP — миллион маршрутов IPv4 и 250 тысяч IPv6; семейства адресов можно измерять раздельно, указав это. Это лабораторные параметры, а не текущие размеры глобальной таблицы и не данные о скорости оборудования. Отчёт должен назвать фактическое количество ROA и VRP, долю охваченных BGP-маршрутов, пересечения VRP, распределение длин префиксов и число путей со сменившимся статусом.

Приложение B даёт проверку на собственных измерениях. В испытании BIRD 2.19.2/Linux с 1 060 368 исходными VRP, 1000 выбранными префиксами и 1230 операциями VRP среднее за десять прогонов составило 5027,552 мс от начала до конца и 4813,556 мс после установки. Разница около 214 мс — отрезок до позднего старта в этой среде; большая часть измеренного времени пришлась на этап после установки. Эти цифры не описывают другие маршрутизаторы. Пара показывает, зачем публиковать начало, нагрузку и конец вместе с результатом.

Изменения, сгруппированные в одной области структуры проверки, могут нагружать устройство иначе, чем рассеянные; проект просит испытать оба варианта. Перед замером RTR, VRP и BGP приводят к согласованному состоянию, устройство прогревают, журналы, потоковую телеметрию и фоновые задачи отключают или ограничивают, чтобы не искажать опыт. Это помогает воспроизвести результат. Рабочая сеть с включённым наблюдением должна повторить тест со своей конфигурацией: документ не даёт универсальной надбавки к лабораторному времени.

Проект не называет победителя и не сообщает об аварии. Он требует показать линию старта. При выборе ёмкости ROV главный интервал — от отправки RTR до устойчивой FIB. Время после установки полезно для диагностики, если опубликовано рядом с полным временем и его нагрузкой.

Проект методики ROV, версия 00 · RFC 8210 · RFC 6811