January 1996 - lir-wg - mailman.ripe.net

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: Chiappa blows his brains out (was Re: Policy Statement)
by jnc＠ginger.lcs.mit.edu 30 Jan '96

30 Jan '96

<There's an interesting point in the middle of this, about how multihoming presents technically rooted problems no matter *how* we do the addressing, even if we solve the conflict he mentions, and that these problems have an impact on what policies it is useful to discuss...> From: "Joel M Snyder, writing fool" <Joel_M_Snyder(a)opus1.com> GIVEN that I have sufficient knowledge about routing as is necessary to fully understand every technical issue involved Sorry, I guess I just assumed the wrong interpretation of what your question was about. (Also, to be honest, if we've got to the point that most everyone understands these issues, I guess it's time for the champagne... :-) GIVEN that I have a rudimentary and imperfect understanding of the political and economic issues regarding IP numbering and the propagation of routes thereunto I'm not sure anyone has a truly "global" view of this, although if one listens on this and other lists hard, one can start to get a view which integrates the large and small ISP's, equipment suppliers, etc, etc... GIVEN that there exists some set of organizations who want to purchase multiple T1s from multiple independent suppliers ... HOW do I resolve the conflict between justifiable corporate service requirements and the expressed statements ... that anyone who does not consume at least a /18 worth of address space is not worthy of being globally routed? To start with, this is another case where setting the size-based filter for routing updates is having deleritous effects. Again, all we're doing is creating a demand for address space, and as long as there is no well-modulated back-pressure on address space (such as charging for it), I'm not sure I see any easy way of dealing with it. Second, whether it's a /18 or a /24 is of no interest to the routing. Let's assuming we can separate the addressing issues out, to focus just on the routing cost, which is going to be the same *regardless* of how you resolve the address space issues. This is important: *** No matter how you do the addresses, you *still* have the problem that if *** a significant percentage of customers want to be multihomed, and we still *** don't have any mechanism or tools for reducing the scopes of those *** advertisements from global (such as I mentioned in my original message on *** this thread), we will find it technically impossible to provide this *** multihoming capability to a large number of users: we will be rerunning the *** very routing table growth (tracking local sites individually) that caused *** us to go to CIDR in the first place. I don't know about you, but I could do without a re-run of that particular learning experience! :-) Ideally, in solving this, I would take a monetary approach, which is to say "what are the true costs of this multihoming, and given that, is it important enough to the client for them to pay for it", but of course we don't have a charging mechanism for routes that would help to answer this, and maybe never will. So, I can't use that copout. Maybe a better question is to ask "what goal are they really after with multi-homing", because if the answer is "reliability", then perhaps they get more bang for their <insert-local-currency> with things like multiple access lines, etc. I am asking, I suspect, not for a technical answer (there being none other than Chiappa's "it's gonna cost"), but the most politically correct answer to give the organization I understand that you have a very "bottom-line" concern, which is "what do we tell the customer", but I hope that this time I have made clear to everyone that there is no solution to the technical question of "can we provide multihoming on a large scale", *at least in the system as it stands today*. (I.e. if this is an important goal we need to get cracking on technical solutions...) Any policy discussion must take place in an environment which is aware of this technical constraint. Thus, your question about the policy conflict you pointed out is interesting and true, but ultimately not a critical one... Noel

1 0

Re: Chiappa blows his brains out (was Re: Policy Statement)
by jnc＠ginger.lcs.mit.edu 30 Jan '96

30 Jan '96

From: Scott Huddle <huddle(a)mci.net> Probably the best thing that be currently supported is getting two diverse connections to a single provider that can globally aggregate your network. The connections should go to different POPs and should follow seperate physical paths. This should provide you the desired reliability and load sharing. This solution has been pointed out before. Also, Dorian Kim sent in a good message to the Big-Internet list talking about reliability (the stated goal of most multi-homing), and the 7 places you could do redundancy, and what was really important in achieving reliability, which contained a lot of good insight. Here's his message (appended). Noel -------- Date: Fri, 1 Sep 1995 03:57:16 -0400 (EDT) From: Dorian Rysling Kim <dorian(a)cic.net> To: ... big-internet(a)munnari.oz.au Subject: Re: Multihoming .... There are many places where redundancy can be achieved with multiple connections. 0) Equipment spares on site 1) Diverse local access of the two links 2) Diverse routing of the physical links into COs 3) Diverse routing to different local providers 4) Diverse routing to different regional providers 5) Diverse routing to different large transit providers (MCI, Sprint, ANS, Alternet, Eunet etc) 6) #5 + connection to the NAPs. All of the above give you redundancy at various single points of failures. In my experince, #0 - #2 should be considered as important in providing true redundancy as 4-6. In fact, in most cases, the most common case of outtages come from equipment failures, and circuits themselves, and sites who are looking for multihoming for the reason of redundancy should look at the cost of having 0-2, and think long and hard about whether multihoming is what they really need. -dorian

