August 1999 - Test - lists.nanog.org

Re: What frame relay switch is causing MCI/Worldcom such grief?
by smd＠clock.org 09 Aug '99

09 Aug '99

Vijay - | Traffic flows change faster than the topology in most cases. So, in other words TE is a hack to make up for people's weaknesses in forecasting that leads one into a connectivity graph where the normally-selected logical path between two points is insufficient for the amount of traffic one wants to shuffle between ingress and egress? "Our forecast horizon is shorter than our planning cycle, so therefore we need TE" is probably the most real argument I've run into so far for doing TE, but it's so terribly sad that this is the case. Again, again, again, just like so many other times in the past. The other "compelling reason" I've run into for TE/MPLS is that it allows some people to close the book on the ATM-switch-in-the-middle-of-a- cluster-of-7[05]xx-es hack that was done in response to another famous underprediction of growth about which the people who seem most in favour of MPLS seem the most unforgiving. Ironic, isn't it? | Traffic measurements from end to end (per city flows) are also | easier to measure with the city to city pipe as it were. Uhm, think about that carefully before you declare it a compelling reason - step 1: sort traffic into categories that group together combinations of the 5-tuple, step 2: count this traffic. Possible implementation: add column to FIB table which is of the type struct counter { long long bytes; long long packets } * When a packet matches the FIB row, forward according to directives in the other columns, and then do: FIBLINE.counter->packets++; FIBLINE.counter->bytes += packet_length; Add glue to allow the FIB-creation-system to assign a particular counter per FIB entry, and some stuff to allow for the nice extraction of this information. One might even put it like this "show interface POS 0/1 quasi-vc <identifier>", which should show you a pretty printed summary of what the relevant counter structure contains. In other words, if extracting information about aggregate traffic flows is the means by which someone justifies deploying a pseudo- circuit-switched network like MPLS, I believe the problem lies in poor communications skills when communicating one's needs to one's vendor(s). Sean.

2 1

clinton creates internet study group (and police force?)
by Ehud Gavron 09 Aug '99

09 Aug '99

text of the EO: http://www.usnewswire.com/topnews/Current_Releases/0807-107.htm One analysis: http://www.worldnetdaily.com/bluesky_btl/19990809_xcbtl_clinton_co.shtml Ehud

1 0

Re: What frame relay switch is causing MCI/Worldcom such grief?
by Vadim Antonov 09 Aug '99

09 Aug '99

> So I guess that means you know more than all those smart people (on > both the service provider side and equipment side) who are helping > incorporate lessons from Frame Relay and ATM circuit routing into > MPLS? Yep. I can put together two and two and get four. I'm not going to read yet another lecture on computational complexity of adaptive circuit routing but so far nobody figured out a way to make it work in a network comparable to the current Internet in size. That's why nobody is even attempting to do MPLS or whatever across IXPs and only do in in the interior (actually this is also misguided, but for different reasons, having more to do with implementation complexity). BTW, a good many smart people who actually built the biggest chunks of the Internet backbone and the software which keeps it running share my opinion. In any case, the argument that million lemmings cant be all wrong is particularly hilarious. The issue of virtual circuit vs per-hop routing was discussed extensively in this forum years ago (in ATM vs IP context) and the consensus was pretty much against ATM. I would advise you to review the archives and see for yourself. Since there were no dramatic advances in either understanding of the problem, circuit-routing algorithms, or basic computing technology (well, the quantum computing can concievably solve the computablibity problem for circuit routing, but not any time soon :) i see little reason to start the arguments all over again. Of course, you may have something really new to say on the topic, but i would check that that wasn't already beaten to death. Regards, --vadim

3 2

Re: What frame relay switch is causing MCI/Worldcom such grief?
by smd＠clock.org 09 Aug '99

09 Aug '99

| So I guess that means you know more than all those smart people (on | both the service provider side and equipment side) who are helping | incorporate lessons from Frame Relay and ATM circuit routing into | MPLS? Yes. Sean.

2 1

Re: What frame relay switch is causing MCI/Worldcom such grief?
by Vadim Antonov 09 Aug '99

09 Aug '99

