Кратко

  • Сервис MEF Ethernet Tree назначает каждой линии доступа роль Root или Leaf. Leaf может обмениваться трафиком с Root, но не с другими Leaf; обычный VPLS считает линии равноправными.
  • Прямо обозначенный как гипотетический пример с двумя пограничными маршрутизаторами в RFC 7152 показывает, почему адреса назначения и доставки кадра недостаточно: удалённый узел не знает роль линии-источника.
  • Меморандум 2014 года задаёт требования — несколько Root, смешанные роли на одном узле и обратную совместимость. Последующие RFC описывают модели и механизмы, но не доказывают внедрение или результат услуги.

Анализ

Роль была свойством линии доступа

Ethernet Tree — это многоточечная услуга с корнем. Линия Root может обмениваться трафиком с другими Root и Leaf. Линия Leaf может обращаться к Root, но передавать трафик другой Leaf нельзя. Ethernet LAN устроена иначе: её линии доступа могут взаимодействовать друг с другом.

Когда услуга проходит через сеть оператора, различие становится эксплуатационным. В примере RFC 7152 два пограничных маршрутизатора подключают по одной клиентской линии Root и Leaf и пересылают кадры Ethernet через псевдопровод. Получивший кадр маршрутизатор видит, что он пришёл от удалённого PE. Но он может не знать, по какой локальной линии кадр вошёл в первый маршрутизатор и имела ли она роль Leaf.

Известный MAC-адрес назначения не снимает вопрос. Он показывает, куда адресован кадр, но не сообщает роль входной линии. Без неё удалённый узел не может надёжно применить запрет Leaf-to-Leaf к известному или неизвестному unicast, broadcast и multicast. RFC отдельно уточняет: схема дана для объяснения проблемы и не описывает типичную услугу.

VPLS переносил связность, но не эту политику

Существующая модель VPLS относилась к линиям доступа одинаково и обеспечивала связь между любыми точками внутри экземпляра. Это подходило для эмуляции Ethernet LAN, но не выражало отношение Root-Leaf, требуемое услугой MEF. Не хватало не ещё одного клиентского адреса, а свойства сервисного подключения, которое должно оставаться понятным после прохождения ядра оператора.

Поэтому RFC 7152 сформулировал требования, а не объявил готовое решение. Нужно было запретить обмен между Leaf, разрешить несколько Root и допустить Root- и Leaf-линии на одном пограничном узле. Решение также должно было указать применимую технологию VPN второго уровня и по возможности не нарушать существующие VPLS и EVPN. Если новую функцию поддерживали лишь некоторые PE, ограничение действовало только в совместимой части; документ не обещал сквозную изоляцию через неподдерживаемый сегмент.

Меморандум перечислил возможные сценарии: VPN «центр — филиалы», оптовый доступ, мобильный backhaul, синхронизация времени, доступ в Интернет, видео и управление устройствами. Это варианты использования из документа требований, а не статистика действующих сервисов. RFC также отличает E-Tree от обсуждавшейся тогда виртуальной частной multicast-услуги: E-Tree допускает unicast и multicast в рамках правил Root и Leaf, а multicast сам по себе не заменяет все эти потоки.

Последующие RFC назвали недостающий контекст

Опубликованная позднее в 2014 году RFC 7387 предложила архитектурную модель E-Tree и назвала два пробела: VPN второго уровня не различала роли линий доступа, а удалённый PE не получал указания, пришёл кадр от Root или Leaf. RFC 7796 позднее описала поддержку E-Tree в VPLS с разными VLAN-идентификаторами для кадров от Root и Leaf, чтобы фильтровать их на Leaf-портах. RFC 8317 расширила поддержку на EVPN и PBB-EVPN.

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

Исторический вывод уже, чем утверждение «кадр теряет источник». Кадр сохраняет адреса и проходит через транспорт. На границе уровней может потеряться знание оператора о сервисной линии, которая задаёт кадру роль при пересылке. Сеть способна доставить биты, но не иметь контекста, нужного для исполнения условий услуги.

Источники

Карточка RFC 7152 в каталоге RFC Editor подтверждает статус публикации.

Основной источник — RFC 7152: он задаёт требования и называет пример с двумя PE гипотетическим. RFC 7387, RFC 7796 и RFC 8317 описывают архитектуру и последующие механизмы для VPLS и EVPN. Эти документы подтверждают содержание спецификаций, но не показатели внедрения, конфигурации операторов, измерения трафика или конкретный эксплуатационный результат.