January 1996 - Test - lists.nanog.org

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

15 Feb '96

From: Geoff Huston <G.Huston(a)aarnet.edu.au> it will be economically infeasible IF we continue with this strange system of zero dollar interconnections we use as a peering model. ... 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 ... then I'd also note that giving away transit is similarly a case completely irrational behaviour! 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. Geoff, while I sort of agree with you, please note that the current "free" models in all these areas do have one real advantage, which is that they are simple. Perhaps we will need "more realistic economic structure[s]", but I can more or less guarantee you that those will be more complex as well. Also, that complexity has a cost, which also has to be figured in. (The classic example is long-distance telephone service, where the cost of creting the bill is said to be far larger than the cost of the underlying service.) Finally, given past history, I suspect that the 'Net community, and particularly the 'Net technical community, is going to have a painful transition, on the emotional level and others, to this brave new world of more commercial structures, and the inevitable technical impacts that causes. That has certainly been the case in every such step in the past... Noel

14 24

Re: Policy Statement on Address Space Allocations
by Alex.Bligh 05 Feb '96

05 Feb '96

Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> wrote: > If you insist on prefix-length filtering I have proposed a soloution > for future address space allocated via the RIPE NCC several times: > > - set your inbound prefix length filter to /19. > > - The RIPE NCC will *guarantee* that we will not make more than > 1024 non-aggregateable allocations from each /8. > > - The RIPE NCC will continue to work with the providers to > maximise aggregation. Our goal is a maximum of 1024 routes > per /8 visible at major exchange points. Incidentally this > is the same goal that you seem to have. You are not distinguishing (initial) allocation from announcement. Your guarantee is worthless in the sense that it only gurantees that the announcements (as opposed to allocations) can be aggregated if each window allocation is tied to a single AS, and thus, for instance that none of the allocation is for PI space, or for allocation to customers who aren't local-IRs but have their own AS etc. etc. You also have the problem that currently it is impossible for local-IRs to allocate blocks of IP numbers that wouldn't be filtered out to multihomed customers (with their own AS - thus almost inevitably requiring a separate announcement) where that customer under the RIPE rules isn't 'justified' in getting a /19 (too small, for instance). Conservation vs. aggregation again. What is your recommendation on this? Alex Bligh Xara Networks PS: Here's Sprint's sister company's current announcement of routes *originating* in its AS as I see them - I do hope Sprint takes the honest path if it does refuse to carry short announcements and not route all bar 4 of these nets, as well as a similar long list from AS1239 :-) I'm not convinced Sprint has the moral highground here.... Network Next Hop Metric LocPrf Weight Path *> 160.214.0.0 194.68.130.50 0 4000 ? *> 163.164.0.0 194.68.130.50 0 4000 ? *> 194.41.63.0 194.68.130.50 0 4000 ? *> 194.106.0.0/19 194.68.130.50 0 4000 ? *> 194.106.32.0 194.68.130.50 0 4000 ? *> 194.106.33.0 194.68.130.50 0 4000 ? *> 194.106.34.0 194.68.130.50 0 4000 ? *> 194.126.64.0/19 194.68.130.50 0 4000 ? *> 194.133.0.0/19 194.68.130.50 0 4000 i *> 194.133.4.0/23 194.68.130.50 0 4000 ? *> 194.133.6.0 194.68.130.50 0 4000 ? *> 194.133.7.0 194.68.130.50 0 4000 ? *> 194.133.8.0 194.68.130.50 0 4000 ? *> 194.133.15.0 194.68.130.50 0 4000 ? *> 194.133.24.0 194.68.130.50 0 4000 ? *> 194.133.28.0 194.68.130.50 0 4000 ? *> 194.140.128.0/19 194.68.130.50 0 4000 ? *> 194.140.224.0/21 194.68.130.50 0 4000 ? *> 194.149.192.0/18 194.68.130.50 0 4000 ? *> 194.158.0.0/20 194.68.130.50 0 4000 ? *> 194.176.96.0/19 194.68.130.50 0 4000 ? *> 194.204.96.0/23 194.68.130.50 0 4000 ? *> 196.27.0.0 194.68.130.50 0 4000 ? *> 196.27.1.0 194.68.130.50 0 4000 ? *> 198.169.26.0 194.68.130.50 0 4000 ? *> 204.59.0.0/16 194.68.130.50 0 4000 i *> 204.83.37.0 194.68.130.50 0 4000 ? *> 204.83.237.0 194.68.130.50 0 4000 ? *> 204.83.254.0 194.68.130.50 0 4000 ? *> 206.49.64.0/18 194.68.130.50 0 4000 i *> 206.49.65.0 194.68.130.50 0 4000 ?

