Article View: pl.internet.polip
Article #96436Re: Frame Relay po światłowodzie
From: Krzysztof Halasa
Date: Wed, 19 Mar 2014 18:08
Date: Wed, 19 Mar 2014 18:08
93 lines
5468 bytes
5468 bytes
Rafał Wilk <rw@inet_CYFRA6_.pl> writes: > - łącze symetryczne No ale w tym przypadku to wada (taka symetryczność FR 10/10 powstaje przez obcięcie asymetrycznego downlinku DSLa 80/10 - interes raczej kiepski). Zwłaszcza, że tu chodzi o dostęp kliencki, który zapewne będzie niesymetryczny z dużą przewagą downstreamu. > - CIR i SLA > - możliwość odpalenia sesji BGP > - możliwość podpięcia własnej adresacji lub otrzymania jakiejś większej > za pośrednictwem operatora > - możliwość odpalenia load balancingu Nie było mowy o takich potrzebach. Load balancing obecnie jest bez sensu, jeśli możemy po prostu mieć odpowiednio szybsze łącze. Ew. jeśli mamy różne koszty routingu w różne miejsca, ale wtedy BGP a nie jakiś "LB" z jednym operatorem. LB to jest teraz właśnie amatorstwo, i to w tym negatywnym znaczeniu. Takie rzeczy to się robiło na 2-Mbitowych HDSLach, ale nie teraz. > - wydajność pakietowa, która nie jest sztucznie ograniczona na DSLAM No fakt, bo to nie przechodzi przez DSLAM. Jest sztucznie ograniczona przez router (routing switch) FR. > - w przypadku awarii lub ataków wsparcie ze strony NOC To ma (może mieć) znaczenie, jeśli na takim linku mamy jakieś zasoby np. WWW itp. Jeśli potrzebujemy dostępu "klienckiego", to jest to wywalanie kasy w błoto (zwłaszcza jeśli FR nie jest jedyną możliwością). > - relatywnie stałe i z reguły niskie opóźnienia W DSLu opóźnienia mogą być minimalnie większe ze względu na sposób kodowania z przeplotem, ale to nie są wartości, które da się w takich warunkach zauważyć. Pomijając to, opóźnienia zawsze są niewielkie, chyba że link jest wolny/przeciążony (no i przy SATach). Chyba nikt nie myśli, że dla DSLi jest jakiś oddzielny szkielet itp. Kiedyś to by tak mogło być. > - brak problemów z VPN i innymi tunelami (niezdegradowane MTU) DSLe też mają przecież MTU 1500. Tak w ogóle, to mogą mieć większe, tylko chyba nie w tej akurat usłudze (i niespecjalnie w publicznym internecie). Właśnie w FR MTU może być mniejsze niż w ADSL, np. ograniczone do 1500 bajtów IP, albo np. 1596 itp. (bo to starsza technologia - może być jednak większe). W ADSLu może w ogóle nie być odgórnego ograniczenia na MTU, zwłaszcza jeśli ktoś ma na tym link pomiędzy oddziałami firmy (zdaje się że TPSA ma nawet taką usługę, ale tu musimy(?) przejść przez Ethernet i ograniczenie będzie). > - niezawodność Np. jeśli ktoś porównuje do DSLa na starych papierowych kablach w wodzie na granicy zasięgu, to jasne. Kwestia lokalnych warunków, oraz potrzeb - ile ktoś jest skłonny zapłacić za to, że może może nie będzie tych np. kilku godzin rocznie bez sieci. Inna sprawa, że jeśli już się coś stanie z linkiem światłowodowym, to problemy będą nieco większe niż przy miedzi. Z tym, że to specyfika światłowodu vs miedź, a nie FR vs ADSL. > DSL to taka zabawka dla mas. Do profesjonalnych zadań się nadaje średnio. W każdym razie z pewnością tak to przedstawiają usługodawcy. Problem w tym, że prawdziwe rozwiązania profesjonalne uwzględniają potrzeby i koszty, i znakomitej większości zastosowań profesjonalnych np. SOHO taki DSL wystarczy bez problemu. Jeśli ktoś wydaje nie swoje pieniądze (np. z budżetu albo korporacji, innymi słowy układ jest socjalistyczny), to jasne, kto by się przejmował jakimś tam dobrem "wspólnym" lub firmy. Jeśli pieniądze pochodzą z własnej kieszeni, to to od razu inaczej wygląda. A tak w ogóle, nie można kupić dostępu Ethernetowego (np. tańszego)? FR jest drogi z jednego, niezwykle prostego powodu - ta technologia jest starsza i ma wiele razy mniej użytkowników. Reszta to ideologia, żeby userzy czuli się wyjątkowi płacąć ileś tam razy tyle. W szczególności na ADSLu przynajmniej tak samo jak na FR (nie mam na myśli obecnej oferty TPSA) można mieć: - połączenia punkt-punkt, punkt-multipunkt i dowolny (także full) mesh - BGP, SLA, CIR (lepszy technicznie niż w FR), LB (lepszy technicznie, bo oparty o celki o małym i stałym rozmiarze) - tunelowanie dowolnych treści (np. telefonii, video itd) bez ograniczeń na wielkość pakietów itp. wraz z zachowaniem interaktywnego dostępu do sieci (lepiej niż w FR). -- Krzysztof Hałasa
Technical Details
Message-ID:
<m3ob123vu2.fsf@intrepid.localdomain>Path:
mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.atman.pl!news.nask.pl!news.nask.org.pl!not-for-mailReferences:
<lfansu$u05$1@usenet.news.interia.pl> <lfbq4e$8pa$1@portraits.wsisiz.edu.pl> <m3zjkxakee.fsf@intrepid.localdomain> <lfqces$dse$1@usenet.news.interia.pl> <m3k3bs7esy.fsf@intrepid.localdomain> <lgc0lj$grm$2@srv.chmurka.net> <lgc3rn$h4j$1@news.task.gda.pl>Show Full Headers
Complete Article Headers
Path: mbox-mo1.pugleaf.net!news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.atman.pl!news.nask.pl!news.nask.org.pl!not-for-mail From: Krzysztof Halasa <khc@pm.waw.pl> Newsgroups: pl.internet.polip Subject: Re: Frame Relay po światłowodzie Date: Wed, 19 Mar 2014 19:08:21 +0100 Organization: NASK - www.nask.pl Lines: 93 Message-ID: <m3ob123vu2.fsf@intrepid.localdomain> References: <lfansu$u05$1@usenet.news.interia.pl> <lfbq4e$8pa$1@portraits.wsisiz.edu.pl> <m3zjkxakee.fsf@intrepid.localdomain> <lfqces$dse$1@usenet.news.interia.pl> <m3k3bs7esy.fsf@intrepid.localdomain> <lgc0lj$grm$2@srv.chmurka.net> <lgc3rn$h4j$1@news.task.gda.pl> NNTP-Posting-Host: ni.piap.pl Mime-Version: 1.0 X-Trace: pippin.nask.net.pl 1395252505 21289 195.187.100.4 (19 Mar 2014 18:08:25 GMT) X-Complaints-To: abuse ATSIGN nask.pl NNTP-Posting-Date: Wed, 19 Mar 2014 18:08:25 +0000 (UTC) Cancel-Lock: sha1:FNFyAs5Akb7DEbKEh2jww0KpVdc= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit