Re: Policy Statement on Address Space Allocations
From: "Joel M Snyder, writing fool" <Joel_M_Snyder@opus1.com> The company wishes to have more than one connection to the Internet through more than one of the major providers From: lodge@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.
Oh, good, the multi-homing discussion again.
(The loud "bang" you just heard was Noel blowing out his brains in sheer desperation and frustration.)
You're misinterpreting my question. The fault must be mine; I guess that my query wasn't specific enough. Let me put it another way: 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). jms Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Phone: +1 520 324 0494 (voice) +1 520 324 0495 (FAX) jms@Opus1.COM http://www.opus1.com/jms Opus One PLEASE NOTE: The useful parts of Arizona changed from area code 602 to area code 520 on March 20, 1995.
In message <9601291837.AA01730@ginger.lcs.mit.edu>, Noel Chiappa writes:
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
Noel, You may not have to wait as long as you think. The slides below were presented at the most recent RPS WG meeting: ftp://ftp.ans.net/pub/papers/slides/rps/aggregation.ps ftp://ftp.ans.net/pub/papers/slides/rps/aggr-methods.ps 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. I'm not sure the slides are entirely self explanitory, but I think they convey the general idea. This work is progressing. Gradually, but it is progressing. ANS should have working code to do this deployed by next IETF. 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. Curtis
participants (3)
-
Curtis Villamizar -
jnc＠ginger.lcs.mit.edu -
Joel M Snyder, writing fool