Кратко

  • draft-geng-grow-bmp-rr-sync-00 предлагает последовательность BoRR, Route Monitoring и EoRR для точечной синхронизации одной BMP RIB-view без сброса других сессий.
  • EoRR подтверждает заявление отправителя о завершении; он не подтверждает, что каждый маршрут был сформирован, передан, принят и записан.

Коллектор получает EoRR и удаляет всё, что осталось stale. Это может точно отразить состояние маршрутизатора. Но та же последовательность получится, если пакет записей потерялся во внутренней очереди или live withdrawal пересёкся с replay на неясной границе. Корректный финальный маркер завершает обе истории.

Такова доказательная граница BMP Extension for Non-Disruptive RIB View Synchronization, загруженного 30 сентября 2026 года. Версия 00 — активный индивидуальный Internet-Draft со статусом I-D Exists. В заголовке указан Standards Track, а поле предполагаемого статуса RFC в Datatracker пусто. Это не документ рабочей группы GROW, не RFC, не назначение IANA и не отчёт о внедрении.

Точечный ремонт вместо общего сброса

BMP передаёт состояние BGP на коллекторы. Короткий сбой, переполнение буфера или перезапуск процесса оставляют сохранённую копию расходящейся с RIB отправителя. Сбрасывать весь BMP-сеанс или затрагивать BGP peer ради одной view слишком дорого.

Проект добавляет BMP Route-Refresh. Для <Peer, AFI, SAFI> отправитель посылает BoRR, передаёт полный текущий набор активных маршрутов в сообщениях Route Monitoring, затем EoRR. Коллектор помечает старые записи stale, обновляет появившиеся и в конце удаляет остаток. Заимствованный из RFC 7313 шаблон действительно уменьшает зону воздействия.

Конверт без описи

В версии 00 нет ID операции, ожидаемого количества, подтверждения по prefix, финального digest или независимого readback. В примере между маркерами допустимо ноль или больше RM. Ноль корректен для пустой RIB; ровно так же выглядит потеря всех сообщений replay при сохранившемся EoRR.

RFC 7854 использует Route Monitoring и для snapshot, и для непрерывных изменений, не требует порядка dump и допускает сжатие состояния. Проект не помечает каждое RM как replay или live и не привязывает параллельные изменения к нумерованной эпохе. Отправитель знает смысл, а другой коллектор восстанавливает его по TCP-порядку и локальным правилам.

Идентичность view шире тройки

RFC 8671 разделяет Adj-RIB-In и Adj-RIB-Out, pre-policy и post-policy. RFC 9069 добавляет Loc-RIB instance и filtered view. Надёжная квитанция должна фиксировать peer type, distinguisher, BGP ID, направление, этап политики, instance, фильтр и версию export-конфигурации.

Полная Adj-RIB-In не доказывает Loc-RIB. Полная Loc-RIB не доказывает FIB, прохождение пакетов или результат сервиса.

TLS не считает отсутствующие маршруты

Проект предупреждает о поддельном EoRR и требует IPsec, TLS или строгие ACL. Защита подтверждает канал и целостность. Она не подтверждает полноту набора у авторизованного отправителя, отсутствие внутренней потери или commit всех сообщений до purge.

Нужная цепочка включает разрешённый trigger, полную идентичность view, ID и стартовую эпоху, получение BoRR и commit stale, count или digest отправителя, loss и backpressure, порядок live updates, отправку и получение EoRR, числа purge и reject, затем итоговое сравнение.

Принцип минимальной спецификации Heng Lu отделяет общий смысл от локального доказательства. Running-code primacy требует фактов о том, что системы действительно увидели, записали и сравнили. EoRR может закончить replay; полноту должна подтверждать отдельная квитанция.

Источники