Кратко

  • Версия 03 проекта рабочей группы PCE предлагает согласовать возможность S-BFD в OPEN, а затем передавать запрос для отдельного LSP через LSPA. PCE инициирует или меняет путь, PCC сообщает состояние.
  • При B=1 нужен удалённый дискриминатор. При B=0 разные разделы по-разному описывают судьбу параметров, а удаление по отсутствию всего TLV пока существует лишь как редакторская альтернатива.

Кому принадлежит последняя запись

Path Computation Element (PCE) рассчитывает путь и может отправлять распоряжения по PCEP. Path Computation Client (PCC) находится рядом с самим путём и держит его рабочее состояние. Проект расширения для параметров BFD предлагает передавать через этот протокол настройки Seamless Bidirectional Forwarding Detection (S-BFD) для конкретного Label-Switched Path (LSP). Централизованное управление удобно ровно до того момента, когда запись «команда отправлена» принимают за запись «детектор работает». Эти строки появляются на разных машинах.

Сначала участники договариваются, понимают ли они новое расширение. В объект OPEN при создании сессии помещается LSP-S-BFD-Capability TLV. Полученный B=1 означает способность партнёра обмениваться новыми TLV. Если поле отсутствует либо B в OPEN равен нулю, отправлять ему S-BFD TLV в объекте LSPA нельзя. Перечень типов построения пути, указанный для S-BFD, должен входить в список типов, поддерживаемых всей сессией PCEP. Посторонний тип вызывает PCErr с типом 21 и значением 2 и закрытие сессии. Когда общего подходящего типа нет, предложенный механизм не может задавать S-BFD для создаваемых LSP через PCEP.

Так очерчивается область общего языка. Сам PCC может по местной политике использовать S-BFD без этого удалённого механизма. Успешный обмен OPEN, в свою очередь, ничего не включает на определённом LSP. Возможность обмена сообщениями и уже применённая конфигурация занимают разные графы журнала. Если производитель помещает их в одну зелёную пиктограмму «поддерживается», оператору потом придётся разбирать, что именно поддерживалось и что действительно работало.

Поле для конкретного LSP переносится в LSPA. PCC посылает его в PCRpt, PCE — в PCInit либо PCUpd. Здесь B отвечает уже не за переговоры между партнёрами, а за состояние S-BFD на пути. Одинаковая буква скрывает две разные ступени: OPEN допускает разговор, LSP-TLV содержит указание. Отчёт PCC добавляет ещё одну ступень. Между указанием и работающей сессией остаётся локальное применение настройки; проект не даёт контроллеру возможности перескочить через этот факт одной записью в своём логе.

Включить можно по полям. Выключить — пока по трактовке

При B=1 для LSP проект велит применить S-BFD и требует подполе с удалённым дискриминатором. За его отсутствие предусмотрена ошибка. Дополнительное подполе может передать минимальный интервал отправки и множитель от 1 до 255. Контроллер, сохранивший только значение B, потеряет часть своего же распоряжения. Для проверки нужны и обязательный дискриминатор, и параметры, которые PCC получил вместе с командой.

Базовое правило для B=0 дано в разделе 4.3.2.1: при обновлении от PCE S-BFD удаляется, при создании LSP контроллером не применяется. Раздел 4.2 отдельно велит PCC игнорировать обновление B=0, если S-BFD на этом LSP не было. PCE может игнорировать такой же сигнал для пути, инициированного PCC, при том же исходном состоянии. Удалять пустое место бессмысленно. Важнее не отметить такую операцию как успешное удаление действовавшего детектора. Отправленная просьба и изменение локального состояния — два события.

С параметрами при B=0 возникает настоящий спор. Раздел 4.2 говорит, что участник может игнорировать их подполе; игнорировать его или сохранить конфигурацию решает реализация. Раздел 4.3.2.2 говорит, что подполе должно игнорироваться. Затем редакторская заметка предлагает совсем иной признак удаления: если весь LSP-S-BFD TLV перестал поступать, S-BFD на существующем LSP надо снять. Эта заметка обозначена как альтернатива, а не действующее правило. Явный ноль в поле и отсутствие поля целиком — разные последовательности байтов и разные поводы для действий. Объединить их в кнопку «выкл.» на панели легко; сделать одинаково понятными двум реализациям гораздо труднее.

Некоторые ошибки проект уже умеет называть. Если S-BFD TLV приходит от партнёра, не заявившего соответствующую возможность, его содержимое игнорируется и возвращается PCErr типа 19. Множитель вне диапазона 1–255 приводит к ошибке типа 23. Новые значения для этих ошибок и типы TLV в разделе IANA пока обозначены TBD. Класс отказа можно указать точно, но не стоит выдавать ещё не распределённый номер за запись реестра.

Ещё одно ограничение открывается внутри группы ассоциации. Раздел 6 говорит: в некоторых реализациях LSP одной группы должны иметь одинаковые параметры S-BFD. Если различаются минимальный интервал, множитель либо удалённый дискриминатор, участнику следует выдать ошибку ассоциации типа 26. Это условная заметка о реализации. Превратить её в неизменный закон всех сетей — значит приписать проекту больше власти, чем он берёт. Контроллер может предложить разнородные параметры; PCC может отвергнуть их из-за местного ограничения. Ответ должен позволить отличить такой отказ от провала переговоров в OPEN.

RFC 7880 описывает сам S-BFD. RFC 8231 и RFC 8281 дают основы PCEP с состоянием и LSP, инициируемых PCE; проект также ссылается на RFC 9050 с архитектурой центрального контроллера. Они объясняют, почему такая команда появилась в повестке. Новый TLV остаётся проектом, а не результатом испытаний в названной сети. Между версией 02 и версией 03 обновились дата, срок действия и оформление; существенное правило выключения сохранило оба конфликтующих глагола. Новая цифра в названии документа ещё не выключила детектор.

Проверка в рабочей системе должна собрать цепочку для одного LSP: объявление возможности в OPEN, общий тип пути, сообщение PCInit или PCUpd, отчёт PCRpt, действующую настройку PCC и состояние сессии S-BFD. Первая пара подтверждает право вести разговор. Сообщение показывает волю PCE. Отчёт показывает, что заявил PCC. Последняя пара отвечает, что реально применено и что запущено. Если речь заходит о здоровье пути, понадобятся отдельные наблюдения. Число нажатий кнопки у контроллера не измеряет работу детектора.

В официальном наборе источников нет трассы, связывающей B=0 или B=1 этого расширения с отчётом, конфигурацией и сессией конкретного PCC. Такая трасса изменила бы вывод для указанной реализации. Редакторам остаётся вопрос, общий для всех: сохранять параметры после B=0 или безусловно отбрасывать, а молчание в виде отсутствующего TLV считать приказом или просто отсутствием новой команды?

Источники