- Test - lists.nanog.org

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 19 Aug '96

19 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 19 Aug '96

19 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 19 Aug '96

19 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

Re: Customer AS
by Vadim Antonov 19 Aug '96

19 Aug '96

In my (rather extensive) practice, multihoming by itself is usually a major source of connectivity problems. Whoever arguing _for_ mulihoming for everyone forgets that taking more routing information in has dangers not present when you don't do routing yourself. I never saw any customer who had the ability to configure a multihomed site properly on their own; and most of the bogus routing information comes from multihomed customer sites. It is _much_ better to multihome to the same provider who then can take care of messy global routing. --vadim PS A UPS for CPE usually fixes 95% of transmission problems. I've seen people willing to spend money on multihoming but doing things on commercial power.

7 8

Re: Customer AS
by Vadim Antonov 19 Aug '96

19 Aug '96

Sean Donelain wrote: >>PS There is a proof by existance that reliable operation w/o >> customer multihoming is possible. It is called POTS. >That's funny. Anyone who needs reliable telephone service >quickly learns how to multi-home between telephone providers, >inbound and outbound. Inbound? Huh? Just dial a different number? >AT&T periodically puts out a press release >saying their network is so reliable, no one needs to buy service >from anyone else. No matter what, POTS is a lot more reliable and dependable than Internet. That definitely can be attributed by adequate resources being spent on the redundancy. >Anyone who needs reliable electrical service, quickly learns >how to multi-home between electrical providers. The street >mains, a UPS, and generator. Some people even get a redundant >connection to another street mains. Ah, if onle one could store Internet connectivity in a battery. >Yes, it is complicated to multi-home between providers of >anything (telphone, electricity, Internet, bagels). Not at all. Everything you can store (like bagels) is easy. >A redundant connection to the same provider might help in a few limited >circumstances. In about 98% of all cases of equipment malfunction. >But generally, when a provider fails on one >connection, the probility their other connections are working >drop dramatically. Ghm. What makes you think it does not drop nearly as much for inter-provider multihoming? >When the electricity fails, using a different >connection to the same electical provider usually doesn't work >either. Or, as recent intertie problems showed, connection to any provider whatsoever also doesn't work. If you don't drag wires to the other coast, that's it. >That's why people buy UPS's instead of second power supplies. The person who would invent an "Uninterruptible Network Supply" is going to be filthy rich. The question about multihoming is easy -- what is price/benefits? "Price" includes price for society at large, as well. --vadim PS. An often forgotten fact from the life of fault-tolerant systems: Practically all systems have threshold where addition of extra redundancy actually makes system less reliable! That is because the probability of Bysantine-type failures (i.e. ones which are not adequately dealt with by means of replication, something like cascading power failures, or bogus routes) grows with the number of components (at least linearly), and the benefits of redundancy diminish as negative exponent. BTW, Internet is way beyond the threshold if you look at it as a system. Therefore everything which makes the network simplier improves its reliablity.

1 0

Re: Customer AS
by Sean Doran 19 Aug '96

19 Aug '96

-----BEGIN PGP SIGNED MESSAGE----- Per Gregers Bilse <bilse(a)EU.net> writes: > What would happen if the customer used private address space and NAT > & ALGs to hook this into the two providers' CIDR space? I think that this is an excellent idea. In fact, Ed Kern at Digex is working with OFRV on making this real, so that other folks can do so when the NAT code is available in IOS. He might have something to say about your note. > Has anybody noticed that the net global routing table has bumped 40k > a couple of times recently? Yes. Fun fun fun. Has anyone else seen SSE microcode size get too big as a result? Ping. More than 2/3 of the way to the point where 7000s+SSPs will not be usable with traffic towards a fair number of destinations, in routers that carry full routing. > Would the registries have problems with this approach? Would it matter if they did? :-) No, seriously, any concerns about the cases where twice the PA address space will be used should be releived by the reduction in demand (or at least in absolute need) for PI address space. In short, if it works well enough to be a general solution for customer migratability without requiring migratable address allocations, it's obviously a net win for the registries too. > Another issue is that the I-must-be-multihomed-to-different-providers > mantra frequently isn't anything else than a funny idea in somebody's > head. Well, I agree with you about market misperception. However, this doesn't seem to be a very popular thing to say (flame wars ahead), and in part this is because few people have been saying it in public, even when they actually agree. Sean. -----BEGIN PGP SIGNATURE----- Version: 2.6.2 Comment: PGP Public Key in ftp://ftp.sprintlink.net/engineer/smd/pgpkey iQCVAwUBMhZE7kSWYarrFs6xAQEvegQAjTHWfPO1Kbeuc6TYgFJ16EV6KjTq22AM tcW/VGP7NJ3DDuySlDgHqa2180NKrDlBGbU9kyK9nZJB67eWtvigEJ+V4T+D33aP vlJXNItzbQR7X9hnbAHr386VGDFjdm+CrnvC6fPGUZm754B2AbwCI/4qVJ9PZy2s wU78IyMudiM= =TWtU -----END PGP SIGNATURE-----

3 2