Кратко

  • RFC 9573 заменяет множество пространств, привязанных к входным PE, общим блоком домена или несколькими совместно используемыми контекстными пространствами.
  • Экономия работает лишь при поддержке процедуры всеми PE и точками сегментации и при едином назначении; способ обеспечить эти условия оставлен за пределами RFC.
  • Развёртыванию нужны отдельные квитанции полномочий, версии, резервирования, выбора таблицы, установки FIB, согласованности маршрутов и наблюдаемой доставки.

Миллион значений превратился в тысячу — на бумаге

В примере RFC сеть имеет 1001 PE, каждый с 1000 VPN или широковещательных доменов. При назначении меток каждым источником выходной PE должен понимать миллион значений в тысяче контекстов. Общая метка для каждой услуги сокращает таблицу примерно до тысячи строк.

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

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

Обязательная поддержка не равна доказанной поддержке

RFC требует, чтобы все PE и точки сегментации поддерживали процедуру. Как это обеспечить, документ прямо оставляет вне своего охвата. Назначение меток VPN, BD и ES и осведомлённость каждого PE также формируются внешними методами.

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

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

Внешняя метка выбирает таблицу, внутренняя — услугу

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

Context-Specific Label Space ID Extended Community передаёт этот выбор. PE ставит селектор в таблицу MPLS по умолчанию, а услугу — в выбранную контекстную таблицу. Это две независимые установки. Правильный селектор к таблице старой версии остаётся ошибкой.

В пакете нет журнала согласования и номера контроллерной генерации. Проверка обязана связать желаемое состояние, принятую конфигурацию, фактическую FIB и наблюдаемый тестовый трафик.

На границе региона агрегат распадается

Два потока могут идти по одному селективному туннелю T1 в регионе A, а после границы — по T2 и T3. Точка сегментации должна различить их и переключить на разные продолжения.

RFC предлагает выделять PE непересекающиеся блоки в нескольких общих контекстных пространствах. Каждый PE самостоятельно назначает из своего блока метки для сегментированных PMSI. Центр не выбирает каждое число, но отвечает за границы, владельца и эпоху блока.

Альтернатива переносит поиск (C-S,C-G) в VRF точки сегментации. Тогда растёт число потоковых маршрутов, а не меток. Архитектура перемещает состояние между подсистемами, не отменяет его.

Противоречие означает withdrawal

Маршрут не может одновременно нести DCB flag и идентификатор контекстного пространства. При наличии обоих он считается отозванным. При отсутствии обоих действует прежняя привязка upstream label к пространству исходного PE.

Маршруты x-PMSI или IMET одного туннеля тоже должны согласовать режим интерпретации. Иначе приёмник не знает, в какой таблице читать метку после туннельной инкапсуляции, и трактует их как отозванные.

Это отказ от догадки в control plane. Он не доказывает мгновенное удаление старой записи data plane, завершение пакетов в пути или отсутствие доставки в соседнюю услугу.

Реестр закрепляет синтаксис

IANA выделяет DCB bit, subtype Extended Community и реестр типов идентификатора. Эти номера обеспечивают совместимый формат, но не свидетельствуют о реализации, включении функции или правильности назначения.

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

Sources

Источники