1 0

Re: Chiappa blows his brains out (was Re: Policy Statement)
by Scott Huddle 30 Jan '96

30 Jan '96

Joel_M_Snyder(a)Opus1.COM writes > GIVEN that there exists some set of organizations who want to purchase > multiple T1s from multiple independent suppliers for purposes of > reliability and load sharing yet have need for less than 255 unique IP > addresses, and GIVEN that certain extremely popular software products (such > as Netscape Navigator) which are important to these organizations were > developed by programmers who seem to have no knowledge of either efficiency > or the way that the Internet works, and GIVEN that I have sufficient > knowledge about routing as is necessary to fully understand every technical > issue involved, and GIVEN that I have a rudimentary and imperfect > understanding of the political and economic issues regarding IP numbering > and the propagation of routes thereunto, HOW do I resolve the conflict > between justifiable corporate service requirements and the expressed > statements on these mailing lists the past few weeks which seem to imply > that anyone who does not consume at least a /18 worth of address space is > not worthy of being globally routed? > > I am asking, I suspect, not for a technical answer (there being none other > than Chiappa's "it's gonna cost"), but the most politically correct answer > to give the organization (which is not Netscape). You present a hard edge case that isn't particularly well met by the current infrastructure and it can't necessarily be done well or even done at all. (Sean's tricky chocolate-consulting hack excluded). Probably the best thing that be currently supported is getting two diverse connections to a single provider that can globally aggregate your network. The connections should go to different POPs and should follow seperate physical paths. This should provide you the desired reliability and load sharing. -scott

2 1

RE: Chiappa blows his brains out (was Re: Policy Statement)
by lodge＠houston.omnes.net 30 Jan '96

30 Jan '96

Scott, >You present a hard edge case that isn't particularly well met by the current >infrastructure and it can't necessarily be done well or even done at all. >(Sean's tricky chocolate-consulting hack excluded). Probably the best >thing that be currently supported is getting two diverse connections to >a single provider that can globally aggregate your network. The connections >should go to different POPs and should follow seperate physical paths. >This should provide you the desired reliability and load sharing. Thank you, thank you, thank you. This is exactly the kind of pragmatic advice I was looking for. Saying "don't do it" or "multihoming costs" is not helpful -- this sort of answer is. Regards, Mathew

1 0

Hmmmmmm...
by Sean Doran 29 Jan '96

29 Jan '96

>From the latest Cook Report: | InterNIC now dealing with IP address requests from 50 new ISP start ups | every week. By sending them to their upstream providers InterNIC has | gone from handing out 800 CIDR blocks in the /24s to /21s ranges to about | 30 /24s - /21s per month. Sean.

3 2

Re: Policy Statement on Address Space Allocations
by Hank Nussbacher 29 Jan '96

29 Jan '96

On Fri, 26 Jan 1996 13:59:32 +0000 (GMT) you said: >Just to spend a few minutes thinking about it, what do the phone >companies do ? They are the nearest thing with a large installed base >that the Internet even begins to map onto. There are however some >fundemental differences - primarily the fragmentation of Europe (which >is not the case in the US). > >We have a 2Mb line from London to Amsterdam which costs us very much >the same as a T1 from London to Washington. As I understand it, this >"milk them for all they are worth" pricing of the telcos applies to >cross-border land lines in Europe also. > >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? >To wash some dirty laundry here, we as a provider have been trying to >get new address space for our dial up customers from RIPE NCC for almost 6 >months now. We allocate *each* dialup customer *1* IP address from a >block and dynamically route them based on where they log in to the >service (including RSN Amsterdam). The RIPE NCC has >effectively< refused >us space because they believe that we should change the product we >sell and use dynamic IP for dialups. > >We are the largest dialup ISP in Europe. We are not the largest provider >in Europe because we follow the rest of the ISPs like sheep, buying Ciscos >and installing off the shelf terminal servers. We provide a product which >our customers understand gives them *more* for their money. We do something >different, and the customers like it. Tough fact of business life that. 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. 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? >But this is all I have seen you do, therefore, how can I but believe >that this is the case. Every private mail that has been sent to us as >a company involves you acting as God and us as the grovelling peasants >praying for a benidication of address space. I have all these mails >in my various folders, as do you. 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. >Why not. We are not a communist society are we ? Each individual member >of RIPE have their own unique requirements in a commercial and >academically challenging world. We have a USP (Unique Selling Point) of >giving our paying customers there own IP address (OK - it is not >unique, but close enough). We have built propretary technology that >allows our users to use *any* of our dial in points and get the same >service, with the same IP number etc etc, and as one of our primary USPs >we cannot allow the RIPE NCC to try to change that. 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? >Peter Galbavy peter(a)demon.net Hank Nussbacher Israel

2 1

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

29 Jan '96

At 8:04 PM 27/1/96, Hank Nussbacher wrote: >What this has to do with RIPE allocation policies is beyond >me. Everyone in the European realm suffers from extremely high >tariffs. So what? Because tariff distort topologies. In the short term, if you drew a map that used tariffs as the metric of your topology, the Atlantic would hardly be larger than the Rhine. This in itself is at cross purpose with the local implementation of CIDR, i.e. allocation of addresses to European networks from a European block by the RIPE NCC. If you look at the medium term, the perspective is even more interesting. Deregulation will gradually take place in the next three years. It will most probably result in lower tariffs for some lines, but not all, and definitely not at the same time. Take the map which I mentioned above. Imagine it printed on a fin sheet of elastic rubber, not paper. The effect of deregulation is that for the next three years the rubber will be constantly deformed, shrinking here and inflating there, and you are very lucky if you can predict where and when. To believe that this would not have some influence on addressing and internetworking is at least shortsighted. Christian Huitema

2 1

Re: Policy Statement on Address Space Allocations
by Geoff Campbell 29 Jan '96

29 Jan '96

> From: Ronald Khoo <ronald(a)office.demon.net> > That's too simplistic. A /19 in the Netherlands may well make sense. > In the UK it would be far too small, for ANY of our registries. That may well be the case with Demon Internet, who allocate a fixed IP address per customer, but for ISPs like ourselves at Global who use dynamic addressing, a /19 is fine - I've just renumbered my network to handle the next 37,500 dialup customers using one half of our /19, the only reason I shall need more in the next couple of years is if we sell lots of large leased line setups, that all need their own IP space. Regards, Geoff Campbell Technical Director Global Internet Ltd.

1 0

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

29 Jan '96

| 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.... Moral high ground does not interest me. Working networks interest me. I have to carry the ^1239_ routes internally anyway to get my customers able to talk to each other. I don't need to carry your routes at all, unless one of my customers wants to talk to you. It's a simple thing, elegantly described by Jeff Young earlier today. It was also elegantly described by Yakov Rekhter in his CIDRD presentation of the concepts of Push and Pull. Ordinarily I would answer "filter away; we've been prepared for this kind of filter being applied against us since day #1 (although admittedly it's not going to be too pretty if someone wants to talk to you and suddenly can't. been there, done that)". As a mechanism for motivating our customers to aggregate better than they could, an important provider doing a similar sort of inbound filtering likely would be much more widely effective than the occasional Seanogram to various customers warning of doom and the possibilities of being filtered, which sometimes seem to be completely ignored. This filtering is analagous to how ANS is able to get people to register their prefixes in the RADB or run into inbound announcement filters that will stop you from talking with AOL and other ANS customers. As you note, AS 4000 is run by a different company, and you shouldn't punish them just because I'm an arrogant asshole, as I have no control over or involvement with their routing strategies. (I'm not even sure that I'm entirely popular over there. ;-) ) However, yes, they are not aggregating as well as they could be, and are announcing more-specific-routes that are completely subsumed by aggregates. Some of those folks are here and should feel free to speak for themselves. Hi guys! :) Sean. | 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 ?

2 1