Prabhu -- a particluar implementation does not matter when the underlying idea is bad. Any circuit routing for data is broken-as-designed. (BTW, the irrelevance of the particulars is why i omitted attribution in the first place. This was a comment on the general state of affairs, not on the situation. Thanks for providing details, though). --vadim >From: Prabhu Kavi <prabhu_kavi(a)tenornetworks.com> >Vadim, >Your response is unrelated to the message I replied to, which >asked about the link state algorithm that Cascade uses. >As far as I know, nobody has announced which set of MCI Wordlcom's >switches were responsible for their outage. Since MCI Worldcom >uses multiple types in their network, statements like "goes as >predicted - complexity bites" is irresponsible at best, even if it >is later determined the Cascade switches were actually the cause >of the outage. >Prabhu

2 1

OUTAGE: MCI/Worldcom frame-relay network
by Sean Donelan 09 Aug '99

09 Aug '99

MCI/Worldcom's frame-relay network has been experiencing serious problems for the last six hours or so. Originally thought to be an upgrade gone bad, now the cause is unknown. MCI/Worldcom is in the process of shutting down and rebuilding different switches one-by-one. It is unknown when the network will stabilize. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

RE: What frame relay switch is causing MCI/Worldcom such grief?
by Baird, Alan 09 Aug '99

09 Aug '99

I believe WorldCom is using the BSTDX-9000/CBX-500 switches on their network. The problems that they are having sound suspiciously like what would happen to a network when it exceeded the 200 node limit on some of Ascend's older code. Perhaps they haven't got around to going to the new code release? Alan Baird Williams Network Architecture Lab -----Original Message----- On Mon, 9 Aug 1999, Alan Hannan wrote: What frame relay switch is causing MCI/Worldcom such grief?

1 0

Re: What frame relay switch is causing MCI/Worldcom such grief?
by Christopher Gibiault 09 Aug '99

09 Aug '99

current resume attached -----Original Message----- From: Prabhu Kavi <prabhu_kavi(a)tenornetworks.com> To: Vadim Antonov <avg(a)kotovnik.com> Cc: nanog(a)merit.edu <nanog(a)merit.edu> Date: Monday, August 09, 1999 2:52 PM Subject: Re: What frame relay switch is causing MCI/Worldcom such grief? > >Vadim, > >Your response is unrelated to the message I replied to, which >asked about the link state algorithm that Cascade uses. > >As far as I know, nobody has announced which set of MCI Wordlcom's >switches were responsible for their outage. Since MCI Worldcom >uses multiple types in their network, statements like "goes as >predicted - complexity bites" is irresponsible at best, even if it >is later determined the Cascade switches were actually the cause >of the outage. > >Prabhu > >Vadim Antonov wrote: >> >> This pretty much goes as predicted - complexity bites. Watch for more. >> >> What happened to the KISS principle? >> >> --vadim >> >> >On top of OSPF, there is a protocol which is responsible for actually >> >setting up the connections according to specific constraints (e.g. >> >bandwidth, QoS level). Again, this is similar to the work >> >now being done in working groups responsible for CR-LDP and RSVP. >> >Cascade released its version in 1993, and has been refining it >> >ever since. > >---------------------------------------------------------------------- >Prabhu Kavi Phone: 978-264-4900 x125 >Director, Prod. Mgmt. FAX: 978-264-0671 >Tenor Networks Email: prabhu_kavi(a)tenornetworks.com >50 Nagog Park WWW: www.tenornetworks.com >Acton, MA 01720 >---------------------------------------------------------------------- > >

1 0

Re: What frame relay switch is causing MCI/Worldcom such grief?
by Vadim Antonov 09 Aug '99

09 Aug '99

This pretty much goes as predicted - complexity bites. Watch for more. What happened to the KISS principle? --vadim >On top of OSPF, there is a protocol which is responsible for actually >setting up the connections according to specific constraints (e.g. >bandwidth, QoS level). Again, this is similar to the work >now being done in working groups responsible for CR-LDP and RSVP. >Cascade released its version in 1993, and has been refining it >ever since.

2 1

CORRECTION/UPDATE: Re: OUTAGE: MCI/Worldcom frame-relay network
by Sean Donelan 09 Aug '99

09 Aug '99

UUNET has restored the frame-relay outage paragraph to their web page. It was gone at 12:00EDT (Noon), it was back at 12:29EDT. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0