- Test - lists.nanog.org

Re: What frame relay switch is causing MCI/Worldcom such grief?
by Martin Cooper 10 Aug '99

10 Aug '99

Alex Bligh <amb(a)gxn.net> wrote: > > Yes. > > Not disagreeing with Sean, which whilst amusing is often unproductive: Heh. > One of the higher clue arguments in favour of maintaining an L2 > mesh (and 'routing' protocol) is that it converges quicker than > than L3 as in theory it has less nodes. The normal counter arguments > are: > 1. that L1 (SONET/SDH) converges quicker still. But the reason ISPs adopted NBMA L2 networks in the first place is because the telcos convinced them that L2/L3 integration was going to happen (or because the ISPs got a cheap deal in support of the telcos' agenda of making that happen). The ATM Forum has done a great job on the IP/ATM integration front (I don't think). As you say, L1 converges quicker still, which is a very good argument for running IP on top of Packet Over SONET/SDH and using MPLS in support of IP virtual-circuits to do QoS routing. > 2. as MCI/Worldcom may well have aptly demonstrated, L2 routing > protocols have their own problems. MCI/Worldcom is just a crappy bureaucracy - that's the real reason. > 3. L3 routing can be hierarchicalized (sp?) and tweaked to converge > just as effectively - witness sending your loopback IP's round as > next hops in BGP and running an underlying IGP such as OSPF/ISIS/EIGRP > which cuts out many (though unfortunately not all) recomputations > when the underlying fabric changes. But L3 routing is not the issue... > 4. Implementation of L2 heavy protocols on routers is often poor. Witness > how long it took Cisco to implement OAM management. So just how long > does it take to notice a VC's gone down? Telcos like nailed-up QoS products because they understand them. ISPs like best-efforts QoS products because they understand them. Cisco likes both (and buzzwords like 'integration') because it's into aquiring market share in both markets. The Internet is never (IMHO) going to become a fully circuit-switched QoS network because of all the cooperation that has to happen to prevent it melting down when operating as a best-efforts network (which is what it basically still is don't forget). MPLS (despite what the telco spin-doctors might claim) is not really about integration with ATM - it's about introducing levels of QoS appropriate to the services ISPs want to provide over their own networks (and perhaps, given a year or so, in conjunction with peer networks as well). VoIP doesn't need the predictably precise levels of jitter (with associated protocol overheads) and suchlike that the telco ATM (reinvented voice-switching) weenies claim will be required to provide a decent QoS for voice traffic. > A more convincing argument for buying ATM circuits is that they > (are) / (used to be) dirt cheap. Recent experience suggests there may > be a reason for this. The telcos are flogging a dead horse with IP over ATM QoS integration. Best pretend that's why you're buying ATM if you want a cheap deal (or just invoke your MCI/Worldcom contractual QoS guarantees ;-) ). > Alex Bligh > GX Networks (formerly Xara Networks) I think it's high time you dropped the 'formerly' stuff and learn to live with the fact that you sold out. ;-) M.

1 0

NetCool
by Mike Heller 10 Aug '99

10 Aug '99

Would anyone like to share positive or negative experiences with this product on or off the list? From what I've seen of it, I'm very impressed. I'd like to get real world feedback. Thanks in advance mike Michael Heller Sr. Systems Engineer Earthweb, Inc. 212.448.4175 mikeh(a)earthweb.com

2 1

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

10 Aug '99

