Кратко

  • Редакция 07 предлагает две YANG-модели: для единичного OAM-теста и для последовательности, порядок которой задаёт пользователь, с периодом, повторением, состояниями и подключёнными моделями устройств.
  • success в оркестраторе не доказывает, какая версия и когда была выполнена, все ли шаги состоялись, сопоставимы ли пробный и рабочий трафик, найдена ли единственная причина, разрешено ли изменение и восстановилась ли услуга.

Расписание организует поиск, но не выносит заключение

Сетевая диагностика редко состоит из одного действия. Проверяют связность, трассируют путь, измеряют потери и задержку, сужают подозреваемый участок и повторяют наблюдение в нужное время. draft-ietf-opsawg-scheduling-oam-tests-07 пытается представить этот процесс общей структурой. ietf-oam-unitary-test описывает тест и целевые узлы, а ietf-oam-test-sequence собирает тесты в заданном пользователем порядке и добавляет период или повторение.

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

Datatracker показывает, что редакция 07 остаётся активным Working Group Internet-Draft группы OPSAWG с предполагаемым статусом Standards Track. Номера RFC нет, обработка IESG не начата. История фиксирует ранние рецензии OPSDIR и PERFMETRDIR с итогом Has Issues; рецензия YANG Doctors не завершена. Документ не подтверждает реализацию, внедрение или соответствие.

Подтверждение 1: точный план

Проект заимствует у RFC 9922 состояние расписания, версию, местное время, последнюю и следующую реализацию и счётчики. Единичный тест может указывать несколько ne-config и подключать модель OAM устройства под root.

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

Подтверждение 2: применение, а не только приём

Редакция 07 задаёт planned, configured, ready, on-going, stop, error и success; последовательность добавляет failure. Это представление конкретной реализации.

Принятая запись NETCONF или RESTCONF не подтверждает, что все устройства применили план. RFC 8342 различает running, intended, applied и operational. Желаемые данные могут не стать действующими. Нужна сверка intended и operational по каждому узлу с сохранением возможностей, схемы и частичных отказов.

Ранняя рецензия OPSDIR отмечает ещё одну границу: текст говорит о запуске по требованию, но не определяет нормативные RPC/action. Операции нижележащих моделей нельзя приписывать этому проекту.

Подтверждение 3: конкретная реализация расписания

Повторение — правило, а не идентификатор запуска. Задержка очереди, перезапуск, повторная попытка, наложение окон, переключение контроллера и коррекция часов могут сделать last-occurrence и счётчик неоднозначными.

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

Подтверждение 4: полнота шагов

Список имеет ordered-by user. Ошибка одного теста не обязана останавливать следующие. Это позволяет собрать остаточные данные, но отличает окончание обхода списка от полноты диагностики.

Ранняя рецензия PERFMETRDIR спрашивает, почему stop приводит к успеху у единичного теста и к отказу у последовательности. OPSDIR требует ясности в error/failure, уведомлениях, корреляции, согласованности и откате на нескольких узлах. Подтверждение перечисляет все обязательные шаги, зависимости, узлы, времена, результаты, пропуски и решения продолжить, а также гипотезы, которые нельзя исключить из-за пробела.

Подтверждение 5: смысл измерения

Проект расписания не задаёт подробные входы и результаты OAM, а использует модели устройств, например TWAMP-модель из RFC 8913. RFC 8528 позволяет подключить одну модель под другую, но не предполагает источник экземпляров данных и может оставлять создание mount point за пределами спецификации.

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

RFC 7799 различает активные, пассивные и гибридные измерения. Сгенерированные пробные пакеты и рабочий трафик по умолчанию относятся к разным наблюдаемым совокупностям.

Подтверждение 6: сопоставимость с пострадавшей услугой

RFC 10014 отделяет топологическое совпадение пути от одинаковой обработки пересылки. Проба может пройти те же узлы и каналы, но попасть в другую очередь, получить иной QoS, выбрать другую ветвь ECMP или не испытать policer и нагрузку клиента.

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

Подтверждение 7: причинная гипотеза и полномочие

Проект осторожно говорит о candidate root cause. RFC 9940 различает event, fault, problem, symptom, cause, alert, alarm и incident; вывод о причине может опираться на несколько входов. RFC 8632 называет возможные корневые ресурсы подсказками для клиентского приложения.

Диагностическая запись должна сохранять наблюдения, конкурирующие объяснения, исключённые гипотезы, уверенность, границы и условие опровержения. Затем отдельно проверяется право изменить сеть. Разрешение создавать тесты не даёт права менять маршрутизацию или QoS. RFC 8341 выделяет контроль доступа; изменение требует владельца, политики, точного содержания, радиуса воздействия, окна и отката.

Подтверждение 8: услуга после изменения

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

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

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