Кратко

  • Transport Class объединяет туннели, которые оператор считает достаточно сходными; её 32-битный Color называет локальный класс, но не кодирует универсальный SLA.
  • При одновременном наличии Color в TEA, Transport Class RT и service route приоритет идёт именно в таком порядке.
  • Импорт в TRDB, разрешение next hop, fallback, программирование FIB, передача пакета и результат услуги — разные состояния.

Число получает смысл из конфигурации

RFC 9832 позволяет включить RSVP-TE, SR-TE, Flex-Algo и другие туннели в один класс по достаточно близким TE-характеристикам. Это может быть малая задержка, защита или обход узла. Точный способ классификации остаётся за реализацией и оператором.

Класс получает 32-битный Transport Class ID, называемый Color. Ноль предназначен для Best Effort, остальные значения — Private Use. Поэтому 100 в двух сетях не гарантирует одинаковые пределы задержки, потерь, защиты или период измерения.

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

Победивший атрибут не отменяет остальные

Color sub-TLV в Tunnel Encapsulation Attribute относится к конкретной инкапсуляции. Transport Class RT в BGP CT задаёт импорт в TRDB и может играть роль Mapping Community. Color Extended Community на service route выражает запрос overlay.

Раздел 7.10 задаёт порядок от более конкретного к менее конкретному: TEA Color, Transport Class RT, затем service-route Color. Это обеспечивает детерминированное решение, но не полноценный аудит.

Следует сохранять все полученные значения, типы атрибутов, peer, версию policy и итог. Одна строка «effective Color 100» не покажет, переопределил ли TEA запрос сервиса.

TRDB остаётся границей control plane

У каждого класса есть логическая Transport Route Database. BGP CT route несёт RD:endpoint, Transport Class RT и MPLS label либо эквивалентный идентификатор. Если класс настроен локально, роль Route Target определяет TRDB для импорта.

RFC разрешает реализовать TRDB как таблицу только для control-plane reachability. Туннельные маршруты не обязаны занимать forwarding plane, пока не разрешают next hop. Наличие в правильной базе не подтверждает ни выбор сервисом, ни аппаратную запись.

В роли Mapping Community RT выбирает Resolution Scheme. Он содержит одну или упорядоченный ряд TRDB. Longest Prefix Match ищет endpoint; резервная база используется только при отсутствии совпадения в предыдущих. При отсутствии Scheme для класса применяется Best Effort. Без Mapping Community также применяется Best Effort, а BGP CT route не добавляется в классовую TRDB.

Совместимость сохраняет достижимость, но может скрыть исчезновение обещанного режима.

Fallback требует объяснения

Совпадение во второй TRDB не говорит, почему его не было в первой. Причиной могут быть отказ туннеля, import policy, RTC filter, неверный endpoint, устаревшая конфигурация или несовместимый forwarding. RFC определяет поиск, а не диагноз.

Подтверждение разрешения должно содержать маршрут и peer, все Color-поля, effective Mapping Community, версию Scheme, порядок TRDB, базу совпадения, выбранный туннель и факт fallback. Без совпадения маршрут становится unresolvable. Непригодный Best-Effort BGP CT route нельзя распространять дальше.

Route Target Constraint управляет распространением. При построении outbound filter нужно учитывать несколько EBGP RTC paths, а не только best path. Отсутствие маршрута может быть фактом распространения до того, как станет фактом туннеля.

Граница переводит локальный словарь

В примере несогласованных доменов service community color:0:100500 сохраняется, но локальные схемы связывают её с TRDB 500, 300 и 100. Border routers переписывают Transport Class RT с 500 на 300, затем с 300 на 100.

Так координация ограничивается соседними доменами. Однако локальный RT не доказывает одинаковый SLA. Требуется хранить полученный и отправленный RT, определения сторон, соглашение, commit policy, исполнивший узел, время и rollback. Конечное 300 без истории превращает перевод в ложную универсальную семантику.

За разрешением следует forwarding

Когда MPLS border node переобъявляет BGP CT route с next hop self, он выделяет label и устанавливает маршрут для swap или pop входящего label с отправкой в разрешённый туннель. Реализация может выборочно ставить BGP CT routes в FIB для control-plane peering.

Дальше проверяются аппаратная запись, общая инкапсуляция и пакет. В примерах RFC MPLS-only и SRv6-only nodes не могут общаться напрямую: их BGP CT routes остаются непригодными без общей технологии.

SLA закрывают измерения на сервисной границе: потери, задержка, доступность, защита и окно измерения. RFC 9832 имеет статус Experimental; публикация не доказывает внедрение или результат. Verified Erratum 8583 лишь заменяет три SN1 на SN11.

Мысль Heng Lu о «бесцветном» Интернете возвращает оценку к эффективности, которая реально работает для операторов, а не к ярлыку. Здесь Color остаётся индексом, проверяемым исполнением. Running-Code Primacy требует воспроизводимых атрибутов, policy и FIB; Reality Layers разделяет идентификатор, значение, control plane, forwarding и клиентский итог. Это редакционные рамки BTW, не новые требования IETF.

Источники