Кратко

  • was-the-last-lie-accepted показывает лишь, был ли принят последний Link Information Element на данном интерфейсе. Поле не доказывает ThreeWay, правильность ZTP, полноту TIE, установку RIB/FIB или доставку трафика.
  • Успешный clear означает начало перестройки соединения. Восстановление подтверждается только последующей цепочкой наблюдений и независимой проверкой доставки.

Правдивый ответ с узкой областью

RFC 9719 задаёт YANG 1.1-модель RIFT, совместимую с NMDA и расширяющую модель маршрутизации IETF. Поле was-the-last-lie-accepted доступно только для чтения. True означает, что последний принятый с линии LIE прошёл проверку. При отказе last-lie-reject-reason и уведомление neighbor-error дают контекст.

Это утверждение относится к одному сообщению на одном интерфейсе. Оно не говорит, что сосед подтвердил узел, состояние достигло ThreeWay, ZTP выбрал нужный уровень, топологическая база согласована, маршрут попал в пересылку или пакет дошёл до сервиса.

RFC 9692 разделяет эти факты в конечном автомате. В TwoWay уже получен допустимый LIE, но ещё нет допустимого ThreeWay LIE. Только ThreeWay позволяет объявить соседство и обмениваться TIE, TIDE и TIRE. Приём проверяет вход; ThreeWay подтверждает взаимность.

Как строится доказательство

Модель предоставляет отдельные точки контроля: состояние интерфейса и причину отказа, FSM соседства, отправленные и принятые предложения ZTP, лучшее предложение и удаления, счётчики и очереди LIE/TIE/TIDE/TIRE, локальную базу TIE, время SPF и вызвавший его TIE, уведомления об ошибках соседа и TIE.

Если LIE отклонён, до изменений сохраняют причину, идентификатор соседа, уведомление и временную линию. Формулировки журналов у реализаций могут различаться, поэтому стандартизованное состояние должно оставаться рядом с ними.

Если LIE принят, проверяют переход в ThreeWay и его устойчивость. Остановка в TwoWay не противоречит первому наблюдению: она точно указывает промежуток между допустимым сообщением и взаимным подтверждением.

Далее исследуют предложения и иерархию. Допустимый LIE не гарантирует, что уровень и направление соответствуют замыслу фабрики. Received offer, best offer и removal reason отражают разные решения.

Следующий рубеж — синхронизация. Сопоставляются база TIE, активность TIDE/TIRE, очереди, число соседей, запуск и длительность SPF. Устойчивое соседство не компенсирует неполную информационную базу.

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

Сброс — действие, а не сертификат

clear-neighbor и clear-all-neighbors разрывают одно или все соседские соединения интерфейса. Успех вызова подтверждает приём команды, но не завершение перестройки. В разделе безопасности RFC отмечено, что несанкционированные сбросы могут постоянно пересоздавать соединения и нарушать устойчивость.

До сброса фиксируют состояние, затем выбирают минимальное воздействие, а после заново проверяют LIE, ThreeWay, предложения, TIE, SPF, установку маршрутов, аппаратную пересылку и доставку. Сброс способен убрать устаревшее состояние — и одновременно уничтожить след причины.

Что на самом деле стандартизировано

Автоматизация может отслеживать повторные отказы, запускать проверку базы после ThreeWay, связывать инициирующий TIE со временем SPF и сравнивать рабочие предложения с конфигурационным намерением.

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