Кратко

  • Маршруты автоматического обнаружения MVPN и EVPN добавляют или удаляют выходной PE из множества Leaf политики SR P2MP; затем контроллер отдельно рассчитывает и создаёт экземпляр дерева.
  • Доказательство доставки должно соединять одну генерацию PTI с программированием узлов, Tree-SID, идентичностью сервиса, split horizon, счётчиками ветвей и наблюдением получателя.
  • Hooman Bidgoli — один из пяти указанных авторов RFC 10018. Открытые источники подтверждают вклад в коллективную спецификацию, но не единоличное авторство или контроль промышленной сети.

В журнале изменений можно увидеть безупречную последовательность: новый выходной PE появился как Leaf, число участников увеличилось, запрос к контроллеру завершился успешно. Если остановиться на этой строке, multicast-сервис кажется введённым в эксплуатацию.

Однако получатель находится по другую сторону нескольких независимых переходов. Контроллер должен рассчитать допустимое дерево. Каждый узел должен получить правильное поколение сегментов репликации. Выходной PE должен снять Tree-SID и выбрать нужный VPN-контекст. Приложение должно принять поток без недопустимых потерь и дублей. Запись о первом переходе не наблюдает остальные.

RFC 10018 был опубликован в августе 2026 года как документ IETF Standards Track. Его редакторы — Rishabh Parekh и Daniel Voyer; среди авторов также указаны Clarence Filsfils, Hooman Bidgoli и Zhaohui Zhang. Документ описывает расширения MVPN и EVPN для деревьев Segment Routing P2MP и ingress replication. Он особенно полезен там, где оператор не смешивает связанные, но разные состояния.

Auto-discovery сообщает о намерении включить узел

В SR P2MP Policy есть Root, множество Leaf и один или несколько candidate paths. Кандидат может содержать ограничения или цель оптимизации и иметь ноль либо несколько P2MP tree instances. Желаемое членство, вариант политики и созданное дерево с самого начала представлены отдельными сущностями.

Когда входной PE импортирует маршрут автоматического обнаружения от выходного PE, он узнаёт этот PE как Leaf соответствующего P-tunnel и добавляет его в политику. Withdrawal удаляет участника. На стороне выхода маршрут связывается с нужным MVPN- или EVPN-сервисом, а модуль политики получает сигнал о присоединении в роли Leaf или Bud.

Механизм даёт проверяемую историю. Можно установить источник объявления, время импорта, затронутую политику и момент withdrawal. Если маршрут отсутствовал, это объясняет, почему получатель не попал даже в предполагаемое дерево.

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

Контроллер должен назвать поколение результата

Получив Leaf-множество, candidate path, ограничения и цель, контроллер рассчитывает P2MP tree instance. Он соединяет replication segments на Root, промежуточных узлах и Leaves. Каким протоколом они устанавливаются — BGP, PCEP, NETCONF или иным, — RFC 10018 не определяет.

Граница спецификации становится границей контроля. Обновление членства могло попасть в очередь, но ещё не быть рассчитано. Контроллер может отвергнуть невыполнимое ограничение. Southbound-транзакция может пройти на большинстве устройств и оставить одно со старой версией. Успешный ответ интерфейса может предшествовать активации в аппаратуре.

Поэтому аудируемая единица — идентифицированная генерация. Следует сохранять candidate-path ID, хеш Leaf-множества, ограничения, цель, запрос контроллеру, идентичность рассчитанного PTI и acknowledgement каждого узла. Слово «success» без этой связи невозможно сопоставить с трафиком.

Смежные стандарты сохраняют разделение. RFC 9960 задаёт структуру политики; RFC 9524 — роли Root, Bud, Leaf и промежуточного узла репликации; RFC 9961 — ping и traceroute для MPLS SR P2MP Policy. Политика, установленное состояние и OAM дополняют друг друга, а не заменяют.

Tree-SID не заменяет контекст сервиса

Созданный экземпляр получает Tree-SID. Root помещает payload в дерево, узлы провайдера создают копии по установленным ветвям, Leaf снимает Tree-SID и передаёт содержимое в контекст MVPN или EVPN.

Для выделенного дерева идентификатора иногда достаточно, чтобы восстановить сервис. В shared tree один P-tunnel обслуживает несколько VPN, поэтому дополнительный service label, SRv6 service SID или argument различает клиентов. Пакет способен пройти правильное дерево и оказаться в неправильной таблице.

EVPN multihoming требует split horizon. Он не даёт BUM-трафику вернуться через тот же Ethernet Segment и создать дубликат. Корректное Leaf-множество не подтверждает корректную обработку ESI. Две копии у получателя остаются отказом, даже если схема членства безупречна.

В записи следует соединить Tree-SID, service label или SID, Ethernet Segment, split-horizon value, входной PE и egress lookup. Число Leaves не позволяет достоверно вывести ни одно из этих значений.

Ingress replication меняет поверхность отказа

RFC 10018 охватывает и ingress replication. Входной PE создаёт отдельную копию для каждого выходного PE и отправляет её по пути SR-MPLS или SRv6. Модуль SR P2MP Policy и контроллер участвуют иначе, чем при общем дереве.

Клиентский результат может выглядеть одинаково, но причины отказа различны. Для дерева критичны единая генерация и промежуточные репликаторы. Для ingress replication важны число копий у источника и unicast-достижимость каждого выхода. Поле «multicast включён» стирает различие, нужное дежурной смене.

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

Получатель завершает цепочку доказательств

На Root считают принятые клиентские пакеты и пакеты, помещённые в конкретный Tree-SID или набор ingress-копий. На узлах сохраняют вход, реплицированные выходы и drops для того же поколения. На Leaf фиксируют decapsulation и выбор сервисного контекста. На границе получателя измеряют ожидаемую последовательность, потери, дубликаты, порядок, задержку и полезное потребление.

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

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

Что открытые записи говорят о Hooman Bidgoli

Профиль IETF Datatracker, зафиксированный 1 сентября 2026 года, перечисляет семь RFC, связанных с Hooman Bidgoli. Среди них RFC 9524 о SR-репликации, RFC 9960 о P2MP Policy, RFC 9961 об OAM и RFC 10018. Последний указывает его аффилиацию с Nokia в Ottawa. Официальная страница спикеров Nokia SReXperts на дату сохранения описывала опыт в IP/MPLS, multicast и безопасности маршрутизаторов.

Эта последовательность делает его участие релевантным сразу нескольким уровням системы. Она не подтверждает исключительное изобретательство, владение консенсусом IETF или эксплуатацию конкретного сервиса. RFC 10018 подписан пятью авторами и опирается на более ранние работы MVPN, EVPN и Segment Routing.

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

Квитанция multicast должна быть операцией join

Для каждого изменения сохраняются сервис и tenant, режим доставки, Root, импортированные маршруты, роли Leaf или Bud, candidate path, ограничения и цель. К ним добавляются запрос контроллеру, поколение PTI и подтверждения replication segments от каждого устройства.

Затем Tree-SID соединяется с service label или SID, Ethernet Segment, split horizon и egress lookup. Цепочку закрывают принятые пакеты, созданные копии, drops ветвей, Leaf decapsulation, OAM, результаты получателя и время alarms. При withdrawal сохраняются инициатор, сроки очистки и доказательство прекращения остаточного трафика.

Такой подход не делает multicast простым. Он делает расхождение локализуемым. Leaf-множество остаётся точным описанием предполагаемого членства. Доставка остаётся отдельным утверждением, которое подтверждают только последующие согласованные записи.

Источники