[rainbowirdi]

Крутил 7750 от алкатель впечатление не очень. Проблем много было...

[tgz]

Даже и не завтра - это у всеми тут любимой цыски. Едем дальше. Много MAC'ов, нужно их прикрыть. Два пути:

1. MAC оператора. Проблемы learning'а остаются. Уёбищный сигналлинг там же. Топология только кольцо.

2. метка MPLS. Минус пожалуй один, дорого. Но это не на долго. И в свете Светлого Будущего под названием gmpls понятно у кого и что будет красивее. IETF на gmpls фапает давно и серьезно, так что никуда мы от этого не денемся.

 

Выбор есть. И время покажет кто прав, а кто виноват.

 

 

[Lovetc]

Про Nortel. Если достаточно оптики (или есть dwdm), то в ядре Nortel можно сделать split-mlt. Тогда вся эта конструкция превращается в простеший, практически неубиваемый "ящик", который очень (очень-очно-очень :) ) удобно администрировать без толпы инженеров прописывающих vlan/pwe или приблуд для этого, которые интеграторы впаривают за пару нерусских лямов. Один минус - действительно непонятно что с ними будет. Баги и сейчас лечат нормально, но например 10 GE MESU вышла только в варианте dual-homed. Видимо кто-то из топ-заказчиков успел пробить в таком виде и когда в софте появится поддержка обычного single-home непонятно.

P.S. Ну дружеские приколы "мы ESR карты больше не развиваем, покупайте теперь R-модули" видели у всех вышеперечисленных производителей, так что в минус это не пишем :)

 

P.P.S. Если вам не нужны общие фразы про протоколы, тренды и пр.:

1. нарисуйте точные логические схемы подачи сервисов/технологических каналов по вашей сети. Представьте как вы будете это включать на предлагаемом оборудовании. Желательно вживую на стенде. Потом представьте, что так нужно сделать хотя бы 100 раз в рабочий день :) Потом подумайте как это все документировать.

2. представьте обычные работы на сети. Смену софта, падение питания, переконфигурирование топологии оптики на разных уровнях и т.п. Нормальные такие задачи возникающие в ходе эксплуатации сети. Одно только упражнение "было кольцо в 10 access node - трафик вырос - давайте сделаем два по 5" будет для производителей оборудования очень занимательным

Изменено 29 октября, 2009 пользователем Lovetc

[inkelyad]

А за PBB скажу, что нужен он 100%.

Еще бы его сделали достаточно дешевым для того, чтобы соответствующую "умную розетку" прямо у абонента ставить. Так ведь не сделают -- будут функционал и цену ядра/агрегации "накачивать".

[rus-p]

PBB сейчас (на самом деле будет он даже и не завтра) лишь мифический способ наэкономить в CAM'е MAC адресов. Способ кривой. Нужный тут далеко не каждому. Я щетаю подохнет оно не родившись.

Кручу уже год, не на стенде, отзыв, с тем функционалом который есть у Алкателя, просто супер.

Кроме очевидных плюсов типа маков, сокращения времени изучения при флапе, есть не очевидный - провиженинг требуется только в точке подключения клиента, никаких псевдоваеров, и более тонких но очень важных технических вопросов, которые ломают голову в последующей техподдержке. За одно это, могу назвать это прорывом в технологии подключения клиента к L2 впн.

Изменено 30 октября, 2009 пользователем rus-p

[Fduchun]

Крутил 7750 от алкатель впечатление не очень. Проблем много было...

А поконкретней?

[JoeDoe]

А за PBB скажу, что нужен он 100%.

Еще бы его сделали достаточно дешевым для того, чтобы соответствующую "умную розетку" прямо у абонента ставить. Так ведь не сделают -- будут функционал и цену ядра/агрегации "накачивать".

Ну так я уже говорил про Alcatel-Lucent 7210 SAS-M -  там как раз идея функциональность ближе к клиенту предоставить. MPLS FRR/PWE/VPLS он уже умеет, PBB будет в начале 2010. Цена в разы меньше Catalyst 3750 Metro. Да и "маленькие" 7750 официально представили 28 числа. И по цене с ASR от Cisco вполне сопоставимо. Только backplane - 90 Гбит/с wire-speed routing. Тут еще Juniper со своим "New Network" MX 3D.

