- Test - lists.nanog.org

RE: [NIC-960710.6343] INVOICE (hardcopy) (01-jul-1996 - 07-jul-1996)
by Bill Woodcock 21 Aug '96

21 Aug '96

We haven't seen too many mis-bills, but quite a few uncredited payments... i.e. our customer gets a cancelled check back, but then the InterNIC either cancels the domain or refuses to acknowlege payment, or both. I'd say this is happening in 1%-2% of cases, which seems pretty high. -Bill Woodcock

2 1

Access to the Internic Blocked
by Golan Ben-Oni 21 Aug '96

21 Aug '96

Network Solutions has decided to filter our CIDR addr, 169.132 / 16 since about 5 PM yesterday from reaching the internic. Below is a forwarded copy of email exchange between myself, and MCI -- It appears that there is no backup routing engineer at the Internic which troubles me greatly. MCI has been attempting to contact them every 30 minutes since yesterday to no avail. This is the second time in a month or so that this has happened. Since I was unable to contact Mark Kosters, I felt it might be helpful to contact Kim Hubbard - To my dismay, she refused to acknowledge our problem and hung up on me with an attitude. <sigh> Of course, this pleases me to no end. ---------- Forwarded message ---------- Date: Mon, 19 Aug 1996 17:11:32 -0400 From: Nour Elouali <nour(a)mci.net> To: markk(a)netsole.com, allwync(a)rs.internic.net Cc: bnite(a)tremere.ios.com, trouble(a)mci.net Subject: Access Denied Hi there, One of our peers _idt.net_ cannot reach your site, see the forwarded traceroute.. They cannot route to you from any IP Address within their CIDR Block 169.132.0.0/16. According to my traceroute, I see that they get filtered out at network-solutions which is your provider. Will you be able to assist? Thanks... -Nour Elouali MCI NOC ****** border7.wtn#tr 198.41.0.6 Type escape sequence to abort. Tracing the route to rs1.internic.net (198.41.0.6) 1 network-solutions.Washington.mci.net (204.70.77.42) 8 msec 8 msec 4 msec 2 rs1.internic.net (198.41.0.6) [AS 6245] 8 msec 4 msec 4 msec ****** ------- Forwarded Message Delivery-Date: Mon, 19 Aug 1996 17:27:36 -0500 Received: from postoffice.Reston.mci.net by carbon.cary.mci.net (8.6.12/kaw-mci.net/feb95) id NAA02326; Mon, 19 Aug 1996 13:27:24 -0400 Received: from tremere.ios.com (tremere.ios.com [169.132.32.250]) by postoffice.Reston.mci.net (8.7.5/8.7.3) with ESMTP id NAA28560 for <trouble(a)mci.net>; Mon, 19 Aug 1996 13:27:21 -0400 (EDT) Received: (from bnite@localhost) by tremere.ios.com (8.7.5/8.6.9) id NAA08739 for trouble(a)mci.net; Mon, 19 Aug 1996 13:27:11 -0400 (EDT) Date: Mon, 19 Aug 1996 13:27:11 -0400 (EDT) From: Golan Ben-Oni <bnite(a)tremere.ios.com> Message-Id: <199608191727.NAA08739(a)tremere.ios.com> To: trouble(a)mci.net Subject: Traceroute to Internic traceroute rs.internic.net traceroute to rs.internic.net (198.41.0.6), 30 hops max, 40 byte packets 1 eth-3.gw-4.hck.idt.net (169.132.32.254) 2.907 ms 2.026 ms 3.068 ms 2 eth-0.gw-1.hck.idt.net (169.132.34.250) 107.054 ms 121.335 ms 77.012 ms 3 10.255.255.1 (10.255.255.1) 82.342 ms 70.764 ms * 4 192.41.177.181 (192.41.177.181) 55.270 ms 48.858 ms 42.972 ms 5 core2-hssi2-0.Washington.mci.net (204.70.1.213) 40.422 ms 40.915 ms 43.822 ms 6 border7-fddi-0.Washington.mci.net (204.70.74.51) 33.906 ms 78.689 ms 75.278 ms 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 * * * 14 * * * ------- End of Forwarded Message

10 13

How connect to a NAP ?
by James R. Fisher 703-648-7026 20 Aug '96

