Технологии MPLS более двадцати лет. Всё это время она широко использовалась операторами связи, а также в больших корпоративных сетях. Казалось бы, стоит ли искать «лучшее вместо хорошего»? Так, да не так.

В завершающей части нашего цикла про Traffic Engineering обсудим подробнее тему Segment Routing, к которой мы подошли в прошлый раз И для этого нам будет нужно разобраться, что же не хватало в MPLS.

Cодержание энциклопедии Traffic Engineering:

1. Основы, распределённый и централизованный расчёт туннелей, магия РСЕ

2. Основы РСЕР и Stateful PCE, Междоменный RSVP‑TE, новый взгляд на РСЕСС

3. Жизнь после MPLS (мы находимся здесь)

Итак, сначала был MPLS

Основные причины феноменального успеха MPLS

На начальном этапе в конце 1990-х‑начале 2000-х — форвардинг на основе метки фиксированного размера в 32 бита был более эффективен на маршрутизаторах у операторов связи, в сравнении с принципом Longest Prefix Match (LPM) при обычной IP‑маршрутизации.
Virtual Private Networks (VPN) позволили создавать поверх общей MPLS‑инфраструктуры оверлейные сети: L2 и L3-связность для клиентов с заданным уровнем качества обслуживания. Это было необычайно крутым прорывом в то время.
Поддержка TE на основе RSVP‑TE, про который я писал в предыдущих частях.
Обеспечение защиты от сбоев и быстрой сходимости.

Но некоторые ограничения MPLS вынудили индустрию думать про что‑то ещё.

Недостатки MPLS

Необходимость специализированных протоколов для работы (LDP, RSVP‑TE).
LSP, созданный LDP, всегда следует кратчайшему пути (SPF), который получен от IGP. Также необходима т. н. синхронизация с IGP.
Фиксированный формат MPLS‑метки не позволяет добавлять различную метаинформацию.
Масштабируемость RSVP‑TE: необходимость поддерживать forwarding‑state для N*(N-1) LSP, где N — количество РЕ в случае полной связности в том числе и на промежуточных Р‑маршрутизаторах. Если здесь есть читатели, которые проводили сравнение RFI/RFP от вендоров, то они помнят, что там были разные цифры по количеству туннелей на Head‑End, Tail‑End и midpoint. Добавим к этому сложность мониторинга, эксплуатации и конфигурирования RSVP‑TE, особенно для случаев распределённого ТЕ и полной связности, когда при добавлении RSVP‑TE LSP или нового РЕ необходимо было сделать это на N-1 устройствах (обратные LSP).
Сложность организации Е2Е LSP в случае нескольких доменов, например, если это типичная операторская сеть с несколькими IGP‑доменами. Здесь уместно сравнить домены с островами, в этом случае у нас в каждом домене был бы свой транспорт MPLS (LDP или RSVP‑TE). А для E2E LSP мы были бы вынуждены использовать BGP‑LU Тут можно вспомнить аббревиатуру Seamless MPLS — это та архитектура, на основе BGP‑LU LSP, при помощи которой мы решали проблему E2E междоменного LSP, но появлялась дополнительная сложность.
Сложность организации Е2Е сервиса (VPN) в случае нескольких доменов: вспоминаем варианты Inter‑AS VPN.

Да, для этих проблем были найдены обходные пути или решения: RSVP‑TE Automesh, Autobandwidth, Refresh reduction, Seamless MPLS, Inter‑AS VPN, — но сами проблемы всё равно оставались.

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

В 2013 году на свет появилась технология, о которой мы начали говорить в прошлый раз, — Segment Routing. Буквально это «маршрутизация сегментов», дальше по тексту будем называть её SR. Суть очень коротко заключается в том, что она:

