Кратко

  • RFC 5654 — документ Standards Track от сентября 2009 года; Deborah Brungard входит в число его пяти редакторов. В нём сказано, что требования MPLS-TP относятся к поведению механизмов и процедур протокола, служащих строительными блоками. Документ прямо указывает, что это не требования к реализации и не описание функций, которые поддерживает реализация MPLS-TP.
  • RFC допускает создание транспортных путей статической или динамической конфигурацией и говорит, что сеть MPLS-TP и её пути могут полностью работать, включая OAM и защиту, при отсутствии плоскости управления. Это предусмотренные варианты, а не доказательство текущего выбора оператора, установленного пути, трафика, переключения защиты или выполнения SLA.

Профиль задаёт инструменты, а не выбирает сеть

Слово «профиль» легко услышать как описание уже готового устройства мира: совместимые устройства, определённая топология, возможно, готовая к продаже услуга. RFC 5654 осторожнее. Он формулирует требования к MPLS Transport Profile и объясняет, что они относятся к поведению механизмов и процедур протокола, из которых строится этот профиль. Это не требования к реализации.

Во введении граница становится практической. Документ определяет, какие возможности должны быть доступны в инструментарии MPLS и какая новая работа над протоколом требуется. Он не описывает, какие функции поддерживает конкретная реализация MPLS-TP. Это спецификация требований, помещённая на Standards Track, чтобы на неё можно было нормативно ссылаться в работе ITU-T. Общая точка отсчёта может быть важной, не становясь ни перечнем функций продукта, ни конфигурацией в эксплуатации, ни приказом оператору выбрать определённую модель работы.

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

Статика, динамика и отсутствие плоскости управления — разные состояния

RFC 5654 говорит, что транспортные пути MPLS-TP могут устанавливаться статической или динамической конфигурацией. Он также утверждает, что сеть MPLS-TP и её транспортные пути всегда могут полноценно работать, включая OAM и защиту, без какой-либо плоскости управления. Текст сохраняет пространство выбора для того, кто отвечает за сеть; он не выбирает метод за названную сеть.

Раздел о плоскости управления сохраняет то же разделение. Сеть MPLS-TP должна быть пригодна к работе без её использования. Если плоскость управления применяется, она должна поддерживать независимость топологий плоскости управления и плоскости данных; следовательно, отказ первой не означает отказ второй. Она также должна работать независимо от конкретных плоскостей управления клиентского или серверного слоя.

Эти фразы прежде всего запрещают быстрые выводы. Доступность динамической способности не доказывает её включения. Допустимость статического предоставления не доказывает наличия статической конфигурации. Возможность различить два типа отказа не доказывает здоровье любой из плоскостей в данный момент. Требование к OAM или защите тоже не доказывает, что произошло переключение, что оно было корректно настроено или что трафик клиента защищён. Для каждого утверждения требуется свидетельство системы, которой принадлежит соответствующее состояние.

Общее правило не стирает административные границы

RFC признаёт, что за одну сеть слоя или за разные сети слоёв могут отвечать различные административные группы. Он требует возможности скрывать от клиентских слоёв адресацию сети слоя MPLS-TP и другую информацию, например топологию. По выбору оператора между слоями может передаваться ограниченная сводная информация, например SRLG или достижимость.

Это намеренно скромное общее правило: оно делает границу возможной, но не отменяет её. Клиентский слой не получает автоматически право видеть полную нижележащую топологию, а реализация сама по себе не раскрывает административную модель оператора. Если сводка опубликована, её источник, охват, свежесть и политика остаются проверяемыми фактами. Если её нет, нельзя восстанавливать воображаемую универсальную топологию из механизмов, которые RFC всего лишь допускает.

Работающая система должна выдать собственные квитанции

Для конкретного утверждения о транспорте нужна более длинная цепочка свидетельств, чем сам документ. Запись о реализации может показать версию программного обеспечения и поддерживаемые функции. Системы управления или контроля могут показать способ предоставления, намерение пути и действие сигнализации. Плоскость пересылки может показать установленное состояние и счётчики. OAM может зафиксировать, что именно проверялось, когда и между какими конечными точками. Записи о защите могут показать условие запуска, действие и результат. Лишь измерение услуги способно показать итог на согласованной границе клиента.

RFC не заменяет ни одну из этих квитанций. Он даёт общий язык, на котором могут проектироваться определённые системы. Он не доказывает матрицу поддержки поставщика, инвентарь, топологию, путь, поток, отказ, событие защиты или опыт клиента. Использовать его как такое доказательство — значит спутать стандарт с оператором, а доступную способность с осуществлённым внедрением.

Здесь полезно различие Heng Lu между минимальной общей спецификацией и локализованными будущими решениями. Общая спецификация координирует то, что обязано быть общим; последующие решения остаются у тех, кто запускает системы. Артефакт координации не становится операционной реальностью только потому, что опубликован. Сила RFC 5654 именно в том, что он не превращает свой инструментарий во всеобщее предписание реализации.

Признать редакторскую работу Брунгард, не приписывая ей чужую власть

RFC 5654 называет редакторами Ben Niven-Jenkins, Deborah Brungard, Malcolm Betts, Nurit Sprecher и Shigeru Ueno. Публичный профиль Brungard в IETF Datatracker идентифицирует её и даёт происхождение публичной фотографии, на которой основан редакционный портрет. Это поддерживает ограниченную атрибуцию: она редактировала совместный документ требований.

Источники не доказывают, что она написала RFC одна, выбрала последующую реализацию, управляет нынешними решениями IETF или ITU-T, эксплуатирует сеть оператора или гарантирует транспортную услугу. Точная атрибуция сильнее преувеличения: она признаёт работу над общей технической границей и сохраняет реализацию, конфигурацию, наблюдение и ответственность за реальную сеть за локальными участниками.

Границы доказательств

Источники устанавливают содержание RFC 5654 и выраженные в нём пределы. Они не устанавливают текущее применение MPLS-TP конкретным оператором, место внедрения, живой путь, топологию, состояние плоскости управления, результат OAM, действие защиты, трафик или клиентский опыт. Описанная здесь цепочка квитанций — операционное прочтение этих границ, а не новое требование к RFC.

Источники