Кратко

  • RFC 9835 хранит в сетевом attachment circuit ссылку на AC, показанный в сервисном слое. Корреляция отвечает на вопрос, какой объект должен реализовать какой заказ, но не доказывает исправность bearer, маршрутизации или клиентского результата.
  • Имя сетевого AC уникально лишь в пределах узла. Наследование профиля, локальные переопределения, зависимости Parent/Child AC и административное и рабочее состояния требуют отдельных записей.
  • Доказательство доставки начинается после ссылки: правильная цель, вычисленная конфигурация, подтверждённая запись, наблюдаемое состояние, OAM в заявленной области, сервис end-to-end и фактический клиентский трафик.

Заказ закрыт, а филиал всё ещё изолирован

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

Однако bearer может оставаться недоступным, VLAN — не совпадать, профиль маршрутизации — оказаться устаревшим, а второй конец VPN — ещё не существовать. Ссылка доказывает, о каком объекте говорят системы. Она не доказывает, что объект дал нужный эффект.

RFC 9835, также зафиксированный в карточке RFC Editor, определяет модель ietf-ac-ntw. Она позволяет готовить AC до или во время создания сервиса и хранить в сетевом объекте ссылку, под которой этот AC показан клиенту. Стандарт создаёт аудируемый шов между намерением и исполнением, а не обещание одновременного завершения обоих процессов.

Bearer, AC и SAP — не три названия одного объекта

RFC 9833 называет bearer физическим или логическим соединением между клиентской точкой и сетью оператора. AC — конфигурация поверх этого соединения, необходимая для обмена данными. Один bearer может нести несколько AC; AC может быть связан с несколькими peer SAP; на SAP могут завершаться несколько AC.

Эта кратность меняет расследование. Авария bearer способна затронуть семейство каналов. Ошибка конфигурации одного AC совместима со здоровым bearer. Локально исправный SAP не описывает весь сервис. В журнале нужны отдельные идентификаторы bearer, AC, SAP и услуги, а не плоский circuit-id, скрывающий структуру.

RFC 9834 представляет bearer и AC как клиентские услуги. RFC 9835 описывает сетевую сторону. RFC 9836 связывает эти объекты с сервисными и сетевыми моделями L2VPN и L3VPN. Связь моделей не отменяет собственные решения, состояния и доказательства каждого слоя.

svc-ref — ключ сопоставления, а не печать успеха

RFC 9835 использует ссылку AC из сервисной модели, чтобы сопоставить запрос с AC, фактически заведённым в сети. При этом имя сетевого AC уникально в пределах узла, а не всей сети. Единое правило именования в сервисном и сетевом слоях зависит от конкретного развёртывания и стандартом не гарантируется.

На двух узлах вполне может существовать ac-17. При миграции стабильная клиентская ссылка может начать указывать на новый узел. Простое сравнение строк создаст ложное совпадение. Полезная квитанция фиксирует ссылку, сеть, узел, AC, SAP, субъекта, принявшего решение о соответствии, и эпоху его действия.

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

Эффективная конфигурация должна иметь происхождение

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

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

RFC 9836 также отдаёт данным указанного AC приоритет над пересекающимися inline-данными VPN access. Это правило полномочий: оно решает, какое намерение победит. Оно не подтверждает атомарное применение, одинаковую интерпретацию всеми устройствами или корректный откат.

RFC 8342 в NMDA отделяет намерение и конфигурацию от operational state. RFC 8345 задаёт сетевую модель, которую расширяет RFC 9835. Появление объекта в datastore не завершает проверку, а ставит три вопроса: что запросили, что стало эффективным и что теперь наблюдает сеть?

Удаление родителя расширяет масштаб решения

Parent AC может содержать общие свойства, а Child AC — детали отдельных peer SAP. Дочерние объекты наследуют свойства родителя. RFC 9835 требует при удалении Parent AC удалить все Child AC.

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

До удаления оператору нужна замороженная область воздействия: родитель, дети, SAP, сервисы, bearer, эффективные профили и наблюдаемое состояние. После удаления модель надо сверить с устройствами и трафиком. Исчезновение строки из datastore подтверждает мутацию модели, но не безопасное прекращение услуги.

Operational state должен иметь право опровергнуть admin state

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

Заказ может быть принят, но ждать активации. AC может быть сконфигурирован, но находиться down. Интерфейс может быть up с неверной VLAN. Исправный AC в одной точке не доказывает исправность VPN целиком.

RFC 9408 определяет SAP как точку отсчёта на стороне провайдера и отделяет наблюдаемое там состояние от состояния всей сетевой услуги. RFC 9181, RFC 9182 и RFC 9291 задают типы и модели VPN, а RFC 9543 расширяет контекст до network slices. Локальный индикатор не вправе говорить за все эти области.

Практическая лестница доказательств различает запрос; принятие и ссылку; отображение на сеть, узел, SAP и AC; разрешение наследования; запись в нужную цель; operational state; OAM с известной областью; состояние услуги end-to-end; клиентский трафик или прикладной canary. Это не обязательно девять баз данных. Смысл в том, что квитанция одной ступени не получает полномочия следующей по умолчанию.

Источники подтверждают устройство моделей и их границы. Они не подтверждают конкретное внедрение, соответствие продукта, инцидент, темпы распространения, срок восстановления, экономию или результат SLA. Предлагаемая лестница — эксплуатационная практика, а не новое требование IETF.

Право читать и писать связь — тоже власть

Раздел безопасности RFC 9835 предупреждает, что несанкционированное чтение может раскрыть клиентские идентификаторы peer-sap-id. Запись способна влиять на адресацию, маршрутизацию, фильтрацию, шифрование, ключи и привязку услуги. Учётная запись, меняющая связь между сервисным намерением и сетевым AC, редактирует не только метаданные — она способна перенаправить сетевую реальность.

Следует разделять право создать коммерческое намерение, перевести его в сетевую модель, записать конфигурацию на устройство и наблюдать рабочее состояние. Журнал должен сохранять аутентифицированного субъекта, область полномочий, старое и новое значение и результат. Ответ API 200 не доказывает ни мандат, ни доставку услуги.

Долговечная ценность RFC 9835 — прослеживаемый шов между обещанием сервисного слоя и объектом внутри сети. Автоматизация становится подотчётной, когда от этого шва можно пройти к независимому наблюдению и клиентскому результату. Она становится театром, когда ссылка сама считается доказательством работающего канала.

Источники