Кратко

  • RFC 9917 — Proposed Standard IETF, опубликованный в январе 2026 года; он обновляет RFC 9350 и RFC 9843. Документ добавляет ограничения reverse affinity, использующие Extended Administrative Groups на обратном ребре для исключения соответствующего прямого ребра при расчёте Flex-Algorithm.
  • Для безопасного включения нужны владелец телеметрии, раздельные пороги установки и снятия, проверка кодирования, согласованный выигравший FAD, проверенная поддержка и измеримый rollback. RFC не выполняет эту операционную работу автоматически.

Механизм

Рассмотрим два направленных ребра: прямое, по которому трафик покидает узел, и обратное, на котором удалённая сторона может сообщить о своём приёме. Дальний получатель способен увидеть входные ошибки, а CRC errors RFC 9917 приводит только как пример. Если показатель пересекает порог, заданный оператором, на обратном ребре можно установить Extended Administrative Group. Затем вычисление пути может использовать эту группу как основание для исключения соответствующего прямого ребра из конкретной топологии Flex-Algorithm.

Это не означает, что RFC 9917 сам обнаруживает неисправность или сам связывает живую телеметрию с группой. Документ не задаёт универсальные пороги и не доказывает наличие такой интеграции у конкретного производителя. Reverse affinity также не делает физическую линию двунаправленно симметричной: речь идёт о направленном входе в политику маршрутизации.

Ограничения для IS-IS и OSPF

RFC 9917 определяет для IS-IS и OSPF три варианта обратного Admin Group constraint. Exclude исключает ребро при наличии требуемой группы. Include-any требует совпадения хотя бы с одной группой из списка. Include-all требует совпадения со всеми указанными группами. Это не универсальная гарантия, что каждый маршрутизатор поддерживает каждый constraint для каждого Flex-Algorithm.

Форматный контроль столь же важен, как и логика маршрута. Неправильная длина reverse-affinity sub-TLV игнорируется. Дублирующиеся вхождения обрабатываются так, как предписано для соответствующих получателей IS-IS и OSPF в RFC 9917. Нельзя без основания расширять это поведение или переносить результат проверки одного протокола на другой.

Упорядоченный реестр pruning

Правила 8, 9 и 10 расширяют уже существующий упорядоченный реестр pruning, описанный в связи с RFC 9350 и RFC 9843. Относительный порядок прежних правил менять нельзя; правила нельзя удалять, объединять или повторять. Поэтому сначала необходимо определить выигравший FAD, а затем применить единую последовательность правил. Формально принятый FAD сам по себе не доказывает, что все узлы построят одинаковую обрезанную топологию.

За кодирование Extended Administrative Group отвечает RFC 7308. В тесте нужно подтвердить длину, значение, число появлений и передачу sub-TLV, а не только увидеть ожидаемый маршрут. При смешанной поддержке один и тот же сигнал может привести к различному pruning. Какие реализации поддерживают RFC 9917, из данных RFC вывести нельзя.

Flooding и повторный пересчёт

Если группа меняется при каждом колебании показателя, сеть может получить лишний IGP flooding и повторные пересчёты путей. RFC 9917 предлагает рассматривать разные пороги set и clear/unset, а также обычное IGP throttling. Это возможные средства сдерживания, а не готовые значения для любой сети. Нужно измерять частоту изменения группы, объём объявлений, число пересчётов, время сходимости и устойчивость резервного пути.

Анализ Theo March

Операторское решение должно связывать весь процесс: кто владеет телеметрией, кто утверждает пороги, кто проверяет кодирование, как подтверждается выигравший FAD, какие узлы поддерживают IS-IS, OSPF и три семейства ограничений, что видно в наблюдаемости и как выполняется rollback. Приёмочный сценарий должен сравнить прямые и обратные атрибуты, состояние группы, FAD и обрезанную топологию и при установке, и при снятии сигнала.

Тема этой статьи не совпадает с воспроизведением PCEPS и границами TLS 1.3 early data в RFC 9916, с жизненным циклом аренды DHCPv6 в RFC 9915, с проекцией маршрутов RPL в RFC 9914 или с восстановлением RAW в RFC 9912. Здесь рассматривается именно доказательство на обратном направлении как упорядоченный вход для pruning IGP Flex-Algorithm.

Реестр «утверждение — RFC»

Утверждение Источник
Reverse affinity, статус и правила 8–10 RFC 9917
Базовая модель Flex-Algorithm, выбор FAD и прежние правила RFC 9350
Предшествующие ограничения и расширения метрик RFC 9843
Кодирование Extended Administrative Group RFC 7308
Детали IS-IS и OSPF, длины и дублирования RFC 9917, разделы 5–12

Путь решения о приёмке

  1. Владелец данных: зафиксировать источник входных ошибок и владельца телеметрии; не предполагать автоматическое обнаружение.
  2. Пороги: определить и отдельно проверить set и clear, включая гистерезис и последствия задержки.
  3. Кодирование: проверить RFC 7308, длины, значения и дубликаты для IS-IS и OSPF.
  4. Политика: подтвердить выигравший FAD, смысл exclude/include-any/include-all и неизменность порядка правил.
  5. Поддержка и сходимость: проверить смешанные возможности, flooding, пересчёты, время сходимости и наблюдаемость.
  6. Решение: включать только при воспроизводимой end-to-end доказательной цепочке; при расхождении выполнить rollback и сохранить причину.