Dave Cooper <dcooper(a)eli.net> wrote: > The problem is not capacity planning. Most large > backbones have dedicated resources to determine > 6-12 month needs in their cores. There are good > tools to help you do that, not to mention good ole' > regression analysis along with programs like Wandl. > But those statistical tools will only go for 12 months > out with a "decent" deviation. Once you > go any further, you are grabbing at straws. The rule of thumb: build as big network as you can and then connect only as many customers as it can sustain :) Seriously, TCP/IP can accomodate very gross mistakes in capacity planning - up to an order of magnitude. Trivial trend analysis and random traffic distribution gives predictions which are good enough. In fact, there are no good ways to measure demand for data traffic -- the actual traffic measurements reflect the current available capacity and effects of routing decisions more than anything else, and only show pathologically bad capacity problems. >The problem lies with the provisioning times for >circuits at the OC-3/OC-12/OC-48 level. That problem should have non-technical solution. Fix telco bureaucracy. Or just let the sluggish ones die; everybody will be better off for that. > This creates > the need to use existing resources to reduce latency > and delay until you can bring the physical topology > to specification. This creates the need to worry about more than the short term revenue, and to actually listen to what engineers have to say. The problem is not technological, and no technological fix is going to cure it - any such fix only masks the symptoms, simply prolonging the agony and draining scarce engineering resources. >I highly doubt the big players are looking at MPLS >to bail themselves out of the physical topology >constraints (although that might be a side benefit >for both the provider AND the customer). They're introducing a whole new can of worms complexity-wise for something which at best promises 10-20% improvement (bandwidth utilization-wise; the latency-related actual performance degradation makes even that benefit highly doubtful). 2 months of advantage just do not worth it. Customers increasingly are limited by server capacity, and worry a lot more about availability than about backbone capacity. --vadim

1 0

RE: At the risk of being on-topic...
by Lance Tatman 10 Aug '99

10 Aug '99

Ames is currently offering beta services of Gigabit Ethernet, channelized FE and FE via a pair of Cabletron SSR-8600's connected to the Gigaswitch FDDI's with multiple trunks. Ames has not requested a 5th OC-3c to the Worldcom side of the MAE-West, nor have they been turned down. Ames plans to work with Worldcom regarding the capacity between the two sides of the MAE-West to meet requirements. If you would like to participate in the beta program, please send email or call me at 650-604-3664. -----Original Message----- From: Deepak Jain [SMTP:deepak@ai.net] Sent: Tuesday, August 10, 1999 10:12 AM To: nanog(a)merit.edu Subject: At the risk of being on-topic... ...and the risk of on-topic having changed since the last time I checked. I heard that Ames has quietly implemented a gigabit ethernet switch that is interconnected to the Mae-West fabric. Has anyone starting using it/any details to share? Rumor also has it that Ames requested a 5th OC-3 to connected to the Worldcomm side of Mae-West which was turned down by Worldcomm management. Deepak Jain AiNET

1 0

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

10 Aug '99

The traffic-engineering reason for L2 "routing" is only valid for complex-topology networks. In simple topologies, the penalty for suboptimal paths effectively cancels gains from spreading traffic around. Physical fiber plants do have rather simple topologies (the rich topologies are usually "optical illusions" created by SONET layer). >From a customer's point of view performance of the network is _not_ measured as available bandwidth; but rather as performance of his TCP streams; which depends heavily on latencies and loss. Increasing latency while there's a lossy component in the path (which is increasingly found not in backbone but at ingress tail circuits, and outside of the ISP control) downgrades performance apporximately inversely proportionally to the latency. In other words: excluding grossly overloaded circuits, you want the path with least latency! This is because your performance is limited by the tail-circuit (or exchange point) loss _and_ the backbone latency. MPLS does nothing to help avoid these lossy places (avoiding IXP loss would require propagation of interior routing information into peer backbones). Additionally, suboptimal paths as a rule involve more hops, which increase latency variance proportionally. Now, no matter how one jumps, most congestions only last seconds. Expecting any traffic engineering mechanism to take care of these is unrealistic. A useful time scale for traffic engineering is therefore at least days - which can be perfectly accomodated by capacity planning in fixed topology. At these time scales traffic matrices do not change rapidly. In fact, as long as there are more than three backbones, one can safely assume that most traffic goes from customers (proportionally to size of their pipes) to the nearest exchange point; and from exchange points randomly to all customers (again proportionally to their access pipe sizes). Backbones which neglect the capacity planning because they can "reroute" traffic at L2 level simply cheat their customers. If they _do not_ neglect capacity planning, they do not particularly need the L2 traffic engineering facilities. Anyway, the simplest solution (having enough capacity, and physical topology matching L3 topology) appears to be the sanest way to build a stable and manageable network. Raw capacity is getting cheap fast; engineers aren't. And there is no magic recipe for writing complex _and_ reliable software. The simpler it is, the better it works. --vadim

