Кратко

  • RFC 9791, опубликованный в июле 2025 года как Informational, описывает NFFRR как сценарий применения MNA после уже выполненной FRR, но не задаёт законченного стандартизованного действия NFFRR.
  • Истёкшие draft-kompella-mpls-nffrr-04 и draft-li-mpls-mna-nffrr-01 предлагают конкретные механизмы, сигнализацию и неназначенный бит TBA, однако это не действующее назначение IANA и не доказательство внедрения.
  • Управленческий вопрос шире кодировки: первая точка локального ремонта получает возможность фактически сказать следующей точке «не спасай этот пакет ещё раз». Такое вето оправдано только тогда, когда известны модель отказа, топология, способности узлов и происхождение метки.

От локальной защиты к распределённому запрету

Раздел 2.1 RFC 9791 формулирует проблему коротко: после первой FRR второй узел может применить ещё одну FRR к тому же пакету, и результатом способен стать цикл до истечения TTL, загрузка каналов и дополнительная потеря. Документ говорит о маркировке уже перенаправленных пакетов средствами MNA, чтобы исключить дальнейшую FRR. Но RFC 9791 — каталог случаев применения, а не полная спецификация NFFRR. Это различие принципиально: наличие описанной потребности не равно существованию согласованного сетевого действия с назначенным кодом, совместимой сигнализацией и доказанной эксплуатацией.

Истёкший draft-kompella-mpls-nffrr-04 идёт дальше. Его EVPN active-active пример показывает, как один физический отказ CE2 проявляется перед PE2 и PE3 как два локальных отказа соединений. PE2 перенаправляет пакет к PE3; PE3 пытается защитить собственную недоступность CE2 и возвращает пакет. В предложенной схеме метка NFFRR после первой защиты должна заставить PE3 отбросить пакет вместо второго ремонта. Потеря здесь не случайность, а выбранная цена за прекращение цикла.

Именно поэтому NFFRR удобнее рассматривать не как ещё один технический флаг, а как делегированное вето. Первый PLR не просто выбирает обход. Он переносит вперёд решение о том, что последующая локальная оптимизация опаснее отказа от доставки. Нижестоящий узел, доверяя метке, отказывается от собственного механизма защиты, хотя локально у него может существовать доступный ремонтный путь.

Что должно быть истинно, чтобы вето было разумным

Первое предположение относится к топологии. RFC 5286 прямо связывает наличие безопасного loop-free alternate с топологией и типом защищаемого отказа. RFC 7490 аналогично рассматривает repair path как безопасный лишь при ожидаемой модели отказа и отдельно предупреждает, что более тяжёлый отказ способен вернуть риск петли. Следовательно, фраза «пакет уже ремонтировался» недостаточна. Нужно понимать, почему именно второй ремонт считается опасным в данной структуре графа.

Второе предположение — о природе отказа. Один и тот же внешний симптом может представлять отказ линии, узла, общей группы риска или единого CE, который двумя PE воспринимается как два независимых события. NFFRR полезен именно там, где локальные наблюдения расходятся с реальной причинностью. Но если первая точка неверно классифицировала событие, её запрет может уничтожить вполне безопасную вторую возможность доставки.

Третье предположение — о возможностях. RFC 9789 требует, чтобы применение MNA опиралось на знание того, какие узлы и какие действия поддерживают, причём сигнализация возможностей остаётся отдельной задачей. RFC 9994 уже задаёт общую in-stack кодировку MNA, области действия и поведение при неизвестном действии: при U=0 узел пропускает неизвестное network action и переходит к следующему, при U=1 отбрасывает пакет; для такого отбрасывания предусмотрен локальный счётчик и допускается ограниченное по частоте уведомление оператору. Но это общая семантика неизвестного MNA-действия, а не NFFRR.

Четвёртое предположение — о доверии. Истёкший draft-kompella-mpls-nffrr-04 прямо предупреждает: злонамеренный или скомпрометированный LSR может вставить NFFRR и тем самым подавить FRR, вызывая лишнюю потерю. Значит, метка — это не только сигнал состояния, но и команда с негативным полномочием. Чем сильнее её действие, тем важнее происхождение, границы доверия и фильтрация.

Пять способов ошибиться с одной меткой

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

Устаревшая метка опаснее, чем кажется. Если контекст топологии или отказа изменился, решение, оправданное несколько миллисекунд назад, может больше не соответствовать текущему пути. Маркер без понятия срока действия превращает прошлое наблюдение в бессрочную инструкцию.

Поддельная метка — случай происхождения и доверия. Компрометированный LSR или нарушенная граница домена способны навязать downstream-узлу отказ от FRR. Неверно понятая метка — случай семантики: один узел считает её обязательным запретом, другой — советом, третий вообще не распознаёт действие. На пути со смешанными возможностями один сегмент может соблюдать вето, другой проигнорировать неизвестное действие, а третий при выбранной политике неизвестного действия отбросить пакет. Поэтому «наличие бита» не равно единому поведению пути.

На 20 сентября 2026 года реестр IANA MPLS Network Actions не содержит NFFRR. Это особенно важно на фоне RFC 9994, Proposed Standard июня 2026 года: стандартизована общая конструкция MNA sub-stack, но не само действие NFFRR. Тем самым нельзя превращать механизмы из истёкших черновиков, их сигнализацию или TBA-позиции в якобы действующее назначение или свидетельство внедрения. В совокупности эти источники не доказывают измеренный производственный инцидент, реализацию NFFRR, совместимость реализаций, распространённость механизма или какой-либо количественный эффект.

Квитанция сдерживания FRR

Я предлагаю для редакционного анализа BTW понятие «квитанция сдерживания FRR». Это предложение Daniel Kade, а не требование какого-либо RFC. Его цель — сделать запрет на второй ремонт проверяемым постфактум.

Такая квитанция должна сохранять: класс услуги; первое и второе наблюдения отказа; первый PLR и способ ремонта; версию топологии и использованную модель отказа; идентификатор действия, его область, место вставки и положение в стеке; доказательство заявленных возможностей узлов; происхождение метки и правила пограничной фильтрации; факт распознавания ниже по пути и конечную судьбу пакета; счётчики, признаки перегрузки и потерь; владельца политики, а также условие её пересмотра или истечения.

Смысл этой записи не в бюрократии. Если оператор сознательно меняет «возможно доставить» на «обязательно прекратить дальнейшую защиту», то после события должна остаться цепочка доказательств, позволяющая ответить на три вопроса: кто принял решение, на какой модели мира оно основывалось и подтвердилось ли ожидаемое сдерживание петли реальным поведением пути.

Источники