Кратко

  • Редакция -12 проекта draft-ietf-bier-bfd находится на этапе WG Last Call и пока не является RFC. Для BIER она прямо опирает инициативное сообщение активного получателя на механизм RFC 9780, отличая его от запрашиваемых процедур RFC 8563. Раздел о незапрошенных сообщениях был и в редакции -11, поэтому речь не о первом появлении самой идеи.
  • При обнаружении потери непрерывности BFER отправляет BFIR пакет BFD по одноадресному пути, отделённому от дерева рассылки, и указывает идентификатор отказавшей P2MP-сессии. Ответ Final завершает обмен извещениями, но сам по себе не удостоверяет, что прежний путь снова работает.

Нулевое число тревог у отправителя легко принять за нулевое число отказов. Для дерева BIER такая арифметика опасна. Входной маршрутизатор BFIR рассылает контрольные пакеты BFD, а каждый выходной BFER самостоятельно следит за их поступлением. Если одна ветвь пропала, первым об этом знает её получатель. Чтобы это стало знанием источника, нужно доставить отдельное сообщение, распознать сессию и получить ответ.

Обновлённый 29 сентября проект формулирует эту цепочку гораздо предметнее. Datatracker IETF показывает действующий Internet-Draft рабочей группы BIER, находящийся в WG Last Call, со статусом IESG I-D Exists. Отсюда нельзя выводить, что процедура уже стандартизована, внедрена у операторов или сопровождала измеренный инцидент. Это текст о предлагаемом применении BFD «точка — множество точек» в BIER.

RFC 8562 описывает контроль непрерывности от головы дерева к его концам. Он позволяет концу заметить отсутствие пакетов, но не превращает такое наблюдение в сведения головы о состоянии конкретного получателя. Раздел 6 редакции -12 выбирает для BIER инициативное извещение активного конца по RFC 9780 и противопоставляет его запрашиваемым способам RFC 8563. Важна точность сравнения: редакция -11 уже содержала подраздел о незапрошенном уведомлении, а в RFC 8563 тоже есть упоминание незапрошенных пакетов. Новая редакция яснее закрепляет опорный механизм и обязательные параметры обмена.

При отказе BFER должен установить бит Poll, состояние Down и диагностическое значение Control Detection Time Expired. В поле Your Discriminator переносится My Discriminator неработающей P2MP-сессии. Пакет адресуется BFIR по IP/UDP с портом назначения 4784. Обратный одноадресный маршрут должен быть независим от дерева многоадресной доставки: отправить тревогу по потенциально повреждённой ветви было бы недостаточно.

Текст требует посылать один пакет в секунду, пока не получен корректный для этой сессии ответ с битом Final либо пока дефект не исчезнет. Для повышения вероятности доставки рекомендованы также три пакета с псевдослучайными промежутками в пределах секунды. У BFIR поле Your Discriminator служит ключом выбора сессии; после совпадения он посылает BFER одноадресный пакет BFD с Final. Для пакетов в прямом направлении BFER, напротив, различает сессии по сочетанию BFIR-id и назначенного головой My Discriminator. Поэтому полезный журнал должен связывать сигнал с обоими контекстами, а не только фиксировать слово «тревога».

Совпавшая сессия и ответ Final говорят о прохождении конкретного уведомления. Они не говорят о восстановлении многоадресной доставки. Кроме того, одновременное повреждение многих ветвей может вызвать шквал уведомлений на плоскость управления; проект обсуждает ограничение частоты. Следовательно, молчание центра допускает и иные объяснения, кроме здоровья всех ветвей: например, отказ обратного пути или нехватку пропускной способности для сигналов. Это эксплуатационный вывод из описанного механизма, не статистика отказов.

Ранее опубликованный материал о BIER Ping разбирал диагностические проверки и их прохождение в IETF; здесь предметом служит доставка постоянных аварийных наблюдений.

Источники