Стандартизуется в рабочей группе IETF Source Packet Routing in Networks (SPRING WG).
Использует парадигму маршрутизации от источника (Source Routing). Путь пакета определяет входящий маршрутизатор (РЕ), только на нём сохраняется per‑flow состояние.
Путь пакета описывается в виде набора инструкций (сегментов, инструкция либо топологическая, либо сервисная).
Каждый узел сети (маршрутизатор) анонсирует сегменты для имеющихся у него интерфейсов/префиксов: Prefix‑ Segment Identifier (SID), в RFC 8402 их также называют IGP SID. Сегмент, привязанный к loopback‑интерфейсу, называется Node‑SID (идентифицирует маршрутизатор), сегмент для физического интерфейса называется Adjacency‑SID (Adj‑SID). Также есть специальные сегменты, например: Anycast‑SID, Binding SID (BSID), см. подробнее RFC 8402 и мой доклад на nexthop.
Для сигнализации сегментов в сети, либо их индексов из Segment Routing Global Block (SRGB), в базовом сценарии используются наши старые‑добрые друзья: протоколы IGP (OSPF, ISIS), также может использоваться BGP‑LS, основное применение которого т. н. Egress Peering Engineering для сигнализации соответствующих SID, и кроме того: BGP‑LU и PCEP. То есть более никаких специальных протоколов нет, и как изящно написано в RFC 1925: «(6) проще переместить проблему (например, в другую часть сетевой архитектуры), чем решить её».
При использовании IGP‑сегментов SR поддерживает разные алгоритмы, наиболее очевидный — это выбор кратчайшего пути (SPF). Таким образом путь до исходящего маршрутизатора (Egress PE) может определяться только одним сегментом (SID) и поддерживать ECMP‑балансировку. Тут есть некоторые аналогии с LSP на основе LDP, такой режим ещё называют SR‑BE (Best Effort).
SR с точки зрения форвардинга бывает двух типов: SR‑MPLS, где формат сегмента идентичен формату MPLS‑метки, и SRv6, где формат сегмента идентичен IPv6-адресу.
SR поддерживает ТЕ — про это поговорим подробно дальше.

SR прошла долгий путь за эти 10 лет, от изначального неприятия и межвендорских споров о том, например, чья имплементация MPLS лучше, — до достаточно зрелой и стабильной технологии, которая получила своё признание и место в различных сетях и была поддержана всеми основными сетевыми вендорами (с нюансами). Сейчас SR выглядит вполне достойной альтернативой классическому MPLS.

Некоторое время тому назад мы в NOC Яндекса решили, что надо двигаться в сторону SR, для чего прошли через все этапы планирования и внедрения новой технологии:

Формулировка постановки задачи — для чего нам нужна SR.
Выбор типа технологии на тот момент: исходя из поддержки вендорами и зрелости мы выбрали SR‑MPLS.
Проработка требуемой функциональности, в том числе ТЕ на основе SR Policy, согласование параметров SR (SRGB и т. д.), написание HLD, тестирование в лаборатории.
Начало разработки собственного SDN‑контроллера (Сусанин).
Проработка процедуры миграции.
Поэтапная миграция на ISIS с расширениями SR — его выбрали в силу того, что большинство новой функциональности сейчас появляется сначала в ISIS. Параллельная работа ISIS и OSPF, затем полный переход на ISIS.
Развёртывание SR‑BE, уход от RSVP‑TE в части сети.
Развёртывание ТЕ на основе SR Policy c расчётом на Сусанине и т. д.
Решение различного рода проблем в процессе миграции, о которых мы также рассказывали в докладах на nexthop

Не буду далее погружаться в теоретизирование по SR, а приведу несколько базовых примеров:

mpls lsr-id 192.168.200.24

segment-routing
 tunnel-prefer segment-routing  <- Задание предпочтительности выбора SR-BE  vs. LDP
 local-block 156502 159999         <- SRLB

isis 20
 is-level level-2
 cost-style wide
 network-entity 1921.6820.0024.00:00
 is-name lab2
 traffic-eng level-2
 segment-routing mpls
 segment-routing global-block 150000 156000  <- SRGB


interface LoopBack0
 ip address 192.168.200.24 255.255.255.255
 isis enable 20
 isis tag-value 20
 isis prefix-sid index 5090  <-  Задание индекса для Prefix-SID для Loopback

Базовая настройка SR-MPLS на маршрутизаторе Huawei

[~lab2]dis segment-routing adjacency mpls forwarding

            Segment Routing Adjacency MPLS Forwarding Information

Label     Interface                     NextHop           Type    MPLSMtu   Mtu       VPN-Name                    
-------------------------------------------------------------------------------------------------------------
48083     100GE0/1/29.860    172.16.26.249   ISIS-V4     ---       9000      _public_                    
48084     100GE0/1/29.887    172.16.26.195   ISIS-V4     ---       9000      _public_                    
48085     100GE0/1/29.886    172.16.26.197   ISIS-V4     ---       9000      _public_    
[SNIP]

Просмотр Adj-SID на маршрутизаторе Huawei

[~lab2] display segment-routing prefix mpls forwarding

                   Segment Routing Prefix MPLS Forwarding Information
             --------------------------------------------------------------
             Role : I-Ingress, T-Transit, E-Egress, I&T-Ingress And Transit

Prefix                          Label      OutLabel   Interface                NextHop          Role  MPLSMtu   Mtu     State
            -----------------------------------------------------------------------------------------------------------------
