Кратко

  • draft-ietf-lisp-site-external-connectivity-05 разрешает непустой набор pETR RLOC, когда адрес внешний, неизвестный либо известный, но не зарегистрированный.
  • Ответ выбирает выход в рамках IID и версии политики. Он не обнаруживает назначение, не подтверждает нативный маршрут после pETR и не является квитанцией приложения.
  • Регистрация, выбор, cache, декапсуляция, внешняя пересылка и результат сервиса должны оставаться разными доказательствами.

В RFC 9301 отсутствие регистрации может привести к Negative Map-Reply без локаторов и с ограниченным по времени действием. Редакция 05, поданная 30 сентября 2026 года, сохраняет процедуру вычисления non-LISP «hole», но требует ненулевой Loc-Count. В ответе перечисляются Proxy-ETR, через которые следует попытаться выйти наружу.

Неизвестный адрес не стал зарегистрированным EID. Система нашла правило для класса трафика без более точного сопоставления. Это похоже на динамически поддерживаемый default route: pETR регистрируются, сервер ранжирует их и может публиковать изменения подписчикам.

Следующий шаг не закрывает пробел

Правильная запись сохраняет одновременно unknown_or_unregistered и external_exit_selected. Флаг resolved=true уничтожил бы исходную неопределённость.

В аварии это принципиально. Map-Reply может быть верен, а пакет исчезнуть после pETR из-за внешнего маршрута, фильтра, перегрузки или неработающего сервиса. Повторный успешный запрос ещё раз подтверждает выбор выхода, но ничего не говорит о недостающем участке.

Регистрация pETR фиксирует заявление кандидата. Ответ сервера фиксирует решение. Readback map-cache показывает предполагаемое состояние ITR. Счётчик декапсуляции доказывает прибытие к шлюзу. Ответ приложения доказывает удалённый результат. Ни одна ранняя квитанция не подписывает следующую стадию.

Регистрация — заявление о пригодности

pETR с внешней связностью может зарегистрироваться для VPN Instance ID, указав настраиваемый Distinguished Name, набор RLOC и при необходимости VPN-контекст. Vendor-specific LCAF может переносить сведения о местоположении, ресурсах или производительности.

Аутентификация отвечает, кто отправил запись. Политика допуска должна отдельно определить, мог ли этот субъект объявлять выход для IID и контролировал ли RLOC. Операционное наблюдение должно показать, когда внешняя связность была проверена и какое событие удаляет кандидата.

RFC 9306 задаёт контейнер для формата производителя, а не общую семантику измерений. «Доступность» может быть конфигурацией, локальным счётчиком или старой оценкой контроллера. Без производителя, схемы, единицы, окна, метода, доверия и срока действия это policy hint, а не сравнимый факт.

Если такие поля распределяют трафик, у шлюза появляется стимул описывать себя оптимистично. Происхождение и метод измерения становятся частью управления, а не необязательным комментарием.

Priority и Weight задают намерение

RFC 9300 предпочитает меньший Priority и распределяет поток по относительным Weight среди RLOC с одинаковым приоритетом. Эти числа управляют выбором ITR, но не доказывают ёмкость, задержку, стоимость, независимость путей или фактическую долю.

Разные RLOC могут вести к одному устройству или провайдеру. Соотношение 70/30 может быть договорной политикой, а не измерением полосы. Воспроизводимая квитанция хранит исходных кандидатов, причины исключения, snapshot метаданных, версию политики, tie-break и ожидаемое распределение. Затем его сверяют со счётчиками encapsulation, decapsulation и native forwarding по каждому pETR.

Map-Notify-Ack подтверждает только сообщение

RFC 9437 позволяет публиковать изменения через Map-Notify, защищённый nonce и security association, с подтверждением Map-Notify-Ack. Без pub/sub проект предлагает более короткий TTL.

ACK подтверждает управляющее сообщение, а не программирование каждой таблицы и не доставку пакета. Короткий TTL ограничивает желаемый возраст состояния, но не гарантирует успешное обновление.

Автоматизация должна записывать стадии отдельно: обновление аутентифицировано, scope принят, запись выполнена, readback совпал, data-plane canary дошёл до pETR, внешний canary прошёл шлюз, приложение завершило запрос. Первая отсутствующая квитанция определяет границу расследования.

Default имеет самый широкий радиус

ITR может установить hole prefix или default map-cache entry. Проект рекомендует оставить известные EID-блоки более точными записями, всегда вызывающими Map-Request. Иначе широкое внешнее правило поглотит обычное EID-разрешение.

Default упрощает настройки, но одним изменением перемещает много несвязанных потоков. Вместе с доступностью меняются точка наблюдения, стоимость, юрисдикция и контроль безопасности. Вводить механизм следует на узком IID, с защищёнными префиксами, canary-ITR и ограниченным TTL. Rollback должен убрать только проблемный pETR, не очищая чужие caches.

Datatracker показывает Experimental Internet-Draft, а не RFC, отчёт о внедрении или интероперабельности. AI-инфраструктура в тексте — пример применения, а не доказательство реализации в конкретной сети.

Reality Layers Лу Хэна дают точную модель аудита: Distinguished Name — символ, Map-Reply — решение, cache — состояние, пакет — действие, удалённый ответ — результат. Надёжность требует проверяемых связей между слоями, а не одного зелёного статуса.

Источники