Кратко

  • Согласно редакции 34, поддерживающий механизм пир при значении Site Physical Availability 0% должен считать недоступными для пересылки все маршруты, связанные с Site-ID. Эффект равен индивидуальному отзыву маршрутов, но сами отзывы не передаются.
  • В обычном BGP эти маршруты могут оставаться действительными. Поэтому источник обновления, поколение сопоставлений, решение каждого узла, RIB, FIB, потоки и итог сервиса требуют отдельных подтверждений.

В 09:14 пограничная площадка теряет последний работоспособный сервер. Выходной маршрутизатор отправляет один BGP UPDATE с Site-ID и нулевой физической доступностью. Десятки префиксов по-прежнему видны в BGP-таблице входного маршрутизатора, но больше не выбираются для трафика, управляемого метаданными. Серии withdrawals нет. Для оператора маршрутизации пути существуют; для сервиса площадка исчезла.

Именно это расхождение делает редакцию 34 BGP Extension for 5G Edge Service Metadata важной. Она принята 25 сентября 2026 года, титульная дата — 23 сентября. Документ остаётся Internet-Draft рабочей группы IDR в состоянии I-D Exists. На титуле указан Standards Track, однако поле Intended RFC status в Datatracker пусто. Нет shepherd, ответственного Area Director и telechat; ориентир на июль 2027 года предусматривает WGLC. Это не RFC, не выделенный код IANA, не реализация и не результат развёртывания.

Одна команда получает область действия из прошлого

Проект определяет необязательный нетранзитивный Edge Metadata Path Attribute. Маршрут может связать сервисный префикс с 16-битным Site-ID. Отдельное обновление затем сообщает динамические свойства площадки, не повторяя их в каждой маршрутной записи. В автономной форме NLRI содержит loopback выходного маршрутизатора, RouteFlag-I равен нулю, а значение применяется к уже связанным маршрутам. При RouteFlag-I, равном единице, сообщение создаёт связь, а процент доступности игнорируется.

Нулевой случай теперь сформулирован прямо. Поддерживающий speaker обязан считать все связанные маршруты недоступными для пересылки. Проект называет эффект эквивалентным индивидуальному отзыву каждого маршрута, хотя отдельные withdrawals не отправляются. Пиру без Edge Metadata для прекращения использования путей всё ещё нужны обычные отзывы BGP.

«Эквивалентность» описывает результат выбора внутри механизма, а не тождество состояний. В другом месте проект разрешает маршруту, исключённому из выбора по метаданным, оставаться корректным для обычной BGP-достижимости. Префикс присутствует в RIB, но не подходит одному классу сервиса. Такое разделение снижает churn и не смешивает здоровье приложения с доступностью сети. Одновременно зелёная сессия и видимый префикс перестают быть доказательством работоспособного сервиса.

Ноль не содержит перечня затронутых маршрутов

Автономное обновление не перечисляет сервисные префиксы. Его веер зависит от ранее полученных связей маршрут–Site-ID. Если один ingress хранит 42 маршрута для Site-ID 711, а другой — 41 из-за пропущенного обновления, оба могут правильно обработать один ноль и отключить разные множества.

Записи «получено Site-ID 711 = 0» недостаточно. Нужна версия карты: ключи маршрутов, момент вступления в силу, исходный speaker и точки принятия решений, подтвердившие поколение. Число элементов и digest рассчитанного множества позволят сопоставить замысел с применением, не заставляя протокол публиковать все внутренние решения.

Версия, подтверждение и digest — операционные рекомендации этой статьи, а не требования редакции 34. Проект определяет поведение протокола, но не систему квитанций для всего парка. Оператор может использовать локальную телеметрию, контроллер или подписанные журналы. Локальный выбор средств допустим; неясность в вопросе «к чему должен был примениться ноль» — нет.

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

Получатель должен принимать автономное обновление только от соответствующего egress-маршрутизатора либо от разрешённого route reflector, чей Originator-ID указывает на этот egress. Условие критично: поддельный ноль способен сделать все связанные маршруты недоступными и вызвать отказ в обслуживании.

Корректная BGP-сессия не равна авторизации такого действия. Reflector может быть законным соседом, но передать неожиданный Originator-ID. Loopback egress может быть достижим, хотя сессия выполняет иную роль. Квитанция должна сохранять аутентифицированного пира, AFI/SAFI, согласованную Edge Metadata Processing Capability, идентичность egress, Originator-ID, Site-ID, байты атрибута и решение политики.

Capability согласуется двусторонне для каждого AFI/SAFI. Атрибут необязателен и нетранзитивен; NO_ADVERTISE, AS-Scope sub-TLV и обычная фильтрация ограничивают распространение. Неизвестные sub-TLV игнорируются, отсутствие значения никогда нельзя трактовать как ноль. Эти меры уменьшают риск, но не доказывают поддержку на всех ingress и не подтверждают обычные withdrawals для несовместимых пиров.

У измерения, объявления и потока разные часы

Site Physical Availability принимает значения от нуля до 100, выходящие за диапазон игнорируются. Проект разделяет интервал измерения и объявления, рекомендует по умолчанию не менее 30 секунд и допускает dampening либо hysteresis. Привязка потока зависит от реализации: уже выбранный egress может обслуживать поток, пока действительно не станет недостижимым.

Площадка может измерить ноль в 09:14:00, отправить его в 09:14:12, один ingress применит решение в 09:14:13, а закреплённый поток завершится в 09:15:00. Единая метка «событие ноль» скрывает расстояние между измеренной реальностью, распределённым управлением и опытом пользователя.

Автономное обновление не предназначено и для next-hop resolution. Оно меняет пригодность площадки для сервиса, но не говорит, что loopback недостижим или что произошла конвергенция BGP. Лестница доказательств должна различать измерение, разрешённый источник, поколение карты, capability, приём, определение целевого множества, политику, RIB, FIB, обработку потоков и итог сервиса.

Минимальная спецификация оставляет место местной политике

Подход Heng Lu предлагает стандартизировать минимальную основу координации, сохранив будущие и локальные решения у операторов. Здесь такой основой могут стать идентичность площадки, смысл доступности, допустимый источник и область действия. Алгоритм измерения, ранжирование и fallback остаются локальными. Приоритет работающего кода затем требует показать границу, на которой протокольное значение превращается в решение пересылки.

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

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

Источники