20 Aug '96

Quick question from a lurker: If a Federal Agency wanted to connect directly to a NAP (e.g., MAE-East, MAE-West), how would they start the process, who are the contacts ? P.S. Does FIX still exist ? Thanks. -jrf

3 2

Re: Customer AS
by Justin W. Newton 20 Aug '96

20 Aug '96

At 11:41 PM 8/19/96 -0400, Perry E. Metzger wrote: > >Sean Doran writes: >> | We can't pretend to be able to replace the phone networks until we can >> | achieve similar reliability. Phone networks typically are spec'ed to >> | two minutes a year downtime. >> >> Uh huh, while I agree with you that the Internet is not >> remotely as stable as voice networks are, I think that >> this has a great deal to do with the revenue difference. > >I strongly disagree. It has far more to do with the primitive >engineering methods we are employing. > >The mere fact that I've actually seen networks built in the real world >that simply never go down and that don't cost an order of magnitude >more leads me to believe that it can be done. I must admit that these >networks are much smaller than the national networks a large provider >tends to build -- on the order of twelve cities, fifteen or sixteen >sites, and a hundred or two hundred ethernets. On the other hand, such >a network is more than large enough that a "normal" network of this >sort will experience substantial downtime in some of its links. The >networks I've been involved with, though, go down orders of magnitude >less frequently than you normally expect. Why is that? > >1) redundancy in all components and links. >2) No "cowboy"ism. 3) These sites aren't turning up /hundreds/ of T-1's and other links on a given week. 4) Points of entry into these networks are very limited, and therefore the network manager has much more control over what comes into and out of his network as far as both data and routing advertisements. 5) These networks are not nearly large enough at this point in time to seriously push hardware to/beyond its design specifications. 6) Traffic patterns are relativelty predictable, you don't suddenly have triple the traffic over one link that you didn't have yesterday. Anyone care to add to the list? Justin Newton Internet Architect Erol's Internet Services

2 1

Re: Customer AS
by Dave Morton 20 Aug '96

20 Aug '96

>Sean - not picking nits but should that not be 28 T1s i.e. 24 * 28 >giving 672 DS0s ? > >Given the cost of even the cheapest voice tariff from DE to the US >as another example I get an annual worth of 311 million dollars >for the same DS2 circuit. Given that a leased transatlantic DS3 costs DS3... >between 6.5-7 million dollars p.a. this again reinforces your point below. > >Dave

1 0

Re: Customer AS
by Dave Morton 20 Aug '96

20 Aug '96

>| We can't pretend to be able to replace the phone networks until we can >| achieve similar reliability. Phone networks typically are spec'ed to >| two minutes a year downtime. > >Uh huh, while I agree with you that the Internet is not >remotely as stable as voice networks are, I think that >this has a great deal to do with the revenue difference. > >Consider that a T3, eating 690 DS0s, at 10 cents/minute/DS0, >is worth ($52560 * 690) some thirty-six million dollars a year >in revenue on the voice network. Sean - not picking nits but should that not be 28 T1s i.e. 24 * 28 giving 672 DS0s ? Given the cost of even the cheapest voice tariff from DE to the US as another example I get an annual worth of 311 million dollars for the same DS2 circuit. Given that a leased transatlantic DS3 costs between 6.5-7 million dollars p.a. this again reinforces your point below. Dave >I think you will agree that a T3 for Internet connectivity >is not worth a very large fraction of that. > >Moreover, a backbone T3 for voice going down costs >(at roughly 10 cents/minute/DS0) $4000/hour in lost >billable revenue. > >If the money figures for Internet connectivity were anywhere >near the figures for voice, and was billed by use in small >increments, you would expect greater investment in reliability, >as one sees on voice networks. > >Frankly, where there is significant competition and little >or no loss-leading and cross-subsidy, the Internet >is precisely as reliable as people are willing to pay for. > > Sean. >

1 0

Re: Customer AS
by Paul Ferguson 20 Aug '96

20 Aug '96

