Кратко

  • RFC 9757 позволяет через PCEP согласовать BGP-сессии, явные маршруты к соседу, объявления префиксов и пересылку Raw или Tunnel, но PCInitiate фиксирует намерение контроллера, а PCRpt — лишь ограниченное свидетельство PCC.
  • Эксплуатационная цепочка должна продолжаться через полномочия и эпоху контроллера, синхронизацию, двустороннюю идентичность BGP, принятие политикой, установку в RIB/FIB, пакетные canary-тесты, упорядоченное восстановление и доказанную очистку.

Контроллер способен получить безупречную последовательность подтверждений, когда работоспособность сервиса ещё не доказана. Один маршрутизатор сообщает, что обработал инструкцию по соседству. Промежуточные узлы подтверждают явные маршруты. Пограничные устройства говорят, что отправили префиксы. Символьное имя пути и идентификатор контроллера совпадают, экран становится зелёным. Но эта цепочка не обязана показывать, что удалённый BGP-спикер принял маршрут, что каждая таблица пересылки содержит нужный next hop, что переключение прошло без петли и что хотя бы один пакет пересёк путь.

В RFC 9757 эта граница особенно важна: документ распространяет модель PCE-as-a-Central-Controller на обычные механизмы сети Native IP. Он опубликован со статусом Experimental и описывает пути, составленные из BGP-сессий, хостовых маршрутов и объявлений префиксов. Записи RFC Editor и Datatracker подтверждают идентичность и статус спецификации. Сам RFC просит отзывы о реализации и развёртывании, эксплуатационном воздействии, масштабировании и стабильности. Выделенные объекты и нормативные процедуры поэтому не являются доказательством распространения или производственного успеха.

Три инструкции связаны именем пути, но не стали одной транзакцией

Для Native IP сообщение PCInitiate несёт объекты SRP и LSP, Central Controller Instruction с Object-Type 2 и ровно один из трёх новых объектов. BPI описывает BGP-соседа. EPR описывает хостовый маршрут к нему. PPA описывает префиксы, которые следует ему объявить. Symbolic Path Name связывает распределённые инструкции в единый сквозной путь, а CC-ID различает указание контроллера внутри PCEP-сессии.

Такая корреляция ценна, но не делает выполнение атомарным. Одному пути нужны разные объекты на разных устройствах, и каждый PCC сообщает только о порученной ему работе. PCRpt может подтвердить инструкцию и участвовать в синхронизации состояния. Однако повторение объекта не превращает PCC в независимого свидетеля. Это отчёт о том, что PCEP-реализация и локальные модули управления считают обработанным.

Граница начинается ещё до команд. Оба участника PCEP должны объявить Path Setup Type 4 и бит Native-IP capability. Несовместимое согласование приводит к определённым ошибкам и завершению сессии. Это защищает от незаметного расхождения возможностей, но не доказывает свежесть топологии у PCE, корректность организационных полномочий, полноту набора PCC или безопасность окна изменений. Помимо аутентификации PCE и защищённого PCEP-канала, эксплуатация должна сохранить удостоверенную личность контроллера, объём разрешений, владельца решения и эпоху управления.

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

У BGP должны быть свидетели с обеих сторон

В BGP Peer Info входят AS соседа, локальный и удалённый адреса, EBGP TTL, поле состояния или ошибки и бит T, выбирающий стратегию пересылки. Адреса должны быть выделены для Native IP, а не разделяться с вручную созданной сессией. Получивший объект PCC пытается установить сессию и сообщает о ходе, успехе или отказе.

Ключевое слово — «сообщает». RFC 9757 не меняет конечный автомат BGP из RFC 4271. Она передаёт выбранные параметры локальному BGP-модулю; многие остальные значения берутся по умолчанию. Статус BPI established — полезное свидетельство одного устройства, но не двусторонний протокол сессии. Эксплуатационная квитанция должна объединять адреса и AS обоих концов, AFI/SAFI, защиту транспорта, экземпляр политики, идентичности маршрутизаторов, поколение сессии и времена установления. Иначе старое соседство, неожиданный default или неверный peer могут получить ту же успокаивающую метку.

Более широкая архитектура CCDR в RFC 8821 использует несколько BGP-сессий для формирования выбора пути Native IP. Эта цель не отменяет политику импорта и экспорта. Когда PPA предписывает пограничному PCC объявить префиксы определённому соседу, RFC 9757 требует отчёт после успешной отправки. «Отправлено» заканчивается на локальной стороне. Оно не доказывает доставку, запись в Adj-RIB-In соседа, прохождение route policy, выбор лучшего пути, дальнейшее объявление или использование для пересылки. Для значимых изменений следует связать идентификатор исходящего UPDATE, свидетельство принимающего соседа, точную ревизию политики, выбор Loc-RIB и запись FIB, которую встретит трафик.

