Кратко

  • Редакция 10 проекта OPSAWG о планировании тестов OAM говорит, что последующая правка шаблона отдельного теста не должна незаметно менять уже настроенную последовательность. Модель последовательности теперь включает список самих тестов вместо прежнего списка ссылок; переименованы и некоторые элементы YANG.
  • Текст сохраняет требование контроля очередности пользователем и признаёт, что перестановка влияет на отчёт. Но в новом списке unitary-test больше нет инструкции ordered-by user, присутствовавшей в редакции 09. По RFC 7950 список без неё по умолчанию упорядочивает система. Это расхождение внутри обсуждаемого проекта, а не доказанный сбой действующей сети.

Диагностическая программа может сначала проверить доступность узла, затем измерить задержку и после этого проследить маршрут. Список результатов без порядка выполнения не описывает весь метод исследования. Документ draft-ietf-opsawg-scheduling-oam-tests предлагает две модели YANG, с помощью которых внешние системы управления и оркестрации планировали бы одиночные проверки OAM и их последовательности. Документ остаётся Internet-Draft рабочей группы с предполагаемым статусом Proposed Standard; опубликованной RFC и подтверждением внедрения он не является.

Редакция 10 добавляет важное различие между многоразовым шаблоном и зафиксированным планом. В разделе 4.2 сказано: изменение шаблона одиночного теста впоследствии не должно скрытно переписывать ранее настроенную цепочку. В самой модели вместо test-ref появляется список unitary-test, использующий состав одиночного теста. Такая граница необходима при сравнении двух запусков: иначе можно принять разные процедуры за одинаковые. Но из текста нельзя вывести, что какое-либо программное обеспечение уже хранит версии планов и связывает с ними отчёты.

С контролем порядка возникает отдельная проблема. Пояснения редакции 10 утверждают, что именно пользователь отвечает за расположение тестов, поскольку от него зависит выдача. Они прямо требуют указать ordered-by user. В редакции 09 такая инструкция была в списке ссылок, а в пришедшем ему на смену списке её нет. Описание нового списка допускает и пользовательский, и системный порядок, не выбирая формальную семантику. RFC 7950 задаёт её при отсутствии инструкции: применяется системная сортировка. Обещание в абзаце не меняет правило языка моделирования.

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

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

Источники