Кратко

  • RFC 9831 разрешает в типах I, J и K включить поле SRv6 SID с нулевым значением, чтобы передать желаемое поведение или структуру, не задавая сам исполняемый SID.
  • Флаг S доказывает наличие поля, но не готовность значения. Headend разрешает ссылку на узел или смежность по локальной SR-информации и отдельно фиксирует отсутствие, невозможность или несовпадение.
  • Проверяемая цепочка хранит флаги, исходные биты, контекст ссылки, источники разрешения, полученный SID, причину проверки, выбор, установку и наблюдение пакета.

Ноль может передавать полномочие

Необязательное поле обычно представляют как двоичный выбор: есть или нет. Для SRv6-типов I, J и K появляется третий операционный случай. Флаг S сообщает, что 16-октетное поле SID есть, но в нём может находиться IPv6-адрес, состоящий из нулей.

Контроллер использует такую форму, когда хочет указать endpoint behavior или SID structure, но не выбирать конкретный SID. Передача завершена, а выбор значения намеренно оставлен принимающему узлу. Ноль здесь не означает повреждение или случайную пустоту.

Если поля SID нет, блок behavior/structure тоже запрещён. Если поле присутствует с нулём, блок может уточнять ожидание от будущего локального результата. Ненулевой SID образует третий вариант: отправитель уже предлагает конкретное значение. В каждом случае граница ответственности проходит по-разному.

Сведение отсутствия и нуля к null уничтожает факт делегирования. Сведение нулевого и ненулевого полей к “SID present” создаёт ложный готовый результат. Нужны S, B, все 128 исходных бит, тип сегмента и адреса или интерфейсные идентификаторы, задающие контекст.

Явный путь может содержать ссылку

Segment List sub-TLV кодирует один явный путь к endpoint, а каждый Segment sub-TLV — его упорядоченный элемент. Явными становятся порядок и смысл шага, но не обязательно окончательное значение для плоскости передачи.

Типы C и D описывают IPv4/IPv6-узлы для получения SR-MPLS label. Типы E–H описывают смежности адресами и interface ID. Типы I–K применяют этот подход к узлам и смежностям SRv6. RFC 9256 требует от headend разрешить такие описания в label или SID.

Контроллеру не нужно встраивать в каждое объявление все текущие локальные назначения. Получатель может обновлять внутреннее соответствие, сохраняя внешнюю ссылку. Однако его SR-состояние становится обязательной частью исполнения.

Два headend могут получить одинаковые байты, но разрешить их по-разному. Один видит актуальный источник префикса и интерфейс, другой не находит запись или получает другое значение. Сохранённое объявление доказывает общий вход, но не общий выход. Нужны источник, версия, время и результат локального разрешения.

A, S, B и V — не четыре голоса за валидность

Флаг A делает поле SR Algorithm значимым для применимых типов. Без A отправитель обязан записать ноль, а получатель — игнорировать поле. Такой ноль не просит выбрать алгоритм локально; он не утверждает алгоритм вообще.

S отмечает наличие поля SID. Он не говорит, нулевое ли значение, найдено ли оно, согласуется ли со ссылкой и может ли быть установлено.

B отмечает блок SRv6 endpoint behavior и SID structure у типов B, I, J и K. Блок не может существовать без поля SID, но поле может быть нулевым. Следовательно, B описывает ожидание от значения, которое ещё предстоит получить.

V требует от SRPM выполнить SID verification. Это команда на проверку, а не её итог. Отображать V=1 как “verified” — значит подменять задание квитанцией об успехе.

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

Получатель вправе получить другой SID

RFC 9256 описывает SR-DB как концептуальный набор сведений для расчёта и проверки. Реализация не обязана создавать буквальную базу с таким названием. Она должна иметь локальный контекст, связывающий префикс, узел, интерфейс или пару адресов с текущим SID.

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

В нескольких доменах граница знания меняет способ представления. Если headend не может проверить достижимость удалённого SID, RFC 9256 требует для него прямой тип A или B; первый SID всегда должен быть достижим. Стандарт не приписывает локальному resolver всеведение.

Получатель не просто читает структуру. Он определяет применимые поля, обращается к локальным фактам, достраивает или сравнивает значение и оценивает список. Аутентификация BGP-соседа подтверждает источник сообщения, но не правильность адреса узла, интерфейса, behavior или топологии.

Правильная длина не делает список исполняемым

RFC 9831 задаёт разные длины в зависимости от присутствия SID и behavior/structure. Это защищает границы полей и не позволяет принять последующие октеты за текущие. Проверка доказывает форму.

Тип определяет структурную роль. Флаги определяют, какие поля интерпретировать. SRPM проверяет список целиком. RFC 9256 объявляет список со смесью SR-MPLS и SRv6 недействительным, даже если каждый отдельный sub-TLV идеален.

RFC 9830 уже выносит семантическую проверку явного пути за пределы BGP. RFC 9831 не меняет существующие операции и fault management SR Policy. Предыдущий разбор RFC 9830 отделял доставку кандидата от права установить пересылку. Здесь рассматривается более ранняя граница: само доставленное поле может быть просьбой к получателю завершить описание.

Регистрация синхронизирует грамматику

IANA выделяет коды типам C–H и I–K и биты флагам A и S. Благодаря этому реализации читают одинаковые числа одинаково. Но запись в реестре не создаёт локальную топологию, актуальную SID или аппаратную возможность.

Код Type J не доказывает поддержку конкретным маршрутизатором. Interface ID не доказывает неизменность линии. Разрешённый SID не доказывает установку, а установка — наблюдаемый пакет. Статус Experimental также не сообщает о масштабе внедрения.

“Поддерживается” может означать только разбор. “Разрешён” требует локального контекста. “Проверен” требует сравнения. “Активен” относится к выбору кандидата. “Установлен” относится к forwarding plane. “Наблюдался” требует контролируемого трафика. Эти слова нельзя сокращать до одного статуса.

Не переписывать историю разрешённым значением

Квитанция контроллера хранит intent, порядок, тип, контекст узла или линии, A/S/B/V, длины, исходные значения, версию и время. В ней явно указано: ненулевой SID предоставлен, нулём делегировано разрешение или поле пропущено.

Квитанция headend добавляет источники SR, версию, результат, неоднозначность и время. Проверка добавляет поиск, совпадение, смешение технологий и причину отказа. Затем отдельно идут валидность кандидата, активный выбор, программирование, пакет и результат сервиса.

Так неразрешившаяся делегация возвращается владельцу локальных данных, конфликт с предоставленным SID — границе между сторонами, а поздний отказ установки — платформе пересылки. Причина не теряется в общем “path failed”.

Источники