Я думаю, будет интересно посмотреть за схваткой за edge/access рынок (типа 7750SRc4 vs. MX80 vs. ASR) . Особенно когда core рынок (в России его нет) ну совсем никакой!

Читайте на ночь Чтиво!

 

[tgz]

А что, у откателя есть коробки с PBB, но без MPLS?

[JoeDoe]

А что, у откателя есть коробки с PBB, но без MPLS?

Про откатель не знаю - не видел ;)

A в 7450/7750 PBB интегрирован как расширение в концепцию VPLS. При этом если вы на дух не переносите MPLS/LDP/RSVP сигналинг и т.п, а хотите весь backbone на 802.1ah сделать - пожалуйста, используйте b-sap вместо sdp. Про G.8031 тунеллинг не уверен, так как концепция Alcatel-Lucent в интеграции VPLS и PBB. В таком случае, вам действительно не нужно прописывать новые PW "сотнями каждый день" на бэкбоне - создайте несколько b-vpls на все случаи ваших архитектур L2vpn и мапируйте туда пользовательские сетки. По-моему это намного более удобно и управляемо, чем один 802.1ah домен с управлением по (M)STP (sic!).

[Fduchun]

А что, у откателя есть коробки с PBB, но без MPLS?

Небольшой флейм: PBB но без MPLS - это всего лишь MAC in MAC с тем же опасным и малопредсказуемым STP, RSTP, MSTP - оно вам надо? Посадить еще больше клиентов на кривую технологию восстановления, без OAM, без автоматического провижениннга услуг?

 

Даю справку: Нортел имел единственного в мире потенциального большого клиента для PBB-TE, которому мыл мозги - British Telecom. В конце концов Alcatel-Lucent сделал реальное, единственное в мире решение PBB + VPLS, чем решил попутно кучу проблем самого VPLS. Нортел так ничего рабочего и не родил, вследствие чего в BT про развитие на Нортеле забыли. После этого весь шум вокруг как PBB, так и PBB-TE сошел на нет.

 

Ну а по теме вопроса: Alcatel-Lucent вроде как обещает со временем поддержку PBB в чистом Ethernet коммутаторе - 7210 SAS-M, но вот когда это будет - вопрос большой. Так что без MPLS пока нету.

Изменено 31 октября, 2009 пользователем Fduchun

[tgz]

Ну раз нету, то таки ***й мне PBB, если MPLS в коробке?

К PBB-TE, который IEEE 802.1Qay, Nortel уже никакого отношения не имеет.

[JoeDoe]

Ну раз нету, то таки ***й мне PBB, если MPLS в коробке?

К PBB-TE, который IEEE 802.1Qay, Nortel уже никакого отношения не имеет.

Читайте посты выше - PBB при использовании с VPLS упрощает provisioning и решает проблемы с масштабируемостью в сетях провайдера.

Так что PBB (802.1ah) нужен, а вот 802.1Qay – большой вопрос...

Изменено 31 октября, 2009 пользователем JoeDoe

[tgz]

Ну давайте разберемся. Начнем с малого. На основании чего BEB ставит в пакет B-DA, B-TAG и I-TAG?

[Bambuk]

S-vlan -> I-Tag

 

C-DA,S-vlan,I-Tag -> B-DA,B-SA,B-Tag

 

после чего передаем B-DA,B-SA,B-Tag по MPLS.

 

Чем вам тут MPLS не нравится? Или вы наоборот считаете что если есть MPLS, то все эти дополнительные инкапсуляции не нужны?

[Fduchun]

Ну раз нету, то таки ***й мне PBB, если MPLS в коробке?

Это вопрос масштаба.

PBB нужен для решения проблемы резкого роста MAC таблицы на PE-rs маршрутизаторах при использовании H-VPLS архитектуры. То есть формально в H-VPLS клиенты подключаются к MTU-s устройствам, а те в свою очередь либо через MPLS PW, либо через Q-in-Q к PE-rs. И full mesh туннелей у вас только между PE-rs. За счет этого растет масштабируемость VPLS услуги (не нужен везде full mesh туннелей при росте подключений, меньше проблем с сигналингом и прочее).

