Кратко

  • RFC 10018 позволяет объявить SR P2MP P-tunnel как <Root, Tree-ID> и формировать его набор листьев из MVPN- или EVPN-маршрутов A-D. Это ограниченное свидетельство плоскости управления, а не доказательство установки одного полного PTI и получения правильной нагрузки каждым листом.
  • Закрывать работу следует только после сопоставления для одного candidate path и Instance-ID: требуемых выходов, A-D, набора контроллера, установки Replication segment, FIB, OAM и подтверждения нагрузки в верном MVPN/EVI. Удаление требует столь же точного финального следа.

Опасен не красный экран, а убедительный зелёный

Полный отказ дерева заметен. Частичный отказ похож на нормальную работу. Root продолжает отправлять, промежуточные узлы увеличивают счётчики, большинство листьев отвечает. Совокупный трафик почти не меняется. Один выход остаётся без данных, но его ноль растворяется в сумме.

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

RFC 10018 даёт общий способ описать такую службу. Он определяет P-tunnel для MVPN и EVPN, реализованный PTI в SR-MPLS или SRv6, связывает его с PMSI Tunnel Attribute и маршрутами Auto-Discovery, а также описывает отдельный режим ingress replication.

При этом RFC не присваивает объявлению власть над реальным результатом. Конкретная передача candidate path и листьев контроллеру через PCEP, BGP, NETCONF или иной механизм остаётся за границей документа. Значит, этот переход должен иметь собственную телеметрию и собственную ответственность.

У Policy есть постоянное имя, у дерева — версии

PMSI Tunnel Attribute кодирует идентификатор <Root, Tree-ID>. Сначала идёт 32-битный Tree-ID, уникальный в контексте Root, затем IP-адрес Root. IANA закрепила 0x0C за SR-MPLS P2MP Tree и 0x0D за SRv6 P2MP Tree.

Этого достаточно, чтобы независимые реализации ссылались на одну Policy. Но RFC 9960 отдельно определяет candidate paths и P2MP Tree Instances. Candidate может не иметь PTI, если контроллер не способен вычислить дерево с нужными ограничениями. При make-before-break PTI может быть несколько, но активным должен быть один. Две активные инстанции способны доставлять дубликаты.

Каждый PTI имеет 16-битный Instance-ID. Его Replication segments в плоскости управления привязаны к Root, Tree-ID, Instance-ID и Node-ID. Поэтому один <Root, Tree-ID> переживает множество расчётов, топологий и состояний forwarding.

Если мониторинг не хранит Instance-ID, старый ping может «подтвердить» новый PTI. Запоздалый ответ узла попадёт в чужое изменение. После преждевременного повторного использования идентификатора невозможно отличить задержанный пакет от текущего. Постоянное имя Policy не заменяет версию исполнения.

Маршрут листа сообщает о членстве, а не о приёме

В MVPN импорт нужного Intra-AS I-PMSI или Leaf A-D добавляет egress PE в Leaf Set на ingress PE. Withdraw убирает его. Egress PE присоединяется как Leaf или Bud после импорта объявления Root и обязан породить Leaf A-D, если выставлен Leaf Information Required.

В EVPN соответствующий жизненный цикл строится на IMET, S-PMSI и Leaf A-D. Это важное свойство: членство получает наблюдаемое начало и конец.

Но BGP-событие не устанавливает автоматически всю цепочку данных. Модуль MVPN/EVPN создаёт candidate, меняет Leaf Set и передаёт его модулю SR P2MP Policy; тот сообщает контроллеру. RFC 10018 не определяет транзакцию до каждого узла.

Поэтому одновременно существуют как минимум три множества: выходы, требуемые службой; выходы, видимые в A-D; листья, принятые текущей ревизией контроллера. Они могут иметь одинаковый размер и разный состав. Новый лист уже виден в BGP, но отсутствует в расчёте. Старый отозван, но ещё остаётся в PTI.

Нужны состав, ревизия и время. Поле leaf_count не доказывает соответствие. Контроллер должен показывать, какую версию Leaf Set использовал конкретный Instance-ID.

Частичная установка должна быть видимым состоянием

RFC 9960 прямо допускает отказ установки Replication segment, например из-за конфликта SID. Узел должен сообщить успех, а при отказе — желательно причину. Контроллеру следует ограниченно повторить попытки и выдать сигнал при окончательном отказе. Он может разобрать PTI при проблеме некоторых сегментов; при отказе сегмента Root это рекомендуется.

Следовательно, «рассчитано», «запросы отправлены», «частично принято», «полностью принято», «есть в FIB», «активировано на Root» и «проверено по листьям» — разные факты.

RFC 9960 описывает полезный порядок: сначала программируются листья и промежуточные узлы, затем Root. Root становится последним клапаном. Это не доказательство поведения конкретного продукта, а критерий для его проверки.

Контроллер должен раскрывать результат по Node-ID: Replication-SID, требуемую ревизию, подтверждение или отказ, причину, число повторов, терминальное состояние и время. Единый ACTIVE имеет смысл лишь при прозрачном правиле его вычисления.

