Кратко

  • Индивидуальный проект IETF от 28 октября предлагает шесть новых типов пакетов и подписку на события, периодические обновления либо оба режима.
  • Событийный Push Notify содержит идентификатор подписки, тип изменения и серийный номер, но не передаёт изменённые объекты RPKI. Данные описаны в Periodic Update.

У оператора после изменения ROA два времени на часах. Первое — когда кэш узнал новость. Второе — когда маршрутизатор принял проверенные данные. Проект push-режима RTR обещает сократить задержку при критических событиях, однако формат срочного пакета закрывает только первый этап.

В RFC 8210 кэш уже может отправить Serial Notify без запроса маршрутизатора. Получив его, маршрутизатор вправе немедленно послать Serial Query или Reset Query, не ожидая таймера обновления. Действующий проект 8210bis сохраняет ту же схему. Кэш подаёт сигнал; маршрутизатор решает запрашивать ли изменения; ответ несёт объявления и отмены. Поэтому проблема не в полном отсутствии активного уведомления.

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

Push Notify содержит номер подписки, категорию изменения и серийный номер. Документ упоминает ROA, ASPA и ключи маршрутизаторов, но ни один из этих объектов в схеме пакета не передаётся. Последовательность дальнейшей доставки данных после события не расписана. Даже если сигнал приходит мгновенно, сам по себе он не меняет таблицу у маршрутизатора. Старый Serial Notify уже позволял запустить запрос без ожидания следующего цикла.

В Periodic Update содержится другая логика: по согласованному интервалу идут Cache Response, пакеты данных и End of Data. Кэш указывает серийный номер, который, по его мнению, держит маршрутизатор. При несовпадении с реальным номером маршрутизатор обязан отказаться от обработки. Значит, отправитель может предложить новый пакетный поток, но не вправе объявить локальное состояние получателя совпадающим со своим предположением.

Карточка IETF показывает индивидуальный проект с планируемым статусом Standards Track и текущим I-D Exists. В тексте нет воспроизводимого сравнения задержек или отчёта о внедрении. Следующая версия могла бы расписать путь данных после событийного сигнала и измерить время до принятия. Пока быстрый канал приносит звонок, а груз идёт по расписанию.