Мутант-переросток, часть V
Кратенько про сервисы.
1) L2 VPN точка-точка
Тут все понятно.
2) L2 VPN многоточка, он же VPLS
Тут в принципе тоже все ясно. Те же туннели между PE свитчами, что в обычном VPLS, тот же лернинг на границе, тот же split horizon forwarding. Все то же самое. То же самое и в части мультикаста. А именно чудовищно неэффективная репликация на ingress node. Когда бродкастного/мультикастного трафика мало, то и фиг с ним. А от видео эта конструкция двинет кони.
Есть, конечно, выход. PBT может жить бок о бок с обычным *STP - некоторые VID используются для установки PBT-путей, а некоторые живут, как жили раньше, т.е. с STP. Можно взять один vlan, запустить в нем мультикаст, который будет фладиться человеческим образом, а на PE-свитче MVR'ом реплицировать его клиентам. Можно. Но это шаг назад. У нас опять возникает ненавистное дерево. Ясно, что это решение никак не тянет на Provider Backbone Transport.
Другого способа побороть проблему мультикаста в этой среде я не вижу. Фокус а-ля аткателевкий daisy chained VPLS здесь не пройдет. Никакого multipoint LSP, как в MPLS мире, здесь не предвидится. В общем, грустно.
3) L3 VPN
Вендоры, которые не умеют ничего умнее ethernet'а очень любят глубокомысленно говорить: "Over 95 percent of all data traffic originates and terminates on Ethernet ports." Они скромно молчат о том, что 99.99% of all data traffic travels the networks in IP packets. ;)
L3 VPN масштабируются существенно лучше, чем всяческий VPLS. Причем масштабируются лучше не только со стороны оператора, а, что более важно, со стороны клиента. Подход, основанный на сборе всех подряд в один широковещательный домен имеет очевидные ограничения. Поэтому, как ни крути, а продавать L3 VPN надо.
Что здесь предлагает PBT? А ничего.
Хочешь, бери обставляй свой PBT'шный "backbone" роутерами по кругу и запускай на них MPLS/BGP VPN. Хорошо? Абсолютно ничего хорошего.
Хочешь, стягивай клиентов L2 point-to-point туннелями к паре роутеров, которые и исполняют L3 VPN. Хорошо? Да тоже ничего приятного.
Хочешь, выстраивай полноценный MPLS домен, а PBT используй для агрегации. Уже теплее. Только это уже не backbone transport, а совсем даже aggregation. Если б оно еще управлялось по человечески - сигнализацией. ;)
4) Трипельплей и прочий новомодный IPTV
См. пункт 2 про мультикаст.
Все. Хватит. Надо закруглять.
Итак. Что такое этот PBT? По своей сути, это такой недо-MPLS. С неясным позиционированием, с недостатками в области масштабирования, в области восстановления, в области сервисов.
Единственный плюс этого PBT - это более низкая стоимость компонентов forwarding plane. Однако, если довести функциональность PBT'шного forwarding plane до той степени, что он сможет избавиться от своих недостатков, этот forwarding plane станет стоить ничуть не дешевле MPLS'ного, а думается, что и дороже.
Может быть, PBT найдет свое место в сети агрегации, подтягивая клиентов к сети. Однако, непонятно, что делать с мультикастом - уж больно не хочется назад к *STP. Однако IEEE с некоторых пор разрабатывает 802.1aq - shortest path bridging как замену *STP в ethernet сетях. Это, на мой взгляд, выглядит привлекательней для сети агрегации, чем PBT.
This entry was originally posted in my livejournal
Тут все понятно.
2) L2 VPN многоточка, он же VPLS
Тут в принципе тоже все ясно. Те же туннели между PE свитчами, что в обычном VPLS, тот же лернинг на границе, тот же split horizon forwarding. Все то же самое. То же самое и в части мультикаста. А именно чудовищно неэффективная репликация на ingress node. Когда бродкастного/мультикастного трафика мало, то и фиг с ним. А от видео эта конструкция двинет кони.
Есть, конечно, выход. PBT может жить бок о бок с обычным *STP - некоторые VID используются для установки PBT-путей, а некоторые живут, как жили раньше, т.е. с STP. Можно взять один vlan, запустить в нем мультикаст, который будет фладиться человеческим образом, а на PE-свитче MVR'ом реплицировать его клиентам. Можно. Но это шаг назад. У нас опять возникает ненавистное дерево. Ясно, что это решение никак не тянет на Provider Backbone Transport.
Другого способа побороть проблему мультикаста в этой среде я не вижу. Фокус а-ля аткателевкий daisy chained VPLS здесь не пройдет. Никакого multipoint LSP, как в MPLS мире, здесь не предвидится. В общем, грустно.
3) L3 VPN
Вендоры, которые не умеют ничего умнее ethernet'а очень любят глубокомысленно говорить: "Over 95 percent of all data traffic originates and terminates on Ethernet ports." Они скромно молчат о том, что 99.99% of all data traffic travels the networks in IP packets. ;)
L3 VPN масштабируются существенно лучше, чем всяческий VPLS. Причем масштабируются лучше не только со стороны оператора, а, что более важно, со стороны клиента. Подход, основанный на сборе всех подряд в один широковещательный домен имеет очевидные ограничения. Поэтому, как ни крути, а продавать L3 VPN надо.
Что здесь предлагает PBT? А ничего.
Хочешь, бери обставляй свой PBT'шный "backbone" роутерами по кругу и запускай на них MPLS/BGP VPN. Хорошо? Абсолютно ничего хорошего.
Хочешь, стягивай клиентов L2 point-to-point туннелями к паре роутеров, которые и исполняют L3 VPN. Хорошо? Да тоже ничего приятного.
Хочешь, выстраивай полноценный MPLS домен, а PBT используй для агрегации. Уже теплее. Только это уже не backbone transport, а совсем даже aggregation. Если б оно еще управлялось по человечески - сигнализацией. ;)
4) Трипельплей и прочий новомодный IPTV
См. пункт 2 про мультикаст.
Все. Хватит. Надо закруглять.
Итак. Что такое этот PBT? По своей сути, это такой недо-MPLS. С неясным позиционированием, с недостатками в области масштабирования, в области восстановления, в области сервисов.
Единственный плюс этого PBT - это более низкая стоимость компонентов forwarding plane. Однако, если довести функциональность PBT'шного forwarding plane до той степени, что он сможет избавиться от своих недостатков, этот forwarding plane станет стоить ничуть не дешевле MPLS'ного, а думается, что и дороже.
Может быть, PBT найдет свое место в сети агрегации, подтягивая клиентов к сети. Однако, непонятно, что делать с мультикастом - уж больно не хочется назад к *STP. Однако IEEE с некоторых пор разрабатывает 802.1aq - shortest path bridging как замену *STP в ethernet сетях. Это, на мой взгляд, выглядит привлекательней для сети агрегации, чем PBT.
This entry was originally posted in my livejournal
0 TrackBacks
Listed below are links to blogs that reference this entry: Мутант-переросток, часть V.
TrackBack URL for this entry: http://net-geek.org/cgi-bin/mt/mt-tb.cgi/53
