Кратко

  • RFC 9502 даёт контролируемый способ объявить префикс в контексте Flexible Algorithm; она не превращает объявление в свидетельство фактической доставки.
  • Для критичного изменения нужны отдельные следы: FAD, участие по IPv4/IPv6, локальный расчёт, FIB и измерение трафика или сервиса.

Слова «маршрут под алгоритмом 128 активен» выглядят как технический вывод. На деле в них отсутствует предмет. Активно ли определение? Участвует ли конкретный маршрутизатор в IPv4? Появилась ли запись в его FIB? Или кто-то наблюдал успешный поток клиента? Каждая версия вопроса требует другой записи, другого владельца и другого временного окна. Одна и та же фраза не может честно служить доказательством для всех.

RFC 9502 полезна тем, что сохраняет эти различия. Она расширяет IGP Flexible Algorithms на IPv4- и IPv6-prefix reachability. Префикс становится входом для расчёта, связанного с условиями алгоритма. Он не становится приказом немедленно пересылать пакеты и не становится квитанцией об их прибытии. Сначала система должна решить, кто имеет право участвовать, затем — какой путь допустим, и лишь потом — что установить локально.

Начало этой цепочки — Flexible Algorithm Definition, FAD. По RFC 9350 узлы должны согласиться с определением; узел, который не может его поддержать, проверить или принять, прекращает участие в соответствующем алгоритме. Номер в реестре или в конфигурации поэтому не равен единому состоянию сети. Он ничего не говорит о том, какую версию ограничений принял каждый узел и какие узлы исключены. Для управления изменением это означает: хранить нужно не только номер, но и версию FAD, параметры, владельца, согласие и отказ.

Далее важна независимость плоскостей. Участие задаётся для каждого IP data plane. IPv4 может участвовать, когда IPv6 нет; возможности и локальная политика могут различаться. Формула «вся сеть переведена на Flex-Algorithm» способна скрыть именно ту асимметрию, которая превратит изменение в инцидент. В отчёте должна быть матрица «узел — IPv4 — IPv6 — состояние», а не одна отметка возле имени алгоритма.

После участия не исчезает сам расчёт. На результат влияют топология, метрики, ограничения, свойства линков, исключения и локальная политика. Видимый префикс не обязательно достижим в рамках алгоритма; достижимый не обязательно выбран; выбранный не обязательно установлен. RFC 9502 предписывает исключать неучаствующие узлы из расчёта. Неучастие — не пустая ячейка телеметрии, а часть того, почему путь получился или не получился.

Особенно показателен отрицательный результат. При конфликтующей информации об одном и том же префиксе под разными алгоритмами RFC 9502 требует проигнорировать её и не устанавливать соответствующий маршрут. Отсутствие записи в FIB может быть корректным защитным действием, а не недостатком мониторинга. Если после изменения команда заменяет такой факт скриншотом желаемой конфигурации, она превращает свидетельство осторожности протокола в неподтверждённое сообщение об успехе.

FIB — следующий, более сильный, но всё ещё локальный факт. Она показывает, что конкретный маршрутизатор принял решение о пересылке. RFC 9502 при этом ограничивает одну IP-плоскость одним маршрутом алгоритма для того же префикса. Несколько алгоритмов на архитектурной схеме не означают несколько одновременно используемых производственных путей. Убедительное утверждение должно назвать узел, таблицу, префикс, next hop и время.

Проверка трафика приходит после FIB, а не вместо неё. Счётчик, потоковая запись или синтетический тест покажут нечто о движении данных в установленной точке и окне. Но и они не заменяют метрику пользовательского опыта. Утверждение о доступности приложения требует своей SLO- или клиентской телеметрии. Это разграничение освобождает сетевую команду от обязанности обещать то, чего её приборы не наблюдают, и не позволяет бизнесу выдать конфигурацию за результат.

На практике достаточно пяти коротких журналов. Первый: FAD — идентификатор, ограничения, версия, согласие. Второй: участие — каждый узел отдельно по IPv4 и IPv6. Третий: расчёт — префикс, момент, подходящий путь и причина исключения. Четвёртый: FIB — конкретная локальная установка. Пятый: наблюдение — инструмент, период и результат. Для сервисного обещания добавляется шестой, независимый журнал SLO. Журнал на следующем уровне не должен заполняться выводом из предыдущего.

Это согласуется с мыслью Heng Lu в заметке о минимальной начальной спецификации: механизм, который локализует будущее решение, не принимает его вместо участников. FAD задаёт рамку для расчёта, но не принимает определение за каждый узел и не устанавливает запись в каждой FIB. Локальность здесь не дефект, который следует скрыть для руководства; это граница ответственности, которую руководству следует видеть.

Рассуждение о running code даёт схожее предостережение. Работающий код — существенное доказательство в своей области, но не разрешение заявлять о ненаблюдаемых последствиях. FIB подтверждает локальное решение, не подтверждает качество приложения за пределами домена. Масштаб доказательства должен соответствовать масштабу обещания.

Реестр IANA IGP Parameters публикует пространство идентификаторов, включая диапазон 128–255 для Flexible Algorithms. Он координирует имена, а не состояние устройств. Реестр не знает, была ли принята FAD, участвует ли IPv6 и прошли ли пакеты. Подменять наблюдение номером из публичного реестра — значит путать институт именования с операционной истиной.

Наконец, RFC 8174 дисциплинирует чтение нормативных слов. Требование MUST NOT install объясняет, почему безопасным исходом может быть неустановка. Оно не разрешает придумать положительный результат, который никто не измерил. Для руководства это не тонкость языка: это способ не принимать необратимое решение на основе фразы, чей объект неизвестен.

Хороший разбор изменения поэтому начинается не с вопроса «всё ли зелёное?», а с вопроса «какой слой сейчас доказывается?». Такой порядок делает автоматизацию проверяемой, а не медленнее. Алгоритм может быть объявлен. Маршрут всё равно должен быть рассчитан, установлен и наблюдён.