192.168.200.180/32  152860     3          100GE0/1/29.860   172.16.26.249    I&T   ---       9000    Active
192.168.200.181/32  152861     3          100GE0/1/29.861   172.16.26.247    I&T   ---       9000    Active
192.168.200.182/32  152862     3          100GE0/1/29.862   172.16.26.245    I&T   ---       9000    Active
192.168.200.183/32  152863     3          100GE0/1/29.863   172.16.26.243    I&T   ---       9000    Active
192.168.200.24 /32   155090     NULL       Loop0                    127.0.0.1             E       ---       1500    Active
[SNIP]

Просмотр SR-MPLS Label Forwarding Information Base на маршрутизаторе Huawei

[~lab2] dis isis 20 lsdb local verbose

                        Database information for ISIS(20)
                        -----------------------------------
                          Level-2 Link State Database

LSPID                  Seq Num    Checksum   HoldTime       Length   ATT/P/OL
-----------------------------------------------------------------------------
0872.5022.8232.00-00*  0x000172f6 0x36d1     32230          1165     0/0/0
 SOURCE       lab2.00
 HOST NAME    lab2
 NLPID        IPV4
 AREA ADDR    01
 INTF ADDR    192.168.200.24
 INTF ADDR    172.16.4.158
 INTF ADDR    172.16.4.126
 INTF ADDR    172.16.4.94
 [SNIP]
+NBR  ID      rr1.00  COST: 10
   Adj-Sid    48082      F:0 B:0 V:1 L:1 S:0 P:0 Weight: 0 <-  По флагам см. ниже. Вес используется для балансировки
+NBR  ID      rr1-clone.00  COST: 10
   Adj-Sid    48083      F:0 B:0 V:1 L:1 S:0 P:0 Weight: 0
[SNIP]
+IP-Extended  192.168.200.24      255.255.255.255  COST: 0          Tag: 20
   Prefix-Sid   5090       Algorithm: 0   Flag: R:0 N:1 P:1 E:0 V:0 L:0   Metric: --  <-  Алгоритм 0 – SPF (1 – Strict SPF)
 Router ID    192.168.200.24
 Router Cap   192.168.200.24 D: 0  S: 0
   Segment Routing Cap   I: 1   V: 0   SRGB Base: 150000     Range: 6001  <- Диапазон SRGB
   Segment Routing MSD   BMI: 10    <- Максимальная глубина стека меток 
   Segment Routing Local Block  Flags: 0x00  SRLB Base: 156502     Range: 3498  <- SRLB
[SNIP]

Просмотр LSDB на маршрутизаторе Huawei

Комментарий по флагам Prefix‑SID ( R:0 N:1 P:1 E:0 V:0 L:0 — передаются в Prefix‑SID sub‑TLV):

R — re‑advertisement. Если он установлен, то префикс мог быть импортирован из другого протокола или из ISIS другого уровня (L2 → L1, например).
N — Node SID, идентификатор узла в SR, устанавливается, когда Prefix‑SID назначен loopback‑интерфейсу.
P — no PHP, выключение penultimate hop popping (PHP), т. е. маршрутизатор перед исходящим не снимает его метку (SID).
E — explicit null.
V — value, если установлен, то Prefix‑SID содержит конкретное значение, а не индекс в SRGB.
L — local significance, локальная значимость, по умолчанию не ставится для Prefix‑SID, а ставится для Adj‑SID.

Комментарий по флагам Adj‑SID ( F:0 B:0 V:1 L:1 S:0 P:0 — передаются в Adj‑SID sub‑TLV):

F — address family (0-IPv4, 1-IPv6).
V — value, передаётся значение Adj‑SID.
L — local, локальная значимость, как аналогичный флаг для Prefix‑SID выше.
S — set, если установлен, то данный Adj‑SID может быть использован и для других интерфейсов.
P — persistent. Adj‑SID могут назначаться заново автоматически после рестарта устройства либо падения интерфейса, либо быть постоянными (не меняющимися). Этот флаг сигнализирует о постоянном типе Adj‑SID.

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

Очень быстро скажу и про SRv6: помимо первоисточников RFC 8402 и RFC 8986, а также докладов на nexthop я рекомендую прочитать книгу SRv6 Network Programming Ushering a New Era of IP Networks. Принципиальное отличие SRv6 от SR‑MPLS заключается в том, что сегмент — это IPv6-адрес, согласно RFC 8986, поделённый на две части: локатор и функцию. Локатор — это IPv6-префикс, идентифицирующий маршрутизатор, а функция — это инструкция по обработке пакета, также опционально может быть и третья часть — аргументы для функции. Таким образом SRv6 — это первая технология, реализующая на практике концепцию сетевого программирования и существенно уменьшающая нагрузку на control plane.

