Кратко

  • Редакция от 28 октября индивидуального проекта об эластичной маршрутизации по доступной полосе убрала два прежних способа запускать возврат с обходных путей.
  • Теперь первое условие требует, чтобы весь трафик уже оказался на основном пути и его загрузка оставалась ниже порога после восстановления. Проверки до первого переноса текст не задаёт.

Объезд открыт. Вернуться можно, если уже вернулся.

Это не абстрактный спор о настройке таблицы. В примере редакции от 28 октября из двух волокон на участке A–B одно выходит из строя: линия теряет половину пропускной способности, но соединение сохраняется, и трафик A–C продолжает идти через B. Обходы есть через D — A–D–C или A–D–B–C. Предложение предлагает ближайшему узлу увидеть перегрузку и задействовать их.

Авторы оценивают обычное ручное или контроллерное восстановление в минуты или часы и связывают задержку с экономическими потерями. Это их оценка в тексте проекта; отдельные замеры не приведены. Главный ответ предложения — локальный обход до завершения общей оптимизации. Но когда сеть готова выйти из обхода, проект отнимает у локального узла ясный первый шаг.

Временный объезд должен когда-то закончиться. Раздел 4.4 определяет traffic fallback как перенос трафика с альтернативных путей обратно на основной. Затем он перечисляет условия возврата. Условие 1 требует, чтобы весь трафик уже был переключён обратно и загрузка основного пути не превышала Post-restore Threshold. Условие 2 требует сохранять это состояние в течение настраиваемого Restore Period. Для начала действия потребовалось доказательство того, что действие завершено.

В июльской редакции 00 последовательность была иной. Возврат запускался при падении загрузки проблемной линии ниже порога восстановления либо после динамической оценки, что локальная линия выдержит весь трафик без новой перегрузки. Условие должно было держаться заданное время. Октябрьский текст удалил оба способа. Общее описание всё ещё упоминает снижение загрузки ниже порога, но подробная процедура привязана к состоянию после полного возврата.

Авторы могли иметь в виду прогноз будущей загрузки при возвращении всех потоков. Возможен и пробный перенос по частям с остановкой при ухудшении. В разделе 4.4 нет ни расчёта прогноза, ни пробного порядка, ни правила отката. Низкая загрузка основного пути, пока часть потоков идёт в обход, сама по себе не показывает будущую нагрузку. Не хватает теста до первого переноса. Если он появится в следующей редакции, этот вывод изменится.

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

Источники