Кратко

  • AltMark SRH TLV из RFC 9947 описывает ограниченное наблюдение внутри контролируемого SRv6-домена. Он не удостоверяет публичное развёртывание, полный путь, опыт клиента или достижение сервисной цели.
  • L, D, FlowMonID, время и последовательность поддерживают измерительный вывод только после сверки входа в домен, функций SID, привязки идентификаторов, периодов, часов и точек сбора.
  • Важен не вопрос «появилась ли метка?», а кто задал какой охват, какие конечные точки реально её обработали и какое независимое доказательство сервиса поддерживает вывод.

Перенос поля не переносит бремя доказательства

Alternate Marking разделяет последовательные партии пакетов, чтобы наблюдать потери, задержку и джиттер в живом трафике. RFC 9341 описывает метод, RFC 9343 — представление в IPv6 option headers, а RFC 9947 переносит данные в экспериментальный TLV SRH. Предпосылка понятна: SR-узлы предполагается быстро обрабатывают SRH, тогда как некоторые реализации могут не обрабатывать Destination Options, несколько extension headers или отправлять их на медленный путь.

Но это не готовый результат производительности. RFC прямо просит сравнить выживаемость пакетов, стоимость обработки и эффект на forwarding plane. Опубликованный формат — не инвентарь возможностей конкретного маршрутизатора, ASIC, политики, поставщика или клиентского пути. Первичен исполнявшийся маршрут, а не возможность, описанная документом.

Контролируемый домен ограничивает эксперимент, а не делает его глобальным

RFC 9947 требует контролируемый SR-домен, согласованное значение из экспериментального диапазона TLV и запрет на вход и выход пакетов с AltMark. В документе нет действий IANA. Локальная координация поэтому может быть строгой, но не превращается в глобальное выделение, доказательство внедрения в Интернете или согласие внешних сетей.

Граница нужна и для безопасности: оператор выбирает узлы, контролирует доступ и должен предотвращать инъекцию или утечку помеченных пакетов. Но доверенный домен не делает автоматически доверенным вывод. Он не показывает, что все ожидаемые функции SID включены, что список сегментов не изменился, что 20-битный идентификатор не столкнулся с другим, или что путь в 10:00 остался путём клиента в 15:00. До графика нужен журнал измерения: владелец домена, значение TLV, границы, версия SR policy, ожидаемый список сегментов, функции SID, правило выбора потока, период, коллектор и явно перечисленные недоказанные вещи.

FlowMonID связывает кандидатов, но не создаёт уникальную личность

Базовый TLV содержит 20-битный FlowMonID, а также L и D. Он нужен потому, что IPv6 Flow Label нельзя использовать для идентификации наблюдаемого потока. Это не идентичность клиента, не субъект полномочий и не глобальный первичный ключ. RFC предупреждает: значение, выбранное на входе домена, может столкнуться с другим даже при псевдослучайном выборе. Расширенные поля могут удлинить идентификатор и нести данные для различения, но уменьшают неоднозначность лишь при одинаковом назначении и толковании в домене.

Поэтому запись «поток 41718 потерял 0,02 %» недостаточна. Она может означать устойчивый поток в одном периоде, а может смешивать двух кандидатов, разные селекторы или разные версии policy. Нужны правило соответствия, атрибуты потока, версия policy, временной интервал и коллектор.

Функция SID решает, кто прочитает метку

Hop-by-Hop Option обрабатывается на каждом прыжке. Destination Option перед SRH и AltMark SRH TLV следуют за конечными точками сегментов, на которые последовательно указывает адрес назначения. Промежуточный или выходной SR-узел, не умеющий обработать TLV, может его проигнорировать; узел с SID без функции не обязан даже искать TLV. Частичное инструментирование полезно, но делает фразу «измерен весь путь» неверным сокращением. Наблюдение могло поступить только от совместимых конечных точек. Хопы между ними, изменённый список сегментов и проигнорированные поля остаются вне утверждения.

Бит M разделяет измерение сегмент за сегментом и end-to-end. Второе — заявленный охват в домене, а не доказательство пользовательского опыта за его пределами; первое — локальное наблюдение, а не гарантия завершения приложения через несколько доменов.

У времени, последовательности и сервиса отдельные цепочки доказательств

Расширенные данные могут нести timestamp, последовательность и управление обратным мониторингом. Узел может сравнить время пакета с локальными часами и вывести одностороннюю задержку. Это возможность, а не автоматически проверенное число. Отчёт о задержке должен хранить источник и эпоху часов, точки сравнения, обработку рассогласования, место захвата и расчёт. Это дисциплина доказательств, а не приписываемое RFC дополнительное требование.

Пропуск последовательности также не обязан быть потерей сети: он может возникнуть из-за выборки, потери захвата, изменения правила или сбоя коллектора. Бит F не даёт посчитать исходный фрагментированный пакет несколько раз, но не доказывает доставку всех фрагментов и реконструкцию содержимого приложением.

Эксперимент ставит вопросы, а не назначает победителя

RFC 9947 спрашивает, выживает ли SRH TLV лучше или хуже extension headers, помогает или мешает обработке, как влияет на пересылку и как его метаданные соотносятся с другой on-path telemetry. Он ожидает последующей оценки, а не даёт её. Честный опыт фиксирует версии ПО и SR policy, сравнивает два кодирования там, где безопасно, и сохраняет обработку на конечных точках, коллизии, потери коллектора, счётчики пересылки, неожиданное игнорирование и независимый service canary. «На этом пути не найдено измеримого преимущества» — полезный результат. «TLV существует» — нет.

Пять ступеней доказательства

  1. Декларация: настроены домен, экспериментальное значение, селектор, SR policy и SID-функции.
  2. Наблюдение пакета: вход реально добавил TLV, а ожидаемые точки увидели или обработали его в зафиксированный интервал.
  3. Измерительный вывод: идентификаторы, периоды, последовательность и часы сверены для ограниченного наблюдения.
  4. Связь с сервисом: независимая транзакция, синтетическая проба или canary приложения увидели релевантное поведение.
  5. Решение: ответственный оператор изменил, принял, эскалировал или откатил и сохранил причину.

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

Источники