Вот сравнительная таблица из доклада:

SRv6 обладает уникальной возможностью которая не существовала ни в классическом MPLS, ни в SR‑MPLS. Так как локатор — сегмент (SID), идентифицирующий маршрутизатор, — это IPv6-префикс, то мы можем агрегировать локаторы со всех маршрутизаторов одного домена и отправлять в другой домен сети только один агрегат! Конечно, это требует тщательного планирования IPv6 адресов, примеров в литературе достаточно.

Выше я объяснил наш выбор SR‑MPLS, но мы также смотрим в сторону использования SRv6 в будущем и прорабатываем возможные сценарии, так как нам очевиден её огромный потенциал.

Естественно, для работы SRv6 (аналогично SR‑MPLS) нужны расширения для протоколов, и ниже список некоторых из них на момент написания статьи:

Внимательный читатель может заметить в списке ещё одно преимущество ISIS — в нём необходимо лишь включение поддержки IPv6-топологии, в отличие от OSPF, который требует дополнительно новый протокол OSPFv3.

Я сознательно пропускаю описание таких важных моментов технологии, как варианты Fast Reroute (FRR), Flex‑Algo, измерение производительности и OAM — они напрямую не относятся к теме статьи и нуждаются в отдельном и подробном рассмотрении.

Реализация ТЕ в Segment Routing

Обратимся к первоисточникам и разберёмся в паре терминов.

Обзор SR Policy

RFC 8402 прямо описывает модель реализации ТЕ в архитектуре Segment Routing:

An SR Policy can be used for Traffic Engineering (TE), Operations, Administration, and Maintenance (OAM), or Fast Reroute (FRR) reasons.

Что же такое эта SR Policy, и в чём здесь развитие и отличие от предыдущего RSVP‑ТE?

Приведу формальное определение, также из RFC 8402:

SR Policy: an ordered list of segments. The headend of an SR Policy steers packets onto the SR Policy. The list of segments can be specified explicitly in SR‑MPLS as a stack of labels and in SRv6 as an ordered list of SRv6 SIDs. Alternatively, the list of segments is computed based on a destination and a set of optimization objective and constraints (e.g., latency, affinity, SRLG, etc.). The computation can be local or delegated to a PCE server. An SR Policy can be configured by the operator, provisioned via NETCONF [ RFC6241 ] or provisioned via PCEP [ RFC5440 ]. An SR Policy can be used for Traffic Engineering (TE), Operations, Administration, and Maintenance (OAM), or Fast Reroute (FRR) reasons.

Итак, из этого определения следует, что SR Policy — это упорядоченный список сегментов, либо в виде MPLS‑меток для SR‑MPLS, либо в виде IPv6-префиксов для SRv6. Данный список может быть сформирован либо локально (CLI), либо получен извне, например, от РСЕ. SR Policy отражает описание ТЕ‑пути согласно заданному критерию или ограничению, например: кратчайший путь, путь с наибольшей доступной полосой пропускания, путь с минимальной задержкой и т. д.

Существенно подробнее архитектура SR Policy описана в фундаментальном RFC 9256.

Уместно сравнить SR Policy с матрёшкой, так как SR Policy представляет собой иерархический набор нескольких конструкций, вложенных друг в друга.

Давайте на основе этой диаграммы рассмотрим, что это за конструкции и как они совмещаются вместе. Для простоты пойдём слева направо.

Сама SR Policy по RFC 9256 определяется, как кортеж (tuple) из трёх параметров:

Headend — IP‑адрес маршрутизатора, где будет применена SR Policy.
Endpoint — IP‑адрес узла назначения политики, есть специально оговоренный случай, когда он может быть 0.0.0.0 или::, см. секцию 2.1 RFC 9256.
Color — цвет, 32-битное значение произвольного формата, ассоциирующее политику с определенной целевой функцией.

SR Policy — это итоговая конструкция, или самая большая матрёшка, которая содержит в себе N‑конструкций следующего уровня. Такой следующей вложенной конструкцией является путь‑кандидат (candidate path, СP), их количество не ограничивается стандартом. На практике, как правило, у многих вендоров поддерживается до 64 CP — но это уже ограничение маршрутизатора. Путь‑кандидат однозначно ассоциируется только с определенной SR Policy (не может разделяться между несколькими). Из N путей‑кандидатов, которые могут быть в одной политике, в моменте активным должен быть только один, про алгоритм его выбора поговорим ниже.

Путь‑кандидат имеет несколько важных параметров, про которые я должен написать.

