Кратко

  • Индивидуальный проект от 28 октября предлагает пять общих информационных элементов MPLS для повторения в упорядоченном шаблоне IPFIX. Если IPv4-адрес, IPv6-адрес или длина префикса недоступны на позиции K, экспортёр не должен передавать этот атрибут ни для K, ни для более глубоких позиций. Пропуск пустого места заставил бы получателя принять K+1 за K.
  • Старые позиционные поля остаются в реестре IANA. Новые зависят от отдельного проекта упорядоченного экспорта; получатель без его поддержки может молча потерять весь набор. Идентификаторы пяти новых элементов пока обозначены TBD.

Метка осталась; исчезло знание о ней

Пусть измерительный процесс наблюдает стек из трёх меток. Адрес следующего перехода известен для первой и третьей, для второй — нет. Экспортёр, который отправит только два адреса, даст получателю последовательность из двух значений. Получатель привяжет второе значение ко второй метке. На самом деле оно относится к третьей. Сами биты адреса могут быть верными; неверной становится связь между адресом и глубиной.

Раздел 4.7 нового проекта запрещает такое уплотнение. Экземпляры mplsLabelIPv4Address, mplsLabelIPv6Address и mplsLabelPrefixLength должны идти подряд, начиная с вершины. Когда значение на позиции K отсутствует, тот же элемент нельзя экспортировать для K и всех более глубоких позиций. Третья метка никуда не девается, и другие атрибуты ещё могут описать её правильно. Оборванный адресный ряд больше не имеет права указывать её место. Разреженный набор позиций проект оставляет за пределами своей модели.

Для типа метки есть иной выход. Если mplsLabelType на позиции K неизвестен, экспортёр передаёт 0, Unknown. Позиция сохраняется, незнание объявлено. Для адреса и длины префикса такого заменителя проект не задаёт, поэтому последовательность обрывается. «Тип второй метки неизвестен» и «эта серия не может надёжно назвать второй и нижние уровни» — разные сообщения для оператора.

Предыстория видна в реестре информационных элементов IPFIX. В нём десять позиционных полей для секций стека MPLS: IE 70–79. Каждое имя заранее говорит, какую глубину оно обозначает, от верхней метки до десятой. Новый проект предлагает повторять один mplsLabelStackEntry в упорядоченной записи и добавляет четыре общих атрибута. Старые поля не упраздняются: коллекторы без новой грамматики по-прежнему нуждаются в них.

Размер записи тоже изменится. По RFC 3032 полная запись метки занимает четыре октета: значение, класс трафика, флаг дна стека и TTL. Нынешние позиционные поля передают три октета без TTL. Новый общий элемент несёт все четыре и позволяет видеть TTL глубже в стеке; когда TTL не нужен, это дополнительный октет на каждую метку. Богаче наблюдение — больше поток экспорта.

Порядок должен пройти три узла доверия

RFC 7011 допускает повторение одного информационного элемента в шаблоне IPFIX. Обычный шаблон, однако, не даёт коллектору гарантии, что повторения отражают порядок наблюдений. Сопутствующий проект предлагает упорядоченные наборы шаблонов. Измеритель записывает значения в порядке наблюдения, экспортёр сохраняет и обозначает порядок, коллектор трактует n-е вхождение как n-е наблюдение. Пересортированная для красоты таблица не заменит согласия всех троих.

Гарантия действует отдельно для каждого элемента. Второй mplsLabelStackEntry и второй mplsLabelType относятся ко второй метке потому, что оба определения привязывают второе вхождение к глубине два. Относительный порядок разных элементов внутри сообщения не обещан. Если коллектор выводит дополнительную связь лишь из их соседства в байтах, он добавляет факты, которых протокол не сообщил.

Переход требует проверить получателя. В разделе 7 сказано включать новый экспорт только для коллекторов, о поддержке которых известно. Старый может отбросить весь упорядоченный набор без сообщения об ошибке. Пока оба типа получателей существуют, экспортёрам нужны и старые позиционные, и новые общие элементы. Обновление только отправителя способно сделать отчёт беднее.

Datatracker указывает статус активного индивидуального Internet-Draft. Пять новых номеров в заявке IANA ещё заменены TBD. Проверка с намеренно отсутствующим атрибутом средней метки, сохранённым шаблоном и восстановленными коллектором позициями покажет, удерживает ли программная цепочка эту границу.

Источники