Кратко

  • В проекте указано внедрение или отображение информационной модели как минимум на девяти аппаратных платформах четырёх производителей и открытая частичная реализация модели данных. Это подтверждает практическую работу, но не одинаковое поведение каждого развёртывания.
  • Раздел о статусе реализации носит информационный характер, должен быть удалён перед публикацией RFC и прямо говорит, что IETF не проверял предоставленные участниками сведения. Продуктовая поддержка не является полномочием на автоматическую реакцию.

В тендерной таблице появилась удобная отметка: «поддерживает packet-discard model». После неё две разные платформы считались взаимозаменяемыми. На одной дерево причин доходило до подробного подтипа, на другой заканчивалось уровнем выше. Одна считала событие в аппаратном тракте, другая использовала программный прокси. Панель привела значения к одной схеме и объявила их сопоставимыми.

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

Проект Information and Data Models for Packet Discard Reporting не обещает такой взаимозаменяемости. Редакция 16 датирована 30 июля 2026 года и истекает 31 января 2027-го. На 2 октября документ OPSAWG был активным Internet-Draft, предназначенным для статуса Proposed Standard, переданным в IESG и находившимся в очереди RFC Editor в ожидании назначения. Номера RFC ещё не было.

В разделе о реализации перечислены как минимум девять аппаратных платформ: семейства Broadcom, Cisco, Juniper и Marvell. Также приведён открытый SLAX-скрипт, реализующий часть модели данных для Juniper MX. Это сильнее чистой схемы на бумаге: авторы получили практический опыт и внесли наблюдения в эксплуатационный раздел.

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

Соответствие имеет измерения

Слово «поддержка» скрывает множество вопросов. Какая редакция модели реализована? Какова максимальная глубина дерева? Какие интерфейсы, плоскости управления и логические элементы охвачены? Есть ли отдельные счётчики для транзитного ACL и защиты control plane? Отличается ли null-route от no-route? Как отмечаются разрывы счётчиков? Прямое это измерение или прокси?

Минимальная реализация может поддерживать только первые шесть уровней семиуровневой классификации. Это допустимо, но важно для сравнения. Отсутствующий дочерний узел не равен нулевому значению. Платформа, показывающая более глубокую причину, не обязательно теряет больше пакетов; она может лишь честнее разделять их.

Семантика старых счётчиков тоже различалась между поставщиками. Именно это стало одной из причин нового проекта. Нельзя объявить проблему решённой одним названием модели, не проверив, как аппаратный и программный тракт привязаны к её классам.

Стандартный язык не заменяет приёмочные испытания

Организация должна заморозить профиль соответствия для каждого типа устройства: версия, поддерживаемые пути, точки измерения, ограничения, reset-семантика, производительность экспорта и известные прокси. Этот профиль — не маркетинговая декларация, а исполняемый контракт приёмки.

Тесты должны создавать наблюдаемые состояния: ошибка L2, TTL expiry, no-route, null-route, no-buffer, ACL, policer, reset и разрыв потока. Нужно проверять не только появление счётчика, но и отсутствие двойного учёта, направление, область, время и связь с потоком.

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

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

Minimum Initial Specification должна хранить профиль возможностей рядом с данными. Running-Code Primacy требует повторять тесты после обновления ПО, смены ASIC, включения новой функции и изменения экспортного пути. Совместимость — состояние, которое измеряют, а не титул, который присваивают навсегда.

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

Источники