Protocol‑Origin — тот протокол, через который создаётся путь‑кандидат. RFC 9256 задаёт три возможных варианта, и чем выше номер, тем большим приоритетом он обладает:
Три варианта протоколов создания пути-кандидата. У читателя постарше может возникнуть ассоциация с тремя источниками известного политэкономического учения
Originator — тот узел, который создаёт путь‑кандидат, например уже нам хорошо известный РСЕ. Он имеет форму: ASN (AS number) 4 байта, адрес узла 128 бит (для IPv4 старшие биты устанавливаются в 0).
Discriminator — дискриминатор, 32-битное число, идентифицирующее его в контексте SR Policy, используется для выбора активного СР.
Preference — предпочтительность СР, 32-битное число, используется для выбора активного СР. По умолчанию 100, чем больше, тем приоритетнее.

Таким образом, кортеж <Protocol‑Origin, Originator, Discriminator> однозначно идентифицирует путь‑кандидат в рамках одной SR Policy.

Возможны ещё другие опциональные параметры, например, имя пути‑кандидата.

Кроме перечисленных параметров, путь‑кандидат содержит в себе ещё несколько маленьких матрешек — списки сегментов (Segment List). Каждый Segment List содержит помимо самих сегментов, описывающих путь пакета от headend к endpoint, ещё и вес (weight). Вес используется для балансировки нагрузки между несколькими путями в рамках одного пути‑кандидата: либо ECMP, если вес у всех Segment List одинаков, либо weighted ECMP, если веса разные.

С учётом множества параметров у пути‑кандидата, мне пришла на ум аналогия в виде матрёшки с шестерёнками, и вот как она выглядит в представлении нейросети Шедеврум:

Фантазия на тему SR Policy и путей-кандидатов по версии Шедеврума

Путь‑кандидат остаётся активным до той поры, пока в его составе есть хотя бы один активный список сегментов (Segment List). Список сегментов остаётся активным, пока NH первого сегмента в списке находится в FIB и маршрутизатор может его разрешить (resolve), либо пока механизм мониторинга этого SL (например, S‑BFD) не определит его переход в состояние Down. Если путь‑кандидат имеет несколько активных SL, то трафик между ними будет балансироваться в зависимости от выставленного для каждого из них веса: ECMP или w/ECMP.

Какой же путь‑кандидат будет выбран активным в случае наличия нескольких? Во‑первых, в игру вступает Preference — тот, у кого она наиболее высокая, и становится активным. Если есть несколько путей‑кандидатов с одинаковой Preference — движемся дальше:

Выбирается путь с более высоким Protocol‑Origin.
Предпочитается уже существующий, инсталлированный путь.
Выбирается путь с более низким значением Originator, например, в случае нескольких РСЕ.

Но это ещё не всё, что мы должны знать о пути‑кандидате. Если заглянуть поглубже в его «личное дело», то можно узнать, что пути‑кандидаты бывают трёх видов:

Динамический — выражает некую целевую функцию, решающую определённую оптимизационную проблему, и посчитанный при помощи РСЕ.
Явно указанный (explicit), заданный через CLI с указанием одного или нескольких SL.
Композитный — пожалуй, самый сложный вариант, и я пока не видел информации ни у одного вендора о его поддержке. Это что‑то вроде контейнера для группировки SR‑политик для балансировки трафика между ними. Для таких политик задаётся три главных критерия: endpoint»ы должны быть одинаковыми, цвета должны быть одинаковыми, эти SR‑политики не должны использовать композитные пути‑кандидаты (исключаем рекурсию).

Методы доставки SR Policy на оборудование

В предыдущем параграфе я указал, что принципиально существует три пути доставки SR Policy на оборудование:

через CLI (Netconf),
через РСЕР,
через BGP‑SR.

Полагаю, вариант конфигурации через CLI/Netconf является очевидным, его темплейты описаны в вендорской документации. Как я говорил в докладах на nexthop, мы использовали этот вариант в качестве промежуточного: «разливали» конфигурации с политиками, посчитанными нашим контроллером, на РЕ через доступные средства автоматизации. Перейдём к следующему возможному варианту.

РСЕР (как бы он нам ни надоел). К сожалению или счастью, РСЕР относится к классу достаточно несложно расширяемых протоколов (опять вспомним BGP), так как использует сообщения, которые состоят из набора объектов. Они, в свою очередь, состоят из TLV и sub-TLV. Поэтому вполне логичным было предложить использовать его и для передачи SR Policy, нужны лишь некоторые расширения. Эти расширения описаны в PCEP Extensions for SR Policy Candidate Paths.

