Кратко

  • RFC 9655 добавляет необязательный Egress TLV 32771 перед Target FEC Stack, чтобы all-Nil-FEC MPLS ping/traceroute указывал IPv4 или IPv6 конечного egress.
  • При нулевой глубине code 36 означает точное совпадение с локальным interface/loopback, code 10 — отсутствие совпадения; legacy code 3 может прийти без новой проверки.
  • Намерение SR Policy, вывод endpoint, запрос, capability, фактическое переключение, offline-реконструкция и результат пользовательского трафика должны сохраняться как разные квитанции.

Почему Nil FEC допускает ложный финал

Nil FEC из RFC 8029 не несёт сведений о связанном FEC. Если он внешний, Target FEC validation полностью пропускается. Это позволяет headend проверить стек, выданный междоменным контроллером, даже если значения labels за пределами локальной базы неизвестны.

Когда один Nil FEC представляет весь стек, получатель также не может определить, является ли он задуманным выходом. Ошибочно направленный probe способен завершиться на другом узле и вернуть успех.

RFC 9655 помещает Egress TLV перед Target FEC Stack. Поле адреса занимает четыре октета для IPv4 или шестнадцать для IPv6. При положительной глубине code 8 сообщает transit switching. При глубине ноль узел ищет точное совпадение адреса среди локальных интерфейсов и loopback. Совпадение даёт 36, отсутствие — 10.

Code 36 удостоверяет владельца конечного адреса. Он не перечисляет операции над labels до этого момента.

Ожидаемый адрес тоже является версией состояния

Обычно он берётся из Endpoint SR Policy по RFC 9256. Если Endpoint отсутствует или равен нулю, используется конец последнего segment. Для Adj-SID это удалённый узел adjacency; для Binding SID — последний узел связанного пути.

Следовательно, request содержит результат работы контроллера и headend. Binding мог измениться, topology recompute мог завершиться, а probe — использовать прошлый epoch. Egress точно ответит на устаревший вопрос.

Нужно хранить policy ID, candidate path, segment list, источник Endpoint, binding resolution, controller epoch, build headend, raw request и время. RFC 8402 описывает segments как инструкции; Egress TLV сверяет лишь полученную из них конечную identity.

Code 3 — это не более старое написание code 36

Неподдерживающий transit node может игнорировать TLV, пропустить его или вернуть ошибку, а headend продолжит с большим TTL. Если расширение не понимает egress, новый lookup не выполняется и возможен старый code 3.

Совместимость сохранила процедуру, но не силу свидетельства. Dashboard должен различать 36 после lookup и 3 без доказанного lookup. В журнал входят факт отправки TLV, capability узла, адрес, depth, code/subcode, версия и сырые bytes.

RFC 9041 уточняет обработку code points, а IANA registry хранит 32771 и 36. Запись в реестре не означает, что production image поддерживает или включает функцию.

Реконструкция должна показывать пробелы

В traceroute каждый hop становится receiver. Ответы и SR-процедуры RFC 8287 позволяют offline application сравнить наблюдения с ожидаемым путём. Но этот verdict имеет собственные inputs и власть.

Программа должна сохранять TTL, responder, depth, code, expected policy epoch и правило для отсутствующих ответов. Нельзя вставить в gap участок из controller intent, а затем назвать его наблюдением. Legacy hop, silence и ECMP оставляют неопределённость.

Даже полная OAM-картина не является service receipt. Probe и production flow могут иметь другие hash inputs, время и steering. Нужны production counters, наблюдение на egress и действие приложения.

Слои реальности Heng Lu не позволяют символу заменить исполнение. Минимальная начальная спецификация согласует конечную identity, оставляя deployment ответственным локально. Приоритет работающего кода требует вернуться к конкретной версии и фактическому forwarding state.

Источники