Кратко
- RFC 9160 добавляет пять значений к
mplsTopLabelType(46), чтобы запись IPFIX могла указать заданный контекст выделения MPLS Segment Routing, а не выдавать число метки за доказательство происхождения. - Типизированный экспорт способен поддержать ограниченное расследование; он не доказывает завершённую миграцию, работающий маршрут, установленную политику или результат сервиса.
Верхняя MPLS-метка — это наблюдаемый числовой факт. IPFIX позволяет его экспортировать, а аналитика — сгруппировать. Ошибка начинается, когда к числу добавляют незафиксированную биографию: будто оно само назвало протокол, который его выделил. RFC 9160 вводит не такую биографию, а недостающий различитель в самом экспортируемом описании.
IETF Informational RFC был опубликован в декабре 2021 года; единственный указанный автор — Thomas Graf из Swisscom. Документ определяет пять кодовых точек для существующего информационного элемента IPFIX mplsTopLabelType(46): Path Computation Element, OSPFv2 Segment Routing, OSPFv3 Segment Routing, IS-IS Segment Routing и BGP Segment Routing Prefix-SID. Они позволяют записи выразить предусмотренный контекст MPLS SR протокола плоскости управления для данного типа метки.
Причина в том, что номер не является самораскрывающимся идентификатором. RFC 9160 говорит, что IGP adjacency SID, LDP и динамические BGP-метки могут пользоваться общим диапазоном выделения. Одна и та же видимая величина может соответствовать нескольким механизмам. Вывести протокол из голого числа значит заменить числовое совпадение доказательством происхождения, которого поле не содержит.
Описанные в RFC применения — это наблюдение, а не объявление победы. Оператор может отслеживать переход от LDP к IS-IS или OSPF Segment Routing, либо от динамических BGP-меток к BGP Prefix-SID. В сочетании с типом другие прямо названные элементы IPFIX — адреса верхней метки, участок стека и forwarding status — могут поддержать выводы о количестве пересланных или отброшенных пакетов, возможных причинах отброса, loopback-адресе provider edge и протоколе метки. Формулировка важна: поддержать выводы не значит самостоятельно подтвердить событие.
Такая запись не является сертификатом эксплуатации. RFC и значение реестра не показывают, что определённый exporter включён, collector увидел полный набор, запись аутентична или наблюдение охватило нужный путь. Тип поля не доказывает, когда миграция началась или закончилась, почему выбрана policy, дошёл ли пакет до назначения и получил ли пользователь результат. Более точная семантика не отменяет границ наблюдения, сбора и охвата.
Два значения BGP в RFC 9160 особенно наглядны. Существующая кодовая точка BGP 4 относится к значению метки в атрибуте пути MP_REACH_NLRI. Новая кодовая точка 10 для BGP Segment Routing Prefix-SID относится к значению индекса метки в TLV Label-Index. В разговоре оба объекта можно назвать BGP-меткой, но технически это разные предметы. RFC сохраняет различие до того, как общий ярлык сделает его невидимым.
Sofia Ren применяет здесь метод Lu Heng как дисциплину минимального проверяемого высказывания. Документ координации и реестр способны зафиксировать семантику, но не объявить ненаблюдаемую работу свершившейся. Минимально защищаемый факт таков: exporter при названных условиях наблюдения и сбора представил в записи IPFIX определённый тип выделения верхней метки. Для вывода о control plane, forwarding или сервисе нужны отдельные источники именно этих фактов.
Поэтому расследование должно хранить исходный экспорт, идентичность exporter, точку наблюдения, интервал сбора, template, границу целостности и конкретные поля корреляции. Утверждение о плоскости управления сверяется с её собственными записями; утверждение о пересылке — с доказательством пересылки; утверждение о сервисе — с сервисной телеметрией. Ни номер, ни его тип не заменяют эти проверки.
Вклад Graf состоит не в том, чтобы сделать панель всеведущей. Он мешает приписать голому числу происхождение, которого оно не несёт. Результат — более чистая цепочка между типизированным фактом экспорта и историей сети, которая всё ещё требует доказательств во время реальной работы.
Источники
- RFC 9160 — Экспорт информации о типе MPLS Segment Routing метки в IPFIX
- IANA — Информационные элементы IPFIX
- RFC 7012 — Информационная модель IPFIX
- RFC 8660 — Segment Routing с плоскостью данных MPLS
- IETF Datatracker — Thomas Graf
- Heng Lu — Running-Code Primacy
- Heng Lu — Minimum Initial Specification
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