9 13

Re: Policy Statement on Address Space Allocations
by Peter Galbavy 02 Feb '96

02 Feb '96

> >All this impacts very severely on the commercial decisions taken as to > >the routeing of traffic. I would much rather buy more lines to the US > >and let the traffics flow back to Europe then to just buy lines to > >Europe. Luckily, commercial concerns are not the only contraints > >within which we have to work. > > What this has to do with RIPE allocation policies is beyond > me. Everyone in the European realm suffers from extremely high > tariffs. So what? Sorry - I do not know your background, but here in the UK, in business, money and financing matters. If I can show that I could buy two lines for the same amount of money; where on would be 20% utilised on average and the other at 80% then any money (wo)man will take the second option as it is *seen* to be better use of the money. > You and hundreds of other companies approach RIPE with the same > story of how big they are, how large their investors are, how > their network is gonna take the world of the Internet by storm, > and therefore they deserve a /16 or even a /15. If RIPE followed > your logic, there would be no more address space left. I have to say it, even if I was trying not too, - but we *are* the largest dialup IP provider in Europe. Anyone want to argue ? We are not a new provider asking for a new allocation. We have a large, installed customer base that is growing at between 10 and 15% per *month*. This is difficult enough to manage in terms of our infrastructure. I am doing two things in Amsterdam this week. One is the RIPE, the other is visiting our Amsterdam operation, which is due to go live very soon now. Other countries to follow. We are not new comers here is what I am trying to get across. I think we have suffered in terms of the Internet politics because we have been too busy being concerned about our customer base... > Use dynamic IP like the rest of us. We all realize the drain of > IP addresses and try our best to maximize the addresses. Why > should you be different? Because we have a grwoning customer base that has been buying that particular product fastre than we can sell it for 3 1/2 years now. > It all depends on your ego. You could just look at them as > an organization assigned the tough role of making sure there > are IP addresses available in 1999. You see it as God. A viewpoint > based on your world view. Roll on IPv6 - that will be hell for us, but we will cope. I do not want "fix" what isn't actually broken now, or is likely to be. > IBM has 460 POPs in over 40 countries and uses dynamic IP addresses. > I can be in London or NYC or Tel Aviv and still use my SLIP connection > to read my mail wherever I am. Why should you have static IP addresses > for something others can do the dynamic way and thereby conserve > IP address space? Your mail yes, but can you access secure systems that use IP filtering ? Can you run a BBS from midnight to 5am and p expect people to find your host by domain name ? Can you get SMTP mail delivery ? etc etc. We have always been selling a full Internet connection, not just access. Regards, -- Peter Galbavy peter(a)demon.net @ Demon Internet phone://44/181/371_3700 http://www.wonderland.org/~peter/ snail://UK/N3_1TT/London/42_Hendon_Lane/Demon_Internet_Ltd/

2 1

Re: Policy Statement on Address Space Allocations
by Sean Doran 01 Feb '96

01 Feb '96

| 1) Provider X can announce the aggregate outside of the area & thus | give free transit to the whole area; or | | 2) Provider X can announce just provider X's customers outside of the | area, thus defeating the gain from aggregation; or | | 3) Provider X can be paid by everyone else in the area to provide | transit to the entire area to where ever else Provider X connects to. Just to be vicious, I think I should mention option #4: Provider X can announce the aggregate outside of the area and drop packets bound for people in the area who do not pay Provider X for transiting packets to them. I think you will find that if a system were set up such that there were many touchdowns of this nature (announcing a single prefix), people would be screaming that they were at the mercies of the decisions about to whom in each local aggregate each long-distance carrier would be willing to deliver traffic. One could also view this as a way to push the problems of CIDRization out to the edges -- it would then be the end sites which would have to learn and be able to route towards the exceptions in the local aggregates, rather than the long-haul carriers. Sean.