Суть заключается в новом объекте: ASSOCIATION. Черновик стандарта также использует термин SR Policy Association (SRPA). Вспомним пример из прошлой части:

Здесь записываются параметры SR Policy (или ассоциации), такие как:

Тип ассоциации (должен быть 6 — SR Policy).
Источник ассоциации (IP‑адрес headend»а).
ID ассоциации (16-бит).
Расширенные TLV (кодируют color и endpoint).

SRPA‑объект также содержит следующие важные TLV:

SRPOLICY‑POL‑NAME TLV: (опциональное, тип 56) передаёт имя SR Policy.
SRPOLICY‑CPATH‑ID TLV: (обязательное, тип 57) передаёт идентификатор пути‑кандидата SR Policy.
SRPOLICY‑CPATH‑NAME TLV: (опциональное, тип 58) передаёт строку с именем пути‑кандидата SR Policy.
SRPOLICY‑CPATH‑PREFERENCE TLV: (опциональное, тип 59) передаёт предпочтительность пути‑кандидата SR Policy.

Как видно, обязательным является только передача идентификатора пути‑кандидата, всё остальное — опционально. К сожалению, поддержка передачи имён SR Policy и пути‑кандидата на момент написания статьи — крайне слабая со стороны вендоров.

РСЕ и РСС должны сигнализировать друг другу то, что они поддерживают передачу SR Policy в РСЕР. Для этого используется SR‑POLICY‑CAPABILITY TLV, который содержится в объекте OPEN, его формат описан в секции 5.1 черновика стандарта.

Я хочу ещё отметить появление нового важного и полезного механизма, которого не было в более ранних версиях черновика стандарта, а именно: INVALIDATION TLV. С его помощью любая из сторон (РСС и/или РСЕ) может контролировать отправку трафика через LSP, в случае если с ним что‑то случилось (сбой, падение). Ранее, без механизма с INVALIDATION TLV, LSP сразу переводился в состояние Down, трафик переставал передаваться через него, и РСС переходил либо на SR‑BE с SPF, либо на резервный LSP (segment list или другой путь‑кандидат). В случае с INVALIDATION TLV LSP переходит в состояние «сброса» (drop state), т. е. LSP остается в статусе Up, но его трафик сбрасывается headend»ом. Это т. н. поведение «Drop‑upon‑Invalid», описанное в секции 8.2 RFC 9256.

Читатель задаст резонный вопрос: зачем такие сложности, что вы тут «намутили», товарищи? Эта сложность нужна там, где необходимо, чтобы определённый сервис, крайне чувствительный к SLA/SLO, передавался по строго определенному пути с какими‑то заданными ограничениями, например, минимальная задержка, либо не передавался вообще.

Возможные причины попадания LSP в это состояние:

F: First‑hop resolution failure — разрешение (lookup) первого NH в списке сегментов на headend не был успешным.
P: Path computation failure — не смогли посчитать путь.
V: Verification failure ‑OAM/BFD/Performance Management — не смогли верифицировать LSP.
G: Generic — иные возможные причины.

Чуть позже мы ещё подробнее скажем про важность для SR Policy специального типа сегмента, называемого Binding SID (BSID). Сейчас же просто отметим, что в SRPA‑объекте нет никакой информации про него. Действительно, он посылается с РСЕ на РСС другим образом, посредством TE‑PATH‑BINDING TLV (тип 55, LSP объект). Это описано в черновике стандарта Carrying Binding Label/Segment Identifier (SID) in PCE‑based Networks.

BGP — третий протокол, который может быть использован для доставки SR Policy. Для этого придумали отдельную SAFI (BGP SR, 73), используемую с AFI 1 (IPv4) или AFI 2(IPv6) для SR‑MPLS и SRv6 соответственно. Реализация описана в черновике стандарта Advertising Segment Routing Policies in BGP.

Пример BGP SR Update, SR Policy кодируется в Tunnel Encapsulation Attribute

В последнем примере появился новый параметр под названием Distinguisher, 4-байтное значение, которое делает SR Policy уникальной в контексте кортежа <color, endpoint>. Более конкретно — он делает уникальными пути‑кандидаты одной SR Policy либо SR Policies с одинаковыми кортежами <color, endpoint>, но с разными headend»ами.

Также видим Policy Color, 4-байтное значение идентифицирующее endpoint, так как трафик, имеющий BGP Color Community с таким же цветом будет отправляться этому endpoint. Про это поговорим отдельно в разделе про отправление трафика в SR Policy.

Формальное описание структуры BGP SR Policy (секция 2.2 RFC 9256)

