Кратко

  • В примере рабочего проекта SPRING путь CP1 несёт 200 Мбит/с по двум спискам сегментов с предполагаемой ёмкостью 100 Мбит/с каждый. После отказа одного списка рекомендованное правило RFC 9256 может оставить CP1 «действительным», хотя предполагаемая ёмкость оставшегося списка вдвое меньше нагрузки.
  • Проект предлагает минимум действительных списков и минимум суммы их весов. Эти пороги позволяют исключить CP1 раньше, но их связь с реальной ёмкостью и спросом обязан поддерживать оператор.

Табло говорит «работает». Арифметика возражает

На входе 200 Мбит/с. Два равновесных списка сегментов принимают по 100 Мбит/с — именно так устроен пример в проекте рабочей группы SPRING. Их веса равны единице, нагрузка делится хешированием потоков поровну. Если один список становится недействительным, второй остаётся. Предполагаемая максимальная ёмкость второго — 100 Мбит/с. Однако кандидатный путь CP1 может сохранить активное состояние: RFC 9256 рекомендует считать путь действительным при наличии хотя бы одного действительного списка.

Правило отвечает на точный вопрос: остался ли маршрутный компонент? Сервису нужен ответ на другой вопрос: выдержит ли сохранившийся компонент назначенную нагрузку? Общее слово «действителен» позволяет панели управления показать зелёный индикатор там, где расчёт пропускной способности уже красный. Сеть может следовать RFC буквально, а оператор всё равно принять неверное решение о нагрузке.

В SR Policy POL1 есть CP1 и CP2. Первый выбран потому, что он действителен и имеет более высокий приоритет. RFC 9256 признаёт явный кандидатный путь недействительным, когда у него не осталось ни одного действительного списка. Потеря одного из двух списков не обязательно отодвигает CP1 в пользу CP2. В проекте не указана пропускная способность CP2 и не показан результат реальной передачи после возможного переключения. Поэтому запасной путь нельзя назначить героем истории без собственных данных.

Сколько живых списков достаточно?

Авторы предлагают два управляющих параметра. Восьмибитный Minimum Valid Segment List Count задаёт минимальное число действительных списков. Для CP1 из примера значение 2 означает потерю действительности после отказа любого списка. Ноль снимает дополнительное требование, а 0xff требует работоспособности всех списков. Второй параметр — 32-битный Minimum Cumulative SL Weight — задаёт нижнюю границу суммы весов действительных списков. При весах 1 и 1 порог 2 также исключит CP1: после отказа сумма составит 1. Ноль снимает требование по весу, 0xffffffff требует всех списков. Если заданы оба порога, должны выполняться оба; два нуля возвращают механизм RFC 9256.

Подсчёт списков удобен для проверки, но не различает их ширину. Два списка могут отличаться по ёмкости в несколько раз. Вес допускает более тонкую настройку, однако он отражает относительное распределение трафика, а не измеряет Мбит/с. В примере единица веса связана с 100 Мбит/с только потому, что таково исходное предположение авторов. Если физическая ёмкость поменялась, а вес остался прежним, сумма 2 будет верной записью устаревшего проекта сети. Порог защищает лишь ту модель ёмкости, которую оператор действительно обновляет.

Головной узел, по проекту, может получать параметры из конфигурации, PCEP или BGP. Подробные расширения протоколов должны появиться в другом документе; этот проект не просит IANA о назначениях. Единой цифры для всех сетей здесь нет. Решение принимает оператор: какой объём трафика закреплён за CP1, какую потерю он может пережить и в какой системе хранится ответственное значение порога. Между числом в контроллере и числом на головном узле нужен проверяемый след. Иначе новая настройка увеличит число полей, не увеличив доверия к решению.

Слои отказа нельзя складывать в один

Список сегментов может стать недействительным по правилам разрешения или проверки RFC 9256. Кандидатный путь может оставаться действительным благодаря другому списку. Вся SR Policy недействительна лишь тогда, когда недействительны все её кандидатные пути. Изменение действительности пути требует повторного выбора; выигрывает действительный кандидат с наивысшим приоритетом. Предлагаемые пороги действуют на среднем уровне, где CP1 ещё имеет список, но может уже не подходить для назначенной нагрузки.

Это раньше, чем состояние, для которого RFC 9256 описывает необязательное Drop-Upon-Invalid. Там речь идёт о недействительной политике целиком. Здесь цель — не ждать полного исчезновения маршрута, чтобы пересмотреть активный кандидат. Если CP1 исключён, выбор может перейти к CP2. Его способность выдержать 200 Мбит/с проект не подтверждает. Раннее обнаружение нехватки и безопасный резерв — две разные задачи.

Проект не содержит производственного журнала, измерения перегрузки или истории настроек на действующей сети. О фактическом эффекте можно будет судить по записи, которая свяжет пороги, ёмкость списков, наблюдаемую нагрузку и итоговый выбор. Сейчас источник показывает разрыв между узким критерием действительности и предположением о ёмкости.

Число должно иметь хозяина

При потере списка полезная запись покажет нагрузку CP1, состояние каждого списка, их оставшееся число и сумму весов, применённые минимумы и источник этих минимумов. Контроллер с порогом 2 и головной узел с порогом 0 живут в разных режимах риска. Изменение ёмкости должно вести к пересмотру весов и порогов с отметкой времени. Лишь тогда оператор сможет объяснить, какой именно факт подтверждал зелёный индикатор в момент отказа.

Источники