Кратко

  • 22 сентября 2026 года рабочая группа MPLS передала draft-ietf-mpls-on-path-telemetry-flag-05 в IESG. Publication Requested — процедурный статус, а не одобрение IESG, публикация RFC, выделение IANA или доказательство внедрения.
  • Флаг P запрашивает открытку у узлов, понимающих MNA и имеющих включённый сбор данных. Он не задаёт универсальный набор данных и сам по себе не подтверждает экспорт с каждого перехода.
  • Для обоснованного вывода нужна квитанция от триггера до экспорта: область действия, политика маркировки, возможности и состояние узлов, версия шаблона, идентичность открыток, транспорт, потери, корреляция и отсутствующие переходы.

Механизм намеренно экономит место в пакете. Head-end добавляет к выбранному пакету sub-stack MPLS Network Actions. Один флаг P в записи Format D просит узлы на label-switched path создать открытки, а более богатые измерения передаются вне полосы.

Экономия места не отменяет обязанность доказывать результат. Бит означает запрос, а не запечатанный журнал всех ответов.

Publication Requested обозначает передачу работы

Datatracker датирует revision 05 21 сентября. На следующий день статус рабочей группы стал Submitted to IESG for Publication, а статус IESG — Publication Requested. Ответственным area director и action holder указан Jim Guichard.

Эти поля показывают, у кого следующее решение. Они не означают одобрение текста. Проект ещё не стал RFC, а таблица IANA Network Action Flags Without Ancillary Data на момент фиксации источников не содержала регистраций. Shepherd write-up запрашивает Proposed Standard, отмечает широкую поддержку, отсутствие возражений, две декларации IPR и отсутствие известных реализаций.

Opcode 1 в MNA Sub-Stack уже выделен в RFC 9994. PBT-M использует это действие и отдельно просит новый флаг внутри него. Наличие opcode не подтверждает выделение P.

За одним битом стоят локальные решения

Revision 05 помещает LSE Format D после action LSE. P действует hop-by-hop, не имеет ancillary-data LSE и использует U=0: узел, не понимающий действие, пропускает его. Даже поддерживающий узел создаёт открытку только при включённом сборе и экспортирует типы данных, выбранные локальной конфигурацией.

Head-end выбирает пакет для наблюдения, но не несёт полный договор измерения. Узел может не поддерживать PBT-M, поддерживать его в выключенном состоянии или применять другую версию шаблона. При достижении лимита экспорт может быть подавлен. Пользовательский пакет во всех случаях продолжает движение.

Проект требует маркировать лишь малую часть, никогда не все пакеты, и задаёт по умолчанию не более одного из 1 000 пакетов потока. Узел ограничивает генерацию средним значением 1 000 открыток в секунду и burst 2 000. Сверх лимита пакет пересылается без открытки, а превышение учитывается.

Успешная доставка и полнота наблюдения — разные результаты.

Открытка — локальное утверждение

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

Открытки могут прийти не по порядку или потеряться. Одного TTL иногда недостаточно при push и pop меток. Проект рассматривает вектор TTL по LSE, идентификатор узла, flow ID и timestamp. Если два одновременно летящих пакета могут разделить доступный ключ, корреляция неоднозначна и должна быть отброшена.

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

Квитанция от маркировки до экспорта

Поле Сохраняемое доказательство
Триггер P, входная точка, политика, версия sampler и частота
Область trust domain, ожидаемый LSP и временное окно
Готовность node ID, поддержка PBT-M, включение и версия
Семантика локальный template, версия и выбранные типы данных
Идентичность ключ packet/flow, последовательность и время экспорта
Доставка назначение, транспорт, отправлено, потеряно, подавлено
Реконструкция правило, порядок, отброшенные неоднозначности
Полнота ожидаемые и полученные узлы, пропуски и partial-path
Безопасность лимиты, исключения, превышения и граница доверия

Это не новый формат в сети, а эксплуатационная квитанция из данных control plane, экспортёров и коллектора. Она оставляет инструкцию малой и делает смысл результата воспроизводимым.

У целостности есть граница доверия

Флаг P изменяем и не аутентифицирован. На границе trust domain его следует очистить либо отбросить пакет. Внутри скомпрометированный или неверно настроенный узел может поставить или снять P. Rate limit ограничивает нагрузку, но не подтверждает целостность наблюдения.

В проекте также нет YANG-модели. Это не общий вердикт о качестве, а практическая граница: обнаружение возможностей, включение, идентичность шаблона, состояние экспорта и политика коллектора должны управляться явно.

Три LSE, то есть 12 байт, позволяют оставить фиксированную инструкцию в label stack, а богатые данные отправлять вне полосы. Точная формулировка такова: пакет несёт дешёвый триггер, сеть и коллектор — доказательство.

Источники

  1. IETF Datatracker: Postcard-Based Telemetry using MPLS Network Actions
  2. История документа
  3. Shepherd write-up рабочей группы
  4. Текст revision 05
  5. Реестр IANA MPLS Network Actions
  6. RFC 9994: MPLS Network Actions Framework