Кратко

  • Текущий проект LISP multicast говорит: при потере ITR, служившего корнем инкапсуляции, получающие ETR должны построить состояние к новому корню и заново сообщить ему о нужных потоках (S-EID,G).
  • Anycast способен сохранить доступность RLOC и свести изменение underlay к перестройке RPF. Однако ETR может не заметить смену физического узла; тогда преемник узнает состояние получателя лишь из следующего периодического Join/Prune.
  • Daniel Kade предлагает квитанцию преемственности корня и явный долг повторной отправки joins. Это инструменты операционного управления, а не новые поля LISP или PIM.

Зелёный адрес может скрывать молчащее дерево

Представим трансляцию из одного исходного сайта в несколько сетей. Его Ingress Tunnel Router выходит из строя. Маршрутизация переводит общий anycast RLOC на второй ITR. Проверки адреса снова успешны, а multicast-underlay меняет интерфейс обратного пути. Команда routing вправе сказать, что адрес быстро восстановился.

Сервис этим ещё не доказан. Старый ITR знал, какие удалённые ETR присоединились к каким сочетаниям источника и группы. Новая машина способна принимать трафик на тот же RLOC, не располагая этим перечнем. Имя корня осталось, но оперативная память принадлежала исчезнувшему процессу. Пока получающие сайты не повторят намерение, преемник может не знать, какой внутренний поток кому инкапсулировать.

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

draft-ietf-lisp-rfc6831bis-07 — активный документ на стадии IESG Evaluation. Он нацелен на Proposed Standard и в случае утверждения заменит экспериментальный RFC 6831. Редакция 07 опубликована 11 сентября 2026 года. Сравнение с 06 показывает прежде всего нормативные формулировки, обновлённые ссылки IGMP/MLD и редакционное обслуживание. Эта статья анализирует устойчивую границу всей текущей архитектуры, а не приписывает номеру 07 новое устройство failover.

Намерение называется EID, дерево — RLOC

LISP разделяет Endpoint Identifier и Routing Locator. Внутри сайтов источник и получатель имеют дело с EID источника и multicast-группой. Underlay строит маршруты на RLOC. Такое разделение сохраняет идентичность при смене точки подключения, но распределяет multicast-состояние между двумя пространствами имён.

Получатель присоединяется к (S-EID,G) через IGMPv3 или MLDv2. Пограничный ETR ищет EID источника и по приоритету и весу mapping выбирает RLOC исходного ITR. В multicast-underlay ETR посылает два сигнала. Инкапсулированный в unicast PIM Join/Prune доставляет (S-EID,G) выбранному ITR. Другой Join/Prune создаёт (S-RLOC,G) в underlay. Первый объясняет инкапсулятору, какой внутренний поток нужен; второй формирует дерево с корнем-локатором.

В unicast-underlay ITR явно хранит список RLOC получающих ETR и выполняет head-end replication: по внешней копии на назначение. На приёмной стороне ETR снимает заголовок LISP и обращается к внутренней multicast FIB для (S-EID,G), прежде чем передать пакет локальным получателям.

Эти свидетельства нельзя заменять друг другом. Map-Reply указывает locators, но не подтверждает установку потока в физическом экземпляре. Успешный RPF показывает направление underlay, но не знание S-EID у корня. Локальный join может сохраняться, хотя удалённый инкапсулятор о нём забыл. Пакет способен прийти по общему дереву (RLOC,G) и быть отброшен из-за отсутствия соответствующего внутреннего состояния.

Поэтому операционный объект — не одна «multicast-маршрутизация». Это цепь: намерение получателя, пограничное состояние ETR, выбранный физический корень, EID-состояние ITR, репликация в underlay или у источника, принятие ETR и наблюдение конечного получателя. У каждого звена свой владелец и часы.

Смена физического корня создаёт обязательство

Раздел 6 проекта объясняет, почему отказ ITR значительнее обычного события RPF. В unicast локальная достижимость может позволить переключить locator без сложной координации. В LISP multicast выбранный ITR является корнем инкапсуляции дерева. Если он недоступен, присоединившиеся ETR должны создать (S-RLOC,G) к новому корню и передать ему инкапсулированный Join/Prune с нужным (S-EID,G).

У обязательства есть измеримое множество — все затронутые ETR. Есть и предмет — состояния источник-группа, которые они ожидают у преемника. Сайты обнаруживают отказ, делают новый выбор и повторяют Join в разные моменты. Одна отметка «переключение завершено» скрывает это распределение, особенно его медленный хвост.

Anycast делает переход менее заметным. Когда несколько ITR используют один RLOC, маршрутизация переводит адрес, а underlay может увидеть лишь новый интерфейс RPF. Для удалённого ETR адрес не изменился. Может отсутствовать событие, немедленно запускающее повторную unicast-передачу (S-EID,G). Проект прямо говорит: новый anycast ITR иногда получает это состояние только при следующей периодической отправке ETR.

У интервала нет универсальной длины. На него влияют реализация, таймеры PIM, потери, сходимость, политика refresh и режим underlay. Из текста не следует, что каждое переключение обязательно теряет пакеты или укладывается в один срок. Надёжный вывод уже: восстановление адреса и восстановление состояния — разные события.

Долг повторной отправки joins

