Кратко

  • RFC 7570 задаёт общий необязательный контейнер ERO Hop Attributes для сигнализации и RRO Hop Attributes для отчётности по атрибутам, связанным с конкретным переходом. ERO-субобъект имеет тип 35, переменную длину и содержит один или несколько TLV Hop Attributes в пределах длины субобъекта.
  • Субобъект ставится после идентифицирующего ERO-субобъекта либо после label-субобъектов, относящихся к этому переходу. Атрибуты применяются к непосредственно предшествующему субобъекту или субобъектам. Следовательно, размещение задаёт область действия, но не даёт власти над всем LSP.
  • Документ, определяющий атрибут, должен указать допустимые предшествующие типы ERO, значимость и толкование порядка, правила изменения и требования к отчётности. Бит R задаёт режим обработки, а не содержательный смысл атрибута.

На уровне пакета последовательность такова: субобъект, идентифицирующий переход, затем тип 35 и TLV атрибута. При R=1 узел проверяет TLV по обязательным правилам RFC 5420, раздел 5. При R=0 применяются необязательные правила раздела 4.2. Это определяет реакцию на содержимое у адресованного перехода, но не создаёт семантику TLV и не разрешает управлять остальными узлами. Допустимое место, порядок, изменение и отчётность определяются спецификацией атрибута, локальной политикой и полномочиями узла.

Обрабатывающий узел может отклонить атрибут из-за RSVP-политики или admission control, а также изменить его, если процедуры соответствующего TLV это разрешают. Узел, не поддерживающий ERO Hop Attributes при обработке ERO, возвращает Routing Error / Bad EXPLICIT_ROUTE PathErr; ERO усекается на проблемном субобъекте. Некорректный или повреждённый субобъект не становится допустимым из-за R=0. RFC 3209 отдельно говорит: неизвестный ERO-субобъект, уже встреченный при обычной обработке, вызывает Bad Explicit Route Object, тогда как ещё не встреченный может быть передан дальше.

Для флагов действуют только те, что определены как допустимые в данном контексте: недействительные флаги молча игнорируются, а неизвестные должны приводить к Unknown Attributes Bit PathErr.

Нельзя смешивать отчётность всего LSP и свидетельства для одного перехода. Атрибуты, переданные в LSP_ATTRIBUTES или LSP_REQUIRED_ATTRIBUTES, обычно отражаются в RRO Attributes по RFC 5420. Атрибут, переданный только в ERO Hop Attributes, обычно отражается в RRO Hop Attributes; это также субобъект типа 35. Узел может сообщить, что рассмотрел атрибут ERO, или вернуть дополнительный TLV, однако обязанность отчитываться о соответствии должна быть установлена определяющим документом атрибута.

Транзитные узлы обычно пересылают RRO Hop Attributes без изменений, но граница домена может удалить или изменить их из-за конфиденциальности либо ограничения размера. Поэтому наличие записи RRO не является неизменным доказательством, а отсутствие записи не доказывает неисполнение.

RFC 7571 следует использовать только как ограниченный пример: запрос OAM loopback адресуется конкретному узлу, а состояние loopback может быть передано через RRO Hop Attributes. Это не превращает loopback в общее значение механизма RFC 7570. Получателю, которому нужно поведение на определённом переходе, необходимы поддержка и разрешение именно этого узла. Успешное установление LSP при необязательной обработке само по себе не доказывает выполнение.

Путь решения оператора

  1. Укажите нужный переход и непосредственно предшествующий ERO-субобъект; сопоставьте тип и порядок с документом, определяющим атрибут.
  2. Проверьте локальную авторизацию, policy и admission control. Отдельно решите, нужен ли R=1 или приемлем R=0 с ограниченным свидетельством.
  3. Проверьте размер ERO и Path, правила флагов, допустимость изменения и фильтрацию RRO на границах доменов.
  4. Сопоставьте Path, PathErr и RRO. Не считайте успешный setup доказательством необязательного соответствия без отчёта, предписанного спецификацией.

Пакетные проверочные фикстуры

  • Fixture A: ERO для узла A, сразу за ним type=35 с TLV и R=0. Убедитесь, что адресован A, а из сообщения нельзя вывести полномочия или исполнение на узле B.
  • Fixture B: отправьте type=35 с R=1 узлу без поддержки. Ожидайте Routing Error / Bad EXPLICIT_ROUTE PathErr и ERO, усечённый на ошибочном субобъекте.
  • Fixture C: проверьте отдельно недействительный и неизвестный флаги: первый молча игнорируется, второй должен вызвать Unknown Attributes Bit PathErr.
  • Fixture D: сопоставьте атрибут всего LSP в RRO Attributes с hop-атрибутом в RRO Hop Attributes, затем удалите RRO на границе домена. Результат — отсутствие свидетельства, а не автоматическое доказательство сбоя.
  • Fixture E: используйте недопустимый предшествующий ERO-тип или запрещённый порядок. Проверьте локальный отказ либо разрешённое изменение; R не даёт права обходить спецификацию атрибута.

Набор источников не устанавливает, какие поставщики или операторы реализуют ERO или RRO Hop Attributes. В нём нет данных о распространённости, частоте отказов setup, росте сообщений или последствиях для клиентов. Здесь не утверждаются инцидент, внедрение или коммерческий результат. По errata сохранена только зафиксированная страница поиска RFC Editor; более широкого утверждения об исправлении нет.

Источники