3 2

At the risk of being on-topic...
by Deepak Jain 10 Aug '99

10 Aug '99

...and the risk of on-topic having changed since the last time I checked. I heard that Ames has quietly implemented a gigabit ethernet switch that is interconnected to the Mae-West fabric. Has anyone starting using it/any details to share? Rumor also has it that Ames requested a 5th OC-3 to connected to the Worldcomm side of Mae-West which was turned down by Worldcomm management. Deepak Jain AiNET

1 0

MCI/Worldcom customer advisory
by Sean Donelan 10 Aug '99

10 Aug '99

Although I said I wouldn't post any more updates about the MCI/Worldcom frame-relay problems, since I said MCI/Worldcom wasn't keeping its customers updated, I should inform you that we received our first 'customer advisory' from MCI/Worldcom at 1:57am CDT this morning. MCI/Worldcom informed us they are 'upgrading' their network, and some customers may see a few service interruptions or congestion. Because MCI/Worldcom's PR department seems determined to declare me a crank posting rumors on the Internet, perhaps other MCI/Worldcom customers carry more weight. http://www.cbot.com/news_views/trading.html I called it a "collapse," MCI/Worldcom's President of operations called it a "meltdown." I think either word communicates the seriousness of the situation better than MCI/Worldcom's PR department calling it an "upgrade." Those that have read my postings over the years know I'm less upset about the actual outage, than I'm angry about the management response to the problem. The entire weekend we couldn't reach anyone with more authority at MCI/Worldcom than the call-taker or first-level tech. The upper management simply vanished. BTW, I think Alan is just worried because Frontier bid on replacing MCI/Worldcom as our frame-relay provider, and he might get me as a customer again. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: OUTAGE: MCI/Worldcom frame-relay network
by Alan Hannan 10 Aug '99

10 Aug '99

> I'm confused by your message. Which is more questionable: The MarketWatch > story which was clearly inaccurate -- it didn't even mention impact to the > industry they report on (i.e., CBOT) -- or the messages Sean posted? From > all appearances Sean's messages were timely, highly accurate, and very > informative. This is more than can be said of the news media coverage. > This is the second time I have witnessed you complaining about outage > information being posted and discussed in this forum. Why is information > sharing bad? I don't believe that information sharing is bad. I think it is good. I do not believe NANOG is appropriate for real time operational issues. That's all. -alan PS - sean's messages were not 'highly accurate' as they maintained that WCOM was not reporting on the problems, while they were.

4 3

Register.com (sucks)
by Ehud Gavron 10 Aug '99

10 Aug '99

Operational: New registry fails to be a registry. More of a 'user site registry'. It's been five days and I can't seem to get a human at register.com with a clue. I made a mistake and registered a domain with them instead of netsol. Here's how the nightmare unfolds. 1. They created records (MX and SOA) which cannot be removed via their graphical interface. 2. Despite providing a primary and secondary server, when I changed the primary server it did NOT ever zone xfr the new zone. Customer service says: "Can't mix offsite primaries and secondaries." Right. 3. Customer service won't respond to email. Have to use web form!!! 4. Domain validations require an email to be sent (so far so good) with a URL which is 86+ characters long which must be cut and pasted and used to verify authentication. (You get the feeling I'm on on 80- character terminal window here? Two cut and pastes...) 5. They take 24+ hours to respond to any query. So far... I've done more "changes" and "updates" and "emails" than I've ever had to do... all for one domain name. Anyone have a human contact over there with a clue? Ehud

1 0

Acceptable Use, WAS: Re: OUTAGE: MCI/Worldcom frame-relay network (fwd)
by David Lesher 10 Aug '99

10 Aug '99

Unnamed Administration sources reported that Forrest W. Christian said: > > > Is there ANY topic which is ok to discuss on the nanog list? sex, religion & politics have not been mentioned yet..... -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0