Кратко

  • draft-ietf-bier-source-protection-11 описывает случай, когда путь от резервного BFIR к выбранному BFIR обрывается, а пути выбранного BFIR к BFER остаются рабочими. Перехват роли тогда не нужен и способен породить дубликаты.
  • Обратный Ping тоже не представляет прямой multicast автоматически. Без совместной трассы он может не пройти при исправной услуге или пройти при повреждённом сервисном пути.
  • Идентичность наблюдения, результат детектора, режим резерва, полномочие переключения, потери или дубликаты, приём и результат приложения требуют отдельных квитанций. Ревизия 11 остаётся Informational Internet-Draft.

Резервный маршрутизатор знал один достоверный факт: по сессии наблюдения перестали приходить ожидаемые пакеты. Контроллер дописал к нему ещё три: основной узел умер, все получатели потеряли поток, резерву пора передавать.

Основной узел продолжал работать. Его пути к получателям тоже. Разорвалась лишь боковая связь между двумя входами. Когда резерв начал передачу, один поток получил два источника. Автоматика точно описала собственную слепоту и ошибочно назвала её отказом услуги.

Именно эту границу раскрывает ревизия 11 проекта о резервном входе BIER. Важен не только выбор между BFD и Ping. Важно, какая наблюдаемая поверхность даёт право менять другую поверхность.

В одной схеме несколько направленных путей

По RFC 8279 BFIR вводит пакет в домен BIER, а BFER получают его; ядро пересылает по BitString без multicast-состояния для каждого потока. При этом BFER всё равно выбирает upstream multicast hop. Overlay распространяет сведения выбора, BIER transport переносит пакеты.

Проект называет выбранный вход S-BFIR, альтернативный — B-BFIR. Разные BFER могут выбирать разные входы, а две входные точки — обслуживать разные подмножества. Фраза «основной отказал» без имени потока и получателей слишком груба.

Нужно сохранить как минимум три направления:

  1. B-BFIR → S-BFIR, где резерв наблюдает выбранный вход;
  2. S-BFIR → каждый BFER, где идёт защищаемая услуга;
  3. BFER → S-BFIR, где может идти обратный Ping.

Эти пути иногда совпадают по ссылкам, но предполагать это нельзя. Разрыв первого доказывает потерю наблюдения на нём. Он не доказывает гибель узла или отказ второго пути.

В примере warm standby BFIR2 теряет связь с BFIR1, считает BFIR1 отказавшим и принимает роль S-BFIR. Между тем BFIR1 по-прежнему достигает всех или части BFER. Проект прямо называет переключение ненужным и указывает результат: дублирование пакетов в сети и у BFER.

Возможна и противоположная ошибка. Связь между входами здорова, но путь BFIR1 к отдельному BFER повреждён. Зелёный индикатор наблюдения не равен зелёному состоянию услуги.

У Down должен оставаться субъект

RFC 5880 задаёт BFD для конкретного forwarding path. RFC 8562 расширяет его на multipoint. BIER BFD revision 12 добавляет bootstrap и active-tail notification. Скорость не расширяет область доказательства.

Записанное состояние Допустимый вывод Недопустимое расширение
BFD Down между резервом и выбранным Эта сессия пересекла порог Все пути к BFER отказали
Нет ответа на обратный Ping Этот probe не завершился Прямой multicast остановился
Tail превысил Detection Time Он не видел ожидаемый контроль Поток потеряли все получатели
BFER выбрал новый UMH Выбор изменился для него и потока Приложение восстановилось
Резерв начал отправку Возник второй источник Все дубликаты отфильтрованы

Квитанция должна хранить направление, концы, поддомен, обработку пакета, entropy или path selection, discriminator, интервал, порог и класс трафика. Один Down лишает событие объекта.

Обратный Ping ошибается и при провале, и при успехе

BFER может послать Ping к BFIR1 и после нескольких пропущенных ответов признать его failed UMH. Но защищаемый multicast идёт от BFIR1 к BFER, а запрос — в обратную сторону.

При асимметричной маршрутизации пути расходятся. Проект фиксирует обе ошибки: Ping не проходит, хотя multicast работает; Ping проходит, хотя прямой путь повреждён. Поэтому запрос следует co-route с наблюдаемым прямым путём.

Совместная трасса не доказывает delivery приложения. Она лишь делает сетевую пробу более репрезентативной. Полнота, порядок и отсутствие дубликатов требуют данных от BFER и приложения.

Cold, warm и hot распределяют не только время

Общий проект резервного multicast ingress описывает три режима.

Cold standby запрашивает поток у альтернативы после решения получателя. Постоянных дубликатов нет, но signaling и convergence могут терять пакеты.

Warm standby заранее сообщает запрос выбранному и резерву, хотя обычно передаёт только выбранный. Резерв запускается быстрее, но может получить право судить о receiver path, которого не наблюдает.

Hot standby передаёт с обоих входов, а BFER отбрасывает невыбранную копию. Перерыв короче, но двойная полоса и корректная фильтрация становятся постоянной ценой.

Это не лестница зрелости. Режимы перекладывают потери, полосу, синхронизацию состояния, власть детектора и фильтрацию на разных участников. Требование «самый быстрый failover» не описывает, кто платит и кто вправе ошибиться.

У разных BFER может быть разное настоящее

Разным BFER разрешено выбирать разные S-BFIR и использовать разные timeout. Один уже перешёл на BFIR2, другой остаётся на BFIR1, третий ещё ждёт Detection Time. Глобальный primary_failed стирает эту картину.

Минимальный ключ решения содержит flow, BFER или группу, S-BFIR, observation path, detector, threshold и предыдущую версию состояния. Затем control receipt отделяется от effect receipt: кто изменил UMH и по какому правилу; когда реально начал BFIR2 и прекратил BFIR1; сколько было loss, duplicate и reorder; какой источник принял каждый BFER; что увидело приложение.

Один пакет от BFIR2 доказывает только единичную доставку, но не остановку BFIR1 и не сходимость всех получателей.

Рабочий проект не равен эксплуатационному отчёту

Revision 11 — документ рабочей группы BIER от 1 октября 2026 года с предполагаемым Informational status. Это не RFC; он не запрашивает IANA allocation. Security Considerations отсылают к BIER, multipoint BFD, MVPN failover, BIER Ping и BIER BFD.

Текст доказывает, что mismatch путей, ложные результаты и ненужный перехват признаны проблемой дизайна. Он не доказывает реализацию поставщика, interoperability, внедрение или восстановление реального сервиса.

Reality Layers Лу Хэна привязывает символическое состояние детектора к физической поверхности, которую он измерил. Policy Mirror требует назвать действующее лицо, правило, область и последствие там, где сигнал меняет topology.

Квитанция failover

Сохраняйте flow identity; S-BFIR/B-BFIR; множество BFER; standby mode; overlay и прежний выбор; detector/session; направленный observation path; доказательство одинаковой обработки probe и flow; timer, threshold и пропущенные пакеты; уполномоченного актора; старый и новый UMH; фактический старт и остановку источников; loss/duplicate/reorder counters; состояние приёма; результат приложения.

Если co-routing не доказан, пишите эквивалентность_пути_не_проверена. Если резерв не видит receiver path, пишите путь_получателя_неизвестен. Названное незнание ограничивает действие; скрытое незнание получает лишнюю власть.

Источники