- Test - lists.nanog.org

Re: Policy Statement on Address Space Allocations
by Vadim Antonov 31 Jan '96

31 Jan '96

The zero-settlement scheme works ok as long as interconnected parties are of about the same size. That makes them suffer equally from routing bloat. Incidentally, that was part of the reasoning after Sprint's IXP peering policy. In any case having zillions of small ISPs to be at top-level IXPs is economical and technical insanity, and it seems that it can only be fixed by rather steep settlements at IXPs to make it a very expensive prestige shopping. BTW, "settlements for routes" is a rather interesting thing. Imagine, say, Sprint peering with Joe Blow Internet-And-Burgers. Let's assume that route costs $100/yr, so Sprint pays $1M/yr to JBIB and JBIB pays back $300/yr. Sounds like a good business for JBIB :) The better idea is auctioning and trading the routing slots, though it is unclear where the proceeds from the initial auction should go. Probably to fund the Network Police which would chase the bootleg route injectors. I don't know what you make of it, but i think that sucks a lot more than the zero-sum model we have now. --vadim Not speaking for Sprint. PS Given the choice between fixing the technology and fixing the society it is always more prudent to go after technology. >From list-admin(a)merit.edu Tue Jan 30 20:56:10 1996 Received: from merit.edu (merit.edu [35.1.1.42]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id UAA11534 for <avg(a)titan.sprintlink.net>; Tue, 30 Jan 1996 20:56:08 -0500 Received: from nico.aarnet.edu.au (nico.aarnet.edu.au [139.130.204.16]) by merit.edu (8.7.3/merit-2.0) with SMTP id TAA25560 for <nanog(a)merit.edu>; Tue, 30 Jan 1996 19:59:35 -0500 (EST) Received: (from gih@localhost) by nico.aarnet.edu.au (8.6.10/8.6.10) id LAA25214; Wed, 31 Jan 1996 11:56:53 +1100 From: Geoff Huston <G.Huston(a)aarnet.edu.au> Message-Id: <199601310056.LAA25214(a)nico.aarnet.edu.au> Subject: Re: Policy Statement on Address Space Allocations To: huddle(a)mci.net (Scott Huddle) Date: Wed, 31 Jan 1996 11:56:53 +1100 (EST) Cc: asp(a)uunet.uu.net, G.Huston(a)aarnet.edu.au, cidrd(a)iepg.org, nanog(a)merit.edu In-Reply-To: <199601310009.TAA06568(a)new6.Reston.mci.net> from "Scott Huddle" at Jan 30, 96 07:09:12 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: R Yes this inevitably leads to another instantiation of the Grande Olde Religious War on Settlements. However now the folk who are religiously tainted towards supporting the continued viability (or even absolute necessity in some versions of the War) of zero dollar interconnection now have the added hurdle of demonstrating how they can also solve the routing table scaling issues as a basic precursor of demonstrating that Zero Dollar settlements (aka free transit) is a Good Thing. Good luck and may the force be with them. And the forum in which this will happen? Personally I'm of the view this is not an area which naturally lends itself to the open processes of NANOG and the IETF. The most likely scenario is that the forum will either be smoke-filled back rooms or elevated views on the 150th floor, or both. And no, this is not a completely comforting answer for many. thanks, Geoff > > In the same way that giving away IP addresses and giving away IP > > routing can only be described as a very bad case of irrational > > behaviour, especially when the underlying resource is under stress as > > it is at present, then I'd also note that giving away transit is > > similarly a case completely irrational behaviour! > > Agreed, but doesn't this lead to the religious War On Settlements. Yakov's > push/pull paper on route announcements coupled with traffic levies > would seem to to address your point. Do you agree? > > > All this points to a desperate need for a more realistic economic > > structure to be used within a number of key aspects of Internet > > infrastructure. > > Agreed, what are the forums, though? There are both techie questions to > be answered as well as hard business case scenarios. NANOG seem > unlikely to address the former, where the IETF seems ill equipped to > answer the latter. > > -scott > > [...] > > Andrew's comments: > > > > > > > > > Half correct. Everyone in the area carries full routes for the block. > > > > Everyone outside the area can listen to only the /8 advertisement. > > > > > > So these providers are providing the free transit to their > > > non-customers? > > > > > > This does not make any business sense; it will not happen. > > > --asp(a)uunet.uu.net (Andrew Partan) > > > > > > > > > > > >

1 0

Re: Policy Statement on Address Space Allocations
by Robert A. Rosenberg 31 Jan '96

31 Jan '96

