Кратко

  • RFC 9736 разделяет пространства TLV для Peer Up и Initiation и требует сохранять порядок повторяющихся String TLV. Он определяет владельца кодов, а не доказывает корректность развёрнутой системы.
  • Операционный вывод требует цепочки квитанций: версия реестра и отправителя, исходные байты, решение парсера, сохранённая запись, сессия, поток маршрутов, forwarding, действие и независимый результат.

Почему общий namespace перестал быть безобидным

Initiation описывает наблюдаемую систему, а Peer Up — BGP-сессию. RFC 7854 тем не менее дал им общий namespace Information TLV. По мере появления расширений стало неясно, кому принадлежит новый Type Code и какая семантика допустима в каждом сообщении.

RFC 9736 делит этот реестр. Старый получает имя BMP Initiation Information TLVs; новый — BMP Peer Up Message TLVs. Для Initiation Type 0 означает String, Type 1 — sysDescr, Type 2 — sysName. Для Peer Up Type 0 означает String, Type 3 — VRF/Table Name, Type 4 — Admin Label. Неуместные в каждом контексте номера зарезервированы.

Строка определяется числом байтов в Length и кодируется UTF-8; нулевой терминатор не требуется. Поле Information в Peer Up необязательно, а его наличие определяется через Message Length общего заголовка. String может повторяться, причём при отчёте порядок значений должен сохраниться. Если база оставила одно значение или отсортировала массив, она изменила доказательство.

Совместимость спецификаций не сертифицирует продукт

RFC 9736 сообщает, что реализации, соответствующие RFC 7854, 8671 и 9069, соответствуют и новому документу. Это позволяет перенести существующие назначения без изменения их wire semantics. Фраза не называет ни один vendor release и не проверяет production pipeline.

Коллектор может сохранить только последнюю повторённую строку. Может распознать Type 3, но связать имя таблицы не с тем эмулированным Loc-RIB peer. Может молча удалить будущий неизвестный TLV. Реестр IANA при этом остаётся верным; теряется локальная доказательность.

Поэтому квитанция начинается с исходных данных. Следует сохранить Peer Up bytes, идентификатор BMP-сессии, build и конфигурацию отправителя, Message Length и порядок TLV. Capture связывается с версией коллектора, parser schema, проверкой длины и unknown-TLV policy. Затем raw ingest сравнивается с декодированным объектом и сохранённой строкой. Без исходника нельзя отличить отсутствие на проводе от потери внутри системы.

Что остаётся после Peer Up

В RFC 7854 Peer Up сообщает о переходе наблюдаемой BGP-сессии в Established и несёт оба OPEN плюс TCP-данные. Но при старте самой BMP-сессии Peer Up отправляется и для peers, уже находящихся в Established. Время получения не всегда равно времени создания BGP-сессии.

RFC 8671 отделяет Peer Up/Down от того, будут ли поступать Route Monitoring или Route Mirroring для Adj-RIB-In либо Adj-RIB-Out. Initiation, Peer Up, первичный dump, End-of-RIB и incremental updates — разные этапы. Одна корректная запись не доказывает полноту feed.

RFC 9069 представляет Loc-RIB эмулированными peers, иногда несколькими на таблицу для разных address families. VRF/Table Name полезен, но имя global не уникально. Нужны также peer distinguisher, BGP ID и OPEN capabilities.

Цепочка, достойная решения

Оператор должен указать snapshot реестра, версию отправителя, BMP-сессию и peer epoch, байты сообщения, версию парсера, политику неизвестных типов, raw и decoded receipts, подтверждение сессии, coverage маршрутов, RIB/FIB или активное измерение, санкционированное действие и независимый результат.

Цепочка вправе закончиться неопределённостью. Peer Up доказывает отчёт о сессии, но не принятие маршрута. Полный feed может не доказывать аппаратный forwarding. Forwarding не обязательно доказывает бизнес-эффект. RFC 9736 укрепляет первый слой; дисциплина состоит в том, чтобы не выдавать его за последний.