3 3

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

31 Jan '96

I love engineers playing economists and lawyers :) That reminds me of nuclear physicists who are pretty damn sure they can do anything better than anybody else, including writing programs. Sure, yeah. I would call to look for solutions in the domain we understand and can influence, namely the technological soultions, and let the sleeping legal hounds lie. It appears that the current economical model of Internet is sustainable for time sufficient for design and deployment of new technology. (I meant *new* technology, not IPv6 or creatures of Alcohol-Troubled Minds). Please do not take that personally, it is just a reality check. --vadim

2 1

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

31 Jan '96

From: Curtis Villamizar <curtis(a)ans.net> > 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 ... automated tools we don't have yet, don't hold you breath for > that one either. You may not have to wait as long as you think. ... The idea is to provide a means to specify the aggregation boundary within the IRR and provide the tools to transform that specification into router configurations. Oh, I should also mention that Tony Li did have an idea for how to do something like the above (providing a path between primary and secondary) automatically; it involves forwarding a more specific route toward the source of a more generic route. This is worth investigating, I think. One issue with that approach is how good the routes are to the destination if the link to the primary goes down. A lot of traffic might wind up taking two sides of a triangle, but maybe that's OK for a fallback. The configured AAB probably provides better routing after a failure has happened, at higher routing overhead of course. Also, another way to think of these things are as "partition repair" mechanisms. Some routing protocols which support areas also support automatic partition repair mechanisms; IS-IS does this with a tunnel. Maybe we should look into the work that has been done in that area, too. This code will enable ANS to do much better aggregation that we now do regardless as to whether other providers buy into the idea. To accomplish the type of multiprovider cooperation you refer to above, it is a matter of getting someone else doing the same thing, or something similar enough that we have someone to cooperate with. I think that eventually we're probably going to have to look into abstraction control mechanisms that operate on scales larger than a single provider; not clear how urgently that will happen. It's true that we are having to sit fairly hard on the 32-bit space to fit everyone into it, but now that multi-level CIDR is being deployed, that is not as big an issue. The big issues that I see coming up now are things like: - How do we set AAB's and similar configured items; the current hand configuration of things like this just won't keep working. - The need for continuing to add levels of abstraction (we're currently up to about 5 - carrier, ISP, customer, subnet, host) but need to keep going to keep the routing table growth supportable as the growth in net size continues to outpace technology growth. In other words, addresses will likely have to be more organized at higher and higher levels (since the lower ones are already pretty logically assigned), which is going to be very painful indeed. Noel

1 0

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

31 Jan '96

From: Vadim Antonov <avg(a)sprint.net> 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 :) That why I've always thought that *iff* we have route charging (not sure it's a practical solution, but I think about it), the charge should be based on the *scope* of the advertisement. A route that has to be advertised globally thus costs more. In this case, "Sprint" would pay JBIB a routing fee based on the size of JBIB times the number of routes Sprint injects. JBIB's fee would be the sum of { for each route JBIB injects, the sum of the routing fees to carry that route everywhere it goes in the 'Net }. (Presumably Sprint will have a charge based on the size of its net, etc, etc.) On average, if JBIB is injecting a small number of routes, this work out close to a wash (small no of routes time large scale being about equal to large numebr of routes over small scope) This is an ideal model, in practise it could well be too complex, but it's useful to think about. The better idea is auctioning and trading the routing slots, though it is unclear where the proceeds from the initial auction should go This assume that all slots are global in scope. This is unlikely to be the case. My suggestion was that each ISP auction all the slots in its routers, the money going to the ISP. This produces (in practise) the system above, where the cost of a route is related to the scope over which it is advertised. This has a number of interesting long-term stabilization properties. If the number of routes grows too fast (i.e faster than technology) it will cause the cost of routes to go up, producing back-pressure to rearrange addresses so that we can do the same job with less routes. Also, if a key ISP doesn't provide enough routing slots, or gouges people for them, in either case driving up the price, that will increase the cost of using that ISP, and a competitor can snarf the business. 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. Well, it's certainly more complex, and maybe unworkably complex. On the other hand, if there is a problem, *something* that can handle it will evolve one way or the other. If community pressure on people to be good about routes won't do it, life suggests that some other means, a combination of legal and commercial (since that is how we allocate scarce resources in this world, which is what routing slots will be), will arrive. Noel

