Кратко

  • RFC 9960 идентифицирует SR P2MP Policy по Root и Tree-ID и различает листья, кандидатные пути и экземпляры PTI. Эти значения описывают пересылку, а не договорное или институциональное право получателя.
  • RFC 9961 адресует ping и traceroute конкретному PTI внутри кандидатного пути. Документ прямо ограничивает вывод: это не проверка кандидатного пути целиком и не механизм для SRv6.
  • Квитанция аудитории должна связать решение о членстве с Policy, путём, PTI, листьями, поколением контроллера, областью OAM и завершением переключения. Это редакционное предложение Daniel Kade, а не требование IETF.

Дерево отвечает на вопрос «куда», а не «кому положено»

Point-to-multipoint экономит повторную передачу по общим участкам. Один поток выходит из Root и копируется там, где маршруты расходятся. RFC 9960 задаёт архитектуру такой конструкции для SR-MPLS и SRv6.

Policy имеет идентичность <Root, Tree-ID>. В ней перечислены Leaf nodes и кандидатные пути с топологическими или ресурсными ограничениями и целями оптимизации. Контроллер вычисляет P2MP Tree Instances и устанавливает Replication segments, превращая расчёт в работающую пересылку.

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

Аудитория возникает в другой системе: договорах, реестре ролей, tenant-контуре, графике дежурств или ответственном человеческом решении. Автоматизация переводит эту популяцию в адреса и контексты сервиса. Если проекция устарела, безупречное дерево не исправит её. Оно безупречно исполнит старую волю.

Универсальный стандарт не обязан определять клиентов каждой организации. Минимальная общая спецификация оставляет локальные будущие решения локальным владельцам. Но отделение решений требует явной связи между ними.

Под одним Tree-ID сменяется несколько реальностей

Policy может иметь несколько кандидатных путей. Root выбирает активный по правилам RFC 9256. Если ограничения не выполняются, у пути нет PTI. Во время make-before-break может существовать несколько PTI.

Активным должен быть ровно один экземпляр. RFC 9960 предупреждает: несколько одновременно активных PTI активного пути способны доставить листьями дубликаты. Значит, Tree-ID не фиксирует конкретное состояние. Старый и новый экземпляры сохраняют общую Policy, но отличаются Instance-ID и состоянием на промежуточных узлах.

Контроллер может сначала построить новый PTI, затем активировать его и удалить старый. Это снижает потери, однако создаёт период двойного состояния. Если телеметрия хранит только «Policy работает», исчезает ответ, какой экземпляр проверялся, как долго они сосуществовали и перестал ли старый получать трафик.

Один PTI обычно связан с одним многоточечным сервисом, но при различимом service context может обслуживать несколько. Исправность транспорта поэтому не доказывает правильность контекста и аудитории конкретного сервиса.

Контроллер реализует решение, но не обязательно принимает его

Оператор, сетевой узел или машина могут передать контроллеру Root, набор листьев и кандидатные пути. Контроллер вычисляет топологию, назначает Replication-SIDs и устанавливает состояние через PCEP, BGP, NETCONF/YANG или иной механизм. Явное статическое дерево тоже допустимо.

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

Policy Mirror Хэна Лу помогает не спутать уровни. Работающая инфраструктура показывает, кто фактически может заставить пакеты размножаться. Именно поэтому её надо проверять. Но след выполнения не самоподписывает легитимность команды.

Неудачные поколения тоже являются доказательством. Конфликт SID может сорвать установку сегмента. RFC рекомендует сообщать причину, ограничивать повторы и выдавать предупреждение; частичный PTI иногда следует разобрать. Если последний успех перезапишет предыдущий опыт, пропадёт время неполного состояния и факт очистки.

Узкая проверка сильнее общего зелёного статуса

RFC 9961 расширяет ping и traceroute для MPLS SR P2MP Policy. Запрос указывает кандидатный путь и конкретный PTI, включая Root, Tree-ID и Instance-ID. Он проверяет именованный экземпляр вместо неопределённого «multicast».

Спецификация сама очерчивает предел. Sub-TLV проверяет один PTI внутри пути, а не кандидатный путь как абстракцию. Механизм применим к MPLS Replication-SIDs и не охватывает SRv6. Круг ответчиков можно ограничить ради снижения нагрузки.

Успех поддерживает утверждение о выбранном MPLS data plane в определённый момент. Он не доказывает полезную доставку приложению, актуальность договора, корректность списка членов, отсутствие дубликатов при переходе, поведение SRv6 или законность входных данных контроллера.

Эти ограничения не обесценивают OAM. Точный факт можно соединить с решениями и конфигурацией. Безымянный зелёный индикатор такую связь только скрывает.

Что хранит квитанция аудитории

Первая часть находится вне сети: сервис и context, авторитетный источник членства, версия и срок действия, ответственный и исключения. Затем фиксируется соответствие устойчивых локальных субъектов адресам Leaf/Bud, включая добавления, удаления и срок. Повторно выданный адрес не должен наследовать права прежнего владельца.

Техническая часть содержит <Root, Tree-ID>, <Protocol-Origin, Originator, Discriminator> кандидатного пути, ограничения, цель и причину выбора. Для экземпляров нужны старый и новый Instance-ID, точный набор Leaves/Buds, поколения контроллера и конфигурации, распределение SID и результат установки на каждом узле.

Наблюдение называет метод OAM, MPLS-ограничение RFC 9961, целевой PTI, ожидаемых ответчиков, время и результаты. Переход фиксирует порядок активации, интервал сосуществования, наблюдение дубликатов, условие отката и доказательство удаления старого PTI.

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

«Квитанция аудитории» — аналитический термин статьи, а не новый объект RFC и не сертификат IETF.

Удаление требует положительного доказательства

Добавление оставляет цепь успехов: запрос, настройка, установка, ответ. Удаление часто растворяется в отсутствии. Но исключение получателя должно дойти до активных, резервных и частично установленных поколений.

Закрытие отдельно доказывает, что Root больше не направляет трафик в старый PTI, состояния репликации сняты, а исключённые листья не остались в backup. «Неактивный» и «удалённый» — разные состояния.

RFC 9960 также предупреждает о внешней инъекции при слабой защите границы SR domain и о петлях репликации из-за ошибочного контроллера, создающих шторм до исчерпания TTL или Hop Limit. Успешный ответ листа не проверяет эти условия автоматически.

Границы и источники

Источники не подтверждают внедрение названным оператором, неправомерное включение, реальное дублирование, атаку или выигрыш производительности. Они описывают архитектуру и заявленные риски. Оператор может выбрать MPLS, SRv6, статическое дерево, другую OAM или отказаться от P2MP.

Достаточен узкий вывод: Tree-ID идентифицирует транспортную Policy, Instance-ID — её реализацию, RFC 9961 наблюдает конкретный MPLS PTI. Право на получение приходит из другой системы и должно сохраняться рядом с деревом, исполнившим решение.