Кратко

  • RFC 5330 объявляет число TE LSP с сигнализированной полосой, равной нулю. Использовать его для распределения по равностоимостным путям можно лишь на основе статистического предположения; алгоритм, веса и критерий успеха остаются за пределами RFC.
  • Счётчик зависит от политики включения: LSP, созданные системой управления, разрешено не учитывать. Отсутствие sub-TLV означает отсутствие информации, а не ноль. Нагрузка и результат требуют отдельных наблюдений.

Красивое равенство перед первым измерением

Представим два пути одинаковой стоимости. Каждый объявляет значение 40. Контроллер заключает, что население распределено поровну, и оставляет маршруты без изменений. Независимые счётчики затем показывают: по одному пути прошло в семь раз больше байтов.

RFC 5330 не опровергнут. Он никогда не утверждал, что один LSP равен другому по трафику. Документ объясняет, что при статистических предположениях о совокупной нагрузке число unconstrained TE LSP может помогать распределять существующие или новые пути. Спецификация алгоритмов прямо оставлена за пределами документа.

Ошибка возникла там, где локальная гипотеза была представлена как свойство протокола. Число 40 — наблюдаемый вход. «Ожидаем равную нагрузку» — модель. «Нагрузка стала равной» — результат, который надо измерить.

Три утверждения не должны храниться в одном поле.

Ноль относится к запросу полосы

Unconstrained TE LSP в RFC 5330 — это TE LSP, сигнализированный с bandwidth, равной нулю. Нулевое значение не измеряет фактические пакеты и байты.

Мотивационная схема использует полную сетку таких LSP вместе с MPLS TE Fast Reroute. При совпадении TE- и IGP-метрик трафик может идти по кратчайшему IGP-пути и всё равно иметь локальную защиту.

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

Для сравнения нагрузки нужны источник счётчиков, временное окно, байты, пакеты, скорость и способ привязки к LSP. Число LSP может быть признаком, но не заменой этих данных.

У алгоритма есть автор, версия и допуски

Когда reservable bandwidth не помогает различить пути для запросов с нулевой полосой, число LSP выглядит удобным tie-breaker. Однако конкретный выбор остаётся локальным.

Один алгоритм может минимизировать число LSP. Другой может сочетать его с байтовой скоростью, задержкой, SRLG и историческим спросом. Третий может применять гистерезис, чтобы не перестраивать пути из-за малых колебаний.

Decision receipt должен назвать версию TE-базы, значения и их возраст, population contract, дополнительные метрики, кандидатов, алгоритм и версию, выбранное действие, окно проверки и измеренный результат.

Если решение нельзя воспроизвести, ссылка на RFC не добавляет ему доказательности. RFC стандартизирует поле, а не ответственность за модель.

Население счётчика выбирается локально

RFC 5330 разрешает не включать в объявленное число unconstrained TE LSP, которые настроены и provisioned системой управления.

Два пути со значением 40 могут иметь разное фактическое население. Один originator считает все LSP; другой исключает 25 контроллерных. Даже внутри одного домена обновление ПО может изменить правило без создания или удаления путей.

Поэтому каждому значению нужен population contract: включённые источники provision, квалифицирующие состояния сигнализации, обработка make-before-break, момент входа и выхода, правило для management LSP, версия конфигурации и время активации.

Равные целые числа сравнимы только после сравнения контрактов. Иначе алгоритм оптимизирует различия в учёте.

Отсутствие нельзя поставить на лёгкую чашу весов

Sub-TLV является необязательным. RFC 5330 требует понимать его отсутствие как отсутствие информации о линке.

Если один путь объявляет 40, а на другом type 23 отсутствует, это не 40 против 0. Второе состояние неизвестно через данный механизм. Присвоение нуля делает наименее наблюдаемый путь самым привлекательным.

Модель должна различать присутствующий ноль, положительное значение, отсутствие, malformed, отсутствие поддержки и отсутствие наблюдения. Только первые два состояния содержат объявленное число.

Алгоритм может приостановить решение, применить явно помеченный fallback или использовать другой источник. Он не должен превращать пробел в факт ради полной матрицы.

