Кратко

  • Операция vn-compute в RFC 9731 выполняется до инстанцирования: она может вернуть рассчитанную VN и ссылки на матрицу связности, но не создаёт VN и не резервирует ресурсы.
  • Отказ от такого результата является отменой предложения. Rollback рабочей сети начинается лишь после появления конфигурации, обязательств ресурсов и установленных объектов.
  • Надёжная цепочка отдельно фиксирует расчётный snapshot, решение о конфигурации, допуск доменов, реальные туннели, сходимость, трафик и результат для клиента.

Команда нажала «rollback» и сообщила, что сеть возвращена в исходное состояние. На самом деле она лишь удалила расчёт из очереди согласования.

Ни один туннель не был демонтирован. Пропускная способность не освобождалась. Трафик не переключался. Сеть до и после операции оставалась одной и той же, потому что рассчитанная VN ещё не существовала.

RFC 9731 проводит эту границу прямо. vn-compute служит для просмотра полной виртуальной сети до инстанцирования. Результат расчёта не создаёт VN и не резервирует ни одного ресурса в системе.

Точное название действия важно: пока реальность не изменилась, отменяется решение. После изменения реальности приходится откатывать систему.

Абстракция показывает не весь underlay

RFC 9731 определяет YANG-модель операций Virtual Network. В основном сценарии ACTN Customer Network Controller выражает клиентский взгляд, а Multi-Domain Service Coordinator координирует данные и расчёт. Access Points описывают свойства клиентских концов, Virtual Network Access Points делят AP между разными VN и связывают их с границей провайдера.

VN Type 1 может выглядеть как набор абстрактных links между краями. Type 2 способен показать виртуальные узлы, links и предполагаемый путь. Клиенту не требуется полный внутренний граф провайдера.

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

Граница service model формулирует тот же принцип: описание услуги не предполагает конкретный способ её инженерной реализации и доставки.

vn-compute остаётся предынсталляционным действием

В запрос можно включить constraints и критерии оптимизации для всей VN и отдельных участников. Значения участника способны переопределить более общие. Ответ может ссылаться на одноузловую абстрактную topology и для каждого VN member указывать connectivity-matrix-id, где находятся свойства пути.

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

Расчёт отвечает «что могло бы быть построено при этих сведениях». Он не отвечает «что уже стало частью рабочей сети».

Успех расчёта не покрывает последующие события

Успешный RPC может подтвердить, что запрос принят, расчёт не завершился определённой ошибкой и в конкретный момент вернул определённые members, topology references и matrix references под заданными constraints.

Сам по себе он не подтверждает право создать live VN, commit конфигурации в нужный datastore, admission каждого домена или установку tunnel и LSP. Он также ничего не доказывает о сходимости operational state, прохождении пакетов, потере, задержке, защите и принятии услуги клиентом.

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

«Доступно» не означает «выделено»

Расчёт может вернуть ошибки: MDSC не готов, зависимый CNC недоступен, нет доступного ресурса, путь не найден, Access Point неизвестна.

Отсутствие ошибки «нет ресурса» иногда принимают за резервирование. Это неверно. Оно означает лишь, что информационный snapshot допускал решение.

До следующего шага ресурс может получить другой запрос. Локальная policy может измениться, абстрактный link — получить другое отображение, а владелец домена — отклонить конфигурацию. Доступность описывает состояние в расчёте. Выделение является действием субъекта с полномочиями.

Этим утверждениям нужны разные авторы.

Матрица связности не является туннелем

Ссылка на connectivity matrix позволяет связать VN member с допустимыми switching-комбинациями и потенциальными свойствами TE path внутри абстрактного узла.

Она сохраняет полезную структуру, не раскрывая весь underlay. Но ссылка не выделяет bandwidth, не подтверждает применение конфигурации на каждом участке и не показывает, что LSP установлен и forwarding работает.

Если matrix ID попадает в change ticket со статусом «provisioned», изменилось только слово. Доказательством реального состояния служат идентификаторы фактических объектов, результаты их установки и операционные наблюдения.

Распределённая координация не централизует власть

MDSC может организовать много-доменный расчёт, не имея права единолично тратить capacity всех доменов. У каждого есть собственные admission policy, maintenance state, quotas, protection requirements и конкурирующие запросы.

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

Сервис расчёта подписывает входные данные, версии и результат. Владелец конфигурации фиксирует намерение. Домены фиксируют admission или отказ. Provisioning называет реальные tunnel и LSP. Операции наблюдают сходимость, а граница услуги — клиентский трафик. Автоматизация связывает эти записи, но не превращает их в одну власть.

Snapshot стареет до начала работ

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

Пока согласование ждёт, меняются topology, resources, policy, Access Point и доступность зависимого controller. Чем дольше интервал до инстанцирования, тем больше результат похож на историческую опцию.

Расчёт нужно связывать с constraints, members, версиями abstract topology и matrix, policy revision, временем resource view, участвующими controllers и сроком действия. Существенное изменение требует recompute или нового review.

Без такого конверта оператор не отличит свежий расчёт от replay старого ответа.

Конфигурация и operational state остаются разными

Модель следует NMDA и размещает operational state в одном дереве с конфигурацией. Это облегчает навигацию, но не объединяет намерение и наблюдение.

VN member может быть настроен и оставаться down. Во время convergence состояние может относиться к прежней конфигурации. Единый ответ способен содержать leaves, записанные разными механизмами в разное время.

Поэтому свидетельство должно включать datastore, timestamp, controller и revision модели. Соседство в schema не является причинным тождеством.

Ошибки расчёта не описывают весь lifecycle

Определённые причины ошибок полезны на стадии computation. Они не являются полным набором отказов reservation, provisioning, convergence и service validation.

Резервирование способно провалиться после верного расчёта. Provisioning может частично пройти в одних доменах и не пройти в других. Operational state может не сойтись. Трафик способен использовать путь с допустимыми абстрактными свойствами и всё же не отвечать нуждам клиента.

Для каждой стадии нужны собственные положительные и отрицательные receipts. Один общий success скрывает частичный результат и лишает команду точки восстановления.

Compute и create требуют разных прав

В разделе безопасности предполагаются защищённые NETCONF или RESTCONF и контроль NACM. Конфигурация и operational data могут быть чувствительными; сам vn-compute способен раскрыть сведения о VN.

Право вычислять поэтому не безобидно: оно может открыть endpoints, topology, policies и потенциальную capacity. Но оно не должно автоматически включать create, reserve или delete.

Read, compute, configure, reserve и delete можно разнести по отдельным capabilities. Система планирования получает право на вычисление, а live change остаётся у отдельно одобренного субъекта.

Отмена и rollback имеют разную цену

До commitment результат расчёта можно отбросить. Ничего не надо освобождать, потому что ничего не было занято. При необходимости выполняется новый расчёт.

После commit обратный путь может потребовать удалить tunnel, освободить capacity, восстановить policies, синхронизировать домены и защитить действующий traffic. Здесь уже есть затронутая система, риск и стоимость.

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

Цепочка receipts определяет точку невозврата

Сначала сохраняются принятый compute request и информационный snapshot. Затем — рассчитанные members, matrix references и errors. После этого принимается отдельное configuration decision с известным approver. Собирается resource admission всех нужных доменов. Фиксируются реальные tunnel или LSP и их installed state. Наблюдается operational convergence, проверяется traffic на клиентской границе, записывается acceptance или оставшийся gap.

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

RFC 9731 ставит первый маркер: сеть в результате расчёта ещё не стала сетью, которую можно откатить.

Источники