Кратко

  • RFC 3468 зафиксировал консенсус сосредоточить работу MPLS на RSVP-TE для traffic engineering и не начинать новую работу по CR-LDP.
  • Этот консенсус не выбирает сеть, реализацию или сервис: статус документов, внешние ссылки и эксплуатационные решения существуют отдельно.

Что именно приняло IESG

RFC 3468 был опубликован в феврале 2003 года как Informational RFC. Его заголовок прямо говорит о решении по фокусу работы MPLS Working Group. В документе описан спор о направлении между RSVP-TE и CR-LDP. Получившийся консенсус заключался в том, чтобы сосредоточить для traffic engineering работу на RSVP-TE и не предпринимать новой работы по CR-LDP; IESG этот консенсус принял.

Это утверждение о границах полномочий рабочей группы. Оно не требует от оператора удалить действующий протокол из сети, не объявляет одну реализацию верным выбором и не определяет выбор LSP или услуги. Превращая его в сетевое предписание, читатель смешивает программу работы, статус RFC и решение в конкретной операционной среде.

Что решение оставило без изменения

В RFC 3468 намеренно перечислено то, чего оно не меняет. Документ не предлагает менять статус RFC 3212 или его расширений и не отзывает их. Он требует сохранить возможность ссылаться на документы, поскольку организации вне IETF могут продолжать использовать такие ссылки и обновлять их в собственном темпе. Также документ не призван мешать отдельным людям продолжать работу, хотя продолжение работы группы по этому пути не поощряется.

Эти оговорки не являются формальностью. Отсутствие новой групповой работы не удаляет документ. Сохраняемая ссылка не является рекомендацией развернуть технологию. А свобода отдельного участника не создаёт официальную программу. Только такое разделение защищает запись о стандартизации от слишком широкого вывода.

Узко подтверждённая роль Loa Andersson

Публичный профиль IETF Loa Andersson связывает его с RFC 3468. Подтверждённый здесь вклад — совместная с George Swallow подготовка документа, а не текущая власть над чужими сетями или выбором их реализаций. Поэтому корректный профиль приписывает ему участие в формулировании границы работы и требует отдельных, сетевых и датированных доказательств для эксплуатационных выводов.

В RFC приведён также опрос июня 2002 года: 22 из 23 ответов упоминали RFC 3209 для сигнализации GMPLS, а три — RFC 3212. Это историческое свидетельство о небольшой выборке в определённый момент, а не современная рыночная статистика и не автоматическое предписание для последующего внедрения.

Почему граница устава имеет значение

Полезная версия этой истории звучит не как «победа протокола». Добровольная группа стандартизации направила ограниченное время участников и аккуратно описала пределы такого решения. Для аудита и архитектурных решений последующие утверждения стоит соотносить с видом доказательства: решения по уставу — с направлением работы, метаданные RFC — со статусом, внешние источники — со ссылками, а операционные данные — с фактическим развёртыванием.

Источники