Надо сфокусировать внимание на том, что сам сегмент (SID) передаётся в Segment Sub‑TLV. RFC 9256 определяет несколько типов (А‑К) сегментов, и чтобы окончательно не заплутать, упомяну лишь два основных:

Type A: SR‑MPLS Label.
Type B: SRv6 SID.

Остальные можно найти в секции 2.4.4.2 RFC 9256.

Стоит сделать небольшое отступление в сторону SRv6. Теперь стало совершенно очевидным, что SRv6 Policy будет представлять собой набор, стек IPv6-адресов. Как же должен выглядеть IPv6-пакет с этими адресами, где они все должны размещаться?

Для ответа на вопрос обратимся к RFC 8754, который описывает новый тип IPv6 Routing Header, называемый IPv6 Segment Routing Header (SRH).

При прохождении пакета из SRH (снизу вверх) берётся SID и записывается в поле DA внешнего IPv6-заголовка, а также уменьшается счётчик Segments Left.

А если нам надо описать достаточно длинный путь, например, с MSD ==10, то у нас будет 10 IPv6-префиксов в SRH? Как насчёт эффективности?

Ответ: да, будет 10 IPv6-префиксов. Для повышения эффективности в случае ТЕ на SRv6 и SRH используется т. н. «компрессия» SRH. Она изначально была предложена в двух основных видах. Точнее, есть и третий вариант, но в силу его ограниченной поддержки, упомяну только для формальности:

G‑SRv6 (вариант предложенный Huawei).
uSID (вариант предложенный Cisco).
SRm6 (вариант от Juniper).

Их подробное описание и сравнение выходит за рамки этой статьи. Отмечу, что в IETF была создана специальная design team, которая должна была на основе консенсуса сделать один общий вариант. В итоге он был описан в черновике стандарта Compressed SRv6 Segment List Encoding и теперь предлагается использовать два подхода (Flavors) для этого:.NEXT‑C-SID, REPLACE‑C-SID.

Вернёмся к BGP SR.

Кто посылает SR Policy на headend в случае BGP SR? В отличие от варианта с РСЕР, тут может быть три варианта:

Endpoint посылает BGP SR Update к Headend.
RR посылает BGP SR Update к Headend.
PCE (контроллер, Сусанин в нашем случае) посылает BGP SR Update к Headend.

На Headend программный компонент SRPM, получив одинаковые SR Policy из одного или нескольких источников, выбирает одну из них на основе значения Protocol Origin для инсталляции в FIB и передачи трафика через неё.

Какой из трёх вариантов более предпочтителен? Ответ, как обычно: It depends. Всё зависит от конкретной ситуации. Например, если у вас нет контроллера, создающего динамические политики с путями‑кандидатами, то ответ будет очевидным: CLI/Netconf.

Если же контроллер есть, то ситуация будет более сложная: необходимо понять, какие варианты он поддерживает: PCEP, BGP или оба? Какие варианты поддерживает ваше оборудование? Какие ограничения есть с обеих сторон?

Открытых вопросов много, приведу общие соображения на основе полученного опыта:

Вариант с BGP SR Policy поддерживается большим числом производителей (мы тестировали пока только SR‑MPLS).
В отличие от РСЕР, у которого есть различные сообщения в сторону РСЕ: PCRpt, PCErr, — BGP SR имеет проблемы с обратной связью, по сути, её нет. Поэтому для политик, отправленных через BGP SR, необходимы средства мониторинга на маршрутизаторе, проверяющие их состояние и передающие в РСЕ результаты по статусам: streaming telemetry, OAM, PM и так далее.
По РСЕР за последние пару лет также наметились некоторые улучшения: например, переход вендоров с приватных номеров TLV в SRPA‑объекте на стандартные. Также ещё один широко распространённый в мире вендор стал поддерживать SR Policy через РСЕР и сделал поддержку имён путей‑кандидатов. Таким образом, из большой четвёрки на текущий момент остался только один вендор, у которого её сейчас нет. Конечно, проблемы остались, но есть очевидный прогресс.

Передача трафика через SR Policy

Секция 8 RFC 9256 определяет несколько вариантов передачи трафика через SR Policy, от простых до достаточно сложных. Я перечислю их:

Входящий активный SID соответствует локально сконфигурированному BSID в SR Policy на headend.
Отправка по узлу назначения (per‑destination), входящие пакеты соответствуют BGP/VPN префиксу, которые рекурсивно резолвятся в нужную SR Policy, например, с Color community от endpoint.
Per‑flow, входящие пакеты соответствуют либо рекурсивно резолвятся в специальную структуру (forwarding array), записи в которой соответствуют сконфигурированным SR Policy.
Policy‑Based, входящие пакеты соответствуют критерию в сконфигурированной политике и отправляются в SR Policy.

