Кратко

  • Если подтверждения полученных ремонтных LSP и новые запросы сверки используют один механизм передачи PSNP, revision 05 рекомендует сначала отправлять подтверждения.
  • Для каждого peer и уровня разрешена одна попытка. В опыте примерно с 6 700 фрагментами и 40 узлами перекрывающиеся попытки породили PSNP-запросы, равные почти пятикратному числу фрагментов.

Восстановление способно само продлевать сбой

CASH сначала сравнивает крупные диапазоны LSDB. PASH сужает область расхождения, а обычный SNP-обмен или flooding доставляет недостающие LSP. После этого у принимающей стороны возникают две конкурирующие задачи: попросить ещё отсутствующие данные и подтвердить уже доставленные ремонтные данные.

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

Текст revision 05 от 26 сентября 2026 года формулирует правило для такого случая. Datatracker одновременно показывает предел: это индивидуальный Internet-Draft без RFC stream и формального статуса IETF. Намерение стать Experimental не свидетельствует о внедрении.

Попытка закрывается после последней передачи

Уже revision 04 требовала не более одной reconciliation attempt для каждого peer и level. Новый периодический CASH нельзя начинать, пока остались PASH или PSNP на отправку либо вызванные текущей попыткой передачи и повторы LSP.

В приведённом опыте около 6 700 фрагментов на 40 узлах при перекрытии попыток создали PSNP-запросы в объёме примерно пяти полных наборов фрагментов; счётчик продолжал расти. Авторы связывают усиление с наложением попыток, а не с хеш-функцией или одним лишь масштабом.

Revision 05 добавляет правило планирования. Когда один PSNP-механизм обслуживает acknowledgments и reconciliation entries, сначала следует отправлять подтверждения полученных LSP, а остаток места использовать для запросов. SHOULD допускает обоснованное исключение, но превращает устройство scheduler в проверяемое эксплуатационное условие.

Совпадение, приём и доставка требуют разных квитанций

Предыдущая статья BTW «Хеши совпали. Это не доказало, что сеть права» разобрала revision 01 и границы совпадения сводки. Её тезис не повторяется. Здесь предметом служит следующий этап: завершение уже начатого ремонта без самоподдерживающегося усиления.

PSNP acknowledgement подтверждает приём определённого LSP, но не всю LSDB. Попытка ASH заканчивается только после связанных PASH, PSNP, передач и повторов LSP. Затем отдельно проверяются SPF, установка FIB и прохождение пользовательского трафика.

Первая квитанция должна связать peer, level, attempt, причину, диапазоны, глубину запросов, возраст подтверждений, открытые LSP, повторы, отложенные CASH и переход в завершённое состояние. Вторая фиксирует LSDB, вычисление и установку маршрута. Третья проверяет пакеты. Зелёный статус одного слоя не переносится в следующий.

Объявление способности тоже имеет узкий смысл. В Hello Capability draft ASH_RX и ASH_TX разделены по направлению и adjacency. RFC 1195 даёт контекст; RFC 5304 и RFC 5310 защищают целостность PDU, но не физическую истинность; RFC 9681 ускоряет flooding, не закрывая счёт ремонта.

Running-Code Primacy требует наблюдать выход подтверждения, прекращение повтора и возврат трафика. Minimum Initial Specification оставляет общий минимум: одна попытка, приоритет квитанции, явный конец. Reality Layers не позволяет объявленной способности присвоить силу наблюдаемого результата.

Источники