Кратко
- В миграционном примере RFC 9689 старые узлы продолжают применять LDP или RSVP-TE, новые получают прямые инструкции PCECC, а контроллер выступает прокси на границе.
- Связность пути не объединяет владение состоянием. Нужны отдельные доказательства соответствия идентификаторов, ответов узлов, переключения ingress, принятия сиротского состояния и очистки.
Приложение A.1 RFC 9689 описывает привлекательную возможность: менять сеть постепенно. Node1, Node2 и Node3 продолжают устанавливать LSP обычным способом; Node3 может представлять новые узлы; PCECC программирует выходной сегмент Node3, оба сегмента Node4 и входной сегмент Node5.
Для пакета это один маршрут. Для оператора граница остаётся материальной. Слева состояние объясняют соседства LDP, резервации RSVP-TE и локальные таблицы. Справа — сессии PCEP, Central Controller Instructions, CC-ID и отчёты PCRpt. Прокси связывает записи, но не делает их одной записью.
Сценарий нельзя выдавать за внедрение. RFC 9689 имеет статус Informational, а случаи в приложении не находились в активной разработке на момент публикации. Источники не подтверждают реализацию конкретного производителя, оператора, сбой или измеренный результат.
На границе нужен реестр соответствий
По RFC 9050 CC-ID уникален в пределах одной сессии PCEP. PLSP-ID, источник и идентификаторы LSP связывают инструкции на разных PCC. Но эти координаты сами по себе не указывают на идентичность старого LDP- или RSVP-TE-состояния.
Поэтому реестр миграции должен связать заявку, сервис, старый LSP, граничный узел и интерфейс, вход прокси, правило преобразования, выход прокси, PCE, сессию PCEP, PLSP-ID, все CC-ID, направление метки, целевое поколение и поколение отката. Вход, решение и выход следует хранить раздельно.
Без реестра значения меток могут быть верны, а полномочия — неизвестны. Одну метку мог выделить PCC, другую назначить PCE, пока старая резервация ждёт таймера. Статус «UP» не отвечает, кто вправе удалить каждый фрагмент.
Набор подтверждений не становится атомарным
RFC 9050 отправляет PCInitiate каждому PCC и получает PCRpt. Метка вне допустимого диапазона или ошибка установки дают явный отказ. Это точное локальное свидетельство, но не единая фиксация всего пути.
PCE обязан сопоставить ответы одному поколению и проверить все роли — ingress, transit и egress. Два ответа при молчании третьего узла означают частичную установку, а не решение большинством. Старая часть пути требует собственного синхронного наблюдения.
Порядок обновления make-before-break разделяет три момента: установить новые инструкции, переключить ingress, получить его отчёт и затем удалить старые инструкции. До переключения новый набор может занимать ресурсы без трафика. После переключения два поколения могут сосуществовать. После очистки PCECC на старой стороне ещё могут оставаться резервация и отображение прокси.
Откат зависит от момента. До переключения удаляют неполное новое поколение. После него сначала возвращают разрешённый путь. Если старое состояние уже снято, «назад» означает повторное построение, а не смену флага.
Сиротское состояние продолжает действовать
При потере PCE RFC 9050 не удаляет CCI немедленно. Они могут жить до State Timeout Interval, а новый PCE способен принять сиротские инструкции. RFC 8283 отдельно отмечает сложность синхронизации параллельных контроллеров без потери сетевых изменений.
Это защищает непрерывность, но отделяет работающий код от текущего владельца. Новая PCEP-сессия не доказывает, что заменяющий контроллер восстановил отображение прокси, стадию миграции и полномочие на изменение.
Запись восстановления должна содержать последнее полное поколение, ответившие и неответившие узлы, ingress, старую сигнализацию, незавершённую очистку, сроки, событие принятия сироты и правило следующего действия. Синхронизация обнаружит различие меток, но не восстановит незаписанное решение.
Поэтому завершение формулируется проверяемо: единая карта идентичности покрывает обе стороны; все обязательные узлы подтвердили одно поколение; переключение ingress отдельно разрешено; остатки старой и новой схемы удалены; потеря контроллера и принятие сирот испытаны; наблюдение за пересылкой согласуется с контрольными квитанциями, но не подменяет их.
Прокси полезен именно как минимальная точка совместимости. Если приписать ему единую власть над всем LSP, шов не исчезнет — исчезнет возможность им управлять.
Источники
- RFC 9689, запись публикации и история IETF
- Обычный текст, XML и поиск опечаток
- RFC 9050, процедуры PCECC
- RFC 8283, архитектура PCECC
- RFC 8231, Stateful PCE
- RFC 8281, LSP по инициативе PCE
- RFC 8741, запрос делегирования
- RFC 5440, PCEP и RFC 8253, PCEP поверх TLS
- RFC 5036, LDP и RFC 3209, RSVP-TE
- Минимальная начальная спецификация и локальное будущее решение
- Слои реальности и символическая власть
- Приоритет работающего кода
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