Но H-VPLS порождает проблему ресурса MAC таблицы на PE-rs, к которому вроде как клиенты напрямую не подключаются, но вот клиентские MAC адреса он коммутировать должен. :( Кроме того размера памяти под MAC, большое количество MAC адресов скапливающемся на одном устройстве влиеяет на скорость сходимости, так как MAC learning rate величина конечная даже на больших и дорогих коробках: при 100К адресах в MAC таблице и MAC learning rate в 50К в секунду в худшем случае сходимость будет 2 секунды, что не есть гуд.

Использование PBB поверх VPLS (а точнее, H-VPLS), решает обе проблемы разом.

MTU-s упаковывает клиентские MAC в B-MAC и B-Tag и передает в облако. Это сильно снижает нагрузку на PE-rs - он видит только B-MAC адреса и все, а так как их немного, то и сходимость растет.

Дополнительно решается проблема с сигналингом. В H-VPLS каждый отдельный клиентский VPLS имеет свою метку, что есть ресурсы LDP и так же влияет на сходимость - пока маршрутизаторы по LDP всеми метками сервисов не обменяются, форвардинг не заработает. А PBB внутри VPLS позволяет иметь вообще один MPLS VPLS и внутри него через PBB клиентские сервисы, что снижает нагрузку на сигналинг и опять же уменьшает время сходимости.

 

Как видим, такая конструкция нужна только для очень больших сетей. В мире их немного и пока PBB + VPLS используется только в нескольких больших конторах (возможно, COLT) и у одного оператора в России (вроде как для предоставления VPLS или VLL для юр. лиц.). Кстати, у British Telecom, который так очень желал видеть PBB и PBT от Нортела конструкция PBB + VPLS коммерчески вроде как не запущена, им пока хватает обычного VPLS.

Изменено 31 октября, 2009 пользователем Fduchun

[JoeDoe]

Спасибо за развёрнутый рассказ про PBB + VPLS, коллега.

Хотелось бы только добавить: для уменьшения времени сходимости LDP, что становится критичным при появлении большого количества MPLS устройств в сети (MTU-s) понадобятся всё-таки некоторые изменения в сигналинге. Думаю, появление LDP DoD (Downstream-on-Demand) решит и проблему роста таблицы меток.

[tgz]

S-vlan -> I-Tag

 

C-DA,S-vlan,I-Tag -> B-DA,B-SA,B-Tag

 

после чего передаем B-DA,B-SA,B-Tag по MPLS.

 

Чем вам тут MPLS не нравится? Или вы наоборот считаете что если есть MPLS, то все эти дополнительные инкапсуляции не нужны?

Именно. От MAC learning'а мы же никуда не делись. Просто убрали его чуть дальше. Ну хорошо, будь это коробка без MPLS и с ценой на порядок меньше. Но ведь нет. Никто не мешает немного допилить сигналинг в MPLS и получить все то же самое, но с меткой. Картинка получится куда более стройной и простой.

В PBB же у нас сигналинг весь изярнетовский, с STP и прочим, как мне помнится. Но тут могу ошибаться.

Так что с точки зрения стройности архитектуры - PBB есть костыль. Временный и ненужный. MPLS все равно сползет вниз и выдавит его оттуда.

 

[Bambuk]

Вот с изярнетовским сигналингом, в частности с STP есть проблемы. Чтоб их обойти и нужно использовать MPLS. Если вас не смущает STP и например полсотни ядреных свичей на L2, то можно и без MPLS.

[tgz]

В PBB-TE никакого STP нет. В TRILL тоже. ***й мне PBB, если там STP? Такой балет нам не нужен.

[Bambuk]

Я что-то не понимаю что вам не нравится. То что железки с достаточным функционалом дорого стоят и эта цена на ваш взгляд не оправдана?

[Fduchun]

В PBB-TE никакого STP нет. В TRILL тоже. ***й мне PBB, если там STP? Такой балет нам не нужен.

А какой сигналинг есть в PBB-TE?

Сначала нам пели песни, как зашибись все делать через внешнюю систему управления. Но вопросы про ее стоимость, реакцию на изменения в сети, интеграцию и прочее последователями PBT всегда опускались, как неудобные.

Потом стали петь песню про GMPLS в качестве сигнализации, но тогда возникал вопрос - нафига козе боян, в чем смысл PBT и ее упрощение по сравнению со "сложным" MPLS, если там надо будет использовать GMPLS?

Под конец своей жизни Нортел начал пихать идею, что для динамического присоединения PE к услуге нужен динамический протокол, который Нортел предлагал сделать на базе IS-IS... Ну в общем, идея понятна.

 

Поэтому, пока PBT не ответит внятно - как все это будет работать и пока сторонники PBT типа Ciena или Ericsson не предложат на рынок рабочее РЕШЕНИЕ, которое как они обещают будет по цене обыных Enterprise коммутутаторов - все это marketing bullshit.

 

Если что и вырастет из этого стандарта - то это будет видно через несколько лет.

Но самое большое подозрение вызывает факт, что если технология действительно НУЖНА клиентам, то крупные операторы (DT, BT, AT&T и прочие) не просто смотрят в лабах вендоров железо построенное на черновых еще редакциях, но и уже развертывают сети на которые это железо ставят, обкатывают технологию и дальше ее затачивают.

Про PBT ничего подобного не было слышно ни в процессе развития, ни после ратификации. Что наводит на подозрения, что кроме как IEEE этот PBT никому не нужен.

[JoeDoe]

Можно в PBB-TE и без STP.

G.8031 это только link protection. Но для полной замены MSTP вам будет нужен G.8032 v2. Работающий.

По-моему всё это пока больше в теории (где стройные ряды производителей?!). А MPLS давно и успешно в сетях практически всех операторов. Да и готов кто либо из операторов перейти с IP/MPLS на Pure Ethernet как основу своей сети?!

[Fduchun]

И продолжая этот флейм, скажу что пока про выпуск массового чипсета под PBT ничего не сказано, в то время как Broadcom выпустил семейство чипсетов под MPLS - BCM 5662X. И на них уже начали появляться недорогие MPLS железки - Huawei S9300, например.

Конечно, MPLS там не такой мощный, как на больших коробках, но для Metro агрегации или небольших сетей этого более чем достаточно.

[Cr_net]

А за PBB скажу, что нужен он 100%. Если у вас на PE 1000 клиентов с сетками (VPLS) по 1000 MAC каждая, то PE должен держать MAC таблицу в миллион адресов. Это что ж за рутер должен быть! По-этому PBB реально спасает ситуацию с масштабированностью услуг на PE.

Вот честно, мне трудно представить ситуацию, что кто то из клиентов юриков будет объединять офисы на 1000 хостов, не поставив в таких офисах роутер, ибо самому клиенту траблшутить такую свою сеть, что с pbb, что без - это проще застрелиться. Количество маков расти будет на за счёт услуг vpls, а за счёт физиков. Которых терминировать надо непосредственно в pe c функционалом браса. Если алкатель дальше будет развиваться по пути люцента, а не тиметры выдумывая очередной масштабируемый чистый езер на костылях то это плохо.

[JoeDoe]

А за PBB скажу, что нужен он 100%. Если у вас на PE 1000 клиентов с сетками (VPLS) по 1000 MAC каждая, то PE должен держать MAC таблицу в миллион адресов. Это что ж за рутер должен быть! По-этому PBB реально спасает ситуацию с масштабированностью услуг на PE.

Вот честно, мне трудно представить ситуацию, что кто то из клиентов юриков будет объединять офисы на 1000 хостов, не поставив в таких офисах роутер, ибо самому клиенту траблшутить такую свою сеть, что с pbb, что без - это проще застрелиться. Количество маков расти будет на за счёт услуг vpls, а за счёт физиков. Которых терминировать надо непосредственно в pe c функционалом браса. Если алкатель дальше будет развиваться по пути люцента, а не тиметры выдумывая очередной масштабируемый чистый езер на костылях то это плохо.

Всё действительно уже перешло во флейм...

Что что, а развитие Alcatel-Lucent в области IP/MPLS/CarrierEthernet уже лет шесть определяет команда Тиметры (Basil Alwan всё это время руководитель IP Division). Даже софт для последних продуктов (типа 7210) называется TiMOS. И никто там "чистый езер" и не видет как основу для бэкбона. PBB (а не PBT) был сделан, как расширение к VPLS для решения проблем масштабируемости и управления (читайте посты выше). A BRAS никто делать точно не будет. Зачем? Если серия 7750 и так может терминировать тысячи клиентов интернета со всеми функциями BRAS-a (IPoE, PPPoE, DHCP, Radius, IPSec, DPI). Плюс L2VPN и L3VPN для бизнеса и SGW/PGW для LTE EPC в одном ящике. С названием CNG (converged network gateway). Который является частью общей HLN (High Leverage Network) - стратегии развития сетей, по версии Alcatel-Lucent.

Изменено 1 ноября, 2009 пользователем JoeDoe