Кратко

  • Проект draft-ietf-teas-actn-poi-applicability-20 находится на этапе IESG Last Call до 23 сентября 2026 года и задуман как информационный RFC. Два заключения «Not ready» принадлежат рецензентам и не означают отказ IESG.
  • Специалист по безопасности предлагает анализ активов и границ доверия. Специалист по эксплуатации спрашивает, как MDSC и PNC восстанавливают согласованное состояние после перезапуска, потери уведомлений, переключения координатора и изменения, принятого лишь одной областью.
  • Перед передачей полномочий автоматизации оператору нужно испытать права доступа, актуальность данных, идентичность незавершённой операции, компенсацию частичного результата и состояние услуги. Это аналитический критерий статьи, а не установленное проектом требование.

Три контроллера, два разных ответа

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

Двадцатая редакция проекта ACTN/POI разбирает работу Multi-Domain Service Coordinator (MDSC) с Provisioning Network Controllers (PNC) пакетной и оптической областей на основе существующих протоколов и моделей YANG. Финальный сбор замечаний IESG начался 9 сентября и должен закончиться 23 сентября. Намеченный статус — Informational. На момент проверки 21 сентября документ оставался Internet-Draft, а не утверждённым или опубликованным RFC. В нём уже есть разделы о безопасности и эксплуатации. Рецензии спорят об их достаточности для реальной координации многих доменов.

Yaron Sheffer завершил рецензию по безопасности 18 сентября, а Nick Buraglio — по эксплуатации 19 сентября. Обе получили отметку «Not ready». В кратком выводе Buraglio называет некоторые опасения небольшими, но недостаток эксплуатационного раздела относит к основным проблемам в подробном тексте. При этом рецензия Zheng Zhang по маршрутизации получила «Ready» и содержит в основном уточнения. Нельзя складывать оценки разных директоратов в мнимое окончательное решение IESG.

Защищённый канал может передавать устаревшую правду

Sheffer отмечает, что раздел 7 говорит о защите интерфейсов и уделяет отдельное внимание LLDP. Он просит дополнить это коротким анализом угроз для архитектуры с несколькими административными областями, поставщиками и отношениями доверия. Необходимо обозначить защищаемые активы и границы, рассмотреть захваченные или злонамеренные контроллеры, ложные либо устаревшие сведения о топологии и ресурсах, несанкционированные действия между уровнями, раскрытие данных, истощение ресурсов и несовместимые состояния пакетной и оптической частей.

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

RFC 8453 задаёт роли ACTN и возможность формировать абстрактное представление сети по правилам доступа. Шифрование и аутентификация подтверждают канал и отправителя, но не доказывают, что представление ещё актуально, что разрешение охватывает именно данное изменение или что перезапущенный PNC помнит принятое ранее обязательство. Для управления важны происхождение, версия, срок действия и адресат данных, а также пределы прав на действия с каждой областью.

После потери уведомления возникают две версии настоящего

Buraglio обращает внимание на то, что MDSC получает сведения о топологии и услугах из уведомлений PNC. Потеря сообщения, перезапуск PNC или частичный сбой способны разделить состояние координатора и состояние домена. Как обнаружить расхождение и восстановить достоверную картину? Что делать с операцией в процессе во время перезапуска или переключения MDSC? Продолжат ли работать ранее настроенные услуги, если координатор недоступен? Проект, по оценке рецензента, не даёт достаточных ориентиров.

Последовательность действий между MDSC, пакетным и оптическим PNC также требует сроков ожидания, правил повтора и понимания задержки настройки. Рецензент отдельно спрашивает о случае, когда пакетная часть изменилась, а оптическая нет, и об обратном случае. Проверка такой системы должна связывать повтор с предыдущим запросом и выяснять, что реально подтвердил каждый домен, до компенсации. Это операционный вывод статьи из поставленных вопросов, не описание конкретного сбоя и не приписанный проекту универсальный алгоритм отката.

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

Проверять надо момент расхождения

Оператор может потребовать единую цепочку для каждого изменения: кто санкционировал запрос, какую версию ресурсов использовал каждый контроллер, какой устойчивый идентификатор есть у незавершённой операции, что подтвердил или отверг каждый PNC и как изменилось обслуживание клиента. Затем испытание намеренно теряет уведомление, перезапускает PNC в середине работы, переключает MDSC между ответами и доводит до успеха только одну область. Система должна уметь честно сказать «состояние неизвестно, новые команды остановлены до сверки», а не автоматически объявлять всё успешным.

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

Источники

Проект ACTN/POI и статус; рецензия по безопасности; рецензия по эксплуатации; рецензия по маршрутизации; рамочный RFC 8453.