Кратко

  • В draft-ietf-pim-multicast-over-srv6-01 multicast распределяется нативным IPv6-механизмом: PIM или контроллер создаёт (S,G)/(*,G), вход RPF и набор выходов, а не SID-список ветвей.
  • Flex-Algo влияет на unicast-маршрут, из которого PIM выводит RPF. RFC 9502 требует раздельно объявлять участие IP data plane и участие SR.
  • Приёмка должна отдельно проверить анонс источника, FAD и участников, RPF, владельца и применение записи, overlay-связь, репликацию по ветвям и результат у получателя.

Рассинхронизация начинается с правильных решений

Представим, что ограничение Flex-Algo исключило перегруженный линк. IGP быстро пересчитал unicast-путь к источнику. Для PIM это означает новый RPF-интерфейс. Но Join/Prune ещё распространяется, и трафик продолжает приходить по прежней ветви. Каждая подсистема действует по своей спецификации, однако вместе они на короткое время дают потерю.

PIM-SM строит upstream именно от unicast-вопроса: через какой интерфейс маршрутизатор пошёл бы к источнику? Черновик позволяет анонсировать адрес источника в Flex-Algo 128 и тем самым использовать ограниченный IP-путь. Это не превращает multicast-пакет в SR-пакет; алгоритм лишь меняет линейку, которой измеряется обратный путь.

RFC 9350 определяет FAD через тип вычисления, метрику и ограничения. Совпадение номера без совпадения определения недостаточно, а неподдерживаемое определение может вывести узел из алгоритма. RFC 9502 проводит ещё более важную границу: IP Flex-Algo является самостоятельным data plane, участие в нём объявляется отдельно от SR-MPLS или SRv6.

Следовательно, здоровое участие в SR для FA128 не доказывает участие в IP FA128, которое нужно RPF. Операционный экран обязан показывать data plane, версию FAD, состав участников и фактический RPF, а не одну общую метку.

SRv6 — контекст сети, но не формат дерева

Архитектура Segment Routing описывает source routing для unicast и оставляет применение концепции к multicast вне области документа. SRv6 Network Programming задаёт поведения для пакетов с SR-инструкциями. Текст версии 01, его HTML и XML выбирают иной путь: multicast ортогонален SR и использует нативные возможности IPv6.

Живая запись содержит источник, группу, входной RPF-интерфейс и список выходных интерфейсов. В ней нет упорядоченного набора SID для каждой развилки. Поэтому «multicast в сети SRv6» может быть точной формулировкой, тогда как «segment-routed multicast-дерево» — уже не подтверждённый вывод.

Контроллер добавляет владельца, а не новый data plane

Черновик допускает централизованный расчёт и установку нативных IPv6 multicast-записей. Это позволяет строить специализированные деревья, но на каждом маршрутизаторе всё равно нужен правильный вход и набор выходов. Успех API подтверждает приём намерения; он не подтверждает программирование ASIC на всех ветвях и не является тестом доставки.

PIM и контроллер могут сосуществовать, если обслуживают разные источники и группы. Условие определяет право собственности. При пересечении на одном (S,G) PIM может состарить централизованную запись, а reconciliation контроллера — перезаписать распределённую. Детальная northbound-инсталляция отнесена к дополняющему документу, поэтому авторизацию, межузловую атомарность и rollback этот текст не гарантирует.

В телеметрии нужны владелец, версия намерения, результат каждого узла и readback forwarding plane. Иначе два исправных control plane способны совместно создать неверную запись.

Overlay требует ещё одной сверки идентичности

Архитектура MVPN и процедуры BGP MVPN отделяют клиентское multicast-состояние от туннеля провайдера. RFC 6515 разрешает IPv4- или IPv6-адреса инфраструктуры, RFC 7716 охватывает Global Table Multicast, RFC 8950 допускает IPv6 next hop для IPv4 NLRI.

В примере черновика PIM-SSM создаёт нативное IPv6-дерево провайдера, MP-BGP передаёт PMSI и клиентские маршруты, а пакет клиента идёт как IP-in-IPv6. Next Header 4 означает внутренний IPv4, 41 — IPv6. Поле не доказывает правильный VPN, список получателей, декapsulation и все копии. Специальной SRv6-процедуры для этого overlay черновик не требует.

Проверка должна связать клиентский поток, PMSI, провайдерский (S,G), счётчики ветвей, выходной PE и разрешённого получателя. Нужна и отрицательная сторона: другой VPN и неучастник не должны видеть поток.

Новая дата не создаёт новых эксплуатационных данных

Замороженные Datatracker API, страница и история показывают активный Internet-Draft рабочей группы PIM. Заголовок называет предполагаемый статус Informational; ответственный AD, shepherd и telechat не указаны. Это не RFC, не перепись внедрений, не interop-тест и не измерение производительности.

Замороженное сравнение с версией 00 обнаружило лишь дату, срок, номер версии и колонтитулы. Технический механизм не изменился. Фраза об отсутствии новых security issues поверх ссылочных спецификаций ограничивает область, но не аутентифицирует запись контроллера, не проверяет FAD и не подтверждает PMSI.

Источники и пределы

Корпус включает 01 TXT, HTML, XML, 00 TXT, API, status и history. Контекст дают RFC 7761, RFC 6513, RFC 6514, RFC 6515, RFC 7716, RFC 8402, RFC 8950, RFC 9350, RFC 9502, RFC 8986. Ни один источник не даёт именованного внедрения, матрицы поставщика, времени сходимости, потерь или SLA.