Кратко

  • 13 августа 2026 года IESG одобрила draft-ietf-opsawg-discardmodel-16 как Proposed Standard. Информационная модель и модель данных YANG дают операторам более единообразный способ сообщать о сбросах пакетов на интерфейсах, на уровне устройства и в плоскости управления.
  • Документ прямо говорит: одной классификации недостаточно, чтобы признать сброс намеренным или случайным. Счётчик фиксирует локальное наблюдение устройства; смысл определяют намерение оператора, конфигурация, базовый уровень, длительность, контекст сервиса, порядок реализации и соседние доказательства.

Один класс может требовать противоположных решений

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

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

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

Одобрение создаёт общий язык наблюдения

13 августа 2026 года IESG одобрила версию 16 документа “Information and Data Models for Packet Discard Reporting” для публикации в качестве Proposed Standard. До публикации RFC Editor текст остаётся Internet-Draft. Его подготовила Operations and Management Area Working Group.

В объявлении описаны независимая от реализации информационная модель и модель данных YANG для сбросов на интерфейсах, на устройстве и в плоскости управления. В отчёте shepherd указаны сопоставления или реализации на девяти аппаратных платформах четырёх поставщиков, а также открытая реализация части модели YANG. Это существенное свидетельство работающего кода. Но оно не доказывает повсеместное внедрение, одинаковый учёт в разных микросхемах или поддержку в какой-либо названной рабочей сети.

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

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

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

Устройство сброса владеет лишь узким фактом

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

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

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

Поэтому счётчик подтверждает узкое утверждение: «это устройство окончательно сбросило пакет в данном классе». Сам по себе он не подтверждает, что устройство вызвало отказ сервиса, что именно здесь появилась первая неисправность или что выбранное исправление безопасно.

Единственный учёт не означает единственную причину

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

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

Если применимы несколько причин, их приоритет должен быть описан без двусмысленности. Реализации следует раскрывать discard-order-capability от высшего приоритета к низшему либо документировать иной механизм. Поэтому две платформы могут увидеть один пакет и выбрать разные классы, если их конвейеры применяют причины в разном порядке, при этом обе следуют заявленному приоритету.

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

Значение счётчика принадлежит своей эпохе

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

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

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

Необходимо различать три состояния: модель определяет счётчик; устройство объявляет соответствующую функцию; реализация заполняет счётчик в текущей эпохе. Отсутствие в третьем состоянии не равно нулю. Ноль не доказывает, что затронутых пакетов не было за пределами области наблюдения.

Намерение остаётся у оператора

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

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

Потери из-за нехватки буфера тоже зависят от контекста. Небольшие потери best-effort ниже согласованного порога могут быть приемлемым следствием нагрузки. Устойчивые потери выше порога требуют добавления ёмкости или перемещения трафика. У Lower Effort может быть другая базовая линия. Одна ветвь перегрузки не переносит договор сервиса внутрь устройства.

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

Автоматизации нужно соединение доказательств

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

Безопасное решение соединяет несколько записей. Сначала фиксируются идентичность устройства, программное обеспечение и конвейер пересылки. Далее — точные компонент, интерфейс, направление, уровень, класс и подтип; объявление функции; признак заполнения; приоритет; значение, время, разрыв и базовый уровень. Затем добавляются конфигурация или политика, способная дать результат, её владелец и утверждённое намерение, а также сведения о маршрутах, соседстве, очередях, оборудовании, потоках и пакетах до и после точки наблюдения.

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

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

Источники