Кратко

  • RFC 9833–9836 отдельно моделируют несущую линию, клиентский сервис AC, сетевой AC провайдера и ссылки, связывающие эти объекты с L2- или L3-VPN.
  • Проверенный и одобренный запрос может оставаться в awaiting-processing. Имена сервисного и сетевого AC тоже могут различаться: приём заказа и совпадение строк не доказывают реализацию.
  • Цепочка доказательств продолжается через сопоставление, выбор PE/SAP, привязку VPN, предполагаемую и применённую конфигурацию, рабочее состояние, OAM и трафик.

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

Сам по себе этот разрыв не доказывает сбой или обман. Его намеренно сохраняют RFC 9833, RFC 9834, RFC 9835 и RFC 9836. Четыре документа Standards Track, опубликованные в сентябре 2025 года, распределяют заказ и реализацию между связанными YANG-моделями. Статус одного уровня не должен без доказательств становиться фактом другого.

Страницы RFC 9833, RFC 9834, RFC 9835 и RFC 9836 подтверждают консенсус IETF и одобрение IESG. Они не подтверждают внедрение у конкретного оператора, настройку устройства или передачу пакета. Стандарт и работающая услуга — разные квитанции.

Несущая линия не равна AC

Bearer — нижележащая проводная или беспроводная линия. Attachment circuit — созданная поверх неё схема обмена между окончанием клиента и сетью провайдера. Один bearer способен нести несколько AC; один AC может быть связан с несколькими клиентскими окончаниями или peer-SAP; одно окончание может завершать несколько AC.

Поэтому доступность bearer не доказывает активность нужного клиентского AC. Закрытие одной услуги не даёт права удалить общий ресурс или соседние услуги. Один зелёный индикатор стирает именно ту множественность, которая ограничивает область автоматического действия.

RFC 9834 позволяет провайдеру выдать bearer reference, который клиент получает и использует в дальнейшем запросе AC. Провайдер вправе принять или отклонить клиентский идентификатор. Идентификатор AC уникален лишь в домене провайдера; его доказательная сила зависит от издателя, области и текущего объекта разрешения.

Клиентская модель не описывает внутреннюю сборку

RFC 8309 определяет клиентскую сервисную модель как описание заказанной или воспринимаемой услуги, а не способа её инженерной реализации. RFC 9834 скрывает от клиента PE, SAP, интерфейс, топологию и технологию.

Так общий запрос переносится между разными внутренними сетями. Но клиентский объект не может доказывать размещение, которое модель намеренно не показывает. Его квитанция ограничена личностью и полномочиями заказчика, ссылкой на bearer или peer-SAP, ID сервисного AC, параметрами, проверкой и административным состоянием.

RFC 9833 вводит awaiting-validation, awaiting-processing, admin-prohibited и rejected. Запрос может быть одобрен и проверен, но ожидать действий до активации. Интерфейс, превращающий awaiting-processing в «активно», добавляет несуществующий результат.

Сети требуется собственная идентичность

RFC 9835 определяет ietf-ac-ntw. Эта модель сопоставляет сервисную ссылку с фактическим сетевым AC и хранит размещение PE/SAP. Здесь переносимое намерение начинает связываться с конкретным ресурсом оператора.

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

Наличие сетевой записи также не подтверждает применение. RFC 8969 разделяет сервисные, сетевые и аппаратные модели и требует поднимать рабочее состояние и статистику вверх. Модель сети выражает намерение оркестратора; нижний уровень должен ответить, что выполнено.

Glue фиксирует связь, а не результат

RFC 9836 добавляет ietf-ac-glue, чтобы VPN-модели ссылались на правильные идентичности AC. Он дополняет сервисную модель L3VPN из RFC 8299, сервисную модель L2VPN из RFC 8466 и сетевую модель L3VPN из RFC 9181. RFC 8345 и RFC 9543 дают смежный контекст топологии и контроля услуги.

Ссылка glue доказывает моделируемую ассоциацию VPN и AC. Она не доказывает выделение ресурсов, применение на устройствах, достижимость, пересылку или SLA. Сервисный AC может указывать на сетевой AC A, а VPN — на B. Все объекты существуют, все ID синтаксически верны, но граф неверен.

Предполагаемое, применённое и наблюдаемое

RFC 8342 различает настроенные значения, предполагаемую конфигурацию и рабочее состояние. Задержка, оборудование, протоколы и другие системы могут разделить <intended> и <operational>. Только их сравнение показывает, какая часть намерения используется.

Полная цепочка аутентифицирует и авторизует субъект, разрешает bearer, принимает сервисный AC, сопоставляет его сетевому AC, выбирает PE/SAP/интерфейс, привязывает правильный VPN, создаёт предполагаемую конфигурацию, наблюдает применение и состояние, а затем отдельно измеряет OAM, достижимость, трафик и результат услуги.

RFC 7950 задаёт YANG, не навязывая единую внутреннюю архитектуру. RFC 9408 предоставляет рамку безопасности YANG-модулей. Эти материалы не доказывают конкретную атаку; они показывают, почему право записи должно относиться к правильному объекту и уровню.

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

Источники