Кратко

  • Ранняя рецензия Дональда Истлейка для Routing Area Directorate завершена 27 сентября с оценкой «Not ready». Это мнение рецензента об активном проекте рабочей группы IDR, а не отклонение IESG.
  • Редакция 13 предлагает SHOULD проверять достижимость следующего узла в базе пересылки выбранной плоскости данных и MAY дополнительно проверять доступность пути. Что именно происходит с кандидатом на лучший маршрут при неудаче, явно не сказано.
  • Рецензент настаивает на проверке состояния, которое будет реально использовано для пакетов, включая конкретную метку или туннель и рекурсивное разрешение. Другая подходящая на вид запись может не иметь отношения к выбранному пути.

Таблица IP может содержать следующий узел, а транспорт к нему — отсутствовать. Проект IDR объясняет проблему на примере MPLS VPN: пограничный маршрутизатор видит путь в таблице, но предназначенный для трафика LSP не функционирует. Маршрут всё ещё может привлекать пакеты и объявляться соседям, хотя через другой пограничный узел был бы доступен альтернативный путь. Это схема возможной неисправности, а не сообщение о зафиксированной аварии.

Новая дата относится к рецензии. Дональд Истлейк III датировал её текст 25 сентября; Datatracker отметил завершение 27 сентября и результат «Not ready». Сам draft-ietf-idr-bgp-bestpath-selection-criteria-13 от 14 сентября остаётся действующим Internet-Draft рабочей группы IDR с предполагаемым статусом Proposed Standard. У IESG он значится как «I-D Exists», заседание не назначено. Пометка об обновлении RFC 4271 прямо оговаривает условие «if approved». Рабочая группа проходила Last Call и проверку директора области ещё в 2020 году. Следовательно, нынешний отзыв не означает ни первого рассмотрения темы, ни окончательного решения IETF.

В разделе 3 проект содержит два важных условия. Достижимость следующего узла SHOULD определяться по базе пересылки той плоскости данных, которую выбрала политика. Проверка работоспособности пути средствами OAM той же плоскости MAY проводиться дополнительно. Выбор политики и конкретного способа автор оставляет за пределами документа. Истлейк признаёт проблему реальной, но обращает внимание на разрыв: RFC 4271 уже исключает неразрешимый маршрут из второй фазы выбора. Новая редакция не сообщает прямо, считается ли маршрут неразрешимым после провала первой или второй проверки. Предложенная рецензентом формулировка с MUST — предложение к исправлению, а не действующий текст проекта.

Даже при чётком последствии остаётся вопрос, какую запись проверять. Для MPLS фактический путь может использовать метку LDP, prefix SID в Segment Routing, туннель RSVP-TE или SR Policy либо BGP labeled unicast с дальнейшим рекурсивным разрешением. Для непосредственного соседа может быть нужна запись без метки. Существование иной записи в базе не доказывает пригодность механизма, по которому пойдут пакеты. Рецензент предлагает проверять именно эту цепочку, иначе две реализации могут выбрать разные лучшие маршруты из одинаковых входных данных.

Существующие правила также нужно согласовать. RFC 9012 уже считает маршрут неразрешимым, если атрибут Tunnel Encapsulation не содержит осуществимого туннеля. Истлейк спрашивает, что к этому добавляет новый текст; это не доказанный конфликт стандартов. Его замечания об OAM охватывают колебания сигнала, ложные ответы, неопределённость при запуске и возможные петли при разных решениях IP-маршрутизаторов. Речь о рисках конструкции, а не об измеренных последствиях конкретного внедрения.

Практический след решения включал бы выбранную плоскость данных, применяемую метку или туннель, рекурсивное разрешение, результат проверки и фактическое решение о маршруте. Daniel Kade предлагает связывать эти факты для локальной подотчётности; IETF пока не предписывает такой журнал. Публикация проекта также не показывает, какие сети уже используют эти проверки.

Источники