Теоретические основы и архитектура
Урок продолжает модуль Segment Routing: вы уже умеете строить SR Policy с явным списком меток и защищать линки TI-LFA. Здесь вы переходите от одной политики к управляемой системе путей. Политика идентифицируется парой color и endpoint, внутри неё несколько candidate path с preference, и активным становится лучший действительный. On-Demand Next-hop создаёт политику автоматически, когда приходит BGP-маршрут с нужным color, а Automated Steering направляет в неё трафик без ручных маршрутов. Binding SID превращает политику в одну метку, которую можно использовать для сжатия стека и стыковки доменов. Для сложных расчётов подключают PCE: PCEP передаёт делегированные пути, BGP-LS поставляет топологию. Вы разберёте, когда путь считает headend, а когда PCE, и что происходит, когда PCE недоступен.
Модель SR Policy: что именно хранит headend
Базовый SR Policy вы уже строили в уроке про SR Policy и TI-LFA: один explicit список меток и steering по color. В этом уроке - полная модель RFC 9256. Политика однозначно задаётся тройкой (headend, color, endpoint). Color - 32-битное число, смысл которого оператор определяет сам (например, 100 - минимальная задержка, 200 - критичный VRF, 300 - bulk); endpoint - адрес egress-узла. Внутри политики лежит один или несколько candidate path. Каждый путь имеет preference (больше - лучше), protocol-origin (PCEP 10, BGP SR Policy 20, локальная конфигурация 30), originator и discriminator. Активным выбирается действительный путь: сначала сравнивается preference, при равенстве - protocol-origin (больше лучше), затем originator (меньше лучше) и discriminator (больше лучше). Путь действителен, если разрешим первый SID списка; политика действительна, пока действителен хотя бы один путь. Внутри пути может быть несколько segment list с весами: так получается ECMP или UCMP между списками.
Explicit и dynamic пути
Explicit путь - список SID, заданный вручную или контроллером; headend лишь проверяет, что первый сегмент резолвится. Dynamic путь описывается целью и ограничениями, а список SID вычисляет сам headend (или PCE). Цель оптимизации: минимальная IGP-метрика, минимальная TE-метрика или минимальная задержка (если IGP анонсирует измеренную задержку линка). Ограничения: affinity (exclude-any, include-any, include-all по битам admin group), SRLG, максимальное число меток в стеке, дизъюнктность с другой политикой (group-id, тип link, node или SRLG). Расчёт - constrained SPF на TED, который IGP заполняет расширениями SR и TE (TE-метрика, affinity, задержка, MSD). Результат - строгий путь, который сжимается в SID list: Node-SID для участков, где кратчайший путь совпадает с нужным, и Adj-SID там, где нужно «выбрать» линк. Длина списка ограничена MSD (maximum SID depth) ingress-узла, которое узел сообщает в IGP и в PCEP.
Color + endpoint, ODN и Automated Steering
BGP-маршрут получает расширенное community Color (RFC 9012). Automated Steering (AS) работает так: если на headend есть действительная политика (color, endpoint), совпадающая с color маршрута и его next hop, маршрут резолвится через политику; иначе остаётся резолв через IGP. ODN (On-Demand Next-hop) снимает необходимость вручную создавать политику для каждого PE: оператор задаёт шаблон on-demand для color 200 (способ расчёта и ограничения), и политика (200, next hop) создаётся при появлении первого маршрута с таким color и next hop. Когда маршрутов не остаётся, политика удаляется по таймеру. Важные детали: color должен совпасть точно (если нет color-only steering по RFC 9256), шаблон не создаёт путей для маршрутов без color, а число создаваемых политик растёт с числом PE, поэтому ODN планируют вместе с лимитами платформы. Per-destination steering выбирает политику по BGP-маршруту; per-flow steering классифицирует трафик на ingress (DSCP или ACL) в класс пересылки, и каждый класс получает свою политику; его реализация и ограничения зависят от платформы. Трафик IGP-префиксов в политику направляют отдельным механизмом (autoroute или static), он не является AS.
Binding SID
Binding SID (BSID) - локальная метка headend, при получении которой узел вставляет стек SID политики. Он нужен в трёх случаях. Первый: сжатие стека - узел с малым MSD вставляет один BSID политики, а длинный стек добавляет промежуточный узел. Второй: стыковка доменов и ASBR - сегмент пути между доменами скрыт за одной меткой, топология внутри не раскрывается. Третий: стабильный интерфейс для контроллера и сервисов - внутренние SID можно менять, BSID остаётся прежним. BSID берут из SRLB (у Cisco по умолчанию 15000-15999) или назначают динамически; при динамическом назначении значение меняется при пересоздании политики, поэтому для внешнего использования его фиксируют. Типичные ошибки: два экземпляра с одинаковым BSID на узле, BSID вне SRLB, забытый отзыв BSID в контроллере после удаления политики.
PCE, PCEP и BGP-LS
PCE (Path Computation Element) считает путь для PCC (Path Computation Client, обычно headend). PCEP (RFC 5440) работает поверх TCP 4189: Open, Keepalive, PCReq, PCRep, PCNtf, PCErr, Close. Stateful-расширение (RFC 8231) добавляет PCRpt (PCC сообщает состояние пути) и PCUpd (PCE меняет путь), RFC 8281 - PCInitiate (PCE создаёт путь сам). Расширения для SR описаны в RFC 8664: SR-ERO с типами SID, возможность SR и MSD в Open. Пассивный PCE считает по запросу; активный stateful PCE получает делегирование и может сам менять путь после изменения топологии. Топологию PCE получает по BGP-LS (RFC 7752, обновлён RFC 9552): узлы, линки и префиксы IGP упаковываются в NLRI AFI 16388 SAFI 71, а SR-атрибуты передаются расширениями RFC 9085. Обычно выбирают один-два IGP-узла на домен, которые экспортируют TED в BGP-LS на RR или напрямую на PCE.