1 0

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

31 Jan '96

At 2:41 PM 30/1/96, Andrew Partan wrote: >> The proper solution is for all these companies to form a consortium. The >> consortium would run the NAP and contract with multiple NSP's for >> service. In that case, the NSP's are not providing transit to >> non-customers because the consortium is the customer and every ISP who >> joins the consortium gets multihoming reliability outside the region. > >Ah - we may have something that works - we have someone (the >consortium) being paid (by these companies) to provide (or further >purchase) transit. My initial message may have been terse, but I was certainly not expecting the "deviant CIX" or "specialized NAP" or "Agregating CIDR Internet Detour" (ACID, (tm)) to provide world wide reachability for free. In fact, it is providing a service at a cost. The service is to provide reachability to smallish 192/27 single home or multihomed networks. It does so by aggregating several such networks into a larger, CIDR routable, 192/8 (or /10, or /15). The cost is indeed that the transit traffic goes through the ACID, consume bandwidth and other resources, and that these resources have to be payed for. In short, networks owners pay for not having to renumber; how much they are ready to pay depends on how expensive their renumbering will be. Paying can be done in many way, from the "consortium" which you suggest to some fees to a service company that operates the ACID. In fact, the major roadblock here is the intrisic monopoly -- at first sight, there can only be one ACID for a given aggregate. This may trigger all sorts of regulatory questions. Sharing of resource between consortium members or service customers may be done either the usual way (i.e. FIFO and random luck) or in a more organized way, e.g. using class based queuing. Christian Huitema

3 2

Re: Policy Statement on Address Space Allocations
by marthag＠MIT.EDU 31 Jan '96

31 Jan '96

> > In message <199601291642.QAA09648(a)diamond.xara.net>, "Alex.Bligh" writes: > > Iljitsch van Beijnum <iljitsch(a)unix1.bart.nl> wrote: > > > > > No they don't. You can ask the RIPE NCC for special PI space to assign to > > > this customer. It seems they have a "chemical waste dump" to satisfy > > > this kind of requests from. > > > > Ah. That will be the "chemical waste dump" that Daniel K said > > he didn't care about whether it got routed or not (no offence > > Daniel - neither do I), and is all but unaggregatable so presumably > > Sprintlink et al. won't want to waste their CPUs routing it as well. > > What hope for a customer with those IP numbers? > > > > Alex Bligh > > Xara Networks > > > Alex, > > Here's my suggestion. > > If you put that multi-homed customer in a larger aggregate (have them > pick one of the providers and allocate from their address space) all > of the providers must then announce the more specific. Some providers > will block the longer prefix. The longer prefix will be preferred and > traffic will avoid going through those providers that block it. This > might cause longer or suboptimal routing for the longer prefix. > Providers everywhere will have either the shorter prefix or both, so > full connectivity would exist. > > If the multi-homing is sufficiently localized within the topology (for > example, multiple providers in the same region or country) there might > be a chance to draw an aggregation boundary around the whole thing and > block the longer prefix outside of that locality and avoid the > possibility of suboptimal routing due to long prefix filtering. > > Curtis > Except that if the shorter prefixed route goes down, half the world will not be able to see any route to site, which sort of defeats the purpose of being multi-homed. Martha Greenberg marthag(a)mit.edu

2 1

MCI to market MSN
by alexy＠alpha.c2.org 31 Jan '96

31 Jan '96

MCI and Microsoft will now be building networks together, MCI ditching Netscape and starting to sell Microsoft network access tools & pushing MSN... >From the local rag news paper: "MCI, Microsoft to jointly market on-line services WASHINGTON -- MCI Communications Corp., switching its Internet Strategy, said it will team up with Microsoft Corp. to jointly market and develop services for the burgeoning on-line industry" The story later goes on to say: "MCI will promote Microsoft Network, the No. 4 U.S. on-line service, and sell Microsoft's Internet software through its SHL Systemhouse unit" Interesting, No? -alex

3 2