Czesc,
Czy macie moze jakies doswiadczenia z sieciami VPN realizowanymi w MPLS
?
Chodzi mi o oferty operatorow w Polsce. Z tego co udalo mi sie znalezc w
sieci to taka oferte ma Telenergo i Crowley. Czy od strony klienta jest to
bardziej ciekawa oferta niz PVC ATM/FR ?
MJ

do góry

Marcin Jarota wrote:

>Czesc,
> Czy macie moze jakies doswiadczenia z sieciami VPN realizowanymi w MPLS
>?
>Chodzi mi o oferty operatorow w Polsce. Z tego co udalo mi sie znalezc w
>sieci to taka oferte ma Telenergo i Crowley. Czy od strony klienta jest to
>bardziej ciekawa oferta niz PVC ATM/FR ?
>

A czego oczekujesz po tych VPN'ach?
IMHO jedyną ich zaletą jest większa różnorodność łącz, w stosunku do
ATM/FR. W szczególności dochodzi ethernet.
Moim zdaniem, poważną wadą jest to, że pomiedzy Twoimi węzłami widać
część infrastruktury providera (routery PE). Oczywiście są wynalazki
temu zapobiegające, typu FRoverMPLS czy ATMoverMPLS, ale trudno mówić tu
o zaletach w stosunku do czystych ATM/FR.
I jeszcze jedno: biorąc sytuację na dziś, raczej zapomnij o rezerwacjach
QoS (pasmo, opoźnienia). Zresztą nawet gdy zostaną porządnie
zaimplementowane, to i tak nie będą mogły się równać z rezerwacjami i
kontrolą parametrów w sieci ATM. Aczkolwiek będą porównywalne z FR.

do góry

On Thu, 31 Oct 2002, Marcin Jarota wrote:

> Czy macie moze jakies doswiadczenia z sieciami VPN realizowanymi w MPLS
> Chodzi mi o oferty operatorow w Polsce. Z tego co udalo mi sie znalezc w
> sieci to taka oferte ma Telenergo i Crowley. Czy od strony klienta jest to
> bardziej ciekawa oferta niz PVC ATM/FR ?

Sa jeszcze wezly operatorow miedzynarodowych: AT&T, Equant i chyba
Worldcom.

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
sposob w calej sieci operatora. Zeby osiagnac podobny efekt uzywajac
FR/ATM musialbys kupic oddzielne PVC/VC. Ryzyko ze operator nie
dotrzyma kontraktu jest podobne dla kazdej technologi. Dobry provider
MPLSa dostarcza statystyki QoS.

W przypadku duzej liczby siteow (duzego mesha) MPLS powinien byc
tez duzo tanszy niz FR/ATM.

MPLS VPN zapewnia routing IP pomiedzy siteami, zwykle zestawia sie
tylko sesje BGP pomiedzy routerem klienta a interfesem (nalezacym do
VRF klienta) routera providera (PE).


Pzdr,
Grzesiek

do góry

Marcin Jarota <m...@m...szczecin.pl> wrote:
> Chodzi mi o oferty operatorow w Polsce. Z tego co udalo mi sie znalezc w
> sieci to taka oferte ma Telenergo i Crowley. Czy od strony klienta jest to
> bardziej ciekawa oferta niz PVC ATM/FR ?

MPLS jest też w ofercie Dialogu:
http://www.dialogok.pl/dialog/internet/internet.php?
id=43

T.

do góry

Mariusz Krukowski napisal(a) [31 Oct 2002]:

> A czego oczekujesz po tych VPN'ach?

To jest najistotniejsze pytanie! Technologia (ATM/MPLS/lacze cyfrowe) ma
jedynie sluzyc spelnieniu tych oczekiwan.

> Oczywiście są wynalazki [...] typu FRoverMPLS czy ATMoverMPLS, ale
> trudno mówić tu o zaletach w stosunku do czystych ATM/FR.

Oczywiscie - nie ma sensu budowac sieci MPLS tylko po to, zeby przenosic
po niej ruch ATM. XoMPLS trzeba traktowac raczej jako emulacje, czyli cos
w stylu DLSW (przenoszenie SNA w IP), CES (przenoszenie TDM w ATM) czy XOT
(przenoszenie X.25 w TCP).

> I jeszcze jedno: biorąc sytuację na dziś, raczej zapomnij o
> rezerwacjach QoS (pasmo, opoźnienia). Zresztą nawet gdy zostaną
> porządnie zaimplementowane, to i tak nie będą mogły się równać z
> rezerwacjami i kontrolą parametrów w sieci ATM.

W jednym zdaniu polaczyles dwie rzeczy: "zapomnij o rezerwacjach" i
"pasmo, opoznienie". Mechanizmy ATM sa zupelnie inne, niz mechanizmy IP.
ATM jest zorientowany polaczeniowo, wiec rezerwacje dla polaczen robi
zdecydowanie lepiej. W IP praktycznie nie ma odpowiednika zestawiania
polaczen z okreslonymi parametrami (RSVP sie nie liczy), lecz nie jest to
technika polaczeniowa.

Natomiast z punktu widzenia uzytkowego (czyli efektow odczuwalnych przez
uzytkownika) mozna natomiast uzyskac takie same efekty - gwarancje
opoznienia i przepustowosci (zakladajac prawidlowo skonfigurowana siec).
Jezeli uzytkownik widzi takie same efekty, technologia lezaca pod spodem
nie jest zbyt istotna, o ile tylko jego VPN zachowuje sie zgodnie z
wymaganiami.