At 6:09 1/29/96, Alex.Bligh wrote: > Currently I have 2 choices as >far as I can make out, give them a bit of my /19, break up my >nice aggregate and ensure loads of extra announcements (and that >probably none of them get routed by anyone applying prefix based >filtering), or give them a new /19 all of their own (you've >said it, that's the minimum size allocation) which actually >solves their problem and mine, but this isn't an option >currently available because currently it's one window per local-IR. >So they have to go and become a local IR. If the high /21 of your /19 is not Allocated, you just assign it to them and add ONE announcement of the /21 to supersede with the current /19. If it is not free but is sparsely populated you can move the stuff out to free it up or go to RIPE to get your /19 turned into an /18 (ie: get the /19 right after your current /19 [RIPE did give you the first /19 in a shorter prefix block didn't they?]) in exchange for returning the /21 worth of space [giving you 3 extra /21s worth of space], and divide that 2nd /19 into a /20, and 2 /21s giving them the 2nd /21 (still doing the same 2 announcements as you would if allocated out of your current /19).

5 4

Re: Policy Statement on Address Space Allocations
by Scott Huddle 31 Jan '96

31 Jan '96

Geoff Huston <G.Huston(a)aarnet.edu.au> writes > If you manage to provide a better model for interconnection which > includes a rational economic model of interaction then, strangely > enough, you then have a powerful tool you can use to address teh > technical issue of scaling the routing domain. > > i.e. > > "free transit" is stupid, as Andrew indicates. > > "transit" is possible given a rational economic model of the > transit interaction. > > In the same way that giving away IP addresses and giving away IP > routing can only be described as a very bad case of irrational > behaviour, especially when the underlying resource is under stress as > it is at present, then I'd also note that giving away transit is > similarly a case completely irrational behaviour! Agreed, but doesn't this lead to the religious War On Settlements. Yakov's push/pull paper on route announcements coupled with traffic levies would seem to to address your point. Do you agree? > All this points to a desperate need for a more realistic economic > structure to be used within a number of key aspects of Internet > infrastructure. Agreed, what are the forums, though? There are both techie questions to be answered as well as hard business case scenarios. NANOG seem unlikely to address the former, where the IETF seems ill equipped to answer the latter. -scott [...] > Andrew's comments: > > > > > > Half correct. Everyone in the area carries full routes for the block. > > > Everyone outside the area can listen to only the /8 advertisement. > > > > So these providers are providing the free transit to their > > non-customers? > > > > This does not make any business sense; it will not happen. > > --asp(a)uunet.uu.net (Andrew Partan) > > > > > >

2 1

Re: Policy Statement on Address Space Allocations
by Brett D. Watson 31 Jan '96

31 Jan '96

> > > > Ah, the "Bill Manning Solution"(tm). Now if we could only get ISPs > > like Sprint to play, Bill could get his Nobel Internet Prize. > > > > Er, this is to give you notice that my legal counsel advises me > that you should cease and desist until the appropriate documents > are signed. > > And its not the Noble (or even igNobel) prize I'm after, its > 192.0.0.0/8 !!!! Bwahahahah :) > > As to the monies collected? I need a new wardrobe and a shave. > Perhaps even a life :) at least buy some new t-shirts :) -brett

1 0

Re: Have we started to chop up the B-space into /24's.
by Brett D. Watson 31 Jan '96

31 Jan '96

the problem is that sprint is filtering this announcement per sean's policy. -brett > > Hmm: > > Well since the Net 39 experiment proved that it is ok to chop > larger class-full address block into smaller class-less address > blocks, why not. > > --jon. > > > From list-admin(a)merit.edu Tue Jan 30 08:19:07 1996 > Date: Tue, 30 Jan 96 16:56:54 MET > From: Peter Lothberg <roll(a)stupi.se> > To: nanog(a)merit.edu > Subject: Have we started to chop up the B-space into /24's. > > > Date: Mon, 29 Jan 1996 17:50:09 +0000 > From: William griffin <wgriffin(a)mci.net> > To: insc(a)sprintlink.net > Cc: trouble(a)mci.net, pp000314(a)interamp.com > Subject: route not being advertised > > We have a customer with the following address: 164.103.3.0/24 and it seems > that you are not accepting our advertising of it. Could you please adv. > > -- > The darkness illuminates the light. > > William Griffin > Network Engineer > wgriffin(a)mci.net > (800)977-4662 > > > % whois 164.103.0.0 > > Telecommunications Department of Information Systems (NET-IPAPER) > International Paper > Southwind Computer Center > 3232 Players Club Parkway > Memphis, TN 38125 > > Netname: IPAPER > Netnumber: 164.103.0.0 > > Coordinator: > Harrison, Donald R. (DRH37) PP000314(a)INTERRAMP.COM > (901) 748-5459 (FAX) (901) 748-5401 > > Record last updated on 08-Feb-93.

1 0

Re: Have we started to chop up the B-space into /24's.
by Brett D. Watson 31 Jan '96

31 Jan '96

the customer owns the whole /16 but for some reason they only announce this /24. -brett > At 04:56 PM 1/30/96 MET, Peter Lothberg wrote: > > > > >Date: Mon, 29 Jan 1996 17:50:09 +0000 > >From: William griffin <wgriffin(a)mci.net> > >To: insc(a)sprintlink.net > >Cc: trouble(a)mci.net, pp000314(a)interamp.com > >Subject: route not being advertised > > > >We have a customer with the following address: 164.103.3.0/24 and it seems > >that you are not accepting our advertising of it. Could you please adv. > > > >-- > >The darkness illuminates the light. > > > >William Griffin > >Network Engineer > >wgriffin(a)mci.net > >(800)977-4662 > > > > > > Hmm. > > According to WHOIS, 164.103/16 appears to belong to: > > % whois 164.103 > Telecommunications Department of Information Systems (NET-IPAPER) > International Paper > Southwind Computer Center > 3232 Players Club Parkway > Memphis, TN 38125 > > Netname: IPAPER > Netnumber: 164.103.0.0 > > Coordinator: > Harrison, Donald R. (DRH37) PP000314(a)INTERRAMP.COM > (901) 748-5459 (FAX) (901) 748-5401 > > Record last updated on 08-Feb-93. > > The InterNIC Registration Services Host contains ONLY Internet Information > (Networks, ASN's, Domains, and POC's). > Please use the whois server at nic.ddn.mil for MILNET Information. > > - paul >

1 0

Re: Draining the Swamp, A Straw Proposal
by Justin W. Newton 30 Jan '96

30 Jan '96

On 29 Jan 96 at 20:56, Sean Shapira wrote: > Introduction: > ------------- <snip> > - Depend only on voluntary participation by Internet providers. I hate to say this but... I previously worked for a different place than I do now. Part of the reson I left was the complete "Whats in it for us" attitude there. I have a feeling that that attitude is becoming far too prevelent on the internet. Of late there seems to be a much higher quitient of people running providers who are either slothful, not technically competent enough to do their job, or both. None of these people will renumber unless they have to. (I have a feeling renumbering at the place that I used to work would take at least 2 weeks, given 1 months notice for a handful of Class C's). No matter what you do, people like this are going to be affected by your change and are going to resist it unless they are more or less /forced/ to act. If they get someone with talent to work there they will /forbid/ him from doing the right thing if it takes more than 30 minutes of his time or /not/ doing it has a real identifiable cost to them. /These/ are some of the people who have these small blocks, and these are the people we have to reclaim some space from. It may be politically bad, but if we are going to do some space reclamation, lets do it whole bore. > > - Gain for participating providers smaller route tables. > > - Assure that no customer of a provider is unduly harmed by > the provider's participation. > > Can a solution be found that includes all these criteria? Perhaps > not, but here's a "straw" proposal nonetheless. > > Proposal: > --------- > > Participating providers divide a swamp into sections. For > example, four providers could divide 192/8 into 192.0/10, > 192.64/10, 192.128/10, and 192.196/10. > > Each provider continues to announce its customer /24 routes, but in > addition each announces to the others one of the four /10 routes. > For the /10 route which it announces, each provider accepts and > keeps all the /24 routes it hears. For the other three, it keeps > only the /10 route and filters out any /24 routes it hears. > > The resulting routing might be inefficient: provider A might > deliver packets to provider B that are eventually destined for > a customer of provider C. But packets do continue to reach > their ultimate destinations. > > Providers get smaller route tables, while customers remain > blissfully unaware (and thus continue to pay for service ;-). > > Note that four is not a magic number: any two providers could > bilaterally enter into an agreement of this type and get reduced > route table sizes. > > Personal Note: > -------------- > > As an observer on the sidelines of nanog activity, I certainly > lack the experience of the "older, wiser heads" who operate the > major providers' backbone networks. Those with that experience, and > the knowledge accrued therefrom, may well find gaping holes in this > straw proposal. I look forward to their criticism, either in > traffic on the list, in private email, or in person at the upcoming > San Diego meeting. > > -- > Sean Shapira sds(a)jazzie.com +1 206 443 2028 > <a href="http://www.jazzie.com/sds/">Sean's Home Page</a> > Serving the Net since 1990. Justin Newton | jnewton(a)hq.mainet.com Internet Administrator # (703) 506-0505 MAI Network Services | Detroit MXP online now #

2 1

Re: Policy Statement on Address Space Allocations
by huitema＠pax.inria.fr 30 Jan '96

30 Jan '96

At 11:22 AM 26/1/96, Sean Doran wrote: >| > We just have some differences of philosophy -- you think >| > that RIPE really can persuade people into having only >| > 1024 announements (preferably far fewer) in 195/8, and >| > I don't. That's all. >| >| OK. I call this a challenge but you won't let me try ;-). > >You and Randy Bush seem to be reading each other's minds. > >He has proposed this in a way that is very interesting, >and which I will think about. > >There is a bad failure mode to consider that even a badge >afterwards won't make any more attractive. > >Mostly it's "what on earth do we do if we cross the >threshold of 1024 prefixes in 195/8?" to which I see no easy >answer that doesn't involve inflict enormous pain on people >with old, established long prefixes in 195/8. There is at least one very simple response. Set up some deviant CIX, say IX195-8, let everyone with a shortish 195/8 prefix connect to it either directly through their own provider, or indirectly through some tunnel, and have IX195-8 announce reachability of 195/8. That is, in short, altern topology to meet addresses when the converse is too hard. KRE detailed that for the general case, but it would be even simpler in the case of RIPE, since all the allocated network numbers are in the same geographical area. Christian Huitema

6 6

Re: Policy Statement on Address Space Allocations
by jnc＠ginger.lcs.mit.edu 30 Jan '96

30 Jan '96

From: "Joel M Snyder, writing fool" <Joel_M_Snyder(a)opus1.com> The company wishes to have more than one connection to the Internet through more than one of the major providers From: lodge(a)houston.omnes.net (Mathew Lodge) its upstream provider ... They also want to be multi-homed from day one. They currently offer all sorts of fully redundant data services, and understandably they can't see why they should have a single point of failure in their global Internet access. Oh, good, the multi-homing discussion again. (The loud "bang" you just heard was Noel blowing out his brains in sheer desperation and frustration.) Here's a repeat of a previous post to a different list: For those who aren't up on the technical background to multihoming, you should consider consulting the Big-Internet archives from the end of September '95 for a long discussion of it. (In particular, see the thread "Discussing encap/mapping proposal", especially the messages of Thu Aug 31 23:33:12 1995 from me, Fri, 01 Sep 1995 11:13:39 -0500 from Scott M. Ballew, and Fri Sep 1 13:25:59 1995 and Sun Sep 3 01:23:59 1995 from me, which discuss the theoretical background in some detail. The thread "Multihoming", especially the messages Fri Sep 1 11:20:25 1995 and Mon Sep 4 14:26:06 1995 also contains some valuable material.) For those who don't wish to paw through all that, here are the salient points, quickly: 1. Multihoming for robustness adds new capability to the system, and that new capability does not come without cost, the cost being greater routing overhead. The amount of routing overhead will vary depending on many factors. 2. Connectivity-based addressing (i.e. the thing that "provider-based" is a subset of) provides routes at least as good, and at as least as small a cost in routing overhead, as any other addressing scheme. (Connectivity-based addresses for multi-homed sites allow us to use less than global scopes for the advertisement of routing information about such sites. Non-connectivity-based addresses do not have this characteristic; they require advertisment through the entire network.) 3. The cost in routing overhead (at least in conventional hop-by-hop routing systems such as the current Internet) is dependent on how far apart, in the connectivity topology, the multiple connections are. (More widely separated connections can increase the routing overhead with little payback in increased reliability.) 4. The cost further depends (again, in the same kind of systems) on how optimal you want routes to be if both links are up, how optimal you want them to be if one is down (and it will vary depending on whether it's a primary or secondary). I hope everyone will keep these 4 main points in mind in any discussion on multi-homing. Now, a few extra comments appropriate to this case: There is *no way*, in the current overall routing architecture (which uses exchange of routing tables) to add multihoming for fault tolerance without a cost in routing overhead. Providing this fault-tolerance is not zero-cost in *any* scheme I can conceive (TANSTAAFL, surprise, surprise), but some are better than others. Since redesigning the entire architecture is not something we can do this week, I'll leave the pleasant contemplation of such alternatives to academic, ivory-tower, environs. We can *easily* limit the amount of routing overhead caused by multi-homing among different providers if we provide some structure in the addressing hierarchy *above* providers. (To be technical, this will allow less than global advertisement scopes of such multi-homed entities.) Since this could necessitate renumbering most of the 'Net, I don't expect it to happen anytime soon. We can also limit the amount of routing overhead by providing configured AAB boundaries for a given multihomed site which enclose a path between the primary and secondary providers. Since this will in some cases require cooperation among multiple providers, as well as either i) massive amounts of manual mechanical configuration bookkeeping, or ii) automated tools we don't have yet, don't hold you breath for that one either. Noel PS: If you didn't understand that last paragraph, read the references before you speak.

3 2

Re: Policy Statement on Address Space Allocations
by Sean Doran 30 Jan '96

30 Jan '96

| If word gets out that going with a small provider == having | to renumber your corporate hosts regularly, big providers will have | effectively locked small players out of the market... which helps their | pocketbooks at the expense of a lot of other people. Well, I can only speak about one big provider, however I would be surprised if my view is not shared to some extent by at least some of our competitiors, and by all the engineers at ALL of them, no matter what their marketing people have gotten into their heads. Large providers cannot afford to squeeze small providers out of the marketplace. Not one of them has more than a tiny fraction of the customer-support labour resources of the aggregate of their own customers (not to mention customers' customers, and so on and so forth). Indeed, there are more customer-support handholders employed by folks downstream from Sprint around the world than there are people who work for Sprint. Moreover, there are timezone issues, local language issues, and numerous other problems that would have to be dealt with by any large provider attempting to be a worldwide dialup-Internet/local-services provider. I am willing to bet my farm that SprintLink could never support large numbers of dialup end users in a reasonable way and do so in a manner that is cost-competitive with our customers. In fact, the bulk of our cutomers who are reading this message may well quip that SprintLink has done a just barely tolerable job of supporting its current customer base. Moreover, while there is a much stronger corporate committment to SprintLink now than there ever has been in its history, and what looks alot like strong recognition by senior executives that the Internet is Really Different from private data networking services, I don't think anybody really believes we could compete on the customer-support front with two-smart-people-and-a-bunch-of-{modems,ISDN}. Being a large service provider is about pushing the envelope of IP and transmissions technology, about dealing with complicated routing issues, and about supporting large customers better and more cost-effectively than they could do by stringing their own lines among themselves. Being a small service provider is about customer support. Moreover, it's customer support for people whose only exposure to the Internet so far has involved paying too much money to folks like Prodigy. In other words, don't panic about large providers competing directly with local access providers. No customer-support resources, no desire to dry up the substantial revenue we get from more local access providers (some of which are continental in scope, some of which are national in scope, and some of which are local to a state or metropolitan area). Now, what is true is that some of the companies who are big providers have invested lots of money into trademarks and brand names and are keen on keeping themselves visible in the consumer market as something of a household name. Do not be surprised to see, rather than an attempt to squash out local providers, many plans to swing deals with local providers as outsource centres for customer support or as franchises selling lower-end services, that would result in making some small providers much bigger and much richer. Moreover, franchise/outsource deals or no, remember that our goal is to do what we're really good at (providing international backbone connectivity to smart people who don't need very much customer support) and make money doing it. It is not forcing customers to stay with us and us alone that helps our bottom line, it's giving customers enough good service and support that they are a/ happy and b/ in need of MUCH more bandwidth to SprintLink, for which we will happily charge money. So instead of seeing customers multihoming or wanting to be able to multihome as a disease, I see it as a symptom. The disease is that we have a bunch of hardware which must handle enormous loads for which they were never designed, and which we can't replace immediately, because there is no better alternative. Moreover, with respect to some things, such as an ever-increasingly-large-and-flap-prone routing table, there is no ultimate cure except preventative medicine. That medicine is called CIDR (Call it data robitussin?), and helping roll out ANYTHING that will encourage people to avoid increasing the size of routing tables in the routers of the world which are most CPU bound right now. The encouragement, IMHO, should be in the form of the work PIER is addressing (sorry about the pun), some possible future renumbering tools, NATs, or any other technology which results in making a change of addresses painless and quick, so that people have little or no reason to object to using provider-supplied addresses. | At this rate we're going to see the policy change to "each RBOC gets a /7 | out of the old class A space, and then that's it" Have you ever met an RBOC data person? Have you ever met anyone at an RBOC who understands the Internet? Hi Warren! (Well, there's Mark Knopper, I suppose, so there's at least one person at one subsidiary of one RBOC...) You're better off panicking about @Home, who have been hiring some amazingly clueful people, but I think you will find that even they would rather make money off small ISPs than consider them competitors. So, that said, hopefully a little of the Evil Greedy Bastard image will be dispelled in your mind, and a bit of "hm, you know, maybe they aren't lying through their teeth, and maybe this is good for *US* too", might have seeped in. If not, well, then may your days (in the future sometime) of being considered an arch-villain by smaller organizations be at least as interesting as mine. Sean.

5 6