Синтаксически удобный ноль может стать причиной реальной концентрации трафика.

При повторе действует первое значение

RFC 5330 присваивает type 23 счётчику для IS-IS и OSPF. В форме IS-IS значение занимает два октета, в OSPF — четыре внутри соответствующего Link TLV. Повторение в контейнере не допускается; если появляется второй экземпляр, получатель обрабатывает только первый.

При последовательности 40, затем 52 маршрутизатор использует 40. Декодер с last-write-wins может сохранить 52. Алгоритм тогда принимает решение на основе числа, которое protocol receiver отверг.

Parse receipt сохраняет протокол, контейнер, порядок, offsets, lengths, все значения, выбранный первый экземпляр и причину игнорирования остальных. Нормализованная строка не доказывает отсутствие дубля.

Реестр IANA подтверждает общее значение codepoint. Он не подтверждает полученную последовательность и не удостоверяет поведение конкретной реализации.

Частота объявлений — ещё один параметр модели

Число меняется при создании, перемещении и удалении LSP. Но RFC 5330 не определяет origination triggers и предупреждает против систематического flooding с чрезмерной гранулярностью при каждом изменении.

Один originator может публиковать по событию, другой по порогу, третий по таймеру. Две свежие LSA могут представлять разные временные срезы. Sequence и age характеризуют объект протокола, но не раскрывают ожидающие изменения населения.

Count receipt должен включать trigger policy, aggregation window, время последнего recompute и допустимый consumer staleness. Если известен churn, а значение стоит на месте, это причина проверить гранулярность, а не доказательство стабильности.

Алгоритм, сравнивающий пути, должен принимать значения одной совместимой временной эпохи. Иначе он сравнивает прошлое одного пути с настоящим другого.

Собственное действие алгоритма меняет следующий вход

Балансировщик, использующий RFC-5330-счётчик, перемещает или создаёт LSP. Тем самым он меняет население, которое будет объявлено в следующий раз.

Возникает контур управления. Если система не хранит причинность, она может принять последствия своего решения за независимое подтверждение модели. Например, после переноса пути числа сблизились; платформа объявляет успех, хотя байтовый дисбаланс сохранился или усилился.

Нужны intervention ID, время решения, набор изменённых LSP, ожидаемый эффект, защитное окно и независимые метрики результата. Следующее значение счётчика надо пометить как потенциально обусловленное собственным действием.

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

Число затронутых LSP не закрывает влияние

RFC 5330 также называет оценку количества LSP, затронутых отказом линка, возможным применением поля. Это число путей, а не услуг или клиентов.

Каждый LSP нужно связать с актуальным маршрутом, трафиком и сервисами. Защита требует собственных данных: запрос, метод, защищаемый hop, detour или bypass, readiness, общая ёмкость и последний тест.

Facility backup может защищать множество основных LSP одним ресурсом. Одинаковое число основных путей может зависеть от совершенно разной резервной архитектуры. Успешное переключение control plane не гарантирует допустимые потери, задержку и прикладной результат.

Счётчик помогает выбрать место расследования. Он не вычисляет бизнес-ущерб.

Успех определяется не формой входа

Для честной автоматизации надо разделить receipts. Wire receipt фиксирует origin, scope, link identity, ключ LSA/LSP, sequence, checksum, точку и время захвата. Parse receipt фиксирует упорядоченные экземпляры. Count receipt и population contract объясняют число и его границы.

LSP receipt подтверждает реальные пути и состояния. Traffic receipt измеряет нагрузку. Protection receipt подтверждает связи и готовность. Decision receipt воспроизводит алгоритм. Impact receipt закрывает наблюдаемый исход.

Такое разделение не ослабляет RFC 5330. Оно оставляет полю ту власть, для которой оно создано. Зарегистрированный символ координирует значение; объявление переносит утверждение originator; локальная политика формирует население; running code принимает решение; результат проверяется наблюдением.

Сорок и сорок — хороший повод задать вопрос. Ответом они становятся только после измерения.

Источники