> [...o parametrach QoS w IP...] Aczkolwiek będą porównywalne z FR.

ATM i Frame Relay maja bardzo duzo wspolnego, obydwie technologie wywodza
sie z ISDN. Glowna roznica polega na tym, ze ATM ma kilka klas ruchu z
wieloma parametrami, zaprojektowanych dla konkretnych typow ruchu, podczas
gdy Frame Relay ma w zasadzie jedna klase.

W praktyce z klas ATM wykorzystuje sie: CBR do emulacji lacz stalych, UBR
do przenoszenia IP bez gwarancji i VBR-nrt do przenoszenia ruchu z pewnymi
gwarancjami. Jeszcze konkretniej: w wiekszosci sieci ATM dla transmisji
danych oferuje sie VBR-nrt. Pokusilbym sie tu o stwierdzenie, ze Frame
Relay odpowiada konceptualnie klasie VBR-nrt. Posiada podobne parametry:
CIR (~=SCR), MIR (~=MBS) oraz EIR (~=PCR). Analogiczny efekt mozna uzyskac
takze i w sieci IP dzieki mechanizmom ksztaltowania i ograniczania ruchu
(rate-limit, shaping). Takze znakowanie (FR DE, ATM CLP, IP DSCP) jest
dostepne i stosowane we wszystkich trzech technologiach.
W IP takze jest mozliwe (w zaleznosci od implementacji) tworzenie
rozmaitych klas ruchu IP z gwarancja opoznienia i/lub z gwarancja
przepustowosci.

--
(moskit-at-irc.pl)

do góry

Grzesiek Pawelski <g...@e...pw.edu.pl> wrote:

>
>
> On Thu, 31 Oct 2002, Marcin Jarota wrote:
>
> > Czy macie moze jakies doswiadczenia z sieciami VPN realizowanymi w MPLS
> > Chodzi mi o oferty operatorow w Polsce. Z tego co udalo mi sie znalezc w
> > sieci to taka oferte ma Telenergo i Crowley. Czy od strony klienta jest to
> > bardziej ciekawa oferta niz PVC ATM/FR ?
>
> Sa jeszcze wezly operatorow miedzynarodowych: AT&T, Equant i chyba
> Worldcom.
>
> 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.
Dokładnie odworotnie jest w ATM - ATM forum TM4.0 definiuje 5 klas QoS
- to jest standard (piękna sprawa).

> sposob w calej sieci operatora. Zeby osiagnac podobny efekt uzywajac
> FR/ATM musialbys kupic oddzielne PVC/VC. Ryzyko ze operator nie
> dotrzyma kontraktu jest podobne dla kazdej technologi. Dobry provider
> MPLSa dostarcza statystyki QoS.
>
> W przypadku duzej liczby siteow (duzego mesha) MPLS powinien byc
> tez duzo tanszy niz FR/ATM.
>
> MPLS VPN zapewnia routing IP pomiedzy siteami, zwykle zestawia sie
> tylko sesje BGP pomiedzy routerem klienta a interfesem (nalezacym do
> VRF klienta) routera providera (PE).

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.

Generalnie - VPN L2 - to jest piękna sprawa. Np. wg. draftu
Laserre.....


>
>
> Pzdr,
> Grzesiek
>


--
cYa, 3.14iotr/2
Dobry programista wiesza się z programem....
Hiroshima'45; Czernobyl'86; Windows'95

Zwrotne bajty daj na "w...@k...net.pl"

do góry

On Thu, 31 Oct 2002 w...@k...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.


> 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 ;)
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.


> Generalnie - VPN L2 - to jest piękna sprawa. Np. wg. draftu
> Laserre.....
>

Nie wiem, w praktyce widzialem tylko L3.


Pzdr,
Grzesiek

do góry

Grzesiek Pawelski napisal(a) [02 Nov 2002]:

> Zazwyczaj BGP uznawane jest za najlepszy protokol na styku
> administracyjnym sieci, i nie chce mi sie tlumaczyc dlaczego.

W przypadku VPN styk CE-PE nie jest tak do konca stykiem administracyjnym.
Router PE "nalezy" do sieci danego klienta.

--
(moskit-at-irc.pl)

do góry

On Sat, 2 Nov 2002, Marek Moskal wrote:

> Grzesiek Pawelski napisal(a) [02 Nov 2002]:
>
> > Zazwyczaj BGP uznawane jest za najlepszy protokol na styku
> > administracyjnym sieci, i nie chce mi sie tlumaczyc dlaczego.
>
> W przypadku VPN styk CE-PE nie jest tak do konca stykiem administracyjnym.
> Router PE "nalezy" do sieci danego klienta.


interfejs na routerze PE jest przypisany do danego VRFa,
co nie jest rownoznaczne z VPNem, jest osiagalny z dolaczonego CE.
CE<->PE to styk administracyjny jakby na to nie patrzec.
Klient moze zarzadzac routerem CE, ale za routing w sieci core,
tzn. pomiedzy routerami CE, odpowiada zawsze operator.

Pzdr,
Grzesiek

do góry

Grzesiek Pawelski <g...@e...pw.edu.pl> wrote:

>
>
> On Thu, 31 Oct 2002 w...@k...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 "w...@k...net.pl"

do góry