Кратко

  • RFC 3446 дал нескольким активным PIM-SM RP один Anycast-адрес, направляя источники и получателей к топологически ближайшему экземпляру.
  • MSDP-сеансы, router ID и происхождение/RPF Source-Active требовали уникального unicast; ближайший маршрут не доказывал синхронизацию или доставку.

Одна активная привязка превращала расстояние в цену

RFC 2362 позволял настроить несколько RP, но активной оставалась одна привязка группы. Она концентрировала декапсуляцию Register, замедляла переключение и тянула трафик далеко. RFC 3446 приводил пример европейских участников, чьи данные шли через RP в США и обратно.

Разделить 224.0.0.0/4 между RP можно было лишь зная будущую нагрузку и постоянно меняя конфигурацию. Равные диапазоны не означали равную работу.

Informational-документ вышел в январе 2003 года. Его текст, RFC Editor, Datatracker, история, ссылки, цитирования и опечатки подтверждают описание, но не результат конкретной сети.

Общая дверь выбирала, а не синхронизировала

Все RP получали один Anycast-адрес на логическом интерфейсе и объявляли /32 в IGP. Register и Join шли по ближайшему маршруту. Но привязки групп должны были совпадать, а остальные маршрутизаторы учили их статически, через Auto-RP или bootstrap из RFC 5059. Адрес не синхронизировал конфигурацию.

Активные источники распространялись через MSDP, позднее описанный в RFC 3618. MBGP не требовался, MSDP требовался. Концы его пиринга использовали уникальный unicast.

Anycast нельзя было выбирать router ID: соседство могло не подняться. Нельзя было указывать его как RP в Source-Active: peer-RPF отвергал сообщение. Внешняя идентичность отвечала «какой экземпляр ближе?», внутренняя — «какой конкретный пир создал состояние?». Первая скрывала реплику, вторая сохраняла происхождение.

MSDP также создавал состояние (S,G) на пути к источнику. Нестабильность unicast меняла обслуживающий RP под неизменным именем. Целостность маршрутизации, PIM и MSDP оставалась разными задачами.

RFC 4601 и RFC 7761 пересмотрели PIM-SM; RFC 4610 предложил PIM Anycast-RP, а RFC 4786 общую практику Anycast. Это контекст, не единственная причина. IANA регистрирует multicast-адреса и параметры PIM, а не доставку.

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

Клиенту нужно имя, скрывающее реплику; репликам — имена, различающие их. Универсальное имя стирает происхождение, нужное координации.

Источники