Подтверждение маршрута — не чтение линейной карты

EPR связывает настройку соседа с достижимостью. Он устанавливает хостовые маршруты к адресам соседства — как правило, с приоритетом выше динамических IGP-маршрутов и ниже ручных или иных статических записей. PCC должен проверить достижимость next hop. Чтобы не создать временную петлю, PCE добавляет состояние EPR в обратном порядке сквозного пути, удаляет в прямом порядке и при обновлении устанавливает новый next hop до удаления старой инструкции.

Эта последовательность — самостоятельная поверхность контроля. Журнал должен хранить версию пути, зависимости устройств, время отправки и ответа, разрешение next hop и момент удаления старого состояния. Успешный PCRpt показывает, что PCC принял или завершил операцию EPR в рамках своей реализации. Всё равно нужны независимые чтения RIB и FIB, состояние adjacency и наблюдение пакетов. Маршрут может присутствовать в control plane, но проиграть предпочтение, не попасть в аппаратную таблицу, ссылаться на устаревшее соседство или прийти после того, как другой узел уже убрал старый путь.

То же разграничение действует для Raw и Tunnel. Raw пересылает по исходному адресу назначения; степень управления путём умеренная, и трафик с другого входа может разделить предпочтительный сегмент. Tunnel применяет IP-in-IP между выбранными входом и выходом, жёстче связывая эту пару. Бит T фиксирует выбор, но не доказывает инкапсуляцию, декапсуляцию, безопасный MTU, проверку источника, идентичность конечных точек или фактический путь. В canary-пакете нужны идентификатор входа, класс потока, размер, время и ожидаемый выход; для Tunnel требуются отдельные свидетельства обоих концов.

При отказе корреляция становится вопросом времени

RFC 9757 рассматривает BPI, EPR и PPA с одним Symbolic Path Name как атрибуты общего пути в базе LSP и использует синхронизацию из RFC 8232. Stateful-модель RFC 8231, процедуры PCE-initiated из RFC 8281 и центральные инструкции RFC 9050 задают окружающие правила состояния, делегирования и таймаута.

Синхронизация доказывает то, что было сообщено в пределах конкретной версии базы и контекста сессии. Она не останавливает сеть. Если PCC выходит из-под управления, PCE должен пересчитать и развернуть путь на активных PCC, избегая временных петель. При отказе PCE инструкции можно делегировать заново, а существующее состояние способно прожить до State Timeout Interval. Поэтому доказательствам нужны эпоха контроллера, поколение PCEP-сессии, версия базы, набор PCC и точное время каждой смены полномочий.

Очистка — тоже не одна кнопка Delete. PCE отправляет явные инструкции удаления для PPA, EPR и BPI. Безопасное подтверждение следует зависимостям: требуемые объявления отозваны; устаревшая пересылка исчезла, не оборвав преждевременно оставшийся путь; BGP-сессия и её конфигурация удалены; в RIB, FIB, таблицах туннелей и синхронизированной базе не осталось состояния. Последний свидетель сочетает отрицательный и положительный тест: выведенный путь больше не несёт canary, а оставшийся или откатный путь продолжает его нести.

Принцип Heng Lu Running-Code Primacy предлагает полезную дисциплину: координационные артефакты не могут быть важнее реализации, проверки, развёртывания и использования. Minimum Initial Specification отделяет общий технический словарь от последующих локальных решений. Применительно к RFC 9757 это значит ценить её слой корреляции, не заставляя его удостоверять факты за пределами наблюдения.

Руководству нужен реестр из десяти связанных квитанций: полномочия и эпоха; взаимная capability; завершённая синхронизация; запрос и ответ для каждого объекта; двусторонняя идентичность BGP; принятие политикой; реализация RIB/FIB; состояние Raw/Tunnel; пакетные и сервисные canary; пересчёт, отзыв и rollback. RFC 9757 улучшает первую половину цепи. Её ценность не в превращении PCRpt в доказательство пакета, а в том, чтобы сделать границу явной до того, как зелёный экран станет неподкреплённым деловым решением.

Реестр источников

Текущее состояние документа проверяется через поиск errata для RFC 9757. Основу PCEP задаёт RFC 5440, а RFC 8408 и RFC 8283 дают контекст PST и PCECC. Редакционные критерии также опираются на тексты Heng Lu Reality, Not Advocacy и Reality Layers.