Autor: Piotr Oniszczuk (wolodzia_at_kki.net.pl)
Data: Sun 03 Nov 2002 - 18:19:34 MET
Grzesiek Pawelski <gpawelsk_at_elka.pw.edu.pl> wrote:
>
>
> On Thu, 31 Oct 2002 wolodzia_at_kki.net.pl wrote:
>
> > > MPLS jest przystosowany do potrzeb IP. Mozesz wyszczegolnic
> > > parametry dla poszczegolych rodzajow ruchu w swojej sieci,
> > > np. oddzielnie dla VoIP i web. Pakiety beda traktowane w odpowiedni
> >
> > Och, to czy możesz wyszczególnić parametry (per usługa), czy nie -
> > zależy od implementacji. Jeśli implementacja oferuje QoS na MPLS a'la
> > E-LSP lub L-LSP - Ok, jednak w MPLS - dziś - jest to wyłącznie kwestia
> > implementacji dostawcy.
>
> operator wydaje gruba kase na MPLS w jakims celu zazwyczaj.
Wiesz, w większości przypadków dziś jest to wynik mody ;-).
Co do faktycznych korzyści - jedyne co mówią operatorzy z MPLS'owym
doświadczeniem o sensowności MPLS to TE (traffic engenieering).
Dobre narzędzie do TE zapuszczone na optymalizację Offline może dać do
30-35% uzysku z danej infrastruktury. Ten uzysk występuje jednak
wyłącznie w sieciach mocno obciążonych (z niemałą liczbą linków
przeciążonych) - co w przypadku dużych szkieletowych sieci IP jest
rzadkością. Tzw MPLS VPN - to bardzie hasło niż unikalna technologia.
Control plane opiera się ma MP-BGP, zaś MPLS w data plane po prostu
łatwiej robi pewne rzeczy (label stacking). Nic nie stoi na
przeszkodzie, żeby w data plane dać np. GRE....
Teoria MPLS jest dość chwytliwa (np. połączeniowy charakter - jak w
ATM - ma gwarantować QoS), jednak jak spojrzysz na dzisiejsze
wdrożenia - to tylko obiecanki (choć są dziś całkiem niezłe
mulitserwisowe switche dające dla MPLS absolutny QoS).
>
>
> > Dokładnie odworotnie jest w ATM - ATM forum TM4.0 definiuje 5 klas QoS
> > - to jest standard (piękna sprawa).
> >
>
> no i co z tego, ITU zawsze wszystko musi zestandaryzowac ;)
No i nic z tego.
Lepiej mieć standard, niż nie mieć. W ATM masz AINI, NNI PNNI, itp -
możesz spokojnie połączyć dwie różne sieci operatorskie i spokojnie
zestawiać SVC między nimi - będzie chodziło cacy (pełne QoS z TM4.x
itp).
W świecie IP, IETF dopiero pracuje nad InterAS BGP extensions. Jednak
nawet jeśli dopracuje te drafty - masz jedynie rozwiązaną sprawę BGP
(chodzi głównie o budowę VPN'ow L3 fizycznie obejmujących kilka sieci
operatorskich, każda przecież z różnymi AS). A co z QoS... daleka
droga.
Wiesz - jest szkoła otwocka i szkoła falenicka....
> Operator zawsze moze zaimplemetowac klasy dla swoich SLA.
> Nie potrzebuje do tego standardow ITU, ani nawet RFC.
>
>
> > RFC2547bis (w zasadzie to RFC powinno być punktem odniesienia przy
> > rozważaniach o VPN L3) nie wymaga stosowania koniecznie BGP na styku
> > CE-PE. Zazwyczaj lepiej jest polegać na RIPv2 (starocie) lub OSPF.
> > Wiesz - nie każdy admin u klienta zarządzający ruterem CE zna BGP, zaś
> > OSPF jest tutaj też OK i jest prostszy.
>
> Zazwyczaj BGP uznawane jest za najlepszy protokol na styku
> administracyjnym sieci, i nie chce mi sie tlumaczyc dlaczego.
Wiesz, niechce mi się pisać - choć definicja VPN jednoznacznie
sugeruje, że VPN to pojedyńcza forma administracyjna.... - wszak masz
np. takie pole w IP-VPNv4 - ale.......niechce mi się pisać
>
>
> > Generalnie - VPN L2 - to jest piękna sprawa. Np. wg. draftu
> > Laserre.....
> >
>
> Nie wiem, w praktyce widzialem tylko L3.
Szkoda - myślałem że będzie ciekawie
>
>
> Pzdr,
> Grzesiek
-- cYa, 3.14iotr/2 Dobry programista wiesza się z programem.... Hiroshima'45; Czernobyl'86; Windows'95 Zwrotne bajty daj na "wolodzia_at_kki.net.pl"
To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 18:02:38 MET DST