At 06:55 PM 8/16/96 -0400, Curtis Villamizar wrote: >> I would make them renumber with a new class c that was not in your CIDR >> block. >> Maybe they could get a class C from the swamp? > >Are you suggesting that all dual homed networks should be renumbered >such that they can't be aggregated and can't be reached from a good >part of the Internet. I don't think that is a good idea. > >Are suggesting punishing a customer for picking up a second provider >by giving them an unroutable prefix? I hope not. > Curtis, Not sure what you mean here concerning 'unroutable' prefixes, but the issue with obtaining an allocation for one of the upstream provider's CIDR block when multihomed *does* have its drawbacks, at least from the end-user perspective. If said prefix (let's say a /24) is announced in the 'allocating' provider's aggregate, and the more specific is announced via the 'other' provider, the more specific will always be preferred. Of course, you can play a few tricks (AS_PATH prepend, etc.), but this situation introduces unique problems. In fact, the <draft-hubbard-registry-guidelines-05.txt> draft indicates that this is one of the few acceptable instances when allocation can be done by one of the various registries and not by (one of) the upstream service provider(s). I think this is a contributing factor to the overall growth of the global routing table(s), but this is an issue we need to deal with. From an operational perspective, I'd opt for using a prefix which was not allocated from either/any upstream provider. From a global perspective, this contributes to route bloat. :-/ - paul

10 13

Re: Customer AS
by Sean Doran 20 Aug '96

20 Aug '96

| We can't pretend to be able to replace the phone networks until we can | achieve similar reliability. Phone networks typically are spec'ed to | two minutes a year downtime. Uh huh, while I agree with you that the Internet is not remotely as stable as voice networks are, I think that this has a great deal to do with the revenue difference. Consider that a T3, eating 690 DS0s, at 10 cents/minute/DS0, is worth ($52560 * 690) some thirty-six million dollars a year in revenue on the voice network. I think you will agree that a T3 for Internet connectivity is not worth a very large fraction of that. Moreover, a backbone T3 for voice going down costs (at roughly 10 cents/minute/DS0) $4000/hour in lost billable revenue. If the money figures for Internet connectivity were anywhere near the figures for voice, and was billed by use in small increments, you would expect greater investment in reliability, as one sees on voice networks. Frankly, where there is significant competition and little or no loss-leading and cross-subsidy, the Internet is precisely as reliable as people are willing to pay for. Sean.

2 1

Re: Customer AS
by Vadim Antonov 20 Aug '96

20 Aug '96

Randy Bush wrote: >> In my (rather extensive) practice, multihoming by itself is >> usually a major source of connectivity problems. >in my meager and bottom-feeding scum-sucking practice, multi-homing >decreased unreliability delivered to our customers by a factor of ten >or more. Right. If you know what you're doing and have resources to manage it. PSG/TLG/RainNet is what? Probably the largest regional in Northwest. Nobody argues about benefits of multihoming for providers like that (and you have enough customers to maintain significant level of aggregation, too). The problem is that basement operators are multi-homing, too. >this very moment i am sitting at a site which is single-homed to an >anonymous NSP's major POP in a farming town in mid-Cal. i can not get >to www.cisco.com from here. yet i can get to my home net, which is >quite multi-homed, and get to cisco from there. > >so, as we say in my family, i smell cows. See advice below. >> It is _much_ better to multihome to the same provider who then >> can take care of messy global routing. >just what i always wanted, two connections to a broken provider. you >must be kidding. Pick a provider which is not broken. None of them will help you agaist a clueless idiot injecting /24s covering your nameservers, though (don't feed me the RA -- as long as dominant routers can't do the massive filtering on their own it is close to useless). AUTH_CERTIFICATE attribute anyone? :) It may make sense to restrict multihoming to those who can aggregate their routes to, say, no less than /17s. --vadim PS There is a proof by existance that reliable operation w/o customer multihoming is possible. It is called POTS.

2 1

Collapse of the Internet on NPR
by William B. Norton 20 Aug '96

20 Aug '96

In case you haven't heard enough on this topic, Bob Metcalfe, Don Heath (Internet Soceity, and Larry Magid (Los Angeles Times) discussed the eminent collapse of the Internet on NPR. The whole things can be heard via real-audio off the web: http://www.realaudio.com/contentp/npr/nf6A16.html There were a couple mildly interesting discussions in the beginning, and then it turned into a discussion about browser wars. Bill

1 0