Теперь будет уместно сравнить SR Policy с перечисленными выше способами передачи трафика через RSVP‑TE LSP и убедиться в огромной разнице и намного большей гибкости в случае SR Policy.

BSID — специальный сегмент, дающий невероятные возможности

Я решил специально остановиться на Binding SID и на том, что он может нам дать. Давайте вспомним его определение из RFC 8402:

In order to provide greater scalability, network capacity, and service independence, SR utilizes a Binding SID (BSID). The BSID is bound to an SR Policy, instantiation of which may involve a list of SIDs. Any packets received with an active segment equal to BSID are steered onto the bound SR Policy.

Это очевидно специальный SID, авторы RFC придумали для него потрясающее применение — при его получении РЕ «разворачивает» его в новый стек сегментов. Таким образом мы можем преодолевать любые имеющиеся ограничения на глубину стека меток (MSD). Вот пример такого использования на основе моих тестов.

Вариант удлинения стека меток при помощи BSID

Перефразируя Булгакова: «Тем, кто хорошо знаком с ~~пятым измерением~~ Binding SID, ничего не стоит ~~раздвинуть помещение~~ увеличить глубину стека меток до желательных пределов».

Сравнение SR Policy и RSVP-TE

Достаточно сложно сравнивать такие различные технологии, тем не менее, я попытаюсь.

Функциональность	RSVP‑TE	SR Policy
Необходимость специального протокола для сигнализации LSP	Да, RSVP	Нет
Наличие forwarding (soft) state на промежуточных (Р) маршрутизаторах	Да, количество состояний пропорционально количеству LSP	Нет
Наличие встроенного механизма (протокола) для резервирования полосы	Да, RSVP	Нет, РСЕ должен отвечать за это
Необходимость поддерживать forwarding (soft) state на промежуточных (Р) маршрутизаторах	Да, необходим обмен Path/Resv сообщениями (либо поддержка Refresh Reduction)	Нет
Поддерживаемый тип ТЕ	Распределённый, централизованный	Распределённый, централизованный
Тип LSP	Симплексный, точка‑точка	Симплексный, иерархический N Segment Lists → N Candidate Paths→ N SR Policies
Междоменный LSP	Да, с определёнными сложностями	Да, существенно легче организуемый
Поддержка Stateful РСЕ	Да	Да
Протокол для взаимодействия с РСЕ	Только РСЕР	PCEP+BGP+Netconf
Встроенная поддержка балансировки трафика	Нет	Да (ECMP/wECMP)
Возможность расширять глубину стека меток	Нет	Да, с помощью BSID
Поддержка защиты	Да: HSB, защита линка и узла	Да: резервные SL, резервные СР
Управляемость и контролируемость	Сложная	Более лёгкая
Развитие технологии вендорами	Нет	Да, очень активно
Поддержка вендорами	Все основные вендоры	BGP для SR‑MPLS: Все основные вендоры PCEP для SR‑MPLS: три из четырех. Для SRv6 — надо тестировать.

Выводы делайте сами.

Quo vadis или камо грядеши?

В заключение постараюсь кратко обрисовать основные на момент написания статьи тенденции в развитии ТЕ и связанных технологий на основе обсуждений в IETF. На каких вопросах фокусируется экспертное сообщество:

Развитие и стандартизация технологии сетевых слайсов (network slicing).
Развитие Yang‑моделей (например, для ТЕ).
Дальнейшее развитие РСЕР (SR, SRv6, BIER, SR Policy, PCECC).
Segment Routing — Path Segment (новый интересный вариант SID), развитие SRv6 (в т.ч. компрессия SRH), Yang модели для SR, использование STAMP для мониторинга производительности LSP (PM).
Interdomain Routing — SR Policy, BGP Classful Transport (это решение продвигается одним известным вендором), использование Flowspec, Yang модель для BGP, BGP Color‑Aware Routing, развитие BGP‑LS, формализация PIC.
MPLS: попытки придать MPLS новую жизнь в одноимённой рабочей группе при помощи MPLS Network Actions (специальные метки для метаинформации).
IGP: оптимизация flooding, Yang‑модели, Flexible Algorithms.

Подводя итог: идёт нормальная работа по оптимизации и доведения до стабильно работающего состояния имеющихся технологий, появляется что‑то новое типа BGP‑CT, сетевых слайсов и т. д. Видимо достаточно скоро встанет вопрос с использованием AI.

На этом позвольте закончить, если найдёте приведенную здесь информацию полезной, я буду очень рад.

Эволюция Traffic Engineering-3. Жизнь после MPLS