Правильный путь способен закончиться в неправильном сервисе

Tree-SID — идентификатор PTI в плоскости данных. Root инкапсулирует нагрузку, провайдерские узлы реплицируют, лист снимает Tree-SID и передаёт содержимое. Но контекст MVPN или EVI может задаваться отдельно.

Для дерева, выделенного одной MVPN, Tree-SID может быть достаточен. При совместном использовании нужен upstream-assigned MPLS label или SRv6 Multicast Service SID. RFC 10018 определяет End.DTMC4, End.DTMC6 и End.DTMC46; IANA присвоила им 76, 77 и 78. Для некоторых SRv6-кодировок действуют правила transposition.

Таким образом, пакет может пройти по верному PTI и попасть не в ту MVPN, не выполнить нужный multicast table lookup или использовать неверно собранный service SID.

EVPN добавляет split horizon для multihoming Ethernet Segment. Он предотвращает лишние копии BUM. В SR-MPLS участвует ESI label, в SRv6 — Arg.FE2 с End.DT2M. Сам факт приёма пакета не показывает, должна ли эта копия была быть отфильтрована.

Финальное свидетельство должно называть PTI, лист, MVPN/EVI, service ID, split-horizon state и результат нагрузки. Tree-SID направляет в дерево, но не удостоверяет tenant и не заменяет подтверждение приложения.

Ingress replication требует другого расследования

При ingress replication входной PE создаёт копию для каждого выхода и отправляет её по unicast. Модуль SR P2MP Policy и контроллер не участвуют.

Для IR проверяются членство выхода, service ID, выбранная unicast/SR-TE policy и конкретная копия. Для P2MP — контроллер, PTI, сшитые Replication segments, активная инстанция и OAM дерева.

Отличается и traffic engineering. IR в определённых случаях допускает обработку по egress. В PTI копирование происходит внутри дерева, поэтому ingress задаёт одно обращение для дерева.

Fallback с P2MP на IR должен фиксировать остановку старой Root, начало индивидуальных копий, период перекрытия и удаление PTI. Иначе восстановление может создать незаметные дубликаты.

OAM обязан назвать проверяемую инстанцию

RFC 9961 определяет ping и traceroute для конкретного candidate path и PTI. Probe проходит соответствующие Replication segments и собирает ответы листьев. Желательно уметь отдельно проверять и неактивный PTI.

При make-before-break это отделяет старое дерево от нового. Общие Root и Tree-ID не означают общую топологию. В отчёте нужны Instance-ID, время, ожидаемые листья и ответ каждого.

Для несмежных Replication segments P2MP OAM проверяет структуру репликации, а unicast OAM — соединяющий путь. RFC 9961 не включает обнаружение отказа этого unicast-пути в собственную гарантию.

OAM-ответ ещё не равен рабочей нагрузке. Он не доказывает производственный service SID, допустимую потерю, split horizon или обработку приложением. Нужен canary по каждому листу: последовательность, проверяемая метка содержимого, счётчик в нужном контексте или application acknowledgement, связанный с тем же PTI.

Разности множеств превращают «где-то не работает» в задачу

Полезно вести:

  • E — выходы по обязательству службы;
  • A — выходы в A-D/Leaf A-D;
  • C — листья, принятые контроллером для текущего candidate;
  • I — листья с полной установленной цепочкой сегментов данного PTI;
  • F — листья в актуальном forwarding активной инстанции;
  • O — листья, отвечающие OAM точных candidate и Instance-ID;
  • D — листья с подтверждённой нагрузкой в правильном MVPN/EVI;
  • W — удалённые листья с доказанными withdraw, deprogramming и quiescence.

Строгая служба может требовать E = A = C = I = F = O = D. Разрешённый поднабор должен иметь владельца, причину, влияние, срок и условие восстановления. Удаление завершается только после выхода из активных множеств и входа в W.

E − A указывает на заказ/A-D, A − C — на приём контроллером, C − I — на установку, I − F — на достоверность подтверждения, F − O — на путь, O − D — на контекст или приложение.

Равное количество не означает равные члены. Ответ старого листа не компенсирует отсутствие нового.

Чего не доказывают источники

RFC и реестры подтверждают архитектуру, коды и переходы. Они не доказывают внедрение конкретным оператором, поддержку каждым продуктом, распространённость, актуальную совместимость или реальный инцидент из примера.

Запись IANA — это присвоенное значение, не исполнение. Standards Track не обязывает развёртывать. IETF задаёт общий язык, но не управляет Root оператора.

Это соответствует приоритету работающего кода у Lu Heng: документ не может объявить эффект вопреки наблюдаемой сети. Минимальная начальная спецификация и локальное будущее решение сохраняют за оператором выбор внедрения и риска.

Наблюдаемый факт не всегда желателен. Отозванный лист, который продолжает получать, — реальность и одновременно доказательство незавершённого удаления.

Источники