Кратко

  • Если 255 октетов недостаточно, один объект IS-IS можно представить несколькими TLV одного типа и с одним ключом. Каждая часть должна разбираться самостоятельно, а получатель обязан собрать всю информацию независимо от порядка и размещения во фрагментах LSP.
  • Новый capability sub-TLV типа 30 носит только информационный характер, не перечисляет codepoint по отдельности и не должен менять отправку или обработку в самом протоколе.
  • Разрешение на включение требует внешней матрицы версий и поведения всех получателей для конкретного codepoint, поэтапной проверки и заранее испытанного отката.

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

Именно такой тихий раскол описывает RFC 9885. IS-IS кодирует сведения в кортежах Type-Length-Value. Поля Type и Length занимают по одному октету, поэтому Value одного TLV ограничен 255 октетами. С ростом сетей и числа атрибутов traffic engineering один логический объект перестал всегда помещаться в старый контейнер. RFC закрепляет несколько появлений TLV как стандартный способ расширения там, где прежняя спецификация не задала иной механизм.

MP-TLV нельзя понимать как поток байтов, разрезанный в случайном месте. Части образуют один объект, если у них совпадают тип и, когда он применим, уже определённый ключ объекта. Значение ключа остаётся в ведении исходной спецификации TLV. Каждая часть должна разбираться без помощи остальных. Разделить sub-TLV или другую единицу данных между частями запрещено: такая кодировка недействительна.

Получатель собирает смысл

Поддерживающий маршрутизатор принимает информацию из всех частей. Порядок прибытия и положение во фрагментах LSP значения не имеют. Части могут находиться в одном или разных LSP; их место в IIH тоже не меняет результат. Содержимое обрабатывается как логически соединённое, а повтор ключа сохраняет идентичность объекта.

Противоречия при этом не исчезают. Фиксированное значение, например метрика, может не входить в ключ и различаться между частями. Это ошибка. Ошибкой будет и несовместимое повторение sub-TLV, который должен встречаться один раз. Если исходный документ не установил особое правило, используется первое появление в LSP с наименьшим номером; для IIH — первое появление в нём.

Требования к приёму и отправке намеренно асимметричны. Получатель не вправе отвергнуть две части по 100 байт только потому, что они поместились бы вместе. Отправителю, напротив, не следует создавать несколько TLV, пока процедура неприменима к этому codepoint или сведения не превысили ёмкость одного TLV. Если целый TLV ещё допустим, но текущий LSP заполнен, предпочтительнее перенести его целиком в другой LSP.

Так сохраняется совместимость: получатель терпим к допустимой, хотя и излишней форме; отправитель не расширяет поверхность риска без нужды. Факт успешного приёма не подтверждает обоснованность решения о разделении.

Тип 30 предупреждает, но не договаривается

Частичное внедрение особенно опасно для codepoint, чьи старые спецификации не говорили о нескольких частях прямо. Неподдерживающий получатель может выбрать одно появление и игнорировать остальные. Если потеряны атрибуты канала для constrained path, вычисления расходятся; RFC указывает на возможные петли и отброшенный трафик. Это условный риск стандарта, а не сообщение о случившемся инциденте.

Для диагностики в Router CAPABILITY TLV появился sub-TLV типа 30 длиной ноль. Он сообщает о поддержке MP-TLV там, где прежние документы подразумевали её неявно. Область действия несущего объявления ограничена соответствующим уровнем IS-IS.

Однако спецификация сразу ограничивает его силу. Объявление предназначено только для информации. Реализация IS-IS не должна менять отправляемые данные или обработку полученных данных на его основании. Это не переговоры, не согласие и не автоматическая блокировка опасной конфигурации.

У типа 30 нет поля со списком codepoint. Документ предполагает широкую поддержку, но признаёт: реальная реализация может поддерживать MP-TLV только там, где этого потребовали её сценарии. За одним общим признаком скрыта матрица платформ, версий, ролей и codepoint.

Колонка MP в реестрах IANA отвечает на другой вопрос. Y говорит, что процедура применима к определению codepoint. Это не телеметрия конкретного устройства: она не доказывает наличие функции в установленном образе, локальное включение или одинаковую интерпретацию всеми получателями.

Полномочие остаётся у оператора

RFC рекомендует средства включения генерации на уровне отдельных codepoint. Если функцию можно отключить, реализация обязана журналировать два события: получение MP-TLV при отключённом использовании и локальную необходимость создать MP-TLV при отключённой генерации. Такие записи показывают воздействие и потребность, но не выполняют изменение.

До включения оператор должен подтвердить, что все будущие получатели правильно разбирают нужный codepoint. Нужны уровень, роль, платформа, установленная версия, тестовые байты, результат разбора, расчёт пути, FIB и проверка возврата. Аутентификация IS-IS полезна, но корректно аутентифицированные сведения всё равно могут быть неполно поняты старым получателем. Целостность источника и семантическая способность — разные факты.

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

Источники