Я называю долгом повторной отправки joins все намерения получателей, установка которых у нового ITR ещё не доказана. При смене физического корня каждый ETR с неподтверждённым (S-EID,G) становится открытой позицией. Слово «долг» не обвиняет и не обозначает простой счётчик пакетов. Оно не даёт распределённому переходу исчезнуть за одним зелёным индикатором.

Минимальная позиция связывает ETR, S-EID, группу, старый ITR, ожидаемого преемника, поколение последнего join, время refresh, режим underlay и условие закрытия. Если реализация предоставляет подтверждение установки состояния, его можно использовать. Если нет, ограниченную проверку состояния на корне следует связать с наблюдением на ETR или управляемом тестовом получателе.

Успешный ping к anycast RLOC, маршрут в RIB, запись mapping cache, соседство PIM или живой процесс не погашают долг. Ни один сигнал не показывает, что намерение данного получателя попало именно в новый физический экземпляр. Восстановление одного сайта также не подтверждает остальные: их ETR могут ждать других циклов.

Позиция может закрыться из-за законного прекращения спроса. Получатель вышел из группы, источник остановился или политика переместила поток. Запись должна указать основание и полномочие: «установлено и наблюдалось», «явно отозвано», «истекло по объявленному правилу» или «деградация принята названным ответственным». Молчаливое исчезновение не является восстановлением.

Квитанция преемственности корня

Квитанция преемственности корня соединяет эти доказательства. Это предложение Daniel Kade по операционному управлению, а не новое поле в пакетах LISP, PIM, IGMP или MLD. Квитанция не позволяет одной команде закрыть инцидент на основании только своего слоя.

Сначала она фиксирует физические идентификаторы старого и нового ITR, их отдельные или общие RLOC, источник и время обнаружения, уверенность, версию mapping и владельца решения. Один общий адрес недостаточен: предмет проверки — скрытая смена физического экземпляра за ним.

Далее по каждому затронутому охвату записывается контрольный прогресс: последнее известное (S-EID,G) старого корня, новый выбор, сходимость RPF, поколение join на ETR, инкапсулированный повтор и установленное состояние преемника, когда оно наблюдаемо. Точка сбора и источник времени остаются с каждым фактом. Несопоставимые часы нельзя превращать в достоверную причинную последовательность.

Затем фиксируется результат: первый пакет, принятый новым корнем; первый правильный пакет на каждом выборочном ETR; непрерывность последовательности или приложения, если доступна; окно потерь и дублей; нежелательный трафик, отброшенный из-за внутреннего состояния; возраст оставшегося долга. Доказательство на маршрутизаторе нельзя называть здоровьем приложения.

Полномочие на откат входит в ту же квитанцию. Система может позволять вернуть определённый unicast locator, вывести преемника, вызвать контролируемый refresh, переместить поток или временно принять head-end replication. Универсальной команды здесь нет; должны быть явными действие, охват, ответственный и способ проверки.

Вместе с репликацией перемещается доказательство

Проект допускает репликацию внутри сайта, на транзитном маршрутизаторе underlay, на ETR или ITR. Multicast-underlay хранит больше промежуточного состояния. Unicast-underlay переносит цену к копиям и полосе исходного сайта. Приоритеты и веса Map-Reply могут также направлять разные сайты к разным ITR.

Учёт обязан следовать топологии. Список ETR у ITR — план репликации, не квитанция доставки. Здоровое дерево (S-RLOC,G) может объединять несколько внутренних источников. Проект отмечает, что сайт способен получить поток, которого не запрашивал, из-за общего дерева и затем отбросить его при отсутствии (S-EID,G). Решение корректно, но общая полоса уже потрачена.

Здесь пересекаются безопасность и устойчивость. Проект описывает, как вредоносный сайт-получатель может вызвать приход нежелательных данных на легитимные сайты того же дерева. Фраза «пакет достиг ETR» может означать успех, растрату или атаку. Смысл задают внутреннее состояние и ожидаемое множество получателей.

Диагностический пробел остаётся

Подробная locator reachability, некоторые процедуры mPITR и дизайн mtrace для LISP multicast вынесены за рамки проекта. О mtrace сказано, что решение ещё предстоит определить на основе Mtrace Version 2. Поэтому универсальная трассировка не даёт полной картины через пространства EID и RLOC.

Каждая метрика должна называть слой. Проверка underlay показывает путь RLOC; состояние ITR — установку (S-EID,G); счётчики ETR — декапсуляцию и внутренний поиск; получатель — полезное прибытие. Их корреляция может поддержать вывод о сервисе. Подмена всех одним сигналом — нет.

Задача проекта IETF — специфицировать механизм и границы, а не выдать универсальный продукт наблюдаемости. Поэтому оператор обязан точно формулировать выводы. «Anycast-переключение успешно» относится к адресу. Для восстановления multicast нужны также состояние и доказательство у получателя.

Источники

  1. Текущий проект LISP multicast
  2. История проекта
  3. Запись Datatracker API
  4. Редакция 07 в HTML
  5. Текст редакции 07
  6. Сравнение редакций 06 и 07
  7. Рабочая группа LISP
  8. RFC 6831
  9. RFC 9300: плоскость данных LISP
  10. RFC 9301: плоскость управления LISP
  11. RFC 8059: атрибуты PIM Join для LISP
  12. RFC 7761: PIM
  13. RFC 8487: Mtrace Version 2
  14. RFC 9776: IGMPv3
  15. RFC 9777: MLDv2
  16. RFC 7799: терминология измерений
  17. XML редакции 07