Кратко

  • RFC 8966, подготовленный Juliusz Chroboczek и David Schinazi, считает вычисление метрики Babel локальной политикой. Бесконечная локальная стоимость должна давать бесконечный результат, а в остальных случаях новая метрика должна быть строго больше объявленной соседом.
  • Это условие поддерживает избегание петель. Оно не делает значение маршрута доказательством ёмкости, цены, практической задержки, текущей достижимости или результата услуги. RFC 9616 показывает, что даже точные выборки RTT могут быть слишком шумными для прямого выбора маршрута.

У числа есть граница применения

Малое значение в таблице маршрутизации легко принимают за универсальное «лучше». Но Babel не требует одной формулы для всех узлов и интерфейсов. Он допускает разные стратегии и разделяет только проверяемое ограничение: добавление локальной стоимости не должно улучшать метрику в той же вычислительной логике.

Строгая монотонность не позволяет маршруту пройти по циклу и вернуться как будто без ухудшения. Это инвариант безопасности, а не центральная шкала ценности. Выбранная запись сообщает о локальном решении при известных входах; она не доказывает, что трафик сейчас проходит, удалённый сервис отвечает или путь даёт лучший пользовательский результат.

Сходимость без обещания глобального оптимума

RFC 8966 различает строгую монотонность и левую дистрибутивность. Первая необходима против устойчивых петель. Вторая рекомендована, но не обязательна для сходимости без петель. Без неё Babel может сойтись, не достигнув глобального оптимума; сам глобальный оптимум может не существовать.

Поэтому локальная политика не превращается в верховный арбитраж. Бесконечные и недопустимые маршруты не выбираются; более новый номер последовательности нельзя предпочесть только за новизну, поскольку это может вызвать колебания и при некоторых метриках устойчивые чёрные дыры. При меняющихся значениях RFC рекомендует гистерезис. Он требует устойчивого локального основания для переключения, но не обещает уровень сервиса.

RTT сначала требует правила перевода

RFC 9616, написанная Baptiste Jonglez и Chroboczek, исходит из того, что RFC 8966 не предписывает единый алгоритм метрики. Расширение RTT помогает там, где число переходов или потери выбирают плохой путь в туннельной либо VPN-топологии. Но точная выборка RTT всё равно может быть шумной и при прямом использовании вызвать обратную связь и колебания. Поэтому документ задаёт отображение в стоимость и гистерезис, а применение ограничивает средами, где симметричная задержка действительно предсказывает нужный выбор канала.

RFC 8965, автором которой является Chroboczek, описывает устойчивость Babel к новым и колеблющимся метрикам, но фиксирует и ограничения периодических обновлений и полной таблицы маршрутов. Его открытый профиль IETF связывает его с RFC 8965, 8966 и 9616, не доказывая контроля над работающей сетью или политикой оператора.

Границы доказательств

Источники не показывают действующий домен Babel, активный туннель, текущий RTT, ёмкость, цену, состояние безопасности или результат доставки услуги. Полезная запись метрики должна хранить алгоритм и версию, локальный охват входов, окно наблюдения, преобразование, допустимость, гистерезис и условие выбора.

Источники