- NANOG - lists.nanog.org

MCI-Worldcom in the news
by Patrick Greenwell 11 Aug '99

11 Aug '99

Well, someone picked the outage story up(sort of...) http://www.excite.com/computers_and_internet/tech_news/zdnet/?article=zdnew… /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ Patrick Greenwell "This is our time. It will not come again." \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

1 0

WEATHER: tornado and power outages in salt lake city utah
by Sean Donelan 11 Aug '99

11 Aug '99

There was a tornado in Salt Lake City Utah which caused a lot of damage in the downtown area and power outages throughout the area. Several local ISPs in the area seem to be down. One ISP I was able to reach is on backup power. Traceroutes seem to reach the POPs of backbone providers, so they seem to be up. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Register.com (followup - suckage removed)
by Ehud Gavron 11 Aug '99

11 Aug '99

Following my NANOG posting, one individual was kind enough to forward my posting to the CEO of Register.com, Richard Forman. Soon I had a first-level support rep who couldn't "ping my domain." When I started talking words like SOA and NS and MX she transfered me to Morris Djouejati, who knew those words. Morris explained they're still working on making the web front-end be able to remove those extra MXs, but since my NSs were both offsite it wouldn't make a difference. This morning I got a followup call from Richard Forman, who wanted to ensure everything had been taken care of. I am, in fact, satisfied. Register.com has, in fact, successfully registered a working domain name for me. While they did make mistakes, and they didn't respond immediately, I never sat on hold for two hours ;-) Ehud (futurely gavron(a)wetwork.net)

1 0

in-addr.arpa question
by Hank Nussbacher 11 Aug '99

11 Aug '99

I have a client who is now peering with BBN. BBN supplied a /30 as follows: 207.112.240.113 is their side via a company they purchased called Nap.Net. The DNS shows: NChicago2-core0.nap.net Thats ok. The other side is the customer colo router and the IP of 207.112.240.114 shows: chi2-vts.ianet.net Now I claim that the domain ianet.net (based on Internic data) is some company in WV and has nothing to do with us (ianet is the customer name we were assigned by BBN). BBN claims that is this their "standard naming convention" for assigning customer interface names. Traceroutes will show up with ianet.net in the path. I claim this is in violation of some RFC. Am I wrong? There may be many such PTR records within BBN for "customername.net". Thanks, Hank

4 3

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

11 Aug '99

Joel Halpern <joel(a)mcquillan.com> wrote: > Martin Cooper said something similar to: > > 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. > > Actually, that turns out not to be the case. The adoption of layer 2 > switching technology into the internet core set of tools predates any of > the ATM hype. It was done with frame relay. Oh absolutely - I wasn't just referring to ATM in the context of NBMA L2 switching. > It was not done on the > basis of L2/L3 integration, but because it gave the ISPs something more > useful than just a fixed size (DS3) set of pipes between places. Well ok, but if you follow that marketing pitch (making nailed up L2 links more useful to extremely popular overlayed L3 networks like the Internet) to its logical conclusion, it ends up there, because the motivation behind it is to be seen to add value to the product (shifting unspecified data from A to B) to stave off commoditisation. M.

2 1

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