From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 00:50:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00689; Fri, 1 Sep 1995 00:50:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA24108; Fri, 1 Sep 1995 00:47:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA24071; Fri, 1 Sep 1995 00:28:38 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29808; Fri, 1 Sep 1995 00:28:36 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.31] (dial-cup2-1.iway.aimnet.com [204.118.88.31]) by aimnet.com (8.6.12/8.6.12) with SMTP id HAA17626; Thu, 31 Aug 1995 07:27:36 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Aug 1995 07:28:32 -0700 To: Tony Li From: Dave Crocker Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk At 2:07 AM 8/31/95, Tony Li wrote: > However, that's not what customers want to do. They want redundant > independent connectivity over large areas. > >I've seen no data to support this claim. In fact, given the economics a number of folks from small providers sent notes about this explicitly. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 01:50:36 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03398; Fri, 1 Sep 1995 01:50:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA24183; Fri, 1 Sep 1995 01:47:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA24168; Fri, 1 Sep 1995 01:36:18 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02667; Fri, 1 Sep 1995 01:36:10 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzfek22659; Thu, 31 Aug 1995 11:35:44 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: Multihoming To: tli@cisco.com (Tony Li) Date: Thu, 31 Aug 1995 11:35:44 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199508310907.CAA26469@greatdane.cisco.com> from "Tony Li" at Aug 31, 95 02:07:21 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1767 Precedence: bulk > However, that's not what customers want to do. They want redundant > independent connectivity over large areas. > I've seen no data to support this claim. > > Also, please note that this discussion has assumed that multihoming is > a significant problem, which is yet to be shown. As of the original > CIDR draft, we were seeing approximately 10% of the sites as > multihomed. As the user community changes, this appears to be > dropping, which is only reasonable as more and more sites are > individual users. My data supports this - not very many sites are multihomed. In fact, in the original data that I did, I forgot all of our dialup customers (oops). When I include them, here is what I get: 0.9% of non-ISP customers are doing active routing 2% of all customers are doing active routing 4% of non-ISP leased line customers are doing active routing 8% of all leased line customers are doing active routing 33% of ISP customers are doing active routing At 2% of all customers doing active routing and 820 active ASs (today) in the internet, this is a still a low 40K sites in the Internet. I think that our customer base is still atypical & does more multihoming than the 'average' customer - since there are certainly more than just 40K sites in the Internet. I think that we can afford having the routes for all multihomed sites being seen globally, so long at routes for singly homed sites are mostly not seen - so long at they are mostly aggregated. If we can split this discussion into two parts - one dealing with multihomed sites (all ISPs and the (today) less than 1% of all of other sites), and one dealing with singly homed sites (everybody else), I think that we may make more progress. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 03:32:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07507; Fri, 1 Sep 1995 03:32:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA24327; Fri, 1 Sep 1995 03:27:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA24312; Fri, 1 Sep 1995 03:13:46 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06823; Fri, 1 Sep 1995 03:13:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08603; Thu, 31 Aug 95 13:12:53 -0400 Date: Thu, 31 Aug 95 13:12:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508311712.AA08603@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Non-congruent AAB's Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: jnc@ginger.lcs.mit.edu (Noel Chiappa) use of N-C AAB's requires longest-match routing table lookups, not first-match, but we already have this. Also, longest-match is one way of dealing with partitions (i.e. A.1 comes unglued from the rest of A.*, and you have B between A.1 and the rest of A.*), not that it's necessarily the best way, or that you should have partitions happening in a reasonably well engineered network. Also, of course, using this to repair partitions may need some dynamic adjustment of the AAB for A, not a trivial task. Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 03:50:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08317; Fri, 1 Sep 1995 03:50:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA24364; Fri, 1 Sep 1995 03:47:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA24345; Fri, 1 Sep 1995 03:37:32 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07829; Fri, 1 Sep 1995 03:37:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08513; Thu, 31 Aug 95 13:06:48 -0400 Date: Thu, 31 Aug 95 13:06:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508311706.AA08513@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz > You need ... the new style routing more or less up, which means most > "core" routers need to be participating in the new-style routing. That's also easy - all it means is adding some number of new routes to the routing table Hmm, that sounds like what I said in a (later but parallel?) message: I suppose you keep the oldstyle one fully operational, in parallel, until you got the new one to the point where you can reduce the old one to stubs. Then you just make the switch [and turn off the old one most places]. I have to go away and think about this; it sounds technically vaguely plausible, but there are some things I don't see yet, and some more things I worry about. For the first, since you don't have a "flag day" to turn off the old one, how do you decide which destinations to encapulsate for, and which ones not to (since you have the old and new systems running in parallel, you can send packets over either one to a given destination)? Hmm, I guess that you have to do a complicated hop-step, where you run the destination address through your mapping table, and look to see if you have a route to the mapped address. If so, it can be reached through the "new-style" core, and you can go either way, might as well default to new. If not, you can't yet reach it through the new-style core, and you have to send it over the old one. I guess this would also be the way to figure out when the "turn off date" is, as well as get you info on what you need to do to get there. For all destinations advertised in the old-style routing, try and run a mapping; if you don't have one, need to update the mapping. Then, see if you have a route to the new one. If not, need to convert them to new-style, or make them into a stub. When you get a clean sweep, start turning off the old routing, which should not be in use any more. The thing that makes me nervous here with this "parallel" strategy, unlike the "translate" strategy, is that until you get the new-style core up and running completely, you have to keep the entire old one running in parallel. (You don't have to with the "translate" one, since pieces of the topology that only run old-style can interoperate with the new one, which doesn't happen here, except as stubs.) That means you have to handle the current routing load (which we are all saying cannot be handled unless CIDRized) as well as a new one, in parallel. at any one point I'd think we'd probably need a couple of hundred to start. I don't see this. I don't see how you can get by with anything less than the more or less full new table before switching off the old, at least in "parallel" mode. Its also going to produce some rather less than optimal routing for a while, until the existing default free rouutes can be phased out. You mean, to the extent that pieces are converted to stubs since they aren't running new-style, transit paths through those stubs that used to exist will; go away? I can't reconcile this to your mention of "default-free", and don't see any other way to get less optimal routes than you already had. Perhaps you had some different vision of how things would operate in parallel? What is not required is for any particular number of routers to be enable to do the mapping and encapsulation, they can be turned on one by one, after the decapsulation is available, and the routing info for the interior addresses is available. The issue is not so much the decapsulation being available. (You can tell that automatically if a new-style route is available.) There's no reason not to have encapsulation enabled by default at all times. Doing anything *other* than an automatic check for whether or not you can decapsulate is going to be a nightmare configuration problem, to turn the encapsulation on. And if you've got an automatic system, why turn it off? Unless I misunrstood what you are saying again, I see no reason to ever have encapsulation disabled. Of course, this is all theoretical exploration, not relevant to our problems here, becuase we don't have time to do it. I'm only indulging because I think we'll need to pull the answers to this problem down off the shelf when we convert to a new routing architecture, and if I start thinking about the details now, they'll be there when I need them. Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 04:11:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09065; Fri, 1 Sep 1995 04:11:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA24401; Fri, 1 Sep 1995 04:07:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA24386; Fri, 1 Sep 1995 03:54:55 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08407; Fri, 1 Sep 1995 03:54:51 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id KAA14402; Thu, 31 Aug 1995 10:54:48 -0700 Date: Thu, 31 Aug 1995 10:54:48 -0700 From: Tony Li Message-Id: <199508311754.KAA14402@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Subject: Re: Multihoming Precedence: bulk > However, that's not what customers want to do. They want redundant > independent connectivity over large areas. > >I've seen no data to support this claim. In fact, given the economics a number of folks from small providers sent notes about this explicitly. Exact references, please? I've grep'ed through the entire discussion and re-read what appear to be relevant articles and find no such data. I confess that I certainly might have missed something. Pointers to mail source addresses and dates would be more than adequate. Tony From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 04:30:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10051; Fri, 1 Sep 1995 04:30:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA24459; Fri, 1 Sep 1995 04:27:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA24442; Fri, 1 Sep 1995 04:15:49 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09286; Fri, 1 Sep 1995 04:15:14 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08954; Thu, 31 Aug 95 14:14:56 -0400 Date: Thu, 31 Aug 95 14:14:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508311814.AA08954@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@brandenburg.com Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker > I think you've just made my point. Again this implies that somehow some magic was being otherwise suggested. Not at all. I'm just saying that not all the details had been worked though. one might observe that the transition for 'flat' netowrk assignments to the cidr scheme also requires support of flat network addresses until everyone conforms to cidr. This statment makes no technical sense at all. If you read it purely as written, a "flat" address is one that cannot be aggregated. Since there will always be non-aggregable addresses at the top level, then by definition there will always be support for them. If you read it as saying support for "longest match" will be dropped, again, there are no plans to do that, and for a number of technical reasons (which I have pointed out), including support for non-congruent AAB's, partition repair, etc that this capability will continue to exist. What this means, in short, is that CIDR is in some sense a superset of flat addressing, so there's no way to "drop" support for flat addresses. All we can do is stop using them as much. Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 04:33:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10135; Fri, 1 Sep 1995 04:33:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA24484; Fri, 1 Sep 1995 04:31:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA24415; Fri, 1 Sep 1995 04:09:38 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09049; Fri, 1 Sep 1995 04:09:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08859; Thu, 31 Aug 95 14:08:07 -0400 Date: Thu, 31 Aug 95 14:08:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508311808.AA08859@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@brandenburg.com Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker > Topology-based-addresses can do more or less anything geographic > addresses can do, with more flexibility. (I except metro-addressing, > since that contains a mapping step which gives it even more > flexibility.) More flexibility? From a sufficiently constrained technical view, perhaps. What on earth are you talking about? "Geographic addressing" is a proper subset of topology-based addressing, one in which the topology is constrained to make a given (static) addressing plan function over time. How something which is a proper subset of another can be less constrained than the superset is beyond me. More pain and difficulty to the population of Internet users? Definitely! In fact, from THEIR view, provider-dependent addressing results in considerably LESS flexibility. If you would stop using politically loaded terminology (which tries to enhance a point you're pushing), and think about the underlying technical fundamentals, using neutral and technically-based terminology that doesn't straight-jacket your vision, you would perhaps understand that there is more to topology-based addressing than provider-based addressing. Moreover, if you expand your thinking to include all of the possibilities of topology-based addressing, you would see that you can basically provide the capabilities of geographic addressing in parts of the topology, whilst not limiting other parts of the mesh. You might even understand that issues like multihoming are not less solvable in topology-based address schemes, and that the underlying cost/benefit tradeoffs are the same in each. As a matter of operational reality, the provider-dependent scheme doesn't provide flexibility for users or local providers, only for transit providers. As a matter of mathematical, not just operational, reality, any large-scale network is going to have to use topology-based addresses for its routing. Perhaps you should go and spend some time trying to think this through, and coming to a better understanding of the underlying fundamentals. Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 04:49:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10649; Fri, 1 Sep 1995 04:49:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA24518; Fri, 1 Sep 1995 04:47:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA24461; Fri, 1 Sep 1995 04:29:01 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09868; Fri, 1 Sep 1995 04:28:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09012; Thu, 31 Aug 95 14:28:32 -0400 Date: Thu, 31 Aug 95 14:28:32 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508311828.AA09012@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@brandenburg.com Subject: Re: IP Encapsulation Growth Proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker >> you might also then view this idea as architecturally clean > One thing I'd have though this whole debate would have taught people is > that archiectures which work fine at one order of scale don't always > work well when scaled up by several orders of magnitude. One could, as easily, argue that the scale of impact for imposed, large-scale renumbering is a scaling problem vastly worse than in creating and deploying the encapsulation engines. A global scheme always has issues of scaling. You appear to have completely missed my point, so let me make it clearer. The architecture (as opposed to the basic idea) of the model you want people to emulate, sending IP packets over LAN's, works because most LAN's are small. ARP, routing prtocols like OSPF, all assume a small number of machines on a net. The propose mapping backbone is not small. If we could simple scale up the LAN wrapping architecture to WAN scales, we wouldn't need ROLC, and all the protocols being designed three. > Unless you are using terminology in a non-standard way, this is > incorrect. To use the WAN example, it's not translating the next-hop IP > address to the WAN MAC address (i.e. address resolution) that's so hard, > it's picking the exit From the standpoint of architectural and algorithmic role, the view that the "lower layer" IP in the Encaps scheme is identical to a subnet or link layer is exactly and formally correct. If it's really identical, how come ROLC is having to design new protocols? This is all exactly like doing IP over x.25 rather than IP over IP. Last I looked, ROLC is still working on how to make this actually work in service on a large scale (i.e. not with a static translations, etc). The fact that this particular subnet or link layer has yet-another below it is irrelevant to this discussion Again, you seem to have completely misunderstood what is going on. I never said it was, and where on earth you got the impression I did think anything like that is beyond me. Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 05:28:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12129; Fri, 1 Sep 1995 05:28:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA24607; Fri, 1 Sep 1995 05:27:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA24588; Fri, 1 Sep 1995 05:20:12 +1000 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11649; Fri, 1 Sep 1995 05:20:06 +1000 (from swb1@cornell.edu) Received: from [132.236.199.117] (SWB.CIT.CORNELL.EDU [132.236.199.117]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id IAA21718; Thu, 31 Aug 1995 08:45:08 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Aug 1995 08:45:30 -0400 To: Dave Crocker From: Scott W Brim Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk At 21:26 08/30/95, Dave Crocker wrote: > Scott, I think your comments were quite well formulated and stated. >I suggest, however, that they seem to be on the wrong list. Given that >your note pertains to the use of cidr, I would think that it should be >discussed within the working group responsible for considering cidr >deployment. It doesn't make sense to get better at deploying something >that simply shouldn't be deployed. ok, I'll say something brief over there. ...Scott From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 05:47:52 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12891; Fri, 1 Sep 1995 05:47:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01275 Fri, 1 Sep 1995 05:12:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA24557; Fri, 1 Sep 1995 05:07:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA24532; Fri, 1 Sep 1995 04:50:11 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10656; Fri, 1 Sep 1995 04:50:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09107; Thu, 31 Aug 95 14:50:06 -0400 Date: Thu, 31 Aug 95 14:50:06 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9508311850.AA09107@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, narten@vnet.ibm.com Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Thomas Narten" > Seriously, I often wonder if the debate here is having any useful effect. What I think would be a *lot* more helpful is to put together a single summary of the issues, the possible approaches, and the pros and cons of the various approaches, and finally (and most important!), comparing the relative tradeoffs of the various approaches. You're talking about a 40+ page document, and one, moreover, that assumes background knowledge of fundamentals of routing that will take about 40+ pages of background knowledge. (I can be pretty sure of that, since I'm in the process of putting together a "Fundamentals of Routing and Addressing In Extremely Large Networks" and it's already over 20 pages of single-spaced text, and I've barely gotten going.) BTW, there is plenty of available background material in the technical literature (perhaps not as RFC's, but knowledge doesn't exist unless it's in RFC form)? If people want to read up on this stuff, it's not that the material is not there. Some of the more advanced concepts (like AAB's) aren't written down yet, but those are easy enough to understand once you have a solid background. Why haven't people read this stuff? Based on this, I do wonder if everyone who wants to participate will i) have the patience to read these documents, and ii) will really understand them. Anyway, once you've read and absorbed the second one, it's intuitively obvious that there really isn't any such document as the first one; the so-called "various approaches" are not really that different. It's like trying to chose between the wave and particle model for quantum mechanics: it's a non-question. It would also help if common terminology was used. Too much of the discussion seems to result from different interpretations of what terms like "heirarchical addressing", "provider-based addressing" ... etc. mean. Well, people being more precise with terminology would help, but I'd say that an equally big problem is that too many people haven't thought about things enough. E.g. there seems to be a persistent beliefd that hierarcial addressing implies hierarchical routing, and that's absolutely wrong. But some folks are clearly already spending a lot of time posting messages. If that effort could be rechanneled... Sure. I was busy working on papers when some people woke up to the clear implications of what had been decided several years ago, and started an agitation to derail the only solution we have in train for a severe problem. Once we all understand that we have to go on, I can stop reading mail full time and go back to writing. Just *exactly* *what* is the immediate "CIDR problem"? ... Ooops, sorry. The *real* problem is that CIDR now (or was it always??) requires renumbering. Hmm. Does this requirement come from *CIDR* or is it *really* a result of the need to limit the number of routing table entries ... I'll bet if the question were asked, you'd get ten different answers plus a fair amount of head scratching. No, there is one set of right answers, plus a set of confused ones stemming from insufficient understanding. Without a clear understanding of the problem, it's hard to come up with solutions. Indeed. That's why I get frustrated that people don't take more advantage of the vast bulk of technical literature on the subject that's *already* available. Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 08:07:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17474; Fri, 1 Sep 1995 08:07:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA24750; Fri, 1 Sep 1995 08:07:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA24735; Fri, 1 Sep 1995 07:52:39 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16767; Fri, 1 Sep 1995 07:52:28 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id RAA00566; Thu, 31 Aug 1995 17:54:06 -0400 Date: Thu, 31 Aug 1995 17:54:05 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Multihoming To: Tony Li Cc: big-internet@munnari.OZ.AU In-Reply-To: <199508311754.KAA14402@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk well, I have a couple of universities that want this. partly to supplement the provided free (slow unreliable) access they have, with a second source, partly just to be redundant and never off line. Sorry, no specifics on that one like email addresses. Businesses want this too, and there is one specialized outsourcer out there who deals just in that: providing disaster recovery solutions. One is to have a fully redundant link to 'the' internet. Mike On Thu, 31 Aug 1995, Tony Li wrote: > > > However, that's not what customers want to do. They want redundant > > independent connectivity over large areas. > > > >I've seen no data to support this claim. In fact, given the economics > > a number of folks from small providers sent notes about this explicitly. > > Exact references, please? I've grep'ed through the entire discussion > and re-read what appear to be relevant articles and find no such data. > I confess that I certainly might have missed something. Pointers to > mail source addresses and dates would be more than adequate. > > Tony > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 08:48:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19363; Fri, 1 Sep 1995 08:48:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA24813; Fri, 1 Sep 1995 08:47:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA24795; Fri, 1 Sep 1995 08:39:52 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18997; Fri, 1 Sep 1995 08:39:46 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.44] (dial-cup2-21.iway.aimnet.com [204.118.88.51]) by aimnet.com (8.6.12/8.6.12) with SMTP id PAA05416; Thu, 31 Aug 1995 15:38:30 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Aug 1995 15:39:29 -0700 To: Tony Li From: Dave Crocker Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk At 10:54 AM 8/31/95, Tony Li wrote: >Exact references, please? I've grep'ed through the entire discussion >and re-read what appear to be relevant articles and find no such data. >I confess that I certainly might have missed something. Pointers to >mail source addresses and dates would be more than adequate. Well, tony, since the discussion has been nicely fragmented among about 4 lists, I suggest you check cidrd, big-internet, iap and inet-access. Thought some of the submissions were on cidrd, but that was probably out of scope. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 08:49:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19390; Fri, 1 Sep 1995 08:49:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA24837; Fri, 1 Sep 1995 08:48:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA24809; Fri, 1 Sep 1995 08:42:16 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19113; Fri, 1 Sep 1995 08:42:14 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05636 Fri, 1 Sep 1995 08:42:10 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.44] (dial-cup2-21.iway.aimnet.com [204.118.88.51]) by aimnet.com (8.6.12/8.6.12) with SMTP id PAA05580; Thu, 31 Aug 1995 15:39:48 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Aug 1995 15:40:49 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk Noel, I'll try to respond to the series of notes you've sent taking exception both to my analysis and tone. On the matter of analysis, I'll offer my own request that YOUR tone be just a tad less parental. It well may be that I'm not right, but then it well may be that I am. Please allow some room for the latter. On tone, I admit to some sustained concern on this topic, since it appears that reasoned debate about the efficacy of the path being pursued has not only been lacking but discouraged. At any rate in the style of "I didn't do it and promise never to do it again" I'll comment that the language you seem to have taken exception to does not, by my reading, reflect any particular tone. At base -- and heaven knows this has all gotten pretty base -- I'd guess that the difficulty in finding some overlap in our views is that you are talking mathematically and I am talking operationally. At 11:08 AM 8/31/95, Noel Chiappa wrote: >What on earth are you talking about? "Geographic addressing" is a proper >subset of topology-based addressing, one in which the topology is constrained This means that you can make it behave in ways that geographic won't permit. That is flexibility in the model, but it is restriction in terms of end-user effects. If you make it behave as not geographic but strictly provider-dependent, AS IT HAS MOSTLY BEEN ADMINISTERED SO FAR, then the effect on customers of this service very much RESTRICTS their legitimate choices. The cost of changing providers is dramatically higher. That sounds like LESS flexibility in terms of THEIR operational choices. > More pain and difficulty to the population of Internet users? > Definitely! In fact, from THEIR view, provider-dependent addressing > results in considerably LESS flexibility. >If you would stop using politically loaded terminology (which tries to enhance >a point you're pushing), and think about the underlying technical fundamentals, Well, heaven forbid that I should try to enhance a point I'm pushing. Heaven forbid any of us from doing THAT... Why, we might even end up stooping into an attack on each other's style and we can't have THAT? By the way, Noel, I don't see what in my earlier statement as particularly political or loaded. I'm asserting that the current -- not theoretical, current -- scheme has a simple and direct effect of greatly limiting operational (and therefore business) choices for local providers. >Moreover, if you expand your thinking to include all of the possibilities of >topology-based addressing, you would see that you can basically provide the ahh, but this is not a mental exercise, Noel. the perfectness of the idea isn't the issue, only the real application to the operational internet. >As a matter of mathematical, not just operational, reality, any large-scale no. let's keep it at "just" operational. it might actually end up being practical that way. >Perhaps you should go and spend some time trying to think this through, and I suppose I could offer some suggestions for you, too, but I might end up using politically loaded terminology. kissy. kissy. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 09:28:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21066; Fri, 1 Sep 1995 09:28:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA24923; Fri, 1 Sep 1995 09:27:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA24872; Fri, 1 Sep 1995 09:09:38 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20159; Fri, 1 Sep 1995 09:09:31 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id QAA05511; Thu, 31 Aug 1995 16:16:36 -0700 Date: Thu, 31 Aug 1995 16:16:33 -0700 (PDT) From: Michael Dillon To: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft (fwd) Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk I am told that this list is where people are discussing CIDR and multi-homing issues so I am forwarding this message and another one to this list. ---------- Forwarded message ---------- Date: Wed, 23 Aug 1995 16:46:11 -0700 (PDT) From: Michael Dillon To: Small Internet Access Providers Cc: cidrd@iepg.org Subject: Re: ownership, leasing, renumbering, and that draft On Wed, 23 Aug 1995, Dave Crocker wrote: > >To: Robert Elz > >cc: curtis@ans.net, cidrd@iepg.org > >Subject: Re: ownership, leasing, renumbering, and that draft > >Date: Wed, 23 Aug 1995 15:31:46 -0400 > >From: Curtis Villamizar > > > >I completely disagree that small providers are going to be dual homing > >in droves. I know of no evidence of any trend in this direction. > > Any small providers out there care to comment? I haven't any statistical evidence but on the several mailing lists inhabited by ISP's the topic of multihoming does come up regularly. Sometimes it is an ISP who mentions that they are multihomed in the course of discussing connectivity and sometimes it is an ISP who mentions that multihoming is in their plans once they can afford their second T1 connection. I personally feel that the only reason small ISP's aren't multihoming in droves yet is that many of them are still running with a single T1 connection. I think many of them do want to become multihomed but I don't think many of them understand much about running BGP. I think that the Internet community could benefit from some sort of tutorial material about how to properly transition from single-homed to multihomed running BGP. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 09:29:29 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21136; Fri, 1 Sep 1995 09:29:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA24945; Fri, 1 Sep 1995 09:29:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA24886; Fri, 1 Sep 1995 09:10:47 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20184; Fri, 1 Sep 1995 09:10:32 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id QAA05520; Thu, 31 Aug 1995 16:17:39 -0700 Date: Thu, 31 Aug 1995 16:17:36 -0700 (PDT) From: Michael Dillon To: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft (fwd) Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk A second message regarding multihoming based on my experiences on three different ISP mailing lists ---------- Forwarded message ---------- Date: Thu, 24 Aug 1995 00:38:52 -0700 (PDT) From: Michael Dillon To: Small Internet Access Providers Subject: Re: ownership, leasing, renumbering, and that draft On Wed, 23 Aug 1995, Dave Crocker wrote: > At 7:44 PM 8/23/95, Nathan Stratton wrote: > >sure, I have frac T into sprint, will have a full T into mci by the end > >of the month and a 10 meg into MAE by the end of teh month. > > don't know if any of you are interested, but the prevailing > sentiment on the cidrd mailing list seems to be that this sort of > connectivity is -- and will remain -- rare enough to be insignificant for > planning efforts. My own interpretation of cidr is that it will not > sustain heavy occurrence of this kind of multi-homing. > > To the extent that you wish to discuss this, you really SHOULD join > the cidrd mailing list (send to majordomo@iepg.org and subscribe cidrd in > the body) and offer your OWN perspective on the need for comfortable > support of large-scale multi-homing. This is a *DARN* good idea. My earlier post about the need for tutorial material to assist in the transition managed to elicit a smart-ass comment from one of the people who is a major Internet personality involved in CIDR and BGP issues. Judging by that comment, this person thinks the matter is trivial, yet the feeling I get is that every ISP out there, including mom-and-pop operations, has multi-homing as a goal. Personally, I expect that every community in North America with a population over 20,000 will have multihomed providers by the end of 1997. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 09:48:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21929; Fri, 1 Sep 1995 09:48:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA24982; Fri, 1 Sep 1995 09:47:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA24941; Fri, 1 Sep 1995 09:29:08 +1000 Received: from diablo.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21107; Fri, 1 Sep 1995 09:28:49 +1000 (from doleary@cisco.com) Received: (doleary@localhost) by diablo.cisco.com (8.6.10/CISCO.SERVER.1.1) id QAA27567; Thu, 31 Aug 1995 16:27:57 -0700 Date: Thu, 31 Aug 1995 16:27:57 -0700 From: "Dave O'Leary" Message-Id: <199508312327.QAA27567@diablo.cisco.com> To: big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu, inet-access@earth.com Subject: Re: casting your multi-homing/provider-changing vote Precedence: bulk Some comments are interspersed below. > To: Multiple recipients of list IAP > Date: Thu, 31 Aug 1995 15:39:58 -0700 > From: Dave Crocker > Subject: casting your multi-homing/provider-changing vote > > Folks, > > You may recall that a week or so ago I raised a concern about the > possibility of local providers effectively being prevented from doing > multi-homing and being put out of business by the side-effect of changing > providers and having to change IP network numbers (and the numbers of all > their customers.) This concern comes from the design of the cidr scheme > for IP network address assignment. I believe that this mis-characterizes the situation. I do not believe that deployment of CIDR as is being proposed "effectively prevents local providers from multi-homing," or even prevents anyone from changing providers without renumbering. The document in question has been/is being modified to address these issues (I believe, I haven't re-read the current one for a good 2 or 3 days now... :-). Specifically, I believe that there will be a cost to multihoming, above that of simply getting another connection from the second provider. The addition costs will cover the engineering of routing for non-local prefix, carrying the additional prefix, and engineering the BGP connection to provide routing info, etc. These costs might be incurred with both the original provider and the secondary provider. However, the document is simply describing Best Current Practice. It has no authority to force anyone to do anything, including accepting or refusing customer routes, forcing renumbering, etc. The backbone providers will presumably engineer their networks to keep their existing customers happy (through providing reachability at acceptable performance levels to as much of the Internet as possible), just as local providers try to provide performance and reachability to as much of the rest of the Internet as possible. The BCP is pointing out the existence of a tradeoff (connectivity vs. incurring costs, renumbering vs. cost avoidance) that some users and providers may face in the future as the Internet continues to grow. These are the same kinds of business/technical tradeoffs that most of the people who are running local ISPs have to make every day anyway. If you have questions about the BCP and its implications, you can ask technical questions on the CIDRD and big-internet lists, but business issues should be addressed with your upstream provider(s). Please note that these utterings are simply the perspective I see in my personal crystal ball, and I am *not* speaking for cisco systems, as we do not tell our customers how to run their businesses or how to price their services. > Some of you responded, expressing a desire or need to do > multi-homing. The chair of the cidr deployment working group, Tony Li, > moved the discussion of the efficacy of cidr off of the cidrd list and onto > the big-internet list. He says that he has seen none of the messages that > were in support of the need for multi-homing. > > You might want to subscribe to big-interest-request@munnari.OZ.AU > and send (or re-send) your comments to the list. (I'll assume that you can > figure out what address to send the actuall messages to...) > > Honest, folks. If you care about being able to change transit > providers and/or you care about being able to do multi-homing comfortably, > it's important that you say so. The current claim is that there's not > enough interest in this to worry about... > > d/ I believe the current assumption is that the number of multihomed cases will be small enough that they can be handled by the current architecture, given adequate renumbering of the numerous small, singly homed sites which are currently addressed with prefixes that do not roll up well into the existing address hierarchy. If some readdressing occurs, then thousands of multihomed entities can exist in the Internet without a problem. > -------------------- > Dave Crocker +1 408 246 8253 > Brandenburg Consulting fax: +1 408 249 6205 > 675 Spruce Dr. page: +1 408 581 1174 > Sunnyvale, CA 94086 USA dcrocker@brandenburg.com Thanks, dave o'leary cisco systems From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 10:33:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23931; Fri, 1 Sep 1995 10:33:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA25040; Fri, 1 Sep 1995 10:27:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA25025; Fri, 1 Sep 1995 10:11:22 +1000 Received: from ACADEM.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22879; Fri, 1 Sep 1995 10:10:59 +1000 (from sob@academ.com) Received: (from sob@localhost) by academ.com (8.6.12/8.6.9) id TAA13326; Thu, 31 Aug 1995 19:10:44 -0500 Message-Id: <199509010010.TAA13326@academ.com> From: sob@academ.com (Stan Barber) Date: Thu, 31 Aug 1995 19:10:44 CDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Michael Dillon , big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft (fwd) Precedence: bulk Michael Dillon recently said: > Personally, I expect that every community in North America with a > population over 20,000 will have multihomed providers by the end of 1997. This is already true, if you include that every community in America can get to multi-homed providers via 800 service today. I assume you really mean to say "locally operated multi-homed providers" or something like that. Please clarify. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 10:47:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24676; Fri, 1 Sep 1995 10:47:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA25077; Fri, 1 Sep 1995 10:47:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA25073; Fri, 1 Sep 1995 10:42:08 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24335; Fri, 1 Sep 1995 10:41:49 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id RAA06393; Thu, 31 Aug 1995 17:48:50 -0700 Date: Thu, 31 Aug 1995 17:48:49 -0700 (PDT) From: Michael Dillon To: Stan Barber Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft (fwd) In-Reply-To: <199509010010.TAA13326@academ.com> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 31 Aug 1995, Stan Barber wrote: > Michael Dillon recently said: > > Personally, I expect that every community in North America with a > > population over 20,000 will have multihomed providers by the end of 1997. > > This is already true, if you include that every community in America can > get to multi-homed providers via 800 service today. > > I assume you really mean to say "locally operated multi-homed providers" > or something like that. Please clarify. You are correct. I mean that there are LOTS of small locally operated ISP's springing up and they all want to be multihomed for the redundancy and backup that they can gain. In addition, large organizations like universities, 4-year colleges, business running important WWW sites all want to be multi-homed. It's only a matter of time and the economic justification comes as soon as the ISP or organization can make a case for buying their second T1 line. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 11:36:08 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26693; Fri, 1 Sep 1995 11:36:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12181 Fri, 1 Sep 1995 11:33:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA25161; Fri, 1 Sep 1995 11:27:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA25122; Fri, 1 Sep 1995 11:16:24 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25779; Fri, 1 Sep 1995 11:16:01 +1000 (from sob@academ.com) Received: from ACADEM.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA11574 Fri, 1 Sep 1995 11:15:37 +1000 (from sob@academ.com) Received: (from sob@localhost) by academ.com (8.6.12/8.6.9) id UAA13607; Thu, 31 Aug 1995 20:12:22 -0500 Message-Id: <199509010112.UAA13607@academ.com> From: sob@academ.com (Stan Barber) Date: Thu, 31 Aug 1995 20:12:22 CDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Michael Dillon Subject: Re: ownership, leasing, renumbering, and that draft (fwd) Cc: big-internet@munnari.OZ.AU Precedence: bulk > On Thu, 31 Aug 1995, Stan Barber wrote: > > > Michael Dillon recently said: > > > Personally, I expect that every community in North America with a > > > population over 20,000 will have multihomed providers by the end of 1997. > > > > This is already true, if you include that every community in America can > > get to multi-homed providers via 800 service today. > > > > I assume you really mean to say "locally operated multi-homed providers" > > or something like that. Please clarify. > > You are correct. I mean that there are LOTS of small locally operated > ISP's springing up and they all want to be multihomed for the redundancy > and backup that they can gain. I am currently polling the providers based in Houston for this kind of info and will report my findings back the list. I don't yet know how many are planning to be multi-homed in the time frame you mention. Today, there are 33 Houston-based providers that I know about. Of those, only one might be considered multi-homed. I have been told that one other is, but have not been able to confirm that from actual routing information available in the Internet. I also know that another is currently re-engineering their infrastructure to make multi-homing possible, but it is unclear if they will choose to actually multi-home. That leaves 30 that are not currently multi-homed. Now, Houston may not be representative of the rest of the country, but it does make an interesting data point. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 11:50:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27312; Fri, 1 Sep 1995 11:50:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA25241; Fri, 1 Sep 1995 11:47:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA25185; Fri, 1 Sep 1995 11:37:51 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26694; Fri, 1 Sep 1995 11:36:09 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12146 Fri, 1 Sep 1995 11:32:36 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09992; Thu, 31 Aug 95 21:29:43 -0400 Date: Thu, 31 Aug 95 21:29:43 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509010129.AA09992@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Dave Crocker > "Geographic addressing" is a proper subset of topology-based addressing, > one in which the topology is constrained This means that you can make it behave in ways that geographic won't permit. Right. It also means you can make topology-based emulate geographic. That is flexibility in the model, but it is restriction in terms of end-user effects. If you make it behave as not geographic but strictly provider-dependent ... then the effect on customers of this service very much RESTRICTS their legitimate choices. The cost of changing providers is dramatically higher. That sounds like LESS flexibility in terms of THEIR operational choices. The thing that I keep trying to make plain is that the other alternatives do not have zero cost to the system as a whole; i.e. saying "changing providers is expensive this way, so it's not the right choice" does not fully take into account the true costs of the other alternatives. Everyone admits that provider-based addresses for singly-homed customers have a painful cost, i.e. customer renumbering. On the other hand, the old "flat-addressed" model is just not viable, for reasons I hope everyone grasps by now. We can explore other alternatives, such as "exchange-point based addressing", which is also "topology-based addressing", but very different in flavor from "provider-based". However, the old way of doing this is gone for good, and everyone has to understand that. Well, heaven forbid that I should try to enhance a point I'm pushing. Heaven forbid any of us from doing THAT... What I object to is that in using that terminology, you're i) not starting from the technology, but rather policy, and mathematics beats politics every day of the week, and ii) more importantly, it is likely to cause people to not understand that there are many other options which are all "topolology-based addressing" which are not plain, vanilla, "provider-based". I'm asserting that the current -- not theoretical, current -- scheme has a simple and direct effect of greatly limiting operational (and therefore business) choices for local providers. If you're talking about multihoming, that statement is incorrect for technical reasons, and I will be sending an analysis of multihoming in shortly which explains why, in reply to Scott Brim's message. this is not a mental exercise, Noel. the perfectness of the idea isn't the issue, only the real application to the operational internet. Who's talking about "perfectness"? I just want us to consider options which are not stated so as to contain demonstrably incorrect assertions. > As a matter of mathematical, not just operational, reality, any > large-scale network is going to have to use topology-based addresses for > its routing. no. let's keep it at "just" operational. it might actually end up being practical that way. OK, Dave, you go work on a 1000-mile-per gallon carburetor. The rest of us will do a little quick mathematics and decide the energy content of the chemical bonds in gasoline isn't high enough to ever reach that point (at least, for the energy consumption of the contemporary car technology in the applicable areas like drag, tire friction, etc). Ooops, sorry, I guess we're being mathematical, not practical. Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 11:54:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27489; Fri, 1 Sep 1995 11:54:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA25266; Fri, 1 Sep 1995 11:52:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA25183; Fri, 1 Sep 1995 11:37:46 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26742; Fri, 1 Sep 1995 11:37:17 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.49] (dial-cup2-19.iway.aimnet.com [204.118.88.49]) by aimnet.com (8.6.12/8.6.12) with SMTP id SAA23176; Thu, 31 Aug 1995 18:33:34 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Aug 1995 18:34:33 -0700 To: "Dave O'Leary" From: Dave Crocker Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu, inet-access@earth.com Precedence: bulk The detailed response... At 4:27 PM 8/31/95, Dave O'Leary wrote: >I believe that this mis-characterizes the situation. I do not believe >that deployment of CIDR as is being proposed "effectively prevents >local providers from multi-homing," or even prevents anyone from Network numbers are assigned by providers. Local providers will get their CIDR block from their transit providers. End-users from their attachment providers. Numbers & blocks will be 'leased', that is the assignment is not permanent. If you change your up-link attachment, you will need to return your block and get a new one from your new provider. This necessitates renumbering. For local providers, it necessiates renumbering by all your subscribers. Multi-homing support is provided by taking the network number within one provider's block and advertising out another provider's link. As such it does not fit within their CIDR block. Hence, each advertisement of a multi-homed net which goes out additional links is an exception in the routing table. Any large-scale use of this mechanism completely defeats the purpose of CIDR. It allows no aggregation. The other handling for multi-homing is if a provider is large enough to get their own, top-level CIDR block. Clearly there had better not be very many of these or there will be a large, flat, global table which is what CIDR is supposed to eliminate. Now I believe the above summarizes the details that have recently been discussed. If there are others that are showing up in the next draft of the leasing proposal, it would be helpful to hear of them. I think it not at all complicated to predict from the above that multi-homing had better not occur on a large scale and that local providers will have very, very strong disincentives from changing transit providers. It is, in fact, not clear to me that a local provider will be able to change even once. >provider. The addition costs will cover the engineering of routing >for non-local prefix, carrying the additional prefix, and engineering How will those costs cover turning the global routing table into a flat address space, if there is wide-spread multi-homing? If that WON'T be the effect, please explain how. >However, the document is simply describing Best Current Practice. It >has no authority to force anyone to do anything, including accepting Either the imprimatur of the IETF is useful or it isn't. A BCP is an official IETF document. If the BCP has so little meaning, why bother to seek the label? >of the rest of the Internet as possible. The BCP is pointing out the >existence of a tradeoff (connectivity vs. incurring costs, renumbering >vs. cost avoidance) that some users and providers may face in the The leasing proposal does not, in my opinion, come close to discussing tradeoffs. It pushes one point of view and substantially ignores the downsides of that view, as I described in my -myth- I-D comments. >local ISPs have to make every day anyway. If you have questions about >the BCP and its implications, you can ask technical questions on the >CIDRD and big-internet lists, but business issues should be addressed questions and criticisms of CIDR have been ruled out of order for the CIDR mailing list. >I believe the current assumption is that the number of multi-homed >cases will be small enough that they can be handled by the current how small is small enough? at what point will it be too many? At the moment there appears to be both a denial of much need and a lack of solid boundary statements so there is no way to know whether the current scheme will suffice at all, other than to state that multi-homing causes CIDR to propagate exception entries globally. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 12:31:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29677; Fri, 1 Sep 1995 12:31:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA25417; Fri, 1 Sep 1995 12:28:33 +1000 Received: by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA25394; Fri, 1 Sep 1995 12:26:27 +1000 Received: from [204.118.88.49] (dial-cup2-19.iway.aimnet.com [204.118.88.49]) by aimnet.com (8.6.12/8.6.12) with SMTP id SAA23112; Thu, 31 Aug 1995 18:33:04 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 31 Aug 1995 18:34:03 -0700 To: "Dave O'Leary" From: Dave Crocker Subject: Do you need multi-homing? (was: casting your...vote) Cc: big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu, inet-access@earth.com Precedence: bulk At 4:27 PM 8/31/95, Dave O'Leary wrote: >I believe that this mis-characterizes the situation. I do not believe > You might want to subscribe to big-interest-request@munnari.OZ.AU > and send (or re-send) your comments to the list. (I'll assume that you can >> Honest, folks. If you care about being able to change transit >> providers and/or you care about being able to do multi-homing comfortably, Let's keep the current issue brief and focussed: The chair of the cidr working group claimed to have seen no evidence that providers expect to be multi-homed and there have been some statistics published indicating only a limited need for this. I am suggesting that now is a good time to voice your opinions and your intent, so that there is some clear and undeniable record of the need to support this connection mode adequately. We can debate the details of 'adequately' later. For now, the simple fact of the need is being denied. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 13:50:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03544; Fri, 1 Sep 1995 13:50:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA25543; Fri, 1 Sep 1995 13:47:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA25526; Fri, 1 Sep 1995 13:36:48 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02892; Fri, 1 Sep 1995 13:35:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10488; Thu, 31 Aug 95 23:33:12 -0400 Date: Thu, 31 Aug 95 23:33:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509010333.AA10488@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, swb1@cornell.edu Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Scott W Brim Multihoming is the appearance of a single (probably aggregated) entity at two different points in the address space I think you meant an entity which is connected at two different points in the network topology, don't you? (The way you put it, that's supporting multi- homing via multiple addresses, which is presumably not what you wanted.) In a hierarchical routing scheme the distance that two appearances need to be propagated separately by routing will depend on (1) how much of a prefix the two appearances have in common, and (2) whether you want to promote or suppress separate paths to the different appearances for other reasons. No, it has little to do with the prefix; it has to do with the operational characteristics you want. Let's go over this in detail. We'll look at a fairly general case, where some entity X is connected to two different providers, P1 and P2, which are both inside a higher-level aggregate A. The "providers" here are actually topological entities; i.e. they coudl be ISP's, or the could be interconnection points, or whatever. The analysis is the same for all. So, that entity can presumably have three potential addresses; A.X, A.P1.X, and A.P2.X. Since the latter are effectively identical, we'll refer to them both as A.P.X, and we'll use the term A.P? for A.P1 and A.P2 together. Now, let's look at what we have to do *inside* A if we wish to have traffic to anything inside X take whichever provider, P1 or P2, is the best way to get to X. To do that, we have to have routes to X flow widely through A, *no matter which form of address we use*. In fact, though, the A.X form will use *more* routing overhead to get equally good routes. This is easy to see. If we use A.X, then a routing table entry for this has to appear everywhere inside A, otherwise traffic for it will not know where to go. If, on the other hand, we use an address of the form A.P1.X, then there will be parts of A where the route to A.P1 and the route to A.P1.X are the same; these will be parts that are close to P1 and far from P2. So, there will be parts of A which do not need a separate entry for A.P1.X, i.e. lower routing overhead. (In technical terms, the AAB for A.P.X can be smaller than A, to produce the same routes as for the A.X form.) So, we see that if we wish optimal routing inside A, the A.P.X form (i.e. the "provider-based" form) actually can consume *less* routing overhead. Now, let's look at the case of inside A, but where we we are willing to accept less than optimal routing. This option does not exist for A.X; if no route exists in parts of A, traffic will simply not get there. However, we can define a AAB for A.P.X which is smaller than the one above, and thus consume less routing overhead, but which will still provide good routes to X from some parts of A. As a "low-end" examples of this, conside the case where we set an AAB for A.P1.X which is no larger than A.P? (i.e. outside of A.P1 and A.P2, A.P1.X is not visible as a separate destination). This will mean that traffic from everywhere else in A will get to X via P1, but traffic from sites inside P2 will use the secondary connection to X. This is not as good as what you get with A.X, of course, but it's an option that isn't even available with the A.X form. Again, if you want the same capabilities as what you get with A.X, A.P.X will give them to you with the same, or lower, routing overhead. Now, let's look at the other case; the routing *outside* A. A similar analysis applies. Here, the object is pick the entry point to A which is closest to X. The highest level of optimality in this choice is obtained by advertising X (in whatever form, be it A.X or A.P.X) directly over some scope outside A. However, the overhead cost of this is large, and, in any case, it is about the same for either case (modulo tweak below). So, let's move on to the next case. Here, we advertise only top-level elements of A outside A. So, we would advertise A.P?, and A.X as well (if we had it). However, it's not fair to compare the A.X form with the A.P.X form here, since to advertise A.X outside A takes *more* overhead than advertising just A.P?. The correct comparison (in terms of equal overhead) is the one above. Note, however, that if we are *already* advertising A.P? over some scope outside A, a similar effect to the one above *inside* A occurs outside. Assuming we are advertising X separately over some scope outside A, the A.X case takes more routing overhead, since it has to be advertised separately throughout the scope, whereas of the A.P.X form is used, though some part of the scope, this sill be subsumed by the appropriate A.P entry, at consequently lower overhead. Now, let's look at the case where we use an address of the form A.P1.X, and advertise only A.P? outside A. Again, this is a case which is *not possible* with the A.X form. There is some part of the network outside A for which the best path to X is through A.P1; traffic from here will take the best entry router anyway. However, for traffic which was best served by using X's connection to P2, it will wind up at a non-optimal entry router. Note, however, that there is zero extra routing overhead outside A to achieve these results. Finally, let's look at the case where nothing is advertised outside A. There are many subcases to this, too many for me to feel like listing them all, but suffice it to say that it makes no difference whether the A.X or A.P.X form is used; an entry router will be picked, the same one no matter which address is used, and the analysis thereafter is as for inside A, above. It now remains only to use these results to generalize to a few other cases, which should just about cover them all. For one, the providers and multihomed entity are not inside some lower-level entity (i.e. A), but rather at the top level. In this case, the analysis is exactly the same as for the "inside A" case, with the containing entity being U, the universal object. There is no "outside U" case, clearly. For another, if the multihoming is not down one level, but down several levels; e.g. A'.B.X and A'.B.P.X. For this case, the B.X and B.P.X cases are exactly the same as the "A" case above, and the superset case, A', uses much the same logic as the "outside A" case above. Finally, if the connection points are not at the same level in the hierarchy, e.g. A".B.P1 and A".C.P2. In this case, one can effectively elide the B and C elements (i.e. consider the B.P1 and C.P2 as atoms), and the analysis procedes as for the "inside A" case, with B and C taking the case of P1 and P2. Of course, the scope of A" may be larger, in which case the absolute overhead cost is larger, but these analyses all ignore how large the scopes actually are, just compare apples to apples. So, for instance, if A" scope is actually a smaller scope than A, the total routing overhead of that case will be smaller than the A case, even though the smallest containing abstraction in the A" case is more levels up the abstraction hierarchy than in the A case. I don't have the energy to go through geographic addresses, but to the extent that they also are related to the topology (by constraining the topology to follow the addresses, instead of the other way around), the exact same analysis will apply. If the geographic addresses do not relate to the topology, the routing overhead will not scale, and that case need not be considered further. This is hardly an exhaustive or rigorous analysis. Perhaps some day I will have the time to do such. However, I think I have sketched a proof that, for a given level of operational characteristics, provider-based addressing of dual-homed entities has the same, or lower, routing overhead than non- provider-based. (Both, are, of course, topology-based...) This makes sense, when you think about it. Provider-based addresses can, to some degree, "piggy-back" on the existing routing overhead to route to the provider mesh, whereas a separate address has to bear it's own routing overhead in isolation. Of far large import, in terms of the amount of routing overhead, is how large the smalled containing scope is, i.e. how widely separated in the topology the multiple attaachment points are. Now, on to the rest of your message. As Noel says, multihoming can be supported in a provider-based scheme -- but at the cost of extra routing overhead Noel didn't say that; I said the cost was the same, for a given level of operational characteristics. However, I now think, having gone through the exhaustive analysis above, that it's actually lower. Therefore we have a goal of not propagating multihoming information very much or very far. Yes, which turns into topology engineering to limit the spacing of your multiple connections. The concepts of (1) basing hierarchical addresses on providers, (2) supporting multihoming between providers, and (3) limiting propagation of multihoming information between providers -- are in direct conflict. No. See the analysis above. There is one thing, which is the usual problem with provider-based addresses, which is that if you switch providers, you have to renumber. Multi-homing is not as bad, though, since if your address is A.P1.X, and you have a secondary connection to A.P2, you can switch the secondary provider without renumbering. Of course, if you connect up to an exchange point, you can switch providers without renumbering, but that's true whether you're singly-homed (well, singly-providered would be more accurate) or multi-providered. If your multihoming is between topologically "local" providers which all hang off the same larger provider then the extra information need not propagate very far -- it can be merged at the larger provider. Yes. However, that's not what customers want to do. They want redundant independent connectivity over large areas. That means having "appearances" in larger providers' chunks of the address space, which makes the prefix shared between the multihoming appearances shorter, and in general leads to further propagation of the information if it is to be useful in meeting the customer's need. It's not so much the form of the address which causes the scope to have to be larger, but graph theory. To get optimal routing to a destination, routing information about that individual destination has to spread out to some scope. If that destination is only connected locally, the scope over which is spreads can be pretty small, and still result in optimal routing. If the destination is connected widely, the scope has to be far larger. For example, if area X has two links, there's some contiguous area of the graph, which includes both the places where those links join, which have to be inside the scope of the detailed info for X to allow traffic crossing the border of that scope to head for the optimal inbound link to X. It all has to to with the topology of the network; the form of the address has little to do with it. OK, so you just tell the customers they can't have the multihoming they want? ... the level of Internet reliability which customers require has gone up faster than the level of reliability which the providers are giving them, such that now many (an increasing number of) customers seem to think they must have the redundancy that multihoming between providers gives them. That is, because of the way the Internet is run, multihoming is now a business necessity. Fine. They need to understand that there's no free lunch, and depending on how they do that multihoming (i.e. what the topology is), and what operational characteristics they want, the cost of doing so is going to vary. An alternative possibility is that, at least within the areas which impact "core" routers, you put multihoming and the address space along different dimensions. ... Specifically, within the "core" you could route NOT by provider but by geography. Thus, within the "core" whether you are multihomed to different providers or not, you would be included in one address prefix, a geographic one, reachable by multiple providers. I don't have the energy to type in the analysis of this, but my suspicion is you would find that the routing overhead to support this is even higher. Either the address hierarchy you are using is a good match to the topology, in which case you've simply got topology-based addresses, or it's not a good match to the topology, and your routing overhead costs just went through the roof. I understand the goal here is not to absolutely minimize routing costs, but rather to provide a system with a give set of operational characteristics. However, understanding how much it will cost you, in overhead, to provide those characteristics, in various schemes, is important. My main -- in fact, only -- concern is that we must not mandate an architecture which puts the providers' capabilities in direct conflict with the users needs, and operationally it appears that the users must have multihoming between independent providers .. The provider-based hierarchical addressing plan feels unsupportable for that reason See the analysis above. Your statement is invalid in a technical sense. This mail ... IS a claim that provider-based addressing may have looked good once, but the Internet and its users have changed, and now its problems outweigh its benefits. I have come to the exactly opposite conclusion. If you would examine my reasoning, and show me where I am wrong, I would be most interested to hear it. Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 14:10:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04474; Fri, 1 Sep 1995 14:10:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA25582; Fri, 1 Sep 1995 14:07:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA25549; Fri, 1 Sep 1995 13:51:22 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03558; Fri, 1 Sep 1995 13:51:06 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA12974; Thu, 31 Aug 1995 23:50:44 -0400 Date: Thu, 31 Aug 1995 23:50:44 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: <9509010129.AA09992@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Has anyone looked at how FCC had to force 800 number portability in the US and is now expanding that into local telephone number portability? Customers have demanded this and eventually FCC and the Telcos are implementing it. The analogy to IP providers is that eventually such portability will have to be retrofitted if it is not provided for in the original design. Will the IP community have to relearn the lessons of the telephone community? From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 14:31:30 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05603; Fri, 1 Sep 1995 14:31:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA25637; Fri, 1 Sep 1995 14:27:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA25593; Fri, 1 Sep 1995 14:09:47 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04454; Fri, 1 Sep 1995 14:09:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10604; Fri, 1 Sep 95 00:09:22 -0400 Date: Fri, 1 Sep 95 00:09:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509010409.AA10604@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker > We can explore other alternatives, such as "exchange-point based Noel, that's what YOU are willing to do. It is not, however, how the discussion has generally been conducted to date In my opinion, I have seem very few (any?) posters on the multi-homing issue who had anything like a reasonable grasp of the issue. and no, EVERYONE most definitely does NOT admit to the problems with the current scheme. Let's not rehash this. There is no track record of legitimate debate about tradeoffs Perhaps if so many people weren't trying (futilely, obviously) to turn back the tide, wasting everyone's time and energy at a time when the Internet has many real and serious needs on which that time and energy would be better spent, people would be more forthcoming, and we could turn out attention to how to make the inevitable future less painful (e.g. with exchange points designs, etc, etc). > and mathematics beats politics every day of the week,... well, that's an interesting credo for living in this world. I believe some US state legislature once tried to legislate pi equal to 22/7. Last time I looked, pi had not obliged. Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 14:33:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05721; Fri, 1 Sep 1995 14:33:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA25659; Fri, 1 Sep 1995 14:30:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA25620; Fri, 1 Sep 1995 14:21:32 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04975; Fri, 1 Sep 1995 14:21:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10629; Fri, 1 Sep 95 00:20:56 -0400 Date: Fri, 1 Sep 95 00:20:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509010420.AA10629@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur Has anyone looked at how FCC had to force 800 number portability in the US and is now expanding that into local telephone number portability? Customers have demanded this and eventually FCC and the Telcos are implementing it. Yes, and the way it works is ... drum roll ... there's a mapping table. Note also that local number portability is some years away, they are being given time to implement this mapping. Needless to say, this will not be free; the users will pay for it (one way or another). The analogy to IP is a little tricky. For one, I can't dial "lcs.mit.edu" on my phone. For another, given that the Internet is a farily seamless international communications system, it might be difficult to impose national rules on its operations like that. Finally, I'm not sure the portability is country-wide (which would really make the mapping hairy, for obvious reasons), but just withing an area code (or maybe a LATA). Since the Internet doesn't have any exact equivalents (yet), the equivalent capability is not clear. The analogy to IP providers is that eventually such portability will have to be retrofitted if it is not provided for in the original design. Oh, goody, legislatures doing network engineering. I'm waiting for them to pass a law saying you have to be able to take your routing-name with you when you go. What's next, regulating the tides? We've already had this argument, five times. A mapping system (like the 800/local portabilty system) would be nice, but the network is growing so fast we don't currently have the time to do it, if we want to keep the network i) growing, and ii) working. Maybe some day. Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 14:38:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05871; Fri, 1 Sep 1995 14:38:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA25679; Fri, 1 Sep 1995 14:34:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA25577; Fri, 1 Sep 1995 14:06:36 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04197; Fri, 1 Sep 1995 14:05:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20086 Fri, 1 Sep 1995 14:04:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10579; Fri, 1 Sep 95 00:02:01 -0400 Date: Fri, 1 Sep 95 00:02:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509010402.AA10579@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, doleary@cisco.com Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu, inet-access@earth.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker > I believe that this mis-characterizes the situation. I do not believe > that deployment of CIDR as is being proposed "effectively prevents > local providers from multi-homing," or even prevents anyone from each advertisement of a multi-homed net which goes out additional links is an exception in the routing table. Any large-scale use of this mechanism completely defeats the purpose of CIDR. It allows no aggregation. Please see the long message I just sent to Big-I (in response to a message from Scott Brim) in which I sketch a proof that, *for a given level of operational capability* (approximately, how good the resulting routes are), the routing overhead cost of using a provider-based address is the same, or lower than, using a non-provider based address. I will quote a few small chunks here: This makes sense, when you think about it. Provider-based addresses can, to some degree, "piggy-back" on the existing routing overhead to route to the provider mesh, whereas a separate address has to bear it's own routing overhead in isolation. ... There is one thing, which is the usual problem with provider-based addresses, which is that if you switch providers, you have to renumber. Multi-homing is not as bad, though, since if your address is A.P1.X, and you have a secondary connection to A.P2, you can switch the secondary provider without renumbering. ... [People] need to understand that there's no free lunch, and depending on how they do that multihoming (i.e. what the topology is), and what operational characteristics they want, the cost of doing so is going to vary. As an addendum to that last, for all but the most minimal levels of functionality, the routing overhead cost of multi-homing is *higher* than single-homing. See the long message to understand why. The other handling for multi-homing is if a provider is large enough to get their own, top-level CIDR block. Clearly there had better not be very many of these or there will be a large, flat, global table which is what CIDR is supposed to eliminate. Again, to quote from the long message: Of far large import, in terms of the amount of routing overhead, is how large the [smallest] containing scope is, i.e. how widely separated in the topology the multiple attaachment points are. ... To get optimal routing to a destination, routing information about that individual destination has to spread out to some scope. If that destination is only connected locally, the scope over which is spreads can be pretty small, and still result in optimal routing. If the destination is connected widely, the scope has to be far larger. For example, if area X has two links, there's some contiguous area of the graph, which includes both the places where those links join, which have to be inside the scope of the detailed info for X to allow traffic crossing the border of that scope to head for the optimal inbound link to X. So, as long as we aren't completely silly about i) how we organize the topology (i.e. how widely we separate our multihoming points in the network's connectivity topology), and ii) how we set up the abstraction hierarchy (so as to minimize the naming scope with contains the multi-homing connection points), this should not be a problem. Now I believe the above summarizes the details that have recently been discussed. It may well do so, but it appears that your summary appears to contain demonstrably incorrect assumptions. I think it not at all complicated to predict from the above that multi-homing had better not occur on a large scale No. Multi-homing with topologically widely separted connection points will be expensive to support, but reliable multi-homing can be had if a little bit of sense is displayed in configuring the network. that local providers will have very, very strong disincentives from changing transit providers. It is, in fact, not clear to me that a local provider will be able to change even once. It all depends on how the topology and naming is arranged. If there is a reasonable naming scope defined in which the local provider can appear as a peer (in address hierarchy terms) of the transit providers, that local provider will be able to switch to any other provider which appears in that naming scope, without only a modest increase in routing overhead from using pure provider-based addresses. Of course, the addresses used will still be topology-based, just a slightly different style. How will those costs cover turning the global routing table into a flat address space, if there is wide-spread multi-homing? If that WON'T be the effect, please explain how. If there is a lot of multihoming with connections widely space over the Internet, the rsultign routign overheat will be substantial, not matter *what* addressing scheme is used. That is a simple, inevitable result of graph theory. > I believe the current assumption is that the number of multi-homed > cases will be small enough that they can be handled by the current As I have stated, this is an incorrect analysis of the situation. What needs to be considered is not how many multi-homes sites there are, but i) how widely separated their connections are in the topology, and ii) what the addressing hierarchy looks like. If i) most sites are reasonably closely spaced, and ii) the addressing hierarchy is reasonable, there is no reason *every* customer cannot be multihomed. how small is small enough? at what point will it be too many? At the moment there appears to be ... a lack of solid boundary statements so there is no way to know whether the current scheme will suffice at all, other than to state that multi-homing causes CIDR to propagate exception entries globally. Anyone making that statement does not understand the whole fundamental basis of CIDR, or multi-homing, very well. On the other hand, your desire for a "solid boundary" displays a simplistic gloss on what is, inevitably, a more complex question, as detailed in the paragraph above. Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 15:31:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08505; Fri, 1 Sep 1995 15:31:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA25751; Fri, 1 Sep 1995 15:27:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA25734; Fri, 1 Sep 1995 15:13:13 +1000 From: wolf@instinet.com Received: from peugeot.instinet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07440; Fri, 1 Sep 1995 15:12:59 +1000 (from wolf@instinet.com) Received: from tus1.devcs.instinet.com by peugeot.instinet.com with SMTP id AA26698 (InterLock SMTP Gateway 3.0 for ); Fri, 1 Sep 1995 01:12:41 -0400 Received: from wolf.instinet.com (wolf.devcs.instinet.com) by tus1.devcs.instinet.com with SMTP (1.37.109.11/16.2) id AA233972617; Fri, 1 Sep 1995 01:16:57 -0400 Date: Thu, 31 Aug 95 11:33:54 PDT Subject: RE: Multihoming To: Scott W Brim , Tony Li Cc: big-internet@munnari.OZ.AU X-Mailer: Chameleon ARM_55, TCP/IP for Windows, NetManage Inc. Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Precedence: bulk In response to: ...customers want... redundant independent connectivity over large areas. Tony Li wrote: I've seen no data to support this claim. In fact, given the economics and security aspects of the situation, most are likely to want highly localized redundancy. Recall that a single point of contact is highly preferable to contain the security exposure. Maintaining lots of different firewalls is painful and expensive. Further it's likely that geographically distant second links simply cost a lot more than the benefit that they provide. You are correct that users will want provider diversity, but that is orthogonal to geographic diversity. ------------------------------- Tony, You could not be more wrong - your thinking process in this case is somewhat stochastic. Every major user of communications systems wants and needs both provider and geographical diversity. We are not sending e-mails around that can be a day late, we (and many others) are sending financial transactions that happen now, or they do not happen, or information is being sent that has value only now (a.k.a., real-time). We generate revenue only when our network is running. When we build our headend data centers, we always think in twos and threes. We get two sites in two states, we get two power sources, we get two or three IXC telcos, we connect to two or three LEC central office switches. Our regional sites are connected to both headends and other regional sites, etc. If we let customers connect to us via the Internet (which I sometimes doubt will ever be ready for real business), will we do less in our provisioning. The answer is a flat out NO ! We have customers throughout the world. I can not risk a major fire or earthquake knocking a city down and with it our access. How many companies went out of business following the Illnios Bell fire where just one CO burned ? No network, no revenue, no pay check. Do you want your pension or mutual fund to lose your money because you made a poor assumption. If the Internet can not support geographically diverse connectivity, to quote you, "...it's broken." For now, I might be implementing Internet technology, but my customer network is going to remain private (i.e., no access via the "public Internet"). Let's think about the users here. ------------------------------------- This message was sent by: Laurence J. Wolf Director of Network Architecture Instinet Corp. E-mail: wolf@instinet.com Date: 08/31/95 Time: 11:03:05 ------------------------------------- From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 15:51:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09465; Fri, 1 Sep 1995 15:51:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA25788; Fri, 1 Sep 1995 15:47:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA25771; Fri, 1 Sep 1995 15:39:52 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08871; Fri, 1 Sep 1995 15:39:04 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA16917; Thu, 31 Aug 1995 22:38:18 -0700 Date: Thu, 31 Aug 1995 22:38:18 -0700 From: Tony Li Message-Id: <199509010538.WAA16917@greatdane.cisco.com> To: mn@ios.com Cc: big-internet@munnari.OZ.AU In-Reply-To: (mn@ios.com) Subject: Re: Multihoming Precedence: bulk Michael, Just to be specific, we're talking large scale geographic diversity. Not just the next provider over. The key question here is the topological distance between the connection points. If the connection points are not wildly diverse, then it's possible to absorb the multihomed sites by aggregation at some point. Please understand that I do NOT discount local multihoming. Even cisco is multihomed, but to _local_ providers. Tony From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 16:33:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11334; Fri, 1 Sep 1995 16:33:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA25852; Fri, 1 Sep 1995 16:27:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA25833; Fri, 1 Sep 1995 16:13:15 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10343; Fri, 1 Sep 1995 16:12:00 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Fri, 1 Sep 1995 15:03:28 +0900 From: Masataka Ohta Message-Id: <199509010603.PAA23001@necom830.cc.titech.ac.jp> Subject: Re: Multihoming To: tli@cisco.com (Tony Li) Date: Fri, 1 Sep 95 15:03:27 JST Cc: mn@ios.com, big-internet@munnari.OZ.AU In-Reply-To: <199509010538.WAA16917@greatdane.cisco.com>; from "Tony Li" at Aug 31, 95 10:38 pm X-Mailer: ELM [version 2.3 PL11] Precedence: bulk > Just to be specific, we're talking large scale geographic diversity. > Not just the next provider over. One important reason for multihoming is to have redundant pathes. > The key question here is the topological distance between the > connection points. If the connection points are not wildly diverse, > then it's possible to absorb the multihomed sites by aggregation at > some point. If the two providers have the same route to the backbone, that's an uninteresting multihoming. Both of them will loss connection with a single fault. If the two provider prefixes are aggregated at some level, partitioning within that level will create a routing blackhole, which is a reason why we shouldn't aggregate providers and should have provider-level flat routing. > Please understand that I do NOT discount local multihoming. Even > cisco is multihomed, but to _local_ providers. If the _local_ providers are connected to the same global backbone, I'm afraind cisco is wasting money for meaningless multihoming. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 16:50:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12196; Fri, 1 Sep 1995 16:50:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA25894; Fri, 1 Sep 1995 16:47:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA25888; Fri, 1 Sep 1995 16:43:35 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11878; Fri, 1 Sep 1995 16:43:28 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA18315; Thu, 31 Aug 1995 23:39:55 -0700 Date: Thu, 31 Aug 1995 23:39:55 -0700 From: Tony Li Message-Id: <199509010639.XAA18315@greatdane.cisco.com> To: mohta@necom830.cc.titech.ac.jp Cc: mn@ios.com, big-internet@munnari.OZ.AU In-Reply-To: <199509010603.PAA23001@necom830.cc.titech.ac.jp> (message from Masataka Ohta on Fri, 1 Sep 95 15:03:27 JST) Subject: Re: Multihoming Precedence: bulk If the two provider prefixes are aggregated at some level, partitioning within that level will create a routing blackhole, which is a reason why we shouldn't aggregate providers and should have provider-level flat routing. Or, providers should be well connected. It's clearly possible to build networks which don't easily partition. If the _local_ providers are connected to the same global backbone, I'm afraind cisco is wasting money for meaningless multihoming. That depends on the failure that you're trying to protect against. Tony From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 16:58:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12604; Fri, 1 Sep 1995 16:58:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA25930; Fri, 1 Sep 1995 16:55:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA25885; Fri, 1 Sep 1995 16:40:52 +1000 Received: from relay1.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11735; Fri, 1 Sep 1995 16:39:26 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by relay1.UU.NET with SMTP id QQzfgs08187; Fri, 1 Sep 1995 02:38:24 -0400 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA18205; Thu, 31 Aug 1995 23:32:54 -0700 Date: Thu, 31 Aug 1995 23:32:54 -0700 From: Tony Li Message-Id: <199509010632.XAA18205@greatdane.cisco.com> To: wolf@instinet.com Cc: swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: Subject: RE: Multihoming Precedence: bulk You could not be more wrong - your thinking process in this case is somewhat stochastic. Highly appropriate considering what we're looking at (human behavior) is highly stocastic. Every major user of communications systems wants and needs both provider and geographical diversity. We are not sending e-mails around that can be a day late, we (and many others) are sending financial transactions that happen now, or they do not happen, or information is being sent that has value only now (a.k.a., real-time). We generate revenue only when our network is running. When we build our headend data centers, we always think in twos and threes. We get two sites in two states, we get two power sources, we get two or three IXC telcos, we connect to two or three LEC central office switches. Our regional sites are connected to both headends and other regional sites, etc. If we let customers connect to us via the Internet (which I sometimes doubt will ever be ready for real business), will we do less in our provisioning. The answer is a flat out NO ! Good. But you've also just proven that you're a major exception. Recall that we're trying to talk about is the scaling effects of multihoming. Who's the average user on the net? Not the service/content provider.... it's the consumer. If the Internet can not support geographically diverse connectivity, No one said that or implied it. Such sites may be difficult to aggregate at any stratum less than at the continental level. They simply need to be treated as an exception within this stratum. As long as the number of such exceptions remains within the growth rates of technology, there's no problem. Let's think about the users here. Do you think the users would appreciate a functional network? Tony From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 17:12:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13108; Fri, 1 Sep 1995 17:12:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA25955; Fri, 1 Sep 1995 17:07:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA25912; Fri, 1 Sep 1995 16:54:46 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12329; Fri, 1 Sep 1995 16:54:30 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Fri, 1 Sep 1995 15:48:14 +0900 From: Masataka Ohta Message-Id: <199509010648.PAA23261@necom830.cc.titech.ac.jp> Subject: Re: Multihoming To: tli@cisco.com (Tony Li) Date: Fri, 1 Sep 95 15:48:13 JST Cc: mn@ios.com, big-internet@munnari.OZ.AU In-Reply-To: <199509010639.XAA18315@greatdane.cisco.com>; from "Tony Li" at Aug 31, 95 11:39 pm X-Mailer: ELM [version 2.3 PL11] Precedence: bulk > If the two provider prefixes are aggregated at some level, > partitioning within that level will create a routing blackhole, > which is a reason why we shouldn't aggregate providers and should > have provider-level flat routing. > > Or, providers should be well connected. It's clearly possible to > build networks which don't easily partition. What you need, then, is a leaf provider, connected to multiple backbone providers, that is, provider multihoming. > If the _local_ providers are connected to the same global backbone, > I'm afraind cisco is wasting money for meaningless multihoming. > > That depends on the failure that you're trying to protect against. Of course, what we need is the global reachability. For people communicating worldwide, mere local reachability is just meaningless. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 17:51:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14625; Fri, 1 Sep 1995 17:51:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA26019; Fri, 1 Sep 1995 17:47:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA26002; Fri, 1 Sep 1995 17:39:39 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14009; Fri, 1 Sep 1995 17:38:22 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id AAA10330; Fri, 1 Sep 1995 00:45:03 -0700 Date: Fri, 1 Sep 1995 00:45:02 -0700 (PDT) From: Michael Dillon To: Stan Barber Cc: big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft (fwd) In-Reply-To: <199509010112.UAA13607@academ.com> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 31 Aug 1995, Stan Barber wrote: > I am currently polling the providers based in Houston for this kind of info > and will report my findings back the list. I don't yet know how many are > planning to be multi-homed in the time frame you mention. Today, there > Now, Houston may not be representative of the rest of the country, but it > does make an interesting data point. It's a start. If the poll is well designed so that the people understand what you mean by "multihomed" and if you ask for some idea of time-frame (within 3 months, 6 months, 12 months, 2 years) then this will provide the datapoints that we need. But it will only work if the questions are reasonably well-designed and if the survey is done in some other metro areas as well. I would be not at all surprised to find a questionnaire in which 75% answered YES to being multihomed within 6 months but only 15% said they would be running BGP4. However when those providers who don't have BGP4 in their plans actually do become multihomed I think most of them actually will be running BGP4. In other words, there is need for some education as to the implications of multihoming, the techniques of multihoming, the justifications for multihoming..... Right now there are three well-known mailing lists for ISP's and there is one well-known FAQ document for ISP's. I think we also need to have a well-known WWW site for ISP's to help get these people access to the resources that are currently available and to serve as a means to direct additional information to that audience. If the trends continue, small local ISP's and mid-sized regional ISP's will provide net access to the majority of sites in the near future. Right now the expertise in Internet architecture and operations is concentrated topologically in those people who operate the core systems and networks. Somehow that expertise has to filter out towards the fringes within the same time frame as network complexity filters out there. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 18:09:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15156; Fri, 1 Sep 1995 18:09:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA26058; Fri, 1 Sep 1995 18:07:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA26050; Fri, 1 Sep 1995 17:59:48 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14778; Fri, 1 Sep 1995 17:59:28 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id DAA27234; Fri, 1 Sep 1995 03:57:16 -0400 Date: Fri, 1 Sep 1995 03:57:16 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: Masataka Ohta Cc: Tony Li , mn@ios.com, big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: <199509010603.PAA23001@necom830.cc.titech.ac.jp> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Masataka Ohta wrote: > which is a reason why we shouldn't aggregate providers and should > have provider-level flat routing. Please explain more. This sounds like an incredibly bad idea. 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 ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 18:30:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16057; Fri, 1 Sep 1995 18:30:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA26114; Fri, 1 Sep 1995 18:27:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA26087; Fri, 1 Sep 1995 18:10:56 +1000 Received: from blob.best.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15167; Fri, 1 Sep 1995 18:10:11 +1000 (from jim@SmallWorks.COM) Received: from hosaka.smallworks.com (hosaka.SmallWorks.COM [192.207.126.1]) by blob.best.net (8.6.12/8.6.5) with SMTP id BAA09406 for ; Fri, 1 Sep 1995 01:09:52 -0700 Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA08611; Fri, 1 Sep 1995 03:09:41 -0500 From: "Jim Thompson" Message-Id: <9509010309.ZM8609@hosaka.smallworks.com> Date: Fri, 1 Sep 1995 03:09:40 -0500 In-Reply-To: Michael Dillon "Re: ownership, leasing, renumbering, and that draft (fwd)" (Sep 1, 12:45am) References: Organization: Nearly none! To: Michael Dillon , Stan Barber Subject: Re: ownership, leasing, renumbering, and that draft (fwd) Cc: big-internet@munnari.OZ.AU X-Mailer: Z-Mail (3.2.0 06sep94) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk > If the trends continue, small local ISP's and mid-sized regional ISP's > will provide net access to the majority of sites in the near future. Sorry to be so US-centric, but this is not going to continue to happen in the US. The 'baby-bells' are getting into the action. (I can't say why I know, suffice it to say that I'm doing some work for a major router vendor, and the customer list for the work contains names like US West, Bell Atlantic, etc.) The whole 'power of the commons' thing should explain why these companies will drive many, if not all, small ISPs into the ground. Jim -- Jim Thompson jim@SmallWorks.COM From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 18:32:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16327; Fri, 1 Sep 1995 18:32:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA26134; Fri, 1 Sep 1995 18:30:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA26094; Fri, 1 Sep 1995 18:18:09 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15637; Fri, 1 Sep 1995 18:17:54 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id BAA10579; Fri, 1 Sep 1995 01:24:28 -0700 Date: Fri, 1 Sep 1995 01:24:28 -0700 (PDT) From: Michael Dillon To: Jim Thompson Cc: Stan Barber , big-internet@munnari.OZ.AU Subject: Re: ownership, leasing, renumbering, and that draft (fwd) In-Reply-To: <9509010309.ZM8609@hosaka.smallworks.com> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Jim Thompson wrote: > > If the trends continue, small local ISP's and mid-sized regional ISP's > > will provide net access to the majority of sites in the near future. > > Sorry to be so US-centric, but this is not going to continue to happen > in the US. The 'baby-bells' are getting into the action. (I can't say > why I know, suffice it to say that I'm doing some work for a major router > vendor, and the customer list for the work contains names like US West, Bell > Atlantic, etc.) > > The whole 'power of the commons' thing should explain why these companies > will drive many, if not all, small ISPs into the ground. I'll believe it when I see it. So far small local and regional ISP's have been able to hold their ground against the telco's by providing superior service. I don't think this will change anytime soon, especially in a country which appears to be developping a great distaste for large monopolies like cable TV, telco's etc... I think the telco's will settle into the backbone provider niche which is something they can do well as well as selling connections to larger corporate clients. That will require a LOT of routers too. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 18:35:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16390; Fri, 1 Sep 1995 18:35:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA26156; Fri, 1 Sep 1995 18:33:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA26097; Fri, 1 Sep 1995 18:21:12 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15820; Fri, 1 Sep 1995 18:21:05 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Fri, 1 Sep 1995 17:13:39 +0900 From: Masataka Ohta Message-Id: <199509010813.RAA23799@necom830.cc.titech.ac.jp> Subject: Re: Multihoming To: dorian@CIC.Net (Dorian Rysling Kim) Date: Fri, 1 Sep 95 17:13:37 JST Cc: tli@cisco.com, mn@ios.com, big-internet@munnari.OZ.AU In-Reply-To: ; from "Dorian Rysling Kim" at Sep 1, 95 3:57 am X-Mailer: ELM [version 2.3 PL11] Precedence: bulk > > which is a reason why we shouldn't aggregate providers and should > > have provider-level flat routing. > > Please explain more. This sounds like an incredibly bad idea. See an Internet Draft: draft-ohta-ipv6-addr-arch-00.txt where an analysis is given on how a geography-based and, at the same time, provider-based hierarchical addressing scheme can scalably support multi-homing with provider-level-flat routing. > There are many places where redundancy can be achieved with multiple > connections. Don't you think hierarchy reduces the redundancy. What's wrong with making addressing scheme as flat as possible? Are there any reason to not to have a provider hierarchy. > 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. Sure. And, flat routing with dense connectivity is the most redundant. Fortunately, the scheme with provider-level-flat routing is scalable enough. > 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. I think you have overlooked a failure mode of partitioning of an aggragated provider group, which will be common with CIDR. A single homed provider for a single homed site is a single point of failure. Two single homed providers, sharing some part of prefix, for a dual homed site have a single point of failure for the site at the aggragation point of the shared prefix. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 20:50:30 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20960; Fri, 1 Sep 1995 20:50:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA26297; Fri, 1 Sep 1995 20:47:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA26281; Fri, 1 Sep 1995 20:34:39 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20541; Fri, 1 Sep 1995 20:34:34 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id AAA13060; Fri, 1 Sep 1995 00:30:18 -0400 Date: Fri, 1 Sep 1995 00:30:18 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Dave Crocker Cc: Noel Chiappa , big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 31 Aug 1995, Dave Crocker wrote: > Noel, that's what YOU are willing to do. It is not, however, how > the discussion has generally been conducted to date, and no, EVERYONE most > definitely does NOT admit to the problems with the current scheme. > > There is no track record of legitimate debate about tradeoffs and > there is strong pressure against changing that. While we are talking about legitimacy, I hope debaters are somehow making their affliations clear so that biases are accounted for. A researcher getting a grant from a large current or future transit provider may have a different opinion on this issue then the future victims of an unfair scheme, whatever that may be. > > >... and mathematics beats politics every > >day of the week,... Not in this earth, maybe in a mathematicians dream, but I would never want to live in a world ruled by mathematicians. Mathematics is a precise art, politics is an art of compromise where nothing is ever precise. > > well, that's an interesting credo for living in this world. > > d/ > > -------------------- > Dave Crocker +1 408 246 8253 > Brandenburg Consulting fax: +1 408 249 6205 > 675 Spruce Dr. page: +1 408 581 1174 > Sunnyvale, CA 94086 USA dcrocker@brandenburg.com > > Sanjay Kapur Kapur Business Systems, Inc. (one of the little guys). From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 20:58:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21133; Fri, 1 Sep 1995 20:58:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA26330; Fri, 1 Sep 1995 20:56:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA26279; Fri, 1 Sep 1995 20:34:21 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20531; Fri, 1 Sep 1995 20:34:12 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id AAA13050; Fri, 1 Sep 1995 00:17:33 -0400 Date: Fri, 1 Sep 1995 00:17:33 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Dave Crocker Cc: "Dave O'Leary" , big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu, inet-access@earth.com Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 31 Aug 1995, Dave Crocker wrote: > > Network numbers are assigned by providers. Local providers will > get their CIDR block from their transit providers. End-users from their > attachment providers. Numbers & blocks will be 'leased', that is the > assignment is not permanent. If you change your up-link attachment, you > will need to return your block and get a new one from your new provider. > This necessitates renumbering. For local providers, it necessiates > renumbering by all your subscribers. > > Multi-homing support is provided by taking the network number > within one provider's block and advertising out another provider's link. > As such it does not fit within their CIDR block. Hence, each advertisement > of a multi-homed net which goes out additional links is an exception in the > routing table. Any large-scale use of this mechanism completely defeats > the purpose of CIDR. It allows no aggregation. > > The other handling for multi-homing is if a provider is large > enough to get their own, top-level CIDR block. Clearly there had better > not be very many of these or there will be a large, flat, global table > which is what CIDR is supposed to eliminate. > > Now I believe the above summarizes the details that have recently > been discussed. If there are others that are showing up in the next draft > of the leasing proposal, it would be helpful to hear of them. > > I think it not at all complicated to predict from the above that > multi-homing had better not occur on a large scale and that local providers > will have very, very strong disincentives from changing transit providers. > It is, in fact, not clear to me that a local provider will be able to > change even once. > > -------------------- > Dave Crocker +1 408 246 8253 > Brandenburg Consulting fax: +1 408 249 6205 > 675 Spruce Dr. page: +1 408 581 1174 > Sunnyvale, CA 94086 USA dcrocker@brandenburg.com > > The above description is that of a monopoly. Is the CIDR addressing scheme being designed by monopolists and large internet providers interested in developing monopolies? I no longer believe that the issue of number portability and multihoming is a technical issue but a commercial/political one with the small internet providers and big transit providers on opposite sides of the spectrum (like David and Goliath). As the Internet gets more important in the life of society, it would be undemocratic to give a few organizations (i.e. transit providers) too much power. In the guise of increasing the size of the Internet, competition is going to be stifled to an unbearable degree and it would be very difficult for a small company to resist the demands of their transit providers. As regulatory organizations do not exist for the Internet, there would be no limit to the price gouging from captive customers who have no choice and can not go to the competition. Transit provider addressing smacks a lot of X.400 addressing and has all the drawbacks of that scheme. As proposed, without easy number portability and the absurd concept of "leasing numbers" from a big company that you are forever beholden to, CIDR will be the death of the Internet as we know it. This is something that the large Telcos want anyway. CIDR might be acceptable if even the large transit providers had to lease numbers and gets a new set of numbers periodically (through some sort of lottery). The democratic way would be that NO ONE is assigned permanent numbers. CIDR addressing may work as proposed if an X.500 type directory service also exists and a computer's routing software discovers its address from this service and it is updated dynamically. As part of the standard, no computer (including a router) would be allowed to store its own routing address but ALWAYS discover it from an X.500 type directory service (much like RARP/BOOTP for ethernet but on a global scale). Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 21:09:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21429; Fri, 1 Sep 1995 21:09:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA26360; Fri, 1 Sep 1995 21:08:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA26354; Fri, 1 Sep 1995 21:02:33 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21248; Fri, 1 Sep 1995 21:02:18 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id HAA28863; Fri, 1 Sep 1995 07:01:18 -0400 (EDT) Date: Fri, 1 Sep 1995 07:01:18 -0400 (EDT) From: Scott Bradner Message-Id: <199509011101.HAA28863@newdev.harvard.edu> To: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk > > The analogy to IP providers is that eventually such portability will have > to be retrofitted if it is not provided for in the original design. > > Oh, goody, legislatures doing network engineering. I think the answer here is simpler - one does not put IP addresses on business cards nor does one (in general) memorize IP addresses and give them out to your friends. The DNS name is used instead. These are things that are done with phone numbers and therefore there is much clearer reasons for phone number portability. And even in this case, the house telecommunications bill specifically says that local number portability is only required if "technically feasible". I used to think this was a problem and even commented on it in public a few times (mostly as a way to scare the audience about the technical savvy of congress) I no longer think this is an issue relevant to IP networks. Scott From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 22:30:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24018; Fri, 1 Sep 1995 22:30:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA26458; Fri, 1 Sep 1995 22:27:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA26438; Fri, 1 Sep 1995 22:14:20 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23514; Fri, 1 Sep 1995 22:14:17 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id IAA28884; Fri, 1 Sep 1995 08:14:11 -0400 Date: Fri, 1 Sep 1995 08:14:10 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: Sanjay Kapur Cc: Dave Crocker , Noel Chiappa , big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Sanjay Kapur wrote: > While we are talking about legitimacy, I hope debaters are somehow making > their affliations clear so that biases are accounted for. A researcher Why is it that this topic always rears its ugly head in these discussions? Is this really so necessary? Can't we just discuss the merits and feasibility of differnt approaches? -dorian, not one of the little guys and not one of the EVIL GREEDY BASTARDs, and feeling distinctly like Rodney King. ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 22:35:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24296; Fri, 1 Sep 1995 22:35:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA26480; Fri, 1 Sep 1995 22:33:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA26441; Fri, 1 Sep 1995 22:18:21 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23638; Fri, 1 Sep 1995 22:18:15 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id IAA00689; Fri, 1 Sep 1995 08:20:22 -0400 Date: Fri, 1 Sep 1995 08:20:21 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Multihoming To: Tony Li Cc: big-internet@munnari.OZ.AU In-Reply-To: <199509010538.WAA16917@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 31 Aug 1995, Tony Li wrote: > > Michael, > > Just to be specific, we're talking large scale geographic diversity. > Not just the next provider over. large scale like X.com, Inc, with a fully owned network of Ts from the west coast to the east coast? Or just NSPs that peer at multiple meetpoints? I could not find in my message the 'next provider over'. Of course, such a large scale entity could then split their network , renumber some thousand hosts, and run bgp internally against the two halves that are connected to two different providers.;-( Well, this discussion here seems to me to go into a simplistic direction without looking at the real world. There will always be some multihomed large entities, and this is better supported in a way that the people who PAY nsps/isps get an acceptable level of service. Between NSPs there are, e.g. big multihomed entities. Or will then the traffic exchange for certain prefixes be limited to the geographically corresponding meetpoints? Then, if that meetpoint dies, an NSP could not route the prefixes that belong to that meetpoint through another one? (for the smarties and fast shooters: I do not talk about a split AS using the surrounding ASs as backbone bypass). How can a meetpoint die? E.g., switch is down. This kind of rerouting needs full support of large scale geographical multihoming. I don't want to tell customers that they cannot be routed because the meetpoint for their geographical area is down, and the engineous internet design does not support large scale rerouting to a different meetpoint. On the other hand I don't see why aggregation should not support large scale multiple interconnection. Within the NSP network the aggregation is still valid, and only big prefixes would change in the routing. To the outside everything is aggregated anyways, with exception of some individual routes. The 'Internet' I see is about 31000 routes large, that is about 4 to 6 Mbytes in table space. Where is the problem on a 64Mbyte router? But then, for NSPs with networks that have an address topology that cannot be aggregated geographically, this is an internal problem. Kind of a design flaw from the past that comes now haunting the present. Why should everyone around such a misdesign then renumber? Why should also a standard not support necessary features because it is a headache for one or the other who in the past did not do the homework and already address geographically? Looks to me as if some peoples' internal problems are put on the whole community. I would like to propose to do it just the other way round: put down what must be supported, and then work on how it can be done. currently it is: we don't know how to do it (although I believe that it is already all possible), so we negate the necessity of it. that's the big bird's head in the sand. > > The key question here is the topological distance between the > connection points. If the connection points are not wildly diverse, well, they can be. for the local entity that wants two access lines this is true. for the nsp routing already it is not, neither for continent wide corporate networks. > then it's possible to absorb the multihomed sites by aggregation at > some point. > > Please understand that I do NOT discount local multihoming. Even > cisco is multihomed, but to _local_ providers. between the corporate networks cisco is small. and not the center of the world either ;-) > > Tony > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Fri Sep 1 22:50:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24797; Fri, 1 Sep 1995 22:50:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA26517; Fri, 1 Sep 1995 22:47:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA26511; Fri, 1 Sep 1995 22:45:27 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24577; Fri, 1 Sep 1995 22:44:51 +1000 (from mn@tremere.ios.com) Received: from tremere.ios.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA11292 Fri, 1 Sep 1995 22:41:28 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id IAA00695; Fri, 1 Sep 1995 08:42:11 -0400 Date: Fri, 1 Sep 1995 08:42:11 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: casting your multi-homing/provider-changing vote To: Sanjay Kapur Cc: Dave Crocker , "Dave O'Leary" , big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu, inet-access@earth.com In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk I did not include Dave Crocker's or Sanjay Kapur's message, to keep this short: I agree with Sanjay on his views. This Internet draft cannot become an ISO standard because of exactly these contents. Happily the IETF is now an ISO standards organisation, and there are means to object to this on a higher level. The proposed standard eliminates competition, since it does not contain the appropriate regulations that would inhibit abuse of the proposed scheme. Such regulations must go very far and will be really voluminous, since all kinds of compensation to downline providers must be provided in case they are forced to renumber for faulty behavious of their upline. It shows to me that IETF must now learn to write fully complete ISO standards. This here is just one half. My wish: don't , pull this back. It will not fly anyways and probably some whole industry environment will kind of laugh at the ISO standard newbies. The whole CIDR thing: CIDR is a tool to reduce ruting overhead. This does not mean that it will be possible to achieve at a 100% CDRised routing environment. All providers who's routers carry x times the internet routing table at any time have misdesigned backbones. Clean this up first, then look at your router loads, offload route calculation from routers that are too weak to do it or change brand. All those who run fully meshed BGP: your fault. Clean up your act. Don't yell 'my routers choke because the internet is too big'. The necessity for CIDR is not disputed, I believe. But the thinking it should be 100% is clearly wrong. ... an ISO standard may not contain stuff that eliminates or hinders competition ... read the charters Mike ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 00:10:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28427; Sat, 2 Sep 1995 00:10:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA26622; Sat, 2 Sep 1995 00:07:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA26614; Fri, 1 Sep 1995 23:55:59 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27424; Fri, 1 Sep 1995 23:55:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11788; Fri, 1 Sep 95 09:55:46 -0400 Date: Fri, 1 Sep 95 09:55:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011355.AA11788@ginger.lcs.mit.edu> To: mn@ios.com, tli@cisco.com Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Michael F. Nittmann" this discussion here seems to me to go into a simplistic direction Indeed. Between NSPs there are, e.g. big multihomed entities. If such organizations want to connect at widely topologically separate points, and have traffic take whichever ones are up/optimal, then no matter *what* kind of address they are given (be it a top level one, or one 17 levels down), routes to that address will have to be flooded throughout large parts of the net. To get a given level of routing performance, there is a certain irreducible level of routing overhead which one must pay. The costs for that routing overheaed are not borne locally, but over a wider scope. I think that the *only* way in which this whole situation will be brought under control is to cut the Gordian knot and charge for routing advertisements, on a sliding scale which takes into account the scope over which that advertisement has to be sent. That way, people will pay for the level of routing service they get, and people who just have to have a certain level of routing functionality will pay for it. E.g. those with widely separate multi-homing will pay more than whose will settle for less widely separated multihoming. if that meetpoint dies ... How can a meetpoint die? E.g., switch is down. I would think that the best way to design such a thing is replicate the most critical elements, so that there are no single points of failure. How to do this economically (and there are ways to achieve that at very reasonable cost, certainly far less than 2x cost, BTW) is a separate thread, though. the engineous internet design does not support large scale rerouting to a different meetpoint. Oh, it will support it, but there's no free lunch; if you want this, you have to pay. But then, for NSPs with networks that have an address topology that cannot be aggregated geographically, this is an internal problem. This is another separate thread, but geographic addressing does not yield routing with acceptable overhead levels unless the topology of the network is constrained so that there is a match between the topology and the addressing hierarchy; i.e. topology-based-addresses. Since we all thus agree that the routing needs topology-based addresses, I hoep to hear no more of this so-called "geographic adddressing". Kind of a design flaw from the past that comes now haunting the present. Yes, the Internet has lots of these. It was never intended to grow this large. Looks to me as if some peoples' internal problems are put on the whole community. Ah, right, the standard refrain. I would like to propose to do it just the other way round: put down what must be supported, and then work on how it can be done. Funny, I thought that's what CIDR did... that's the big bird's head in the sand. You should know. > The key question here is the topological distance between the > connection points. well, they can be. And, if they are, the routign overhead to support them will be larger, as sure as 2+2=4. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 00:29:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29112; Sat, 2 Sep 1995 00:29:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA26833; Sat, 2 Sep 1995 00:27:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA26639; Sat, 2 Sep 1995 00:11:09 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28266; Sat, 2 Sep 1995 00:07:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11811; Fri, 1 Sep 95 10:03:42 -0400 Date: Fri, 1 Sep 95 10:03:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011403.AA11811@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu, inet-access@earth.com, mn@ios.com, root@kbs.netusa.net Subject: Re: casting your multi-homing/provider-changing vote Cc: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Michael F. Nittmann" Happily the IETF is now an ISO standards organisation To everyone out there who assumes this message is sarcastic, I checked with the author, and he's quite serious. I'm sure we're all pleased to know we're part of the ISO. :-) The proposed standard eliminates competition, since it does not contain the appropriate regulations that would inhibit abuse of the proposed scheme. Such regulations must go very far and will be really voluminous, I don't know whether to laugh or cry... There is no way the IETF can write such a document. We're the Internet *Engineering* Task Force, right? Not the Internet Public Utility Comission Task Force... It shows to me that IETF must now learn to write fully complete ISO standards. We're all looking forward to this with great enthusiam. probably some whole industry environment will kind of laugh at the ISO standard newbies. Yes, I'm sure the designers of CLNP/IP4/etc are all laughing at this bunch of incompetent amateurs... All providers who's routers carry x times the internet routing table at any time have misdesigned backbones. I don't believe there are any in this state. The necessity for CIDR is not disputed, I believe. Not everyone would agree with you (at least, if by CIDR you mean the topological assignment of addresses...) an ISO standard may not contain stuff that eliminates or hinders competition ... read the charters Hmm, would fragmenting the Internet be considered "hindering competition"? By Jove, you've done it; provided a legal grounds for going forward with the BCP... Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 00:32:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29321; Sat, 2 Sep 1995 00:32:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA26853; Sat, 2 Sep 1995 00:30:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA26759; Sat, 2 Sep 1995 00:20:37 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28816; Sat, 2 Sep 1995 00:20:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11885; Fri, 1 Sep 95 10:20:14 -0400 Date: Fri, 1 Sep 95 10:20:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011420.AA11885@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, root@kbs.netusa.net Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU, doleary@cisco.com, iap@vma.cc.nd.edu, inet-access@earth.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur The above description is that of a monopoly. Is the CIDR addressing scheme being designed by monopolists and large internet providers interested in developing monopolies? Oh great, another person whose intellectual acuity is so limited the only way they can understand the world is to see it all as a giant conspiracy against them. Hint: just because when you fall out of a tree, you break your leg, it doesn't mean gravity is the result of a scheme designed by hospitals, manufacturers of crutches, etc, etc. I no longer believe that the issue of number portability and multihoming is a technical issue but a commercial/political one Oh. So, you're saying that there are no routing overhead ramifications for picking up your address and taking it with you? Would you care to justify that assertion with a technical argument? As the Internet gets more important in the life of society, it would be undemocratic to give a few organizations (i.e. transit providers) too much power. In the guise of increasing the size of the Internet, competition is going to be stifled to an unbearable degree A graduate of the Tim Bass School of Political Economics, I see. there would be no limit to the price gouging from captive customers who have no choice and can not go to the competition. Hint: switch addresses and you're still "kbs.netusa.net". As proposed, without easy number portability and the absurd concept of "leasing numbers" from a big company that you are forever beholden to, CIDR will be the death of the Internet as we know it. I wait with bated breath for your scheme as to how the routing is going to work with "easy number portability". Yes, mapping would do it, but then the thigns we map into (call them "routing-names") will have to change when you change providers. I assume you feel that that is unacceptable too? The democratic way would be that NO ONE is assigned permanent numbers. Well, I don't know about democratic, but a certain degree of flexibility in the addressing hierarchy, to match the flexibity in the topology, is what the routing would like to see. CIDR addressing may work as proposed if an X.500 type directory service also exists and a computer's routing software discovers its address from this service and it is updated dynamically. I think this is sort of the direction we need to go in, yes. The only question is whether the DNS name is the only permanent name a host needs, or whether we need another namespace. As part of the standard, no computer (including a router) would be allowed to store its own routing address but ALWAYS discover it from an X.500 type directory service (much like RARP/BOOTP for ethernet but on a global scale). Well, there are a number of ways to go. You can either make the whole address dynamic (so the high-order bits come from the routers, and the low-order ones are from something like an Appletalk dynamic address assignment system), or assign the low-order bits in a local table (a la RARP) and again the high- order bits from the routers. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 00:50:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29846; Sat, 2 Sep 1995 00:50:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA26891; Sat, 2 Sep 1995 00:47:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA26875; Sat, 2 Sep 1995 00:36:34 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29433; Sat, 2 Sep 1995 00:36:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11993; Fri, 1 Sep 95 10:36:28 -0400 Date: Fri, 1 Sep 95 10:36:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011436.AA11993@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur While we are talking about legitimacy, I hope debaters are somehow making their affliations clear so that biases are accounted for. That's right, nobody here is saying simply what their real technical opinion is, they are always just pushing some line they are paid to purvey. A researcher getting a grant from a large current or future transit provider may have a different opinion on this issue then the future victims of an unfair scheme, whatever that may be. Gee, maybe I better go check my mailbox, there may be a big check in it for me. Come on Sprint, MCI, AT&T... where's my money? I expect to be paid off for my unswerving support in your heartless and greedy campaign to run the "little guys" out of business. > and mathematics beats politics every day of the week,... Not in this earth, maybe in a mathematicians dream, but I would never want to live in a world ruled by mathematicians. Legislatures have power, I never disputed that, but no legislature in this creation, or any other, can change mathematics (or physics, etc, etc). Mathematicians are just people, and I said nothing about them either. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 01:31:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01613; Sat, 2 Sep 1995 01:31:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA26955; Sat, 2 Sep 1995 01:27:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA26940; Sat, 2 Sep 1995 01:20:38 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01180; Sat, 2 Sep 1995 01:20:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12081; Fri, 1 Sep 95 11:20:25 -0400 Date: Fri, 1 Sep 95 11:20:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011520.AA12081@ginger.lcs.mit.edu> To: dorian@cic.net, mohta@necom830.cc.titech.ac.jp Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, mn@ios.com, tli@cisco.com Precedence: bulk From: Masataka Ohta See .. draft-ohta-ipv6-addr-arch-00.txt where an analysis is given on how a geography-based and, at the same time, provider-based hierarchical addressing scheme can scalably support multi-homing with provider-level-flat routing. For those who haven't looked at his, he proposed splitting up the IPv6 address in a "host identifier" field and a "routing" field; the former stays fixed, and uniquely identifies a machine, and the latter is learned dynamically from the routers, and changes automatically when switching providers. The "routing" part of the address is split up into (fixed) (4 bytes), and portions. There is a limit on the amount of stuff any single can cover (this is to make it easier to take routes which enter and leave a single large provider). As there does not appear to be any hierarchy withing the field, I'm not sure routing using this scheme will scale. Don't you think hierarchy reduces the redundancy. No, what's important are the scopes over which an individual destination is visible; it's only outsides those scopes that the hierarchy starts to effect routes. Cross that boundary, though, and the route from then on is optimal. What's wrong with making addressing scheme as flat as possible? The routing overhead grows too fast. Are there any reason to not to have a provider hierarchy. Well, people don't like changing addresses when they change providers. (I know your scheme avoids that, but we are mostly talking about IPv4 here.) flat routing with dense connectivity is the most redundant. And the most expensive in terms of routing overhead. I think you have overlooked a failure mode of partitioning of an aggragated provider group, which will be common with CIDR. Partioning is a problem in almost any addressing/routing architecture. I know of only two main ways of dealing with it: advertise the pieces, or tunnel (which is what IS-IS does). Two single homed providers, sharing some part of prefix, for a dual homed site have a single point of failure for the site at the aggragation point of the shared prefix. Ah, I think I see what the problem might be. In a network, there is not necessarily any single "aggregation point for shared prefixes", rather, this happens along a long boundary (which some of us call the "abstraction action boundary", or AAB). You are perhaps getting mixed up between the "abstraction hierarchy" and the "network topology" (and they are easy to confuse, I know, I used to :-). Try this simple example (everyone might benefot from this exercise, I think, and it will only take 30 seconds, so *please* do it..). Draw 4 dots in a square, numbered 1-4, and connect them as a square; i.e. each dot has two links. Draw a circle around 1 and 2, and another circle around 3 and 4. Label the circles A and B. Draw another circle around the whole thing. Label it U. You have draw a small topology, and an addressing hierarhcy for it. Dot number 1 has the address U.A.1, etc, etc. Now, you have draw the abstraction hierarchy for this graph (it will look like a Unix file system diagram). There is a root, U. Underneath it are two nodes, A and B. Underneath of them are two more nodes, 1 an 2 for the first, and 3 and 4 for the second. Note: even though A and B "connect" only through U in the *abstraction hierachy*, there are actually *two* connections between A and B in the *topology*. The circles you drew were "abstraction naming boundaries"o (ANB's), though. They say nothing about what the *routing* sees. For instance, A.1 might decide to advertise just a single route, to "A", to it's neighbour in B, *or* it might decide to advertise two routes, one to "A.1" an one to "A.2". In the former case, the AAB for A is the same as the ANB for A; in the latter the AAB is *larger* than the ANB. Now, let's assume the simple case, where the AAB is the same as the ANB, and go back to what I said at the top: In a network, there is not necessarily any single "aggregation point for shared prefixes", rather, this happens along a long boundary ... the AAB. As you can see from this simple example, there are *two* places where routes to A.1 and A.2 are collapsed into a single route to A; across the link from A.1 to B, and across the link from A.2 to B. To be technical about it, the AAB is actually: - the set of nodes which have links which join: - the set of nodes which have routes to individual pieces of an abstarction (e.g. A.1, A.2) to - the rest of the graph, which has only routes to some aggregate of those pieces (e.g. A). I hope this helps. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 02:10:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03145; Sat, 2 Sep 1995 02:10:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA27007; Sat, 2 Sep 1995 02:07:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA27000; Sat, 2 Sep 1995 02:00:02 +1000 Received: from sabre-wulf.nvg.unit.no by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02745; Sat, 2 Sep 1995 01:59:56 +1000 (from agulbra@nvg.unit.no) Received: from romeo-klive.nvg.unit.no (agulbra@romeo-klive.nvg.unit.no [129.241.161.24]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id RAA17458 for ; Fri, 1 Sep 1995 17:59:52 +0200 Received: by romeo-klive.nvg.unit.no (smallmail v1.18); Fri, 1 Sep 1995 17:59:49 +0200 Date: Fri, 1 Sep 1995 17:59:49 +0200 Message-Id: <29559.4435.809971189@romeo-klive.nvg.unit.no> From: Arnt Gulbrandsen Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Precedence: bulk In article Sanjay Kapur writes: >Not in this earth, maybe in a mathematicians dream, but I would never >want to live in a world ruled by mathematicians. Mathematics is a >precise art, politics is an art of compromise where nothing is ever precise. This is not a matter of ruling the world. It is a matter of routing. Ruling the world requires compromises, but routing packets requires rigorous analysis and strict, efficient execution. --Arnt From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 02:13:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03244; Sat, 2 Sep 1995 02:13:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA27045; Sat, 2 Sep 1995 02:11:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA27003; Sat, 2 Sep 1995 02:00:34 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02775; Sat, 2 Sep 1995 02:00:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12276; Fri, 1 Sep 95 12:00:27 -0400 Date: Fri, 1 Sep 95 12:00:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011600.AA12276@ginger.lcs.mit.edu> To: mohta@necom830.cc.titech.ac.jp, tli@cisco.com Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, mn@ios.com Precedence: bulk From: Masataka Ohta > The key question here is the topological distance between the connection > points. If the connection points are not wildly diverse, then it's > possible to absorb the multihomed sites by aggregation at some point. If the two providers have the same route to the backbone, that's an uninteresting multihoming. Both of them will loss connection with a single fault. This seems highly unlikely to me. I can't see two providers sharing a single link to the rest of the network. Even if each has their own link to a single backbone provider, that is still redundancy. Whether or not a single failure will knock out service to the user depends on what addressing structure you have, how the providers are connected (if at all), and how the routing is configured. I can think of configurations which will not keep working, but I imagine an intelligent design would avoid them. If the two provider prefixes are aggregated at some level, partitioning within that level will create a routing blackhole No, no more than partitioning of any aggregate has to create a black hole, depending on how the routing scopes are set. You're right, if the scopes are set too small, partitions can cause black holes, and adjusting the scopes dynamically is probably not in the cards (at least yet, although in the future...) However, partition repair is one of the tougher problems in routign.... If the _local_ providers are connected to the same global backbone, I'm afraind cisco is wasting money for meaningless multihoming. Why? One local provider (or Cisco's link to it) can fail, and they will be OK, no? Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 02:30:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04100; Sat, 2 Sep 1995 02:30:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA27092; Sat, 2 Sep 1995 02:27:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA27041; Sat, 2 Sep 1995 02:11:55 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03188; Sat, 2 Sep 1995 02:11:51 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.34] (dial-cup2-29.iway.aimnet.com [204.118.88.59]) by aimnet.com (8.6.12/8.6.12) with SMTP id JAA11239; Fri, 1 Sep 1995 09:10:27 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Sep 1995 09:11:31 -0700 To: "Michael F. Nittmann" From: Dave Crocker Subject: Re: casting your multi-homing/provider-changing vote Cc: Sanjay Kapur , "Dave O'Leary" , big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu, inet-access@earth.com Precedence: bulk At 5:42 AM 9/1/95, Michael F. Nittmann wrote: >an ISO standards organisation, and there are means to object to this on a Michael, Sorry but the IETF is not part of ISO. There is a very loose, cooperative agreement between ISOC (on behalf of the IETF) and ISO but there is no organizational affiliation at all. The IETF is quite independent of any other organization. d/ ps. for those interested in a summary of the IETF structure and process, please look at the article I had in ACM's StandardsView. A copy is at www.isoc.com. -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 02:32:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04146; Sat, 2 Sep 1995 02:32:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA27116; Sat, 2 Sep 1995 02:30:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA27047; Sat, 2 Sep 1995 02:12:32 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03201; Sat, 2 Sep 1995 02:12:30 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.34] (dial-cup2-29.iway.aimnet.com [204.118.88.59]) by aimnet.com (8.6.12/8.6.12) with SMTP id JAA11293; Fri, 1 Sep 1995 09:11:16 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Sep 1995 09:12:20 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: casting your multi-homing/provider-changing vote Cc: root@kbs.netusa.net, big-internet@munnari.OZ.AU, doleary@cisco.com, iap@vma.cc.nd.edu, inet-access@earth.com, jnc@ginger.lcs.mit.edu Precedence: bulk At 7:20 AM 9/1/95, Noel Chiappa wrote: > From: Sanjay Kapur > The above description is that of a monopoly. Is the CIDR addressing >Oh great, another person whose intellectual acuity is so limited the only For the benefit of those not experienced in the ways of the IETF, I'll note that there are many things that make the success of the IETF standards process quite remarkable. One of them is that personal abuse by those in opposition to one's views is astonishingly common. The second is that some of the long-time IETF participants find it difficult to offer responses in any other tone. Anyhow for those who are the recipients of such abuse, please don't take it personally and definitely don't be intimidated, it's just the way some of us are. Oh, and in case it isn't obvious, yes, I'm one of them too. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 02:35:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04257; Sat, 2 Sep 1995 02:35:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA27136; Sat, 2 Sep 1995 02:34:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA27062; Sat, 2 Sep 1995 02:13:57 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03234; Sat, 2 Sep 1995 02:13:50 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.34] (dial-cup2-29.iway.aimnet.com [204.118.88.59]) by aimnet.com (8.6.12/8.6.12) with SMTP id JAA11366; Fri, 1 Sep 1995 09:12:31 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 1 Sep 1995 09:13:34 -0700 To: Tony Li From: Dave Crocker Subject: Re: Multihoming Cc: mn@ios.com, big-internet@munnari.OZ.AU Precedence: bulk Tony, At 10:38 PM 8/31/95, Tony Li wrote: >Just to be specific, we're talking large scale geographic diversity. >Not just the next provider over. we probably should try to seek some consistency for the discussion, rather than changing criteria in mid stream. you stated that you had seen no evidence of a need for much multi-homing. I asked for folks to respond if they needed it. I made the query generic. You are now trying to constrain the 'legitimate' responses to a specific type of multi-homing. since there are no documented details for the support of multi-homing as you claim and there are no stated policies to move in the direction of support of that type of multi-homing and there is no analysis of the use of current cidr for that purpose, it is perhaps a tad premature to claim that an entire class of multi-homing requiremens is inapplicable to the current discussion. In other words, Tony, it's just fine that you personally believe a large class of multi-homing requirements can be handled by current cidr but it is not established that this is a correct assessment. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 02:39:30 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04465; Sat, 2 Sep 1995 02:39:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA27162; Sat, 2 Sep 1995 02:37:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA27064; Sat, 2 Sep 1995 02:13:58 +1000 Received: from pern.cc.purdue.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03235; Sat, 2 Sep 1995 02:13:50 +1000 (from smb@pern.cc.purdue.edu) Received: from localhost (localhost [127.0.0.1]) by pern.cc.purdue.edu (8.6.12/8.6.12) with ESMTP id LAA23736; Fri, 1 Sep 1995 11:13:39 -0500 Message-Id: <199509011613.LAA23736@pern.cc.purdue.edu> To: big-internet@munnari.OZ.AU Cc: "Scott M. Ballew" Subject: Re: Discussing encap/mapping proposal Date: Fri, 01 Sep 1995 11:13:39 -0500 From: "Scott M. Ballew" Precedence: bulk I sent this to Noel, and he commented back to me on some of this and requested that I send it to the Big-I list after a quick once-through with his comments in mind. So, here goes. Noel sent a message containing a sketch of a proof that provider-based addressing resulted in less routing overhead than non-provider based. This is what I said to Noel (with a few minor clarifications caused by his comments to me): Ok, I have read it, and I think I understand what you are saying (and I even think I _believe_ it, even if I don't _like_ it.) But I do think you are missing an important side effect of provider-based addresses that bears some consideration in the tradeoffs. In fact, I haven't seen anyone even mention this in this thing that passes for a discussion. :-) Granted, I may have missed it, or it may have been on another list that I don't subscribe to ("please, sir, can I have some more" email?) The side effect I see is this: Consider your described site X connected to providers P1 and P2, both connected to big provider A. As you point out, they may have one of three provider-based addresses, depending on which provider you choose as the basis. The are A.X, A.P1.X, and A.P2.X. A.X is uninteresting because it does not exhibit this side effect within provider A. Assume that A.P1.X is the assigned prefix. Routing optimality is not the goal of site X, rather redundant connectivity is (probably more real world, anyway). Ok, clearly provider P1 must maintain a specific route for A.P1.X within P1, or it could not reach X. X will also be advertising A.P1.X to provider P2, and it will need to maintain the specific route within some portion of P2, or X will derive no benefit from its connection to P2. If we look at what the providers P? are advertising to A, there are effective 3 useful cases. The first of these is that P? are both advertising the specific prefix A.P1.X, in addition to their aggregated prefixes A.P?. This case is uninteresting to this discussion because if A accepts the more specific prefix, then the X's prefix might as well be A.X. If it does not, then the advertisements are redundant and unnecessary and this case degenerates into the third case. Case 2 is that P2 advertises the more specific route A.P1.X, along with its own aggregate prefix A.P2 to A, who accepts both (if it doesn't, this is the same as case 3). P1 advertises only its aggregate prefix A.P1 to A. In this case, the primary inbound path from U (the universe) and all of A except P1 is via P2. If the link from P2 to X fails, the routing advertisement of A.P1.X ages, and A fails over to the link through P1. Thus, X gets the redundant connection they thought they wanted. Case 3 is that P? advertise only their aggregate prefixes to A. This results in the least routing overhead (according to my understanding of your message), so is the desired state from a routing overhead point of view. In this case, traffic for site X coming from outside A, or from anywhere in A not part of P? will traverse P1, since no more specific information is available. However, if the link from P1 to site X is down, A is unable to reroute the traffic for site X via P2, since it has no more specific information. Thus, site X has not gotten the redundancy they (in error) thought they were paying for. Noel said that he alluded to this case (and, in fact, does) but missed the implication that if the P1 link to site X fails, then "the site is screwed" (Noel's words. :-) It seems to me that this side-effect needs to be clearly understood by site X, and providers P? and A, so that everyone understands what exactly X is getting, yet no one is even talking about this. Scott M. Ballew Purdue Data Network Purdue University From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 03:10:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05461; Sat, 2 Sep 1995 03:10:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA27222; Sat, 2 Sep 1995 03:07:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA27207; Sat, 2 Sep 1995 02:56:17 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05100; Sat, 2 Sep 1995 02:55:51 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12431; Fri, 1 Sep 95 12:55:43 -0400 Date: Fri, 1 Sep 95 12:55:43 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011655.AA12431@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU, doleary@cisco.com, iap@vma.cc.nd.edu, inet-access@earth.com, jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Precedence: bulk From: Dave Crocker One of them is that personal abuse by those in opposition to one's views is astonishingly common. The second is that some of the long-time IETF participants find it difficult to offer responses in any other tone. If someone sends in a technical submission, it's usually easy to respond to it technically (except those people who persist in sending in submissions of form "2+2=5", of course; after a number of patient explanations which don't seem to "take", there aren't many options left). If someone sends in a submission consisting of vague theorizing about vast conspiracies, I'm not really sure what response you think will do any good. The rest of us would like to have a useful, productive, technical, conversation, if you don't mind. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 03:13:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05636; Sat, 2 Sep 1995 03:13:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA27275; Sat, 2 Sep 1995 03:11:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA27212; Sat, 2 Sep 1995 03:02:23 +1000 Received: from dixon.delong.sj.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05293; Sat, 2 Sep 1995 03:02:18 +1000 (from owen@DeLong.SJ.CA.US) Received: by dixon.DeLong.SJ.CA.US (8.6.12/SMI-4.1) id KAA07203; Fri, 1 Sep 1995 10:05:02 -0700 Date: Fri, 1 Sep 1995 10:05:02 -0700 From: owen@DeLong.SJ.CA.US (Owen DeLong) Message-Id: <199509011705.KAA07203@dixon.DeLong.SJ.CA.US> To: dcrocker@brandenburg.com Subject: Re: Do you need multi-homing? (was: casting your...vote) Cc: big-internet@munnari.OZ.AU Precedence: bulk I just did a reply to the message. I got it from inet-access, which has this annoying habbit of changing the reply-to header to reflect the !*&#&@ list. (It's deliberate, and the owner doesn't want to change it... "PINE works the way I want when it's configured this way, so I'm not changing it.") Owen > At 10:23 PM 8/31/95, Owen DeLong wrote: > >Any provider that hopes to provide any rational level of reliability > >MUST multi-home. To deny this is absurd. > > Owen, thanks for your note but it went to inet-access. It needs to > go to Big-Internet@munnari.OZ.AU. I had thought that the previous round of > responses was sufficient, but apparently the cidrd wg chair missed them, so > it would help to make sure the responses go to the list he is using for > this thread of discussion. > > (My previous note had one of the most interesting 'semantic' typos > I've ever made, since it has 'interest' instead of 'internet' in the > address string. sorry.) > > d/ > > -------------------- > Dave Crocker +1 408 246 8253 > Brandenburg Consulting fax: +1 408 249 6205 > 675 Spruce Dr. page: +1 408 581 1174 > Sunnyvale, CA 94086 USA dcrocker@brandenburg.com > > > From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 03:15:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05727; Sat, 2 Sep 1995 03:15:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA27297; Sat, 2 Sep 1995 03:13:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA27216; Sat, 2 Sep 1995 03:07:15 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05402; Sat, 2 Sep 1995 03:07:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12487; Fri, 1 Sep 95 13:07:08 -0400 Date: Fri, 1 Sep 95 13:07:08 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011707.AA12487@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, tli@cisco.com Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, mn@ios.com Precedence: bulk From: Dave Crocker > Just to be specific, we're talking large scale geographic diversity. > Not just the next provider over. we probably should try to seek some consistency for the discussion, rather than changing criteria in mid stream. Our understanding of what's going on technically with multihoming is increasing during the course of this debate. As a result, we now see more textured statements of the problem. The routing implications of widely-spaced multi-homing are quantitively different from those of narrowly-spaced. Hence Tony's comment. You are now trying to constrain the 'legitimate' responses to a specific type of multi-homing. To those which cause larger impact on the routing, yes, since those are the ones we are interested in, those being the ones which are harder to handle. since there are no documented details for the support of multi-homing as you claim I don't think there are *any* proposals which give what I would call an extensive and realistic discussion of multi-homing support. there is no analysis of the use of current cidr for that purpose Perhaps the CIDR documents need a better one, I could agree there. it is perhaps a tad premature to claim that an entire class of multi-homing requiremens is inapplicable to the current discussion. We're ignoring them not because we don't plan on supporting them, but because they aren't difficult to support; we're focussing in on the tough cases. you personally believe a large class of multi-homing requirements can be handled by current cidr but it is not established that this is a correct assessment. It seems perfectly obvious to me. Multihoming with a limited scope has routing overhead implications which are also limited. Case closed. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 03:31:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06304; Sat, 2 Sep 1995 03:31:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA27341; Sat, 2 Sep 1995 03:28:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA27335; Sat, 2 Sep 1995 03:26:14 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06138; Sat, 2 Sep 1995 03:26:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12523; Fri, 1 Sep 95 13:25:59 -0400 Date: Fri, 1 Sep 95 13:25:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011725.AA12523@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, smb@pern.cc.purdue.edu Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "Scott M. Ballew" I do think you are missing an important side effect of provider-based addresses that bears some consideration Yes, I skipped right over that facet. That's what I get for writing long replies when I'm 53% asleep... The first of these is that P? are both advertising the specific prefix A.P1.X, in addition to their aggregated prefixes A.P?. Ahh, right, I missed this as well (minor bug!): P1 has to advertise A.P1.X as well as A.P1, into all places where its scope for A.P1 advertisements overlaps P2's advertisement for A.P1.X, otherwise traffic will always take the more specific (longest match) route, through P2, even if the P1 route is better. (I keep forgetting that blasted longest-match stuff...) This blows a bit of my analysis, in that the only way to achieve lower routing overhead inside A, when using a provider-based form like A.P1.X, is to limit the scope of the alternate advertisement of X from P2, to areas where the P1 path is not optimal. Of course, if you do this, if the P1 link fails, you're sunk, unless you (at that point) increase the scope back. (This issue of needing dynamic scopes, which respond to topology changes, to get maximally efficient routing with minimal routign overhead, is fascinating. Push the dirt under the carper, it comes up somewhere else... I have to go think about this for a while. Interesting.) Case 2 is that P2 advertises the more specific route A.P1.X, along with its own aggregate prefix A.P2 to A ... In this case, the primary inbound path from U (the universe) and all of A except P1 is via P2. In other words, here P1 is not advertising A.P1.X separately. Case 3 is that P? advertise only their aggregate prefixes to A. This results in the least routing overhead ... so is the desired state from a routing overhead point of view. Yes, but recall that I also said that in general, to be useful, multihoming results in more routing overhead... So, the fact that this results in no extra routing overhead ought to be a red flag to what's coming... if the link from P1 to site X is down, A is unable to reroute the traffic for site X via P2, since it has no more specific information. Thus, site X has not gotten the redundancy they (in error) thought they were paying for. Yes. I totally missed this. Thanks for finding it! It seems to me that this side-effect needs to be clearly understood by site X, and providers P? and A, so that everyone understands what exactly X is getting, yet no one is even talking about this. So, in fact, we're back to what my first impression of some days ago, that the routing overhead costs inside A, of using A.P1.X, and A.X, to get the same operational effects, are exactly the same. Outside A it's a different story. I believe that this analysis (from the original message) is still correct - does anyone see something I missed? the case where we use an address of the form A.P1.X, and advertise only A.P? outside A. Again, this is a case which is *not possible* with the A.X form. There is some part of the network outside A for which the best path to X is through A.P1; traffic from here will take the best entry router [to A, with respect to X] anyway. However, for traffic which was best served by using X's connection to P2, it will wind up at a non-optimal entry router. Note, however, that there is zero extra routing overhead outside A to achieve these results. Note that this is still probably better, on average than what you will get with *no* advertisements of A.* outside A; there, incoming traffic will pick an entry router effectively at random, so some percentage will end up at non-optimal entry routers anyway. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 03:50:30 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07045; Sat, 2 Sep 1995 03:50:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA27413; Sat, 2 Sep 1995 03:47:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA27365; Sat, 2 Sep 1995 03:37:59 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06583; Sat, 2 Sep 1995 03:37:55 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id KAA26666; Fri, 1 Sep 1995 10:37:41 -0700 From: Dave Siegel Message-Id: <199509011737.KAA26666@seagull.rtd.com> Subject: Re: casting your multi-homing/provider-changing vote To: inet-access@earth.com Date: Fri, 1 Sep 1995 10:37:41 -0700 (MST) Cc: doleary@cisco.com, big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu In-Reply-To: from "Dave Crocker" at Aug 31, 95 06:34:33 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1095 Precedence: bulk > Multi-homing support is provided by taking the network number > within one provider's block and advertising out another provider's link. > As such it does not fit within their CIDR block. Hence, each advertisement > of a multi-homed net which goes out additional links is an exception in the > routing table. Any large-scale use of this mechanism completely defeats > the purpose of CIDR. It allows no aggregation. Not true. If the ISP is aggregating his blocks, and let's say he's got a 32 block, there will only 1 new network announcement on the net. If the NSP with the larger CIDR block uses the shiny new unsuppress statement, they can even let the prefix originate from the ISP, and thereby facilitate better inbound loadbalancing for their client (which, as it stands, pretty much every other NSP will prefer the more specific announcement. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 03:54:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07213; Sat, 2 Sep 1995 03:54:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA27434; Sat, 2 Sep 1995 03:52:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA27368; Sat, 2 Sep 1995 03:38:36 +1000 Received: from gp.magick.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06594; Sat, 2 Sep 1995 03:38:26 +1000 (from dhollis@gp.magick.net) Received: by gp.magick.net (Linux Smail3.1.29.1 #3) id m0soa2o-000xB0C; Fri, 1 Sep 95 10:38 PDT Message-Id: From: dhollis@gp.magick.net (Daniel Hollis) Subject: Multihoming and CIDR To: big-internet@munnari.OZ.AU Date: Fri, 1 Sep 1995 10:38:22 -0700 (PDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1363 Precedence: bulk Greetings, I just thought I'd put my $0.02 (USD) in. We have been having *serious* reliability problems with our upstream feed, SprintNet. We are losing business because of these problems. As a result we are going to become multihomed. Most other providers in the area (3 out of 4) are also becoming multihomed for the same reason. I would ask that the engineering task force *not* make a decision that would cripple an ISP's ability to become multihomed. Any ISP worth its beans these days realizes that in order to provide a reasonable level of stability one _must_ be multihomed. To cripple an ISP's ability to become multihomed is to cripple the very infrastructure of the internet. Please do not be so shortsighted by introducing a "solution" that creates more problems that it solves. To make an analogy: "640k ought to be enough for anyone" - Bill Gates, 1985 Please don't pull a Bill Gates. -Dan ---- ------------------------------------------------------------------------------ Dan Hollis | Seiyuu Daisuki! |"Ranko-chan, ii oyome-san MAGICK.NET System Administrator | Orikasa Ai | ni nareru wa yo" - http://www.magick.net/ | Yokoyama Chisa | Saotome Nodoka dhollis@magick.net | ("(^_^)") | ------------------------------------------------------------------------------ From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 03:57:06 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07295; Sat, 2 Sep 1995 03:57:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA27458; Sat, 2 Sep 1995 03:55:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA27343; Sat, 2 Sep 1995 03:29:05 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06237; Sat, 2 Sep 1995 03:28:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12558; Fri, 1 Sep 95 13:28:25 -0400 Date: Fri, 1 Sep 95 13:28:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011728.AA12558@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: casting your multi-homing/provider-changing vote Precedence: bulk From: "Michael F. Nittmann" it clearly contains matter that rules out competition, and puts free enterprise decisions as to which provider to chose at an unacceptable high cost. It is certainly the case that switching providers is not painless. That doesn't mean it's impossible. Whether or not the pain is "acceptable" is a matter of opinion. What is *not* a matter of opinion is the cost, in routing overhead, of various addressing schemes; that is *not* anything we can change with a wand, political, magic, or otherwise. Give me an addressing scheme, and I can tell you what the routing overhead of it will inevitably be. Two points. First, and less important, is that it's not a zero-pain process now; you have to get a new circuit (assuming you have continuous connectivity), etc, etc. Second, and more importantly, the necessity of changing addresses is caused by two forces over which we have little control; i) the growth of the Internet, and ii) the time to design/document/implement/deploy changes. We have a problem, and the only near-term tool available to deal with it is CIDR, and its supporting routing protocols, etc such as BGP-4. As a *practical* matter, we have three choices: i) stop the growth of the Internet (until some mapping technology which converts from IPv4 addresses to new rotuign-names, which can change at will, is available), ii) fragment the Internet, or iii) change addresses. Take your pick. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 03:59:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07361; Sat, 2 Sep 1995 03:59:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA27512; Sat, 2 Sep 1995 03:57:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA27403; Sat, 2 Sep 1995 03:44:59 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06895; Sat, 2 Sep 1995 03:44:54 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id KAA14212; Fri, 1 Sep 1995 10:52:02 -0700 Date: Fri, 1 Sep 1995 10:51:59 -0700 (PDT) From: Michael Dillon To: big-internet@munnari.OZ.AU Subject: Re: Do you need multi-homing? (was: casting your...vote) (fwd) Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk ---------- Forwarded message ---------- Date: Thu, 31 Aug 1995 22:23:49 -0700 From: Owen DeLong To: inet-access@earth.com Subject: Re: Do you need multi-homing? (was: casting your...vote) Any provider that hopes to provide any rational level of reliability MUST multi-home. To deny this is absurd. Owen > At 4:27 PM 8/31/95, Dave O'Leary wrote: > >I believe that this mis-characterizes the situation. I do not believe > > > You might want to subscribe to big-interest-request@munnari.OZ.AU > > and send (or re-send) your comments to the list. (I'll assume that you can > > >> Honest, folks. If you care about being able to change transit > >> providers and/or you care about being able to do multi-homing comfortably, > > Let's keep the current issue brief and focussed: The chair of the > cidr working group claimed to have seen no evidence that providers expect > to be multi-homed and there have been some statistics published indicating > only a limited need for this. > > I am suggesting that now is a good time to voice your opinions and > your intent, so that there is some clear and undeniable record of the need > to support this connection mode adequately. > > We can debate the details of 'adequately' later. For now, the > simple fact of the need is being denied. > > d/ > > -------------------- > Dave Crocker +1 408 246 8253 > Brandenburg Consulting fax: +1 408 249 6205 > 675 Spruce Dr. page: +1 408 581 1174 > Sunnyvale, CA 94086 USA dcrocker@brandenburg.com > > > From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 04:50:36 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09410; Sat, 2 Sep 1995 04:50:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA27665; Sat, 2 Sep 1995 04:47:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA27658; Sat, 2 Sep 1995 04:42:35 +1000 Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09137; Sat, 2 Sep 1995 04:42:24 +1000 (from barney@databus.databus.com) Date: Fri, 1 Sep 95 14:42 EDT Message-Id: <9509011442.AA20794@databus.databus.com> From: Barney Wolff To: big-internet@munnari.OZ.AU Subject: Re: Multihoming Content-Length: 747 Content-Type: text Precedence: bulk > Date: Fri, 1 Sep 95 13:07:08 -0400 > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > > It seems perfectly obvious to me. Multihoming with a limited scope has routing > overhead implications which are also limited. Case closed. If this is not a tautology I'm not sure I agree. If I run a second link to a second national provider from my single location, at least one of those providers will have to advertise a specific route to me everywhere they advertise routes, up to continental scale or higher. After all, isn't that what I'm paying them for? So it looks limited from my perspective, because the links are only a couple of miles each, but the routing is effectively unlimited in the practical sense. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 04:56:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09539; Sat, 2 Sep 1995 04:56:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA27687; Sat, 2 Sep 1995 04:54:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA27619; Sat, 2 Sep 1995 04:31:52 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08582; Sat, 2 Sep 1995 04:30:45 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id OAA00944; Fri, 1 Sep 1995 14:32:43 -0400 Date: Fri, 1 Sep 1995 14:32:41 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: casting your multi-homing/provider-changing vote To: Dave Crocker Cc: big-internet@munnari.OZ.AU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Seen and corrected in my picture. thanks Mike On Fri, 1 Sep 1995, Dave Crocker wrote: > At 5:42 AM 9/1/95, Michael F. Nittmann wrote: > >an ISO standards organisation, and there are means to object to this on a > > Michael, Sorry but the IETF is not part of ISO. > > There is a very loose, cooperative agreement between ISOC (on > behalf of the IETF) and ISO but there is no organizational affiliation at > all. > > The IETF is quite independent of any other organization. > > d/ > > ps. for those interested in a summary of the IETF structure and process, > please look at the article I had in ACM's StandardsView. A copy is at > www.isoc.com. > > -------------------- > Dave Crocker +1 408 246 8253 > Brandenburg Consulting fax: +1 408 249 6205 > 675 Spruce Dr. page: +1 408 581 1174 > Sunnyvale, CA 94086 USA dcrocker@brandenburg.com > > > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 04:59:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09732; Sat, 2 Sep 1995 04:59:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA27740; Sat, 2 Sep 1995 04:58:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA27622; Sat, 2 Sep 1995 04:36:12 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB08759; Sat, 2 Sep 1995 04:35:00 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id OAA00951; Fri, 1 Sep 1995 14:37:14 -0400 Date: Fri, 1 Sep 1995 14:37:13 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: casting your multi-homing/provider-changing vote To: big-internet@munnari.OZ.AU In-Reply-To: <9509011651.AA12413@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk no, what I mean is the decision of a provider with hundreds of customers. What will happen: if the provider choses to change his upline provider, his customers must renumber ... or join with the upline provider. got me? that's the unacceptable limitation of free enterprise coming in. Stay and accept whatever happens, or change provider (as an isp) and lose customers and revenue. Mike On Fri, 1 Sep 1995, Noel Chiappa wrote: > From: "Michael F. Nittmann" > > it clearly contains matter that rules out competition, and puts free > enterprise decisions as to which provider to chose at an unacceptable high > cost. > > It is certainly the case that switching providers is not painless. That > doesn't mean it's impossible. Whether or not the pain is "acceptable" is a > matter of opinion. What is *not* a matter of opinion is the cost, in routing > overhead, of various addressing schemes; that is *not* anything we can change > with a wand, political, magic, or otherwise. Give me an addressing scheme, and > I can tell you what the routing overhead of it will inevitably be. > > Two points. First, and less important, is that it's not a zero-pain process > now; you have to get a new circuit (assuming you have continuous > connectivity), etc, etc. > > Second, and more importantly, the necessity of changing addresses is caused by > two forces over which we have little control; i) the growth of the Internet, > and ii) the time to design/document/implement/deploy changes. We have a > problem, and the only near-term tool available to deal with it is CIDR, and its > supporting routing protocols, etc such as BGP-4. > > As a *practical* matter, we have three choices: i) stop the growth of the > Internet (until some mapping technology which converts from IPv4 addresses to > new rotuign-names, which can change at will, is available), ii) fragment the > Internet, or iii) change addresses. Take your pick. > > Noel > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 05:31:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10841; Sat, 2 Sep 1995 05:31:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA27817; Sat, 2 Sep 1995 05:27:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA27811; Sat, 2 Sep 1995 05:25:34 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10557; Sat, 2 Sep 1995 05:25:25 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id PAA14722; Fri, 1 Sep 1995 15:25:09 -0400 Date: Fri, 1 Sep 1995 15:25:08 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: <9509010420.AA10629@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Noel Chiappa wrote: > > Oh, goody, legislatures doing network engineering. I'm waiting for them to > pass a law saying you have to be able to take your routing-name with you when > you go. What's next, regulating the tides? Making fun of this issue will not stop regulators from stepping in once the masses start getting taken to the cleaners by the monopolistic "transit providers" and lawyers start smelling money. > > We've already had this argument, five times. A mapping system (like the > 800/local portabilty system) would be nice, but the network is growing so > fast we don't currently have the time to do it, if we want to keep the > network i) growing, and ii) working. Maybe some day. > The reason this argument has been visited so many times is because many people perceive it to be of overriding importance and pleading lack of time is not the answer when the result is to give a very few totally unregulated organizations so much power. If it is not designed into the system, it will be much more painful "some day". > Noel > Sanjay Kapur Kapur Business Systems, Inc. n't 2x, isn't hard). That way, the larger scope of advertisements needed for multi-homing can be less than the entire Internet. Please do not be so shortsighted by introducing a "solution" that creates more problems that it solves. The thing is, you can legitimately issue that warning to a number of different proposals... Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 05:48:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11586; Sat, 2 Sep 1995 05:48:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA27903; Sat, 2 Sep 1995 05:47:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA27893; Sat, 2 Sep 1995 05:41:04 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11374; Sat, 2 Sep 1995 05:40:57 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id PAA14804; Fri, 1 Sep 1995 15:40:40 -0400 Date: Fri, 1 Sep 1995 15:40:39 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Arnt Gulbrandsen Cc: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: <29559.4435.809971189@romeo-klive.nvg.unit.no> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Arnt Gulbrandsen wrote: > > This is not a matter of ruling the world. It is a matter of > routing. Ruling the world requires compromises, but routing packets > requires rigorous analysis and strict, efficient execution. > > --Arnt > I have to strongly disagree with you. Why is high efficiency so important? I would compromise on theoretical efficiency any day if practical efficiency is improved as a result. In the new information based society whoever controls the information spigot rules the world. Unregulated monopolies are by nature very ineffecient because the people running them are not interested in providing good service and are not interested in making sure the customer is happy becuase the customer has no choice. The proposed IP numbering scheme would make transit providers effectively monopolies. What good is high theoretical efficiency if you have to pay 10 times more to a transit provider than you would pay in a system with 10% less efficiency? I am talking markets, you are talking mathematics. We should be at a compromise and then we are talking politics :-) Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 05:49:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11672; Sat, 2 Sep 1995 05:49:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA27923; Sat, 2 Sep 1995 05:49:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA27896; Sat, 2 Sep 1995 05:41:27 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11386; Sat, 2 Sep 1995 05:41:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13115; Fri, 1 Sep 95 15:41:20 -0400 Date: Fri, 1 Sep 95 15:41:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011941.AA13115@ginger.lcs.mit.edu> To: barney@databus.com, big-internet@munnari.OZ.AU Subject: Re: Multihoming Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Barney Wolff > Multihoming with a limited scope has routing overhead implications which > are also limited. If I run a second link to a second national provider from my single location, at least one of those providers will have to advertise a specific route to me everywhere they advertise routes, up to continental scale or higher. At least, to a large enough scope that if either link fails, traffic that makes it into that scope will then make it to the remaining working link, yes. After all, isn't that what I'm paying them for? Yes, but providers may start to charge for advertising routes, where the charge is based on what scope it has to be advertised over (since the larger the scope, the more real resources it takes). So it looks limited from my perspective, because the links are only a couple of miles each, but the routing is effectively unlimited in the practical sense. When I said "multihoming with limited scope", I mean topologically limited. I.e. if I take a map of the whole Internet, I can draw a circle that encloses your two connection points, and have that circle be a lot smaller than the map as a whole. (Well, actually, to be precise, pick an existing abstraction naming boundary which includes your two connection points, since that's what the routing is going to care about. That's because, as Scott Ballew has pointed out, to make multihoming *keep delivering packets* when a link fails, a specific route has to be advertised throughout the smallest enclosing naming scope which contains both (all) attachment points, irrespective of the form of the address. In more technical terms, the AAB of a multihomed entity has to be *at least* the ANB of the smallest common naming abstraction.) As for miles, etc, etc those are all irrelevant. The thing that *really* matter is the network topology, *not* geography. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 06:08:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12328; Sat, 2 Sep 1995 06:08:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA27980; Sat, 2 Sep 1995 06:07:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA27976; Sat, 2 Sep 1995 06:01:56 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12173; Sat, 2 Sep 1995 06:01:52 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13161; Fri, 1 Sep 95 16:01:44 -0400 Date: Fri, 1 Sep 95 16:01:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509012001.AA13161@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Sanjay Kapur Making fun of this issue will not stop regulators from stepping in once the masses start getting taken to the cleaners by the monopolistic "transit providers" and lawyers start smelling money. Realizing that those things are possibly going to happen (as I think we are all wary of) doesn't help solve the technical problems we have. They are probably going to do silly things no matter *what* we do. (E.g. Legislators here in the US have passed a law which attempts to stop the extinction of species, not thinking about the fact that nature has been making species extinct for billions of years...) If we have a choice between two technically plausible solutions, sure, let's pick the one that's less likely to get the legislators/lawyers/etc on our case. I'm not sure that we have that option here. The reason this argument has been visited so many times is because many people perceive it to be of overriding importance and pleading lack of time is not the answer Again, it doesn't matter how many people feel what; that will not produce solutions in zero time. Nobody has come up, over the past two months, with any solution that people agree is plausible for short-term usage, other than the one that is now on the shelf: CIDR, and it's consequent requirement for topology-based addresses. Note that there are a number of things we can do, with topology engineering, that will make life a little easier, that can be deployed in "reasonable" time; e.g. in a couple of months, such as exchange points. If people will stop trying to argue that we can't live with topology-based addresses for policy reasons, maybe we can get on with trying to ameliorate the impact of them. Again, the current situation is that we have three choices: i) stop the growth of the Internet, ii) fragment the Internet, or iii) use topology-based addresses. Take your pick. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 06:28:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13243; Sat, 2 Sep 1995 06:28:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA28055; Sat, 2 Sep 1995 06:27:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA27998; Sat, 2 Sep 1995 06:08:54 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12347; Sat, 2 Sep 1995 06:08:50 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id QAA15076; Fri, 1 Sep 1995 16:08:24 -0400 Date: Fri, 1 Sep 1995 16:08:23 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, doleary@cisco.com, iap@vma.cc.nd.edu, inet-access@earth.com Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: <9509011655.AA12431@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Noel Chiappa wrote: > If someone sends in a submission consisting of vague theorizing about vast > conspiracies, I'm not really sure what response you think will do any good. > The rest of us would like to have a useful, productive, technical, > conversation, if you don't mind. > > Noel > Before your discard "vague theories" of conspiracies, please look at why there is so much interest in providing competition in the telephone industry and what has spurred even Europe to abandon PTT monopolies. The discussion may be "technical" but, if the end result is that it requires unregulated monopolies, is it "useful" or "productive"? I am most interested in one detail: How can I become a "transit" provider and what are the qualifications for becoming a transit provider? One of the major advantages of the current IP scheme is that the above question has a very definite answer and is central to the current success of the Internet. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 06:29:39 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13267; Sat, 2 Sep 1995 06:29:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA28080; Sat, 2 Sep 1995 06:29:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA28005; Sat, 2 Sep 1995 06:09:28 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12362; Sat, 2 Sep 1995 06:09:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13194; Fri, 1 Sep 95 16:09:14 -0400 Date: Fri, 1 Sep 95 16:09:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509012009.AA13194@ginger.lcs.mit.edu> To: agulbra@nvg.unit.no, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Sanjay Kapur Why is high efficiency so important? "maximum" efficiency is not needed, obviously, but it has to be high enough that the overhead growth of the routing, as the network grows, is within the bounds of what the hardware can support. Also, most people do like their traffic to take fairly optimal routes, but that's a separate axis of "efficiency". I would compromise on theoretical efficiency any day if practical efficiency is improved as a result. If you meant by your statement that you're willing to pay a price to get some benefit, sure, that's what engineering is all about. The question is what benefits are possible, and at what price. What good is high theoretical efficiency if you have to pay 10 times more to a transit provider than you would pay in a system with 10% less efficiency? What good are portable addresses if the Internet as a whole ceases to work because of their use? Since the benefit is close to 0, the cost/benefit ratio is very high, no matter how low the cost. I am talking markets, you are talking mathematics. We should be at a compromise and then we are talking politics :-) Unfortunately, mathematics isn't good at compromise. It just is. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 06:31:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13319; Sat, 2 Sep 1995 06:31:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA28100; Sat, 2 Sep 1995 06:30:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA28051; Sat, 2 Sep 1995 06:25:40 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13107; Sat, 2 Sep 1995 06:25:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13277; Fri, 1 Sep 95 16:25:21 -0400 Date: Fri, 1 Sep 95 16:25:21 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509012025.AA13277@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mn@ios.com Subject: Re: casting your multi-homing/provider-changing vote Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "Michael F. Nittmann" what I mean is the decision of a provider with hundreds of customers. What will happen: if the provider choses to change his upline provider, his customers must renumber ... or join with the upline provider. This is indeed a problem. However, in strictly routing terms, there is no way around this. When you start moving chunks of the network around, the routing-names of the chunks that move will have have to change (unless the chunk is so big that it has a top-level name). Any other policy leads to heat-death of the routing. There are a number of reasons why the phone network doesn't have this problem. For one, routing in the phone network (as a whole) is not dynamic. (Individual carriers may route dynamically inside, but that's different.) I don't think the phone network could provide the dynamicity the Internet has, where we want traffic to automatically take a different path no matter what breaks. The reason there's almost always a dial-tone there when you pick up the phone is because their system-level components are engineered to be more reliable (using internal redundancy), not because of redundancy at all levels. The reasons for this difference in approach are obviously historial; the Internet was designed for a higher-massive-failure-rate environment (to put it delicately :-). One obvious solution, again, to this problem as well, is exchange points. I'm sure that when we start to explore them, we'll find some issues (since they have a great deal in common with geographic addressing, probably some of the same issues). Hopefully we will soon get to a point where everyone realizes that i) topology-based routing-names are necesssary if the routing is to scale, ii) we are currently stuck with a design which the addresses in packets are routing-names. At which point, we can all start focusing our energy on doing some engineering to make topology-based addresses a little less painful. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 06:48:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13912; Sat, 2 Sep 1995 06:48:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA28164; Sat, 2 Sep 1995 06:47:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA28157; Sat, 2 Sep 1995 06:40:35 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13660; Sat, 2 Sep 1995 06:40:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13494; Fri, 1 Sep 95 16:40:20 -0400 Date: Fri, 1 Sep 95 16:40:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509012040.AA13494@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk The proposed IP numbering scheme would make transit providers effectively monopolies. PS: Life is full of little "lock-ins" like the address leasing scheme. For instance, try buying a new car. If you decide, one month after you got it, that you don't like it and want to switch to a different maker, you're going to pay a stiff price for the privelege. However, nobody describes that as a "monopoly". Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 06:49:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13949; Sat, 2 Sep 1995 06:49:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA28188; Sat, 2 Sep 1995 06:49:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA28160; Sat, 2 Sep 1995 06:45:25 +1000 Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13857; Sat, 2 Sep 1995 06:45:19 +1000 (from barney@databus.databus.com) Date: Fri, 1 Sep 95 16:45 EDT Message-Id: <9509011645.AA21227@databus.databus.com> From: Barney Wolff To: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU Subject: Re: Multihoming Content-Length: 1790 Content-Type: text Precedence: bulk > Date: Fri, 1 Sep 95 15:41:20 -0400 > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > > So it looks limited from my perspective, because the links are only a > couple of miles each, but the routing is effectively unlimited in the > practical sense. > > When I said "multihoming with limited scope", I mean topologically limited. > I.e. if I take a map of the whole Internet, I can draw a circle that encloses > your two connection points, and have that circle be a lot smaller than the > map as a whole. > > (Well, actually, to be precise, pick an existing abstraction naming boundary > which includes your two connection points, since that's what the routing is > going to care about. That's because, as Scott Ballew has pointed out, to make > multihoming *keep delivering packets* when a link fails, a specific route has > to be advertised throughout the smallest enclosing naming scope which contains > both (all) attachment points, irrespective of the form of the address. In more > technical terms, the AAB of a multihomed entity has to be *at least* the ANB > of the smallest common naming abstraction.) Yes but - if my two providers are from {sprint,mci,alternet,psi,...} the AAB may be Earth - I don't see how it's smaller. It's certainly all of North America. It's not just the smallest enclosing scope that includes both attachment points, because the providers don't run their routing protocols that way - provider A will *not* notice that I'm no longer reachable thru provider B and automatically start advertising me in places it didn't before. De facto, it will have to advertise me in all places I sign up for - and it may well cost more to be world famous. It certainly should, if I'm not in that provider's cidr block. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 06:50:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13982; Sat, 2 Sep 1995 06:50:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA28210; Sat, 2 Sep 1995 06:50:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA28122; Sat, 2 Sep 1995 06:33:50 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13482; Sat, 2 Sep 1995 06:33:45 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id NAA14532; Fri, 1 Sep 1995 13:33:22 -0700 From: Dave Siegel Message-Id: <199509012033.NAA14532@seagull.rtd.com> Subject: Re: Discussing encap/mapping proposal To: root@kbs.netusa.net (Sanjay Kapur) Date: Fri, 1 Sep 1995 13:33:22 -0700 (MST) Cc: agulbra@nvg.unit.no, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 1, 95 03:40:39 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2299 Precedence: bulk > > This is not a matter of ruling the world. It is a matter of > > routing. Ruling the world requires compromises, but routing packets > > requires rigorous analysis and strict, efficient execution. > I have to strongly disagree with you. > > Why is high efficiency so important? > > I would compromise on theoretical efficiency any day if practical > efficiency is improved as a result. In the new information based > society whoever controls the information spigot rules the world. > > Unregulated monopolies are by nature very ineffecient because the > people running them are not interested in providing good service and are > not interested in making sure the customer is happy becuase the customer > has no choice. The proposed IP numbering scheme would make transit providers > effectively monopolies. You have to rememer that these recommendations are coming out of the technical departments, not the marketing departments. If the engineering problems in the Internet cannot be controlled at the top level, then what we tend to think of as the Internet will become slowly deteriorate until service at *all* levels, from all providers, becomes horrible. The technical people themselves have a very important task at hand. It is in their best interest that the Internet continues to function as well as possible, not just because their job is at stake, but most of these engineers have a great personal desire to see the Internet continue to grow, and function as well as it possibly can. > I am talking markets, you are talking mathematics. We should be at a > compromise and then we are talking politics :-) Well, most of us have heard all these arguments before. We're still in the decision and extrapolating progress at this time, and are trying to determine what future *required* policies might have to be. The end goal is for any Internet customer to have their packets delivered 24 hours a day. Certainly, this is most important from a marketing point of view, and the solution must be approached from a mathematical one. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 07:08:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14454; Sat, 2 Sep 1995 07:08:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA28247; Sat, 2 Sep 1995 07:07:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA28241; Sat, 2 Sep 1995 07:00:32 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14323; Sat, 2 Sep 1995 07:00:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13662; Fri, 1 Sep 95 17:00:18 -0400 Date: Fri, 1 Sep 95 17:00:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509012100.AA13662@ginger.lcs.mit.edu> To: barney@databus.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Multihoming Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Barney Wolff > to be precise, pick an existing abstraction naming boundary which > includes your two connection points ... to make multihoming *keep > delivering packets* when a link fails, a specific route has to be > advertised throughout the smallest enclosing naming scope which contains > both (all) attachment points ... In more technical terms, the AAB of a > multihomed entity has to be *at least* the ANB of the smallest common > naming abstraction.) Yes but - if my two providers are from {sprint,mci,alternet,psi,...} the AAB may be Earth - I don't see how it's smaller. It's certainly all of North America. Yup. It's not just the smallest enclosing scope that includes both attachment points, because the providers don't run their routing protocols that way Ah. Look at what I said again; I said the smallest *naming* scope that encloses both. Since the only naming scope that currently encloses both MCI and Sprint is the global one, it follows that if you multihome to MCI and Sprint, to make multihoming work your address must be adverised globally. provider A will *not* notice that I'm no longer reachable thru provider B and automatically start advertising me in places it didn't before. De facto, it will have to advertise me in all places I sign up for - and it may well cost more to be world famous. Yup. Which is one more reason local ISP's may prefer to band together into a cooperative exchange point; if there is a charge for advertising it, the overhead can be shared among all the members of the coop. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 07:28:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15220; Sat, 2 Sep 1995 07:28:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA28295; Sat, 2 Sep 1995 07:27:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA28278; Sat, 2 Sep 1995 07:18:45 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14714; Sat, 2 Sep 1995 07:18:30 +1000 (from kre@munnari.OZ.AU) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Fri, 01 Sep 1995 16:40:20 -0400." <9509012040.AA13494@ginger.lcs.mit.edu> Date: Sat, 02 Sep 1995 07:18:02 +1000 Message-Id: <14880.809990282@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Fri, 1 Sep 95 16:40:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9509012040.AA13494@ginger.lcs.mit.edu> try buying a new car. If you decide, one month after you got it, that you don't like it and want to switch to a different maker, you're going to pay a stiff price for the privelege. However, nobody describes that as a "monopoly". Come on Noel, lets's be a little reasonable in the analogies, this one isn't even close. It just might be if cars came in lots of different sizes (I mean wildly different sizes), and having bought one, you had to build a garage for that one, and in the process redesign and rebuild your house around the new garage, then switching to a different brand of car, would still be possible, but not be highly practicable -- then people would object. No-one here is claiming that having entered into an agreement with a provider to pay X amount for a connection for some period you should be able to decide you don't like it and simply switch somewhere else with no financial penalty - that's the equivalent of your car buying analogy. And while I'm here, some other oddments ... Date: Fri, 1 Sep 95 00:20:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509010420.AA10629@ginger.lcs.mit.edu> A mapping system (like the 800/local portabilty system) would be nice, but the network is growing so fast we don't currently have the time to do it, if we want to keep the network i) growing, and ii) working. Maybe some day. To go back to car analogies, this is equivalent to saying that we have too many cars on the roads, it would be nice to build new roads to handle them, but that takes so long that we can't get by with that (in the short term), so we will simply forget building new roads (Maybe some day), and instead install lots more traffic lights to make everyone go a lot slower, that way more cars will fit in the same road space (the ultimate being when they are all stopped). This just doesn't work - however late it seems were are now in making a decision, if we put it off we will simply dig ourselves further into a bigger example of the same mess we have now. We have to start planning a solution that works, and is acceptable to all - it may be that we will need short term measures to get us by until the real solution is ready, that is not an argument for putting off the solutions to some other undetermined time. Date: Fri, 1 Sep 95 09:55:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011355.AA11788@ginger.lcs.mit.edu> I think that the *only* way in which this whole situation will be brought under control is to cut the Gordian knot and charge for routing advertisements, on a sliding scale which takes into account the scope over which that advertisement has to be sent. I basically agree. I used to think that the only reason this wasn't being done was that none of the providers wanted to go first at something like thus (plus thatthey refuse to agree to any means of equalising costs amongst themselves). On reflection though I suspect that the more basic reason is that right now they can't deliver. They could charge OK, however $'s for many people is not the issue that really matters, they'd simply pay (any amount that wasn't basically the equivalent of a prohibition). That leaves the providers with lots of extra $'s OK, but apparently no good way to spend them to achieve the service that they're supposed to then be providing. That is, if there was any way now that simply by spending more $'s the core providers could make this problem go away, then that would be the solution to adopt. The cost, obviously, would be passed back to the end users, one way or another - perhaps a simple basic tarrif incrrease, or a charge for advertising routes, or something else, that doesn't matter, but it is something that almost all of the net would prefer. Date: Fri, 1 Sep 95 13:25:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509011725.AA12523@ginger.lcs.mit.edu> Outside A it's a different story. I believe that this analysis (from the original message) is still correct - does anyone see something I missed? No, outside A, I suspect you ahve it right. Scott Ballew destroyed your inside A analysis ("proof") before I had the chance... The problem here is that in today's internet, A == U, and outside A is irrelevant. The only way to change that would be to aggregate the big providers in much the same way as is being demanded of everyone below them (including renumbering, etc) - and that is something that no-one would really be happy with (none of the big providers, intermediate ones, small ones, or end users). At the minute, any real multi-homing, which means connecting to topologically widely dispersed providers, means spreading your route world wide, as there simply is no aggregation higher than the big providers, nor any rational way to draw circles that would make it a reasonable thing to do. This means, of course, that anyone who wants a stable number merely needs to connect to two (or more) of the major providers, directly or indirectly, then there is no point asking you to renumber for routing purposes, as your route will be advertised everywhere anyway, portable number, or provider dependant number. If some provider wants to filter your advertisment away, you simply buy a connection to them as well, then they can't. The effect of this, of course, is that routing stops scaling (yet again), and there is nothing at all in cidr to fix it. kre From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 07:48:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15816; Sat, 2 Sep 1995 07:48:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA28334; Sat, 2 Sep 1995 07:47:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA28328; Sat, 2 Sep 1995 07:44:05 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15624; Sat, 2 Sep 1995 07:43:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14040; Fri, 1 Sep 95 17:43:13 -0400 Date: Fri, 1 Sep 95 17:43:13 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509012143.AA14040@ginger.lcs.mit.edu> To: swb1@cornell.edu, wolf@instinet.com Subject: RE: Multihoming Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: wolf@instinet.com your thinking process in this case is somewhat stochastic. Welcome to Big-Internet. :-) If we let customers connect to us via the Internet (which I sometimes doubt will ever be ready for real business) Well, it was never designed to be. The amazing thing is not that the dog talks poorly... How many companies went out of business following the Illnios Bell fire where just one CO burned? Which shows some of the hazards with the phone network's approach to reliability... If the Internet can not support geographically diverse connectivity, to quote you, "...it's broken." ... Let's think about the users here. If I understand you, your bottom-line concern is reliability. Rather than tell the network designers how to provide that reliability, perhaps a better approach would be to say what you need, and then let's see what the best way is to provide it. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 08:28:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17437; Sat, 2 Sep 1995 08:28:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA28451; Sat, 2 Sep 1995 08:27:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA28421; Sat, 2 Sep 1995 08:19:37 +1000 Received: from Tetsuo.Communique.Net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17147; Sat, 2 Sep 1995 08:19:33 +1000 (from nectar@communique.net) Received: from tetsuo.communique.net (Tetsuo.Communique.Net [204.27.64.10]) by tetsuo.communique.net (8.6.12/8.6.12) with SMTP id RAA23120; Fri, 1 Sep 1995 17:19:17 -0500 Date: Fri, 1 Sep 1995 17:19:08 -0500 (CDT) From: Jacques Vidrine To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, dhollis@gp.magick.net, jnc@ginger.lcs.mit.edu Subject: Re: Multihoming and CIDR In-Reply-To: <9509011911.AA13049@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Noel Chiappa wrote: [snip] > What it looks to me like we are going to have to do is some combination of > more rational topology engineering, more thought-out addressing boundary > setting, and more careful routing info scope configuration. [snip] It may well be that I am just naive, but what is wrong with the provider-based addressing that CIDR seems to encourage? I think the answer to that is "CIDR requires -some- (a lot?) of renumbering". If renumbering were not an issue (i.e. if it were "easy" to renumber whole organizations), would CIDR not be a near-perfect solution in the global IPv4 Internet? Jacques Vidrine Communique, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 08:31:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17606; Sat, 2 Sep 1995 08:31:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA28473; Sat, 2 Sep 1995 08:29:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA28429; Sat, 2 Sep 1995 08:23:19 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17268; Sat, 2 Sep 1995 08:23:09 +1000 (from avg@sprint.net) Received: from titan.sprintlink.net by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04372 Sat, 2 Sep 1995 08:23:03 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id SAA01755; Fri, 1 Sep 1995 18:21:44 -0400 Date: Fri, 1 Sep 1995 18:21:44 -0400 From: Vadim Antonov Message-Id: <199509012221.SAA01755@titan.sprintlink.net> To: barney@databus.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Multihoming Precedence: bulk >Ah. Look at what I said again; I said the smallest *naming* scope that >encloses both. Since the only naming scope that currently encloses both MCI >and Sprint is the global one, it follows that if you multihome to MCI and >Sprint, to make multihoming work your address must be adverised globally. By my estimates, the total number of global prefixes in the current Internet topology can be reduced to about 200 if the "ideal" CIDR is implemented. However, the bulk of current routing tables is coming from small networks; and to make everybody to renumber is kind of hard, even if it requires pressing a button. Most people are simply ignorant of the issue, and as more and more people are getting connected the level of clueefulness is bound to drop even lower. Hence my current proposal making renumbering-on-the-fly the cornerstone of the architecture. --vadim From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 08:48:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18206; Sat, 2 Sep 1995 08:48:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA28543; Sat, 2 Sep 1995 08:47:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA28534; Sat, 2 Sep 1995 08:46:40 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18182; Sat, 2 Sep 1995 08:46:36 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id SAA15373; Fri, 1 Sep 1995 18:46:20 -0400 Date: Fri, 1 Sep 1995 18:46:20 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: <9509010409.AA10604@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > > > and mathematics beats politics every day of the week,... > > well, that's an interesting credo for living in this world. > > I believe some US state legislature once tried to legislate pi equal to > 22/7. Last time I looked, pi had not obliged. > > Noel > You are of course correct. Lawmakers are notoriously ignorant about technical issues. Do you really want to propose a scheme that will eventually lead to governmental regulation of the Internet? Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 08:49:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18233; Sat, 2 Sep 1995 08:49:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA28565; Sat, 2 Sep 1995 08:49:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA28537; Sat, 2 Sep 1995 08:47:52 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18191; Sat, 2 Sep 1995 08:47:49 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id PAA25161; Fri, 1 Sep 1995 15:47:40 -0700 From: Dave Siegel Message-Id: <199509012247.PAA25161@seagull.rtd.com> Subject: Re: casting your multi-homing/provider-changing vote To: root@kbs.netusa.net (Sanjay Kapur) Date: Fri, 1 Sep 1995 15:47:39 -0700 (MST) Cc: jnc@ginger.lcs.mit.edu, dcrocker@brandenburg.com, big-internet@munnari.OZ.AU, doleary@cisco.com, iap@vma.cc.nd.edu, inet-access@earth.com In-Reply-To: from "Sanjay Kapur" at Sep 1, 95 04:08:23 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1552 Precedence: bulk > I am most interested in one detail: How can I become a "transit" provider > and what are the qualifications for becoming a transit provider? If you have the money (DS3 backbones aren't cheap), the contacts (it helps to know people at the competition), and the technical competence (none of your competitors are interested in helping you break the Internet for them), those would be the most weighty of the qualifications. These are not particularly easy things to obtain. It's rather a good thing that not just anybody can set up a national backbone...much like not just everyone can throw in some fiber and start up their own long distance network. > One of the major advantages of the current IP scheme is that the above > question has a very definite answer and is central to the current success > of the Internet. Perhaps. Too many national providers will cause problems as well, not in terms of routes, since the number of end-users clients will probably proceed at only a slightly higher rate, but interconnects will overload (check the mae-east stats), too many peering sessions on a Cisco increases flap frequency, since you have less of a chance to dampen things, and too many interconnect points increases the total number of paths, which is a severe memory strain for NSP's at all interconnects. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 09:28:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19372; Sat, 2 Sep 1995 09:28:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA28627; Sat, 2 Sep 1995 09:27:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA28610; Sat, 2 Sep 1995 09:16:40 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18994; Sat, 2 Sep 1995 09:16:27 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id TAA15420; Fri, 1 Sep 1995 19:15:01 -0400 Date: Fri, 1 Sep 1995 19:15:01 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Tony Li Cc: wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU Subject: RE: Multihoming In-Reply-To: <199509010632.XAA18205@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 31 Aug 1995, Tony Li wrote > > Good. But you've also just proven that you're a major exception. > Recall that we're trying to talk about is the scaling effects of > multihoming. Who's the average user on the net? Not the > service/content provider.... it's the consumer. If Internet service is going to reach the "consumer", it has to have reliability similar to or greater than telephone/cable/water/power or any other utility. Consumers will demand that level of reliability. And service providers will give it to them through features like multi-homing. > Let's think about the users here. > > Do you think the users would appreciate a functional network? > > Tony > Yes, users would appreciate a functional network where they had the freedom to choose one or more connections from and freely switch between a variety of openly competing providers. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 09:48:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20090; Sat, 2 Sep 1995 09:48:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA28664; Sat, 2 Sep 1995 09:48:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA28658; Sat, 2 Sep 1995 09:42:16 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19871; Sat, 2 Sep 1995 09:42:10 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id TAA15509; Fri, 1 Sep 1995 19:41:48 -0400 Date: Fri, 1 Sep 1995 19:41:48 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Scott Bradner Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: <199509011101.HAA28863@newdev.harvard.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Scott Bradner wrote: > > I think the answer here is simpler - one does not put IP addresses on > business cards nor does one (in general) memorize IP addresses and give > them out to your friends. The DNS name is used instead. These are things > that are done with phone numbers and therefore there is much clearer > reasons for phone number portability. And even in this case, the house > telecommunications bill specifically says that local number portability is > only required if "technically feasible". > It has been widely reported in the news media (Newsweek, NY Times etc.) that according to House committee staffers, the House telecommunications bill was written by the baby bells who are not interested in the competition that local number portability would provide. > I used to think this was a problem and even commented on it in public a few > times (mostly as a way to scare the audience about the technical savvy of > congress) I no longer think this is an issue relevant to IP networks. Have you ever tried to calculate what it would cost a company with say a thousand IP hosts to change all the addresses if it switches providers? > > Scott > From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 10:48:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22151; Sat, 2 Sep 1995 10:48:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA28736; Sat, 2 Sep 1995 10:47:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA28730; Sat, 2 Sep 1995 10:44:43 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22100; Sat, 2 Sep 1995 10:44:38 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id UAA15655; Fri, 1 Sep 1995 20:44:20 -0400 Date: Fri, 1 Sep 1995 20:44:20 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Dorian Rysling Kim Cc: Dave Crocker , Noel Chiappa , big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Dorian Rysling Kim wrote: > > While we are talking about legitimacy, I hope debaters are somehow making > > their affliations clear so that biases are accounted for. A researcher > > Why is it that this topic always rears its ugly head in these > discussions? Is this really so necessary? > > Can't we just discuss the merits and feasibility of differnt approaches? > > -dorian, not one of the little guys and not one of the EVIL GREEDY > BASTARDs, and feeling distinctly like Rodney King. > > ______________________________________________________________________________ > Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive > Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 > CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian > This topic rears its ugly head for one simple reason: Any decision on IP numbering will have a great influence on how much people will have to pay for the service and to whom. As money is involved, it is best to clearly state your bias so that any potential for conflict of interest is avoided. It may actually be unethical for an employee to NOT advance and protect the interests of their employer in any legitimate manner. It is best if your interests are well known so that your "technical" statements are taken with an appropriate pinch of salt. Sanjay Kapur Kapur Business Systems, Inc. (A user, not a provider) From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 11:48:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23836; Sat, 2 Sep 1995 11:48:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA28808; Sat, 2 Sep 1995 11:47:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA28802; Sat, 2 Sep 1995 11:47:16 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23812; Sat, 2 Sep 1995 11:47:13 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id VAA01186; Fri, 1 Sep 1995 21:47:09 -0400 (EDT) Date: Fri, 1 Sep 1995 21:47:09 -0400 (EDT) From: Scott Bradner Message-Id: <199509020147.VAA01186@newdev.harvard.edu> To: root@kbs.netusa.net, sob@newdev.harvard.edu Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk > Have you ever tried to calculate what it would cost a company with say a > thousand IP hosts to change all the addresses if it switches providers? We seem to have a running thread here - its just too expensive, I don't care if a number of ISPs say that they have had good success when *requesting* (i.e not requiring) sites renumber when they connect up, I say it can't be done. yup, renumbering a big site can be expensive and a real pain, but come to think of it a lot of these sites (not all by a long shot, but a lot) are reconfiguring their nets to use Ethernet or ATM switches, and gee, how about that - they often renumber large chunks of their nets when they do so. No, I do not want to make light of the problems here, that is why Mike & I gladly accepted Bill & Roger's offer to start up a mailing list on the issues about renumbering but lets *all* get real here, no one is going to force IBM, DEC or MIT to renumber their class As I doubt that anyone will force the holders of established class B- sized nets to renumber in any great scale it is not all that hard to renumber a class C-sized net of 15 nodes it is not all that hard to renumber a net if all the hosts get their addresses from DHCP the Internet will double in the next year (i.e. half of the net of a year from now is not yet on, and in many of these cases, not now running IP) most of the new nets will be smallish < 100 hosts (my guess) if the new nets are helped to set up their nets in a way (such as using DHCP) to make renumbering easier, they will find renumbering easier i.e. most of half of the nets that make up the Internet of Sept '96 could support easy(er) renumbering if people decide to address the *how* to renumber rather than the *can't* renumber. even if there is *only* aggregation at the site level, and *none* at any provider level - there is still a very large reduction in the routing table (i.e the talk about the issues of multi-home providers is not important relative to making it easer for a site to be in the CIDR block of thir direct provider. Sites multi-homed to different providers may be an issue but current stats do not show may sites doing this.) at the current rate of growth the Internet providers will be having a "fun" time with their routers unless the ISPs continue to get the kind of reductions that Sean & Andrew have reported that they *currently* have (which they get by having most of their customers within their CIDR blocks) if the routing infrastructure of the Internet can not support the number of routes for the whole Internet you will not be able to get everywhere I don't know where that leaves you but I'd just as soon continue to see *an* Internet rather than *Internets*. If you have another way to ensure that is what we have a year from now and it does not involve making it easer for sires to renumber please state it in enough detail so that it can be built. But to just say 'it's to hard' without making a specific suggestion as to how to avoid the results of not doing things this way begs the issue and does not contribute to the resolution of the problems. Scott From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 12:08:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24514; Sat, 2 Sep 1995 12:08:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA28845; Sat, 2 Sep 1995 12:08:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA28839; Sat, 2 Sep 1995 11:55:21 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24128; Sat, 2 Sep 1995 11:55:08 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id VAA15780; Fri, 1 Sep 1995 21:54:22 -0400 Date: Fri, 1 Sep 1995 21:54:21 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: dcrocker@brandenburg.com, big-internet@munnari.OZ.AU, doleary@cisco.com, iap@vma.cc.nd.edu, inet-access@earth.com, jnc@ginger.lcs.mit.edu Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: <9509011420.AA11885@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Noel Chiappa wrote > From: Sanjay Kapur > > The above description is that of a monopoly. Is the CIDR addressing > scheme being designed by monopolists and large internet providers > interested in developing monopolies? > > Oh great, another person whose intellectual acuity is so limited the only > way they can understand the world is to see it all as a giant conspiracy > against them. You may call me stupid but you can not deny that a large portion of the telecommunications industry (local phone loop) is a monopoly and the same monopoly has been trying very agressively to get into the Internet business. By your argument, Judge Green, the US Justice department and all the state Public Service commissions in the US are also "limited in their intellectual acuity". Do you always try to win a debate by calling your opposite side in the argument stupid? > > Hint: just because when you fall out of a tree, you break your leg, it doesn't > mean gravity is the result of a scheme designed by hospitals, manufacturers > of crutches, etc, etc. I am so disillusioned. I always thought gravity was such a conspiracy. I must be real stupid! > > I no longer believe that the issue of number portability and multihoming > is a technical issue but a commercial/political one > > Oh. So, you're saying that there are no routing overhead ramifications for > picking up your address and taking it with you? Would you care to justify > that assertion with a technical argument? > I am saying that routing overhead is not as important as the freedom to switch internet providers. A scheme that sounds good in theory may be a really bad scheme in practice if the service provider you are stuck with provides bad service. > As the Internet gets more important in the life of society, it would be > undemocratic to give a few organizations (i.e. transit providers) too much > power. In the guise of increasing the size of the Internet, competition is > going to be stifled to an unbearable degree > > A graduate of the Tim Bass School of Political Economics, I see. > Name calling foul. Three point penalty. > there would be no limit to the price gouging from captive customers who > have no choice and can not go to the competition. > > Hint: switch addresses and you're still "kbs.netusa.net". > kbs.netusa.net is just one computer and is a bad example. A better example would be mit.edu. How much would everyone at mit.edu or digital.com or ibm.com or ucla.edu or another big or medium size organization like to switch their IP address so that they could switch Internet service providers. And what if MY service provider (netusa.net) had to change addresses? All his customers will have to change addresses too and at that time may as well decide to go to another service provider if they have to face that hassle anyway. > As proposed, without easy number portability and the absurd concept of > "leasing numbers" from a big company that you are forever beholden to, CIDR > will be the death of the Internet as we know it. > > I wait with bated breath for your scheme as to how the routing is going to > work with "easy number portability". Yes, mapping would do it, but then the > thigns we map into (call them "routing-names") will have to change when you > change providers. > > I assume you feel that that is unacceptable too? But those "routing-names" would be stored in a global repository much like DNS and would be much easier to change than IP numbers stored on each computer and would be handled by the service provider anyway. > > > The democratic way would be that NO ONE is assigned permanent numbers. > > Well, I don't know about democratic, but a certain degree of flexibility > in the addressing hierarchy, to match the flexibity in the topology, is > what the routing would like to see. I propose total flexibility. Why not design a system in which all numbers are leased for a limited amount of time. Global DHCP gone crazy. > > CIDR addressing may work as proposed if an X.500 type directory service > also exists and a computer's routing software discovers its address from > this service and it is updated dynamically. > > I think this is sort of the direction we need to go in, yes. The only question > is whether the DNS name is the only permanent name a host needs, or whether we > need another namespace. > > As part of the standard, no computer (including a router) would be allowed > to store its own routing address but ALWAYS discover it from an X.500 type > directory service (much like RARP/BOOTP for ethernet but on a global > scale). > > Well, there are a number of ways to go. You can either make the whole address > dynamic (so the high-order bits come from the routers, and the low-order ones > are from something like an Appletalk dynamic address assignment system), or > assign the low-order bits in a local table (a la RARP) and again the high- > order bits from the routers. > > Noel > That might work since the main cost in changing service providers is in renumbering IP hosts and that cost would go way if routers heirarchichaly give out numbers. In this scheme, when a router boots up, it gets its address from another router in the heirarchy. But to work, this has to be part of the numbering standard and not left upto another standard or upto each implementation. Also the next generation of the DNS standard would have to require that the authoratative DNS get its information from the same router that handed out that address. A DNS server can query more than one router for a host to provide for multi-homed hosts. This might look vaguely like Microsoft's implementation of WINS/DHCP. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 12:29:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25219; Sat, 2 Sep 1995 12:29:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA28893; Sat, 2 Sep 1995 12:28:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA28876; Sat, 2 Sep 1995 12:12:24 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24612; Sat, 2 Sep 1995 12:12:19 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id WAA15820; Fri, 1 Sep 1995 22:12:05 -0400 Date: Fri, 1 Sep 1995 22:12:05 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: dcrocker@brandenburg.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Discussing encap/mapping proposal In-Reply-To: <9509011436.AA11993@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Noel Chiappa wrote: > From: Sanjay Kapur > > While we are talking about legitimacy, I hope debaters are somehow making > their affliations clear so that biases are accounted for. > > That's right, nobody here is saying simply what their real technical opinion > is, they are always just pushing some line they are paid to purvey. > Maybe they are and maybe they are not, but would it not be better if such an affliation is out in the open so that readers can make up their own mind? > A researcher getting a grant from a large current or future transit > provider may have a different opinion on this issue then the future > victims of an unfair scheme, whatever that may be. > > Gee, maybe I better go check my mailbox, there may be a big check in it for > me. Come on Sprint, MCI, AT&T... where's my money? I expect to be paid off for > my unswerving support in your heartless and greedy campaign to run the "little > guys" out of business. > Amusing. > > and mathematics beats politics every day of the week,... > > Not in this earth, maybe in a mathematicians dream, but I would never > want to live in a world ruled by mathematicians. > > Legislatures have power, I never disputed that, but no legislature in this > creation, or any other, can change mathematics (or physics, etc, etc). > Mathematicians are just people, and I said nothing about them either. > But they CAN legistlate what routing is to be used. I have been in a university environment for the last twenty years and my father is a mathematics professor. I have been around intellectualls of all kinds all my life and have more trust in a representative elected by the people to choose what is best for society than in an unelected intellectual. Intellectuals tend to be too idealistic and not appreciative of the real world. Intellectualls and politicians did try to change mathematics. Do you remember the "New Math" craze of the 1960's after the US educational system was shocked by the launch of the Sputnick by the Soviets? > Noel > From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 13:39:11 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27239; Sat, 2 Sep 1995 13:39:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12192 Sat, 2 Sep 1995 13:30:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA28967; Sat, 2 Sep 1995 13:28:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA28950; Sat, 2 Sep 1995 13:12:35 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26507; Sat, 2 Sep 1995 13:12:29 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA16078; Fri, 1 Sep 1995 23:12:16 -0400 Date: Fri, 1 Sep 1995 23:12:15 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: <9509012001.AA13161@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Noel Chiappa wrote: > From: Sanjay Kapur > > Making fun of this issue will not stop regulators from stepping in once > the masses start getting taken to the cleaners by the monopolistic > "transit providers" and lawyers start smelling money. > > Realizing that those things are possibly going to happen (as I think we are > all wary of) doesn't help solve the technical problems we have. They are > probably going to do silly things no matter *what* we do. > > (E.g. Legislators here in the US have passed a law which attempts to stop the > extinction of species, not thinking about the fact that nature has been making > species extinct for billions of years...) Nature has not been making species extinct at anywhere close to the rate that we have been. > > If we have a choice between two technically plausible solutions, sure, let's > pick the one that's less likely to get the legislators/lawyers/etc on our > case. I'm not sure that we have that option here. > > The reason this argument has been visited so many times is because many > people perceive it to be of overriding importance and pleading lack of > time is not the answer > > Again, it doesn't matter how many people feel what; that will not produce > solutions in zero time. Nobody has come up, over the past two months, with any > solution that people agree is plausible for short-term usage, other than the > one that is now on the shelf: CIDR, and it's consequent requirement for > topology-based addresses. > > Note that there are a number of things we can do, with topology engineering, > that will make life a little easier, that can be deployed in "reasonable" > time; e.g. in a couple of months, such as exchange points. If people will > stop trying to argue that we can't live with topology-based addresses for > policy reasons, maybe we can get on with trying to ameliorate the impact > of them. > > Again, the current situation is that we have three choices: i) stop the growth > of the Internet, ii) fragment the Internet, or iii) use topology-based > addresses. Take your pick. > > Noel > I have a fourth choice that I prefer: Make the core routers MUCH bigger and MUCH faster. What is the fastest CPU in the fastest router? Is anyone using a 400MHz Alpha CPU with 128MB of RAM for routing? In 128MB RAM all routes can be stored as Class C addresses in an array without the need for address search lists. Also allow anyone who is assigned an IP address to sell their unused Class C and Class B addresses on an exchange. Fragment all Class B addresses to Class C addresses for the purposes of routing so that class B addresses can be subdivided and resold by those with few subnets. The above will buy time to design a long term strategy. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 13:48:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27518; Sat, 2 Sep 1995 13:48:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA29004; Sat, 2 Sep 1995 13:48:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA28987; Sat, 2 Sep 1995 13:38:53 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27218; Sat, 2 Sep 1995 13:38:38 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA16235; Fri, 1 Sep 1995 23:38:26 -0400 Date: Fri, 1 Sep 1995 23:38:25 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Discussing encap/mapping proposal In-Reply-To: <9509012040.AA13494@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Noel Chiappa wrote: > The proposed IP numbering scheme would make transit providers effectively > monopolies. > > PS: Life is full of little "lock-ins" like the address leasing scheme. For > instance, try buying a new car. If you decide, one month after you got it, > that you don't like it and want to switch to a different maker, you're going > to pay a stiff price for the privelege. However, nobody describes that as > a "monopoly". > > Noel > Of course car manufacturers are a monopoly and a very highly regulated monopoly. There are car lemon laws that do allow you to return a new and sometimes even a used car that has a lot of problems. Also the manufacture, sale and use of motor vehicles is highly regulated by a large number of government agencies which are supposed to help you if there are problems. A better example would be computer hardware. All the major vendors offer a thirty day return policy on personal computers. In most cases, you can arrange for a free 30-day evaluation of software or hardware. To the best of my knowledge, this option does not exist from network service providers. Lock-ins in themselves are not bad if they come with a reasonable warranty of performance and enforceable procedures to correct problems. If performance is not up to warranty standards, a network service provider should be required to pay a disconnection cost (i.e. the cost of transferring a connection to another service provider) as a warranty cost. Another improper analogy would be if USPS does not deliver packages properly, you can ship via UPS or Fedex or Airborne or any number of shippers. Your address does not change and there is no lock in. Readers get extra points for finding the flaw in this analogy. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 14:08:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28112; Sat, 2 Sep 1995 14:08:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA29047; Sat, 2 Sep 1995 14:08:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA29038; Sat, 2 Sep 1995 13:57:29 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27871; Sat, 2 Sep 1995 13:57:24 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA16253; Fri, 1 Sep 1995 23:56:49 -0400 Date: Fri, 1 Sep 1995 23:56:48 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Jacques Vidrine Cc: Noel Chiappa , big-internet@munnari.OZ.AU, dhollis@gp.magick.net Subject: Re: Multihoming and CIDR In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Jacques Vidrine wrote: > If renumbering were not an issue (i.e. if it were "easy" to renumber > whole organizations), would CIDR not be a near-perfect solution in the > global IPv4 Internet? > > Jacques Vidrine Communique, Inc. > Not only does it have to be easy for whole organizations but for those organizations that are downstream of them and so on and so forth. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 14:09:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28125; Sat, 2 Sep 1995 14:09:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA29067; Sat, 2 Sep 1995 14:09:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA29022; Sat, 2 Sep 1995 13:48:47 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27530; Sat, 2 Sep 1995 13:48:42 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA16245; Fri, 1 Sep 1995 23:48:21 -0400 Date: Fri, 1 Sep 1995 23:48:21 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, mn@ios.com, jnc@ginger.lcs.mit.edu Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: <9509012025.AA13277@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Noel Chiappa wrote: > However, in strictly routing terms, there is no way around this. When you > start moving chunks of the network around, the routing-names of the chunks > that move will have have to change (unless the chunk is so big that it has a > top-level name). Any other policy leads to heat-death of the routing. > > Noel > How do you define "so big" and who decides what is "so big" to have a top level name? I have a very basic questions: Will routers with huge amounts of memory that allows array based routing allow for a very large number of networks? Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 14:10:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28146; Sat, 2 Sep 1995 14:10:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA29100; Sat, 2 Sep 1995 14:10:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA29041; Sat, 2 Sep 1995 14:02:43 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27979; Sat, 2 Sep 1995 14:02:33 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id AAA16279; Sat, 2 Sep 1995 00:00:39 -0400 Date: Sat, 2 Sep 1995 00:00:39 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Dave Siegel Cc: jnc@ginger.lcs.mit.edu, dcrocker@brandenburg.com, big-internet@munnari.OZ.AU, doleary@cisco.com, iap@vma.cc.nd.edu, inet-access@earth.com Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: <199509012247.PAA25161@seagull.rtd.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Dave Siegel wrote: > > I am most interested in one detail: How can I become a "transit" provider > > and what are the qualifications for becoming a transit provider? > > If you have the money (DS3 backbones aren't cheap), the contacts (it helps to > know people at the competition), and the technical competence (none of your > competitors are interested in helping you break the Internet for them), those > would be the most weighty of the qualifications. > > These are not particularly easy things to obtain. It's rather a good thing > that not just anybody can set up a national backbone...much like not just > everyone can throw in some fiber and start up their own long distance network. > > > One of the major advantages of the current IP scheme is that the above > > question has a very definite answer and is central to the current success > > of the Internet. > > Perhaps. Too many national providers will cause problems as well, not in > terms of routes, since the number of end-users clients will probably proceed > at only a slightly higher rate, but interconnects will overload (check the > mae-east stats), too many peering sessions on a Cisco increases flap > frequency, since you have less of a chance to dampen things, and too many > interconnect points increases the total number of paths, which is a severe > memory strain for NSP's at all interconnects. > > Dave > > -- > Dave Siegel President, RTD Systems & Networking, Inc. > (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco > dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, > http://www.rtd.com/ for an ISP." > I get it. If you have a DS3 network then you are a "transit provider". How big does the network have to be? And who decides how big? And what happens when it is a baby bell which is not national but big locally? Sanjay From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 14:32:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28888; Sat, 2 Sep 1995 14:32:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA29139; Sat, 2 Sep 1995 14:28:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA29122; Sat, 2 Sep 1995 14:14:27 +1000 Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28408; Sat, 2 Sep 1995 14:14:18 +1000 (from valdis@black-ice.cc.vt.edu) Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.Beta.13/8.7.Beta.13) with ESMTP id AAA20654; Sat, 2 Sep 1995 00:13:48 -0400 Message-Id: <199509020413.AAA20654@black-ice.cc.vt.edu> To: Sanjay Kapur Cc: Noel Chiappa , big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Your message of "Fri, 01 Sep 1995 23:12:15 EDT." From: Valdis.Kletnieks@vt.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <20392.810015227.1@black-ice.cc.vt.edu> Content-Md5: DWkjkSlmblZuPSU2VDu8rw== Content-Transfer-Encoding: quoted-printable Date: Sat, 02 Sep 1995 00:13:47 -0400 Precedence: bulk On Fri, 01 Sep 1995 23:12:15 EDT, Sanjay Kapur said: > Nature has not been making species extinct at anywhere close to the rate= = > that we have been. Well, except for every 26 million years when Nemesis swings by and tosses us a zillion meteors and causes a 98% kill rate. ;) Anyhow, if we don't fix the routing problem, the net will be dead and we'll be out of touch when it happens next. ;) > I have a fourth choice that I prefer: Make the core routers MUCH bigger= and = > MUCH faster. What is the fastest CPU in the fastest router? Is anyone = > using a 400MHz Alpha CPU with 128MB of RAM for routing? In 128MB RAM all= = > routes can be stored as Class C addresses in an array without the need f= or = > address search lists. All you need now is to figure out how to exchange 128M of lists when there's a routing flap. ;) Valdis Kletnieks Computer Systems Engineer Virginia Tech From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 16:28:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02811; Sat, 2 Sep 1995 16:28:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA29260; Sat, 2 Sep 1995 16:28:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA29243; Sat, 2 Sep 1995 16:14:54 +1000 Received: from dixon.delong.sj.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02238; Sat, 2 Sep 1995 16:14:44 +1000 (from owen@DeLong.SJ.CA.US) Received: by dixon.DeLong.SJ.CA.US (8.6.12/SMI-4.1) id XAA09488; Fri, 1 Sep 1995 23:17:34 -0700 Date: Fri, 1 Sep 1995 09:59:52 -0700 From: owen@DeLong.SJ.CA.US (Owen DeLong) Message-Id: <199509020617.XAA09488@dixon.DeLong.SJ.CA.US> To: inet-access@earth.com Subject: Re: casting your multi-homing/provider-changing vote Content-Length: 7498 X-Lines: 147 Sender: owen@DeLong.SJ.CA.US Precedence: bulk > On Thu, 31 Aug 1995, Dave Crocker wrote: > > > > > Network numbers are assigned by providers. Local providers will > > get their CIDR block from their transit providers. End-users from their > > attachment providers. Numbers & blocks will be 'leased', that is the > > assignment is not permanent. If you change your up-link attachment, you > > will need to return your block and get a new one from your new provider. > > This necessitates renumbering. For local providers, it necessiates > > renumbering by all your subscribers. > > Only partially true. Any reasonable provider who plans to achieve any reasonable size should probably plan on being multihomed from the start. In that case, they should obtain a /18 or larger CIDR from the NIC and advertise that as an aggregate. I am currently in the process of building an ISP. We plan to grow very quickly once we launch. We will deploy nationally over the next two years. We were able to, with some negotiating, obtain a /18 with the reservation of the encompassing /16. By doing it this way, as we grow beyond the /18, the NIC can simply convert the /18 allocation to a /17. Then, as we use that up, they can convert to a /16. We're still going to be advertising one prefix. Our goal is to make it through the first ten years without having to advertise more than 5 routes. > > Multi-homing support is provided by taking the network number > > within one provider's block and advertising out another provider's link. > > As such it does not fit within their CIDR block. Hence, each advertisement > > of a multi-homed net which goes out additional links is an exception in the > > routing table. Any large-scale use of this mechanism completely defeats > > the purpose of CIDR. It allows no aggregation. > > This is where your theory breaks down. If providers plan ahead for whether they are going to be multi-homed or not (small local providers that intend to always be small local providers probably won't, the cost, as you say, is too high), CIDR can be used in a way that makes sense, without limiting the multi-homing possibilities. If you plan to be multi-homed, get your address space from the NIC. If you aren't going to be large enough to justify a /18 prefix, you probably aren't going to be able to pay the other costs of multi-homing anyway. If we can limit the routing tables to /18 or larger, the current belief is that things can survive. > > The other handling for multi-homing is if a provider is large > > enough to get their own, top-level CIDR block. Clearly there had better > > not be very many of these or there will be a large, flat, global table > > which is what CIDR is supposed to eliminate. > > There can be plenty of these, as long as each one is /18 or bigger. > > Now I believe the above summarizes the details that have recently > > been discussed. If there are others that are showing up in the next draft > > of the leasing proposal, it would be helpful to hear of them. > > > > I think it not at all complicated to predict from the above that > > multi-homing had better not occur on a large scale and that local providers > > will have very, very strong disincentives from changing transit providers. > > It is, in fact, not clear to me that a local provider will be able to > > change even once. > > This is the most important thing to avoid. It, in effect, provides a monopoly position to upstream providers. This is a completely unacceptable thing to do to the local providers. We must find a way that small providers can be provided with address space that does not create aggregious problems when they wish to change providers. > > -------------------- > > Dave Crocker +1 408 246 8253 > > Brandenburg Consulting fax: +1 408 249 6205 > > 675 Spruce Dr. page: +1 408 581 1174 > > Sunnyvale, CA 94086 USA dcrocker@brandenburg.com > > > > > > The above description is that of a monopoly. Is the CIDR addressing > scheme being designed by monopolists and large internet providers > interested in developing monopolies? > No, and yes. I don't think it was designed with the idea of creating a monopoly in mind. I think that is a bad side-effect of the easy-way-out solution to several other problems. > I no longer believe that the issue of number portability and multihoming > is a technical issue but a commercial/political one with the small > internet providers and big transit providers on opposite sides of > the spectrum (like David and Goliath). > It is still both a political/commercial and a technical issue. There are several technical problems that are easier to solve if we use the monopoly approach. However, I don't think that should happen, as I agree that it is commercially and politically agregious. Therefore, we must solve the technical problem of how to preserve small-provider address portability without causing the routers to croak. > As the Internet gets more important in the life of society, it would be > undemocratic to give a few organizations (i.e. transit providers) too much > power. > Yep... Of course, society is relatively undemocratic these days anyway, especially in the US, but that's a whole other issue. > In the guise of increasing the size of the Internet, competition is > going to be stifled to an unbearable degree and it would be very > difficult for a small company to resist the demands of their transit > providers. As regulatory organizations do not exist for the Internet, > there would be no limit to the price gouging from captive customers who > have no choice and can not go to the competition. > Exactly the reason that we must find a better technical solution. > Transit provider addressing smacks a lot of X.400 addressing and has all > the drawbacks of that scheme. > Huh? > As proposed, without easy number portability and the absurd concept of > "leasing numbers" from a big company that you are forever beholden to, CIDR > will be the death of the Internet as we know it. This is something that > the large Telcos want anyway. > Agreed. Leasing address space is an absurd concept. Single-homed customers should not be able to take their address space with them unless it is a /18 or bigger, but you should not pay a monthly or yearly fee for your address space. > CIDR might be acceptable if even the large transit providers had to lease > numbers and gets a new set of numbers periodically (through some sort of > lottery). The democratic way would be that NO ONE is assigned permanent > numbers. > It might be democratic, but it would be very agregious to EVERYONE, especially their customers. > CIDR addressing may work as proposed if an X.500 type directory service > also exists and a computer's routing software discovers its address from > this service and it is updated dynamically. As part of the standard, no > computer (including a router) would be allowed to store its own routing > address but ALWAYS discover it from an X.500 type directory service (much > like RARP/BOOTP for ethernet but on a global scale). > Probably something more like DHCP than X.500. Probably it would have to be a local directory service within each organization. Most platforms can support something like this today. > Sanjay Kapur > Kapur Business Systems, Inc. > Owen From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 18:08:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05647; Sat, 2 Sep 1995 18:08:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA29359; Sat, 2 Sep 1995 18:08:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA29355; Sat, 2 Sep 1995 18:05:42 +1000 Received: from panix3.panix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05619; Sat, 2 Sep 1995 18:05:39 +1000 (from hal9001@panix.com) Received: (from hal9001@localhost) by panix3.panix.com (8.6.12/8.6.12+PanixU1.1) id EAA03467; Sat, 2 Sep 1995 04:05:30 -0400 X-Sender: hal9001@popserver.panix.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Mac Eudora Pro 2.1.3 Date: Sat, 2 Sep 1995 04:05:40 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: "Robert A. Rosenberg" Subject: Re: Discussing encap/mapping proposal Cc: root@kbs.netusa.net, big-internet@munnari.OZ.AU Precedence: bulk At 16:01 9/1/95, you wrote: >(E.g. Legislators here in the US have passed a law which attempts to stop the >extinction of species, not thinking about the fact that nature has been making >species extinct for billions of years...) The problem with your statement is that Nature is impersonal and we have little control over it (except for tipping the "balance of Nature" such as by introducing/attacking one species that affects the population of another). We DO have control over our actions (and thus the results of these actions). Our actions thus can directly (by destroying a habitat or over-hunting a species) or indirectly (by killing a predator or food source of that species) affect a species. From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 18:10:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05802; Sat, 2 Sep 1995 18:10:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA29381; Sat, 2 Sep 1995 18:09:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA29352; Sat, 2 Sep 1995 18:05:38 +1000 Received: from panix3.panix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05615; Sat, 2 Sep 1995 18:05:28 +1000 (from hal9001@panix.com) Received: (from hal9001@localhost) by panix3.panix.com (8.6.12/8.6.12+PanixU1.1) id EAA03458; Sat, 2 Sep 1995 04:05:22 -0400 X-Sender: hal9001@popserver.panix.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Mac Eudora Pro 2.1.3 Date: Sat, 2 Sep 1995 04:05:31 -0400 To: "Scott M. Ballew" From: "Robert A. Rosenberg" Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, "Scott M. Ballew" Precedence: bulk At 11:13 9/1/95, Scott M. Ballew wrote: >If we look at what the providers P? are advertising to A, there are >effective 3 useful cases. The first of these is that P? are both >advertising the specific prefix A.P1.X, in addition to their >aggregated prefixes A.P?. This case is uninteresting to this >discussion because if A accepts the more specific prefix, then the X's >prefix might as well be A.X. If it does not, then the advertisements >are redundant and unnecessary and this case degenerates into the third >case. > You are forgetting the advantage that this gives over Case 2 for someone who peers with P1 (but not P2). Any connects to X will route through P1 (if possible) instead of having to go off-into-the-boonies to locate some connection to P2. >Case 2 is that P2 advertises the more specific route A.P1.X, along >with its own aggregate prefix A.P2 to A, who accepts both (if it >doesn't, this is the same as case 3). P1 advertises only its >aggregate prefix A.P1 to A. In this case, the primary inbound path >from U (the universe) and all of A except P1 is via P2. If the link >from P2 to X fails, the routing advertisement of A.P1.X ages, and A >fails over to the link through P1. Thus, X gets the redundant >connection they thought they wanted. If all you want is automatic fall back routing (ie: Route all communications from anywhere except P1 through P2 unless P2 is down [at which point route through P1]), you want your address from P1's CIDR Block (as your Secondary) while having it announced through P2 (Your Primary). Neither of these cases apply when there is no A except for the Internet Itself. If I am an ISP and get my Connections from SprintNet and MCI there is no A they both get their connectivity (or addresses) from. From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 18:48:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06918; Sat, 2 Sep 1995 18:48:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA29448; Sat, 2 Sep 1995 18:48:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA29439; Sat, 2 Sep 1995 18:43:44 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06768; Sat, 2 Sep 1995 18:43:40 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id BAA29210; Sat, 2 Sep 1995 01:43:30 -0700 From: Dave Siegel Message-Id: <199509020843.BAA29210@seagull.rtd.com> Subject: Re: casting your multi-homing/provider-changing vote To: root@kbs.netusa.net (Sanjay Kapur) Date: Sat, 2 Sep 1995 01:43:30 -0700 (MST) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, mn@ios.com In-Reply-To: from "Sanjay Kapur" at Sep 1, 95 11:48:21 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 769 Precedence: bulk > How do you define "so big" and who decides what is "so big" to have a top > level name? It would be, no doubt, an arbitrary decision. > I have a very basic questions: > > Will routers with huge amounts of memory that allows array based routing > allow for a very large number of networks? Now, where did you pick this term up? It means practically nothing, as far as I'm concerned. Cisco: "hey, let's make a router with 256 megs of RAM, that utilizes this new concept in OS design...we'll use ARRAYS to store all the routes!" Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 18:49:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06951; Sat, 2 Sep 1995 18:49:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA29470; Sat, 2 Sep 1995 18:49:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA29442; Sat, 2 Sep 1995 18:46:04 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06863; Sat, 2 Sep 1995 18:46:00 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id BAA29281; Sat, 2 Sep 1995 01:45:45 -0700 From: Dave Siegel Message-Id: <199509020845.BAA29281@seagull.rtd.com> Subject: Re: casting your multi-homing/provider-changing vote To: inet-access@earth.com Date: Sat, 2 Sep 1995 01:45:45 -0700 (MST) Cc: dsiegel@rtd.com, jnc@ginger.lcs.mit.edu, dcrocker@brandenburg.com, big-internet@munnari.OZ.AU, doleary@cisco.com, iap@vma.cc.nd.edu In-Reply-To: from "Sanjay Kapur" at Sep 2, 95 00:00:39 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 805 Precedence: bulk > I get it. If you have a DS3 network then you are a "transit provider". > How big does the network have to be? And who decides how big? And what > happens when it is a baby bell which is not national but big locally? I didn't say that. re-read the rest of the message. You can't provide connecivity to anything if you don't peer. You have to have an intellegently laid out network, and you need to have a technical staff that isn't going to screw up. Due to the complexities at hand, acquiring a good technical staff may be just as hard as finding the money. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sat Sep 2 23:08:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13767; Sat, 2 Sep 1995 23:08:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA29697; Sat, 2 Sep 1995 23:08:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA29691; Sat, 2 Sep 1995 23:01:29 +1000 Received: from access5.digex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13520; Sat, 2 Sep 1995 23:01:24 +1000 (from lanfear@access.digex.net) Received: (from lanfear@localhost) by access5.digex.net (8.6.12/8.6.12) id JAA29242 ; for big-internet@munnari.OZ.AU; Sat, 2 Sep 1995 09:01:19 -0400 Date: Sat, 2 Sep 1995 09:01:19 -0400 From: Lanfear Message-Id: <199509021301.JAA29242@access5.digex.net> To: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal Precedence: bulk : We've already had this argument, five times. A mapping system (like the : 800/local portabilty system) would be nice, but the network is growing so : fast we don't currently have the time to do it, if we want to keep the : network i) growing, and ii) working. Maybe some day. I really dont get how the same damn conversation can be going on, on about five different mailing lists, for the last several weeks/months. The "Internet" is a commercial venture now. Fine. And, being a nice little world of its own, its got a lot of people who dont agree with each other, and who never will. Some people, who have been working at this for longer than ive been breathing, and who actually *want* to keep the "Internet" as a cohesive whole, feel that there are measures that need to be taken to keep it working. These measures seem unjustly harsh, or difficult, or just blame wrong, to other people. They want something different. Many dont know what it is they *do* want, but it seems to involve keeping the "Internet" as they know it, without all those bitter pills someone is trying to jam down their throat. The Internet is a neighborhood. And in the real world, neighborhoods have covenants. Some covenants say you cant have a red barn. Others say you cant have more than half a cat per quarter acre- and only a calico cat at that. If you dont like the covenants, you look somewhere else for a place to live. If youve already bought into the neighborhood, and want to build a frekkin' red barn, you sell your 3 bedroom split level to someone else who doesnt care if they have a red barn or not, and move out to the 'burbs and build as many red barns as you can afford. Market forces drive this thing called the Internet. If you think you are right, in that everyone is going to want a red barn when they wake up and think about it, then move out to the 'burbs and start pre-fabbing the dern things. If you can convince someone with money, or if you have the money yourself, and you dont like what the neighborhood council is talking about, then go out and build this new Internet. Make up your own numbering system, create your networking Utopia. If you are right, then you'll win out. When the "Internet" as we know it collapses, then we will see if the "Tim Bass School of Network Engineering" has actually built anything, or whether the acolytes have done nothing other than waft around pipe dreams of Capri. When people found out that "Super Nintendo" wasn't backwards-compatitble with "Nintendo", they were pissed. But they bought it anyway. Personally, I kinda like this 'hood. And I dont even care if someone starts walking around trying to patrol it with an Uzi- as long as I can have one too. The world is large. What is it that the Saab commercial sez? Find your own internet. From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 00:28:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16484; Sun, 3 Sep 1995 00:28:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA00103; Sun, 3 Sep 1995 00:28:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA29789; Sun, 3 Sep 1995 00:17:29 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16095; Sun, 3 Sep 1995 00:17:23 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id KAA16745; Sat, 2 Sep 1995 10:17:17 -0400 Date: Sat, 2 Sep 1995 10:17:16 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Valdis.Kletnieks@vt.edu Cc: Noel Chiappa , big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: <199509020413.AAA20654@black-ice.cc.vt.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 2 Sep 1995 Valdis.Kletnieks@vt.edu wrote: > > MUCH faster. What is the fastest CPU in the fastest router? Is anyone > > using a 400MHz Alpha CPU with 128MB of RAM for routing? In 128MB RAM all > > routes can be stored as Class C addresses in an array without the need for > > address search lists. > > All you need now is to figure out how to exchange 128M of lists > when there's a routing flap. ;) > Where are all the brilliant graph theorists? Why can't they design a routing system not suspectible to a routing flap? Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 00:48:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17001; Sun, 3 Sep 1995 00:48:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA00144; Sun, 3 Sep 1995 00:48:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA00138; Sun, 3 Sep 1995 00:42:34 +1000 Received: from prime.planetcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16781; Sun, 3 Sep 1995 00:42:28 +1000 (from jgorman@hlc.net) Received: from prime.planetcom.com (prime.planetcom.com [198.69.139.1]) by prime.planetcom.com (8.6.5/8.6.5) with SMTP id KAA15364; Sat, 2 Sep 1995 10:48:31 -0400 Date: Sat, 2 Sep 1995 10:48:30 -0400 (EDT) From: James Gorman X-Sender: jgorman@prime.planetcom.com To: inet-access@earth.com Cc: inet-access@earth.com, dsiegel@rtd.com, jnc@ginger.lcs.mit.edu, dcrocker@brandenburg.com, big-internet@munnari.OZ.AU, doleary@cisco.com, iap@vma.cc.nd.edu Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: <199509020845.BAA29281@seagull.rtd.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 2 Sep 1995, Dave Siegel wrote: > > I get it. If you have a DS3 network then you are a "transit provider". > > How big does the network have to be? And who decides how big? And what > > happens when it is a baby bell which is not national but big locally? > > I didn't say that. re-read the rest of the message. You can't provide > connecivity to anything if you don't peer. You have to have an intellegently > laid out network, and you need to have a technical staff that isn't going to > screw up. > > Due to the complexities at hand, acquiring a good technical staff may be just > as hard as finding the money. I aggree with Dave, except that I believe that finding the money is much easier than finding the technical staff to handle building a "Backbone" network, most if not all those capible of doing it are either a) doing as an ISP already or b) working for someone running or starting and ISP. The talent pool of poeple that actually understand even a majority of the issues involved is so small that it is virtually imposible to find some one looking for a change. The other really bad thing is that if you do have or know someone with the tallent and expeiance, they are soo busy that they are not able to spend the time to bring other talented but not as experianced people up to speed. This is one reason that so many LARGE (read fortune 20) organisations are not involved in it yet and others are just buying or leasing transit from ISP's. Think about it any one can pay to get a DS3 to all of the NAPS but precious few acctually know what to do with it when the get it there. > > Dave > > -- > Dave Siegel President, RTD Systems & Networking, Inc. > (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco > dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, > http://www.rtd.com/ for an ISP." > ============================================================ HLC-INTERNET - America's Leading Corporate Internet Provider James Gorman, Director of East Coast Operations PH: 703.556.4041 FAX: 703.903.6842 E-Mail: jgorman@hlc.net ============================================================= From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 01:08:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17554; Sun, 3 Sep 1995 01:08:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA00189; Sun, 3 Sep 1995 01:08:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA00183; Sun, 3 Sep 1995 01:04:19 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17418; Sun, 3 Sep 1995 01:04:14 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id KAA16826; Sat, 2 Sep 1995 10:54:45 -0400 Date: Sat, 2 Sep 1995 10:54:44 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Dave Siegel Cc: inet-access@earth.com, dsiegel@rtd.com, jnc@ginger.lcs.mit.edu, dcrocker@brandenburg.com, big-internet@munnari.OZ.AU, doleary@cisco.com, iap@vma.cc.nd.edu Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: <199509020845.BAA29281@seagull.rtd.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 2 Sep 1995, Dave Siegel wrote: > I didn't say that. re-read the rest of the message. You can't provide > connecivity to anything if you don't peer. You have to have an intellegently > laid out network, and you need to have a technical staff that isn't going to > screw up. Who decides if the network is intelligently laid out? Very few of the current transit providers have an intelligently laid out network. All of the current transit providers have technical staff that screws up often enough. > > Due to the complexities at hand, acquiring a good technical staff may be just > as hard as finding the money. > > Dave I disagree. It is much harder to find and keep good technical staff than it is to find money. I do not think ANY transit provider has a decent sized competent technical staff. There may be a few good knowledgeable persons in each organization but most of the rest of the technical staff do not know what they are doing. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 01:28:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18231; Sun, 3 Sep 1995 01:28:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA00237; Sun, 3 Sep 1995 01:28:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA00220; Sun, 3 Sep 1995 01:12:09 +1000 Received: from lint.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17608; Sun, 3 Sep 1995 01:12:06 +1000 (from rcraig@cisco.com) Received: from [171.69.174.3] (soler.cisco.com [171.69.174.3]) by lint.cisco.com (8.6.10/CISCO.SERVER.1.1) with SMTP id IAA23368; Sat, 2 Sep 1995 08:10:34 -0700 X-Sender: rcraig@lint.cisco.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 2 Sep 1995 11:12:10 -0400 To: Sanjay Kapur , Valdis.Kletnieks@vt.edu From: rcraig@cisco.com (Robert Craig) Subject: Re: Discussing encap/mapping proposal Cc: Noel Chiappa , big-internet@munnari.OZ.AU Precedence: bulk At 10:17 95/9/2, Sanjay Kapur wrote: >On Sat, 2 Sep 1995 Valdis.Kletnieks@vt.edu wrote: > >> > MUCH faster. What is the fastest CPU in the fastest router? Is anyone >> > using a 400MHz Alpha CPU with 128MB of RAM for routing? In 128MB RAM all >> > routes can be stored as Class C addresses in an array without the need for >> > address search lists. >> >> All you need now is to figure out how to exchange 128M of lists >> when there's a routing flap. ;) >> > >Where are all the brilliant graph theorists? Why can't they design a >routing system not suspectible to a routing flap? > Such a routing system already exists, and has for many years. It is called "static" routing. The behavior of large distributed dynamic systems is still very much a research area. Robert. From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 04:28:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23010; Sun, 3 Sep 1995 04:28:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA00408; Sun, 3 Sep 1995 04:28:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA00402; Sun, 3 Sep 1995 04:27:21 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22781; Sun, 3 Sep 1995 04:27:13 +1000 (from ses@tipper.oit.unc.edu) Received: (from ses@localhost) by tipper.oit.unc.edu (8.6.12/8.6.10) id OAA13630; Sat, 2 Sep 1995 14:27:04 -0400 Date: Sat, 2 Sep 1995 14:27:03 -0400 (EDT) From: Simon Spero To: Robert Craig Cc: Sanjay Kapur , Valdis.Kletnieks@vt.edu, Noel Chiappa , big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk This whole discussion seems to have been caught in a loop for the past week, but before the ttl hits zero, and someone declares Mornington Crescent I'd like to put my 2 cents in. 1) CIDR can and does work to reduce routing table size. It's already reducing the impact of new sites coming on-line. 2) Brownian motion between providers will decay the benefits of CIDR over time. 3) CIDR is designed as a stop-gap measure till IPv6 saves the world. It there's no doubt it buys some extra time - the debate seems to be whether it can buy enough without causing too many IPv4 renumberings. 4) Renumbering is painful, but can be bearable if it can be done over time. UNC's transition from using a subset of MCNCs class B to its own class B took place over many, many months. This was possible due to a really bad network achitecture with way too much bridging, but it seems that phasing the transition over time makes changing addresses a bit less painful. If renumberings need to take place on a flag-day, it's a perfect opportunity to renegotiate your contract. 5) Encapsulation for routing over a core can also work, and theoretically could give a pretty good increase in reliability because routing information can be stabilised much more quickly if there's a lot less of it. 6) Tony has said that he believes the encapsulation boxes will require custom hardware to keep up with T3 speeds. I believe that it would be possible to build a box on top of an ordinary workstation- you'ld have to completely rewrite what bits of the IP stack you needed though. There should be sufficient locality of reference to keep the mapping entries in the on-chip cache. Boxes could be cheapish individually, but a lot of them would be needed. 7) Wouldn't the effort spent on this discussion have been better spent on working on implementing IPv6? 8) Two words - multicast ARP. Simon Contract with America - Explained! |Phone: +44-81-500-3000 Contract: verb |Mail: ses@unc.edu 1) To shrink or reduce in size - the economy contracted +----------------------- 2) To become infected -My baby contracted pneumonia when they stopped my welfare From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 04:48:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23371; Sun, 3 Sep 1995 04:48:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA00445; Sun, 3 Sep 1995 04:48:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA00439; Sun, 3 Sep 1995 04:40:07 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23272; Sun, 3 Sep 1995 04:40:03 +1000 (from gherbert@crl.com) Received: from crl3.crl.com by mail.crl.com with SMTP id AA00513 (5.65c/IDA-1.5); Sat, 2 Sep 1995 10:53:55 -0700 Message-Id: <199509021753.AA00513@mail.crl.com> To: inet-access@earth.com Cc: big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: Your message of "Fri, 01 Sep 1995 21:54:21 EDT." Date: Sat, 02 Sep 1995 10:53:54 -0700 From: George Herbert Precedence: bulk From: Sanjay Kapur >> Oh. So, you're saying that there are no routing overhead ramifications for >> picking up your address and taking it with you? Would you care to justify >> that assertion with a technical argument? >I am saying that routing overhead is not as important as the freedom to >switch internet providers. A scheme that sounds good in theory may be a >really bad scheme in practice if the service provider you are stuck with >provides bad service. Freedom to switch internet providers exists. You will just have to do renumbering for your machines. Freedom to switch without renumbering would probably cause router lockup sometime next spring or early summer at current growth rates. Alternative schemes involving radically changing how IP numbers are looked up, used, and allocated are not deployable in that time period. We frankly wouldn't be done arguing about how to do it by the time the core routers died and backbone providers started ignoring "exception" route announcements to keep the majority of traffic flowing. -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 06:08:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25430; Sun, 3 Sep 1995 06:08:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA00533; Sun, 3 Sep 1995 06:08:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA00516; Sun, 3 Sep 1995 05:52:33 +1000 Received: from Daisy.ee.und.ac.za by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24957; Sun, 3 Sep 1995 05:52:26 +1000 (from barrett@daisy.ee.und.ac.za) Received: by daisy.ee.und.ac.za (Smail3.1.28.1 #31) id m0soybw-0007WWC; Sat, 2 Sep 95 21:52 GMT+0200 Date: Sat, 2 Sep 1995 21:52:14 +0200 (GMT+0200) From: Alan Barrett X-Sender: barrett@daisy.ee.und.ac.za To: big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: <9509012100.AA13662@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 1 Sep 1995, Noel Chiappa wrote: > From: Barney Wolff > Yes but - if my two providers are from > {sprint,mci,alternet,psi,...} the AAB may be Earth - I don't see > how it's smaller. It's certainly all of North America. > Yup. If X is multi-homed to P1 and P2 (and has address P1.X), and Y is multi-homed to P1 and P3 (and has routing address P1.Y), and if P1 is well-connected to P2 and to P3, then P1 can announce a route for the aggregate P1 to all its neighbours, announce a route for P1.X to P2 but not to P3, and announce a route for P1.Y to P3 but not to P2. P3 does not need a route to P1.X if it has a route to P1, and P2 does not need a route to P1.Y if it has a route to P1. I suppose we could say that the AAB for the P1.X-->P1 abstraction is different from the AAB for the P1.Y-->P1 abstraction. It no longer seems useful to talk about the AAB for P1, because different pieces of P1.* may be subsumed into the P1 abstraction at different boundaries. For example, if Barney is multi-homed to Sprint and MCI, and gets address space from Sprint, then Sprint and MCI both need to carry Barney's routes internally, but Alternet, PSI, ..., need not carry Barney's specific routes, because they could be covered by a larger (Sprint) aggregate. > It's not just the smallest enclosing scope that includes both > attachment points, because the providers don't run their routing > protocols that way > > Ah. Look at what I said again; I said the smallest *naming* scope > that encloses both. Since the only naming scope that currently > encloses both MCI and Sprint is the global one, it follows that if you > multihome to MCI and Sprint, to make multihoming work your address > must be adverised globally. I think you need some new terminology if your old terminology leads you to that incorrect conclusion. --apb (Alan Barrett) From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 07:48:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27855; Sun, 3 Sep 1995 07:48:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA00640; Sun, 3 Sep 1995 07:48:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA00634; Sun, 3 Sep 1995 07:41:21 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27786; Sun, 3 Sep 1995 07:41:17 +1000 (from barney@databus.databus.com) Received: from databus.databus.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08274 Sun, 3 Sep 1995 07:38:06 +1000 (from barney@databus.databus.com) Date: Sat, 2 Sep 95 17:35 EDT Message-Id: <9509021738.AA23837@databus.databus.com> From: Barney Wolff To: big-internet@munnari.OZ.AU Subject: Re: Multihoming Content-Length: 1504 Content-Type: text Precedence: bulk > Date: Sat, 2 Sep 1995 21:52:14 +0200 (GMT+0200) > From: Alan Barrett > > For example, if Barney is multi-homed to Sprint and MCI, and gets > address space from Sprint, then Sprint and MCI both need to carry > Barney's routes internally, but Alternet, PSI, ..., need not carry > Barney's specific routes, because they could be covered by a larger > (Sprint) aggregate. Not in practice. The more-specific route will be preferred. There are real issues about how to achieve, in practice, the benefit that multi-homing is intended to achieve, without global advertising. (ie - I don't know how to do it.) If I get address space out of some "MAE-East" block (if such existed), what happens if some fanatic blows it up? The implication is that a topological address assignment strategy requires that an exchange point be distributed in space, not just a bunch of routers in a room. It becomes a >>2x cost, not <2x. At the political level, either you believe that this is a genuinely hard problem or that it's the artificial creation of a big-provider conspiracy. Every piece of evidence I can see points to its being genuine. So multi-homing and portable addresses will be scarce (tho not fixed) resources for some time to come. Economics tells us how to allocate such things optimally, though the answer will not please those who believe that what is now free must forever be free. ("Free" is American slang for "not separately priced".) Barney Wolff From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 08:08:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28526; Sun, 3 Sep 1995 08:08:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA00677; Sun, 3 Sep 1995 08:08:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA00654; Sun, 3 Sep 1995 07:49:14 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27878; Sun, 3 Sep 1995 07:49:10 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id OAA02460; Sat, 2 Sep 1995 14:48:55 -0700 From: Dave Siegel Message-Id: <199509022148.OAA02460@seagull.rtd.com> Subject: Re: casting your multi-homing/provider-changing vote To: root@kbs.netusa.net (Sanjay Kapur) Date: Sat, 2 Sep 1995 14:48:55 -0700 (MST) Cc: dsiegel@rtd.com, inet-access@earth.com, jnc@ginger.lcs.mit.edu, dcrocker@brandenburg.com, big-internet@munnari.OZ.AU, doleary@cisco.com, iap@vma.cc.nd.edu In-Reply-To: from "Sanjay Kapur" at Sep 2, 95 10:54:44 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1969 Precedence: bulk > Who decides if the network is intelligently laid out? Very few of the > current transit providers have an intelligently laid out network. All of > the current transit providers have technical staff that screws up often > enough. Actually, all the designs have their merits and drawbacks. Obviously, the people evaluating your network to understand if you have the technical abilities are the ones making the decisions....these people will be your peers. I mean this in the technical bgp sense, not the traditional sense. > > Due to the complexities at hand, acquiring a good technical staff may be just > > as hard as finding the money. > > > > Dave > > I disagree. > > It is much harder to find and keep good technical staff than it is to find > money. Fine. You've inked it out better than I have. I guess some people find it easier to dig up 10 million dollars out of a hole than I do. > I do not think ANY transit provider has a decent sized competent > technical staff. There may be a few good knowledgeable persons in each > organization but most of the rest of the technical staff do not know > what they are doing. There are almost always a few good technical people at each provider. There is a real need for there to be a core of competent people at each company. Ideally, they'll be training new people so that they can keep up with the load, but if there isn't time...and quite often there isn't, then things will get worse. It took me almost a year to train some people at net99 to the point where they had a clue on how things work, and they still don't understand the ins and outs, but they can hold their own, and fix problems for customers, so at least they're heading in the right direction. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 10:08:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01964; Sun, 3 Sep 1995 10:08:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA00819; Sun, 3 Sep 1995 10:08:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA00813; Sun, 3 Sep 1995 10:02:31 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01856; Sun, 3 Sep 1995 10:02:28 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id RAA06781; Sat, 2 Sep 1995 17:02:21 -0700 Date: Sat, 2 Sep 1995 17:02:21 -0700 From: Tony Li Message-Id: <199509030002.RAA06781@greatdane.cisco.com> To: root@kbs.netusa.net Cc: wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: (message from Sanjay Kapur on Fri, 1 Sep 1995 19:15:01 -0400 (EDT)) Subject: RE: Multihoming Precedence: bulk If Internet service is going to reach the "consumer", it has to have reliability similar to or greater than telephone/cable/water/power or any other utility. Consumers will demand that level of reliability. And service providers will give it to them through features like multi-homing. Consumers are not going to multihome. Do you have two water lines to your house? Yes, the provider may be multihomed. That's a _very_ different case. Yes, users would appreciate a functional network where they had the freedom to choose one or more connections from and freely switch between a variety of openly competing providers. That's not a problem. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 10:28:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02636; Sun, 3 Sep 1995 10:28:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA00867; Sun, 3 Sep 1995 10:28:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA00821; Sun, 3 Sep 1995 10:08:25 +1000 Received: from Tetsuo.Communique.Net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01960; Sun, 3 Sep 1995 10:08:22 +1000 (from nectar@communique.net) Received: from tetsuo.communique.net (Tetsuo.Communique.Net [204.27.64.10]) by tetsuo.communique.net (8.6.12/8.6.12) with SMTP id TAA34472; Sat, 2 Sep 1995 19:08:03 -0500 Date: Sat, 2 Sep 1995 19:08:02 -0500 (CDT) From: Jacques Vidrine To: Sanjay Kapur Cc: Noel Chiappa , big-internet@munnari.OZ.AU, dhollis@gp.magick.net Subject: Re: Multihoming and CIDR In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Indeed, that is the point that I was leading up to. Wouldn't we all be better off discussing _how_ to renumber, instead of whining that we _can't_ or that it is too expensive. Jacques Vidrine Communique, Inc. On Fri, 1 Sep 1995, Sanjay Kapur wrote: > > > On Fri, 1 Sep 1995, Jacques Vidrine wrote: > > > If renumbering were not an issue (i.e. if it were "easy" to renumber > > whole organizations), would CIDR not be a near-perfect solution in the > > global IPv4 Internet? > > > > Jacques Vidrine Communique, Inc. > > > > Not only does it have to be easy for whole organizations but for those > organizations that are downstream of them and so on and so forth. > > Sanjay Kapur > Kapur Business Systems, Inc. > From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 10:48:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03204; Sun, 3 Sep 1995 10:48:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA00914; Sun, 3 Sep 1995 10:48:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA00906; Sun, 3 Sep 1995 10:45:15 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03146; Sun, 3 Sep 1995 10:45:03 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id UAA18171; Sat, 2 Sep 1995 20:44:41 -0400 Date: Sat, 2 Sep 1995 20:44:40 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Jacques Vidrine Cc: Noel Chiappa , big-internet@munnari.OZ.AU, dhollis@gp.magick.net Subject: Re: Multihoming and CIDR In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 2 Sep 1995, Jacques Vidrine wrote: > > Indeed, that is the point that I was leading up to. Wouldn't we all be > better off discussing _how_ to renumber, instead of whining that we > _can't_ or that it is too expensive. > > Jacques Vidrine Communique, Inc. > It may have gone unnoticed, but I have proposed several alternatives all dependent on not having static IP numbers. I have proposed among other alternatives schemes that expand on Microsoft's WINS/DHCP system. To be acceptible, a numbering scheme has to incorporate an expansion of the DNS so that the DNS knows the new address of a IP host name whose number has changed. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 10:49:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03226; Sun, 3 Sep 1995 10:49:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA00936; Sun, 3 Sep 1995 10:49:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA00903; Sun, 3 Sep 1995 10:42:22 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03053; Sun, 3 Sep 1995 10:42:13 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id RAA07231; Sat, 2 Sep 1995 17:42:06 -0700 Date: Sat, 2 Sep 1995 17:42:06 -0700 From: Tony Li Message-Id: <199509030042.RAA07231@greatdane.cisco.com> To: root@kbs.netusa.net Cc: wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: (message from Sanjay Kapur on Sat, 2 Sep 1995 20:36:46 -0400 (EDT)) Subject: RE: Multihoming Precedence: bulk What gave you the idea that consumers will not be multihomed for reliability? Twenty four hour dedicated connections for Internet connectivity (or some other version of the Information Superhighway) to the home is the next growth area for our Industry. As people get more dependent on the Internet, they will demand reliability and the only way that they can get it currently is multihoming. The fact that over 90% of even the early adopters of the net are not multihomed. The fact that every sensical media that I've seen for home access gives you only single homing. However, I do have two different phone lines and two different service providers to a box in my home. [and water, and cable, and power] I'm duly impressed. What about gas? ;-) You must live in earthquake country. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 10:50:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03239; Sun, 3 Sep 1995 10:50:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA00956; Sun, 3 Sep 1995 10:50:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA00889; Sun, 3 Sep 1995 10:37:00 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02847; Sun, 3 Sep 1995 10:36:56 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id UAA18159; Sat, 2 Sep 1995 20:36:46 -0400 Date: Sat, 2 Sep 1995 20:36:46 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Tony Li Cc: wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU Subject: RE: Multihoming In-Reply-To: <199509030002.RAA06781@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 2 Sep 1995, Tony Li wrote: > > If Internet service is going to reach the "consumer", it has to have > reliability similar to or greater than telephone/cable/water/power or any > other utility. > > Consumers will demand that level of reliability. And service providers will > give it to them through features like multi-homing. > > Consumers are not going to multihome. Do you have two water lines to > your house? > > Yes, the provider may be multihomed. That's a _very_ different case. In addition to piped water, my house does have a ground water pump in the basement which has not been turned on for some time now but was in use some decades back when piped water supply was not as reliable. What gave you the idea that consumers will not be multihomed for reliability? Twenty four hour dedicated connections for Internet connectivity (or some other version of the Information Superhighway) to the home is the next growth area for our Industry. As people get more dependent on the Internet, they will demand reliability and the only way that they can get it currently is multihoming. I do not have two water lines because I have not had a water outage that I can recall. The reliability of the water supply in my area is very high. Anyway, water supply is recognized as a monopoly and regulated as such. Before any one asks, I take care of power outages through UPS and power generators. As for cable TV, I have already priced direct satellite providers in addition to my cable TV connection and may buy a dish soon. However, I do have two different phone lines and two different service providers to a box in my home. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 11:08:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03699; Sun, 3 Sep 1995 11:08:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA00998; Sun, 3 Sep 1995 11:08:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA00994; Sun, 3 Sep 1995 11:07:34 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03692; Sun, 3 Sep 1995 11:07:32 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id SAA07693; Sat, 2 Sep 1995 18:06:15 -0700 Date: Sat, 2 Sep 1995 18:06:15 -0700 From: Tony Li Message-Id: <199509030106.SAA07693@greatdane.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: dcrocker@brandenburg.com, tli@cisco.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, mn@ios.com In-Reply-To: <9509011707.AA12487@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: Multihoming Precedence: bulk It seems perfectly obvious to me. Multihoming with a limited scope has routing overhead implications which are also limited. Case closed. The _assumption_ here, of course, is that we do some additional level of aggregation. The correct criticism is that we need to work out mechanisms for correctly determining and performing such proxy aggregation. Volunteers, especially from the provider community, would be most welcome. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 11:09:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03719; Sun, 3 Sep 1995 11:09:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA01020; Sun, 3 Sep 1995 11:09:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA00989; Sun, 3 Sep 1995 11:05:58 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03680; Sun, 3 Sep 1995 11:05:49 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id VAA18211; Sat, 2 Sep 1995 21:05:31 -0400 Date: Sat, 2 Sep 1995 21:05:30 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Tony Li Cc: wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU Subject: RE: Multihoming In-Reply-To: <199509030042.RAA07231@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 2 Sep 1995, Tony Li wrote: > The fact that over 90% of even the early adopters of the net are not > multihomed. The fact that every sensical media that I've seen for > home access gives you only single homing. > That will change unless provider reliability and phone company lines improves. People will get more dependent on the Internet and will not like downtimes. > However, I do have two different phone lines and two different service > providers to a box in my home. [and water, and cable, and power] > > I'm duly impressed. What about gas? ;-) You must live in earthquake > country. > I have bottled gas (propane) and can choose from among many different local companies and I have oil heat where again there are many different suppliers. I do NOT live in earthquake country but I do like reliable service and the freedom to go to a vendor who provides better service. My main objection to monopolies is not that "they are out to get me" but that history has proven time and time again that unregulated monopolies provide bad service at extortionist's prices. > Tony > Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 11:28:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04282; Sun, 3 Sep 1995 11:28:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA01096; Sun, 3 Sep 1995 11:28:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA01075; Sun, 3 Sep 1995 11:11:52 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03752; Sun, 3 Sep 1995 11:11:48 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id SAA07832; Sat, 2 Sep 1995 18:11:36 -0700 Date: Sat, 2 Sep 1995 18:11:36 -0700 From: Tony Li Message-Id: <199509030111.SAA07832@greatdane.cisco.com> To: root@kbs.netusa.net Cc: wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: (message from Sanjay Kapur on Sat, 2 Sep 1995 21:05:30 -0400 (EDT)) Subject: RE: Multihoming Precedence: bulk My main objection to monopolies is not that "they are out to get me" but that history has proven time and time again that unregulated monopolies provide bad service at extortionist's prices. I can't help but to respond to this: it's very clear that no one is instuting a monopoly. In fact, there is so MUCH competition in the ISP market right now (140 in the SF Bay Area) that there is _bound_ to be a major fall out. The winner is likely to be the provider that handles the scaling issues (provisioning of modems, cycles, bw, etc.) the best. If you think that someone is trying to disallow multihoming, you've misread. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 11:48:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04841; Sun, 3 Sep 1995 11:48:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA01142; Sun, 3 Sep 1995 11:48:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA01120; Sun, 3 Sep 1995 11:36:10 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04558; Sun, 3 Sep 1995 11:36:06 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id SAA08273; Sat, 2 Sep 1995 18:36:03 -0700 Date: Sat, 2 Sep 1995 18:36:03 -0700 From: Tony Li Message-Id: <199509030136.SAA08273@greatdane.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: mn@ios.com, tli@cisco.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9509011355.AA11788@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: Multihoming Precedence: bulk that's the big bird's head in the sand. You should know. Children, Please behave yourselves. Co-chair Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 12:28:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05980; Sun, 3 Sep 1995 12:28:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA01249; Sun, 3 Sep 1995 12:28:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA01199; Sun, 3 Sep 1995 12:09:08 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05494; Sun, 3 Sep 1995 12:09:01 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id TAA08870; Sat, 2 Sep 1995 19:08:19 -0700 Date: Sat, 2 Sep 1995 19:08:19 -0700 From: Tony Li Message-Id: <199509030208.TAA08870@greatdane.cisco.com> To: mn@ios.com Cc: big-internet@munnari.OZ.AU In-Reply-To: (mn@ios.com) Subject: Re: Multihoming Precedence: bulk > Just to be specific, we're talking large scale geographic diversity. > Not just the next provider over. large scale like X.com, Inc, with a fully owned network of Ts from the west coast to the east coast? Or just NSPs that peer at multiple meetpoints? Either are fine examples. I could not find in my message the 'next provider over'. Sorry, I was just trying to be perfectly clear. You mentioned universities, and they typically seem to multihome with close topological proximity, if at all. Of course, such a large scale entity could then split their network , renumber some thousand hosts, and run bgp internally against the two halves that are connected to two different providers.;-( True. Well, this discussion here seems to me to go into a simplistic direction without looking at the real world. Exactly the opposite. I've tried to relate what I've seen. We help a LOT of people with BGP and other wierd routing situations. The argument that has been made is that geographically diverse multihoming is so prevalent that the world is effectively flat-routed today and must remain that way. And thus CIDR is useless. I'm not willing to concede such a point without a considerable amount of data. Note that the current routing tables do not seem to suggest that this is the case today (c.f., Andrew's comments about <8%). The economic arguments also lean towards this not becoming the case in the future. Note that anecdotal evidence is of limited interest as we know that there are certainly exceptions. There will always be some multihomed large entities, and this is better supported in a way that the people who PAY nsps/isps get an acceptable level of service. I don't follow this. Between NSPs there are, e.g. big multihomed entities. Or will then the traffic exchange for certain prefixes be limited to the geographically corresponding meetpoints? Then, if that meetpoint dies, an NSP could not route the prefixes that belong to that meetpoint through another one? In case we need to reiterate: the proposal is that there be an abstraction action boundary (AAB) above the level of the local providers. Such an abstraction constrains the scope of prefixes injected by sites that are multihomed "locally". Note that such an AAB need not occur at a major interconnect. Note that this does create a management cost on the providers, which I believe is entirely reasonable. On the other hand I don't see why aggregation should not support large scale multiple interconnection. Within the NSP network the aggregation is still valid, and only big prefixes would change in the routing. It does this just fine if the multihomed connection points are within the abstraction naming boundary. The 'Internet' I see is about 31000 routes large, that is about 4 to 6 Mbytes in table space. Where is the problem on a 64Mbyte router? It can (and has) doubled every nine months. BTW, just in case folks would like a real-world snapshot from a default-free router: 28591 network entries using 6536588 bytes of memory Route Source Networks Subnets Overhead Memory (bytes) bgp 1800 28456 117 1257212 4606508 External: 1637 Internal: 26933 Local: 3 That's 11Mb used just by BGP. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 12:48:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06482; Sun, 3 Sep 1995 12:48:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA01286; Sun, 3 Sep 1995 12:48:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA01280; Sun, 3 Sep 1995 12:40:19 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06337; Sun, 3 Sep 1995 12:40:17 +1000 (from kre@munnari.OZ.AU) To: George Herbert Cc: big-internet@munnari.OZ.AU Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: Your message of "Sat, 02 Sep 1995 10:53:54 MST." <199509021753.AA00513@mail.crl.com> Date: Sun, 03 Sep 1995 12:39:49 +1000 Message-Id: <15045.810095989@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Sat, 02 Sep 1995 10:53:54 -0700 From: George Herbert Message-ID: <199509021753.AA00513@mail.crl.com> Freedom to switch without renumbering would probably cause router lockup sometime next spring or early summer at current growth rates. There's something odd going on here. On one hand we have people saying that clients don't actually switch connections very often, as there are all kinds of costs in doing so - and consequently asking for renumbering isn't really going to be all that big a burden (overall). On the other hand, we have all this moving between providers going on, that is apparently going to make the routing tables explode unless people renumber. These don't quite reconcile to me, which is it really? The original CIDR docs assumed the first, and planned to be able to handle moving providers without requiring renumbering though it recommended it as a good idea where possible. kre From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 13:34:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07725; Sun, 3 Sep 1995 13:34:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA01339; Sun, 3 Sep 1995 13:33:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA01320; Sun, 3 Sep 1995 13:17:08 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07256; Sun, 3 Sep 1995 13:17:05 +1000 (from kre@munnari.OZ.AU) To: Alan Barrett Cc: big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: Your message of "Sat, 02 Sep 1995 21:52:14 +0200." Date: Sun, 03 Sep 1995 13:16:39 +1000 Message-Id: <15050.810098199@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Sat, 2 Sep 1995 21:52:14 +0200 (GMT+0200) From: Alan Barrett Message-ID: If X is multi-homed to P1 and P2 (and has address P1.X), and Y is multi-homed to P1 and P3 (and has routing address P1.Y), and if P1 is well-connected to P2 and to P3, then P1 can announce a route for the aggregate P1 to all its neighbours, announce a route for P1.X to P2 but not to P3, and announce a route for P1.Y to P3 but not to P2. P3 does not need a route to P1.X if it has a route to P1, and P2 does not need a route to P1.Y if it has a route to P1. Continue that analysis to consider what happens at the boundary between P2 and P3, work out where longest match sends packets in all the cases, and I suspect that even without considering the effort this would take to handle with hundreds (or more) of connections, and dozens of peers, you will abandon that as a strategy. For example, if Barney is multi-homed to Sprint and MCI, and gets address space from Sprint, then Sprint and MCI both need to carry Barney's routes internally, but Alternet, PSI, ..., need not carry Barney's specific routes, because they could be covered by a larger (Sprint) aggregate. And when the Spring link is down, no-one on Alternet knows of the MCI link, and the sites multi-homing is close to useless. On the other hand, if MCI advertise the route, Sprint may as well, as its the same prefix, if they don't (which would cut routing table sizes, but not forwarding) then all traffic from outside Sprint goes via MCI, which would mean sites would need to get addresses from their backup provider (which has been deliberately suggested before). The effect of that is that the link you're most likely to change (which is generally easiest to change, as it isn't used for much usually, and you're likely to want the cheapest available) is the one that has your address tied to it. Note that if both Sprint & MCI are advertising your prefix, which is the way you want it if you want to make use of both links in general operation, which is probably the common case (ie: traffic needs more than one link for capacity reasons, may as well get additional reliability by multi-homing), then there's no benefit at all gained by having address space from either Sprint or MCI's address blocks. If there were an aggregate that covered both of them (and excluded someone else) then an address from that block would make sense - but there isn't. kre From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 14:14:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08671; Sun, 3 Sep 1995 14:14:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA01404; Sun, 3 Sep 1995 14:13:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA01382; Sun, 3 Sep 1995 13:58:43 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08387; Sun, 3 Sep 1995 13:58:40 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id UAA22663; Sat, 2 Sep 1995 20:58:30 -0700 From: Dave Siegel Message-Id: <199509030358.UAA22663@seagull.rtd.com> Subject: Re: Multihoming To: tli@cisco.com (Tony Li) Date: Sat, 2 Sep 1995 20:58:29 -0700 (MST) Cc: mn@ios.com, big-internet@munnari.OZ.AU In-Reply-To: <199509030208.TAA08870@greatdane.cisco.com> from "Tony Li" at Sep 2, 95 07:08:19 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1352 Precedence: bulk > The 'Internet' I see is about 31000 routes large, that > is about 4 to 6 Mbytes in table space. Where is the problem on a 64Mbyte > router? > > It can (and has) doubled every nine months. BTW, just in case folks > would like a real-world snapshot from a default-free router: > > 28591 network entries using 6536588 bytes of memory > > Route Source Networks Subnets Overhead Memory (bytes) > bgp 1800 28456 117 1257212 4606508 > External: 1637 Internal: 26933 Local: 3 > > That's 11Mb used just by BGP. How many paths, though? Multiple paths to a particular destination consume memory as well, which becomes an issue with an NSP that decides to show up at too many interconnects/NAPs, and there are starting to be a *lot* of them showing up. Already, we have mae-east, mae-west, PB NAP, Ameritech, Sprint, and I hear that mae-la and mae-houston are in the works, as well as a few regional nap's starting up, like one in Atlanta. Clearly, engineering which of these you want to be at is an important decision, and it doesn't sound wise to be at all of them. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 14:15:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08737; Sun, 3 Sep 1995 14:15:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA01426; Sun, 3 Sep 1995 14:14:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA01385; Sun, 3 Sep 1995 14:02:15 +1000 Received: from Tetsuo.Communique.Net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08410; Sun, 3 Sep 1995 14:02:10 +1000 (from nectar@communique.net) Received: from tetsuo.communique.net (Tetsuo.Communique.Net [204.27.64.10]) by tetsuo.communique.net (8.6.12/8.6.12) with SMTP id XAA27254; Sat, 2 Sep 1995 23:01:53 -0500 Date: Sat, 2 Sep 1995 23:01:51 -0500 (CDT) From: Jacques Vidrine To: Sanjay Kapur Cc: Noel Chiappa , big-internet@munnari.OZ.AU, dhollis@gp.magick.net Subject: Re: Multihoming and CIDR In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk It went unnoticed by me, but that is probably because I am relatively new to this forum. Can the renumbering of complete organizations easily (say, within one week) be done with the technology we have today? I expect to hear answers of both "yes" and "no". In the case of "no", why not? We need to work on eliminating those reasons. Bill Manning and friends have made a good start of documenting practices that will result in a network that will be relatively easy to renumber. How do we educate Internet users? Maybe that is the responsiblity of ISPs. How do we educate ISPs? I dunno. The information is already freely available, but it is hard to be sure everyone with a Pentium machine with a Digiboard in it will track down this information when he/she begins reselling IP access. Let's assume for a moment that we get everyone educated, and that everyone designs their network so that they can get it renumbered withing a week. Now let's say a small to medium ISP has to renumber. Can the ISP get all of it's customers to renumber withing 6 months, or a year? How fast would the ISP and it's customers have to make the transition? I guess what my rambling boils down to is just a couple of questions: (1) When one must renumber, what are the time constraints? I think this is probably very dependant on the size of the address space that must be renumbered, and the number of individual organizations using that address space. (2) Can we quickly (say, within 9 months, before the routing tables have doubled again) deploy technology that will allow renumbering within the time frame of (1)? (3) If the answer to (2) is yes, is CIDR all we need until IPv6? If the answer is no, then whatever are we going to do? (Maybe by the end of this long weekend, Noel will have done some more thinking and have more to say about dynamic ANBs and AABs.) (4) (Most important?) How can we make sure that everyone who is making significant network architecture decisions is educated? Jacques Vidrine Communique, Inc. On Sat, 2 Sep 1995, Sanjay Kapur wrote: > On Sat, 2 Sep 1995, Jacques Vidrine wrote: > > > > Indeed, that is the point that I was leading up to. Wouldn't we all be > > better off discussing _how_ to renumber, instead of whining that we > > _can't_ or that it is too expensive. > > > > Jacques Vidrine Communique, Inc. > > > > It may have gone unnoticed, but I have proposed several alternatives all > dependent on not having static IP numbers. I have proposed among other > alternatives schemes that expand on Microsoft's WINS/DHCP system. > > To be acceptible, a numbering scheme has to incorporate an expansion of > the DNS so that the DNS knows the new address of a IP host name whose number > has changed. > > Sanjay Kapur > Kapur Business Systems, Inc. > From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 14:54:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09956; Sun, 3 Sep 1995 14:54:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA01475; Sun, 3 Sep 1995 14:53:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA01469; Sun, 3 Sep 1995 14:49:28 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09841; Sun, 3 Sep 1995 14:49:04 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: Your message of "Sat, 02 Sep 1995 17:02:21 MST." <199509030002.RAA06781@greatdane.cisco.com> Date: Sun, 03 Sep 1995 14:48:36 +1000 Message-Id: <15078.810103716@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Sat, 2 Sep 1995 17:02:21 -0700 From: Tony Li Message-ID: <199509030002.RAA06781@greatdane.cisco.com> Consumers are not going to multihome. This depends on your idea of what the consumer we are considering is. At times I suspect that the problem seems to be all those zillions of people who just got win'95 and are now able to connect to the internet without having to add in extra software (which many simply don't want to do) - and that giving all those people portable addresses and advertising them would bee a disaster. I agree completely - but we don't need bizarre rules to accomplish that, those people won't usually be able to justify more than a /28 (maybe /26 or /27 in a few odd cases), and often want just a /30 or even /32. To avoid problems with them we simply don't let registries with portable numbers allocate a number to them, it has to come from the provider (which I suspect it almost always will now anyway). The providers can assist by having 3 price levels lowest, for accepting a new number every time you connect (which will be just fine for large numbers of users). internediate, for a permanent number from the providers address block - which remains as long as the customer agreement remains (this is the basic leased address, with no IETF bureaucracy to make it happen). highest for advertising the customer's address. All the home users will want the cheapest of those that will work for them, which will almost always be the first, and they cease to be a problem, and you're right, they won't want multi-homing (they might have accounts at more than one provider, but they wouldn't use both at the same time, and will trivially renumber as they dial each one). Those aren't the users I care about, the ones of more interest to me are the commercial users of the net, with or without Bob Moskowitz paranoia (or prudence if you prefer), with about a hundred or so hosts, and so a /24 (maybe /22 or /23 for the slightly bigger ones). Those people will multi-home. They also have more difficulty renumbering (some need to be active all the time for business reasons, they can't just stop for 30 minutes to renumber). However you're right elsewhere, they will multi-home to local providers, they're not usually likely to put in long distance lines to do this. However, this does not mean that we can aggregate the local providers, as even if those providers aren't multi-homed themselves, their connections are not likely to be topologically close - why should they be? One provider may use Sprint for their connectivity, anotheer MCI, another Alternet, etc. The local providers are all serving the same market, they aren't necessarily even close topologically though - unless we decide to do some kind of geographic based forcing of interconnects (All of Sprint, Alternet, MCI, ... have to interconnect in each of El Paso, Seattle, Denver, Kansas City, New Orleans, London, Paris, Nice, Stockholm, Berlin, Bonn, Sydney, Perth, ... if they want to sell to any providers who are selling into those markets). At the minute end users aren't multi-homed as much as they might be, as until recently (like the last year or so) there really hasn't been enough reasonable alternatives for it to make sense. The cost for adding the redundcancy has to be justifiable - and further, the second provider has to be able to actually provide the service needed. When most of the "old boys" on the net connected, there simply was no option that way. As I think I said before, I'd like to become multi-homed, unfortunately at the minute there is only one provider here with enough connectivity to the world to make sense (connecting to someone with a 64Kb or 128Kb link to the world isn't wholly useful). Incidentally, when counting how much of the net is multi-homed and whether it makes a difference that matters or not, there are two things to avoid. The first is taking any notice of BGP (or even AS) info. I'm not about to get involved in any of that - I don't want to provide transit services for anyone, or anything close. All I want is for my providers to each advertise my net number - that can do that with static routes in their configs if they like, or by my sending them RIP for my net number, that they redistribute into their BGP, or whatever works). Second, and more important, there's no point doing a static count of this, what we have to investigate is the rate of growth - if multi-homing is growing exponentially, then the eventual routing plan is going to have to learn to cope with that, not just ignore it. kre From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 15:33:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11128; Sun, 3 Sep 1995 15:33:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA01556; Sun, 3 Sep 1995 15:33:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01550; Sun, 3 Sep 1995 15:25:12 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10917; Sun, 3 Sep 1995 15:24:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19311; Sun, 3 Sep 95 01:23:59 -0400 Date: Sun, 3 Sep 95 01:23:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030523.AA19311@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Precedence: bulk From: Robert Elz > Scott Ballew destroyed your inside A analysis ("proof") before I had the > chance... This description of Scott's contribution (which I *welcomed*, please note) is incorrect. My analysis was not incorrect (except as noted immediately below), it merely considered only part of the problem, and this is what Scott pointed out. I.e. it analysed how the routing would work with all links up, *not*: - i) whether the destination would still be reachable under various classes of link failure, and - ii) how optimal the routes would be if it was still reachable. There are important questions, and deserve a separate full-blown analysis. I don't have the energy to do the full-blown version of each of these; it's a fairly grind-the-crank thing, anyway, and rather boring. I will state (below) what I consider the important results to be, and leave a detailed analysis to the interested reader. His note did lead me to a bug in my original analysis (where the overhead, for optimal routes, can be lower inside A for the A.P.X address form than the A.X form; this is true only if the scope of the A.P.X advertisement from the other provider is limited, which has bad potential side-effects), but his chief contribution was elsewhere. Also, and equally imporant, his note *also*, it turns out, was not the full story: see below. (I hope Scott will get a chance to review my comments below and give an opinion as to their correctness.) In fact, once that is taken into account, my original conclusion (that provider-based addresses give comparable results, often with less routing overhead) not only only stands, but is reinforced. It's also important to realize not only what he did point out, but, morever, what the wider implications (which he did not state, but I will, below) are. For the question of whether it will still be reachable after a link to one provider fails, clearly we only have to look at the case of inside A. (If it's reachable inside A, then traffic from outside will also reach it, once it gets to A.) For the A.X form, clearly it's still reachable. The A.P.X form breaks down into two cases; the link to the "primary" provider (the one which the multi-homed entity has a provider-based address from) is the one that fails, and the "secondary" provider(s) are the links that fail. The latter case, failure of the secondary link, is easy; if the advertisement of that link stops properly, you will fall back to the primary. The former case, failure of the primary, turns out to be more complex than previously realized, though. Scott pointed out that you can lose all connectivity if the link to the primary fails. Actually, I think his results are "worst-case"; depending on the topology, and routing advertisment scopes, you may still be able to win. (His analysis only considers "all-or-nothing" AAB's for routing advertisements of X, which is probably why he missed this.) For example, suppose P1 is connected directly to P2, and the link from A.P1 to A.P1.X fails. If P2's connection has an AAB which includes P1, then if P1 knows that its link to X is down, traffic *will* still reach X even when the link from X to the primary is down. It will go via P1, and then on to P2, which may not be optimal, but connectivity will not be lost. In more general terms, covering cases in which the primary and secondary are not directly connected, the advertisements from the secondary have to have an AAB large enough to include the primary, as well as a path from the second to the primary (which an AAB that included the primary normally would, unless further link losses partition what used to be a contiguous AAB, cutting the primary out of it). If that is so, then loss of the primary link will *not* make the destination unreachable. Note that, depending on the topology, this may still be a lot less than the entire scope of A, an important result that will be considered below. This points out a bug in a previous statement I made: pick an existing abstraction naming boundary which includes your two connection points ... to make multihoming *keep delivering packets* when a link fails, a specific route has to be advertised throughout the smallest enclosing naming [boundary] which contains both (all) attachment points, irrespective of the form of the address. ... the AAB of a multihomed entity has to be *at least* the ANB of the smallest common naming abstraction. The correct version actually is somewhat more subtle, and differs for the A.X and A.P.X address forms. For the A.X form, the version given is correct. For the A.P.X form, however, the correct form is "a specific route has to be advertised through a scope which includes the secondary provider as well as the primary", or "the AAB of the advertisement by a secondary provider of a multihomed entity with a provider-based address has to include the primary and secondary providers, and a path between them". This makes sense when you think about it; the linking of the ANB and the AAB should have made me suspicious, since the detachability of the two is one of the key things I've been pushing. There is still an attachment for the A.X case, but only since an entity must be advertised throughout the smallest enclosing naming boundary, if there are not to be routing "black holes" (well, "black regions", actually). As a final note, the AAB of the secondary's advertisment of X ought to be large enough to encompass multiple paths from the secondary to the primary, otherwise two simultaneous failures (the link to the primary, and along the path between the primary and secondary within the AAB) will cause a loss of connectivity. This entire topic, the response of routing to *multiple* simultanous failures, is lengthy if carried out formally, and will not be treated further. Analysing how optimal the resulting routes will be is too long to get into. For instance, in the case using the scenario immediately above (scope of the AAB of P2's advertisment is less than A, P1's link to X fails), and where A.P? have an AAB which is larger than A, incoming traffic for A.P1.X will generally take the "best" route, since it will have to go (in many cases) to P1, before it can get to X. Etc, etc. In general, however, I expect the usual rule holds true: better routes mean more routing overhead. For instance, if the scope of P2's advertisement is A, then all routes to X inside A will still be optimal after the failure of the link to P1. Etc, etc. One thing I do suspect is true is that even with a limited scope for P2's AAB of A.P1.X, you will still get fairly decent routing inside A. (Draw a diagram for this.) Traffic which is coming from the part of A "behind" P1 has to go past P1 to get to P2 anyway. Traffic which is coming from the part "behind" P2 will find, as soon as it gets to P2, that it's there anyway. It's only stuff that starts out out on the sides that can lose; it will head to P1 when it could have headed directly to P2. How bad it is all depends on what P2's AAB of A.P1.X looks like (keep drawing!). If it's a long tube that connects P2 and P1, traffic coming from close to behind P2 will face an extra path of almost twice the distance from P1 to P2. For stuff that's about equidistant from P1 and P2, it's an increase of of the distance from P1 to P2. Etc. It's an interesting optimization problem to adjust the shape of the AAB to minimize the extra distances - but then again, you have to balance that against the overhead of the large AAB when the primary link is not down. (Once again we're back into this interesting territory where the shape of the optimal AAB is also influenced by the topology. Hmm. This needs some deep pondering to see what it Really Means.) Anyway, the implications of the above, are, I hope, clear. Multihoming with provider-based addresses *can* be *functional* in the presence of a lost link to a primary (albeit not optimal), with an AAB for the advertisement from the secondary which is much smaller than the entire enclosing ANB. This capability is *not* available with addresses of the A.X form. Moreover, there is an important implication of this for the case where A == U. What this says to us that: >*>*> Provider-based addresses for multi-homed sites allow us to use less than >*>*> global scopes for the advertisement of routing information about such >*>*> sites. Non-provider based addresses do not have this characteristic; they >*>*> require advertisment through the entire network. True, the resulting routes may not be optimal. However, the backup connectivity is achieved with lower routing overhead. This is a cost/benefit tradeoff which an architect cannot make, merely note and make available. Again, this result makes sense: what we are doing is "piggy-backing" on the existing advertisment of the primary provider throughout the entire network. That will serve to get us "close enough" that more specific routing information, spread over a smaller scope, will get us there. There is an even broader implication, which people have probably missed: much of these conclusions holds for geographic addressing too. So, for instance, if site is multi-homed in two different geographic entities, either i) it has to pick an address which is not part of either, or ii) it has to pick an address which is relative to one. In the former case, the only operational choice it has is to advertise that address globally (since, in general, there is no higher network toplogy-based naming boundary which can be used to limit the scope over which it needs to be visible). In the latter, the utility of any secondary connections depends on the scope over which routes are to be advertised. In fact, as far as I can tell on a brief examination, the situations appear to be very similar to those of provider-based, although complicated by the fact that the naming boundaries in geographic addressing are not as natural in terms of the topology. This is because, fundamentally, *both* geographic *and* provider-based addressing exploit the underlying characteristic of topology-based addresses, which is that the ability to aggregate routing data to control routing overhead comes only when addresses are topologically signifcant. So, there is no magic solution. TANSTAAFL. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 15:53:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11705; Sun, 3 Sep 1995 15:53:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA01600; Sun, 3 Sep 1995 15:53:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01593; Sun, 3 Sep 1995 15:42:53 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11440; Sun, 3 Sep 1995 15:42:46 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19422; Sun, 3 Sep 95 01:42:44 -0400 Date: Sun, 3 Sep 95 01:42:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030542.AA19422@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur Do you really want to propose a scheme that will eventually lead to governmental regulation of the Internet? That is just your conjecture as to the results. What evidence do you have that it will actually happen? Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 15:55:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11767; Sun, 3 Sep 1995 15:55:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA01626; Sun, 3 Sep 1995 15:55:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01579; Sun, 3 Sep 1995 15:39:17 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11209; Sun, 3 Sep 1995 15:39:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19397; Sun, 3 Sep 95 01:39:04 -0400 Date: Sun, 3 Sep 95 01:39:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030539.AA19397@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, nectar@communique.net Subject: Re: Multihoming and CIDR Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Jacques Vidrine what is wrong with the provider-based addressing that CIDR seems to encourage? I think the answer to that is "CIDR requires -some- (a lot?) of renumbering". Yeah, that and some smaller things, like, for multi-homed sites, biasing incoming traffic to arrive over the provider which the customer is addressed in. But that seems to be the main one, especially when changing providers, now that this business about provider-baed not working for multi-homing has been gone through. If renumbering were not an issue ... would CIDR not be a near-perfect solution in the global IPv4 Internet? Well, I think so. I guess there is some debate over how painful it will be, and for how long. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 15:56:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11815; Sun, 3 Sep 1995 15:56:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA01655; Sun, 3 Sep 1995 15:56:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01596; Sun, 3 Sep 1995 15:52:59 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11692; Sun, 3 Sep 1995 15:52:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19455; Sun, 3 Sep 95 01:52:46 -0400 Date: Sun, 3 Sep 95 01:52:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030552.AA19455@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, root@kbs.netusa.net Subject: RE: Multihoming Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur > Do you think the users would appreciate a functional network? users would appreciate a functional network where they had the freedom to choose one or more connections from and freely switch between a variety of openly competing providers. I would appreciate a world in which I had a different Ferrari to drive for every day of the week, and a special law exempting me from speed limits. Doesn't mean I'm going to get it... Your statement assumes that the conjunction of the two is possible. If it is not (any many of us who have studied the technical issues involved at great length think it is not), users have a choice of: i) a functional network, *or* ii) the freedom to switch between providers without changing addresses Which do you think they would pick? Also, you didn't formulate option ii) the way I put it above, but the way you phrased it - "the freedom to choose one or more connections from and freely switch between a variety of openly competing providers" - sounds to me like a perfectly good description of the net today. Your definition of "freely" includes "take my routing-name with me", which is where we part paths. That, I am sorry, is just not technically possible. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 15:57:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11850; Sun, 3 Sep 1995 15:57:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA01682; Sun, 3 Sep 1995 15:57:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01576; Sun, 3 Sep 1995 15:37:28 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11197; Sun, 3 Sep 1995 15:37:26 +1000 (from kre@munnari.OZ.AU) To: Jacques Vidrine Cc: big-internet@munnari.OZ.AU Subject: Re: Multihoming and CIDR In-Reply-To: Your message of "Sat, 02 Sep 1995 23:01:51 EST." Date: Sun, 03 Sep 1995 15:36:57 +1000 Message-Id: <15090.810106617@munnari.OZ.AU> From: Robert Elz Precedence: bulk Date: Sat, 2 Sep 1995 23:01:51 -0500 (CDT) From: Jacques Vidrine Message-ID: Can the renumbering of complete organizations easily (say, within one week) be done with the technology we have today? No. Though obviously the size of the organisation counts. I expect to hear answers of both "yes" and "no". Actually I don't, other than by assuming trivially small organisations, almost no-one claims renumbering is easy. In the case of "no", why not? No tools, and (more importantly), because currently numbers have more uses than anything any IP related tool can possibly hope to find and fix. (1) When one must renumber, what are the time constraints? This is actually a very good question, and one that should be addressed explicitly in any doc that advocates renumbering. My guess is that the relevant cidr draft's authors would have said it was not included as that level of policy wasn't being set there. However if the aim is really to be of use this won't do, as the ISP's (who had to set lease terms) would quickly learn that they could get a bit more business if they set more liberal lease terms (connect to me and you can have a lease that lasts 2 years after you disconnect, with him you only get 60 days...). Now with that, when a customer moves, his 2 year lease is effectively a portable address, if the new provider accepts it, then the leasing has been a waste of time. If not, that is if the new provider insists on renumbering in a shorter timeframe, then the leasing structure was not ever needed in the first place. So, a term limit needs to be set in policy if this tactic is to be of any use. As to the real question - how long? This is going to depend on worst case routing table sizes and and how much the net can handle growing routing tables without "breaking". If we assume that the routers all keep one doubling's worth of capacity free, then that's 5-9 months of growth they can handle. If we assume that everyone (currently) on the net were for some reason required to renumber, then we could effectively double the tables (actually much worse at lower levels, but stay with that for now), so the max that can be allowed would probably be about 4 months. Now that's for a fairly big provider needing to renumber, and hence all their clients (which is also what makes big spurts in routing table growth) - consequently their clients need much less than that, to allow for a safety margin, and so the provider has time to chase them if they aren't getting done in time. Say 2 months. Many of these will be smaller (local) providers - they are probably only be able to allow their clients 1 month. So, for end organisations, I'd suspect the limit would have to be of the order of a month - almost regardless of how much address space they have, but definitely dependant upon where they connect in the provider hierarchy. (2) Can we quickly (say, within 9 months, before the routing tables have doubled again) deploy technology that will allow renumbering within the time frame of (1)? No. End user technology (once developed, which this isn't) takes at least 3 years to deploy, 5 is probably closer. (3) If the answer to (2) is yes, is CIDR all we need until IPv6? If the answer is no, then whatever are we going to do? Look for a shceme that doesn't (ultimately) rely on end user renumbering... Some amount will probably be tolerated even without tools, and if it is not easy, provided it won't need to be repeated, ever. Very small organisations (private houses) also have no problems. (4) (Most important?) How can we make sure that everyone who is making significant network architecture decisions is educated? Even more interesting question. kre From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 16:14:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12320; Sun, 3 Sep 1995 16:14:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA01721; Sun, 3 Sep 1995 16:13:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01671; Sun, 3 Sep 1995 15:57:19 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11826; Sun, 3 Sep 1995 15:57:01 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA11091; Sat, 2 Sep 1995 22:56:29 -0700 Date: Sat, 2 Sep 1995 22:56:29 -0700 From: Tony Li Message-Id: <199509030556.WAA11091@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Subject: Re: Multihoming Precedence: bulk I wrote: Co-chair Tony Profuse apologies. Wrong mailing list. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 16:34:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12974; Sun, 3 Sep 1995 16:34:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA01765; Sun, 3 Sep 1995 16:33:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01758; Sun, 3 Sep 1995 16:29:35 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12833; Sun, 3 Sep 1995 16:29:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19840; Sun, 3 Sep 95 02:29:21 -0400 Date: Sun, 3 Sep 95 02:29:21 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030629.AA19840@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur As money is involved, it is best to clearly state your bias so that any potential for conflict of interest is avoided. It may actually be unethical for an employee to NOT advance and protect the interests of their employer in any legitimate manner. Ah. Well, that's easy to respond to, in my case. I don't work for anyone, not even myself. I'm more or less retired (temporarily), and do this because I have a wierd sense of what's fun. So, I can say whatever I darn well want, and do. It is best if your interests are well known so that your "technical" statements are taken with an appropriate pinch of salt. Yes, I've always found that the truth of "2+2=4" varies depending on the employment/bias/conflict-of-interest of the person saying it. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 16:34:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13047; Sun, 3 Sep 1995 16:34:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA01787; Sun, 3 Sep 1995 16:34:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01761; Sun, 3 Sep 1995 16:30:33 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12860; Sun, 3 Sep 1995 16:30:30 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA11421; Sat, 2 Sep 1995 23:29:57 -0700 Date: Sat, 2 Sep 1995 23:29:57 -0700 From: Tony Li Message-Id: <199509030629.XAA11421@greatdane.cisco.com> To: dsiegel@rtd.com Cc: mn@ios.com, big-internet@munnari.OZ.AU In-Reply-To: <199509030358.UAA22663@seagull.rtd.com> (message from Dave Siegel on Sat, 2 Sep 1995 20:58:29 -0700 (MST)) Subject: Re: Multihoming Precedence: bulk How many paths, though? Another snapshot: 28489 network entries (68520/108486 paths) using 6522028 bytes of memory Multiple paths to a particular destination consume memory as well, which becomes an issue with an NSP that decides to show up at too many interconnects/NAPs, and there are starting to be a *lot* of them showing up. True, but you should also understand that (at least with this implementation) the memory usage is sub-linear with respect to alternate paths. That is, if one path for a prefix takes memory X, then the memory for n paths is less than n*X. In fact, if I've read the code and done my arithmetic correctly (10% chance ;-), it's X + n*42. And X > 42. Already, we have mae-east, mae-west, PB NAP, Ameritech, Sprint, and I hear that mae-la and mae-houston are in the works, as well as a few regional nap's starting up, like one in Atlanta. Clearly, engineering which of these you want to be at is an important decision, and it doesn't sound wise to be at all of them. I would expect that the backbones WOULD want to be at all of them. But this is a fine opportunity for someone to teach me more economics... ;-) Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 16:35:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13069; Sun, 3 Sep 1995 16:35:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA01809; Sun, 3 Sep 1995 16:35:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01741; Sun, 3 Sep 1995 16:16:14 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12397; Sun, 3 Sep 1995 16:16:06 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id CAA20354; Sun, 3 Sep 1995 02:16:03 -0400 Date: Sun, 3 Sep 1995 02:16:02 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: RE: Multihoming In-Reply-To: <9509030552.AA19455@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Noel Chiappa wrote: > Your statement assumes that the conjunction of the two is possible. If it > is not (any many of us who have studied the technical issues involved at > great length think it is not), users have a choice of: > > i) a functional network, > *or* > ii) the freedom to switch between providers without changing addresses > > Which do you think they would pick? > > Also, you didn't formulate option ii) the way I put it above, but the way you > phrased it - "the freedom to choose one or more connections from and freely > switch between a variety of openly competing providers" - sounds to me like a > perfectly good description of the net today. Your definition of "freely" > includes "take my routing-name with me", which is where we part paths. > > That, I am sorry, is just not technically possible. > > Noel > Technical feasibility is tied to router design. I guess router designers will be unable to come up with a better and less limiting design quickly enough. Putting my consipiracy theorist hat on, it looks like router designers are not interested in alienating their major customers by depriving them of a chance at becoming a monopoly. I better start lobbying for regulation of the network monopolies that would result because of this lack of vision. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 16:37:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13097; Sun, 3 Sep 1995 16:37:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA01834; Sun, 3 Sep 1995 16:36:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01744; Sun, 3 Sep 1995 16:19:20 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12480; Sun, 3 Sep 1995 16:19:16 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA11278; Sat, 2 Sep 1995 23:19:14 -0700 Date: Sat, 2 Sep 1995 23:19:14 -0700 From: Tony Li Message-Id: <199509030619.XAA11278@greatdane.cisco.com> To: kre@munnari.OZ.AU Cc: root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, big-internet@munnari.OZ.AU In-Reply-To: <15078.810103716@munnari.OZ.AU> (message from Robert Elz on Sun, 03 Sep 1995 14:48:36 +1000) Subject: Re: Multihoming Precedence: bulk Consumers are not going to multihome. This depends on your idea of what the consumer we are considering is. [massive agreement elided...] However, this does not mean that we can aggregate the local providers, as even if those providers aren't multi-homed themselves, their connections are not likely to be topologically close - why should they be? Because the providers have economic factors similar to other users. And because today the geographical layout of the backbones is pretty similar. This is not coincidence. There's quite a bit of incestuousness because the telco's rent fiber from each other. And there's only so much fiber in the ground (of course, the Internet may cause more to be planted...). The result is that the Bay Area providers, for example, either end up connected via the NAP or Mae-West or Stockton. Because they're close to an interconnect, they become topologically close... The local providers are all serving the same market, they aren't necessarily even close topologically though - unless we decide to do some kind of geographic based forcing of interconnects. It's not necessary. Simply proxy aggregate based on the existing interconnects. We can be fairly sure that interconnects will continue to exist. And before someone objects, let me point out that the AAB should NOT be the interconnect itself. One might imagine dropping the AAB for the SF NAP to be the North American continental divide, for example. When most of the "old boys" on the net connected, there simply was no option that way. Baloney. I set up my first multihoming in 1987 between the ARPAnet and Cerfnet as part of the first round of the NSFnet regionals. And my particular site was dual homed to two other local sites. As I think I said before, I'd like to become multi-homed, unfortunately at the minute there is only one provider here with enough connectivity to the world to make sense (connecting to someone with a 64Kb or 128Kb link to the world isn't wholly useful). There are those economic factors at work... ;-) Incidentally, when counting how much of the net is multi-homed and whether it makes a difference that matters or not, there are two things to avoid. The first is taking any notice of BGP (or even AS) info. I'm not about to get involved in any of that - I don't want to provide transit services for anyone, or anything close. All I want is for my providers to each advertise my net number - that can do that with static routes in their configs if they like, or by my sending them RIP for my net number, that they redistribute into their BGP, or whatever works). I don't get this point. Second, and more important, there's no point doing a static count of this, what we have to investigate is the rate of growth - if multi-homing is growing exponentially, then the eventual routing plan is going to have to learn to cope with that, not just ignore it. Indeed. Let's hope that the multi-homing growth rate is something tolerable and that some of my locality arguments hold water. That or ATM can save the day.... Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 16:54:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13531; Sun, 3 Sep 1995 16:54:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA01870; Sun, 3 Sep 1995 16:53:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01815; Sun, 3 Sep 1995 16:35:58 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13067; Sun, 3 Sep 1995 16:35:55 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA11485; Sat, 2 Sep 1995 23:35:49 -0700 Date: Sat, 2 Sep 1995 23:35:49 -0700 From: Tony Li Message-Id: <199509030635.XAA11485@greatdane.cisco.com> To: mohta@necom830.cc.titech.ac.jp Cc: mn@ios.com, big-internet@munnari.OZ.AU In-Reply-To: <199509010648.PAA23261@necom830.cc.titech.ac.jp> (message from Masataka Ohta on Fri, 1 Sep 95 15:48:13 JST) Subject: Re: Multihoming Precedence: bulk > That depends on the failure that you're trying to protect against. Of course, what we need is the global reachability. For people communicating worldwide, mere local reachability is just meaningless. Yes, but transitivity applies (assuming routing is working). So local reachability to a point of global reachability implies global reachability. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 17:13:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14126; Sun, 3 Sep 1995 17:13:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA01921; Sun, 3 Sep 1995 17:13:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA01901; Sun, 3 Sep 1995 17:01:30 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13833; Sun, 3 Sep 1995 17:01:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19956; Sun, 3 Sep 95 03:01:18 -0400 Date: Sun, 3 Sep 95 03:01:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030701.AA19956@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, root@kbs.netusa.net Subject: Re: casting your multi-homing/provider-changing vote Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur Do you always try to win a debate by calling your opposite side in the argument stupid? No, I just lose my patience sometimes. Actually, I ought to realize that driving you away by making such assertions isn't as much fun as having you continue to post things that I can blow large funny holes in. (True, it's not as productive for the mailing list in the short run, but perhaps in the long run we'll get some relief.) I'll do as DCrocker suggests, and cease making direct assessments; if the readers form such assessments by looking at the ease with which things you say get blown up, I can hardly be blamed for what goes on in their minds, can I? > Hint: just because when you fall out of a tree, you break your leg, it > doesn't mean gravity is the result of a scheme designed by hospitals, > manufacturers of crutches, etc, etc. I am so disillusioned. I always thought gravity was such a conspiracy. We look forward to an eventual equal disillusionment on your part about the need to change addresses (i.e. routing-names) when you move to a different place in the topology. Overly optimistic, perhaps... > you're saying that there are no routing overhead ramifications for > picking up your address and taking it with you? Would you care to justify > that assertion with a technical argument? I am saying that routing overhead is not as important as the freedom to switch internet providers. Ah. Suppose the routing overhead is so high there's no functional Internet to connect to? What's the use of being able to switch to the world's best provider at the drop of a hat? A scheme that sounds good in theory may be a really bad scheme in practice if the service provider you are stuck with provides bad service. A scheme that sounds good in theory may be a really bad scheme in practice if the Internet ceases to function. > Hint: switch addresses and you're still "kbs.netusa.net". kbs.netusa.net is just one computer and is a bad example. A better example would be mit.edu. How much would everyone at mit.edu ... like to switch their IP address so that they could switch Internet service providers. You seem to have missed my point. Even if MIT *does* change their addresses, this machine will still be "ginger.lcs.mit.edu", and I don't have to reprint my business cards. And what if MY service provider (netusa.net) had to change addresses? Ah, so you did get a DNS name which is subsidiary to your provider. I will refrain from characterizing this... But those "routing-names" would be stored in a global repository much like DNS In other words, widespread use of a system like DNS could insulate users from changes in the routing-names? I don't suppose there's a lesson there for us with IPv4 addresses... I propose total flexibility. Why not design a system in which all numbers are leased for a limited amount of time. If we were forced to stay with top-down address allocation of a fixed-size space, such a scheme would actually not be irrational. However, I think bottom-up allocation of a variable sized routing-name is a better way to go. For IPv4, which is, irretrievably, top-down fixed-size, we'll just kludge it along for a while... if routers heirarchichaly give out numbers ... this has to be part of the numbering standard and not left upto another standard or upto each implementation. Yes, clearly not going to happen overnight. I think everyone sees that is where we have to go. [Also] the next generation of the DNS standard would have to require that the authoratative DNS get its information from the same router that handed out that address. Well, I think actually the host will have to update the DNS, if we have secure DNS entries. There are other issue, such as how do you find a DNS root server if its address can change, etc, etc. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 17:35:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14659; Sun, 3 Sep 1995 17:35:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA01980; Sun, 3 Sep 1995 17:33:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA01963; Sun, 3 Sep 1995 17:23:55 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14283; Sun, 3 Sep 1995 17:23:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20045; Sun, 3 Sep 95 03:21:57 -0400 Date: Sun, 3 Sep 95 03:21:57 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030721.AA20045@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur > Legislatures have power, I never disputed that But they CAN legistlate what routing is to be used. Umm, err, how does the (e.g.) US legislature say what kind of routing the (e.g.) European Internet is going to use? Or perhaps routing architectures in the Internet will change as we go across national boundaries. This should be interesting... (And here I was bitching and moaning about how crummy the IETF is at designing routing. Clearly I should count my lucky stars and pray. :-) I have been around intellectualls .. all my life and have more trust in a representative elected by the people to choose what is best for society than in an unelected intellectual. "So when the orator is more convincing [before a popular audience] than the doctor, what happens is that an ignorant person is more convincing than the expert before an equally ignorant audience." -- Plato, "Gorgias" Oh, well, what does he know; another unelected intellectual. Intellectualls and politicians did try to change mathematics. Do you remember the "New Math" craze of the 1960's Actually, I thought they tried to change what what *parts* of mathematics were taught, and *how*. Mathematics itself seems to have sailed serenely on... Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 17:38:59 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14818; Sun, 3 Sep 1995 17:38:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA09204 Sun, 3 Sep 1995 17:19:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA01943; Sun, 3 Sep 1995 17:16:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA01904; Sun, 3 Sep 1995 17:07:10 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13898; Sun, 3 Sep 1995 17:05:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20026; Sun, 3 Sep 95 03:05:15 -0400 Date: Sun, 3 Sep 95 03:05:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030705.AA20026@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz The problem here is that in today's internet, A == U, and outside A is irrelevant. See previous message. Provider-based offers either i) identical performance, at an identical cost, or ii) less-optimal performance at a lower cost. The only way to change that would be to aggregate the big providers Using limited AAB's and provider-based addresses provides essentially the same benfits, at the same cost. I.e. you're creating a boundary that has the same effective benefits as creation of an ANB, and leaking of the provider routes outside that ANB. (See analysis of the case where the AAB of A.P? was outside A.) At the minute, any real multi-homing, which means connecting to topologically widely dispersed providers, means spreading your route world wide, as there simply is no aggregation higher than the big providers, nor any rational way to draw circles that would make it a reasonable thing to do. No. You don't have to have ANB's to make this work. See previous message. This means, of course, that anyone who wants a stable number merely needs to connect to two (or more) of the major providers, directly or indirectly, then there is no point asking you to renumber for routing purposes, as your route will be advertised everywhere anyway, portable number, or provider dependant number. Again, incorrect. The effect of this, of course, is that routing stops scaling (yet again), and there is nothing at all in cidr to fix it. Ditto. > A mapping system ... would be nice, but the network is growing so fast > we don't currently have the time to do it this is equivalent to saying that we have too many cars on the roads, it would be nice to build new roads to handle them, but that takes so long that we can't get by with that (in the short term), so we will simply forget building new roads (Maybe some day), and instead install lots more traffic lights I don't know about down there, but up here this happens all the time, actually. But let's not argue the fine details of analogies; an analogy is just an analogy, and will break down if pressed hard enough. We have to start planning a solution that works, and is acceptable to all - it may be that we will need short term measures to get us by until the real solution is ready, that is not an argument for putting off the solutions to some other undetermined time. Sure. Is CIDR a "short-term measure" to me? Of course it is. Do I want to see a real solution? Of course. But I think you know what my idea of a real solution looks like, and it doesn't look like any simple mapping scheme. > the *only* way in which this whole situation will be brought under > control is to .. charge for routing advertisements, on a sliding scale > which takes into account the scope the more basic reason is that right now they can't deliver. They could charge OK, however $'s for many people is not the issue that really matters, they'd simply pay (any amount that wasn't basically the equivalent of a prohibition). That leaves the providers with lots of extra $'s OK, but apparently no good way to spend them to achieve the service that they're supposed to then be providing. You're right, the amounts would have to be large. I have a modest proposal (not very well baked, just throwing it out). A user's bill has two factors: the cost of the line from the user to the ISP (if the ISP is paying for this, otherwise this is zero), plus a factor related to the scope of their routing advertisement. In other words, the entire cost basis of the ISP; staff, plant, the lot, is divided up among customers on the basis of the size of their routing scopes. This is at least as fair as any other way of dividing it up, and it should generate some prety big numbers. if there was any way now that simply by spending more $'s the core providers could make this problem go away, then that would be the solution to adopt. The cost, obviously, would be passed back to the end users .. it is something that almost all of the net would prefer. Well, hanging a Cray off the side of a router is possible, but I don't believe that any router vendor has such a product under development, i.e. probably minimum of 18 months till this is available, if some ISP coughs up many million $ today to get it started, which gets us back to the old problem of how do we keep the net running and growing in the meantime? Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 17:53:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15317; Sun, 3 Sep 1995 17:53:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA02015; Sun, 3 Sep 1995 17:53:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA02000; Sun, 3 Sep 1995 17:37:05 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14701; Sun, 3 Sep 1995 17:36:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20129; Sun, 3 Sep 95 03:34:17 -0400 Date: Sun, 3 Sep 95 03:34:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030734.AA20129@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur I have a fourth choice that I prefer: Make the core routers MUCH bigger and MUCH faster. You're only about the 17th person to suggest this recently, most recently KRE. To repeat what I said to him when he suggested this, I don't believe that any router vendor has such a product under development; the market is perceived as too small. So, if some ISP coughs up many million $ today to get it started, if we start today, it's probably minimum of 18 months till this is available. This gets us back to the old problem of how do we keep the net running and growing in the meantime? In 128MB RAM all routes can be stored as Class C addresses in an array without the need for address search lists. Ah. Do you have any off-the-cuff guesses as to how routing overhead might scale for resources other than memory? What do you feel the complete list of such resources is? Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 18:34:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16557; Sun, 3 Sep 1995 18:34:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA02080; Sun, 3 Sep 1995 18:33:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA02065; Sun, 3 Sep 1995 18:18:23 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16096; Sun, 3 Sep 1995 18:18:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20244; Sun, 3 Sep 95 04:17:57 -0400 Date: Sun, 3 Sep 95 04:17:57 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030817.AA20244@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, hal9001@panix.com Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "Robert A. Rosenberg" > If we look at what the providers P? are advertising to A, there are > effective 3 useful cases. The first of these is that P? are both > advertising the specific prefix A.P1.X .. This case is uninteresting to > this discussion because if A accepts the more specific prefix, then > the X's prefix might as well be A.X. You are forgetting the advantage that this gives over Case 2 for someone who peers with P1 (but not P2). Any connects to X will route through P1 (if possible) instead of having to go off-into-the-boonies to locate some connection to P2. He's not comparing how well the two cases work when using the form A.P.X; that's not the intersting question here. He's comparing, for each case, how well A.X address works versus A.P.X; that *is* what we want to know about. > Case 2 is that P2 advertises the more specific route A.P1.X, along > with its own aggregate prefix A.P2 to A ... P1 advertises only its > aggregate prefix A.P1 to A. If all you want is automatic fall back routing (ie: Route all communications from anywhere except P1 through P2 unless P2 is down [at which point route through P1]), you want your address from P1's CIDR Block (as your Secondary) while having it announced through P2 (Your Primary). That's what he said, no? Neither of these cases apply when there is no A except for the Internet Itself. If I am an ISP and get my Connections from SprintNet and MCI there is no A they both get their connectivity (or addresses) from. In fact, they both apply. As I said in the original long message: It now remains only to use these results to generalize to a few other cases ... For one, the providers and multihomed entity are not inside some lower-level entity (i.e. A), but rather at the top level. In this case, the analysis is exactly the same as for the "inside A" case, with the containing entity being U, the universal object. There is no "outside U" case, clearly. Since both of his cases refer to the "inside A" case, they both apply to your example. Just delete the "A.", and consider use of P1.X and plain X. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 18:36:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16612; Sun, 3 Sep 1995 18:36:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA02102; Sun, 3 Sep 1995 18:36:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA02062; Sun, 3 Sep 1995 18:14:15 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15898; Sun, 3 Sep 1995 18:11:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20211; Sun, 3 Sep 95 04:07:39 -0400 Date: Sun, 3 Sep 95 04:07:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030807.AA20211@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, owen@delong.sj.ca.us Subject: Re: casting your multi-homing/provider-changing vote Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: owen@delong.sj.ca.us (Owen DeLong) > It is, in fact, not clear to me that a local provider will be able to > change even once. This is the most important thing to avoid. It, in effect, provides a monopoly position to upstream providers. This is a completely unacceptable thing to do to the local providers. We must find a way that small providers can be provided with address space that does not create aggregious problems when they wish to change providers. Hmm. Something of a point. I think that perhaps there is something that can be done, with exchange-point coops. The obvious question you're going to face, of course, from small customers, is "if small ISP's get to change their providers without changing their addresses, why can't we"? One way to answer than is to make exchange point coops open to all and sundry, but then you will discover that you have scaling problems in your intra-exchange-point mechanisms. For example, more or less the only way to do the routing in an exchange point (without having some routers there) is to advertise routes to each subscriber of the exchange point to all the upstream providers that service that exchange point. This won't work if the exchange point has a massive number of customers, etc, etc. Also, what if you fall out with your coop? Etc, etc... I think that is a bad side-effect of the easy-way-out solution to several other problems. Perhaps if IPv4 address portabiltiy had been raised as a big enough issue some years back, we might have been able to explore other options. No use crying about splilt milk, though. There are several technical problems that are easier to solve if we use the monopoly approach. This terminology makes me long for the good old days of "provider-based". It's only monopolistic if the local ISP's want somebody *else* to make their life easy, instead of trying to find a solution themselveso that does what *they* want. There's plenty of room within topology-based addresses for alternatives. Start an exchange-point WG. However, I don't think that should happen, as I agree that it is commercially and politically agregious. Yup, it's commercially and politically egregious that some people live longer than others; that should not happen. Therefore, we must solve the technical problem of how to preserve small-provider address portability without causing the routers to croak. We await your solution. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 18:53:54 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17166; Sun, 3 Sep 1995 18:53:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA02142; Sun, 3 Sep 1995 18:53:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA02138; Sun, 3 Sep 1995 18:45:27 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16919; Sun, 3 Sep 1995 18:45:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20339; Sun, 3 Sep 95 04:45:22 -0400 Date: Sun, 3 Sep 95 04:45:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030845.AA20339@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, ses@tipper.oit.unc.edu Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Simon Spero CIDR is designed as a stop-gap measure till IPv6 saves the world. Not to jump on IPv6 (not now, please), but other than easier (it says here) renumbering, how it IPv6 going to solve any of the problems we are discussing, such as support for multi-homing? My contention is that many of these problems will remain with us, and IPv6 has no magic bullet to solve them either. So, we best tackle them and see where we come out... Renumbering is painful, but can be bearable if it can be done over time. Yes, giving a (sub)network multiple IP addresses (which I guess most routers support) allows you to transition hosts one at a time, etc, etc. Wouldn't the effort spent on this discussion have been better spent on working on implementing IPv6? See point 1 above... Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 18:56:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17232; Sun, 3 Sep 1995 18:56:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA02177; Sun, 3 Sep 1995 18:55:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA02124; Sun, 3 Sep 1995 18:39:01 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16680; Sun, 3 Sep 1995 18:38:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20296; Sun, 3 Sep 95 04:37:52 -0400 Date: Sun, 3 Sep 95 04:37:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030837.AA20296@ginger.lcs.mit.edu> To: Valdis.Kletnieks@vt.edu, big-internet@munnari.OZ.AU, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur > All you need now is to figure out how to exchange 128M of lists when > there's a routing flap. ;) Where are all the brilliant graph theorists? Why can't they design a routing system not suspectible to a routing flap? Where are all the brilliant physicists? Why can't they design an engine that never needs any fuel? If you could explain to us how it's possible to have the routing react to a topology change without updating routing table entries, we'd all be interested. (This is particularly true of the current hop-by-hop forwarding architeture, where updating half the routing tables can lead to your traffic going in very small circles...) In case you think "routing flap" refers to the way some older Destination Vector algorithms respond to topology changes, where you get waves of updates washing around the system as it slowly damps to a new stable equilibrium, you need to read the BGP spec. The Path Vector design of BGP will cut out a lot of this. However, I'm too tired to figure out exactly how to characterize the improvement; perhaps Yakov or Tony can furnish a few words on this. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 19:37:45 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18359; Sun, 3 Sep 1995 19:37:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA13576 Sun, 3 Sep 1995 19:14:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA02212; Sun, 3 Sep 1995 19:13:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA02183; Sun, 3 Sep 1995 18:57:25 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17251; Sun, 3 Sep 1995 18:57:13 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20376; Sun, 3 Sep 95 04:56:56 -0400 Date: Sun, 3 Sep 95 04:56:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030856.AA20376@ginger.lcs.mit.edu> To: barrett@iafrica.com, big-internet@munnari.OZ.AU Subject: Re: Multihoming Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Alan Barrett If X is multi-homed to P1 and P2 .. and Y is multi-homed to P1 and P3 ... I suppose we could say that the AAB for the P1.X-->P1 abstraction is different from the AAB for the P1.Y-->P1 abstraction. It no longer seems useful to talk about the AAB for P1, because different pieces of P1.* may be subsumed into the P1 abstraction at different boundaries. Yes, this is what I called "non-congruent AAB's" in a message some days ago. if Barney is multi-homed to Sprint and MCI, and gets address space from Sprint, then Sprint and MCI both need to carry Barney's routes internally, but Alternet, PSI, ..., need not carry Barney's specific routes Right, and if his link to Sprint blows out, if Sprint notices this, and they have a direct link to MCI (intersting, wonder if the voice part of MCI is connected to the voice part of Sprint... but I'm wandering), they can send traffic to him through his link to MCI. A lot of traffic from outside the Sprint/MCI union (e.g. from everyone who is directly connected to Sprint as well as MCI) will wind up taking some extra hops through Sprint... This is what the long message this evening pointed out. > Look at what I said again; I said the smallest *naming* scope that > encloses both. ... to make multihoming work your address must be > adverised globally. I think you need some new terminology if your old terminology leads you to that incorrect conclusion. Not so much new terminology (what we have is adequate, so far as I can see), just a chance to think it all through. The statement you refer is indeed in error, as I noted in the message earlier this evening; a corrected version is in that. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 19:54:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18632; Sun, 3 Sep 1995 19:54:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA02275; Sun, 3 Sep 1995 19:53:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA02249; Sun, 3 Sep 1995 19:36:06 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18159; Sun, 3 Sep 1995 19:36:04 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id CAA10662; Sun, 3 Sep 1995 02:35:55 -0700 From: Dave Siegel Message-Id: <199509030935.CAA10662@seagull.rtd.com> Subject: Re: Multihoming To: root@kbs.netusa.net (Sanjay Kapur) Date: Sun, 3 Sep 1995 02:35:55 -0700 (MST) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 3, 95 02:16:02 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 803 Precedence: bulk > Technical feasibility is tied to router design. I guess router designers > will be unable to come up with a better and less limiting design quickly > enough. Putting my consipiracy theorist hat on, it looks like router > designers are not interested in alienating their major customers by depriving > them of a chance at becoming a monopoly. You are free to invest in the development of a better router, by all means. Let me know when it's available in 3 years, after the Internet is dead for waiting for it to hit the market, and I might buy one for prosperity. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 19:56:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18689; Sun, 3 Sep 1995 19:56:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA02306; Sun, 3 Sep 1995 19:56:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA02269; Sun, 3 Sep 1995 19:51:38 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18608; Sun, 3 Sep 1995 19:51:31 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id CAA10979; Sun, 3 Sep 1995 02:51:19 -0700 From: Dave Siegel Message-Id: <199509030951.CAA10979@seagull.rtd.com> Subject: Re: Multihoming To: tli@cisco.com (Tony Li) Date: Sun, 3 Sep 1995 02:51:19 -0700 (MST) Cc: dsiegel@rtd.com, mn@ios.com, big-internet@munnari.OZ.AU In-Reply-To: <199509030629.XAA11421@greatdane.cisco.com> from "Tony Li" at Sep 2, 95 11:29:57 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1343 Precedence: bulk > True, but you should also understand that (at least with this > implementation) the memory usage is sub-linear with respect to > alternate paths. That is, if one path for a prefix takes memory X, > then the memory for n paths is less than n*X. In fact, if I've read > the code and done my arithmetic correctly (10% chance ;-), it's X + > n*42. And X > 42. Oh, well this isn't nearly as bad as I suspected, unless, of course, X is 43. *grin* All that remains is a theoritical discussion of how route flaps might be magnified. ;-) > of these you want to be at is an important decision, and it doesn't sound > wise to be at all of them. > > I would expect that the backbones WOULD want to be at all of them. > But this is a fine opportunity for someone to teach me more > economics... ;-) Ideally, yes. More interconnects means less time before DS3's have to go OC3c, lower average latency to a site (presuming unsaturated links, of course), and more fault tolerance (your next preferred backup interconnect is likely to be a lot closer, too). If the routers can survive, I'm all for it. ;-) Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 19:59:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18822; Sun, 3 Sep 1995 19:59:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA02328; Sun, 3 Sep 1995 19:59:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA02255; Sun, 3 Sep 1995 19:37:47 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18358; Sun, 3 Sep 1995 19:37:45 +1000 (from dsiegel@rtd.com) Received: from RTD.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA14282 Sun, 3 Sep 1995 19:37:42 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id CAA10596; Sun, 3 Sep 1995 02:32:34 -0700 From: Dave Siegel Message-Id: <199509030932.CAA10596@seagull.rtd.com> Subject: Re: Multihoming To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Sun, 3 Sep 1995 02:32:33 -0700 (MST) Cc: big-internet@munnari.OZ.AU, root@kbs.netusa.net, jnc@ginger.lcs.mit.edu In-Reply-To: <9509030552.AA19455@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 3, 95 01:52:46 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1444 Precedence: bulk > > Do you think the users would appreciate a functional network? > > users would appreciate a functional network where they had the freedom to > choose one or more connections from and freely switch between a variety of > openly competing providers. > > I would appreciate a world in which I had a different Ferrari to drive for > every day of the week, and a special law exempting me from speed limits. > Doesn't mean I'm going to get it... The analogy I came up with tonight seems to fit the bill quite well. I wish I had the freedom to keep the same phone number when my company moves downtown Oct 1. After all, I'll have to have all my business cards reprinted for my staff and I, my ad in the Yellow pages will have the wrong number on it for the next 10 months, and all my brochures will have to be reprinted. Or, the alternative, is to pay by the mile to keep the phone number. Doggonit. USWest has a monopoly. Maybe I'll choose service from the local lightwave CAP. Oops, that doesn't work either. They can't route my prefix either. It's all a conspiracy. *note obvious sarcasm* There are things that people will have to live with. Renumbering isn't such a horrid thing. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 20:02:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18886; Sun, 3 Sep 1995 20:02:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA02350; Sun, 3 Sep 1995 20:02:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA02252; Sun, 3 Sep 1995 19:37:31 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18353; Sun, 3 Sep 1995 19:37:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20394; Sun, 3 Sep 95 05:06:42 -0400 Date: Sun, 3 Sep 95 05:06:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509030906.AA20394@ginger.lcs.mit.edu> To: barney@databus.com, big-internet@munnari.OZ.AU Subject: Re: Multihoming Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Barney Wolff > if Barney is multi-homed to Sprint and MCI, and gets address space from > Sprint, then Sprint and MCI both need to carry Barney's routes > internally, but Alternet, PSI, ..., need not carry Barney's specific > routes, because they could be covered by a larger (Sprint) aggregate. Not in practice. The more-specific route will be preferred. Which more specific-route? A more-specific route to you is only visible inside Sprint and MCI. Outside them, there are only routes to Sprint and MCI. Of course, this results in most of your inbound trafic from the rest of the world (e.g. all people are connected to Sprint, but not people who are connected to MCI and get to Sprint through MCI) coming in through your Sprint link. There are real issues about how to achieve, in practice, the benefit that multi-homing is intended to achieve, without global advertising. Mmm. First, you have to specify what benefit(s) it is you think you are getting. Fault-tolerance? Yah, that's not too hard. Even load-sharing? As we can see from above, a little harder. Optimal routing when both links are up? Optimal routing when only one link is up? Etc, etc, etc... If I get address space out of some "MAE-East" block (if such existed), what happens if some fanatic blows it up? The implication is that a topological address assignment strategy requires that an exchange point be distributed in space, not just a bunch of routers in a room. It becomes a >>2x cost, not <2x. Well, that's something we could talk about. However, I suspect this is not the right mailing to go doing detailed designs on... ("Free" is American slang for "not separately priced".) Oh, that's a good one! :-) Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 20:06:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18950; Sun, 3 Sep 1995 20:06:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA02374; Sun, 3 Sep 1995 20:06:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA02246; Sun, 3 Sep 1995 19:33:59 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18129; Sun, 3 Sep 1995 19:33:27 +1000 (from dsiegel@rtd.com) Received: from RTD.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA13230 Sun, 3 Sep 1995 19:02:44 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id CAA07038; Sun, 3 Sep 1995 02:02:25 -0700 From: Dave Siegel Message-Id: <199509030902.CAA07038@seagull.rtd.com> Subject: Re: Multihoming To: kre@munnari.OZ.AU (Robert Elz) Date: Sun, 3 Sep 1995 02:02:23 -0700 (MST) Cc: tli@cisco.com, root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, big-internet@munnari.OZ.AU In-Reply-To: <15078.810103716@munnari.OZ.AU> from "Robert Elz" at Sep 3, 95 02:48:36 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 7281 Precedence: bulk > This depends on your idea of what the consumer we are considering is. > > At times I suspect that the problem seems to be all those zillions > of people who just got win'95 and are now able to connect to the > internet without having to add in extra software (which many > simply don't want to do) - and that giving all those people > portable addresses and advertising them would bee a disaster. This is totally unfeasible. Most ISP's are dynamically assigning addresses upon logins, especially for Windows and Mac users. > I agree completely - but we don't need bizarre rules to > accomplish that, those people won't usually be able to justify > more than a /28 (maybe /26 or /27 in a few odd cases), and often > want just a /30 or even /32. To avoid problems with them we > simply don't let registries with portable numbers allocate a > number to them, it has to come from the provider (which I suspect > it almost always will now anyway). anything longer than a /24 hasn't been portable in quite a while. If a customer came to me with a partial subnet of a Class C, and wanted me to route it for him, I'd laugh at him. I don't think we're even talking about dialup connections to the Internet, though. dialup customers are not what's causing the problem. Dialup customers change providers every day, and don't expect to take their IP address with them, if they were ever assigned one. > All the home users will want the cheapest of those that will How many home users have a T1? > Those aren't the users I care about, the ones of more interest > to me are the commercial users of the net, with or without > Bob Moskowitz paranoia (or prudence if you prefer), with > about a hundred or so hosts, and so a /24 (maybe /22 or /23 > for the slightly bigger ones). Now we're talking. > Those people will multi-home. They also have more difficulty > renumbering (some need to be active all the time for business > reasons, they can't just stop for 30 minutes to renumber). Not necessarily. If this company buys service from a local ISP, and the ISP is dual or triple homed, the only thing in real danger of going down "uncontrollably" is the tail circuit, which would be an in town circuit. The chances of this happening are much less than a circuit with an IXC involved. If the corporation is truly concerned about protecting themselves, then they should pay their local RBOC for T1 service with a second T1 leaving via a different exit from their building, going to a different CO, etc. This should be all the dual-homing they need. If it's not, then they need a new provider. As for the re-numbering, if the network is designed to use bootp/dhcp, then renumbering shouldn't be too difficult. The only thing that will cause a headache is any Unix/VMS servers. So, just crank the ttl down on the DNS, and bring your staff in on a weekend, and change the 10-15 servers over, modify DNS, bring up dhcp/bootp assignments with a different block, and nobody knows any different when they come back into work the following Monday. > However, this does not mean that we can aggregate the local > providers, as even if those providers aren't multi-homed > themselves, their connections are not likely to be topologically > close - why should they be? One provider may use Sprint By definition, this should already be happening, since you can't advertise the same network (with the same prefix) twice in BGP (at least as far as I recall ;-). > for their connectivity, anotheer MCI, another Alternet, etc. > The local providers are all serving the same market, they > aren't necessarily even close topologically though - unless we > decide to do some kind of geographic based forcing of > interconnects (All of Sprint, Alternet, MCI, ... have to > interconnect in each of El Paso, Seattle, Denver, Kansas City, New > Orleans, London, Paris, Nice, Stockholm, Berlin, Bonn, Sydney, > Perth, ... if they want to sell to any providers who are selling > into those markets). This is not technically feasible at this point in time, unless we could nuke 95% of the current /24 announcements in the routing table. It looks great from a distributed bandwidth distribution architecture, but the bitter reality is that you'll want multiple paths to all customers off El Paso, and you'll still be exhanging all of your routes with the other big guys, so you're stuck with, what, 14 paths, not including the ones that already exist, and I'm sure you meant to include more.... I see router death in that future. > Incidentally, when counting how much of the net is multi-homed > and whether it makes a difference that matters or not, there > are two things to avoid. The first is taking any notice of > BGP (or even AS) info. I'm not about to get involved in any > of that - I don't want to provide transit services for anyone, > or anything close. All I want is for my providers to each > advertise my net number - that can do that with static routes in > their configs if they like, or by my sending them RIP for my > net number, that they redistribute into their BGP, or whatever > works). Unfortunately, you can't exactly ignore the technical requirements to dual home correctly. I think you'll find that if you try the above, when one of those links go down, you will loose connectivity to large portions of the Internet. This rather defeats the purpose. > Second, and more important, there's no point doing a static > count of this, what we have to investigate is the rate of > growth - if multi-homing is growing exponentially, then the > eventual routing plan is going to have to learn to cope with > that, not just ignore it. I don't think that's what we're trying to do. I think we *are* trying to cope with it. Unfortunately, while the Cisco 7500 looks like it's going to be a great router, it's a general concern that router technology might not be able to keep up with the current growth rate. Since the routing table doubles every 9 months, and there is a major breakthrough in technology every 2 years, approximately, it doesn't take a Phd in Mathematics to figure out that we could get behind the power curve pretty easily. The renumbering policy is one way to cope with the problems at hand. For the last two months, I have been undecided on the debate, and have finally decided that I am in support of renumbering. I think the matter can be handled delicately, so as to avoid defensiveness on the part of the customer. I have customers, just like everyone else, that told me when they were signing the contract for their dedicated service, that they wanted to make sure that they could take their Class C with them if/when they left our service, and I put it in the contract that they could. I am going to have to approach these people, and delicately explain the bitter truth, and discuss some options for network design that will ease the transition, should it occur, and it will *cost me* money, since I am inclined to provide these educations services to my direct customers at no cost to them. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 21:34:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21023; Sun, 3 Sep 1995 21:34:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA02475; Sun, 3 Sep 1995 21:33:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA02455; Sun, 3 Sep 1995 21:19:14 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB20495; Sun, 3 Sep 1995 21:19:11 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id EAA27954; Sun, 3 Sep 1995 04:19:00 -0700 Date: Sun, 3 Sep 1995 04:19:00 -0700 From: Tony Li Message-Id: <199509031119.EAA27954@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Subject: Re: Multihoming Precedence: bulk Replying to myself here: Between NSPs there are, e.g. big multihomed entities. Or will then the traffic exchange for certain prefixes be limited to the geographically corresponding meetpoints? Then, if that meetpoint dies, an NSP could not route the prefixes that belong to that meetpoint through another one? In case we need to reiterate: the proposal is that there be an abstraction action boundary (AAB) above the level of the local providers. Such an abstraction constrains the scope of prefixes injected by sites that are multihomed "locally". Note that such an AAB need not occur at a major interconnect. I should point out that I'm proposing that an AAB bisect an AS. I believe that we have this capability in BGP today, especially with the use of route reflectors (a hierarchical distribution of IBGP). The benefits of this are that it allows a restricted scope of abstraction information, disconnects the ANB from the AAB, and provides enough granularity near the AAB to provide for near optimal routes. The downside is the coordination of the AAB. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 21:39:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21098; Sun, 3 Sep 1995 21:39:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA02497; Sun, 3 Sep 1995 21:38:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA02469; Sun, 3 Sep 1995 21:33:31 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21007; Sun, 3 Sep 1995 21:33:29 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id EAA28087; Sun, 3 Sep 1995 04:33:26 -0700 Date: Sun, 3 Sep 1995 04:33:26 -0700 From: Tony Li Message-Id: <199509031133.EAA28087@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal Precedence: bulk In case you think "routing flap" refers to the way some older Destination Vector algorithms respond to topology changes, where you get waves of updates washing around the system as it slowly damps to a new stable equilibrium, you need to read the BGP spec. The Path Vector design of BGP will cut out a lot of this. However, I'm too tired to figure out exactly how to characterize the improvement; perhaps Yakov or Tony can furnish a few words on this. Thank you for that fine intro, Noel. ;-) One can envision a BGP path advertisement as a string which extends outwards from the advertiser. Route flap occurs in two basic ways: an endpoint of the string bounces (e.g., router crash), or a midpoint in that string crashes (e.g., link failure, loss of BGP connection). Either causes two things to happen. First, the part of the string from the point of the incision all the way out (away from the advertiser) is lost. The prefix is withdrawn. This forces a recomputation of possible alternate paths for the particular prefix and adjustment of the routing tables. Further the site must propagate the withdrawl of the advertisement to all "downstream" sites. This costs CPU and can cause packets to fall on the floor. Assuming that the incision heals itself, the string again is extended. An update will propagate outwards. A router learning this prefix may decide to damp the prefix, in which case it will retain the information but not act on it until later. Once the damping (if any) expires, the route is again recomputed and forwarded to downstream neighbors. They will subsequently perform the same actions (including damping). This is a flap. Back to the original question: "Why can't they design a routing system not suspectible to a routing flap?" Answer: because no one has been able to give us an invulnerable string. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 22:33:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22468; Sun, 3 Sep 1995 22:33:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA02567; Sun, 3 Sep 1995 22:33:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA02563; Sun, 3 Sep 1995 22:27:07 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22413; Sun, 3 Sep 1995 22:27:04 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id IAA01389; Sun, 3 Sep 1995 08:29:12 -0400 Date: Sun, 3 Sep 1995 08:29:10 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Discussing encap/mapping proposal To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, root@kbs.netusa.net, jnc@ginger.lcs.mit.edu In-Reply-To: <9509030734.AA20129@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Noel Chiappa wrote: > From: Sanjay Kapur > > I have a fourth choice that I prefer: Make the core routers MUCH bigger > and MUCH faster. no, make just the design better. who would buy a bus oriented box nowadays anyways? all the lemmings! and do route name tagging in the router, so that wherever I plug the router in, I tag the route name with a geographical tag and voila, we have full aggregation. Is this so difficult? Mike > > You're only about the 17th person to suggest this recently, most recently KRE. > To repeat what I said to him when he suggested this, I don't believe that any > router vendor has such a product under development; the market is perceived as > too small. So, if some ISP coughs up many million $ today to get it started, > if we start today, it's probably minimum of 18 months till this is available. > This gets us back to the old problem of how do we keep the net running and > growing in the meantime? > > In 128MB RAM all routes can be stored as Class C addresses in an array > without the need for address search lists. > > Ah. Do you have any off-the-cuff guesses as to how routing overhead might > scale for resources other than memory? What do you feel the complete list of > such resources is? > > Noel > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 22:54:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23044; Sun, 3 Sep 1995 22:54:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA02615; Sun, 3 Sep 1995 22:53:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA02573; Sun, 3 Sep 1995 22:34:29 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22489; Sun, 3 Sep 1995 22:34:18 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id IAA01396; Sun, 3 Sep 1995 08:36:22 -0400 Date: Sun, 3 Sep 1995 08:36:21 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Discussing encap/mapping proposal To: Noel Chiappa Cc: Valdis.Kletnieks@vt.edu, big-internet@munnari.OZ.AU, root@kbs.netusa.net, jnc@ginger.lcs.mit.edu In-Reply-To: <9509030837.AA20296@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Sorry , I can't resist: On Sun, 3 Sep 1995, Noel Chiappa wrote: > From: Sanjay Kapur > > > All you need now is to figure out how to exchange 128M of lists when > > there's a routing flap. ;) > > Where are all the brilliant graph theorists? Why can't they design a > routing system not suspectible to a routing flap? > > Where are all the brilliant physicists? Why can't they design an engine that > never needs any fuel? how about a bike? don't need a physicist for it. And relativity was done by a German 'IRS' official, by the way, who was kicked out of physics school. | | \ | -------- | | | / | (rest deleted) Mike ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 23:00:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23322; Sun, 3 Sep 1995 23:00:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA02648; Sun, 3 Sep 1995 22:58:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA02603; Sun, 3 Sep 1995 22:40:25 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22714; Sun, 3 Sep 1995 22:40:21 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id IAA01404; Sun, 3 Sep 1995 08:42:32 -0400 Date: Sun, 3 Sep 1995 08:42:31 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Multihoming To: Dave Siegel Cc: Sanjay Kapur , jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <199509030935.CAA10662@seagull.rtd.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Dave Siegel wrote: > > Technical feasibility is tied to router design. I guess router designers > > will be unable to come up with a better and less limiting design quickly man, look around. it is there. and routers are to transport traffic, not to calculate graphs. I have the little impression it is a vendor here who wants to affirm all routers suffer the same drawbacks. This discussion should really focus on the future addressing, and not how we can accomodate one vendor's boxes. If they don't survive, others will. Ask me in private for details. Mike > > enough. Putting my consipiracy theorist hat on, it looks like router > > designers are not interested in alienating their major customers by depriving > > them of a chance at becoming a monopoly. > > You are free to invest in the development of a better router, by all means. > Let me know when it's available in 3 years, after the Internet is dead for > waiting for it to hit the market, and I might buy one for prosperity. > > Dave > > -- > Dave Siegel President, RTD Systems & Networking, Inc. > (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco > dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, > http://www.rtd.com/ for an ISP." > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 23:06:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23419; Sun, 3 Sep 1995 23:06:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA02670; Sun, 3 Sep 1995 23:03:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA02606; Sun, 3 Sep 1995 22:42:01 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22768; Sun, 3 Sep 1995 22:41:58 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id IAA01411; Sun, 3 Sep 1995 08:44:11 -0400 Date: Sun, 3 Sep 1995 08:44:10 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Multihoming To: Noel Chiappa Cc: barney@databus.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9509030906.AA20394@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Noel Chiappa wrote: > From: Barney Wolff > > > if Barney is multi-homed to Sprint and MCI, and gets address space from > > Sprint, then Sprint and MCI both need to carry Barney's routes > > internally, but Alternet, PSI, ..., need not carry Barney's specific > > routes, because they could be covered by a larger (Sprint) aggregate. > > Not in practice. The more-specific route will be preferred. > > Which more specific-route? A more-specific route to you is only visible inside > Sprint and MCI. Outside them, there are only routes to Sprint and MCI. Of ouch!! > course, this results in most of your inbound trafic from the rest of the world > (e.g. all people are connected to Sprint, but not people who are connected to > MCI and get to Sprint through MCI) coming in through your Sprint link. > > There are real issues about how to achieve, in practice, the benefit that > multi-homing is intended to achieve, without global advertising. > > Mmm. First, you have to specify what benefit(s) it is you think you are > getting. Fault-tolerance? Yah, that's not too hard. Even load-sharing? > As we can see from above, a little harder. Optimal routing when both links > are up? Optimal routing when only one link is up? Etc, etc, etc... > > If I get address space out of some "MAE-East" block (if such existed), > what happens if some fanatic blows it up? The implication is that > a topological address assignment strategy requires that an exchange > point be distributed in space, not just a bunch of routers in a room. > It becomes a >>2x cost, not <2x. > > Well, that's something we could talk about. However, I suspect this is > not the right mailing to go doing detailed designs on... > > ("Free" is American slang for "not separately priced".) > > Oh, that's a good one! :-) > > Noel > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Sun Sep 3 23:08:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23533; Sun, 3 Sep 1995 23:08:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA02692; Sun, 3 Sep 1995 23:06:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA02609; Sun, 3 Sep 1995 22:50:27 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22966; Sun, 3 Sep 1995 22:50:21 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id IAA01417; Sun, 3 Sep 1995 08:52:10 -0400 Date: Sun, 3 Sep 1995 08:52:09 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Discussing encap/mapping proposal To: Tony Li Cc: big-internet@munnari.OZ.AU In-Reply-To: <199509031133.EAA28087@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Ok, then let's discuss how this can be remedied: how about caching all strings and only flag the one we use? When I look at my stats, the overall number of routes is fairly stable (yes, monotinic rising average). Why can them when they disappear? Just flag it as unavailable, take the (already calculated) next best available, and no traffic is exchanged. When the old buddy comes into the game again, we damp, right, and then we togle flags in memory. We only exchange trafic and advertisements when new kids come on the block, or when we did not hear for a long time from a disabled path. long time is here days or weeks. This makes that the memory is pretty much stable, and that the snapshot image of routes before the last software forced router crash can be loaded from .... yes, behind there ... flash, right. Of course, again for the fast shooters: there will still be a certain amount of adjustment of routes between routers, e.g. one comes up new. But flaps within the picture will be reduced to just that: flaps, not traffic of whole genealogic trees. Watch the flames now Mike On Sun, 3 Sep 1995, Tony Li wrote: > > In case you think "routing flap" refers to the way some older > Destination Vector algorithms respond to topology changes, where > you get waves of updates washing around the system as it slowly > damps to a new stable equilibrium, you need to read the BGP > spec. The Path Vector design of BGP will cut out a lot of > this. However, I'm too tired to figure out exactly how to > characterize the improvement; perhaps Yakov or Tony can furnish a > few words on this. > > Thank you for that fine intro, Noel. ;-) > > One can envision a BGP path advertisement as a string which extends > outwards from the advertiser. Route flap occurs in two basic ways: an > endpoint of the string bounces (e.g., router crash), or a midpoint in > that string crashes (e.g., link failure, loss of BGP connection). > > Either causes two things to happen. First, the part of the string > from the point of the incision all the way out (away from the > advertiser) is lost. The prefix is withdrawn. This forces a > recomputation of possible alternate paths for the particular prefix > and adjustment of the routing tables. Further the site must propagate > the withdrawl of the advertisement to all "downstream" sites. This > costs CPU and can cause packets to fall on the floor. > > Assuming that the incision heals itself, the string again is extended. > An update will propagate outwards. A router learning this prefix may > decide to damp the prefix, in which case it will retain the > information but not act on it until later. Once the damping (if any) > expires, the route is again recomputed and forwarded to downstream > neighbors. They will subsequently perform the same actions (including > damping). This is a flap. > > Back to the original question: "Why can't they design a routing system > not suspectible to a routing flap?" > > Answer: because no one has been able to give us an invulnerable > string. > > Tony > > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 01:14:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27408; Mon, 4 Sep 1995 01:14:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA03039; Mon, 4 Sep 1995 01:13:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA03030; Mon, 4 Sep 1995 01:13:02 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27347; Mon, 4 Sep 1995 01:12:57 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id KAA00175; Sun, 3 Sep 1995 10:59:21 -0400 Date: Sun, 3 Sep 1995 10:59:20 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Discussing encap/mapping proposal In-Reply-To: <9509030629.AA19840@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Noel Chiappa wrote: > Ah. Well, that's easy to respond to, in my case. I don't work for anyone, not > even myself. I'm more or less retired (temporarily), and do this because I > have a wierd sense of what's fun. So, I can say whatever I darn well want, and > do. > Noel > Ah, then you admit to being a loose canon looking for a job? :-) Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 01:15:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27515; Mon, 4 Sep 1995 01:15:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA03061; Mon, 4 Sep 1995 01:15:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA03033; Mon, 4 Sep 1995 01:13:15 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27353; Mon, 4 Sep 1995 01:13:09 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id KAA00163; Sun, 3 Sep 1995 10:30:23 -0400 Date: Sun, 3 Sep 1995 10:30:23 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: <9509030701.AA19956@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > No, I just lose my patience sometimes. Actually, I ought to realize that > driving you away by making such assertions isn't as much fun as having you > continue to post things that I can blow large funny holes in. (True, it's not > as productive for the mailing list in the short run, but perhaps in the long > run we'll get some relief.) OK > > I am saying that routing overhead is not as important as the freedom to > switch internet providers. > > Ah. Suppose the routing overhead is so high there's no functional Internet to > connect to? What's the use of being able to switch to the world's best provider > at the drop of a hat? > > A scheme that sounds good in theory may be a really bad scheme in practice > if the service provider you are stuck with provides bad service. > > A scheme that sounds good in theory may be a really bad scheme in practice if > the Internet ceases to function. I do not expect anyone to switch providers at the drop of a hat. No matter what scheme exists, switching providers would be expensive. I do want consumers (large and small) to be able to drop providers who are providing bad service or charging way too much than their competition. > > You seem to have missed my point. Even if MIT *does* change their addresses, > this machine will still be "ginger.lcs.mit.edu", and I don't have to reprint > my business cards. Kre has already responded on the feasibility and costs of renumbering. > Well, I think actually the host will have to update the DNS, if we have secure > DNS entries. There are other issue, such as how do you find a DNS root server > if its address can change, etc, etc. > > Noel > Have you looked at how Microsoft's WINS/DHCP does it and if it is scalable? Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 01:35:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28167; Mon, 4 Sep 1995 01:35:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA03098; Mon, 4 Sep 1995 01:33:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA03081; Mon, 4 Sep 1995 01:20:59 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27642; Mon, 4 Sep 1995 01:20:57 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id IAA22897; Sun, 3 Sep 1995 08:20:54 -0700 Message-Id: <199509031520.IAA22897@hubbub.cisco.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Multihoming and CIDR In-Reply-To: Your message of "Fri, 01 Sep 95 15:11:40 EDT." <9509011911.AA13049@ginger.lcs.mit.edu> Date: Sun, 03 Sep 95 08:20:53 PDT From: Yakov Rekhter Precedence: bulk Noel, > What it looks to me like we are going to have to do is some combination of > more rational topology engineering, more thought-out addressing boundary > setting, and more careful routing info scope configuration. The addressing > will still be "topology-based", but not "provider-based". I don't think the > routing will handle advertising every multi-homed site throughout the entire > Internet. > > For instance, we might want to look at creating "exchange points" in the net, > which will provide naturally more restricted scope boudaries (i.e. you can > then wrap a higher level abstraction around that exchange point, and all the > local ISP's which get access to the rest of the net through it; making it > reliable by duplicating as needed, but in a shared way so the cost isn't 2x, > isn't hard). That way, the larger scope of advertisements needed for > multi-homing can be less than the entire Internet. Did you have a chance to look at draft-rekhter-stratum-aggregation-01.txt ? Yakov. From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 01:53:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28563; Mon, 4 Sep 1995 01:53:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA03136; Mon, 4 Sep 1995 01:53:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA03130; Mon, 4 Sep 1995 01:47:18 +1000 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28476; Mon, 4 Sep 1995 01:47:14 +1000 (from swb1@cornell.edu) Received: from [132.236.236.26] (CU-DIALUP-0116.CIT.CORNELL.EDU [132.236.236.26]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id LAA18179; Sun, 3 Sep 1995 11:47:04 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 3 Sep 1995 11:48:33 -0400 To: Tony Li From: Scott W Brim Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk At 02:07 08/31/95, Tony Li wrote: > It IS a claim that provider-based addressing may have looked good > once, but the Internet and its users have changed, and now its > problems outweigh its benefits. > >I would be very interested in knowing what you think has changed. >These are the exact same points and issues that we've been discussing >(and discussing, and discussing, and discussing) for the last three >years. I *think* the rest of your response to my message has been covered by others. I believe the business significance of an Internet connection has increased rapidly, that the Internet is now a strategic business tool. That's the big change. For anyone making money over the Internet, connectivity is financially rather important. However, wrt reliability, individual providers aren't keeping up with the rate at which the Internet's business importance is increasing (partly because of the routing thrash we're seeing at the interconnect points ... hmmm ...). Anyway, apparently connecting to multiple major providers, either directly or through local providers which are connected to multiple major providers, satisfies their needs, and connecting to one provider multiply does not. This trend -- I can't call it a "surge" without documentation, and all I can give you is an aggregate subjective feeling about what's rolled past my eyes and ears in recent months -- this trend is based on a strong perceived need by the customers, and the engineering solution embodied in the document goes against it, it sets you up for dissatisfaction on all sides. You say you don't see a lot of evidence for a desire to multihome between providers, while I hear more of it every day. In tiny Ithaca, our 2 local commercial ISPs both say potential customers frequently ask them if they're multiply connected. I'm sorry I can't give you solid evidence. I hope the IESG or someone will actually go out and do a real survey of customers and smaller providers. I also look forward to revisions of the document. ...Scott p.s. just to be sure we're talking about the same thing, geographically diverse multihoming is not what people are after. I see them connecting to different large-scale providers (directly or indirectly) within the same geographic area. I've seen a couple of messages from Tony which make me wonder if he thinks we're talking about geographic separation of access points for a lot of organizations. We're not. From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 02:13:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29308; Mon, 4 Sep 1995 02:13:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA03243; Mon, 4 Sep 1995 02:13:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA03237; Mon, 4 Sep 1995 02:12:55 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29301; Mon, 4 Sep 1995 02:12:53 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id JAA23864; Sun, 3 Sep 1995 09:12:44 -0700 Message-Id: <199509031612.JAA23864@hubbub.cisco.com> To: Sanjay Kapur Cc: big-internet@munnari.OZ.AU Subject: Re: Multihoming and CIDR In-Reply-To: Your message of "Sat, 02 Sep 95 20:44:40 EDT." Date: Sun, 03 Sep 95 09:12:43 PDT From: Yakov Rekhter Precedence: bulk Sanjay, > It may have gone unnoticed, but I have proposed several alternatives all > dependent on not having static IP numbers. I have proposed among other > alternatives schemes that expand on Microsoft's WINS/DHCP system. > > To be acceptible, a numbering scheme has to incorporate an expansion of > the DNS so that the DNS knows the new address of a IP host name whose number > has changed. Work is in progress in the DNSIND WG to specify a mechanism for dynamic DNS updates (see draft-ietf-dnsind-dynDNS-03.txt). This would allow a host to update DNS with the host's new IP address. Yakov. From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 02:15:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29384; Mon, 4 Sep 1995 02:15:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA03263; Mon, 4 Sep 1995 02:15:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA03167; Mon, 4 Sep 1995 01:58:32 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28838; Mon, 4 Sep 1995 01:58:30 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id LAA14804; Sun, 3 Sep 1995 11:58:21 -0400 Date: Sun, 3 Sep 1995 11:58:21 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: Dave Siegel Cc: Noel Chiappa , big-internet@munnari.OZ.AU, root@kbs.netusa.net Subject: Re: Multihoming In-Reply-To: <199509030932.CAA10596@seagull.rtd.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Dave Siegel wrote: > There are things that people will have to live with. Renumbering isn't such > a horrid thing. It's pretty horrid, but it's much better than the alternative. Would you rather break an arm or have your head cut off? (I know, that's a pretty gruesome analogy, but after reading this discussion enough....) -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 02:18:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29438; Mon, 4 Sep 1995 02:18:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA03287; Mon, 4 Sep 1995 02:18:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA03180; Mon, 4 Sep 1995 02:03:50 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28956; Mon, 4 Sep 1995 02:03:39 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id MAA00391; Sun, 3 Sep 1995 12:03:25 -0400 Date: Sun, 3 Sep 1995 12:03:24 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Discussing encap/mapping proposal In-Reply-To: <9509030721.AA20045@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk I am forced to respond below because there were a few side swipes taken at me. I would like to terminate this thread since we are straying further and further away from the real issues. On Sun, 3 Sep 1995, Noel Chiappa wrote: > > But they CAN legistlate what routing is to be used. > > Umm, err, how does the (e.g.) US legislature say what kind of routing the > (e.g.) European Internet is going to use? Or perhaps routing architectures in > the Internet will change as we go across national boundaries. This should be > interesting... > > (And here I was bitching and moaning about how crummy the IETF is at designing > routing. Clearly I should count my lucky stars and pray. :-) Yes. The Internet has been very lucky so far in that governments have not tried to really regulate it. I pray no one gives governments reasons to start regulating the Internet. Until very recently, telecommunications was a government owned monopoly in most parts of the world. What can be deregulated quickly can also be reregulated quickly. > "So when the orator is more convincing [before a popular audience] than the > doctor, what happens is that an ignorant person is more convincing than the > expert before an equally ignorant audience." -- Plato, "Gorgias" > Trust an intellectual to cite Plato. My father always told me that a true expert can explain anything in their area of expertise to a lay man succinctly. Intellectuals normally can not do that and are rarely true experts at doing anything in the real world. > Oh, well, what does he know; another unelected intellectual. I do believe that you know a lot when it comes to routing. I just believe that experts, especially those of the intellectual variety, should be consultants to the real decision makers. Intellectuals and most experts in general are usually very bad decision makers because they ignore everything outside their very narrow point of view. The narrow point of view is what makes them experts in the first place. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 02:20:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29673; Mon, 4 Sep 1995 02:20:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA03309; Mon, 4 Sep 1995 02:20:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA03223; Mon, 4 Sep 1995 02:09:07 +1000 Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29266; Mon, 4 Sep 1995 02:08:58 +1000 (from hcb@clark.net) Received: (hcb@localhost) by clark.net (8.6.12/8.6.5) id MAA19335; Sun, 3 Sep 1995 12:08:11 -0400 From: Howard Berkowitz Message-Id: <199509031608.MAA19335@clark.net> Subject: Re: Multihoming To: tli@cisco.com (Tony Li) Date: Sun, 3 Sep 1995 12:08:11 -0400 (EDT) Cc: root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <199509030002.RAA06781@greatdane.cisco.com> from "Tony Li" at Sep 2, 95 05:02:21 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2587 Precedence: bulk > > > If Internet service is going to reach the "consumer", it has to have > reliability similar to or greater than telephone/cable/water/power or any > other utility. > > Consumers will demand that level of reliability. And service providers will > give it to them through features like multi-homing. The key word here is "like." In a "conventional" router network, especially in small networks, dial backup and similar features are used long before BGP multihoming. > > Consumers are not going to multihome. Do you have two water lines to > your house? No, but as a telecommuter, I have multiple phone lines with alternative phone numbers to reach the provider at different POPs. Even if the economics of out-of-pocket or what-my-boss- will-pay-for and I get ISDN or FR to the house (and by extension the small LAN), I will retain these alternatives. On the other hand, I use Internet services to earn a living. I don't demand the same reliability of my CATV system, because that's entertainment. Even there, I have a limited "multihome" capability of going to an antenna, of course losing the cable channels and losing signal quality on the rest. > > Yes, the provider may be multihomed. That's a _very_ different case. This is one of the key points. The cost of local loops is such that I can't afford diverse physical routing to the local telco switch. I am considering, however, changing ISPs unless their viable multihoming improves--their particular upstream connectivity is IMHO unreliable. One of the reasons I stay with them (aside from the inconvenience of changing) is they have widely dispersed POPs. Will the average Internet "consumer" make distinctions on where the points of failure are in their local provider?> Probably not. > > Yes, users would appreciate a functional network where they had the > freedom to choose one or more connections from and freely switch between a > variety of openly competing providers. > This has been a bit rambling, but the essence is that we need to back off, IMHO, to think of user organization (at least small user) "multihoming" in exterior routing terms, and focus more on their physical connectivity alternatives to local ISPs. Even for the larger user, we need to think whether that larger user will pay for the detailed exterior routing knowledge needed to manage multihoming. Telephone service remains critical for organizations of rather large size, but even in large organizations, there isn't going to be much knowledge of SS#7, ATM NNIs, WAN SONET, etc. Howard From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 02:56:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00761; Mon, 4 Sep 1995 02:56:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA03368; Mon, 4 Sep 1995 02:53:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA03362; Mon, 4 Sep 1995 02:46:16 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00492; Mon, 4 Sep 1995 02:46:11 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id MAA00576; Sun, 3 Sep 1995 12:45:25 -0400 Date: Sun, 3 Sep 1995 12:45:24 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Dave Siegel Cc: Noel Chiappa , big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: <199509030932.CAA10596@seagull.rtd.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Dave Siegel wrote: > > The analogy I came up with tonight seems to fit the bill quite well. > > I wish I had the freedom to keep the same phone number when my company moves > downtown Oct 1. After all, I'll have to have all my business cards reprinted > for my staff and I, my ad in the Yellow pages will have the wrong number on > it for the next 10 months, and all my brochures will have to be reprinted. > > Or, the alternative, is to pay by the mile to keep the phone number. > Doggonit. USWest has a monopoly. Maybe I'll choose service from the local > lightwave CAP. Oops, that doesn't work either. They can't route my prefix > either. It's all a conspiracy. *note obvious sarcasm* > I do NOT get your sarcasm since what you have described is a real problem and people are actually working on it quite a bit. The above description of the way things work is the reason telephone service is regulated as a monopoly. The purpose of regulation is to prevent the telephone company from taking undue advantage of their monopoly position. This is also precisely why local telephone number portability is an issue before the FCC and the Congress. Toll free number portability has already been implemented. There is no consumer protection system built into the Internet except the free market and forcing renumbering curtails that free market. > There are things that people will have to live with. Renumbering isn't such > a horrid thing. Whether it is horrid or not depends on which side of the fence you are on. It is a bonanza for vendors (like you) who can effectively make their customers captive and charge higher rates. Additionaly, when customers have to renumber, they will have to hire consultants to help them which is again a bonanza for certain members of this list. > > Dave > > -- > Dave Siegel President, RTD Systems & Networking, Inc. > (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco > dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, > http://www.rtd.com/ for an ISP." > Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 03:16:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01348; Mon, 4 Sep 1995 03:16:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA03426; Mon, 4 Sep 1995 03:13:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA03420; Mon, 4 Sep 1995 03:12:44 +1000 Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01237; Mon, 4 Sep 1995 03:12:38 +1000 (from vjs@mica.denver.sgi.com) Received: from mica.denver.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id KAA28666; Sun, 3 Sep 1995 10:12:22 -0700 Received: by mica.denver.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for Big-Internet@munnari.OZ.AU id LAA02175; Sun, 3 Sep 1995 11:11:45 -0600 Date: Sun, 3 Sep 1995 11:11:45 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199509031711.LAA02175@mica.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: ISP shakeout Precedence: bulk > From: Tony Li > ... > I can't help but to respond to this: it's very clear that no one is > instuting a monopoly. In fact, there is so MUCH competition in the > ISP market right now (140 in the SF Bay Area) that there is _bound_ to > be a major fall out. The winner is likely to be the provider that > handles the scaling issues (provisioning of modems, cycles, bw, etc.) > the best. > ... I've also been saying for a long time there will soon be a big shakeout among ISP's, but I could be wrong. Consider the Indian model of cable TV systems, as frequently described in the Wall Street Journal. (I don't have any idea if the WSJ is right. For my purposes, it probably doesn't matter.) Supposedly, someone in an appartment building will buy a bunch of VCR's and perhaps a C- or K-band satellite dish, string coax to all neighbors within several hundred feet, and go into the cable-TV-with-video-on-demand business. Supposedly such tiny systems a major part of the cable-TV market in India. Why won't the equivalent happen with front-line Internet Service Providers in the U.S? Why won't individuals have accounts on neighborhood ISP's, each ISP with only between a dozen and a 1000 customers? The ISP's would like the corner pizza parlor, video store, or bar, contracting with big outfits for connectivity and run from someone's basement, family room or bedroom. Perhaps a better analogy would be with BBS's. CompuServ and Prodigy did not exactly drive out of business their zillions of tiny competators. If that happens, the main effect I can as far as multi-homing concerns the popularity of somethign like mobile-IP. Doesn't mobile-IP make difficult renumbering much common, since it competes with dynamic IP address assignment via something like PPP or DHCP? Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 04:13:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02738; Mon, 4 Sep 1995 04:13:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA03500; Mon, 4 Sep 1995 04:13:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03483; Mon, 4 Sep 1995 04:07:46 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02691; Mon, 4 Sep 1995 04:07:42 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id OAA01451; Sun, 3 Sep 1995 14:09:57 -0400 Date: Sun, 3 Sep 1995 14:09:56 -0400 (EDT) From: "Michael F. Nittmann" Subject: addressing proposal To: big-internet@munnari.OZ.AU Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Here is what I am thinking of how the addressing could be solved: the address has hierarchical parts: Part A: network address in the current sense Part B: private tag 1 Part C: Part D: Provider Internal Tag Part E: Provider ID Part E would correspond to the AS number (can well be that same thing) Part D would give a sub-AS hint which would group within a provider Parts B,C: purely provider internal aggregation tags Part A: the IP address of the target (network/host) An entity wishing to connect to the Internet would as usual get an address space. This is all that entity has to worry about. The next upline provider's routing process (router or route processor) tags these addresses at the exit point(s) to the entity with the provider internal tag. All addresses that belong to that entity are now routed under the umbrella of that tag: one route. Evaluation of the route is done only up to that tag. All addresses under it are aggregated. Thisaggregation scheme quits the simplistic bitmap scheme. Only the last router that tagged the (within the provider uniqque) aggregation tag will then expand beyond it and enter more detailed routing info processing. Within a provider's network, additional aggregation steps with more tags may occur. This address is of variable length. It can be implemented rather fast by using IP option fields for additional tags. Upstream provider: at each exit point, the upstream provider's router provides an entry point tag, also unique. The upstream provider only routes on the basis of that tag. The downstream provider can announce routes under different exit points, where they receive different tags (or routing names). The upstream provider gets a limited amount of route names at each meetpoint. Here a provider could charge by route. His downstream customers have the motivation to aggregate as much as possible. And so on until the transit providers to the meetpoints. What this does: everybody can keep his number, since that one is of no siginificance on the higher levels of routing. The device at the exit point tags and so it is at the discretion of the network architect (that's me ;-) ) to decide how to aggregate. The tags can be small numbers, smaller for lower hierarchies. The address looks the same in each hierarchy, since the higher tags are stripped at the upstream gateway. Uniqueness is only required within one provider's networks. This would also solve the AS number problem. Needs distributed registration: a provider registers the 'AS' numbers of his downline. BUT: the downline does not need to care. those at the meetpoints receive their AS numbers from Internic. (this is not monopoly, this is a relief for Internic). those providers then run their registry for their dependents. If a dependent leaves, he is stripped from the registry and entered into a new one, with their unique tag. That second level AS number has only significance within the upline provider. Today we do a tautological break in topology by registering all AS numebrs at the same level, although most of them only appear at second or greater place in AS paths. No, I don't accept objections of 'impossible to encode'. I know how to do it, I know what HW to use to make this parsing a one instruction issue, so do the experts who pretend that the status quo sold old stuff is all they can do for us. No, linear memory won't do, buy content addressable or die, support stochastic strided arrays and build more than off the shelf cheapo. Devices that can do this ARE NOW on the market. And: portability of addresses is there, and more: we don't need unique addresses at all, since the next upline tag makes them unique. Now the reverse path: I am at the bottom here with my host and I want to go to 123.4.5.6.7 in provider X's network, buried 6 levels up and then after the meetpoint 3 levels down. Well, here is the first mistake: who wants to go to 123.4.5.6? I go to thathost.in.the.other.domain.dot . The dns gives me back anything. DNS is not limited to 4 fields, although most braindead code pretends this. DNS has the full target address, up to the last level of tags within the provider where the host resides. All networks of that provider collapse in the routing tables to one route to each exit point of that provider network. The rest is the same as now: who knows the route to ASxxx (and not to host.in.network.x ). The number of providers grows fast two, but will logically be always way smaller than the number of networks. If you want, it looks like hierarchical IP encapsulation. But it is fully dynamic: change of providers is totally possible at all levels of the food chain. With no renumbering at all. And every NSP can aggregate ad gusto, geographically, or whatever. And we could charge: who has more downlines can pay more to the upline for their routing. Or aggregate everything so nicely that it is one route at each exit point. This might fit into IPv6 address syntax. On the host level, no new SW is required. Only the graph calculating processors are to be modified, be it the routers or just route servers. Can we talk constructively about this? Mike ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 04:36:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04385; Mon, 4 Sep 1995 04:36:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA03542; Mon, 4 Sep 1995 04:33:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03536; Mon, 4 Sep 1995 04:31:16 +1000 Received: from Daisy.ee.und.ac.za by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03945; Mon, 4 Sep 1995 04:30:46 +1000 (from barrett@daisy.ee.und.ac.za) Received: by daisy.ee.und.ac.za (Smail3.1.28.1 #31) id m0spJo4-0007VvC; Sun, 3 Sep 95 20:30 GMT+0200 Date: Sun, 3 Sep 1995 20:30:08 +0200 (GMT+0200) From: Alan Barrett X-Sender: barrett@daisy.ee.und.ac.za To: Barney Wolff Cc: big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: <9509021738.AA23837@databus.databus.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > From: Barney Wolff > > For example, if Barney is multi-homed to Sprint and MCI, and gets > > address space from Sprint, then Sprint and MCI both need to carry > > Barney's routes internally, but Alternet, PSI, ..., need not carry > > Barney's specific routes, because they could be covered by a larger > > (Sprint) aggregate. > > Not in practice. The more-specific route will be preferred. I thought we were talking about what *could* be done. I know that, today, most folk don't do it, but nevertheless, existing routers can be configured as I suggested, so that your more-specific route (P1.X) is not announced outside the two top-level providers (P1 and P2) to whom you are multi-homed. If P2 does not announce P1's aggregate to other top-level providers (because P2 does not want to provide transit between other top-level providers and P1), then you are protected against failure of either of your links to P1 and P2, but all your traffic from top-level providers other than P1 and P2 has to come through P1, so you are not protected against failure of P1's links to other top-level providers, and your traffic does not get routed optimally even when all the links are up. If you are not looking for optimal routing, you might well be happy with this. If P2 has enough customers in your position (multi-homed to P1 and P2, with address space allocated by P1), or if you pay enough, then you might persuade P2 to announce P1's aggregate to other top-level providers, and to provide backup transit between other top-level providers and P1 (but only when the P1/P2 links are up). Then P1's links to P3 can fail, and both you and all P1's other customers still have connectivity with P3 via P2. This adds robustness, but does not improve optimality when all links are up. > There are real issues about how to achieve, in practice, the benefit > that multi-homing is intended to achieve, without global advertising. > (ie - I don't know how to do it.) Things certainly get more complicated as the amount of multi-homing increases, especially when folk multi-home to second- or third-level providers each of whom is multi-homed to higher-level providers. The worst case is that routes should be globally advertised, but cases like your example can be handled without global advertising. I suspect that most of the more complex cases can also be handled by sensible choice of where to pay for routes to be carried. For example, when customer X (who has address space P1.Q1.X) connects to providers Q1 (who is connected to top-level providers P1 and P2) and Q2 (who is connected to P3 and P4), then X could decide to pay Q1, Q2 and P3 to carry the P1.Q1.X route, decide that P1 and P2 are already carrying the P1.Q1 route so don't need to carry P1.Q1.X, and decide to let P4 and all the other top-level providers get by with just a route to the P1 aggregate. Hmm, then if Q1 breaks, packets addressed to P1.Q1.X will arrive at P1, who will not know what to do with them. This can be fixed by having P1 carry a more-specific route for P1.Q1.X (in addition to P1.Q1), and exchanging that route with P3, who will be able to route to X via Q2. A similar problem, with the same fix, arises if Q1 stays alive but the link between Q1 and X dies. Now we have a cycle P1-Q1-X-Q2-P3-P1 where each member is carrying the route for P1.Q1.X, another cycle P1-Q1-P2-P1 where each member is carrying the route for P1.Q1, and of course all top-level providers carry a route for P1. There's quite a lot of robustness there, but you don't get optimal routing. --apb (Alan Barrett) From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 04:54:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05523; Mon, 4 Sep 1995 04:54:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA03583; Mon, 4 Sep 1995 04:53:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03574; Mon, 4 Sep 1995 04:49:38 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05115; Mon, 4 Sep 1995 04:48:12 +1000 (from dcrocker@brandenburg.com) Received: from [204.179.132.5] (mg132-005.ricochet.net [204.179.132.5]) by aimnet.com (8.6.12/8.6.12) with SMTP id LAA04464; Sun, 3 Sep 1995 11:46:31 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 3 Sep 1995 11:47:44 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: RE: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk At 2:43 PM 9/1/95, Noel Chiappa wrote: >If I understand you, your bottom-line concern is reliability. Rather than tell >the network designers how to provide that reliability, perhaps a better >approach would be to say what you need, and then let's see what the best way sorry, but that approach is what got us into the current bind. I mean, oh gee, folks need to multihome their connections and not change the IP addresses of every machine in their organization when they change providers and not cause local providers to force all their customers to renumber when THEY change providers? wow. that's amazing. we really should have asked the users to find this stuff out. right, noel. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 04:55:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05542; Mon, 4 Sep 1995 04:55:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA03605; Mon, 4 Sep 1995 04:54:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03576; Mon, 4 Sep 1995 04:49:58 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05132; Mon, 4 Sep 1995 04:48:19 +1000 (from barrett@daisy.ee.und.ac.za) Received: from Daisy.ee.und.ac.za by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27827 Mon, 4 Sep 1995 04:46:32 +1000 (from barrett@daisy.ee.und.ac.za) Received: by daisy.ee.und.ac.za (Smail3.1.28.1 #31) id m0spK2P-0007VyC; Sun, 3 Sep 95 20:45 GMT+0200 Date: Sun, 3 Sep 1995 20:45:00 +0200 (GMT+0200) From: Alan Barrett X-Sender: barrett@daisy.ee.und.ac.za To: Robert Elz Cc: big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: <15050.810098199@munnari.OZ.AU> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Robert Elz wrote: > If X is multi-homed to P1 and P2 (and has address P1.X), and Y is > multi-homed to P1 and P3 (and has routing address P1.Y), and if P1 is > well-connected to P2 and to P3, then P1 can announce a route for the > aggregate P1 to all its neighbours, announce a route for P1.X to P2 but > not to P3, and announce a route for P1.Y to P3 but not to P2. P3 does not > need a route to P1.X if it has a route to P1, and P2 does not need a route > to P1.Y if it has a route to P1. > > Continue that analysis to consider what happens at the boundary > between P2 and P3 work out where longest match sends packets > in all the cases, and I suspect that even without considering the > effort this would take to handle with hundreds (or more) of > connections, and dozens of peers, you will abandon that as > a strategy. P2 and P3 do not exchange the P1.X or P1.Y routes with each other. P1's routing table contains: destination P1.X path X destination P1.X path P2 X (suppressed by shorter path) destination P1.Y path Y destination P1.Y path P3 Y (suppressed by shorter path) P2's routing table contains: destination P1 path P1 destination P1.X path X destination P1.X path P1 X (suppressed by shorter path) (no entry for P1.Y) P3's routing table contains: destination P1 path P1 (no entry for P1.X) destination P1.Y path Y destination P1.Y path P1 Y (suppressed by shorter path) I don't see the problem that you are alluding to. > For example, if Barney is multi-homed to Sprint and MCI, and gets > address space from Sprint, then Sprint and MCI both need to carry > Barney's routes internally, but Alternet, PSI, ..., need not carry > Barney's specific routes, because they could be covered by a larger > (Sprint) aggregate. > > And when the Spring link is down, no-one on Alternet knows of the > MCI link, and the sites multi-homing is close to useless. When the Sprint/Alternet link is down, yes, nobody on AlterNet will know to go through MCI to get to Barney. Unless MCI provides backup transit between Alternet and Sprint -- they can do that without advertising your specific prefic, if they advertise Sprint's aggregate. > If there were an aggregate that covered both of them (and excluded > someone else) then an address from that block would make sense - but > there isn't. Sure. But there could be. --apb (Alan Barrett) From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 06:54:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10186; Mon, 4 Sep 1995 06:54:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA03736; Mon, 4 Sep 1995 06:53:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03730; Mon, 4 Sep 1995 06:41:20 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09920; Mon, 4 Sep 1995 06:41:07 +1000 (from gherbert@crl.com) Received: from crl10.crl.com by mail.crl.com with SMTP id AA28999 (5.65c/IDA-1.5); Sun, 3 Sep 1995 13:40:27 -0700 Message-Id: <199509032040.AA28999@mail.crl.com> To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: Big-Internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: ISP shakeout In-Reply-To: Your message of "Sun, 03 Sep 1995 11:11:45 MDT." <199509031711.LAA02175@mica.denver.sgi.com> Date: Sun, 03 Sep 1995 13:40:27 -0700 From: George Herbert Precedence: bulk Vernon writes: >> From: Tony Li >> ... >> I can't help but to respond to this: it's very clear that no one is >> instuting a monopoly. In fact, there is so MUCH competition in the >> ISP market right now (140 in the SF Bay Area) that there is _bound_ to >> be a major fall out. The winner is likely to be the provider that >> handles the scaling issues (provisioning of modems, cycles, bw, etc.) >> the best. >> ... > >I've also been saying for a long time there will soon be a big shakeout >among ISP's, but I could be wrong. I think this is a simplistic and ultimately unrealistic view of the ISP end-user business community. Netcom won. Netcom got on the double-every-3-months and not fall apart completely in the process growth curve and has ridden it up to low-mid 6 figure membership counts. Their growth has slowed down since then, but it's still significant, and they could have a million users or more come this time next year. Let us define Netcom to be a trancendent ISP, they are no longer playing the same game we are, they are off chasing AOL, Compuserve, Delphi, Prodigy, etc., and likely to win big in that crowd in the next couple of years. There are a number of large ISPs around which are not quite on the same growth curve at this point, though a number of them were on it for some time, indicating that they hit scaling problems. Some of them are still growing strong, some not. None of them seems to currently have the likelyhood of trancending, though a number of them are getting much stronger technically (CRL, for example, has a nationwide T-3 backbone and is peering in several places... I am not currently an employee, but an educated guess would be that it's going to be entering the backbone game over the next year. Netcom has an equivalent backbone...). There are loads of midsized and small ISPs which are growing more slowly. Some are growing quickly and will hit large size over the next year. None of these seem to have affected the proliferation of new small ISPs and the strong growth of those which have technical and business strength. Netcom isn't lowering prices on its service, and its service quality hasn't surpassed that of smaller or larger network providers, so it's not taking customers away from other people. It just figured out how to get big, not better or cheaper. Anyone who can figure out how to get better and cheaper and big will win big, but those are three distinct issues, only one of which has ever been solved on a long term basis by an ISP (Netcom's growth). It appears to me that we have achived a stable equilibrium of pricing (about $20/month), service reliability levels, and growth potential in nearly all the ISPs. I can see how price might come down some, hardware is changing to some degree to make things simpler/cheaper, but it's not going to drop to $10/mo with companies still generating enough excess cash to grow / add POPs etc. Service seems to be intimately tied to many factors beyond the control of growing ISPs... how backordered are your modems and terminal servers, how long does it take to install lines, etc. One thing which is clear is that at this point in the ISP industrys development, things are not a zero-sum game. Everyone is getting back out what they put in, so the market potential exceeds the current capacity. What happens with that potential is an interesting question. -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 09:54:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15689; Mon, 4 Sep 1995 09:54:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA04039; Mon, 4 Sep 1995 09:53:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA04033; Mon, 4 Sep 1995 09:50:51 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15622; Mon, 4 Sep 1995 09:50:37 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id QAA04807; Sun, 3 Sep 1995 16:49:56 -0700 Date: Sun, 3 Sep 1995 16:49:56 -0700 From: Tony Li Message-Id: <199509032349.QAA04807@greatdane.cisco.com> To: mn@ios.com Cc: big-internet@munnari.OZ.AU In-Reply-To: (mn@ios.com) Subject: Re: Discussing encap/mapping proposal Precedence: bulk Ok, then let's discuss how this can be remedied: how about caching all strings and only flag the one we use? Same difference. When I look at my stats, the overall number of routes is fairly stable (yes, monotinic rising average). Why can them when they disappear? Just flag it as unavailable, take the (already calculated) next best available, and no traffic is exchanged. Ah.... because you lose BGP loop suppression if you advertise lies. Watch the flames now Only one: what problem do you think you're solving? Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 10:14:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16263; Mon, 4 Sep 1995 10:14:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA04087; Mon, 4 Sep 1995 10:13:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA04070; Mon, 4 Sep 1995 10:00:19 +1000 Received: from panix3.panix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15903; Mon, 4 Sep 1995 10:00:01 +1000 (from hal9001@panix.com) Received: (from hal9001@localhost) by panix3.panix.com (8.6.12/8.6.12+PanixU1.1) id TAA02618; Sun, 3 Sep 1995 19:53:27 -0400 X-Sender: hal9001@popserver.panix.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Mac Eudora Pro 2.1.3 Date: Sun, 3 Sep 1995 19:53:39 -0400 To: Tony Li From: "Robert A. Rosenberg" Subject: RE: Multihoming Cc: root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU Precedence: bulk At 18:11 9/2/95, Tony Li wrote: >I can't help but to respond to this: it's very clear that no one is >instuting a monopoly. In fact, there is so MUCH competition in the >ISP market right now (140 in the SF Bay Area) that there is _bound_ to >be a major fall out. The winner is likely to be the provider that >handles the scaling issues (provisioning of modems, cycles, bw, etc.) >the best. Of these 140 how many peer at interchange points and how many are buying their interchange from a Sprint/MCI/Alternet/PSI/etc (ie: Are just leaves hung off of the network of another ISP)? Your claim that there is competition is on the order of claiming that because there are 1000 gas stations in the SF Bay Area there is competition even though all of them have to buy their gasoline from one of 8 suppliers (numbers are hypothetical) and are only allowed to deal with one supplier at a time and there are problems with switching suppliers (ie: To switch from Exxon to Shell to Chevron is not an easy/quick deal). From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 10:34:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17068; Mon, 4 Sep 1995 10:34:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA04122; Mon, 4 Sep 1995 10:33:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA04097; Mon, 4 Sep 1995 10:14:16 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16258; Mon, 4 Sep 1995 10:13:57 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id RAA05034; Sun, 3 Sep 1995 17:11:53 -0700 Date: Sun, 3 Sep 1995 17:11:53 -0700 From: Tony Li Message-Id: <199509040011.RAA05034@greatdane.cisco.com> To: hal9001@panix.com Cc: root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: (hal9001@panix.com) Subject: RE: Multihoming Precedence: bulk Of these 140 how many peer at interchange points and how many are buying their interchange from a Sprint/MCI/Alternet/PSI/etc (ie: Are just leaves hung off of the network of another ISP)? Your claim that there is competition is on the order of claiming that because there are 1000 gas stations in the SF Bay Area there is competition even though all of them have to buy their gasoline from one of 8 suppliers (numbers are hypothetical) and are only allowed to deal with one supplier at a time and there are problems with switching suppliers (ie: To switch from Exxon to Shell to Chevron is not an easy/quick deal). I fail to see your point. Yes, many of them have a direct connect to one of the backbones. So? Yes, it's not an easy/quick deal. It never could be "easy" for an ISP to change. That's a production network that you're moving around, not a piece of toast. I really fail to see how this related to multihoming and whether or not there's a monopoly here. Yes, there are a small number of default free providers. It's obviously an open market as we're seeing entries... and we're seeing moves between providers. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 11:14:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18612; Mon, 4 Sep 1995 11:14:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA04184; Mon, 4 Sep 1995 11:13:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA04167; Mon, 4 Sep 1995 11:07:01 +1000 Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18357; Mon, 4 Sep 1995 11:06:48 +1000 (from barney@databus.databus.com) Date: Sun, 3 Sep 95 21:06 EDT Message-Id: <9509032106.AA26615@databus.databus.com> From: Barney Wolff To: big-internet@munnari.OZ.AU Subject: Re: Multihoming Content-Length: 2437 Content-Type: text Precedence: bulk > Date: Sun, 3 Sep 95 05:06:42 -0400 > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > > Which more specific-route? A more-specific route to you is only visible inside > Sprint and MCI. Outside them, there are only routes to Sprint and MCI. Of > course, this results in most of your inbound trafic from the rest of the world > (e.g. all people are connected to Sprint, but not people who are connected to > MCI and get to Sprint through MCI) coming in through your Sprint link. Oh boy, this gets tricky. You're claiming that MCI does not have to advertise me outside itself (and neither does Sprint). Ok, so now my link to Sprint, from which I got my address, goes down. People inside MCI can still get to me, but people outside both, and even people inside Sprint, cannot get to me, because only MCI knows how, and it's not supposed to tell anybody. How is MCI supposed to know that it really should be advertising me to Sprint but to nobody else? In theory, it could notice that my address comes from Sprint's CIDR block and deduce it from that, but is that in fact how the routing protocols in use today actually work and are used? RFC1519 appears to assume otherwise: o Organizations which are multi-homed. Because multi-homed organizations must be advertised into the system by each of their service providers, it is often not feasible to aggregate their routing information into the address space any one of those providers. Note that they still may receive their address allocation out of a transit domain's address space (which has other advantages), but their routing information must still be explicitly advertised by most of their service providers (the exception being that if the site's allocation comes out of its least-preferable service provider, then that service provider need not advertise the explicit route - longest-match will insure that its aggregated route is used to get to the site on a backup basis). For this reason, the routing cost for these organizations will typically be about the same as it is today. My requirements for legitimate multi-homing would include reasonable load- sharing when both links are up, and universal reachability, even if not optimal routing, when one is down. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 11:34:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19230; Mon, 4 Sep 1995 11:34:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA04221; Mon, 4 Sep 1995 11:33:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA04190; Mon, 4 Sep 1995 11:14:31 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18614; Mon, 4 Sep 1995 11:14:28 +1000 (from mn@tremere.ios.com) Received: from tremere.ios.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12827 Mon, 4 Sep 1995 11:14:21 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id VAA01594; Sun, 3 Sep 1995 21:15:20 -0400 Date: Sun, 3 Sep 1995 21:15:19 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Tony's answer: To: big-internet@munnari.OZ.AU Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk I believe Mr cisco id too low under the beltline here. We don't readvertise what we learn from the outside, caching would be of pure internal use. And routes falgged as no usable are just that. Of course, Cisco's BGP implementation is academically correct, but computationally suicidal: each time something moves it gets erased from memory. Why we should not do this: Let me do an analogy: no Ferrari, no cars at all, just relaxing woods. Imagine you are in the woods. What do you see? Trees, bushes, all kind of stuff. Close you eyes. What do you see? I would not see the bushes, trees and all that kind of stuff. Open your eyes again, e.g. like a router after a software forced crash. What do you see? trees, bushes, all kinds of stuff. How many trees changed position? Yes, some my be obscured by a deer coming by. But they are at the same place. A two year old has the view that when he closes the eyes, everything is not there any more. Even that you cannot see him. We know, even when we sleep that the alarm clock will be at the same place tomorrow. It is rare that in moves, but that can happen if I sweep it off the nightstand. Routes: why must a router totally delete a route of a set that points to a target, when that route becomes unusable, or is withdrawn? Keep it. flag it as withdrawn. Age out withdrawn routes in half days, days, whatever. Look at DNS. Works fine. And routes withdrawn and flagged as such are not used and withdrawn towards the igp, whichever you chose. If you chose ospf you are lucky, it does the same. when a router comes up after that software forced crash, why does it need to beg everybody around to give it the whole context? I would say more than 80% of all routes are stull the same. Their packets fell on the floor while the router was pouting, and they will pick up right away. Now, some might have changed. There is only a table consolidation necessary, not a complete multiple table transfer from every peer. How about a checksum/hash algorithm that shows which routes have changed? Hashgroup checksum the same? no consolidation in that group. Hashgroup checksum changed: go check subgroups. Yes, needs intelligent hierarchical hashing. The router could also check on passing icmp unreachables for a certain time (of couse not tony's which would miss 99.9%, as he stated in a packet dump question ). Yes, BGP needs some additional --OPTIONAL-- protocol elements that only those need to support who want to run table consolidation vs. total xfer of bulk data from which 80% did not change at all. I say this to show, there are ways and means. This is no sorcery. But it will never be done by vendors. We must get our act together and forgot about the vendor excuses, and write routing and graph calculation that does not run on bus oriented, overaged designs. I prefer a beefy switch from a switch vendor who knows what he is doing, internally totally cell based, and talk an igp to it, running my peering bgp elsewhere, with better code than possible on routers. Mike ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 11:54:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20027; Mon, 4 Sep 1995 11:54:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA04258; Mon, 4 Sep 1995 11:53:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA04252; Mon, 4 Sep 1995 11:48:24 +1000 Received: from netrail.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19886; Mon, 4 Sep 1995 11:48:18 +1000 (from nathan@netrail.net) Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id VAA00844; Sun, 3 Sep 1995 21:47:49 -0400 Date: Sun, 3 Sep 1995 21:47:49 -0400 (EDT) From: Nathan Stratton To: Tony Li Cc: hal9001@panix.com, root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU Subject: RE: Multihoming In-Reply-To: <199509040011.RAA05034@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Tony Li wrote: > Your claim that there is competition is on the order of claiming that > because there are 1000 gas stations in the SF Bay Area there is competition > even though all of them have to buy their gasoline from one of 8 suppliers > (numbers are hypothetical) and are only allowed to deal with one supplier > at a time and there are problems with switching suppliers (ie: To switch > from Exxon to Shell to Chevron is not an easy/quick deal). > > I fail to see your point. Yes, many of them have a direct connect to > one of the backbones. So? Yes, it's not an easy/quick deal. It > never could be "easy" for an ISP to change. That's a production > network that you're moving around, not a piece of toast. > > I really fail to see how this related to multihoming and whether or > not there's a monopoly here. Yes, there are a small number of default > free providers. It's obviously an open market as we're seeing > entries... and we're seeing moves between providers. The point is that we are getting close to a monopoly, and the big NSP are trying to make it stay that way. i.e sprint not peering with a ISP unless they connect to all of the NAP's. They do this so that small ISP's like me can't get in. If the big NSP's can make it hard to move and hard to get to the NAP's then they can keep their users. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 12:20:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21022; Mon, 4 Sep 1995 12:20:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA04307; Mon, 4 Sep 1995 12:13:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA04289; Mon, 4 Sep 1995 11:56:24 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20092; Mon, 4 Sep 1995 11:55:51 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id VAA05717 for big-internet@munnari.OZ.AU; Sun, 3 Sep 1995 21:55:45 -0400 (EDT) Date: Sun, 3 Sep 1995 21:55:45 -0400 (EDT) From: Scott Bradner Message-Id: <199509040155.VAA05717@newdev.harvard.edu> To: big-internet@munnari.OZ.AU Subject: RE: Multihoming Precedence: bulk > Your claim that there is competition is on the order of claiming that > because there are 1000 gas stations in the SF Bay Area there is competition > even though all of them have to buy their gasoline from one of 8 suppliers Now, I'm not an ISP but I'd guess that the cost of the bacbone connection is not the major part of the ISP's expenses so this might be a bit of a reach as a comparison. Scott From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 12:24:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21203; Mon, 4 Sep 1995 12:24:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA04334; Mon, 4 Sep 1995 12:22:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA04292; Mon, 4 Sep 1995 12:01:53 +1000 Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20384; Mon, 4 Sep 1995 12:01:43 +1000 (from barney@databus.databus.com) Date: Sun, 3 Sep 95 22:01 EDT Message-Id: <9509032201.AA26809@databus.databus.com> From: Barney Wolff To: big-internet@munnari.OZ.AU Subject: Re: Multihoming Content-Length: 1257 Content-Type: text Precedence: bulk > Date: Sun, 3 Sep 1995 20:30:08 +0200 (GMT+0200) > From: Alan Barrett > > I thought we were talking about what *could* be done. I know that, > today, most folk don't do it, but nevertheless, existing routers can be > configured as I suggested, so that your more-specific route (P1.X) is > not announced outside the two top-level providers (P1 and P2) to whom > you are multi-homed. I focus most rigidly on what "can" be done, not what "could" be done. The problem with all the "could" solutions I've heard so far is that I don't see how they get implemented without human (nay, expert) judgement in each case. We just can't afford a situation where it takes significant time for an expert to figure out how to hook up each new customer. You're postulating a world in which each provider has to know, for each customer, which other providers that customer hooks to, so it can advertise its own route to the customer to all that customer's other providers, but not to the world at large. I think that has problems of robustness-of-process as well as labor costs. De facto, multi-homed customers will be advertised world-wide, for a long time to come - or at least until the routers fall over. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 12:36:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21641; Mon, 4 Sep 1995 12:36:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA04377; Mon, 4 Sep 1995 12:33:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA04371; Mon, 4 Sep 1995 12:33:33 +1000 Received: from [129.191.1.1] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21564; Mon, 4 Sep 1995 12:33:26 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA10239; Sun, 3 Sep 95 21:53:10 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA18727; Sun, 3 Sep 95 21:33:13 CDT Date: Sun, 3 Sep 95 21:33:13 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9509040233.AA18727@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: The Conspiracy - Precedence: bulk You've found us out. We router vendors are a vicious cabal of drooling idiots out to rule the world through superior CIDRisms or something. Now you have to be silenced. Expect news reports of network architects tied found tied to their equipment racks with their own entrails. Tony: The Big Yellow Beetle Squeaks Defiance at Eight Bells. From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 12:40:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21953; Mon, 4 Sep 1995 12:40:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA04400; Mon, 4 Sep 1995 12:38:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA04368; Mon, 4 Sep 1995 12:30:18 +1000 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21456; Mon, 4 Sep 1995 12:30:07 +1000 (from swb1@cornell.edu) Received: from [132.236.236.48] (CU-DIALUP-0206.CIT.CORNELL.EDU [132.236.236.48]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id WAA17362 for ; Sun, 3 Sep 1995 22:29:55 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 3 Sep 1995 22:31:24 -0400 To: big-internet@munnari.OZ.AU From: Scott W Brim Subject: Re: Multihoming Precedence: bulk Is there a proposal in the works such that a customer would get its address space from a single provider, and could be multihomed to another provider, but the second provider would need to be connected to the "primary" provider robustly, so that the customer's specific route would not be announced outside of the providers giving the customer connectivity, and if the customer lost connectivity through the primary provider there would theoretically be enough connectivity between the two providers to get around the problem most of the time? ...Scott From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 12:43:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22037; Mon, 4 Sep 1995 12:43:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA04433; Mon, 4 Sep 1995 12:41:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA04350; Mon, 4 Sep 1995 12:25:04 +1000 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21207; Mon, 4 Sep 1995 12:24:44 +1000 (from swb1@cornell.edu) Received: from [132.236.236.48] (CU-DIALUP-0206.CIT.CORNELL.EDU [132.236.236.48]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id WAA16608 for ; Sun, 3 Sep 1995 22:24:23 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sun, 3 Sep 1995 22:25:52 -0400 To: big-internet@munnari.OZ.AU From: Scott W Brim Subject: Re: Multihoming Precedence: bulk At 14:48 09/03/95, Robert Elz wrote: >However you're right elsewhere, they will multi-home to local >providers, they're not usually likely to put in long distance >lines to do this. After so much mail I can't remember if this has been clarified or not. So, just to be sure ... It doesn't matter I multihome to two "local" providers. What matters (under provider-based addressing) is how they are related in the address hierarchy. If I connect to both Sprint and Microsoft in the hamlet of Ithaca, specific routes to me will have to be carried to the level of the hierarchy where they can aggregate for my multihoming to do any good, and that is likely to be a very high level. It doesn't matter how close the providers are topologically either. If cisco buys service from two providers and both providers reach a NAP in only one hop, so what? Cisco's specific routes will still need to be propagated to other providers at that level -- unless you are considering a form of topology-based addressing built around NAPs etc., which I recall was rejected, for good reasons (e.g. lack of flexibility). So let's be careful when we use the word "local" to refer to providers. Geography isn't too relevant to the concern about provider-based addressing and multihoming. Thanks ... Scott From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 12:48:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22158; Mon, 4 Sep 1995 12:48:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA04457; Mon, 4 Sep 1995 12:45:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA04309; Mon, 4 Sep 1995 12:14:43 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20743; Mon, 4 Sep 1995 12:14:37 +1000 (from gherbert@crl.com) Received: from crl6.crl.com by mail.crl.com with SMTP id AA12716 (5.65c/IDA-1.5); Sun, 3 Sep 1995 19:11:29 -0700 Message-Id: <199509040211.AA12716@mail.crl.com> To: "Robert A. Rosenberg" Cc: big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Multihoming In-Reply-To: Your message of "Sun, 03 Sep 1995 19:53:39 EDT." Date: Sun, 03 Sep 1995 19:11:29 -0700 From: George Herbert Precedence: bulk Robert writes: >Of these 140 how many peer at interchange points and how many are buying >their interchange from a Sprint/MCI/Alternet/PSI/etc (ie: Are just leaves >hung off of the network of another ISP)? A somewhat sorted, organized table derived from the ba.internet providers list (site names deleted to save space and sorting pain...) follows. Note that a number of the sites listed are "leaf ISPs" hanging off one of the other midsized bay area ISPs: tlg, scruznet, internex, nbn are all popular. Quick summary: Backbones & direct connect to interchange points: 15 Multihomed: 8 Cix-only (?): 5 Single homed: 105 These guys are backbones and exchange-point direct connects: count=15 Connectivity: Chi-NAP, cix, mae-east, mae-west, Pacbell NAP Connectivity: Nynex NAP, cix, icp.net, mae-east, Fix-east, Fix-west Connectivity: T3:SF-NAP, T3*2:mae-west, 10:CHI-NAP, 10:mae-east Connectivity: We *are* AlterNet. Connectivity: agis, alternet, ans, crl, ibm, mci, mfs, net99, psi, Connectivity: agis, cix, net99, backup to Aimnet Connectivity: agis, sprint, mae-west Connectivity: agis,alternet,ans.net,cerfnet,crl,mci,psinet,sprint Connectivity: alter.net, ans, crl, es.net, geonet, ibm, internex, mci, Connectivity: cerf, Nynex NAP Connectivity: mae-east, mae-west Connectivity: mae-east, mae-west Connectivity: cix, CRL, Connectivity: ibm.net, cix Connectivity: sprint, mae-west [note: the above blows away any "gang of 6" peerage theories ;-) ] These guys are dual-homed: count=8 Connectivity: 4 T1 to mci, 2 T1 to sprint, and T1 peerage with NBN Connectivity: cerf, mci Connectivity: mci, net99 Connectivity: mci, sprint Connectivity: mci, tlg Connectivity: mci, willtel Connectivity: scruz, net99 Connectivity: sprint, barrnet These guys claim to be on via CIX alone (!): count = 5 Connectivity: cix Connectivity: cix Connectivity: cix Connectivity: cix Connectivity: cix These guys are single-homed for now: count=105 Connectivity: SMDS:PacBell Connectivity: aimnet Connectivity: T1: Exodus Connectivity: agis Connectivity: T1:nbn Connectivity: Net99 Connectivity: UUCP: netcom Connectivity: Sprint Connectivity: MCI Connectivity: UUnet Connectivity: alter Connectivity: alternet Connectivity: alternet Connectivity: alternet Connectivity: ans Connectivity: ans Connectivity: barrnet Connectivity: barrnet Connectivity: barrnet Connectivity: barrnet Connectivity: barrnet Connectivity: barrnet Connectivity: barrnet Connectivity: barrnet Connectivity: bdt Connectivity: cerf Connectivity: dnai Connectivity: dnai (?) Connectivity: internet-direct Connectivity: internex Connectivity: internex Connectivity: internex Connectivity: internex Connectivity: interserv Connectivity: ip.net Connectivity: mainstreet Connectivity: mainstreet Connectivity: market.net Connectivity: mci Connectivity: mci Connectivity: mci Connectivity: mci Connectivity: mci Connectivity: mci Connectivity: mci Connectivity: nbn Connectivity: nbn Connectivity: nbn Connectivity: nbn Connectivity: nbn Connectivity: nbn Connectivity: nbn Connectivity: near.net Connectivity: net99 Connectivity: net99 Connectivity: net99 Connectivity: netcom Connectivity: netcom Connectivity: pagesat Connectivity: pagesat Connectivity: pagesat Connectivity: pagesat Connectivity: psi Connectivity: relay.net Connectivity: scruz Connectivity: scruz Connectivity: scruz Connectivity: scruznet Connectivity: sirius Connectivity: sirius (down July 1, July 20 '95) Connectivity: sprint Connectivity: sprint Connectivity: sprint Connectivity: sprint Connectivity: tdl Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: tlg Connectivity: vnet, (scruz until Aug 1) Connectivity: wco Connectivity: wco Connectivity: wco Connectivity: wco Connectivity: wco Connectivity: wco Connectivity: wco Connectivity: wco Connectivity: ? Connectivity: ? Connectivity: ? Connectivity: ? From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 12:56:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22426; Mon, 4 Sep 1995 12:56:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA04478; Mon, 4 Sep 1995 12:54:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA04391; Mon, 4 Sep 1995 12:37:29 +1000 Received: from netrail.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21661; Mon, 4 Sep 1995 12:37:20 +1000 (from nathan@netrail.net) Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id WAA01933; Sun, 3 Sep 1995 22:37:12 -0400 Date: Sun, 3 Sep 1995 22:37:12 -0400 (EDT) From: Nathan Stratton To: Barney Wolff Cc: big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: <9509032106.AA26615@databus.databus.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Barney Wolff wrote: > My requirements for legitimate multi-homing would include reasonable load- > sharing when both links are up, and universal reachability, even if > not optimal routing, when one is down. Ya, and right now that can not be done, We have a sprintlink T1 and wanted to do "legitimate multi-homing" with MCI and sprint. WE had to drop the MCI, and now we are getting a 10 meg into MAE and just using sprint for transit. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 14:58:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27175; Mon, 4 Sep 1995 14:58:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA04604; Mon, 4 Sep 1995 14:53:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA04587; Mon, 4 Sep 1995 14:38:32 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26603; Mon, 4 Sep 1995 14:38:13 +1000 (from vjs@mica.denver.sgi.com) Received: from SGI.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA24002 Mon, 4 Sep 1995 14:20:10 +1000 (from vjs@mica.denver.sgi.com) Received: from mica.denver.sgi.com by sgi.sgi.com via ESMTP (950405.SGI.8.6.12/910110.SGI) for <@sgi.sgi.com:Big-Internet@munnari.OZ.AU> id VAA01256; Sun, 3 Sep 1995 21:17:20 -0700 Received: by mica.denver.sgi.com (940816.SGI.8.6.9/940406.SGI.AUTO) for Big-Internet@munnari.OZ.AU id WAA04637; Sun, 3 Sep 1995 22:16:53 -0600 Date: Sun, 3 Sep 1995 22:16:53 -0600 From: vjs@mica.denver.sgi.com (Vernon Schryver) Message-Id: <199509040416.WAA04637@mica.denver.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: ISP shakeout Precedence: bulk > From: George Herbert > Vernon writes: > >> From: Tony Li > >> ... > >> In fact, there is so MUCH competition in the > >> ISP market right now (140 in the SF Bay Area) that there is _bound_ to > >> be a major fall out. The winner is likely to be the provider that > >> handles the scaling issues (provisioning of modems, cycles, bw, etc.) > >> the best. > >> ... > > > >I've also been saying for a long time there will soon be a big shakeout > >among ISP's, but I could be wrong. > > I think this is a simplistic and ultimately unrealistic view of the ISP > end-user business community. > > Netcom won. ... Sure, Netcom, Microsoft, MCI, IBM, Sears, Sprint, H&R-Block, Uunet, PSI and so forth will do whatever they do, but it could also happen that will be zillions of tiny, retail ISP's that serve web pages email to most individuals and small companies. > ... > likelyhood of trancending ... If that's a reference to the notion in the science fiction book "Fire on the Deep" where some societies/intelligencies develop until they transcend mortal limitations, it seems a propos to Netcom. The idea might even have something to do with renumbering, CIDR, encapsulation etc. In that story, the gods numbered in the 100's or 1000's and lived for years or centuries, while the millions of societies of billions of individuals endured for millenia or millions of millenia, generally completely ignorance of the existence of the gods. Consider the pains suffered by one of the zillions of tiny ISP's when it tries to be usefully multi-homed. Consider the pains of an individual or Joe's Pizza Shoppe usefully multihomed to two neighborhod ISP's, but needing a single DNS name and probably a single IP address so that email and WWW serving does the right thing. The aggregate weight of those tiny guys sounds dominent, sooner if not now. Don't say that the Joe's Pizza Shoppes will deal only with Netcom's. That would be no more reasonable than saying that all pizza shops are franchisees of big chains or all PC's are sold by the big chains (or even built by the big vendors). Don't say that the tiny ISP's will be willingly singled-home. Many will care about reliability. Having 2 IP wholesalers is about a different kind of reliability than a gas station having 2 different wholesalers. Don't say that no individuals will want to be multihomed. In my private life I'm a customer of Netcom, and I really wish it were practical for me to have a backup. (I'm not flaming Netcom; they're just your standard, big company; more reliable than some but less than I'd like.) Will the Netcom of the future be able to renumber its 100,000 neighborhood ISP customers with their 20,000,000 end-users in a year? Maybe or maybe not, depending on details of what those 20,000,000 do for multi-homing, email, mobile-IP, and other stuff. ya'know, UUCP was kind of nice for multihoming. It could be said UUCP died of routing table explosion (the maps) and competition from another scheme which hid routing table hassles from the leaves. (please don't bother to explain UUCP to me. Sgi.com &co still have many UUCP links, but we're working on that.) Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 15:36:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28839; Mon, 4 Sep 1995 15:36:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA04664; Mon, 4 Sep 1995 15:33:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA04658; Mon, 4 Sep 1995 15:26:53 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28460; Mon, 4 Sep 1995 15:25:48 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA09407; Sun, 3 Sep 1995 22:25:44 -0700 Date: Sun, 3 Sep 1995 22:25:44 -0700 From: Tony Li Message-Id: <199509040525.WAA09407@greatdane.cisco.com> To: nathan@netrail.net Cc: hal9001@panix.com, root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: (message from Nathan Stratton on Sun, 3 Sep 1995 21:47:49 -0400 (EDT)) Subject: RE: Multihoming Precedence: bulk The point is that we are getting close to a monopoly, and the big NSP are trying to make it stay that way. i.e sprint not peering with a ISP unless they connect to all of the NAP's. They do this so that small ISP's like me can't get in. If the big NSP's can make it hard to move and hard to get to the NAP's then they can keep their users. And what does this have to do with multihoming? Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 15:57:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29600; Mon, 4 Sep 1995 15:57:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA04702; Mon, 4 Sep 1995 15:53:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA04698; Mon, 4 Sep 1995 15:48:57 +1000 Received: from ACADEM.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29293; Mon, 4 Sep 1995 15:48:52 +1000 (from sob@academ.com) Received: (from sob@localhost) by academ.com (8.6.12/8.6.9) id AAA00908; Mon, 4 Sep 1995 00:48:44 -0500 Message-Id: <199509040548.AAA00908@academ.com> From: sob@academ.com (Stan Barber) Date: Mon, 4 Sep 1995 00:48:44 CDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: vjs@mica.denver.sgi.com (Vernon Schryver), Big-Internet@munnari.OZ.AU Subject: Re: ISP shakeout Precedence: bulk Vernon Schryver writes: > ya'know, UUCP was kind of nice for multihoming. It could be said UUCP > died of routing table explosion (the maps) and competition from another > scheme which hid routing table hassles from the leaves. It still is nice for multihoming. UUCP is still alive and kicking, by the way. There are still places that UUCP can happen MUCH easier than the Internet. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 16:00:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29681; Mon, 4 Sep 1995 16:00:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA04735; Mon, 4 Sep 1995 15:58:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA04674; Mon, 4 Sep 1995 15:37:47 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28884; Mon, 4 Sep 1995 15:37:35 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA09597; Sun, 3 Sep 1995 22:36:02 -0700 Date: Sun, 3 Sep 1995 22:36:02 -0700 From: Tony Li Message-Id: <199509040536.WAA09597@greatdane.cisco.com> To: swb1@cornell.edu Cc: big-internet@munnari.OZ.AU In-Reply-To: (message from Scott W Brim on Sun, 3 Sep 1995 11:48:33 -0400) Subject: Re: Multihoming Precedence: bulk I believe the business significance of an Internet connection has increased rapidly, that the Internet is now a strategic business tool. That's the big change. For anyone making money over the Internet, connectivity is financially rather important. However, wrt reliability, individual providers aren't keeping up with the rate at which the Internet's business importance is increasing (partly because of the routing thrash we're seeing at the interconnect points ... hmmm ...). And thus we have to stabilize the net and the best way to do that is to fix the cause of the instabilities. Getting overhead down and allowing us to concentrate on more bandwidth and more interconnects and better routing would really help. Anyway, apparently connecting to multiple major providers, either directly or through local providers which are connected to multiple major providers, satisfies their needs, and connecting to one provider multiply does not. This trend -- I can't call it a "surge" without documentation, and all I can give you is an aggregate subjective feeling about what's rolled past my eyes and ears in recent months -- this trend is based on a strong perceived need by the customers, and the engineering solution embodied in the document goes against it, it sets you up for dissatisfaction on all sides. It's interesting to call it a surge. As of the time we started CIDR, 10% of the net was multihomed. Given Andrew's data, it sounds very much like the multihoming level is decreasing. This is expected, as we connect many more data consumers that information providers. And the providers are those who want to multihome, as they're the ones getting the money. You say you don't see a lot of evidence for a desire to multihome between providers, while I hear more of it every day. Yes, but what is it in proportion to the growth of the routing table? Not much. And more importantly, you miss the fact that I'm really interested in the "not topologically close" multihomings. p.s. just to be sure we're talking about the same thing, geographically diverse multihoming is not what people are after. I see them connecting to different large-scale providers (directly or indirectly) within the same geographic area. I've seen a couple of messages from Tony which make me wonder if he thinks we're talking about geographic separation of access points for a lot of organizations. We're not. No, we're talking about topological separation. My argument is for geographical locality due to local loop costs. If there's an interconnect nearby, geographical locality implies some degree of topological locality. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 16:16:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00470; Mon, 4 Sep 1995 16:16:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA04780; Mon, 4 Sep 1995 16:13:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA04737; Mon, 4 Sep 1995 15:59:48 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29657; Mon, 4 Sep 1995 15:59:44 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA09962; Sun, 3 Sep 1995 22:59:42 -0700 Date: Sun, 3 Sep 1995 22:59:42 -0700 From: Tony Li Message-Id: <199509040559.WAA09962@greatdane.cisco.com> To: Big-Internet@munnari.OZ.AU Subject: ISP shakeout Precedence: bulk If that happens, the main effect I can as far as multi-homing concerns the popularity of somethign like mobile-IP. Doesn't mobile-IP make difficult renumbering much common, since it competes with dynamic IP address assignment via something like PPP or DHCP? Mobile-IP injects no new routes into routing. Yes, in one mode, you can do address acquisition via PPP or DHCP. It's not required tho. Note that my comments are on the Mobile IP spec today. It's still in flux. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 16:27:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00858; Mon, 4 Sep 1995 16:27:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA04806; Mon, 4 Sep 1995 16:22:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA04763; Mon, 4 Sep 1995 16:08:20 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29962; Mon, 4 Sep 1995 16:08:13 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA10090; Sun, 3 Sep 1995 23:08:04 -0700 Date: Sun, 3 Sep 1995 23:08:04 -0700 From: Tony Li Message-Id: <199509040608.XAA10090@greatdane.cisco.com> To: swb1@cornell.edu (Scott W Brim) Cc: big-internet@munnari.OZ.AU Subject: Re: Multihoming Precedence: bulk Is there a proposal in the works such that a customer would get its address space from a single provider, and could be multihomed to another provider, but the second provider would need to be connected to the "primary" provider robustly, so that the customer's specific route would not be announced outside of the providers giving the customer connectivity, and if the customer lost connectivity through the primary provider there would theoretically be enough connectivity between the two providers to get around the problem most of the time? I know of no such proposal currently. Such a proposal would be entirely reasonable to present in CIDRD. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 16:31:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01036; Mon, 4 Sep 1995 16:31:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA04841; Mon, 4 Sep 1995 16:27:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA04760; Mon, 4 Sep 1995 16:07:35 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29936; Mon, 4 Sep 1995 16:06:44 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA10055; Sun, 3 Sep 1995 23:05:59 -0700 Date: Sun, 3 Sep 1995 23:05:59 -0700 From: Tony Li Message-Id: <199509040605.XAA10055@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Subject: Re: Tony's answer: Precedence: bulk Of course, Cisco's BGP implementation is academically correct, but computationally suicidal: each time something moves it gets erased from memory. No, actually it doesn't. But that's not what you asked. The point is that whether you erase it or flag it, you still have per-prefix computation. Why we should not do this: Let me do an analogy: no Ferrari, no cars at all, just relaxing woods. Imagine you are in the woods. What do you see? Trees, bushes, all kind of stuff. Close you eyes. What do you see? I would not see the bushes, trees and all that kind of stuff. Open your eyes again, e.g. like a router after a software forced crash. What do you see? trees, bushes, all kinds of stuff. How many trees changed position? Yes, some my be obscured by a deer coming by. But they are at the same place. A two year old has the view that when he closes the eyes, everything is not there any more. Even that you cannot see him. We know, even when we sleep that the alarm clock will be at the same place tomorrow. It is rare that in moves, but that can happen if I sweep it off the nightstand. I think what you're proposing is that once we lose a prefix we simply black hole the traffic until we hear the original prefix and path again. Is that correct? Routes: why must a router totally delete a route of a set that points to a target, when that route becomes unusable, or is withdrawn? Keep it. flag it as withdrawn. Age out withdrawn routes in half days, days, whatever. Look at DNS. Works fine. And routes withdrawn and flagged as such are not used and withdrawn towards the igp, whichever you chose. If you chose ospf you are lucky, it does the same. How does this help? What does this solve? Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 16:36:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01302; Mon, 4 Sep 1995 16:36:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA04868; Mon, 4 Sep 1995 16:34:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA04861; Mon, 4 Sep 1995 16:32:21 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01044; Mon, 4 Sep 1995 16:32:03 +1000 (from ses@tipper.oit.unc.edu) Received: from chivalry (chivalry.eit.COM [192.100.58.30]) by tipper.oit.unc.edu (8.6.12/8.6.10) with SMTP id CAA22784; Mon, 4 Sep 1995 02:30:01 -0400 Date: Sun, 3 Sep 1995 23:31:59 -0700 (PDT) From: Simon Spero X-Sender: ses@chivalry To: Andrew Molitor Cc: big-internet@munnari.OZ.AU Subject: Re: The Conspiracy - In-Reply-To: <9509040233.AA18727@anubis.network.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Hah! The running dogs of internation capitalism reveal their conspiracy. Let us rise up and crush them with an Iron Fist of unaggregated freedom. The National Union of Computer Operatives (Hackers local 42) calls for a general strike on 9/4/95, Labour day. Internet On Strike! Forward the Internetworkale! Power Comes From the Barrel of a GNU! From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 16:40:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01418; Mon, 4 Sep 1995 16:40:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA04890; Mon, 4 Sep 1995 16:38:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA04790; Mon, 4 Sep 1995 16:15:53 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00436; Mon, 4 Sep 1995 16:15:49 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01228 Mon, 4 Sep 1995 16:15:35 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA10184; Sun, 3 Sep 1995 23:13:45 -0700 Date: Sun, 3 Sep 1995 23:13:45 -0700 From: Tony Li Message-Id: <199509040613.XAA10184@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Cc: swb1@cornell.edu (Scott W Brim) Subject: Re: Multihoming Precedence: bulk It doesn't matter I multihome to two "local" providers. What matters (under provider-based addressing) is how they are related in the address hierarchy. If I connect to both Sprint and Microsoft in the hamlet of Ithaca, specific routes to me will have to be carried to the level of the hierarchy where they can aggregate for my multihoming to do any good, and that is likely to be a very high level. Possibly. It depends very much on which prefix you can be aggregated with. It doesn't matter how close the providers are topologically either. If cisco buys service from two providers and both providers reach a NAP in only one hop, so what? Cisco's specific routes will still need to be propagated to other providers at that level -- unless you are considering a form of topology-based addressing built around NAPs etc., which I recall was rejected, for good reasons (e.g. lack of flexibility). Yes, specific routes need to be propagated into other providers. But those providers can perform proxy aggregation part-way through their networks. If the two providers are topologically close, then this can happen before we're deep into the backbone. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 16:44:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01496; Mon, 4 Sep 1995 16:44:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA04923; Mon, 4 Sep 1995 16:42:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA04863; Mon, 4 Sep 1995 16:32:28 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01037; Mon, 4 Sep 1995 16:31:48 +1000 (from gherbert@crl.com) Received: from crl6.crl.com by mail.crl.com with SMTP id AA17286 (5.65c/IDA-1.5); Sun, 3 Sep 1995 23:28:10 -0700 Message-Id: <199509040628.AA17286@mail.crl.com> To: vjs@mica.denver.sgi.com (Vernon Schryver) Cc: gherbert@crl.com, big-internet@munnari.OZ.AU Subject: Re: ISP shakeout In-Reply-To: Your message of "Sun, 03 Sep 1995 22:16:53 MDT." <199509040416.WAA04637@mica.denver.sgi.com> Date: Sun, 03 Sep 1995 23:28:10 -0700 From: George Herbert Precedence: bulk You write: >Sure, Netcom, Microsoft, MCI, IBM, Sears, Sprint, H&R-Block, Uunet, PSI >and so forth will do whatever they do, but it could also happen that >will be zillions of tiny, retail ISP's that serve web pages email to >most individuals and small companies. I believe that is what we are seeing now. One ISP with about 75-85 thousand users in the bay area, a bunch (5-6) with 5-15 thousand each, and about 150 more with a few hundred each. The numbers work out about evenly right now that the market is 1/3 netcoms, 1/3 the other big players, and 1/3 all the small guys. >> ... >> likelyhood of trancending ... > >If that's a reference to the notion in the science fiction book "Fire >on the Deep" where some societies/intelligencies develop until they >transcend mortal limitations, it seems a propos to Netcom. The idea >might even have something to do with renumbering, CIDR, encapsulation >etc. In that story, the gods numbered in the 100's or 1000's and lived >for years or centuries, while the millions of societies of billions of >individuals endured for millenia or millions of millenia, generally >completely ignorance of the existence of the gods. It was a reference, but was intended not to refer to the limitations but to the type of game they are playing. Netcom still has a lot of the limitations the small guys do, including finding sufficient good tech staff, equipment shortages, balky phone companies, etc. 8-) >Consider the pains suffered by one of the zillions of tiny ISP's when >it tries to be usefully multi-homed. Consider the pains of an >individual or Joe's Pizza Shoppe usefully multihomed to two neighborhod >ISP's, but needing a single DNS name and probably a single IP address >so that email and WWW serving does the right thing. The aggregate >weight of those tiny guys sounds dominent, sooner if not now. You have a perfectly valid point. >Don't say that the Joe's Pizza Shoppes will deal only with Netcom's. >That would be no more reasonable than saying that all pizza shops are >franchisees of big chains or all PC's are sold by the big chains (or >even built by the big vendors). > >Don't say that the tiny ISP's will be willingly singled-home. Many >will care about reliability. Having 2 IP wholesalers is about a >different kind of reliability than a gas station having 2 different >wholesalers. > >Don't say that no individuals will want to be multihomed. In my >private life I'm a customer of Netcom, and I really wish it were >practical for me to have a backup. (I'm not flaming Netcom; they're >just your standard, big company; more reliable than some but less than >I'd like.) > >Will the Netcom of the future be able to renumber its 100,000 >neighborhood ISP customers with their 20,000,000 end-users in a year? >Maybe or maybe not, depending on details of what those 20,000,000 do >for multi-homing, email, mobile-IP, and other stuff. I think that everyone is seeing these problems today, from the top levels of ISPs to the lowest, as well as individual and commercial customers. Many unanswered questions remain. I have a strong sense that the current strong multi-level structure with many small ISPs is stable in many ways. >ya'know, UUCP was kind of nice for multihoming. It could be said UUCP >died of routing table explosion (the maps) and competition from another >scheme which hid routing table hassles from the leaves. (please don't >bother to explain UUCP to me. Sgi.com &co still have many UUCP links, >but we're working on that.) Ahh, the Good Old Days 8-) Have no fear, UUCP (albeit with standard FQDN these days) is still going strong and will probably be alive into the next decade... -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 17:15:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02562; Mon, 4 Sep 1995 17:15:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA04980; Mon, 4 Sep 1995 17:14:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA04961; Mon, 4 Sep 1995 17:03:52 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02150; Mon, 4 Sep 1995 17:00:28 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzfrv06038; Mon, 4 Sep 1995 02:59:56 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Routing tables & what to do about them To: big-internet@munnari.OZ.AU Date: Mon, 4 Sep 1995 02:59:56 -0400 (EDT) X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 4138 Precedence: bulk As I have read a number of people's comments & concerns on this whole issue of routing table growth and ways of dealing with it, it strikes me that some folks may not realize the problem that we are attempting to deal with. The routing tables in the global Internet are growing, and the rate of this growth is causing problems. Today, in the global Internet, we already have routers that can not handle the size of today's routing tables (of some 30K routes). This has and is causing routing/connectivity problems for portions of the Internet. Upgrading and replacing these routers takes time. This does not only effect small providers or out of the way places on the Internet - for instance, AlterNet has 3 such routers, SprintLink has 5 (both have plans to replace these small routers; but such plans take time to implement & deploy). The rate of growth of the Internet is very fast - estimates of the current doubling rate are between 5 and 9 *months*. The time it takes to double is also getting shorter. Even if every router in the world today could handle the current routing table size, if every new site added to the Internet meant another new route, then 5 to 9 months from now the routing table would double, and double again in an additional 5 to 9 months. The computer industry is doubling the size of computers (cpu, memory) every 18 months; the Internet is growing some 2-3 times faster than this. So if we can only double our routers every 18 months or so, and the Internet is doubling every 5-9 months, sooner or later some aspect of the Internet (like routing tables) is going to hit the limit of our routers, even if we keep upgrading our routers as fast as the computer industry can do so. So we either need to figure out how to let the Internet continue its growth without certain measures of the Internet (like routing tables) growing as fast, or we need to realize that sooner or later, the Internet will cease to function, as its size will have outstripped the capabilities of our routers to handle it. As I rather doubt that anyone really wants the Internet to cease to function, we need to figure out how to handle adding new sites without every new site meaning a new route in the global routing tables. Now remember that things are already starting to break down (& have broken down in some cases). And remember that the growth rate is enormous (doubling every 5 to 9 months). We need to figure out what we can do today, that is already known to work, to reduce the growth rate of the routing tables. Today the only thing that does this is CIDR and renumbering. There are other things being thought about, talked about, designed, and worked on. None of this should stop. We will need the best ideas that we can come up with in the future. However we have to do something now, to make sure that there is a future. Now down to brass tacks. We are at 30K routes today with about 820 active ASs. This shows a very small amount of multihoming. The AlterNet customer base does active routing with us less than 1% of the time. Even if we had to have every multihomed site show up in the global routing tables, and even if every ISP was (or was going to be) multihomed, so what? There just are not that many of these to really matter. Remember what we are really after - holding down the growth rate of the routing tables - the routing tables are going to grow, we just don't want them to grow too fast. The enormous growth in the Internet are the singly homed sites. And most of these are small (in terms of numbers of hosts). If we just solve the problem of adding small singly homed sites to the Internet without adding a new route per site, then we have won! We have reduced the growth rate of the Internet's routing tables to something that we can handle. Renumbering such small singly homed sites is doable and will get us where we want to be - a slowdown in the growth of the Internet's routing tables. Then we will have the time to consider other options. But if we don't do this - then we are essentially dead. Its just a matter of time. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 17:34:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03248; Mon, 4 Sep 1995 17:34:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA05023; Mon, 4 Sep 1995 17:34:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA05017; Mon, 4 Sep 1995 17:32:58 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03203; Mon, 4 Sep 1995 17:32:48 +1000 (from huitema@pax.inria.fr) Received: from sophia.inria.fr by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05600 Mon, 4 Sep 1995 17:32:39 +1000 (from huitema@pax.inria.fr) Received: from [138.96.8.88] by sophia.inria.fr (8.6.12/8.6.12) with SMTP id JAA11723; Mon, 4 Sep 1995 09:30:09 +0200 Date: Mon, 4 Sep 1995 09:30:09 +0200 X-Authentication-Warning: sophia.inria.fr: Host sophmaccdc8.inria.fr claimed to be [138.96.8.88] Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Dave Crocker From: huitema@pax.inria.fr (Christian Huitema) Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu, inet-access@earth.com Precedence: bulk At 6:34 PM 31/8/95, Dave Crocker wrote: > > Network numbers are assigned by providers. Local providers will >get their CIDR block from their transit providers. End-users from their >attachment providers. Numbers & blocks will be 'leased', that is the >assignment is not permanent. If you change your up-link attachment, you >will need to return your block and get a new one from your new provider. >This necessitates renumbering. For local providers, it necessiates >renumbering by all your subscribers. I know I should know better and not enter this amusing contest. But then, what to do during transatlantic flights? Dave, your assumption that "ISP get their numbering space from the up link provider" is, IMHO, the core of the problem. To be frank, it is entirely incompatible with the business plans of the most ambitious ISP. Their buying of redondant capacity precisely aims at establishing them as "big providers". It is a normal path of growth. First a T1, then add a few more, then a couple T3, then team with a good pal here or there. This people are resellers of the capacity. They do want to buy that capacity at market place. At the end of the road, e.g. in v6 addressing, they get a provider number of they own right. Maybe we should just emulate that in v4. After all, one entry per ISP is a lot better than one entry per user... Christian Huitema From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 17:54:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04102; Mon, 4 Sep 1995 17:54:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA05066; Mon, 4 Sep 1995 17:54:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA05060; Mon, 4 Sep 1995 17:51:53 +1000 Received: from clyde.bdt.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04051; Mon, 4 Sep 1995 17:51:47 +1000 (from david@bdt.com) Received: by clyde.bdt.com (/\oo/\ Smail3.1.29.1 #29.4) id ; Mon, 4 Sep 95 00:55 PDT Message-Id: From: david@bdt.com (David Beckemeyer) Subject: Re: Multihoming To: Big-Internet@munnari.OZ.AU Date: Mon, 4 Sep 1995 00:55:38 -0700 (PDT) Cc: gherbert@crl.com Reply-To: david@bdt.com In-Reply-To: <199509040211.AA12716@mail.crl.com> X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 416 Precedence: bulk As one of the "single-homed for now" crowd, we have a strong desire (need) to be dual-homed as soon as possible, so any future proposal and/or solution that presumes smaller providers won't be dual-homed is very undesirable to me. -- David Beckemeyer (david@bdt.com) | Engineering/Connectivity Services Beckemeyer Development | Info: info@bdt.com P.O. Box 21575, Oakland, CA 94620 | WWW: From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 18:54:39 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06302; Mon, 4 Sep 1995 18:54:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA05177; Mon, 4 Sep 1995 18:53:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05173; Mon, 4 Sep 1995 18:51:04 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06179; Mon, 4 Sep 1995 18:50:56 +1000 (from dsiegel@rtd.com) Received: from RTD.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08569 Mon, 4 Sep 1995 18:50:36 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id BAA02985; Mon, 4 Sep 1995 01:45:15 -0700 From: Dave Siegel Message-Id: <199509040845.BAA02985@seagull.rtd.com> Subject: Re: Multihoming To: sob@newdev.harvard.edu (Scott Bradner) Date: Mon, 4 Sep 1995 01:45:15 -0700 (MST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199509040155.VAA05717@newdev.harvard.edu> from "Scott Bradner" at Sep 3, 95 09:55:45 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 909 Precedence: bulk > > Your claim that there is competition is on the order of claiming that > > because there are 1000 gas stations in the SF Bay Area there is competition > > even though all of them have to buy their gasoline from one of 8 suppliers > > Now, I'm not an ISP but I'd guess that the cost of the bacbone connection > is not the major part of the ISP's expenses so this might be a bit of a > reach as a comparison. You're right. It's not. The salaries are the highest single expense. The USWest phone bill is the second. Capital expenditures are somewhere in between there. The Internet links...combined, I guess (we have two) are substantially below the phone bill. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 18:59:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06420; Mon, 4 Sep 1995 18:59:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA05219; Mon, 4 Sep 1995 18:59:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05156; Mon, 4 Sep 1995 18:35:14 +1000 Received: from panix3.panix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05689; Mon, 4 Sep 1995 18:35:10 +1000 (from hal9001@panix.com) Received: (from hal9001@localhost) by panix3.panix.com (8.6.12/8.6.12+PanixU1.1) id EAA12325; Mon, 4 Sep 1995 04:35:06 -0400 X-Sender: hal9001@popserver.panix.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Mac Eudora Pro 2.1.3 Date: Mon, 4 Sep 1995 04:35:05 -0400 To: George Herbert From: "Robert A. Rosenberg" Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU, gherbert@crl.com Precedence: bulk At 19:11 9/3/95, George Herbert wrote: >Robert writes: >>Of these 140 how many peer at interchange points and how many are buying >>their interchange from a Sprint/MCI/Alternet/PSI/etc (ie: Are just leaves >>hung off of the network of another ISP)? > >A somewhat sorted, organized table derived from the ba.internet providers >list (site names deleted to save space and sorting pain...) follows. > >Note that a number of the sites listed are "leaf ISPs" hanging off one of >the other midsized bay area ISPs: tlg, scruznet, internex, nbn are all popular. > >Quick summary: > Backbones & direct connect to interchange points: 15 > Multihomed: 8 > Cix-only (?): 5 > Single homed: 105 Thank you for the table. This means that of those ~140 only ~20-30 actually show up in the Routing Tables (I count the 15 as having their own CIDR Blocks and assume that the Multi-Homed use two or more transit providers). All others are leaves off someone-else's CIDR block and thus do not get/need Global Routing as a unique Network. From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 19:01:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06455; Mon, 4 Sep 1995 19:01:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA05242; Mon, 4 Sep 1995 19:01:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05154; Mon, 4 Sep 1995 18:35:13 +1000 Received: from panix3.panix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05687; Mon, 4 Sep 1995 18:35:08 +1000 (from hal9001@panix.com) Received: (from hal9001@localhost) by panix3.panix.com (8.6.12/8.6.12+PanixU1.1) id EAA12321; Mon, 4 Sep 1995 04:34:58 -0400 X-Sender: hal9001@popserver.panix.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Mac Eudora Pro 2.1.3 Date: Mon, 4 Sep 1995 04:34:57 -0400 To: Tony Li From: "Robert A. Rosenberg" Subject: RE: Multihoming Cc: root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU Precedence: bulk At 17:11 9/3/95, Tony Li wrote: > Of these 140 how many peer at interchange points and how many are buying > their interchange from a Sprint/MCI/Alternet/PSI/etc (ie: Are just leaves > hung off of the network of another ISP)? > > Your claim that there is competition is on the order of claiming that > because there are 1000 gas stations in the SF Bay Area there is competition > even though all of them have to buy their gasoline from one of 8 suppliers > (numbers are hypothetical) and are only allowed to deal with one supplier > at a time and there are problems with switching suppliers (ie: To switch > from Exxon to Shell to Chevron is not an easy/quick deal). > >I fail to see your point. Yes, many of them have a direct connect to >one of the backbones. So? Yes, it's not an easy/quick deal. It >never could be "easy" for an ISP to change. That's a production >network that you're moving around, not a piece of toast. > >I really fail to see how this related to multihoming and whether or >not there's a monopoly here. Yes, there are a small number of default >free providers. It's obviously an open market as we're seeing >entries... and we're seeing moves between providers. OK - I'll rephrase. You state that there are 140 ISPs in the Bay Area. I ask how many of them are providing ACTUAL Connectivity (ie: Have their own IPN Network Number and are at a exchange point) and how many are just reselling someone-else's (ie: Their Provider's or ) Connectivity? So long as you are using a CIDR Block that belongs to someone-else (and that someone-else is the actual Provider with the Internet Connection) then you do not count so far as GLOBAL Routing is concerned (since the routes go the that Provider's Routers and then filter down a linkage chain to you). Of those 140, the only ones that Count for GLOBAL Routing are those who are Multi-Homed via SEPARATE Transit Providers. Having your Addresses from Sprintnet's CIDR Block and routing to the Internet via ISP1 and ISP2 (both of which go to Sprintnet for their connectivity) means that you are Sprintnet to the Global Routers. Using ISP1 and ISP3 (who uses MCI) means that you must be carried in the Router Tables (at least via an Announcement from MCI). Having your own CIDR Block (not one delegated by SprintNET or MCI) means that you get Announced by BOTH. From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 19:14:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06951; Mon, 4 Sep 1995 19:14:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA05297; Mon, 4 Sep 1995 19:14:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05209; Mon, 4 Sep 1995 18:57:16 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06391; Mon, 4 Sep 1995 18:57:13 +1000 (from gherbert@crl.com) Received: from crl6.crl.com by mail.crl.com with SMTP id AA00988 (5.65c/IDA-1.5); Mon, 4 Sep 1995 01:55:49 -0700 Message-Id: <199509040855.AA00988@mail.crl.com> To: "Robert A. Rosenberg" Cc: George Herbert , big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Multihoming In-Reply-To: Your message of "Mon, 04 Sep 1995 04:35:05 EDT." Date: Mon, 04 Sep 1995 01:55:48 -0700 From: George Herbert Precedence: bulk The danger in that assumption is that I personally know of 4 of those smaller ISPs which are going to dual-home shortly. That's out of 6 that I talk to regularly... If that is generalizable, then nearly all of those are going to try and go to dual homing over the next year. As asp pointed out, fortunately this only adds another hundred or so routes if things are done cleanly, but it is an issue. -george From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 19:17:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07171; Mon, 4 Sep 1995 19:17:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA05319; Mon, 4 Sep 1995 19:17:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05202; Mon, 4 Sep 1995 18:56:54 +1000 Received: from red.aa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06384; Mon, 4 Sep 1995 18:56:49 +1000 (from baron@aa.net) Received: (from baron@localhost) by red.aa.net (8.6.12/8.6.9) id BAA11097; Mon, 4 Sep 1995 01:56:21 -0700 Date: Mon, 4 Sep 1995 01:56:21 -0700 (PDT) From: Joe Portman To: Big-Internet@munnari.OZ.AU Subject: Re: Multihoming (fwd) Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk We're also moving towards multi-homing as fast as we can. It's a MUST if you are going to be a reliable provider, big or small. ----------------------------------------------------------------------------- Joe Portman - Alternate Access Inc. Affordable, Reliable Internet baron@aa.net Mercer Island: (206) 230-8732 Seattle: (206) 443-3408 Tacoma: (206) 927-6010 Federal Way: (206) 838-8457 Bellevue: (206) 455-8414 Everett: (206) ???-???? For free trial account: set modem to 8-n-1, login as "new" For questions or support, call our voice line (206) 728-9585. ----------------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 19:19:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07239; Mon, 4 Sep 1995 19:19:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA05342; Mon, 4 Sep 1995 19:19:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA05262; Mon, 4 Sep 1995 19:08:35 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06768; Mon, 4 Sep 1995 19:08:02 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id CAA18208; Mon, 4 Sep 1995 02:07:14 -0700 Date: Mon, 4 Sep 1995 02:07:14 -0700 From: Tony Li Message-Id: <199509040907.CAA18208@greatdane.cisco.com> To: hal9001@panix.com Cc: root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: (hal9001@panix.com) Subject: RE: Multihoming Precedence: bulk OK - I'll rephrase. You state that there are 140 ISPs in the Bay Area. I ask how many of them are providing ACTUAL Connectivity (ie: Have their own IPN Network Number and are at a exchange point) and how many are just reselling someone-else's (ie: Their Provider's or ) Connectivity? So long as you are using a CIDR Block that belongs to someone-else (and that someone-else is the actual Provider with the Internet Connection) then you do not count so far as GLOBAL Routing is concerned (since the routes go the that Provider's Routers and then filter down a linkage chain to you). Of those 140, the only ones that Count for GLOBAL Routing are those who are Multi-Homed via SEPARATE Transit Providers. Having your Addresses from Sprintnet's CIDR Block and routing to the Internet via ISP1 and ISP2 (both of which go to Sprintnet for their connectivity) means that you are Sprintnet to the Global Routers. Using ISP1 and ISP3 (who uses MCI) means that you must be carried in the Router Tables (at least via an Announcement from MCI). Having your own CIDR Block (not one delegated by SprintNET or MCI) means that you get Announced by BOTH. Thank you. I think that the numbers posted by George Herbert make my point very effectively: Quick summary: Backbones & direct connect to interchange points: 15 Multihomed: 8 Cix-only (?): 5 Single homed: 105 Multihoming is not a serious problem with respect to CIDR. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 20:54:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10376; Mon, 4 Sep 1995 20:54:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA05456; Mon, 4 Sep 1995 20:54:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA05449; Mon, 4 Sep 1995 20:40:56 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10081; Mon, 4 Sep 1995 20:40:52 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id DAA23871; Mon, 4 Sep 1995 03:40:51 -0700 Date: Mon, 4 Sep 1995 03:40:51 -0700 From: Tony Li Message-Id: <199509041040.DAA23871@greatdane.cisco.com> To: George Herbert , big-internet@munnari.OZ.AU Subject: Re: Multihoming Precedence: bulk The danger in that assumption is that I personally know of 4 of those smaller ISPs which are going to dual-home shortly. That's out of 6 that I talk to regularly... If that is generalizable, then nearly all of those are going to try and go to dual homing over the next year. As asp pointed out, fortunately this only adds another hundred or so routes if things are done cleanly, but it is an issue. Agreed. Further, it does not take into account the fact that some multihoming to topologically close attachment points can be absorbed via subsequent aggregation. The original question is whether multihoming was a significant problem for CIDR. I think that we've shown pretty definitively that it's not. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 20:57:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10461; Mon, 4 Sep 1995 20:57:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA05491; Mon, 4 Sep 1995 20:57:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA05446; Mon, 4 Sep 1995 20:40:15 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10053; Mon, 4 Sep 1995 20:40:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23177; Mon, 4 Sep 95 06:40:03 -0400 Date: Mon, 4 Sep 95 06:40:03 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041040.AA23177@ginger.lcs.mit.edu> To: hal9001@panix.com, tli@cisco.com Subject: RE: Multihoming Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Robert A. Rosenberg" the only ones that Count for GLOBAL Routing are those who are Multi-Homed via SEPARATE Transit Providers. No. There are at least two ways to provide connectivity via separate transit providers, without causing a routing announcement of global scope. There's another way to connect to several transit providers and use only a small share of a global routing announcement. I don't know if you knew this, and had some operational requirement that wouldn't be met by any of the three schemes below, but either way your statement is not helpful, in that it's either: - i) insufficiently detailed to give us some useful info on what it is that you want above and beyond what these give you, or - ii) wrong. I trust that everyone will heed the implicit suggestion here, without my needing to be unpleasant... Now, back to the technical stuff. The first way is to impose some aggregation structure above the providers, and if you at that point pick two providers who share an aggregate, you can have a separate address (at a peer level in the addresing hierarchy) which has a routing scope which is limited to that naming abstraction. The second way is to pick an address which is subsidiary to your primary provider. Then, advertisements can be limited to a routing scope which includes you and your secondary. The third way is to form an exchange-point cooperative with some other small ISP's. If you would point out why none of these meets your particular requirements, that would be useful. Oh, and please be aware that your requirements may not be meetable. I'd like to be able to levitate, too... Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 20:59:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10493; Mon, 4 Sep 1995 20:59:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA05513; Mon, 4 Sep 1995 20:59:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA05452; Mon, 4 Sep 1995 20:49:42 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10256; Mon, 4 Sep 1995 20:49:38 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23208; Mon, 4 Sep 95 06:49:31 -0400 Date: Mon, 4 Sep 95 06:49:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041049.AA23208@ginger.lcs.mit.edu> To: barney@databus.com, big-internet@munnari.OZ.AU Subject: Re: Multihoming Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Barney Wolff > A more-specific route to you is only visible inside Sprint and MCI. You're claiming that MCI does not have to advertise me outside itself (and neither does Sprint). No, MCI has to advertise its route to you to Sprint, and vice versa. I wasn't clear about that. Ok, so now my link to Sprint .. goes down. People inside MCI can still get to me, but people outside both, and even people inside Sprint, cannot get to me, because only MCI knows how, and it's not supposed to tell anybody. No, everyone can get to you. People send their traffic to Sprint, which ships it to MCI, which sends it to you. How is MCI supposed to know that it really should be advertising me to Sprint but to nobody else?o Configuration of routing scopes. Not easy, I know, but there is nothing better at the moment. (Like I said, I want to go off and think about this issue of how optimal AAB's change when you get failures; I think this is because the graph itself has changed. Hmmm...) In theory, it could notice that my address comes from Sprint's CIDR block and deduce it from that Well, that trick might work for direct connected, but suppose your two providers are not directly connected? Some provider(s) in the middle are going to have to pass routes through. Not simple. RFC1519 appears to assume otherwise: So? There's nothing there that's wrong. Multihoming is not a simple capability to provide in any addressing system. We're now trying to figure out how (if) we can provide it to a high % of ISP's... My requirements for legitimate multi-homing would include reasonable load- sharing when both links are up I assume by reasonable, you don't mean "better than optimal routing would give you"? (I.e. if you are multi-homed, and one link is to the edge of the net, and the other is to the center, more traffic would naturally tend to flow into the one to the center.) Getting better than that is Not Trivial. Come to think of it, getting close to that is not easy, at least not in a big net... Well, we might or might not be able to do something reasonably close to that without a global routing scope, but it depends on the topology of the network, where you multihome, what the address structure looks like (it has suddenly struck me that we might have to renumebr the entire Internet into a rational addressing plan....), etc, etc. The scheme above can get close to it, although the cost in routing overhead will depend on the variables above, as well as how close to optimal you want the routing to be. and universal reachability, even if not optimal routing, when one is down. The scheme above already gives you that. Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 21:14:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10802; Mon, 4 Sep 1995 21:14:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA05552; Mon, 4 Sep 1995 21:14:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA05546; Mon, 4 Sep 1995 21:12:16 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10770; Mon, 4 Sep 1995 21:12:12 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23290; Mon, 4 Sep 95 07:12:06 -0400 Date: Mon, 4 Sep 95 07:12:06 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041112.AA23290@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu Subject: RE: Multihoming Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker > Rather than tell the network designers how to provide that reliability, > perhaps a better approach would be to say what you need that approach is what got us into the current bind. First, I don't recall a torrent of discussion about multi-homing three years ago when the CIDR debate happened. Second, not everyone on this list is equally steeped in routing theory, so inevitably what's going to happen is that the eventual solution (if any) is not going to come from someone with zero knowledge. This may not be apparent to you, for obvious reasons, but it's true, nonetheless. I mean, oh gee, folks need to multihome their connections and not change the IP addresses of every machine in their organization when they change providers and not cause local providers to force all their customers to renumber when THEY change providers? wow. that's amazing. we really should have asked the users to find this stuff out. That addresses would have to change when people moved was utterly implicit was instantly obvious, *or should have been*, when CIDR was picked as the solution to bullet two. If it wasn't, then the members of the IETF have only themselves to blame for making decisions in areas they didn't understand. Your comments here are entirely unhelpful. Do you actually have a practical suggestion, or are you just being, as usual, an irrelevant noise? right, noel. Like I said, irrelevant noise. Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 21:34:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11728; Mon, 4 Sep 1995 21:34:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA05595; Mon, 4 Sep 1995 21:34:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA05572; Mon, 4 Sep 1995 21:23:29 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11127; Mon, 4 Sep 1995 21:23:16 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23351; Mon, 4 Sep 95 07:22:51 -0400 Date: Mon, 4 Sep 95 07:22:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041122.AA23351@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, gherbert@crl.com, tli@cisco.com Subject: Re: Multihoming Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Tony Li > If that is generalizable, then nearly all of those are going to try and > go to dual homing over the next year. The original question is whether multihoming was a significant problem for CIDR. I think that we've shown pretty definitively that it's not. It certainly is the case that there will be orders of magnitude more customers than ISP's. We cannot give the latter portable addresses and have the routing cope, so we're really just arguing around the edges. Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 21:54:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12346; Mon, 4 Sep 1995 21:54:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA05632; Mon, 4 Sep 1995 21:54:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA05615; Mon, 4 Sep 1995 21:37:04 +1000 Received: from blob.best.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11782; Mon, 4 Sep 1995 21:36:32 +1000 (from jim@SmallWorks.COM) Received: from hosaka.smallworks.com (hosaka.SmallWorks.COM [192.207.126.1]) by blob.best.net (8.6.12/8.6.5) with SMTP id EAA16415 for ; Mon, 4 Sep 1995 04:36:24 -0700 Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA17815; Mon, 4 Sep 1995 06:35:49 -0500 From: "Jim Thompson" Message-Id: <9509040635.ZM17813@hosaka.smallworks.com> Date: Mon, 4 Sep 1995 06:35:48 -0500 In-Reply-To: George Herbert "Re: ISP shakeout" (Sep 3, 11:28pm) References: <199509040628.AA17286@mail.crl.com> Organization: Team Big Brother X-Dogma: Microsoft is not the answer. Microsoft is the question. No is the answer. X-Mailer: Z-Mail (3.2.0 06sep94) To: George Herbert Subject: Re: ISP shakeout Cc: big-internet@munnari.OZ.AU Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk On Sep 3, 11:28pm, George Herbert wrote: > Ahh, the Good Old Days 8-) Have no fear, UUCP (albeit with standard > FQDN these days) is still going strong and will probably be alive into > the next decade... Just like FORTRAN. Jim -- Jim Thompson jim@SmallWorks.COM From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 22:34:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13644; Mon, 4 Sep 1995 22:34:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA05701; Mon, 4 Sep 1995 22:34:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA05678; Mon, 4 Sep 1995 22:13:57 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12924; Mon, 4 Sep 1995 22:13:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23596; Mon, 4 Sep 95 08:13:48 -0400 Date: Mon, 4 Sep 95 08:13:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041213.AA23596@ginger.lcs.mit.edu> To: gherbert@crl.com, kre@munnari.OZ.AU Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz On one hand we have people saying that clients don't actually switch connections very often ... On the other hand, we have all this moving between providers going on ... These don't quite reconcile to me, which is it really? I suspect you have different people saying these two things. That's part of the problem here, we don't have a clear crystal ball. Of course, what we do will also affect what range of visions are possible in that crystal ball... The original CIDR docs assumed the first, and planned to be able to handle moving providers without requiring renumbering though it recommended it as a good idea where possible. Here we see one of the problems with that document. True, it didn't *require* renumbering, and *in fact* you *can* let *some* people move without renumbering. On the other hand, it also makes the assumption of technology: capable of dealing with the current routing table size and with some reasonably small rate of growth. It should be instantly obvious that if *lots* of people move, multi-home globally, etc, that assumption would not be met, since the growth of the routing table would not be "reasonably small". That's the problem with statements like the only you're relying on: this plan neither requires nor assumes that already assigned addresses will be reassigned ... Note that this plan does not require domains to renumber if they change their attached transit routing domain. People take them like they are some sort of ironclad guarantee without any limits, and rely on them in ways in which it was never intended they be relied on. Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 22:37:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13726; Mon, 4 Sep 1995 22:37:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA05721; Mon, 4 Sep 1995 22:36:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA05695; Mon, 4 Sep 1995 22:28:42 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13582; Mon, 4 Sep 1995 22:28:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23604; Mon, 4 Sep 95 08:26:47 -0400 Date: Mon, 4 Sep 95 08:26:47 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041226.AA23604@ginger.lcs.mit.edu> To: barrett@iafrica.com, kre@munnari.OZ.AU Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz > For example, if Barney is multi-homed to Sprint and MCI, and gets > address space from Sprint, then Sprint and MCI both need to carry > Barney's routes internally, but Alternet, PSI, ..., need not carry > Barney's specific routes, because they could be covered by a larger > (Sprint) aggregate. And when the Spring link is down, no-one on Alternet knows of the MCI link, and the sites multi-homing is close to useless. No. You may not have thought this through, but a scheme that fits within the above description *does* provide continued connectivity. It merely requires that Sprint be willing to accept routes from MCI about Barney. I.e., there is no more routing overhead, just a slight configuration difference. If so, when the Sprint-Barney link fails, Sprint finds out about an alternate path to Barney via MCI. The traffic from the rest of the net continues to go to Sprint, which ships it to MCI, which gives it to Barney. which would mean sites would need to get addresses from their backup provider ... The effect of that is that the link you're most likely to change ... is the one that has your address tied to it. No. You should use an address from either i) the provider you are least likely to change, or ii) the one which gives you the best overall traffic balance, depending on which is more important to you. If there were an aggregate that covered both of them (and excluded someone else) then an address from that block would make sense - but there isn't. Perhaps there should be. Of course, as I said in a previous message, this would imply renumbering the entire net into a rational addressing plan. What a concept. We'll actually design something about the overall net; if not it's overall topology, then the address plan for it.... Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 22:54:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14197; Mon, 4 Sep 1995 22:54:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA05760; Mon, 4 Sep 1995 22:54:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA05754; Mon, 4 Sep 1995 22:41:15 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13899; Mon, 4 Sep 1995 22:41:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23630; Mon, 4 Sep 95 08:41:07 -0400 Date: Mon, 4 Sep 95 08:41:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041241.AA23630@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, nectar@communique.net Subject: Re: Multihoming and CIDR Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Jacques Vidrine Let's assume .. that everyone designs their network so that they can get it renumbered withing a week. Now let's say a small to medium ISP has to renumber. Can the ISP get all of it's customers to renumber withing 6 months, or a year? How fast would the ISP and it's customers have to make the transition? This question points out several things. 1 - Renumbering doesn't have to be a flag day; you can assign multiple addresses to each network (most routers support this), and slowly transition, one host at a time. 2 - ISP's generally won't switch providers at the drop of a hat. Business realities being what they are, it's usually a process that will take a while, I expect. First, the ISP has to make a decision to move, and then there will have to be some planning, coordination, etc, between the ISP and its new provider. During this period, the ISP should be communicating with its customers about what's going on. Maybe by the end of this long weekend, Noel will have done some more thinking and have more to say about dynamic ANBs and AABs.) Don't count on it. Maybe I can come up with some tweaks around the edges (and AAB's which aren't matched to ANB's, non-gruent AAB's, etc are all tweaks on the basics of K+K), but in general the TANSTAAFL principle of routing says there is no magic bullet. Opimal routing in large networks, with portable addresses, is just never going to be an O(1), or even an O(logN), problem. (Most important?) How can we make sure that everyone who is making significant network architecture decisions is educated? Another "no magic bullet". We could bring everyone on Big-I up to 100% percect speed on graph theory, and two years from now the list would have a large share (it not a majority) of people who were new, and we'd have the same argument all over again. Gee, that description sounds familiar, now that I say it... Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 23:16:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15042; Mon, 4 Sep 1995 23:16:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA05813; Mon, 4 Sep 1995 23:14:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA05809; Mon, 4 Sep 1995 23:13:54 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14922; Mon, 4 Sep 1995 23:13:50 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id JAA06835; Mon, 4 Sep 1995 09:13:39 -0400 (EDT) Date: Mon, 4 Sep 1995 09:13:39 -0400 (EDT) From: Scott Bradner Message-Id: <199509041313.JAA06835@newdev.harvard.edu> To: dcrocker@brandenburg.com, huitema@pax.inria.fr Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu, inet-access@earth.com Precedence: bulk > After all, one entry per ISP is a lot better than one entry per user. As long as its a large enough ISP to have a "short" routing prefix. There is some (fuzzy & changing) threshold as to the minimum sized ISP that should be considered "big enough" to fit this rule. Scott From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 23:21:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15239; Mon, 4 Sep 1995 23:21:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA05839; Mon, 4 Sep 1995 23:19:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA05791; Mon, 4 Sep 1995 22:59:33 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14362; Mon, 4 Sep 1995 22:58:52 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23649; Mon, 4 Sep 95 08:58:44 -0400 Date: Mon, 4 Sep 95 08:58:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041258.AA23649@ginger.lcs.mit.edu> To: kre@munnari.OZ.AU, tli@cisco.com Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz the problem seems to be all those zillions of people ... giving all those people portable addresses and advertising them would bee a disaster. Well, I'm glad to see you agree on that much (I'm not sure everyone else, does, yet), but.... how are you going to explain to these people that they can't have portable addresses, but Mom-and-Pop's ISP can? the ones of more interest to me are the commercial users of the net ... with about a hundred or so hosts ... Those people will multi-home. They also have more difficulty renumbering (some need to be active all the time for business reasons, they can't just stop for 30 minutes to renumber). I'm not sure about the first (they'd be better off with a redundant link to a provider who is multi-homed), and for the second, you don't have to use "flag days" to renumber. local providers, as even if those providers aren't multi-homed themselves, their connections are not likely to be topologically close - why should they be? One provider may use Sprint for their connectivity, anotheer MCI You have just contradicted yourself. Sprint and MCI *are* topologically close; they are connected, which is about as topologically close as you can get. Of course, if Sprint and MCI get large enough, they will have the kind of problems internally we are talking about now. The local providers are all serving the same market, they aren't necessarily even close topologically though - unless we decide to do some kind of geographic based forcing of interconnects Even if we did that, a multihomed local provider would have connections which were topologically no closer than they would be without it, on average (see above). Anyway, your basic point, that multihoming of customers to two different local providers is going to be hard to handle in the routing, has some point to it. I'm too burned out to explain why; it ought to be intuitively obvious to everyone on this list. if multi-homing is growing exponentially, then the eventual routing plan is going to have to learn to cope with that, not just ignore it. If the number of cars on the road in LA is growing exponentially, should the road network just learn to cope with it, and pave over all of LA, or should poeple come to grips with the fact that most exponential growths cannot be handled indefinitely? We can handle some multihoming, and, depending on a lot of factors like how we do it, what the net's topology and addressing hierarchy look it, etc, etc, maybe a lot. But we can't make water run uphill, no matter how hard we try. We have to learn to live with the fact that it runs downhill, and so far, we seem to be doing OK on that front. I look foward (naively and optimistically, perhaps) to the day when everyone is as familiar with the (sometimes painful) limits of routing they are with the (sometimes painful) limits of gravity. Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 23:34:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15681; Mon, 4 Sep 1995 23:34:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA05884; Mon, 4 Sep 1995 23:34:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA05877; Mon, 4 Sep 1995 23:31:56 +1000 Received: from ns.iij.ad.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15575; Mon, 4 Sep 1995 23:31:43 +1000 (from davidc@iij.ad.jp) Received: from argus.iij.ad.jp (argus.iij.ad.jp [192.244.176.41]) by ns.iij.ad.jp (8.6.12+2.4W/3.3W9-NS) with SMTP id WAA14634; Mon, 4 Sep 1995 22:28:08 +0900 Message-Id: <199509041328.WAA14634@ns.iij.ad.jp> To: Scott Bradner Cc: dcrocker@brandenburg.com, huitema@pax.inria.fr, big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu, inet-access@earth.com, davidc@ns.iij.ad.jp Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: Your message of "Mon, 04 Sep 1995 09:13:39 -0400." <199509041313.JAA06835@newdev.harvard.edu> Date: Mon, 04 Sep 1995 22:29:41 +0900 From: David R Conrad Precedence: bulk >There is some (fuzzy & changing) threshold as to the minimum sized ISP >that should be considered "big enough" to fit this rule. We can't even figure out what an ISP is, and you want to come up with what's big and little? Regards, -drc From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 23:36:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15736; Mon, 4 Sep 1995 23:36:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA05908; Mon, 4 Sep 1995 23:36:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA05880; Mon, 4 Sep 1995 23:33:45 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15659; Mon, 4 Sep 1995 23:33:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23737; Mon, 4 Sep 95 09:33:37 -0400 Date: Mon, 4 Sep 95 09:33:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041333.AA23737@ginger.lcs.mit.edu> To: kre@munnari.OZ.AU, nectar@communique.net Subject: Re: Multihoming and CIDR Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz If we assume that the routers all keep one doubling's worth of capacity free, then that's 5-9 months of growth they can handle. This statement assumes that we can continue to provide more of all the resources consumed by routing overhead. I'm not sure this is justified. For instance, the stabilization time for a distributed routing computation is effected by the size of the network, number of destinations tracked, etc. Perhaps, in the future, the current routing architecture, which depends on a "flood" rather than an "inquiry" model, and fully distributed computation, will simply not work any more, and we'll have to go to a system which is very different. However, you can bet your last $$$ that will involve changes even more painful and far-reaching..... Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 23:39:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15769; Mon, 4 Sep 1995 23:39:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA05933; Mon, 4 Sep 1995 23:39:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA05824; Mon, 4 Sep 1995 23:17:39 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15059; Mon, 4 Sep 1995 23:17:33 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id JAA01661; Mon, 4 Sep 1995 09:19:41 -0400 Date: Mon, 4 Sep 1995 09:19:40 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Multihoming To: Nathan Stratton Cc: Barney Wolff , big-internet@munnari.OZ.AU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk it could be done. and this shows that in this case, as in all such, the providers who don't cooperate lose business. You pay only one. If they were smart both would have good business. Mike On Sun, 3 Sep 1995, Nathan Stratton wrote: > On Sun, 3 Sep 1995, Barney Wolff wrote: > > > My requirements for legitimate multi-homing would include reasonable load- > > sharing when both links are up, and universal reachability, even if > > not optimal routing, when one is down. > > Ya, and right now that can not be done, We have a sprintlink T1 and > wanted to do "legitimate multi-homing" with MCI and sprint. WE had to drop > the MCI, and now we are getting a 10 meg into MAE and just using sprint > for transit. > > > Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! > --------------------------------------------------------------------------- > Phone (703)524-4800 NetRail, Inc. > Fax (703)534-5033 2007 N. 15 St. Suite B-5 > Email sales@netrail.net Arlington, Va. 22201 > WWW http://www.netrail.net/ Access: (703) 524-4802 guest > --------------------------------------------------------------------------- > > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 23:42:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15868; Mon, 4 Sep 1995 23:42:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA05966; Mon, 4 Sep 1995 23:41:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA05874; Mon, 4 Sep 1995 23:26:12 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15359; Mon, 4 Sep 1995 23:26:03 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id JAA01675; Mon, 4 Sep 1995 09:28:13 -0400 Date: Mon, 4 Sep 1995 09:28:12 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Tony's answer: To: Tony Li Cc: big-internet@munnari.OZ.AU In-Reply-To: <199509040605.XAA10055@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Tony Li wrote: > > Of course, Cisco's BGP implementation is academically correct, but > computationally suicidal: each time something moves it gets erased from > memory. > > No, actually it doesn't. But that's not what you asked. The point is > that whether you erase it or flag it, you still have per-prefix > computation. the computation would be done for all paths and sitting ready > > Why we should not do this: > > Let me do an analogy: no Ferrari, no cars at all, just relaxing woods. > Imagine you are in the woods. What do you see? Trees, bushes, all kind of .... > We know, even when we sleep that the alarm clock will be at the same > place tomorrow. It is rare that in moves, but that can happen if I sweep > it off the nightstand. > > I think what you're proposing is that once we lose a prefix we simply > black hole the traffic until we hear the original prefix and path > again. Is that correct? > no, we have alternate paths calculated ready sitting. > Routes: why must a router totally delete a route of a set that points to > such are not used and withdrawn towards the igp, whichever you chose. If ... > you chose ospf you are lucky, it does the same. > > How does this help? What does this solve? > the exchanged information entity to say 'is up again' is smaller, no? when we have lots of flaps we want to keep the exchanged data volume low. > Tony > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 23:54:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16252; Mon, 4 Sep 1995 23:54:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA06008; Mon, 4 Sep 1995 23:54:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA05910; Mon, 4 Sep 1995 23:36:34 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15724; Mon, 4 Sep 1995 23:36:31 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id JAA19138; Mon, 4 Sep 1995 09:36:22 -0400 Date: Mon, 4 Sep 1995 09:36:22 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: George Herbert Cc: "Robert A. Rosenberg" , George Herbert , big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Multihoming In-Reply-To: <199509040855.AA00988@mail.crl.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, George Herbert wrote: > The danger in that assumption is that I personally know of 4 of those smaller > ISPs which are going to dual-home shortly. That's out of 6 that I talk to > regularly... This is a general query, but.. how many of these small ISPs who want to dual home know 1) how to run BGP, and 2) how to manage dual homed routing? Esp. in the case when they have their own CIDR blocks? We have a customer who is going to, but it seems they don't have a clue as to above... a pretty worrisome situation... Is this common or are we just unlucky? -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Mon Sep 4 23:57:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16325; Mon, 4 Sep 1995 23:57:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA06041; Mon, 4 Sep 1995 23:56:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA05976; Mon, 4 Sep 1995 23:43:12 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15968; Mon, 4 Sep 1995 23:42:55 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id JAA01681; Mon, 4 Sep 1995 09:44:46 -0400 Date: Mon, 4 Sep 1995 09:44:45 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Routing tables & what to do about them To: Andrew Partan Cc: big-internet@munnari.OZ.AU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Andrew Partan wrote: > As I have read a number of people's comments & concerns on this whole > issue of routing table growth and ways of dealing with it, it strikes ... > > Renumbering such small singly homed sites is doable and will get us > where we want to be - a slowdown in the growth of the Internet's > routing tables. > > Then we will have the time to consider other options. > > But if we don't do this - then we are essentially dead. Its just a > matter of time. > --asp@uunet.uu.net (Andrew Partan) > Everybody agrees, only, the burden should not be placed on the customer. Smallsites, i.e. a web service provider with a couple of hosts and hopefully only a subnet assigned, will probably be able to, and agree, to renumber. For them it is more imprtant that DNS works fine, there is not much cost involved to renumber next time they are down (;-) ). For bigger entities, e.g. small ISPs, with a dozen or so customers, this is a problem, especially if they have one or two 'good' customers, like mid size enterprise type. We cannot put the burden on them, to ask their customer to renumber. I would say, renumber by putting for this a NAT at a strategical aggregation point in the network. Everything below is renumbered. This 'leasing' thing of the addresses is the point: it is too strict and really is contra free enterprise. My opposition is purely against the latter. When we get customers that swith, most of them are willing to renumber. Some just might not be able to do it -- at this point in time -- . They could not survive if they would have to release their addresses the moment they stop service with some other provider, who even might have gone out of business but have a legal successor who wants the addresses. This is my strong pposition point here, and I guess there are some out there that share this. Mike ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 00:14:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17247; Tue, 5 Sep 1995 00:14:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA06086; Tue, 5 Sep 1995 00:14:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA06067; Tue, 5 Sep 1995 00:03:13 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16743; Tue, 5 Sep 1995 00:02:58 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id KAA01699; Mon, 4 Sep 1995 10:05:06 -0400 Date: Mon, 4 Sep 1995 10:05:05 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Multihoming To: Noel Chiappa Cc: barrett@iafrica.com, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9509041226.AA23604@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Noel Chiappa wrote: > From: Robert Elz > > > For example, if Barney is multi-homed to Sprint and MCI, and gets > > address space from Sprint, then Sprint and MCI both need to carry > > Barney's routes internally, but Alternet, PSI, ..., need not carry > > Barney's specific routes, because they could be covered by a larger > > (Sprint) aggregate. > > And when the Spring link is down, no-one on Alternet knows of the > MCI link, and the sites multi-homing is close to useless. > > No. You may not have thought this through, but a scheme that fits within the > above description *does* provide continued connectivity. It merely requires > that Sprint be willing to accept routes from MCI about Barney. I.e., there is > no more routing overhead, just a slight configuration difference. when I see those Sprint things: Barney would need a prefix of 18 or less It is this kind of attitude that creates Barney's problem. Not CIDR or routers or anything else. Mike > > Noel > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 00:54:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18607; Tue, 5 Sep 1995 00:54:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA06356; Tue, 5 Sep 1995 00:54:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA06339; Tue, 5 Sep 1995 00:36:22 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18104; Tue, 5 Sep 1995 00:36:19 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id KAA19481; Mon, 4 Sep 1995 10:36:10 -0400 Date: Mon, 4 Sep 1995 10:36:09 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: "Michael F. Nittmann" Cc: Andrew Partan , big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Michael F. Nittmann wrote: > Everybody agrees, Really? Does everyone agree with Andrew? I wonder.. > only, the burden should not be placed on the customer. . . . . > For bigger entities, e.g. small ISPs, with a dozen or so customers, this > is a problem, especially if they have one or two 'good' customers, like > mid size enterprise type. We cannot put the burden on them, to ask their > customer to renumber. . . . . > My opposition is purely against the latter. When we get customers that > swith, most of them are willing to renumber. Some just might not be able > to do it -- at this point in time -- . They could not survive if they > would have to release their addresses the moment they stop service with > some other provider, who even might have gone out of business but have a > legal successor who wants the addresses. But are we really asking for a flag day readdressing? I for one don't think so, and anyone who is has no idea of operational realities of the Internet. Given the fact that there are no good tools to renumber is, any plan that requires a flg day renumbering is unworkable. However, given a reasonable transition period, something even as massive as renumbering 68 class Cs is doable. Not painless, but doable, and I'm speaking from operational experience. Renumbering with a reasonable transition period, IMO, will help slow down the growth of the routing table, and be feasible. And if we let those sites that absolutes CANNOT renumber be, but still renumber those that can, this is still a win. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 01:14:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19272; Tue, 5 Sep 1995 01:14:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA06406; Tue, 5 Sep 1995 01:14:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA06389; Tue, 5 Sep 1995 00:57:41 +1000 Received: from poblano.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18751; Tue, 5 Sep 1995 00:57:20 +1000 (from jcurran@bbnplanet.com) Received: from jcurran-ppp.near.net by poblano.bbnplanet.com id aa08852; 4 Sep 95 10:56 EDT X-Sender: jcurran@198.114.157.116 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Sep 1995 10:57:15 -0400 To: Andrew Partan From: John Curran Subject: Re: Routing tables & what to do about them Cc: big-internet@munnari.OZ.AU Precedence: bulk Excellent note. It probably won't reduce the email which is effectively advocating global geometric routing growth, but it puts such mail nicely in perspective. /John === At 2:59 AM 9/4/95, Andrew Partan wrote: >As I have read a number of people's comments & concerns on this whole >issue of routing table growth and ways of dealing with it, it strikes >me that some folks may not realize the problem that we are attempting >to deal with. >... >So if we can only double our routers every 18 months or so, and the >Internet is doubling every 5-9 months, sooner or later some aspect of >the Internet (like routing tables) is going to hit the limit of our >routers, even if we keep upgrading our routers as fast as the computer >industry can do so. > >So we either need to figure out how to let the Internet continue its >growth without certain measures of the Internet (like routing tables) >growing as fast, or we need to realize that sooner or later, the >Internet will cease to function, as its size will have outstripped the >capabilities of our routers to handle it. > >As I rather doubt that anyone really wants the Internet to cease to >function, we need to figure out how to handle adding new sites without >every new site meaning a new route in the global routing tables. > >Now remember that things are already starting to break down (& have >broken down in some cases). And remember that the growth rate is >enormous (doubling every 5 to 9 months). We need to figure out what we >can do today, that is already known to work, to reduce the growth rate >of the routing tables. > >Today the only thing that does this is CIDR and renumbering. > >There are other things being thought about, talked about, designed, and >worked on. None of this should stop. We will need the best ideas that >we can come up with in the future. > >However we have to do something now, to make sure that there is a >future. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 01:34:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19969; Tue, 5 Sep 1995 01:34:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA06445; Tue, 5 Sep 1995 01:34:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA06430; Tue, 5 Sep 1995 01:24:10 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19588; Tue, 5 Sep 1995 01:23:58 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id LAA00978; Mon, 4 Sep 1995 11:23:09 -0400 Date: Mon, 4 Sep 1995 11:23:07 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Simon Spero Cc: Andrew Molitor , big-internet@munnari.OZ.AU Subject: Re: The Conspiracy - In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Simon Spero wrote: > Hah! The running dogs of internation capitalism reveal their > conspiracy. Let us rise up and crush them with an Iron Fist of > unaggregated freedom. > > The National Union of Computer Operatives (Hackers local 42) calls for a > general strike on 9/4/95, Labour day. Internet On Strike! > > Forward the Internetworkale! Power Comes From the Barrel of a GNU! > > Very funny. NOT. I guess the only way you know how to answer valid business concerns by a large group of Internet consumers is to ridicule them. The above composition proves that you really do not have good answers and so you are stooping to ridicule. I was hoping that this thread would die out but your attack above needs a response. Capitalism and monopolies can not live together. To be more accurate, the first sentence of your post should read: > Hah! The running dogs of international monopolists reveal their > conspiracy against the capitalists. Let us rise up and crush them with an > Iron Fist of free enterprise. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 01:56:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20748; Tue, 5 Sep 1995 01:56:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA06490; Tue, 5 Sep 1995 01:54:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA06486; Tue, 5 Sep 1995 01:50:37 +1000 Received: from ACADEM.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20489; Tue, 5 Sep 1995 01:50:34 +1000 (from sob@academ.com) Received: (from sob@localhost) by academ.com (8.6.12/8.6.9) id KAA03016; Mon, 4 Sep 1995 10:49:29 -0500 Message-Id: <199509041549.KAA03016@academ.com> From: sob@academ.com (Stan Barber) Date: Mon, 4 Sep 1995 10:49:29 CDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: Sanjay Kapur , Simon Spero Subject: Re: The Conspiracy - Cc: Andrew Molitor , big-internet@munnari.OZ.AU Precedence: bulk > Capitalism and monopolies can not live together. > > Sanjay Kapur > Kapur Business Systems, Inc. Sanjay, this is just not a true statement. There are plenty of existance proofs that show this to be wrong. Electric companies are just one example that come to mind. There are a number of monopolies that exist in this capitalist society. You may argue that ideally this is the case, but this is not an ideal world. I am not an economist so I will not debate the ideal. -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 01:58:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20801; Tue, 5 Sep 1995 01:58:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA06537; Tue, 5 Sep 1995 01:58:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA06480; Tue, 5 Sep 1995 01:47:13 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20394; Tue, 5 Sep 1995 01:47:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23937; Mon, 4 Sep 95 11:47:07 -0400 Date: Mon, 4 Sep 95 11:47:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041547.AA23937@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mn@ios.com Subject: Re: Multihoming Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "Michael F. Nittmann" >>> if Barney is multi-homed to Sprint and MCI, and gets address space from >>> Sprint, then Sprint and MCI both need to carry Barney's routes >> And when the Spring link is down, no-one on Alternet knows of the >> MCI link, and the sites multi-homing is close to useless. > No. ... the above description *does* provide continued connectivity. It > merely requires that Sprint be willing to accept routes from MCI about > Barney. when I see those Sprint things: Barney would need a prefix of 18 or less We were talking about multihomed ISP's, right? Are there a lot of ISP's with a, say, /24? It is this kind of attitude that creates Barney's problem. Not CIDR or routers or anything else. I am unable to parse this piece of political rhetoric. Could you provide details on exactly what technical problem Barney theoretically has in this scenario? Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 01:59:39 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20841; Tue, 5 Sep 1995 01:59:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA06557; Tue, 5 Sep 1995 01:59:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA06483; Tue, 5 Sep 1995 01:49:12 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20458; Tue, 5 Sep 1995 01:49:04 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id LAA01042; Mon, 4 Sep 1995 11:48:41 -0400 Date: Mon, 4 Sep 1995 11:48:40 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Andrew Partan Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Andrew Partan wrote: > Even if we had to have every multihomed site show up in the global > routing tables, and even if every ISP was (or was going to be) > multihomed, so what? There just are not that many of these to really > matter. Remember what we are really after - holding down the growth > rate of the routing tables - the routing tables are going to grow, we > just don't want them to grow too fast. > > The enormous growth in the Internet are the singly homed sites. And > most of these are small (in terms of numbers of hosts). > > If we just solve the problem of adding small singly homed sites to the > Internet without adding a new route per site, then we have won! We > have reduced the growth rate of the Internet's routing tables to > something that we can handle. > > Renumbering such small singly homed sites is doable and will get us > where we want to be - a slowdown in the growth of the Internet's > routing tables. > > Then we will have the time to consider other options. > > But if we don't do this - then we are essentially dead. Its just a > matter of time. > --asp@uunet.uu.net (Andrew Partan) > I have proposal: Don't the backbone sites charge a fee for advertising routes (as part of their service)? They should make the fee high enough to slow down the growth of the routing tables to a reasonable value. This fee should be lower if the numbers are out of the backbone provider's CIDR block (existing shared route) and higher otherwise. Let the market work by raising the price of a scarce resource! Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 02:14:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21292; Tue, 5 Sep 1995 02:14:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA06594; Tue, 5 Sep 1995 02:14:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA06492; Tue, 5 Sep 1995 01:54:55 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20693; Tue, 5 Sep 1995 01:54:49 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id LAA01085; Mon, 4 Sep 1995 11:54:20 -0400 Date: Mon, 4 Sep 1995 11:54:19 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Tony Li Cc: George Herbert , big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: <199509041040.DAA23871@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Tony Li wrote: > The original question is whether multihoming was a significant problem > for CIDR. I think that we've shown pretty definitively that it's not. > > Tony But is CIDR a significant problem for Multihoming? Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 02:16:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21399; Tue, 5 Sep 1995 02:16:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA06616; Tue, 5 Sep 1995 02:15:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA06508; Tue, 5 Sep 1995 01:55:18 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20699; Tue, 5 Sep 1995 01:55:10 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id LAA01065; Mon, 4 Sep 1995 11:52:10 -0400 Date: Mon, 4 Sep 1995 11:52:09 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: "Robert A. Rosenberg" Cc: George Herbert , big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Robert A. Rosenberg wrote: > > Backbones & direct connect to interchange points: 15 > > Multihomed: 8 > > Cix-only (?): 5 > > Single homed: 105 > > Thank you for the table. This means that of those ~140 only ~20-30 actually > show up in the Routing Tables (I count the 15 as having their own CIDR > Blocks and assume that the Multi-Homed use two or more transit providers). > All others are leaves off someone-else's CIDR block and thus do not > get/need Global Routing as a unique Network. > But they will in the future unless reliability improves dramatically. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 02:17:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21431; Tue, 5 Sep 1995 02:17:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA06642; Tue, 5 Sep 1995 02:17:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA06516; Tue, 5 Sep 1995 01:56:33 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20744; Tue, 5 Sep 1995 01:56:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23953; Mon, 4 Sep 95 11:56:27 -0400 Date: Mon, 4 Sep 95 11:56:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041556.AA23953@ginger.lcs.mit.edu> To: asp@uunet.uu.net, mn@ios.com Subject: Re: Routing tables & what to do about them Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Michael F. Nittmann" For bigger entities, e.g. small ISPs ... I would say, renumber by putting for this a NAT at a strategical aggregation point in the network. Good point, we keep forgetting this solution. NAT's aren't without their problems, but if the costs of renumbering are too high, perhaps the costs of NAT's will be acceptable. Actually, the way to do this, probably, is *behind* part of the ISP. That way, customers who want to renumebr and get out from behind the NAT box can. This 'leasing' thing of the addresses is the point: it is too strict and really is contra free enterprise. I'm getting really, really, sick of this "free enterprise" mantra. I happen to be to the right of Ghengis Khan when it comes to free markets (e.g. my constant liking for charging for routing), so it's not ideology that makes me irritable. Reality just has aspects that we just have to live with, aspects that have nothing to do with monopolies, anti-free-entrprise, or any of that stuff. For instance, if you decide to equip your organization with Mac's, get everyone trained, etc, it will be a non-zero-cost decision to switch to PC's. This is the result of some giant conspiracy to prevent competition? If you have a particular point to make, make it, but please spare me the political rhetoric. They could not survive if they would have to release their addresses the moment they stop service with some other provider I'm not aware anyone (or at least, any large number of people) is advocating this. We keep talking about transition periods, lack of flag days, etc, etc. Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 02:19:36 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21487; Tue, 5 Sep 1995 02:19:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA06664; Tue, 5 Sep 1995 02:19:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA06590; Tue, 5 Sep 1995 02:12:29 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21098; Tue, 5 Sep 1995 02:12:06 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id MAA01747; Mon, 4 Sep 1995 12:14:11 -0400 Date: Mon, 4 Sep 1995 12:14:10 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Multihoming To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9509041547.AA23937@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Noel Chiappa wrote: > From: "Michael F. Nittmann" > > >>> if Barney is multi-homed to Sprint and MCI, and gets address space from > >>> Sprint, then Sprint and MCI both need to carry Barney's routes > > >> And when the Spring link is down, no-one on Alternet knows of the > >> MCI link, and the sites multi-homing is close to useless. > > > No. ... the above description *does* provide continued connectivity. It > > merely requires that Sprint be willing to accept routes from MCI about > > Barney. > > when I see those Sprint things: Barney would need a prefix of 18 or less > > We were talking about multihomed ISP's, right? Are there a lot of ISP's with > a, say, /24? no, but startups don't get 18. they are lucky if they get some 20 at first, then some 19. But if they want to offer acceptable service by being truly multihomed and not down if their uplink is down, they need to be multihomed right away. If they do it right, the number of customers is bigger than the 24s they have, since 1 or two host webonauts should not get 24s, right? Now, the published policy just of Sprint is to not route anything longer than 18. How do those 20s and 19s fit in, especially later when the provider gets 18 or 16, but still has the old 20s and 19s. No, reservation is not granted in most of the cases. > > It is this kind of attitude that creates Barney's problem. Not CIDR or > routers or anything else. > the attitude of putting out an arbritary limitation which does not seem to be adapted to the real world, instead of accomodating to real needs. Sorry if you need this in such a detail. Mike > I am unable to parse this piece of political rhetoric. Could you provide > details on exactly what technical problem Barney theoretically has in this > scenario? > > Noel > > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 02:34:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22026; Tue, 5 Sep 1995 02:34:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA06717; Tue, 5 Sep 1995 02:34:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA06711; Tue, 5 Sep 1995 02:30:23 +1000 Received: from poblano.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21927; Tue, 5 Sep 1995 02:30:16 +1000 (from jcurran@bbnplanet.com) Received: from jcurran-ppp.near.net by poblano.bbnplanet.com id aa10502; 4 Sep 95 12:28 EDT X-Sender: jcurran@198.114.157.116 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Sep 1995 12:29:17 -0400 To: Sanjay Kapur From: John Curran Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk At 12:45 PM 9/3/95, Sanjay Kapur wrote: >There is no consumer protection system built into the Internet except the >free market and forcing renumbering curtails that free market. Hmm. Interesting perspective. Sanjay, would you object to a totally free market system in which the customer could choose any option they like, but they have to pay the burdened costs thereof? I'm certain that the cost economics of a single dialup user are different than those of a small ISP, and clearly they would then be able to decide for their own circumstances whether renumbering when changing providers made sense. Of course, one side effect of this approach is that we have to calculate the net cost of 1 additional route with a metro scope, national scope, and world-wide scope. Given that the entire network infrastructure today is serving 30K prefixes and the diseconomies of scale that come from having to quickly switch packets across larger routing tables, it's not inconceivable that the global announcement of 1 prefix could cost thousands of dollars on an annual basis. (Remember that an address prefix greatly displaced from its "natural" topological connection point results in costs for almost every multiply-connected network router, including the smallest dual-homed ISP who is actively using both paths). Currently, this routing is provided "for free" along with Internet service; this would have to change to an additional routing fee model with the fee based on the scope and number of prefixes desired. One natural side effect of this "pure market model" is that it almost guarantees that most folk seek CIDR-compliant prefixes so as to minimize their "scope charge". A small ISP which changes backbone providers either absorbs these new routing charges on behalf of its customers or passes them downstream. The more dramatic the change in topology (i.e. within a metro area, within the same state, etc.), the larger the resulting routing charges. We can setup a system which runs purely on free market economics; I'm just not sure it's what you (or anyone else) really wants... /John From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 02:35:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22173; Tue, 5 Sep 1995 02:35:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA06739; Tue, 5 Sep 1995 02:35:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA06684; Tue, 5 Sep 1995 02:22:53 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21531; Tue, 5 Sep 1995 02:22:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24013; Mon, 4 Sep 95 12:22:47 -0400 Date: Mon, 4 Sep 95 12:22:47 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041622.AA24013@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Charging for routes... Cc: jnc@ginger.lcs.mit.edu Precedence: bulk Speaking of charging for routes, and my dedication to free enterprise, I've just figured out a possible solution to the problem that KRE raised; how do the providers figure out how to charge enough to stop the growth of the routing table? Simple: they create a free market in routing table slots. This has the wonderful side benefit of getting them totally out of fights as to which routes they will and will not handle; the market decides for them. Here's how it works. Large provider X figures out (by looking at their deployed hardware, deployment plans, etc) that for the next N months, they can handle up to M routes. They announce resellable leases on routing table slots, good for N months. They have a number of options here. They could set a price that gets them enough money, and open the gates, first come, first served (or maybe prior holder get first dibs). Or, they could do a "treasury auction", and take bids, and sell slots from the top price down, until they are all gone. Most slots will not be sold individually; other providers will buy blocks of them to get *their* routes carried inside provider X. Now, let's see what happens next. Suppose there are more slots needed than the supply. Prices will rapidly shoot up on the secondary, open market on routing table slots for provider X. This will create pressure on people to sell any extra slots they don't need; if they can reduce their need for routing table slots, they can sell some of their on the open market for more than they paid for them. On the other hand, someone who needs lots of routes because they are doing something silly is going to pay through the nose. Some people simply will not be able to afford routes, and will have to renumber to get connectivity. What is to stop X from providing too few routes to jack up the auction price, or from holding some back, jacking up the market price, and feeding out reserved slots? Someone can indeed manipulate the market like this, but only in the short term. In the long term, the high cost of their "product", routing table slots, will put them at a competitive disadvantage ("get access to my customer base at less $$$"). Customers connected to them will discover that there are parts of the Internet they cannot get to (due to other providers who couldn't afford their provider's routing table slots), and customers will leave for other providers. Notice how this has nice side-effects. The more providers your routing advertisment needs to go over, (i.e. the larger the AAB for it), the more it will cost. This is incentive to renumber in a way which allows you to use a smaller AAB. There are some interesting twinges, particularly with the "treasury auction" model, where the incentive is to maximize the product of number_of_ slots_sold * price_per_slot (your total take), so provider is better off selling less slots at higher money. This is not necessarily bad; it will tend to exert pressure on the routing tables to keep them nice and small... Make it too small, of course, and traffic starts to take non-optimal routes, which means the providers will have to pay out more for transmission capacity to handle the non-optimally routed traffic. So, there's back-pressure there to keep it all even. The one thing we *cannot* do is *not* charge for routing entries. As we have all seen, whenever a finite common resource is not allocated by a free market, as in fishing grounds, one of two things happens: i) it gets fished out (current Internet), or ii) the government steps in to regulate it (usually when it's too late), and we all knwo how good governments are at regulating things... Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 02:54:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22707; Tue, 5 Sep 1995 02:54:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA06794; Tue, 5 Sep 1995 02:54:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA06784; Tue, 5 Sep 1995 02:41:27 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22358; Tue, 5 Sep 1995 02:41:21 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id MAA01282; Mon, 4 Sep 1995 12:40:48 -0400 Date: Mon, 4 Sep 1995 12:40:48 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, nectar@communique.net, jnc@ginger.lcs.mit.edu Subject: Re: Multihoming and CIDR In-Reply-To: <9509041241.AA23630@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Noel Chiappa wrote: > > Opimal routing in large networks, with portable addresses, is just never going > to be an O(1), or even an O(logN), problem. Unless router design is radically changed. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 02:55:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22824; Tue, 5 Sep 1995 02:55:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA06828; Tue, 5 Sep 1995 02:55:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA06765; Tue, 5 Sep 1995 02:39:42 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22275; Tue, 5 Sep 1995 02:39:29 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id MAA01263; Mon, 4 Sep 1995 12:39:06 -0400 Date: Mon, 4 Sep 1995 12:39:05 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: gherbert@crl.com, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: <9509041213.AA23596@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Noel Chiappa wrote: > It should be instantly obvious that if *lots* of people move, multi-home > globally, etc, that assumption would not be met, since the growth of the > routing table would not be "reasonably small". That's the problem with > statements like the only you're relying on: I do not expect *lots* of people to move at all. In fact if the freedom to move remains, transit providers will most likely offer better service which will reduce the desire to move. I am not against the concept of CIDR as such or as originally envisioned. I am just against any blanket prohibition to take your IP block with you. > > this plan neither requires nor assumes that already assigned addresses > will be reassigned ... Note that this plan does not require domains to > renumber if they change their attached transit routing domain. > > People take them like they are some sort of ironclad guarantee without any > limits, and rely on them in ways in which it was never intended they be relied > on. If you read the original IP number documents, it was stated in a manner like that. It even encouraged entities not currently connected to apply for an IP number in case they ever got connected. The problem is that the "ironclad guarantee" was actually given, many people relied on it, and now it seems that some people want to repudiate that guarantee by stating that it was never given. Naturally if your livelihood and your business depends on it, you will be very upset. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 02:58:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22944; Tue, 5 Sep 1995 02:58:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA06852; Tue, 5 Sep 1995 02:56:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA06781; Tue, 5 Sep 1995 02:40:27 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22335; Tue, 5 Sep 1995 02:40:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24041; Mon, 4 Sep 95 12:40:18 -0400 Date: Mon, 4 Sep 95 12:40:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041640.AA24041@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, mn@ios.com Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk From: "Michael F. Nittmann" startups don't get 18. they are lucky if they get some 20 at first, then some 19. But if they want to offer acceptable service by being truly multihomed and not down if their uplink is down, they need to be multihomed right away. I'm not convinced that they cannot get good levels of service by multiple links to a single provider (if you're provider is that incompetent, you'd better get someone better), but let's move on. Now, the published policy just of Sprint is to not route anything longer than 18. Is this for their customers, or for routes coming in from other providers? Presumbly the do route to things smaller than an /18 that are numbered out of their provider block, no? If not, how does the routign inside Sprint work? :-) I think that Sprint is trying to avoid routing the entire Internet "flat", so perhaps the following would be acceptable. Perhaps if they had "secondary-provider" agreements with another provider, those two providers would agree to carry routes for people who are multihomed to both providers. They wouldn't have to export anything smalle than an /18 outside the pair of them, but would carry smaller ones inside (although I doubt they'd carry 10 zillion /28's, multihomed..), presumably at some extra cost. >> It is this kind of attitude that creates Barney's problem. Not CIDR or >> routers or anything else. > I am unable to parse this piece of political rhetoric. Could you provide > details on exactly what technical problem Barney theoretically has in > this scenario? the attitude of putting out an arbritary limitation which does not seem to be adapted to the real world, instead of accomodating to real needs. Sorry if you need this in such a detail. Let's see. Is the arbitrary restriction of building generators which need fuel "an arbitrary limitation which does not seem to be adapted to the real world?" I mean, it's "[not] accomodating [the] real need" to have large amounts of electric power for free... You have not provided a description of a technical problem. It's a political rant with zero useful content. If you have a technical comment/question to make, please do so. Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 03:16:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23334; Tue, 5 Sep 1995 03:16:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA06896; Tue, 5 Sep 1995 03:14:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA06808; Tue, 5 Sep 1995 02:54:37 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22717; Tue, 5 Sep 1995 02:54:30 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id MAA01302; Mon, 4 Sep 1995 12:42:58 -0400 Date: Mon, 4 Sep 1995 12:42:57 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Scott Bradner Cc: dcrocker@brandenburg.com, huitema@pax.inria.fr, big-internet@munnari.OZ.AU, iap@vma.cc.nd.edu, inet-access@earth.com Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: <199509041313.JAA06835@newdev.harvard.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > > After all, one entry per ISP is a lot better than one entry per user. > > As long as its a large enough ISP to have a "short" routing prefix. > > There is some (fuzzy & changing) threshold as to the minimum sized ISP > that should be considered "big enough" to fit this rule. > > Scott > This fuzziness upsets me quite a bit. Internet standards are generally known for their clarity and are normally not this fuzzy. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 03:18:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23501; Tue, 5 Sep 1995 03:18:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA06916; Tue, 5 Sep 1995 03:16:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA06872; Tue, 5 Sep 1995 03:04:41 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23039; Tue, 5 Sep 1995 03:04:36 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24098; Mon, 4 Sep 95 13:04:31 -0400 Date: Mon, 4 Sep 95 13:04:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041704.AA24098@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Subject: Re: Multihoming and CIDR Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Sanjay Kapur > Opimal routing in large networks, with portable addresses, is just never > going to be an O(1), or even an O(logN), problem. Unless router design is radically changed. You don't seem to be getting the message. Sorting N integers can been shown to be an O(NlogN) problem on a sequential machine. Likewise, routing is at least an O(N) problem, where N is the number of entries in the routing table. It has nothign to do with router design. Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 03:20:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23533; Tue, 5 Sep 1995 03:20:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA06940; Tue, 5 Sep 1995 03:18:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA06886; Tue, 5 Sep 1995 03:10:26 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23168; Tue, 5 Sep 1995 03:08:08 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id NAA01405; Mon, 4 Sep 1995 13:03:28 -0400 Date: Mon, 4 Sep 1995 13:03:28 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Dorian Rysling Kim Cc: "Michael F. Nittmann" , Andrew Partan , big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Dorian Rysling Kim wrote: > Internet. Given the fact that there are no good tools to renumber is, any > plan that requires a flg day renumbering is unworkable. However, given a > reasonable transition period, something even as massive as renumbering 68 > class Cs is doable. Not painless, but doable, and I'm speaking from > operational experience. > > Renumbering with a reasonable transition period, IMO, will help slow down > the growth of the routing table, and be feasible. And if we let those > sites that absolutes CANNOT renumber be, but still renumber those that > can, this is still a win. > > -dorian The above is an example of why this issue is not a purely technical issue but one that involves deciding who should bear the burden or the cost of renumbering. Should it be at the routers or the individual sites forced to renumber? Should the network companies be required to upgrade their hardware or should the cost be effectively transferred to the consumer? Should the whole network pay for the cost or the entity that wants to move? Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 03:34:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24090; Tue, 5 Sep 1995 03:34:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA06991; Tue, 5 Sep 1995 03:34:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA06968; Tue, 5 Sep 1995 03:24:59 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23651; Tue, 5 Sep 1995 03:24:55 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id NAA07793; Mon, 4 Sep 1995 13:24:48 -0400 (EDT) Date: Mon, 4 Sep 1995 13:24:48 -0400 (EDT) From: Scott Bradner Message-Id: <199509041724.NAA07793@newdev.harvard.edu> To: root@kbs.netusa.net, sob@newdev.harvard.edu Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU, dcrocker@brandenburg.com, huitema@pax.inria.fr, iap@vma.cc.nd.edu, inet-access@earth.com Precedence: bulk > This fuzziness upsets me quite a bit. please propose clarity Scott From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 03:35:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24124; Tue, 5 Sep 1995 03:35:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA07013; Tue, 5 Sep 1995 03:35:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA06965; Tue, 5 Sep 1995 03:24:03 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23631; Tue, 5 Sep 1995 03:23:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24275; Mon, 4 Sep 95 13:23:56 -0400 Date: Mon, 4 Sep 95 13:23:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041723.AA24275@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, root@kbs.netusa.net Subject: Re: casting your multi-homing/provider-changing vote Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur This fuzziness upsets me quite a bit. Internet standards are generally known for their clarity and are normally not this fuzzy. Where does it say, in the TCP spec, what performance you can expect from a TCP running on a current Sun, over an Ethernet? It *doesn't* say? How fuzzy of it. I mean, this is an important number to real-world user, even if we academics don't care about it. Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 03:37:06 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24164; Tue, 5 Sep 1995 03:37:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA07035; Tue, 5 Sep 1995 03:36:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA06982; Tue, 5 Sep 1995 03:25:11 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23655; Tue, 5 Sep 1995 03:25:00 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id NAA01461; Mon, 4 Sep 1995 13:18:58 -0400 Date: Mon, 4 Sep 1995 13:18:57 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: John Curran Cc: Andrew Partan , big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, John Curran wrote: > Excellent note. It probably won't reduce the email which is effectively > advocating global geometric routing growth, but it puts such mail nicely > in perspective. > > /John > > === If transit providers are confident in their ability to provide good service, they also should be confident in their ability to keep customers. If they keep customers, there will be no need to renumber and dire predictions of global geometric routing growth causing the heat death of the Internet will not come to pass. There is a false assumption in this debate that freedom to move will cause a lot of movement. Movement is caused by other factors and these factors are always weighed against the cost of the move. The problems occur when a networking provider stops giving good service. Customers at that point should be free to leave AND TAKE THEIR NUMBERS WITH THEM. I say "Live free or die" to those proposing monopolies as a way to keep the Internet alive. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 03:39:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24283; Tue, 5 Sep 1995 03:39:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA07058; Tue, 5 Sep 1995 03:38:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA06985; Tue, 5 Sep 1995 03:33:15 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24051; Tue, 5 Sep 1995 03:33:12 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24326; Mon, 4 Sep 95 13:33:09 -0400 Date: Mon, 4 Sep 95 13:33:09 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041733.AA24326@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Subject: RE: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Sanjay Kapur > users have a choice of: > > i) a functional network, > *or* > ii) the freedom to switch between providers without changing addresses > > ... Also, you didn't formulate option ii) the way I put it ... Your > definition of "freely" includes "take my routing-name with me", which is > where we part paths. That, I am sorry, is just not technically possible. Technical feasibility is tied to router design. I guess router designers will be unable to come up with a better and less limiting design quickly enough. Routing-names have to be aggregable for the overhead of routing to scale reasonably; if they are aggregable, that means they have to be topologically sensitive, i.e. they have to change when you move to a different location in the network. If you don't like that characteristic of routign-names, then you have to provide *another* namespace which doesn't have this characteristic, and map them into routing-names. The IETF had the chance, some years ago, to start down this road, and map IPv4 addresses into routing-names. It decided not to, with the result that IPv4 addresses are still routing-names. Now we have to deal with the consequences of that decision. We don't have to option of not dealing with it, we only get to decide how. (I'd use a *very* crude simile, but it's extremely non-PC.) Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 03:41:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24337; Tue, 5 Sep 1995 03:41:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA07080; Tue, 5 Sep 1995 03:39:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA06960; Tue, 5 Sep 1995 03:22:17 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB23559; Tue, 5 Sep 1995 03:22:09 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24256; Mon, 4 Sep 95 13:21:57 -0400 Date: Mon, 4 Sep 95 13:21:57 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041721.AA24256@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: casting your multi-homing/provider-changing vote Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur I am not against the concept of CIDR as such ... I am just against any blanket prohibition to take your IP block with you. OK, I'll bite. If everyone is allowed to take their block with them, then: If everyone decides to *actually* do what they are *allowed* to do, and doing that kills the routing, then how do you decide who gets to exercise that privilege, and who doesn't? Everyone is seeing this capabiltiy of taking an address with you as a right, and I think that's the wrong model, since if everyone does it, the routing will fall over. So, it's not a right, it's a privilege. So, if it's a privilege, how do you decide who gets lucky? If you read the original IP number documents, it was stated in a manner like that. It even encouraged entities not currently connected to apply for an IP number in case they ever got connected. The people who did that didn't understand that they were writing something bogus. (Well, to be fair to them; it was true, for a network of the size we had when they wrote it. We have a much bigger net now, and things have changed. You don't expect personal sales support from Bill Gates anymore, either...) Take it up with them, not me. Please tar and feather them (or worse), I don't care. I can write an offical document that says that I'll sell you a perpetual motion machine for $10, but that doesn't mean I can follow through with it. The problem is that the "ironclad guarantee" was actually given, many people relied on it, and now it seems that some people want to repudiate that guarantee by stating that it was never given. I don't care if it was given or not. That is irrelevant to what we have to do, which is keep the Internet running. To do that, we have to look at what is *feasible*, not what somebody who didn't understand what they were saying promised. A guarantee to sell a perpetual motion machine is worthless. It's not necessary to repudiate it; anyone who continues to rely on such a guarantee after it has been pointed out to them that it is worthless is doing nothing except burying their head in the sand, to their own detriment. Naturally if your livelihood and your business depends on it, you will be very upset. I can sympathize with your being upset. I can't sympathize with your inability to realize that complaining about how unfair it is isn't going to change the trap we're caught in. The only thing that will do any good is figuring out what exits, if any, exist, and how to take them. Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 03:54:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24738; Tue, 5 Sep 1995 03:54:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA07131; Tue, 5 Sep 1995 03:54:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA07125; Tue, 5 Sep 1995 03:53:15 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24715; Tue, 5 Sep 1995 03:53:11 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id NAA07930; Mon, 4 Sep 1995 13:53:05 -0400 (EDT) Date: Mon, 4 Sep 1995 13:53:05 -0400 (EDT) From: Scott Bradner Message-Id: <199509041753.NAA07930@newdev.harvard.edu> To: jcurran@bbnplanet.com, root@kbs.netusa.net Subject: Re: Routing tables & what to do about them Cc: asp@uunet.uu.net, big-internet@munnari.OZ.AU Precedence: bulk > I say "Live free or die" to those proposing monopolies as a way to keep > the Internet alive. humm, seems to be a bit of a drastic set of alternatives (ignoring the "proposing monopolies" overstatement part of your cry) so - your answer to the often stated request for a specific suggestions to avoid the requirement to push the usage of addresses that reflect network topology is "die"? Scott From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 03:55:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24808; Tue, 5 Sep 1995 03:55:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA07164; Tue, 5 Sep 1995 03:55:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA07037; Tue, 5 Sep 1995 03:36:49 +1000 Received: from clyde.bdt.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24153; Tue, 5 Sep 1995 03:36:45 +1000 (from david@bdt.com) Received: by clyde.bdt.com (/\oo/\ Smail3.1.29.1 #29.4) id ; Mon, 4 Sep 95 10:40 PDT Message-Id: From: david@bdt.com (David Beckemeyer) Subject: Re: Multihoming To: hal9001@panix.com (Robert A. Rosenberg) Date: Mon, 4 Sep 1995 10:40:45 -0700 (PDT) Cc: big-internet@munnari.OZ.AU Reply-To: david@bdt.com In-Reply-To: from "Robert A. Rosenberg" at Sep 4, 95 04:35:05 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 1106 Precedence: bulk Robert A. Rosenberg wrote: > Thank you for the table. This means that of those ~140 only ~20-30 actually > show up in the Routing Tables (I count the 15 as having their own CIDR > Blocks and assume that the Multi-Homed use two or more transit providers). > All others are leaves off someone-else's CIDR block and thus do not > get/need Global Routing as a unique Network. If you're saying everything is okay because only 20-30 show up in the routing tables now, I have to disagree because I suspect many of those ~140 are the problem in that many of them may need to be be multi-homed in the future and at that point they will have too many customers to tell them all to just renumber. And they also are "locked" into their current provider for the same reason. Isn't that part of the issue, that we want a solution that doesn't lock providers into their upstream provider, leaving them no options? -- David Beckemeyer (david@bdt.com) | Engineering/Connectivity Services Beckemeyer Development | Info: info@bdt.com P.O. Box 21575, Oakland, CA 94620 | WWW: From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 03:57:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24831; Tue, 5 Sep 1995 03:57:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA07188; Tue, 5 Sep 1995 03:57:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA07093; Tue, 5 Sep 1995 03:40:59 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24312; Tue, 5 Sep 1995 03:40:15 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id NAA01545; Mon, 4 Sep 1995 13:37:23 -0400 Date: Mon, 4 Sep 1995 13:37:22 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Stan Barber Cc: Simon Spero , Andrew Molitor , big-internet@munnari.OZ.AU Subject: Re: The Conspiracy - In-Reply-To: <199509041549.KAA03016@academ.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Stan Barber wrote: > > Capitalism and monopolies can not live together. > > > > Sanjay Kapur > > Kapur Business Systems, Inc. > > Sanjay, this is just not a true statement. > > There are plenty of existance proofs that show this to be wrong. Electric > companies are just one example that come to mind. There are a number of > monopolies that exist in this capitalist society. You may argue that > ideally this is the case, but this is not an ideal world. I am not an > economist so I will not debate the ideal. Take the example of the electric company. The existence of one company prevents another from entering the same market and in that particular market, free trade does not exist and so capitalism in that market also does not exist because no amount of capital will help you get into the market (short of buying out the already existing electric company). Capitalism == Free trade Monopoly == Restraint of trade I should have stated that Capitalism and monopolies can not exist together in a market. Almost all the monopolies that exist in a capitalist society are highly regulated. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 04:00:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24998; Tue, 5 Sep 1995 04:00:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA07214; Tue, 5 Sep 1995 03:59:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA07122; Tue, 5 Sep 1995 03:51:42 +1000 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24692; Tue, 5 Sep 1995 03:51:38 +1000 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id NAA23814; Mon, 4 Sep 1995 13:41:08 -0400 From: Avi Freedman Message-Id: <199509041741.NAA23814@netaxs.com> Subject: Re: Charging for routes... To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 4 Sep 1995 13:41:07 -0400 (EDT) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9509041622.AA24013@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 4, 95 12:22:47 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1350 Precedence: bulk > The one thing we *cannot* do is *not* charge for routing entries. As > we have all seen, whenever a finite common resource is not allocated by a free > market, as in fishing grounds, one of two things happens: i) it gets fished > out (current Internet), or ii) the government steps in to regulate it (usually > when it's too late), and we all knwo how good governments are at regulating > things... > > Noel One issue: As with traditional settlement talks, all it takes is one large player to not go along with the thing and it falls apart. And I think that there are some solutions which do not involve using routers as route computers, but instead using more general-purpose workstation-based solutions as route computers, and using routers as boxes with lots of interfaces, which are fed precomputed routing tables, which might solve the problem, even in the long-term. [The solution would be able to provide route computers that grow in capacity as fast or faster than the routing situation.] The question is: Will anyone do serious work on a solution like that in time? Obviously no harm in talking about it, just thought I'd throw that in. I think that if settlements are to be accepted on *any* basis, basing them on an actually scarce basis like routes is better than basing them on the more phantom "bandwidth" concerns. Avi From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 04:35:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26215; Tue, 5 Sep 1995 04:35:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA07280; Tue, 5 Sep 1995 04:34:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA07274; Tue, 5 Sep 1995 04:26:13 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25929; Tue, 5 Sep 1995 04:26:09 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24672; Mon, 4 Sep 95 14:26:06 -0400 Date: Mon, 4 Sep 95 14:26:06 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041826.AA24672@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, tli@cisco.com Subject: Re: Multihoming Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Tony Li The downside is the coordination of the AAB. You can say that again. I've been musing about this issue of optimal AAB's, and it seems like they are related to the graph's topology the same way ANB's are. (Surprise, surprise...) Of course, the fly in all this ointment is that when you have a link failure, you've just *ta-da* changed the topology. So, really, optimal AAB's/ANB's are in practise a much more complex topic, as you have to think about how well they work after one or more topology failures (as Scott Ballew pointed out). Talk about the optimization problem to end all optimization problems... The bottom line seems to be that if you run the routing in the hairy edge of absolute minimum overhead for really good routes, then when you get a topology change, you can really fall off the cliff. If you accept a higher over-head approach, or one that produces less-optimal routes, it's easier able to withstand topology changes. In other words, you trade off betwen extra cost in the normal case for better response to unplanned events. (Similar to an airline, and extra planes.) Anyway, to get back to optimal AAB's, and topology changes, one obvious reponse is to start thinking about to change them dynamically as needed, either to a preconfigured fallback, or (in my wildet dreams) by some dynamic algorithm which can solve the simpler version of that optimization problem. Then you get into even deeper water... Noel PS: I'll bet K+K's results don't hold if there are topology changes, either... From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 04:54:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26788; Tue, 5 Sep 1995 04:54:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA07320; Tue, 5 Sep 1995 04:54:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA07311; Tue, 5 Sep 1995 04:40:29 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26296; Tue, 5 Sep 1995 04:40:22 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24747; Mon, 4 Sep 95 14:40:15 -0400 Date: Mon, 4 Sep 95 14:40:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041840.AA24747@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mn@ios.com Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "Michael F. Nittmann" do route name tagging in the router, so that wherever I plug the router in, I tag the route name with a geographical tag and voila, we have full aggregation. I was unable to follow for sure that brief description. I'll go with what I can glean, and if I went wrong, perhaps you can elaborate on your scheme. If you have two routes to otherwise dissimilar addresses, A and B, which have the same geographic tag G, how do you aggregate those two routes? In other words, at some distant router, which no longer has A or B in its routing table, how does it tell that A is at G? Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 04:55:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26796; Tue, 5 Sep 1995 04:55:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA07341; Tue, 5 Sep 1995 04:55:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA07314; Tue, 5 Sep 1995 04:51:39 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26577; Tue, 5 Sep 1995 04:51:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24819; Mon, 4 Sep 95 14:51:35 -0400 Date: Mon, 4 Sep 95 14:51:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509041851.AA24819@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mn@ios.com Subject: Re: Multihoming Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "Michael F. Nittmann" routers are to transport traffic, not to calculate graphs. Engines are to burn fuel, not to calculate thermodynamics. So? Routers (or, more properly, all devices that calculate routes) can no more ignore graph theory than engines can ignore thermo. I have the little impression it is a vendor here who wants to affirm all routers suffer the same drawbacks. Ah, yes, the old conspiracy theory. Gee, Cisco, where's my bribe for all this talk about how mathematics puts inherent limits on routing algorithms? (What, mathematics limits the behaviour of algorithms? I'm shocked, shocked, to find gambling going on in a casino.) This discussion should really focus on the future addressing I couldn't agree with you more. not how we can accomodate one vendor's boxes. Basically, yes. However, to the extent that we have to be realistic, and not ivory-tower academics who are out of touch with the real world, we do have to consider installed base, don't we? Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 05:35:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28014; Tue, 5 Sep 1995 05:35:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA07421; Tue, 5 Sep 1995 05:34:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA07393; Tue, 5 Sep 1995 05:19:08 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27525; Tue, 5 Sep 1995 05:19:03 +1000 (from gherbert@crl.com) Received: from crl12.crl.com by mail.crl.com with SMTP id AA02817 (5.65c/IDA-1.5); Mon, 4 Sep 1995 11:15:09 -0700 Message-Id: <199509041815.AA02817@mail.crl.com> To: Sanjay Kapur Cc: Tony Li , George Herbert , big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Multihoming In-Reply-To: Your message of "Mon, 04 Sep 1995 11:54:19 EDT." Date: Mon, 04 Sep 1995 11:15:08 -0700 From: George Herbert Precedence: bulk No. Announcement policies might potentially be a problem for Multihoming, but CIDR proper is not. -george From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 05:36:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28171; Tue, 5 Sep 1995 05:36:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA07441; Tue, 5 Sep 1995 05:35:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA07400; Tue, 5 Sep 1995 05:23:18 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27676; Tue, 5 Sep 1995 05:23:11 +1000 (from gherbert@crl.com) Received: from crl12.crl.com by mail.crl.com with SMTP id AA03994 (5.65c/IDA-1.5); Mon, 4 Sep 1995 11:25:15 -0700 Message-Id: <199509041825.AA03994@mail.crl.com> To: "Michael F. Nittmann" Cc: big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Multihoming In-Reply-To: Your message of "Mon, 04 Sep 1995 12:14:10 EDT." Date: Mon, 04 Sep 1995 11:25:14 -0700 From: George Herbert Precedence: bulk Michael writes: >no, but startups don't get 18. they are lucky if they get some 20 at >first, then some 19. But if they want to offer acceptable service by >being truly multihomed and not down if their uplink is down, they need to >be multihomed right away. >If they do it right, the number of customers is bigger than the 24s they >have, since 1 or two host webonauts should not get 24s, right? >Now, the published policy just of Sprint is to not route anything longer >than 18. How do those 20s and 19s fit in, especially later when the >provider gets 18 or 16, but still has the old 20s and 19s. No, >reservation is not granted in most of the cases. Well, the obvious solution is to insist that backbone ISPs and the NIC, when allocating CIDR blocks for small ISPs, make allowances to grow to /18 via a reservation system. The end user can make this happen today (small ISPs have gotten such growth space commitments) but it is not the default behaviour of the ISPs and NIC. That should be changed by gentle social engineering. If people refuse to allow reservations, then we have a serious problem, but from what I've heard nobody had any problems with doing so once they asked with enough detail and force. The obvious solution to Sprint's policy is that smaller providers shouldn't use Sprint for their second link to go dual-homed, if they are smaller than a /18... -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 05:37:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28210; Tue, 5 Sep 1995 05:37:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA07463; Tue, 5 Sep 1995 05:37:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA07415; Tue, 5 Sep 1995 05:30:52 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27921; Tue, 5 Sep 1995 05:30:47 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id MAA28507; Mon, 4 Sep 1995 12:30:32 -0700 From: Dave Siegel Message-Id: <199509041930.MAA28507@seagull.rtd.com> Subject: Re: Multihoming To: dorian@CIC.Net (Dorian Rysling Kim) Date: Mon, 4 Sep 1995 12:30:31 -0700 (MST) Cc: gherbert@crl.com, hal9001@panix.com, big-internet@munnari.OZ.AU In-Reply-To: from "Dorian Rysling Kim" at Sep 4, 95 09:36:22 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1500 Precedence: bulk > > The danger in that assumption is that I personally know of 4 of those smaller > > ISPs which are going to dual-home shortly. That's out of 6 that I talk to > > regularly... > > This is a general query, but.. how many of these small ISPs who want to > dual home know 1) how to run BGP, and 2) how to manage dual homed routing? > Esp. in the case when they have their own CIDR blocks? We have a customer > who is going to, but it seems they don't have a clue as to above... a > pretty worrisome situation... > > Is this common or are we just unlucky? It's common. Fortunately, training them on how it all works isn't *too* incredibly time consuming. Usually, I ended up taking turns with Vadim beating up on the customer until he got his filter lists correct, and we got all his questions answered. ;-) I use Sprintlink as an example, because customers of net99's that dual-homed with other NSP's usually didn't get a particularly high level of attention from their staff. ...not intended as a knock, Vadim was just gracious enough to offer his services. There were plenty of times when I didn't feel like helping either, due to time restrictions and other projects. The nice thing is, once you've trained them on it, you can almost forget about it. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 05:39:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28259; Tue, 5 Sep 1995 05:39:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA07487; Tue, 5 Sep 1995 05:38:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA07397; Tue, 5 Sep 1995 05:21:37 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27615; Tue, 5 Sep 1995 05:21:34 +1000 (from gherbert@crl.com) Received: from crl12.crl.com by mail.crl.com with SMTP id AA02662 (5.65c/IDA-1.5); Mon, 4 Sep 1995 11:14:13 -0700 Message-Id: <199509041814.AA02662@mail.crl.com> To: Dorian Rysling Kim Cc: George Herbert , big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: Your message of "Mon, 04 Sep 1995 09:36:22 EDT." Date: Mon, 04 Sep 1995 11:14:11 -0700 From: George Herbert Precedence: bulk >This is a general query, but.. how many of these small ISPs who want to >dual home know 1) how to run BGP, and 2) how to manage dual homed routing? >Esp. in the case when they have their own CIDR blocks? We have a customer >who is going to, but it seems they don't have a clue as to above... a >pretty worrisome situation... The answer is yes and no. I've talked to them to try and make sure they have some idea of what they're getting in to, and most listened and have done things like start to follow the proper mailing lists. But there are certain aspects of running BGP which you just don't get, really, until you do it on production-grade systems. Every major ISP has, at one point, done some sort of grade-A fuckup, and all the small ones I've watched go to BGP peerage level did at least one during the setup or initial operational period... So I think they have clues, but don't expect that to mean that nothing will go wrong during the setup period. Wrt your customer, as a general rule of thumb it's far too dangerous to listen to BGP from totally clueless sites. If you do, and especially if you propogate what you hear upstream via BGP, then they can cause an amazing amount of trouble. >Is this common or are we just unlucky? It's probably not that uncommon overall. If I were in your shoes, I'd ask the customer to put off doing their own BGP until they are more technically ept, and have you and the other provider do the dual homing setup. Your mileage may vary... -george From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 05:54:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28662; Tue, 5 Sep 1995 05:54:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA07530; Tue, 5 Sep 1995 05:54:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA07521; Tue, 5 Sep 1995 05:49:55 +1000 Received: from Tetsuo.Communique.Net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28604; Tue, 5 Sep 1995 05:49:51 +1000 (from nectar@communique.net) Received: from tetsuo.communique.net (Tetsuo.Communique.Net [204.27.64.10]) by tetsuo.communique.net (8.6.12/8.6.12) with SMTP id OAA06189; Mon, 4 Sep 1995 14:49:43 -0500 Date: Mon, 4 Sep 1995 14:49:40 -0500 (CDT) From: Jacques Vidrine To: Noel Chiappa Cc: big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: <9509041049.AA23208@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Noel Chiappa wrote: [snip] > (it has suddenly > struck me that we might have to renumebr the entire Internet into a rational > addressing plan....) Ah, the Great Renumbering. Could we do this with the deployment of IPv6? Hmm, I wonder if that would even be soon enough ... I have no concept of the time table for the deployment of IPv6. I'm starting to think that it is "Not soon enough" or even "Too late to save the Internet" :-( Jacques Vidrine Communique, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 05:55:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28715; Tue, 5 Sep 1995 05:55:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA07565; Tue, 5 Sep 1995 05:55:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA07518; Tue, 5 Sep 1995 05:41:04 +1000 Received: from [204.71.127.3] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28320; Tue, 5 Sep 1995 05:40:59 +1000 (from carl@intrepid.net) Received: (from carl@localhost) by loki.intrepid.net (8.6.9/8.6.9) id PAA01219; Mon, 4 Sep 1995 15:40:50 -0400 Date: Mon, 4 Sep 1995 15:40:50 -0400 From: Carl Hillsman Subject: Re: Multihoming To: Nathan Stratton Cc: Barney Wolff , big-internet@munnari.OZ.AU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 3 Sep 1995, Nathan Stratton wrote: > On Sun, 3 Sep 1995, Barney Wolff wrote: > > > My requirements for legitimate multi-homing would include reasonable load- > > sharing when both links are up, and universal reachability, even if > > not optimal routing, when one is down. > > Ya, and right now that can not be done, We have a sprintlink T1 and > wanted to do "legitimate multi-homing" with MCI and sprint. WE had to drop > the MCI, and now we are getting a 10 meg into MAE and just using sprint > for transit. why whouldn't this work??? are your ip addresses from the nic or are they part of sprints block? or is it that mci wouldn't peer with you? carl From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 05:57:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28761; Tue, 5 Sep 1995 05:57:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA07589; Tue, 5 Sep 1995 05:57:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA07524; Tue, 5 Sep 1995 05:52:57 +1000 Received: from gatekeeper.volvo.se by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28642; Tue, 5 Sep 1995 05:52:52 +1000 (from peter@cyklop.volvo.se) Received: from localhost (mail@localhost) by gatekeeper.volvo.se (8.6.5/8.6.5) id VAA01843 for ; Mon, 4 Sep 1995 21:52:49 +0200 Received: from unknown(153.112.1.4) by gatekeeper.volvo.se via smap (V1.3) id sma001838; Mon Sep 4 21:52:29 1995 Received: from cyklop.volvo.se by nike.volvo.se with SMTP (8.6.4/1.37) id VAA13047; Mon, 4 Sep 1995 21:52:28 +0200 Message-Id: <199509041952.VAA13047@nike.volvo.se> Received: by cyklop.volvo.se (1.36.108.7/16.2) id AA18434; Mon, 4 Sep 1995 21:52:27 +0200 From: Peter Hakanson Subject: Provider based addressing vs ... To: big-internet@munnari.OZ.AU Date: Mon, 4 Sep 95 21:52:26 METDST X-Fax: +46 31 542841 Content-Type: text/plain; charset=roman8 Priority: Normal Mailer: Elm [revision: 70.30] Precedence: bulk I have followed this discussion for a while and have (in my opinion) a valid point; If carrierbased addressing might work, but is objected by a number of 'political reasons' (have to renumber when switching carrier ) Why not use geografically based addressing ? This would give the multi-geografical carriers more work, but they have the resources and can use whatever means they need. Geografical based addressing would boild down to assigning large networks to regions in the world, and applied for , lets say, sweden or scandinavia( which has fairly good internal connectivity) an A address. This was the only ipV4 address seen from any customer in scandinavia would be an 'A' address (at least if we all renumber) This would easily solve the smaller ISP problem, since they all would be part of the same address. Really this is just an extrapolation of carrier-based CIDR, just make the carrier equals a region in the world. Migrating to IPV6 would be done by assigning a proper range of addresses to the same area. Multi-national enterprices (like volvo) would have to deal with multiple network numbers internally, if we opt for multiple internet presence. But then it's our problem, not our carriers. US might be a little trickier, due to the many cross country carriers you have, but dont try to solve the US problem (which is not typical) and use that as a general solution. Instead identify US as a special case, which is not typical. Sorry for my english, but i think the meaning get there.. Thanks for the word -- Peter Hakanson VolvoData Dep 2580 phone +46 31 66 74 27 From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 06:14:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29268; Tue, 5 Sep 1995 06:14:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA07632; Tue, 5 Sep 1995 06:14:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA07613; Tue, 5 Sep 1995 06:09:38 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29224; Tue, 5 Sep 1995 06:09:34 +1000 (from gherbert@crl.com) Received: from crl12.crl.com by mail.crl.com with SMTP id AA09193 (5.65c/IDA-1.5); Mon, 4 Sep 1995 11:57:33 -0700 Message-Id: <199509041857.AA09193@mail.crl.com> To: Sanjay Kapur Cc: Noel Chiappa , gherbert@crl.com, kre@munnari.OZ.AU, big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: Your message of "Mon, 04 Sep 1995 12:39:05 EDT." Date: Mon, 04 Sep 1995 11:57:33 -0700 From: George Herbert Precedence: bulk Sanjay, I understand where you are coming from. But we have reached a point in time where continuing to use that previous "ironclad guarantee" is not going to work in the forseeable future. The alternative to some sort of controlling structure where people know what is happening and why is that large ISPs whose core routers start dying will probably start ignoring external routes at the /24 level. That cuts off the least number of end destinations and provides their customer base with the best service if they can't route *everything*. The other alternatives are chaos and regular backbone crashes. I believe it is completely unfair to the end users to move forwards into a situation which is less stable and where their routes may get dumped on the floor arbitrarily. The current process of revoking the "ironclad guarantee" as it were is the only viable alternative. A number of people have proposed alternative solutions, none of which appears to fundamentally solve the problems involved within the timescale in question. If you can actually do so, I'm sure lots of us will be cheering. I wish you good luck if you want to work on one, and if you come up with something which is viable but needs refinement I'd help refine it. But I don't at this point see any such viable alternative on the table. -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 06:53:31 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00786; Tue, 5 Sep 1995 06:53:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23210 Tue, 5 Sep 1995 06:36:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA07678; Tue, 5 Sep 1995 06:34:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA07656; Tue, 5 Sep 1995 06:18:23 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29393; Tue, 5 Sep 1995 06:18:20 +1000 (from gherbert@crl.com) Received: from crl6.crl.com by mail.crl.com with SMTP id AA12006 (5.65c/IDA-1.5); Mon, 4 Sep 1995 12:17:16 -0700 Message-Id: <199509041917.AA12006@mail.crl.com> To: Sanjay Kapur Cc: Dorian Rysling Kim , "Michael F. Nittmann" , Andrew Partan , big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Mon, 04 Sep 1995 13:03:28 EDT." Date: Mon, 04 Sep 1995 12:17:15 -0700 From: George Herbert Precedence: bulk Sanjay writes: >The above is an example of why this issue is not a purely technical issue >but one that involves deciding who should bear the burden or the cost of >renumbering. Should it be at the routers or the individual sites forced >to renumber? Should the network companies be required to upgrade their >hardware or should the cost be effectively transferred to the consumer? >Should the whole network pay for the cost or the entity that wants to move? Upgrade their hardware to WHAT, Sanjay? There is no router out there that can reliably handle twice the current table in operational conditions, based on reports from UUNet and Sprint on their Ciscos' behaviours under those loads. The 7500 will help some, maybe 50% in the near term if we are lucky. ASP indicates that we are seeing exponential routing table growth at a rate of 2x every 5 months or so; what do you plan on doing come next May when we pass what a loaded Cisco 7500 can handle? -george From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 06:53:35 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00791; Tue, 5 Sep 1995 06:53:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23221 Tue, 5 Sep 1995 06:37:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA07700; Tue, 5 Sep 1995 06:35:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA07659; Tue, 5 Sep 1995 06:22:14 +1000 Received: from Tetsuo.Communique.Net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29635; Tue, 5 Sep 1995 06:22:12 +1000 (from nectar@communique.net) Received: from tetsuo.communique.net (Tetsuo.Communique.Net [204.27.64.10]) by tetsuo.communique.net (8.6.12/8.6.12) with SMTP id PAA36616; Mon, 4 Sep 1995 15:21:33 -0500 Date: Mon, 4 Sep 1995 15:21:30 -0500 (CDT) From: Jacques Vidrine To: "Michael F. Nittmann" Cc: Andrew Partan , big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Michael F. Nittmann wrote: [snip] > Everybody agrees, only, the burden should not be placed on the customer. [snip] > I would say, renumber by putting for this a NAT at a strategical > aggregation point in the network. Everything below is renumbered. [snip] And everything below is slowed down. It seems to me that with a "NAT at a strategical aggregation point" that covers several customers, all of the customers suffer the penalties. It would be better to have the NAT as close as possible to the customers who haven't yet renumbered. Then, the customers who _have_ renumbered will not have to pay any overhead associated with NATs. The customer could provide manage it's own NAT, or the ISP could provide and manage it for the customer as value-add. Just like many ISPs handle DNS for the customer. As an aside, it seems to me that today's application level firewalls provide the technology we need for NATs. In fact, it is probably far easier for the organization with a firewall to renumber than the organization that does not use a firewall. The firewall already knows where IP addresses are used in the protocols. Of course, there are cases where the firewall cannot work out of the box. For example, let's say MIT needed to renumber. Some applications at MIT cannot be handled by a firewall, such as the experimental FOOBAR servers. The firewall simply doesn't understand the FOOBAR protocol. These types of applications would have to be handled in the traditional way (i.e. renumber by hand). That shouldn't be a problem, as there probably aren't hundreds of FOOBAR servers. Jacques Vidrine Communique, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 07:54:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB02058; Tue, 5 Sep 1995 07:54:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA07788; Tue, 5 Sep 1995 07:54:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA07782; Tue, 5 Sep 1995 07:53:15 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01940; Tue, 5 Sep 1995 07:53:11 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id OAA06868; Mon, 4 Sep 1995 14:53:07 -0700 From: Dave Siegel Message-Id: <199509042153.OAA06868@seagull.rtd.com> Subject: Re: Multihoming To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 4 Sep 1995 14:53:07 -0700 (MST) Cc: big-internet@munnari.OZ.AU, mn@ios.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9509041547.AA23937@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 4, 95 11:47:07 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1259 Precedence: bulk > when I see those Sprint things: Barney would need a prefix of 18 or less > > We were talking about multihomed ISP's, right? Are there a lot of ISP's with > a, say, /24? RTD has been an ISP since 93, when the NIC was still handing out /24's when we needed stuff for Dedicated clients. I think we've got about 10 of them, or so, plus several CIDR blocks. I'm planning on having all my clients renumber into a /18...this will, of course, take some time. > It is this kind of attitude that creates Barney's problem. Not CIDR or > routers or anything else. > > I am unable to parse this piece of political rhetoric. Could you provide > details on exactly what technical problem Barney theoretically has in this > scenario? I think he's just referring to the fact that Sprint, as well as some other large providers, are *considering* not routing any prefix greater than a /18. This is a policy which pretty much enforces renumbering at the small levels, which is where we need to most condensing to take place. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 08:14:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02622; Tue, 5 Sep 1995 08:14:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA07836; Tue, 5 Sep 1995 08:14:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA07819; Tue, 5 Sep 1995 08:09:23 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02552; Tue, 5 Sep 1995 08:09:17 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id PAA07895; Mon, 4 Sep 1995 15:08:56 -0700 From: Dave Siegel Message-Id: <199509042208.PAA07895@seagull.rtd.com> Subject: Re: Charging for routes... To: freedman@netaxs.com (Avi Freedman) Date: Mon, 4 Sep 1995 15:08:56 -0700 (MST) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <199509041741.NAA23814@netaxs.com> from "Avi Freedman" at Sep 4, 95 01:41:07 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1678 Precedence: bulk > One issue: As with traditional settlement talks, all it takes is one large > player to not go along with the thing and it falls apart. definitely. And the solution has to make some kind of sense from a marketing perspective, or it'll never sell. If it doesn't sell, an NSP won't adopt it. > And I think that there are some solutions which do not involve using routers > as route computers, but instead using more general-purpose workstation-based > solutions as route computers, and using routers as boxes with lots of > interfaces, which are fed precomputed routing tables, which might solve the > problem, even in the long-term. [The solution would be able to provide route > computers that grow in capacity as fast or faster than the routing situation.] As Sean Doran pointed out, a Cisco with a RP and SSE already accomplishes this. The distributed design of the Cisco 7500 further extends this idea, with an RP and SSE on the same board, capacity for two such boards such that you can load share CPU's, plus VIP cards that have a sub-IOS on them that grab routing information from the main RP, you have a much better solution than any kind of Unix based workstation/route calculator. > The question is: Will anyone do serious work on a solution like that in > time? Oh, I'm sure someone will. There are substantial risks involved, though, to put it into production. If it causes problems at an Interconnect, bye-bye peering. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 08:34:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03460; Tue, 5 Sep 1995 08:34:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA07876; Tue, 5 Sep 1995 08:34:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA07872; Tue, 5 Sep 1995 08:29:39 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03324; Tue, 5 Sep 1995 08:29:33 +1000 (from dsiegel@rtd.com) Received: from RTD.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA24978 Tue, 5 Sep 1995 08:29:22 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id PAA08823; Mon, 4 Sep 1995 15:24:18 -0700 From: Dave Siegel Message-Id: <199509042224.PAA08823@seagull.rtd.com> Subject: Re: Multihoming To: dorian@CIC.Net (Dorian Rysling Kim) Date: Mon, 4 Sep 1995 15:24:17 -0700 (MST) Cc: dsiegel@rtd.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, root@kbs.netusa.net In-Reply-To: from "Dorian Rysling Kim" at Sep 3, 95 11:58:21 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 887 Precedence: bulk > > There are things that people will have to live with. Renumbering isn't such > > a horrid thing. > > It's pretty horrid, but it's much better than the alternative. Would you > rather break an arm or have your head cut off? (I know, that's a pretty > gruesome analogy, but after reading this discussion enough....) Well, there are consequences to relocating your business to a different physical location. I'm about to do for the 2nd time in the meager life of my business, 2.5 years. Sooner or later, it will occur to businesses that there will be associated costs in relocating their virtual location as well (as cheesy as that analogy sounds.) Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 08:35:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03495; Tue, 5 Sep 1995 08:35:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA07900; Tue, 5 Sep 1995 08:35:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA07869; Tue, 5 Sep 1995 08:27:08 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03235; Tue, 5 Sep 1995 08:27:03 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id PAA08967; Mon, 4 Sep 1995 15:26:49 -0700 From: Dave Siegel Message-Id: <199509042226.PAA08967@seagull.rtd.com> Subject: Re: Discussing encap/mapping proposal To: root@kbs.netusa.net (Sanjay Kapur) Date: Mon, 4 Sep 1995 15:26:48 -0700 (MST) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 3, 95 12:03:24 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 924 Precedence: bulk > > Oh, well, what does he know; another unelected intellectual. > > I do believe that you know a lot when it comes to routing. I just believe > that experts, especially those of the intellectual variety, should be > consultants to the real decision makers. Intellectuals and most experts > in general are usually very bad decision makers because they ignore > everything outside their very narrow point of view. The narrow point of > view is what makes them experts in the first place. Well, then all we really need to do is to get a few routing intellectuals together with a few marketing intellectuals, and let the marketing weasels translate the problem into an advantage. ;-) Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 08:54:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04311; Tue, 5 Sep 1995 08:54:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA07939; Tue, 5 Sep 1995 08:54:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA07933; Tue, 5 Sep 1995 08:40:14 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03676; Tue, 5 Sep 1995 08:40:04 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id PAA09677; Mon, 4 Sep 1995 15:38:20 -0700 From: Dave Siegel Message-Id: <199509042238.PAA09677@seagull.rtd.com> Subject: Re: Multihoming To: root@kbs.netusa.net (Sanjay Kapur) Date: Mon, 4 Sep 1995 15:38:20 -0700 (MST) Cc: dsiegel@rtd.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 3, 95 12:45:24 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2946 Precedence: bulk > > Or, the alternative, is to pay by the mile to keep the phone number. > > Doggonit. USWest has a monopoly. Maybe I'll choose service from the local > > lightwave CAP. Oops, that doesn't work either. They can't route my prefix > > either. It's all a conspiracy. *note obvious sarcasm* > > I do NOT get your sarcasm since what you have described is a real problem > and people are actually working on it quite a bit. > > The above description of the way things work is the reason telephone > service is regulated as a monopoly. The purpose of regulation is to prevent > the telephone company from taking undue advantage of their monopoly > position. But why do you think this problem arose? Do you think USWest did this out of spite for the customer? No, I don't think so. Do you know what their current solution is? They run a line from one CO to another to forward the call, and charge you based on the mile. Boy, sounds like a technical workaround, if you ask me. > This is also precisely why local telephone number portability is an issue > before the FCC and the Congress. Toll free number portability has already > been implemented. Well, not completely. This is one of the reasons I like my 800 number, though. > There is no consumer protection system built into the Internet except the > free market and forcing renumbering curtails that free market. Believe it or not, everyone here is interested in protecting the free market. If we were not, this discussion would not be taking place, and we would let the Internet break down when it breaks down. > > There are things that people will have to live with. Renumbering isn't such > > a horrid thing. > > Whether it is horrid or not depends on which side of the fence you are on. I'm on all side of the fences, okay? I'm a customer of one NSP, and one ISP, I consult to NSP's, and I have my own clients to consider and look out for. I could be caught having to renumber all the machines on my network, as well as spending thousands of dollars worth of my time to help my customers migrate. Don't think I don't understand for a minute what this entails. I am not, however, so niave as to think that I can just give the problem to whoever is upstream. > It is a bonanza for vendors (like you) who can effectively make their piffle. > customers captive and charge higher rates. Additionaly, when customers have > to renumber, they will have to hire consultants to help them which is > again a bonanza for certain members of this list. I have already stated that I will consult my customers as to more flexible network design at MY cost, not theirs. I don't expect everyone to be willing to do this, but *I* am. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 10:54:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09562; Tue, 5 Sep 1995 10:54:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA08087; Tue, 5 Sep 1995 10:54:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA08081; Tue, 5 Sep 1995 10:44:37 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09192; Tue, 5 Sep 1995 10:44:21 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id UAA02617; Mon, 4 Sep 1995 20:43:42 -0400 Date: Mon, 4 Sep 1995 20:43:41 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Avi Freedman Cc: Noel Chiappa , big-internet@munnari.OZ.AU Subject: Re: Charging for routes... In-Reply-To: <199509041741.NAA23814@netaxs.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Avi Freedman wrote: > > The one thing we *cannot* do is *not* charge for routing entries. As > > we have all seen, whenever a finite common resource is not allocated by a free > > market, as in fishing grounds, one of two things happens: i) it gets fished > > out (current Internet), or ii) the government steps in to regulate it (usually > > when it's too late), and we all knwo how good governments are at regulating > > things... > > > > Noel > > One issue: As with traditional settlement talks, all it takes is one large > player to not go along with the thing and it falls apart. > > Avi > One word: CIX Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 11:14:29 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10397; Tue, 5 Sep 1995 11:14:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA08136; Tue, 5 Sep 1995 11:14:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA08132; Tue, 5 Sep 1995 11:10:20 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10150; Tue, 5 Sep 1995 11:09:48 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id SAA06984; Mon, 4 Sep 1995 18:09:10 -0700 Date: Mon, 4 Sep 1995 18:09:10 -0700 From: Tony Li Message-Id: <199509050109.SAA06984@greatdane.cisco.com> To: mn@ios.com Cc: big-internet@munnari.OZ.AU In-Reply-To: (mn@ios.com) Subject: Re: Tony's answer: Precedence: bulk the computation would be done for all paths and sitting ready It's already that way. the exchanged information entity to say 'is up again' is smaller, no? when we have lots of flaps we want to keep the exchanged data volume low. Routing data bandwidth within the backbone is very much irrelevant in this day and age. Recall that T3 is the minimum interconnect. Tony From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 11:15:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10442; Tue, 5 Sep 1995 11:15:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA08160; Tue, 5 Sep 1995 11:15:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA08118; Tue, 5 Sep 1995 11:06:49 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10077; Tue, 5 Sep 1995 11:06:37 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id VAA02757; Mon, 4 Sep 1995 21:03:39 -0400 Date: Mon, 4 Sep 1995 21:03:37 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: John Curran Cc: big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, John Curran wrote: > Sanjay, would you object to a totally free market system in which the > customer could choose any option they like, but they have to pay the > burdened costs thereof? > > I'm certain that the cost economics of a single dialup user are different > than those of a small ISP, and clearly they would then be able to decide > for their own circumstances whether renumbering when changing providers > made sense. > > Of course, one side effect of this approach is that we have to calculate > the net cost of 1 additional route with a metro scope, national scope, and > world-wide scope. Given that the entire network infrastructure today is > serving 30K prefixes and the diseconomies of scale that come from having to > quickly switch packets across larger routing tables, it's not inconceivable > that the global announcement of 1 prefix could cost thousands of dollars on > an annual basis. (Remember that an address prefix greatly displaced from > its "natural" topological connection point results in costs for almost every > multiply-connected network router, including the smallest dual-homed ISP who > is actively using both paths). > > Currently, this routing is provided "for free" along with Internet service; > this would have to change to an additional routing fee model with the fee > based on the scope and number of prefixes desired. One natural side effect > of this "pure market model" is that it almost guarantees that most folk seek CIDR-compliant prefixes so as to minimize their "scope charge". A small ISP > which changes backbone providers either absorbs these new routing charges on > behalf of its customers or passes them downstream. The more dramatic the > change in topology (i.e. within a metro area, within the same state, etc.), > the larger the resulting routing charges. > > We can setup a system which runs purely on free market economics; I'm just > not sure it's what you (or anyone else) really wants... > > /John > > Actually it sounds like a pretty good idea. Why should the large users subsidise the small users? As long as the costs can be fairly split, what is wrong with charging what it costs to do something to the entity that benefits from it? The large users benefit from connectivity to smaller users but the majority of the benefit is to the small user. Charging a few thousand dollars per year to advertise a route sounds very reasonable to me. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 11:34:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11362; Tue, 5 Sep 1995 11:34:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA08198; Tue, 5 Sep 1995 11:34:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA08180; Tue, 5 Sep 1995 11:17:53 +1000 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10475; Tue, 5 Sep 1995 11:17:48 +1000 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id UAA06911; Mon, 4 Sep 1995 20:55:42 -0400 From: Avi Freedman Message-Id: <199509050055.UAA06911@netaxs.com> Subject: Re: Charging for routes... To: root@kbs.netusa.net (Sanjay Kapur) Date: Mon, 4 Sep 1995 20:55:41 -0400 (EDT) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 4, 95 08:43:41 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 552 Precedence: bulk > > One issue: As with traditional settlement talks, all it takes is one large > > player to not go along with the thing and it falls apart. > > > > Avi > > > > One word: CIX > > Sanjay Kapur > Kapur Business Systems, Inc. I don't think the CIX really matters at this point. I was talking about entities who have exclusive routes to a critical mass of the net. {Sprint, MCI, ANS, Alternet, PSI, Net99/AGIS} come to mind. Any one of them not going along with a settlement (bandwdith-or-route-related) plan would scuttle the whole thing. Avi From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 11:35:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11438; Tue, 5 Sep 1995 11:35:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA08222; Tue, 5 Sep 1995 11:35:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA08194; Tue, 5 Sep 1995 11:30:43 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11122; Tue, 5 Sep 1995 11:30:11 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzfur08826; Mon, 4 Sep 1995 21:29:43 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: ISPs & multihoming To: big-internet@munnari.OZ.AU Date: Mon, 4 Sep 1995 21:29:43 -0400 (EDT) X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1527 Precedence: bulk There is quite a bit of discussion back & forth about ISPs and what happens when they multihome & effects of this on routing. Well, how many ISPs are there? What is the worse damage to the global routing tables if every ISP out there decided to multihome & had to show up in the global routing tables? Estimate 1: 32% of AlterNet's ISP customers are doing active routing with AlterNet. There are 820 active ASs in today's Internet. If 32% of all ISPs are doing active routing today, then there are just 2500 ISPs in the world today. Estimate 2: There are approx 140 ISPs in the SF Bay area. About 20% of them are multihomed. There are 820 active ASs in today's Internet. If 20% of all ISPs are multihomed today, then there are just 4100 ISPs in the world today. Estimate 3: About 6000 ASs have been assigned. If all of these belong to ISPs, then there are just 6000 ISPs in the world today. So, worse case, there seems to be some 6000 ISPs out there today. If every one of them decided to multihome & had to show up in the global routing tables, then we would have just 6000 more routes. I think that we can live with this. Lets please address the real problem - singly homed end-user sites. These had better not show up in the routing tables with one (or more) route per site. We have to figure out how to aggregate their routes into something a lot smaller than the number of sites. We have to figure out how to keep this number of routes small when they do change ISPs. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 11:54:36 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12285; Tue, 5 Sep 1995 11:54:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA08265; Tue, 5 Sep 1995 11:54:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA08261; Tue, 5 Sep 1995 11:53:41 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12224; Tue, 5 Sep 1995 11:53:23 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id SAA07691; Mon, 4 Sep 1995 18:53:12 -0700 Date: Mon, 4 Sep 1995 18:53:12 -0700 From: Tony Li Message-Id: <199509050153.SAA07691@greatdane.cisco.com> To: swb1@cornell.edu Cc: big-internet@munnari.OZ.AU In-Reply-To: (message from Scott W Brim on Mon, 4 Sep 1995 21:51:04 -0400) Subject: Re: Multihoming Precedence: bulk Briefly, topological locality only helps you if use of some other links in the topology is restricted (so that specific routes aren't propagated into all other providers), or if you can proxy aggregate within all the other providers. Ah. Sorry, I was assuming the latter. Obviously if your AAB is not a true boundary you get unintended leakage. Tony From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 11:55:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12362; Tue, 5 Sep 1995 11:55:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA08300; Tue, 5 Sep 1995 11:55:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA08256; Tue, 5 Sep 1995 11:50:04 +1000 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12007; Tue, 5 Sep 1995 11:49:51 +1000 (from swb1@cornell.edu) Received: from [132.236.236.48] (CU-DIALUP-0102.CIT.CORNELL.EDU [132.236.236.12]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id VAA27063; Mon, 4 Sep 1995 21:49:34 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Sep 1995 21:51:04 -0400 To: Tony Li From: Scott W Brim Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk At 22:36 09/03/95, Tony Li wrote: >No, we're talking about topological separation. My argument is for >geographical locality due to local loop costs. If there's an >interconnect nearby, geographical locality implies some degree of >topological locality. Briefly, topological locality only helps you if use of some other links in the topology is restricted (so that specific routes aren't propagated into all other providers), or if you can proxy aggregate within all the other providers. I tried to get the ownership-02 draft but only found -01, to see if your proxy aggregation idea was in there; will try again. ...Scott From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 11:56:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12422; Tue, 5 Sep 1995 11:56:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA08320; Tue, 5 Sep 1995 11:56:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA08257; Tue, 5 Sep 1995 11:50:04 +1000 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12011; Tue, 5 Sep 1995 11:49:54 +1000 (from swb1@cornell.edu) Received: from [132.236.236.48] (CU-DIALUP-0102.CIT.CORNELL.EDU [132.236.236.12]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id VAA27090; Mon, 4 Sep 1995 21:49:44 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu (Unverified) Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Sep 1995 21:51:14 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Scott W Brim Subject: RE: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk At 07:12 09/04/95, Noel Chiappa wrote: >That addresses would have to change when people moved was utterly implicit was >instantly obvious, *or should have been*, when CIDR was picked as the solution >to bullet two. If it wasn't, then the members of the IETF have only themselves >to blame for making decisions in areas they didn't understand. Actually, Noel, the idea I bought was (Yakov's) that new allocations would be along CIDR lines, and there would be so many new ones, with exponential growth, that they would overwhelm the paltry few old address allocations, so they could be ignored. Also I recall that was before the decision to go with provider-based addressing. (I was already off doing other things when a provider-based scheme was selected, apparently.) ...Scott From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 12:15:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13345; Tue, 5 Sep 1995 12:15:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA08367; Tue, 5 Sep 1995 12:14:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA08350; Tue, 5 Sep 1995 12:06:56 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12877; Tue, 5 Sep 1995 12:06:44 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id WAA03008; Mon, 4 Sep 1995 22:06:05 -0400 Date: Mon, 4 Sep 1995 22:06:05 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: <9509041723.AA24275@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Noel Chiappa wrote: > Where does it say, in the TCP spec, what performance you can expect from a TCP > running on a current Sun, over an Ethernet? It *doesn't* say? How fuzzy of it. > I mean, this is an important number to real-world user, even if we academics > don't care about it. > > Noel > Except in the April Fool's Day RFCs, there is no mention of hardware preformance in an RFC. We are not talking of a performance specification but network architecture specification. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 12:20:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13550; Tue, 5 Sep 1995 12:20:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA08391; Tue, 5 Sep 1995 12:18:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA08342; Tue, 5 Sep 1995 12:03:02 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12618; Tue, 5 Sep 1995 12:02:49 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id WAA02988; Mon, 4 Sep 1995 22:02:07 -0400 Date: Mon, 4 Sep 1995 22:02:07 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: jnc@ginger.lcs.mit.edu, mn@ios.com, big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: <9509041640.AA24041@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Noel Chiappa wrote: > Let's see. Is the arbitrary restriction of building generators which need fuel > "an arbitrary limitation which does not seem to be adapted to the real world?" > I mean, it's "[not] accomodating [the] real need" to have large amounts of > electric power for free... > But the restriction that you want to put on is more like: Electric supply is unreliable but you are not allowed to install electric generators in your building because you should only get electric power from the electric company. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 12:26:02 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13826; Tue, 5 Sep 1995 12:26:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03893 Tue, 5 Sep 1995 12:25:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA08413; Tue, 5 Sep 1995 12:20:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA08347; Tue, 5 Sep 1995 12:06:50 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12850; Tue, 5 Sep 1995 12:06:07 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id VAA02938; Mon, 4 Sep 1995 21:54:46 -0400 Date: Mon, 4 Sep 1995 21:54:45 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Multihoming and CIDR In-Reply-To: <9509041704.AA24098@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Noel Chiappa wrote: > From: Sanjay Kapur > > > Opimal routing in large networks, with portable addresses, is just never > > going to be an O(1), or even an O(logN), problem. > > Unless router design is radically changed. > > You don't seem to be getting the message. Sorting N integers can been shown > to be an O(NlogN) problem on a sequential machine. > > Likewise, routing is at least an O(N) problem, where N is the number of > entries in the routing table. It has nothign to do with router design. > > Noel > Why do you have to sort N integers in the router? I believe that the following model has been proposed many times by many people: Have a routing switch and a routing computer as separate pieces of hardware. Store all possible routes in an array of size 256*256*256 (class C) in the routing switch to make it as fast as possible. Have routing computations done on a separate piece of hardware that updates this array through a fast link to the routing switch. The routing switch does not need to be updated every time a new route comes in to the routing computer. If the routing switch has 256 ports, the size of the routing array would be 16MB and the time it takes to transfer this information from the routing computer to the routing switch would be about two seconds for a fast link. This could be done once a day and the routing switch will be down for about two seconds per day while this happens. Since the routing computer is doing nothing but calculate and exchange routing information with other routing computers and sorting 31000 routes, it can do it leisurely without causing any heat deaths of anything. Since routing switches are updated only one a day, the potential for flaps (jerking strings) is also reduced. The above architecture makes the whole system much less vulnerable since each routing computer can be made much smarter and easier to set up and configure and it will also know if its peers have accepted any routing infomration transmitted to them and can keep on retrying till it gets a positive acknowledgement from them. The routing computer can be almost any workstation type computer with commonly available development tools. It does not even have to be up an running all the time. With current technology, it is kind of stupid to combine a routing switch and a routing computer into one piece of hardware (The Router) not optimized for either function. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 12:36:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14269; Tue, 5 Sep 1995 12:36:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA08457; Tue, 5 Sep 1995 12:34:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA08447; Tue, 5 Sep 1995 12:30:17 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14060; Tue, 5 Sep 1995 12:30:04 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id TAA23394; Mon, 4 Sep 1995 19:29:35 -0700 From: Dave Siegel Message-Id: <199509050229.TAA23394@seagull.rtd.com> Subject: Re: Charging for routes... To: root@kbs.netusa.net (Sanjay Kapur) Date: Mon, 4 Sep 1995 19:29:35 -0700 (MST) Cc: freedman@netaxs.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 4, 95 08:43:41 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 497 Precedence: bulk > > One issue: As with traditional settlement talks, all it takes is one large > > player to not go along with the thing and it falls apart. > > One word: CIX > > Sanjay Kapur > Kapur Business Systems, Inc. And you were planning on the CIX saving you......how? Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 12:39:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14497; Tue, 5 Sep 1995 12:39:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA08486; Tue, 5 Sep 1995 12:37:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA08393; Tue, 5 Sep 1995 12:18:40 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13438; Tue, 5 Sep 1995 12:18:09 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id WAA03028; Mon, 4 Sep 1995 22:12:09 -0400 Date: Mon, 4 Sep 1995 22:12:09 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Scott Bradner Cc: sob@newdev.harvard.edu, big-internet@munnari.OZ.AU, dcrocker@brandenburg.com, huitema@pax.inria.fr, iap@vma.cc.nd.edu, inet-access@earth.com Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: <199509041724.NAA07793@newdev.harvard.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > > This fuzziness upsets me quite a bit. > > please propose clarity > > Scott > Define where the boundaries between large and small are and why. Also why should a /18 network with maybe 20 hosts in all be advertised and a /24 network with 250 machines on it be not advertised. The more I think about it, the more I like the idea of charging a reasonable fee (several thousand dollars) for advertising a route. When routing providers start seeing revenue from this, maybe they will invest in developing faster routers that can handle many more routes than currently possible. Writing a check brings things into clarity quickly. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 12:42:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14692; Tue, 5 Sep 1995 12:42:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA08516; Tue, 5 Sep 1995 12:40:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA08450; Tue, 5 Sep 1995 12:31:10 +1000 Received: from Kitten.mcs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14063; Tue, 5 Sep 1995 12:30:07 +1000 (from karl@Mcs.Net) Received: from Jupiter.mcs.net (Jupiter.mcs.net [192.160.127.89]) by kitten.mcs.com (8.6.10/8.6.9) with ESMTP id VAA20034; Mon, 4 Sep 1995 21:29:56 -0500 Received: (from karl@localhost) by Jupiter.mcs.net (8.6.11/8.6.9) id VAA00620; Mon, 4 Sep 1995 21:29:26 -0500 From: Karl Denninger Message-Id: <199509050229.VAA00620@Jupiter.mcs.net> Subject: Re: Charging for routes... To: freedman@netaxs.com (Avi Freedman) Date: Mon, 4 Sep 1995 21:29:26 -0500 (CDT) Cc: root@kbs.netusa.net, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <199509050055.UAA06911@netaxs.com> from "Avi Freedman" at Sep 4, 95 08:55:41 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1147 Precedence: bulk > > > One issue: As with traditional settlement talks, all it takes is one large > > > player to not go along with the thing and it falls apart. > > > > > > Avi > > > > > > > One word: CIX > > > > Sanjay Kapur > > Kapur Business Systems, Inc. > > I don't think the CIX really matters at this point. I was talking about > entities who have exclusive routes to a critical mass of the net. > > {Sprint, MCI, ANS, Alternet, PSI, Net99/AGIS} come to mind. Any one of them > not going along with a settlement (bandwdith-or-route-related) plan would > scuttle the whole thing. > > Avi And if they all collude, we'll be at the federal courthouse 5 minutes later, hopefully with a bunch of other ISPs to file that restraint-of-trade lawsuit as a class action. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 803-MCS1] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 12:46:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14813; Tue, 5 Sep 1995 12:46:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA08560; Tue, 5 Sep 1995 12:43:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA08453; Tue, 5 Sep 1995 12:34:00 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14149; Tue, 5 Sep 1995 12:33:48 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26005; Mon, 4 Sep 95 22:33:38 -0400 Date: Mon, 4 Sep 95 22:33:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509050233.AA26005@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, root@kbs.netusa.net Subject: Re: casting your multi-homing/provider-changing vote Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur >>> As long as its a large enough ISP to have a "short" routing prefix. >>> There is some (fuzzy & changing) threshold as to the minimum sized ISP >>> that should be considered "big enough" to fit this rule. >> This fuzziness upsets me quite a bit. Internet standards are generally >> known for their clarity and are normally not this fuzzy. > Where does it say, in the TCP spec, what performance you can expect from > a TCP running on a current Sun, over an Ethernet? there is no mention of hardware preformance in an RFC. We are not talking of a performance specification but network architecture specification. No, we are talking about performance, as most of us seem to realize. The maximum sized routing table you can have is a function of the overhead of running the routing, overhead measured in hardware capabilities like memory, computing power, bandwidth, etc. Bigger/faster hardware allows you to have bigger routing tables. (Those with long memories will remember that GGP on an LSI-11 had limit of about 300 routes...) Any limit on the length of allowed prefixes is an attempt to limit the size of the routing table to somethign the current hardware can handle, which is a performance limit. Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 12:57:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15254; Tue, 5 Sep 1995 12:57:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA08592; Tue, 5 Sep 1995 12:54:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA08574; Tue, 5 Sep 1995 12:46:42 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14814; Tue, 5 Sep 1995 12:46:06 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id WAA04056; Mon, 4 Sep 1995 22:45:33 -0400 Message-Id: <199509050245.WAA04056@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: inet-access@earth.com Cc: Scott Bradner , big-internet@munnari.OZ.AU, dcrocker@brandenburg.com, huitema@pax.inria.fr, iap@vma.cc.nd.edu Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: Your message of "Mon, 04 Sep 1995 22:12:09 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 04 Sep 1995 22:45:31 -0400 From: "Perry E. Metzger" Precedence: bulk Sanjay Kapur writes: > The more I think about it, the more I like the idea of charging a > reasonable fee (several thousand dollars) for advertising a route. When > routing providers start seeing revenue from this, maybe they will invest > in developing faster routers that can handle many more routes than > currently possible. This is perhaps the most sensible idea I've heard in a while. Unfortunately, it may result in screams. Perry From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 13:07:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15762; Tue, 5 Sep 1995 13:07:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA08632; Tue, 5 Sep 1995 13:04:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA08467; Tue, 5 Sep 1995 12:35:55 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14186; Tue, 5 Sep 1995 12:35:50 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04456 Tue, 5 Sep 1995 12:35:15 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzfuw14668; Mon, 4 Sep 1995 22:33:41 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Geographinc addressing To: big-internet@munnari.OZ.AU Date: Mon, 4 Sep 1995 22:33:41 -0400 (EDT) X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1352 Precedence: bulk People have talked about geographic addressing. Lets look at this in a bit more detail. Lets assume that everyone on the Boston area has a geographic address and that AlterNet and some other ISP (SmallGuy) have some customers in this area, and that AlterNet and SmallGuy peer at some Boston area exchange point. Now AlterNet has to have explicate routes to all sites in the Boston area - our own Boston customers plus all Boston customers of all other Boston ISPs. Humm, I don't see any aggregation here. But to continue. Now the idea is that outside of the Boston area, all ISPs will aggregate all Boston area routes (for all of their own customers and all customers of all other Boston ISPs) into one large Boston route. Now if I peer with some other ISP in some other area (say someone in San Francisco), then I am supposed to send them just one route for the Boston area. I have now suddenly offered transit for SmallGuy between San Francisco and Boston. If SmallGuy is not paying me for transit, then I am not going to do this. The only way of not doing this is to not advertise the single Boston route, but rather to advertise all of my Boston area customers individually - suddenly no more aggregation. So either there is free transit or no aggregation. Geographic addressing is not going to fly. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 13:11:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16028; Tue, 5 Sep 1995 13:11:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA08656; Tue, 5 Sep 1995 13:08:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA08586; Tue, 5 Sep 1995 12:48:35 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14982; Tue, 5 Sep 1995 12:48:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26046; Mon, 4 Sep 95 22:48:10 -0400 Date: Mon, 4 Sep 95 22:48:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509050248.AA26046@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Subject: Re: Multihoming and CIDR Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Sanjay Kapur >>> Opimal routing in large networks, with portable addresses, is just >>> never going to be an O(1), or even an O(logN), problem. >> Unless router design is radically changed. > You don't seem to be getting the message. Sorting N integers can been > shown to be an O(NlogN) problem on a sequential machine. > Likewise, routing is at least an O(N) problem, where N is the number of > entries in the routing table. Why do you have to sort N integers in the router? Are you familiar with the word "analogy"? Have a routing switch and a routing computer as separate pieces of hardware. Growth of the routing tables is outstripping the pace of the growth of hardware capability. Thus, this is at best a short-term bandaid, one good for however many months it takes to chew up the fixed improvement of splitting the problem into, at best, two. the size of the routing array would be 16MB and the time it takes to transfer this information from the routing computer to the routing switch would be about two seconds for a fast link. This could be done once a day and the routing switch will be down for about two seconds per day while this happens. Since routing switches are updated only one a day, the potential for flaps (jerking strings) is also reduced. Oh, good, when a link in the network fails, traffic that would normally flow through it will black-hole for only a day until the routing tables are updated to bypass it. The above architecture makes the whole system much less vulnerable If the absolute, utter and total lack of comprehension displayed by this statement wasn't so pitiful, it would be really funny. It does not even have to be up an running all the time. Oh, I suppose we'll have to add a new ICMP Destination Unreachable type: Destination Unreachable; Route Server Powered Down. Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 13:37:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17341; Tue, 5 Sep 1995 13:37:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA08743; Tue, 5 Sep 1995 13:34:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA08613; Tue, 5 Sep 1995 12:58:51 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15253; Tue, 5 Sep 1995 12:57:42 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id WAA03198; Mon, 4 Sep 1995 22:55:05 -0400 Date: Mon, 4 Sep 1995 22:55:04 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, mn@ios.com, jnc@ginger.lcs.mit.edu Subject: Re: Multihoming In-Reply-To: <9509041851.AA24819@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Noel Chiappa wrote: > > not how we can accomodate one vendor's boxes. > > Basically, yes. However, to the extent that we have to be realistic, and not > ivory-tower academics who are out of touch with the real world, we do have to > consider installed base, don't we? > > Noel > Whose installed base? The network service provider's or the consumer's installed base? Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 13:43:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17697; Tue, 5 Sep 1995 13:43:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA08785; Tue, 5 Sep 1995 13:41:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA08699; Tue, 5 Sep 1995 13:17:01 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16214; Tue, 5 Sep 1995 13:15:41 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by shark.mel.dit.csiro.au with SMTP id AA10725 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 5 Sep 1995 13:15:24 +1000 Received: by rodan.UU.NET id QQzfuy19079; Mon, 4 Sep 1995 23:11:43 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: Multihoming and CIDR To: root@kbs.netusa.net (Sanjay Kapur) Date: Mon, 4 Sep 1995 23:11:43 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 4, 95 09:54:45 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 470 Precedence: bulk > Store all possible routes in an array of size 256*256*256 (class C) in > the routing switch to make it as fast as possible. What about the routes that are > /24s? There are 630 of these in my routers today. > Since routing switches are updated only one a day, the potential for > flaps (jerking strings) is also reduced. So a multihomed site that looses one of its links should be prepared to loose traffic for a full day? --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 13:45:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17773; Tue, 5 Sep 1995 13:45:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA08812; Tue, 5 Sep 1995 13:43:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA08702; Tue, 5 Sep 1995 13:24:35 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16531; Tue, 5 Sep 1995 13:21:42 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA03321; Mon, 4 Sep 1995 23:10:43 -0400 Date: Mon, 4 Sep 1995 23:10:42 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Dave Siegel Cc: freedman@netaxs.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Charging for routes... In-Reply-To: <199509050229.TAA23394@seagull.rtd.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Dave Siegel wrote: > > > One issue: As with traditional settlement talks, all it takes is one large > > > player to not go along with the thing and it falls apart. > > > > One word: CIX > > > > Sanjay Kapur > > Kapur Business Systems, Inc. > > And you were planning on the CIX saving you......how? > > Dave I was trying to be too smart for my own good. I meant look at why CIX did not work before coming up with another settlement scheme. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 13:49:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17950; Tue, 5 Sep 1995 13:49:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA08832; Tue, 5 Sep 1995 13:47:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA08662; Tue, 5 Sep 1995 13:10:06 +1000 Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15931; Tue, 5 Sep 1995 13:09:16 +1000 (from swb1@cornell.edu) Received: from [132.236.236.48] (CU-DIALUP-0223.CIT.CORNELL.EDU [132.236.236.65]) by postoffice3.mail.cornell.edu (8.6.9/8.6.9) with SMTP id XAA06883; Mon, 4 Sep 1995 23:08:43 -0400 X-Sender: swb1@postoffice3.mail.cornell.edu Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 4 Sep 1995 23:10:13 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Scott W Brim Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk At 08:26 09/04/95, Noel Chiappa wrote: >If so, when the Sprint-Barney link fails, Sprint finds out about an alternate >path to Barney via MCI. The traffic from the rest of the net continues to go >to Sprint, which ships it to MCI, which gives it to Barney. I have an immediate concern with this idea (which was what I was getting at in the question I sent last night). The experience of loss of connectivity comes not just from local failures, but also from, for example, thrashing at the exchange points. Having a single representative at the exchange points won't help with that problem. Any thoughts? ...Scott From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 13:52:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18124; Tue, 5 Sep 1995 13:52:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA08859; Tue, 5 Sep 1995 13:50:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA08660; Tue, 5 Sep 1995 13:08:30 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15774; Tue, 5 Sep 1995 13:08:00 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA03286; Mon, 4 Sep 1995 23:06:51 -0400 Date: Mon, 4 Sep 1995 23:06:51 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Avi Freedman Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Charging for routes... In-Reply-To: <199509050055.UAA06911@netaxs.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Avi Freedman wrote: > > > > One word: CIX > > > > Sanjay Kapur > > Kapur Business Systems, Inc. > > I don't think the CIX really matters at this point. I was talking about > entities who have exclusive routes to a critical mass of the net. > > {Sprint, MCI, ANS, Alternet, PSI, Net99/AGIS} come to mind. Any one of them > not going along with a settlement (bandwdith-or-route-related) plan would > scuttle the whole thing. > > Avi > I really meant to say: Five words: Look at why CIX failed. CIX is/was a flat fee settlement system. Before we try to come up with a settlement system, we should look at a recent attempt at one and avoid its mistakes. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 13:59:50 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18480; Tue, 5 Sep 1995 13:59:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA08882; Tue, 5 Sep 1995 13:54:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA08693; Tue, 5 Sep 1995 13:13:00 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16047; Tue, 5 Sep 1995 13:11:58 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id UAA25733; Mon, 4 Sep 1995 20:11:07 -0700 From: Dave Siegel Message-Id: <199509050311.UAA25733@seagull.rtd.com> Subject: Re: Multihoming To: root@kbs.netusa.net (Sanjay Kapur) Date: Mon, 4 Sep 1995 20:11:04 -0700 (MST) Cc: jnc@ginger.lcs.mit.edu, mn@ios.com, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 4, 95 10:02:07 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1039 Precedence: bulk > > Let's see. Is the arbitrary restriction of building generators which need fuel > > "an arbitrary limitation which does not seem to be adapted to the real world?" > > I mean, it's "[not] accomodating [the] real need" to have large amounts of > > electric power for free... > > > > But the restriction that you want to put on is more like: > Electric supply is unreliable but you are not allowed to install > electric generators in your building because you should only get > electric power from the electric company. That is a completely unrealistic analogy. Let's try a different one. You must get your phone service from a phone company, but if you choose not to buy phone service, you are still free to buy phones. "Hey, look at this nifty intercom system we've got." yeah. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 14:19:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19406; Tue, 5 Sep 1995 14:19:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA08995; Tue, 5 Sep 1995 14:14:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA08942; Tue, 5 Sep 1995 14:01:54 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18479; Tue, 5 Sep 1995 13:59:49 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA03471; Mon, 4 Sep 1995 23:57:05 -0400 Date: Mon, 4 Sep 1995 23:57:05 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Dave Siegel Cc: jnc@ginger.lcs.mit.edu, mn@ios.com, big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: <199509050311.UAA25733@seagull.rtd.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Dave Siegel wrote: > That is a completely unrealistic analogy. Let's try a different one. > > You must get your phone service from a phone company, but if you choose > not to buy phone service, you are still free to buy phones. > > "Hey, look at this nifty intercom system we've got." > > yeah. > > Dave If you are bringing in the phone company (again) the analogy should be in being able to take your 800 number with you when you switch phone companies. And you know what? You can. The internet is like 800 number service more than like local telephone service anyway. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 14:37:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20455; Tue, 5 Sep 1995 14:37:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09058; Tue, 5 Sep 1995 14:34:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09017; Tue, 5 Sep 1995 14:18:40 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19370; Tue, 5 Sep 1995 14:18:26 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA09660 Tue, 5 Sep 1995 14:18:17 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzfvc25144; Tue, 5 Sep 1995 00:13:48 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: Multihoming and CIDR To: root@kbs.netusa.net (Sanjay Kapur) Date: Tue, 5 Sep 1995 00:13:47 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 5, 95 00:00:53 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 700 Precedence: bulk > I am only talking about core routers. I *am* talking about core routers. I *am* talking about routes in the /25 to /32 range. There are 630 of these bgp routes in my core routers today. > Actually on the average only half a day. A simple solution to that would > be to increase the update to once per hour in which case the downtime > would be half an hour on the average. This would still be > better than the heat death of the internet that Noel warns us about. NOC to Customer: "I'm sorry, your link outage missed the last routing update window; please wait XX minutes until the next one - all of your traffic will be lost in the mean time". Right. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 14:45:36 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20827; Tue, 5 Sep 1995 14:45:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10665 Tue, 5 Sep 1995 14:45:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09083; Tue, 5 Sep 1995 14:39:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA08962; Tue, 5 Sep 1995 14:08:45 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18801; Tue, 5 Sep 1995 14:07:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26446; Tue, 5 Sep 95 00:07:12 -0400 Date: Tue, 5 Sep 95 00:07:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509050407.AA26446@ginger.lcs.mit.edu> To: root@kbs.netusa.net Subject: Re: Multihoming and CIDR Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur >> Since routing switches are updated only one a day > when a link in the network fails, traffic that would normally flow > through it will black-hole for only a day until the routing tables are > updated to bypass it. When a problem like this happens, there is no reason that the routing switch can not be updated more frequently. ... Let us say the updates are limited to not more than once per hour. OK, I'll bite. Are these routing tables "swaps" synchronized across the entire Internet? I.e. do all the routers in the entire Internet update their tables once per hour at the exact (well, within a minute or so) time? I'll even be a nice guy, and tell you this is a trick question. Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 14:48:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21026; Tue, 5 Sep 1995 14:48:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09120; Tue, 5 Sep 1995 14:44:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09006; Tue, 5 Sep 1995 14:15:50 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19059; Tue, 5 Sep 1995 14:14:24 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id AAA03502; Tue, 5 Sep 1995 00:00:53 -0400 Date: Tue, 5 Sep 1995 00:00:53 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Andrew Partan Cc: big-internet@munnari.OZ.AU Subject: Re: Multihoming and CIDR In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > > Store all possible routes in an array of size 256*256*256 (class C) in > > the routing switch to make it as fast as possible. > > What about the routes that are > /24s? There are 630 of these in my > routers today. > I am only talking about core routers. I assume you mean routes like /16. In that case we can always break it up into 256 identical routes. > > Since routing switches are updated only one a day, the potential for > > flaps (jerking strings) is also reduced. > > So a multihomed site that looses one of its links should be prepared to > loose traffic for a full day? > Actually on the average only half a day. A simple solution to that would be to increase the update to once per hour in which case the downtime would be half an hour on the average. This would still be better than the heat death of the internet that Noel warns us about. > --asp@uunet.uu.net (Andrew Partan) > From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 14:55:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21385; Tue, 5 Sep 1995 14:55:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09167; Tue, 5 Sep 1995 14:52:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA08943; Tue, 5 Sep 1995 14:01:51 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18503; Tue, 5 Sep 1995 14:00:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26368; Mon, 4 Sep 95 23:59:46 -0400 Date: Mon, 4 Sep 95 23:59:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509050359.AA26368@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, mn@ios.com Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Michael F. Nittmann" And relativity was done by a German 'IRS' official, by the way, who was kicked out of physics school. You don't know much about physicists either. Einstein was never a German IRS official, he worked for the Swiss federal patent office from June, 1902, to July 1909, whereupon he became a professor at the University of Zurich. (See "Subtle is the Lord.... The Life and Science of Albert Einstein", by A. Pais, pp 46-47 and 185-186. We academics can't scratch our nose without giving a citation.) As to being kicked out of physics school, on his first attempt at admission to ETH, the Swiss technical academy (where he did his "undergrad" work) he failed the entrance exam, but was later admitted after getting his Matura, a high-school diploma that wouldd entitle him to enroll at ETH. (See Pais, pp. 39-41.) Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 15:05:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21866; Tue, 5 Sep 1995 15:05:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09227; Tue, 5 Sep 1995 15:02:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09138; Tue, 5 Sep 1995 14:46:57 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20828; Tue, 5 Sep 1995 14:45:36 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id VAA02128; Mon, 4 Sep 1995 21:43:30 -0700 From: Dave Siegel Message-Id: <199509050443.VAA02128@seagull.rtd.com> Subject: Re: Geographinc addressing To: asp@uunet.uu.net (Andrew Partan) Date: Mon, 4 Sep 1995 21:43:30 -0700 (MST) Cc: big-internet@munnari.OZ.AU In-Reply-To: from "Andrew Partan" at Sep 4, 95 10:33:41 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1849 Precedence: bulk > Now the idea is that outside of the Boston area, all ISPs will > aggregate all Boston area routes (for all of their own customers and > all customers of all other Boston ISPs) into one large Boston route. > Now if I peer with some other ISP in some other area (say someone in > San Francisco), then I am supposed to send them just one route for the > Boston area. This sounds quite similar to the routing of phone calls based on NPA/NXX. I wish I had a little more telco experience to understand how a translation of that architecture could be translated to a useful data transport design, if at all. It seems to have worked well for the telco's. > I have now suddenly offered transit for SmallGuy between San Francisco > and Boston. > If SmallGuy is not paying me for transit, then I am not going to do > this. However, if all other providers in that area were also providing transport (a tricky idea, no doubt) there might be enough diverse routing to make this feasible in terms of total bandwidth used by client X on your network. Of course, "who charges for transit then, and what do they provide, exactly" becomes an interesting distinction. The ISP, could, potentially say "hm, who do I default to today?" > The only way of not doing this is to not advertise the single Boston > route, but rather to advertise all of my Boston area customers > individually - suddenly no more aggregation. shucks. > So either there is free transit or no aggregation. > Geographic addressing is not going to fly. I never really expected that it would, but it's interesting to see a scenario painted to confirm this. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 15:14:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22317; Tue, 5 Sep 1995 15:14:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09271; Tue, 5 Sep 1995 15:11:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA08983; Tue, 5 Sep 1995 14:12:00 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18929; Tue, 5 Sep 1995 14:11:33 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzfvc24535; Tue, 5 Sep 1995 00:07:40 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: ISPs & multihoming To: dorian@CIC.Net (Dorian Rysling Kim) Date: Tue, 5 Sep 1995 00:07:40 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: from "Dorian Rysling Kim" at Sep 4, 95 11:42:45 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 2138 Precedence: bulk > Perhaps I misunderstand something, but how did you get 6000 more routes > with 6000 ISPs? For example, CICNet has 5 /16s, 1 /15 as well as all the > historical class Bs allocated to CIC universities, and other Bs and /16s > that have been allocated to our customers. Even if everything can be > aggregated and proxy aggragated to /16s, and renumber every customer > allocation not part of our CIDR blocks longer than /16, that's still over > 30+ routes. Be careful here - you are mixing sites & ISPs. If sites are all numbered w/in their ISP's block, then you have just one route per ISP. The problem that some people are pointing out is needing to renumber a whole ISP & all of the ISP's customers - I'm saying that since there are just not that many ISPs, you should never need to renumber an entire ISP & all of its customers. > Granted CICNet is an ex-NSF regional, and we are bigger than small ISPs, > but aren't we looking at at least half a dozen per ISP? Then that's 36,000 > new routes, give or take couple of thousand. Can we handle that? I don't > know.. No that is 36K routes *total* - and since we are already handing 30K today, that is not a big problem. Look at where the explosion in routing tables comes from - its not the addition of new ISPs - there are just not that many of them; its not from the addition of new multihomed sites - there are just not that many of them. Its from the addition of new singly homed sites. Attack that problem - adding an increasing number of singly homed sites (& the movement of them between ISPs) without a similar increase in the size of the routing tables. We *can* handle an increase in the routing table size - but only so long as that increase is something like a doubling every 18 months to 2 years. [The computer industry is only doubling the power of computers every 18 months or so - we need to keep our routing tables growing at no more than this rate.] If we double the size of our routing tables at the current doubling rate of the Internet - at every 5 to 9 months, then we are doomed; its just a matter of when. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 15:25:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22919; Tue, 5 Sep 1995 15:25:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09319; Tue, 5 Sep 1995 15:22:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09052; Tue, 5 Sep 1995 14:31:11 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19849; Tue, 5 Sep 1995 14:27:34 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id AAA03544; Tue, 5 Sep 1995 00:25:04 -0400 Date: Tue, 5 Sep 1995 00:25:04 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: <9509050338.AA26207@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Noel Chiappa wrote: > From: Sanjay Kapur > > The assumption that everyone will move and if they move they will want to > take their addresses with them. > > Well, if most people won't move, and many of those who do won't take their > addresses with them, then we don't have a problem. Good, we can all go home. OK with me. As long as we do not put that prohibition against renumbering. > > You keep acting like I'm the one setting, or trying to set, the constraints. > You're shooting the messenger. If I went off to Tahiti and was never heard > from again, that *still* wouldn't let everyone move and take their address > with them, or be widely multihomed with optimal routing at all times, or > whatever. > > It has nothing to do with me, although you don't seem to be able to comprehend > that (for reasons I won't speculate on, 'cause DCrocker says it's > unprofessional, although I gather from the private comments I've received that > most everyone else on the list has their own opinion already), so I'll give up > trying to explain it. OK. So you do not like me and other people also do not like me and think I am stupid. I can live with that. Why don't you go to Tahiti and let others devise a real solution? Maybe a few days (or years) in the warm tropical sun will improve your disposition. > It does not matter. Unless the Internet goes bankrupt, the original > guarantees are valid and all who inherit the Internet have to uphold them. > > I hope everyone else is as amused by the concept of the Internet going > bankrupt as I am. Good. I like to make people happy. What is the Internet composed of? IETF and a few other bodies like it. They are the legal inheritors of the old Internet and CAN go bankrupt. The other parts of the Internet are the backbone providers. In providing an "Internet Service" and charging fees for it, they also are bound to provide services as laid down by the RFCs and can be sued for breach of contract unless they go bankrupt. I did not think I had to spell out the concept of the Internet going bankrupt but it seems that there are incredibily dense folk in this mailing list. > > Just out of interest, do you have any idea how ridiculous you're making > yourself look? I really don't need to say a thing, you're doing a fantastic > job all on your own. > I had been warned by others who are on the other side of the debate from you about the tendency that you and your friends have to ridicule those that disagree with you. > Ah, so all those jailed people who promised to sell perpetual motion machines > were forced to keep their promise, eh? Of course. They are kept in jail till they can deliver :-). > > If we only wanted an Internet the size of the current one, we'd be fine. > Problem is we want a *bigger* Internet. Something that works fine at one level > of scale doesn't work at another, which is why insects and vertebrates have > very different physiology when it comes to blood, gas exchange, etc. > > that involve different router technology that you refuse to acknowledge. > > So, go build them and make a fortune. > This is the real problem. No one is interested in building them because there is no fortune in it since the market is small. A mechanism should be devised where it would be profitable to make those routers. A route advertisement fee is one such mechanism. > > My solution: Encourage organizations to renumber when changing providers. > Do NOT force them to renumber. > > What do you do if not enough people renumber voluntarily? Let us face that problem when we get there. Currently we do not even try hard enough. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 15:29:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23171; Tue, 5 Sep 1995 15:29:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09356; Tue, 5 Sep 1995 15:27:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA08834; Tue, 5 Sep 1995 13:47:37 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17855; Tue, 5 Sep 1995 13:47:18 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id UAA28040; Mon, 4 Sep 1995 20:46:43 -0700 From: Dave Siegel Message-Id: <199509050346.UAA28040@seagull.rtd.com> Subject: Re: Multihoming and CIDR To: root@kbs.netusa.net (Sanjay Kapur) Date: Mon, 4 Sep 1995 20:46:43 -0700 (MST) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 4, 95 09:54:45 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4340 Precedence: bulk > > You don't seem to be getting the message. Sorting N integers can been shown > > to be an O(NlogN) problem on a sequential machine. > > Likewise, routing is at least an O(N) problem, where N is the number of > > entries in the routing table. It has nothign to do with router design. > > Why do you have to sort N integers in the router? After reading the below, it's obvious you put particular emphasis on the word "router." In any case, let's analyze your design. > I believe that the following model has been proposed many times by many > people: Who? Do they have real-world experience? ...nevermind, I don't want to know. > Have a routing switch and a routing computer as separate pieces of hardware. Why seperate peices of hardware? Can they be on the same backplane at least? > Have routing computations done on a separate piece of hardware that > updates this array through a fast link to the routing switch. The > routing switch does not need to be updated every time a new route comes > in to the routing computer. If the routing switch has 256 ports, the But there's a problem. It *does* need to be updated...I'll explain why later. > size of the routing array would be 16MB and the time it takes to transfer > this information from the routing computer to the routing switch would be > about two seconds for a fast link. This could be done once a day and the > routing switch will be down for about two seconds per day while this happens. 2 seconds if you reload the whole dad-blamed thing from scratch, not if you compare and recalculate. > Since the routing computer is doing nothing but calculate and exchange > routing information with other routing computers and sorting 31000 > routes, it can do it leisurely without causing any heat deaths of anything. And these recalculations are meaningless, since you aren't going to do anything with the info until the router reload. > Since routing switches are updated only one a day, the potential for > flaps (jerking strings) is also reduced. You are correct. There will be no such thing as a route flap. Unfortunately, you also loose dynamic routing capabilities. You may as well static route every route on the Internet! > The above architecture makes the whole system much less vulnerable since > each routing computer can be made much smarter and easier to set up > and configure and it will also know if its peers have accepted any > routing infomration transmitted to them and can keep on retrying till it > gets a positive acknowledgement from them. The routing computer can be > almost any workstation type computer with commonly available development > tools. It does not even have to be up an running all the time. Sounds wonderful. It is definitely less vulnerable. Smarter? You mean, with it's "static" internal array, it's going to know that it can't send packets down link A like it's table says, because it's going to magically know that down link A, there is a line down, and he should send his traffic to link B? Worse yet, Link A is probably redirecting traffic to link B Already, you and are unecessarily forwarding traffic across links. This looks real bad if you're sending the traffic across the country and back. Furthermore, if B has a similar static array design, he might be sending the traffic back to A. Routing loops are no good for anybody, and particularly at the core level. Now your router is constantly generating icmp redirects. Save a lot of CPU didn't we. > With current technology, it is kind of stupid to combine a routing switch > and a routing computer into one piece of hardware (The Router) not optimized > for either function. So, if we take this "routing computer," and call it, say, a Router Processor, and then take this switching device, Let's call it a Silicon Switch Processor. But, instead of seperating them by something flimsy like an ethernet, or an FDDI ring, let's build a backplane, put these suckers on cards, and then use the same bus to load up some interfaces. Sounds like the architecture of a Cisco or a Welfleet, to me. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 15:36:25 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23494; Tue, 5 Sep 1995 15:36:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA11069 Tue, 5 Sep 1995 14:54:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09144; Tue, 5 Sep 1995 14:47:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09032; Tue, 5 Sep 1995 14:24:40 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19604; Tue, 5 Sep 1995 14:23:34 +1000 (from dorian@CIC.Net) Received: from nic.hq.cic.net by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08730 Tue, 5 Sep 1995 14:00:43 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id XAA23191; Mon, 4 Sep 1995 23:58:11 -0400 Date: Mon, 4 Sep 1995 23:58:11 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: Karl Denninger Cc: Avi Freedman , root@kbs.netusa.net, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Charging for routes... In-Reply-To: <199509050229.VAA00620@Jupiter.mcs.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Karl Denninger wrote: > > {Sprint, MCI, ANS, Alternet, PSI, Net99/AGIS} come to mind. Any one of them > > not going along with a settlement (bandwdith-or-route-related) plan would > > scuttle the whole thing. > > And if they all collude, we'll be at the federal courthouse 5 minutes later, > hopefully with a bunch of other ISPs to file that restraint-of-trade > lawsuit as a class action. I can see it now... open standards based pricing plan. I-D to be published soon, and to be moved to Standard track RFC soon. The very first of its kind! Join the route-pricing WG today! Hmmm.. it's kinda funny, in a perverted sort of a way.. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 15:55:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24459; Tue, 5 Sep 1995 15:55:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09448; Tue, 5 Sep 1995 15:52:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09207; Tue, 5 Sep 1995 14:59:53 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21678; Tue, 5 Sep 1995 14:59:47 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id VAA02388; Mon, 4 Sep 1995 21:47:10 -0700 From: Dave Siegel Message-Id: <199509050447.VAA02388@seagull.rtd.com> Subject: Re: Multihoming To: root@kbs.netusa.net (Sanjay Kapur) Date: Mon, 4 Sep 1995 21:47:10 -0700 (MST) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, mn@ios.com In-Reply-To: from "Sanjay Kapur" at Sep 4, 95 10:55:04 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 793 Precedence: bulk > > not how we can accomodate one vendor's boxes. > > Basically, yes. However, to the extent that we have to be realistic, and not > > ivory-tower academics who are out of touch with the real world, we do have to > > consider installed base, don't we? > > Whose installed base? The network service provider's or the > consumer's installed base? Both. Neither as an isolated issue is the problem, but combined, with mixing and matching, that is the problem. The "Internet's" installed customer base is the issue, regardless of who is taking the checks. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 15:58:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24567; Tue, 5 Sep 1995 15:58:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09480; Tue, 5 Sep 1995 15:55:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA09249; Tue, 5 Sep 1995 15:07:22 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21883; Tue, 5 Sep 1995 15:06:09 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by shark.mel.dit.csiro.au with SMTP id AA12684 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 5 Sep 1995 15:05:47 +1000 Received: by rodan.UU.NET id QQzfvg00953; Tue, 5 Sep 1995 01:03:07 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: Geographinc addressing To: dsiegel@rtd.com (Dave Siegel) Date: Tue, 5 Sep 1995 01:03:07 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199509050443.VAA02128@seagull.rtd.com> from "Dave Siegel" at Sep 4, 95 09:43:30 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 880 Precedence: bulk > I wish I had a little more telco experience to understand how a translation > of that architecture could be translated to a useful data transport design, > if at all. It seems to have worked well for the telco's. Telephone calls are based on circuits, not datagrams. So its entirely possible for any call to know who placed the call & thus who should get charged. Data is not voice; voice is not data. Repeat. Some of the telco work really just does not translate to the data world. Btw, 800 numbers are handled via translation tables. And on the subject of telcos; when our company changed it local voice provider, guess what? All of our phone numbers changed. And when we moved to a new building, guess what? All of our phone numbers changed. I sure wish that this accepted telco practice would translate to the Internet world. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 16:00:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24640; Tue, 5 Sep 1995 16:00:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09488; Tue, 5 Sep 1995 15:55:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA09214; Tue, 5 Sep 1995 15:01:12 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21697; Tue, 5 Sep 1995 15:01:03 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id VAA02920; Mon, 4 Sep 1995 21:55:31 -0700 From: Dave Siegel Message-Id: <199509050455.VAA02920@seagull.rtd.com> Subject: Re: Multihoming To: root@kbs.netusa.net (Sanjay Kapur) Date: Mon, 4 Sep 1995 21:55:31 -0700 (MST) Cc: dsiegel@rtd.com, jnc@ginger.lcs.mit.edu, mn@ios.com, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 4, 95 11:57:05 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1318 Precedence: bulk > > That is a completely unrealistic analogy. Let's try a different one. > > You must get your phone service from a phone company, but if you choose > > not to buy phone service, you are still free to buy phones. > > "Hey, look at this nifty intercom system we've got." > > If you are bringing in the phone company (again) the analogy should be in > being able to take your 800 number with you when you switch phone > companies. And you know what? You can. The internet is like 800 number > service more than like local telephone service anyway. An 800 number is the equivalent of a domain name. A local telephone number is the equivalent of an IP address. The 800 number can map to any local telephone number, but if you move locations, you may have to get a different phone number, and you will have to have the phone company remap your 800 number to your new local phone number. Such is the concept behind renumbering. If you change your location in virtual space, you may have to change your IP address, but you can still remap your domain name to your new IP address. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 16:03:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24797; Tue, 5 Sep 1995 16:03:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09522; Tue, 5 Sep 1995 15:59:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA09238; Tue, 5 Sep 1995 15:05:35 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21835; Tue, 5 Sep 1995 15:05:04 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id WAA03452; Mon, 4 Sep 1995 22:04:54 -0700 From: Dave Siegel Message-Id: <199509050504.WAA03452@seagull.rtd.com> Subject: Re: ISPs & multihoming To: dorian@CIC.Net (Dorian Rysling Kim) Date: Mon, 4 Sep 1995 22:04:54 -0700 (MST) Cc: asp@uunet.uu.net, big-internet@munnari.OZ.AU In-Reply-To: from "Dorian Rysling Kim" at Sep 4, 95 11:42:45 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1328 Precedence: bulk > > So, worse case, there seems to be some 6000 ISPs out there today. If > > every one of them decided to multihome & had to show up in the global > > routing tables, then we would have just 6000 more routes. > > Perhaps I misunderstand something, but how did you get 6000 more routes > with 6000 ISPs? For example, CICNet has 5 /16s, 1 /15 as well as all the > historical class Bs allocated to CIC universities, and other Bs and /16s > that have been allocated to our customers. Even if everything can be > aggregated and proxy aggragated to /16s, and renumber every customer > allocation not part of our CIDR blocks longer than /16, that's still over > 30+ routes. He is only looking at the affects of an ISP multi-homing, and the resulting more specific route generated by this. He get's this by extrapolating the fact that an AS is required to multi-home correctly. He is making the assumption that the ISP will be intellegent enough to announce all of it's networks with a single prefix, which is, of course, only possible after signifigant renumbering (for most ISP's, anyway). Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 16:05:38 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24865; Tue, 5 Sep 1995 16:05:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12341 Tue, 5 Sep 1995 15:23:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09292; Tue, 5 Sep 1995 15:17:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA08988; Tue, 5 Sep 1995 14:13:23 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19009; Tue, 5 Sep 1995 14:12:56 +1000 (from root@kbs.netusa.net) Received: from kbs.netusa.net (chms50.noc200.sunysb.edu) by shark.mel.dit.csiro.au with SMTP id AA11563 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 5 Sep 1995 14:12:02 +1000 Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA03435; Mon, 4 Sep 1995 23:44:48 -0400 Date: Mon, 4 Sep 1995 23:44:48 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Multihoming and CIDR In-Reply-To: <9509050248.AA26046@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > Growth of the routing tables is outstripping the pace of the growth of > hardware capability. Thus, this is at best a short-term bandaid, one good for > however many months it takes to chew up the fixed improvement of splitting the > problem into, at best, two. Is the whole internet currently not a bandaid? As long as the bandaid works till IPv6 saves the day, what is wrong with it? > > the size of the routing array would be 16MB and the time it takes to > transfer this information from the routing computer to the routing switch > would be about two seconds for a fast link. This could be done once a day > and the routing switch will be down for about two seconds per day while > this happens. Since routing switches are updated only one a day, the > potential for flaps (jerking strings) is also reduced. > > Oh, good, when a link in the network fails, traffic that would normally flow > through it will black-hole for only a day until the routing tables are updated > to bypass it. When a problem like this happens, there is no reason that the routing switch can not be updated more frequently. Although too frequent an update will cause more problems. Let us say the updates are limited to not more than once per hour. When balanced against the heat death of the Internet that you are always warning about, what is black hole of a link for one hour? > > The above architecture makes the whole system much less vulnerable > > If the absolute, utter and total lack of comprehension displayed by this > statement wasn't so pitiful, it would be really funny. > When balanced against the heat death of the routers that you are always warning about, yes, it is much less vulnerable. If the utter and total lack of comprehension of the problems facing the network consumers displayed by your statements were not so pitiful, they would be really funny. > It does not even have to be up an running all the time. > > Oh, I suppose we'll have to add a new ICMP Destination Unreachable type: > Destination Unreachable; Route Server Powered Down. > No. The routing switch would still be up so the destination would still be reachable. Instead of bringing down the router for software maintenance, only the route computer has to be go down. The routing switch would be much more robust and the current router which can fail due to both a routing software failure or the routing switch failure. > Noel > Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 16:06:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24896; Tue, 5 Sep 1995 16:06:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA09530; Tue, 5 Sep 1995 16:00:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA09229; Tue, 5 Sep 1995 15:02:55 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21748; Tue, 5 Sep 1995 15:02:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26750; Tue, 5 Sep 95 01:02:40 -0400 Date: Tue, 5 Sep 95 01:02:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509050502.AA26750@ginger.lcs.mit.edu> To: root@kbs.netusa.net Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur Why don't you ... let others devise a real solution? Feel free. What is the Internet composed of? IETF and a few other bodies like it. They are the legal inheritors of the old Internet and CAN go bankrupt. You don't seem to understand this either. The IETF is not a legal entity (and it has no assets), any more than "the Internet" is. What are you going to do, serve papers on a mailing list file? I did not think I had to spell out the concept of the Internet going bankrupt but it seems that there are incredibily dense folk in this mailing list. Ah. I had been warned by others who are on the other side of the debate from you Birds of a feather... about the tendency that you and your friends have to ridicule those that disagree with you. Ah, right, the way I ridiculed Scott Ballew for disagreeing with my first long analysis of multihoming. (For those who don't get it, I don't at all mind people disagreeing with me, no matter how junior or unknown they are - I'd never heard of Scott before his message - as long as they have a clue. I think my effusive response to Scott is pretty good proof that this isn't just talk, but for real.) > What do you do if not enough people renumber voluntarily? Let us face that problem when we get there. Where do you think we are now? Why do you think the core routers' tables are getting too big? Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 16:20:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25594; Tue, 5 Sep 1995 16:20:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA09380; Tue, 5 Sep 1995 15:35:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA09294; Tue, 5 Sep 1995 15:18:04 +1000 Received: from ns.iij.ad.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22473; Tue, 5 Sep 1995 15:17:15 +1000 (from davidc@iij.ad.jp) Received: from argus.iij.ad.jp (argus.iij.ad.jp [192.244.176.41]) by ns.iij.ad.jp (8.6.12+2.4W/3.3W9-NS) with SMTP id OAA29209; Tue, 5 Sep 1995 14:15:27 +0900 Message-Id: <199509050515.OAA29209@ns.iij.ad.jp> To: Sanjay Kapur Cc: Dave Siegel , jnc@ginger.lcs.mit.edu, mn@ios.com, big-internet@munnari.OZ.AU, davidc@ns.iij.ad.jp Subject: Re: Multihoming In-Reply-To: Your message of "Mon, 04 Sep 1995 23:57:05 -0400." Date: Tue, 05 Sep 1995 14:17:00 +0900 From: David R Conrad Precedence: bulk Good god, but this is getting boring. >If you are bringing in the phone company (again) the analogy should be in >being able to take your 800 number with you when you switch phone >companies. And you know what? You can. The internet is like 800 number >service more than like local telephone service anyway. One more time: The equivalent of 800 (and other portable telephone "numbers") is a DNS name. You don't have to change it when you change providers as the underlying infrastructure takes care of the mapping for you. Let's go back to the huge array of networks updated every half an hour on average, its was more amusing. Almost as much fun as the conspiracy theories. Hmmm. I don't suppose you spent some time in the Azores recently? Regards, -drc From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 16:38:30 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26435; Tue, 5 Sep 1995 16:38:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA09608; Tue, 5 Sep 1995 16:34:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA09586; Tue, 5 Sep 1995 16:17:06 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25406; Tue, 5 Sep 1995 16:16:08 +1000 (from dsiegel@rtd.com) Received: from relay1.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA14877 Tue, 5 Sep 1995 16:15:46 +1000 (from dsiegel@rtd.com) Received: from seagull.rtd.com by relay1.UU.NET with SMTP id QQzfvc26641; Tue, 5 Sep 1995 00:06:37 -0400 Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id UAA28251; Mon, 4 Sep 1995 20:50:14 -0700 From: Dave Siegel Message-Id: <199509050350.UAA28251@seagull.rtd.com> Subject: Re: Charging for routes... To: karl@Mcs.Net (Karl Denninger) Date: Mon, 4 Sep 1995 20:50:14 -0700 (MST) Cc: freedman@netaxs.com, root@kbs.netusa.net, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <199509050229.VAA00620@Jupiter.mcs.net> from "Karl Denninger" at Sep 4, 95 09:29:26 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1069 Precedence: bulk > > I don't think the CIX really matters at this point. I was talking about > > entities who have exclusive routes to a critical mass of the net. > > > > {Sprint, MCI, ANS, Alternet, PSI, Net99/AGIS} come to mind. Any one of them > > not going along with a settlement (bandwdith-or-route-related) plan would > > scuttle the whole thing. > > And if they all collude, we'll be at the federal courthouse 5 minutes later, > hopefully with a bunch of other ISPs to file that restraint-of-trade > lawsuit as a class action. Why, because they didn't all pitch in for the good of the Internet, and adopt a certain pricing strategy based on routes? That's what Avi was talking about. Rather, you seem to imply that if they did all adopt a policy for charging based on routes, you'd take them to court. Which is it, and what's your basis? Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 16:43:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26661; Tue, 5 Sep 1995 16:43:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09191; Tue, 5 Sep 1995 14:55:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA09060; Tue, 5 Sep 1995 14:35:16 +1000 Received: from chms50.noc200.sunysb.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20174; Tue, 5 Sep 1995 14:34:48 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id AAA03562; Tue, 5 Sep 1995 00:33:53 -0400 Date: Tue, 5 Sep 1995 00:33:52 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Andrew Partan Cc: big-internet@munnari.OZ.AU Subject: Re: Multihoming and CIDR In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 5 Sep 1995, Andrew Partan wrote: > > I *am* talking about core routers. > I *am* talking about routes in the /25 to /32 range. > There are 630 of these bgp routes in my core routers today. The situation is far worse than I envisioned. I throw up my hands in disgust. We allow these routes into the network and then get upset when someone with a /19 route wants to advertise? > > > Actually on the average only half a day. A simple solution to that would > > be to increase the update to once per hour in which case the downtime > > would be half an hour on the average. This would still be > > better than the heat death of the internet that Noel warns us about. > > NOC to Customer: "I'm sorry, your link outage missed the last routing > update window; please wait XX minutes until the next one - all of your > traffic will be lost in the mean time". Right. > > --asp@uunet.uu.net (Andrew Partan) > As compared to: NOC to Customer: "I'm sorry, the Internet is down today" Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 16:45:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26817; Tue, 5 Sep 1995 16:45:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA09648; Tue, 5 Sep 1995 16:43:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA09589; Tue, 5 Sep 1995 16:18:14 +1000 Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23604; Tue, 5 Sep 1995 15:38:54 +1000 (from kre@munnari.OZ.AU) From: Robert Elz To: Big-Internet@munnari.OZ.AU Subject: B-I on autopilot for the rest of this week Date: Tue, 05 Sep 1995 15:38:28 +1000 Message-Id: <15665.810279508@munnari.OZ.AU> Sender: kre@munnari.OZ.AU Precedence: bulk I will not be around my office until early next week (Monday sometime), so won't be processing B-I administrative requests between any that have been done already (and acknowledged), and then. Apologies if you're trying hard to get off the list... Please just wait. If I get a chance I will scan for unsubscribe requests and perform them without acknowledging them earlier, but no guarantees. I will also be directing owner-Big-Internet@munnari.OZ.AU to the bit bucket (so I lose all bounce messages). If you attempt to send admin messages there, they will certainly be lost. Please remember to use Big-Internet-Request@munnari.OZ.AU for admin requests. While I'm here - there are a lot of new users on B-I just recently, please recall the part of the welcome message where it said about reading the archives - at least the recent ones, before saying too much, if not, you can be very tempted to simply repeat what has been said before. The archives are available for anon ftp from munnari.OZ.AU in the directory big-internet/list-archive The recent archives will be in the two files 1995-08-Aug and current for last month, and this month, respectively. Please do fetch and read anything from before you joined the list. And once aghain, please do be careful with quoting - take an extra minute and delete unnecessary parts of messages you are replying to. Thanks, kre From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 16:48:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26921; Tue, 5 Sep 1995 16:48:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA08939; Tue, 5 Sep 1995 14:01:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA08740; Tue, 5 Sep 1995 13:34:13 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17159; Tue, 5 Sep 1995 13:32:59 +1000 (from sob@harvard.edu) Received: from newdev.harvard.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06964 Tue, 5 Sep 1995 13:31:47 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id XAA09462; Mon, 4 Sep 1995 23:28:50 -0400 (EDT) Date: Mon, 4 Sep 1995 23:28:50 -0400 (EDT) From: Scott Bradner Message-Id: <199509050328.XAA09462@newdev.harvard.edu> To: asp@uunet.uu.net, big-internet@munnari.OZ.AU Subject: Re: Geographinc addressing Precedence: bulk An example of some of the problems with geographinc addressing that is close to home for me. I live in Cambridge MA and I'm a beta site on the PSICable Internet service (a 500Kb fully bidirectional Internet connection provided over the local cable TV infrastructure). I work at Harvard University, about 1.5 miles away from me crow-flight-wise. Harvard gets its Internet connectivity from BBN Planet New England Region (once called NEARnet), they get their connection from MCI. PSI and MCI exchange traffic at MAE-East in the Washington DC area. So when I login to my Harvard computer from home my packets travel from Cambridge to DC to Cambridge to get 1.5 miles. Assuming that this level of interconnection, geographinc addressing would mean that routers all over the east coast would have to know to get to my house you have to go to DC. i.e geographinc addressing, in order to work, requires a great deal more localized interconnections between providers than we no have. Supporters of geographinc addressing need to say how this interconnection will come about. Scott From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 16:58:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27377; Tue, 5 Sep 1995 16:58:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA09679; Tue, 5 Sep 1995 16:54:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA09622; Tue, 5 Sep 1995 16:38:15 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26380; Tue, 5 Sep 1995 16:37:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27383; Tue, 5 Sep 95 02:36:50 -0400 Date: Tue, 5 Sep 95 02:36:50 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509050636.AA27383@ginger.lcs.mit.edu> To: swb1@cornell.edu, tli@cisco.com Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Scott W Brim >> It IS a claim that provider-based addressing may have looked good once, >> but ... now its problems outweigh its benefits. > I would be very interested in knowing what you think has changed. > These are the exact same points and issues that we've been discussing > (and discussing, and discussing, and discussing) for the last three > years. I believe the business significance of an Internet connection has increased rapidly, that the Internet is now a strategic business tool. True, but that doesn't change technical feasibility much. Sure, more $$$ means you can pay for higher-priced hardware, but that only buys you smallish time factors at these growth rates. Also, not all the users of the Internet have the same monetary resources, so either i) we can't spread the cost evenly, or ii) we're constrained by not putting net out of reach of the little guys. However, wrt reliability, individual providers aren't keeping up with the rate at which the Internet's business importance is increasing How much of this is due to insufficiently sophisticated design and config, though? (Dorian sent in a message - Fri, 1 Sep 1995 03:57:16 - talking about the 7 places you could do redundancy, such as "Diverse routing of the physical links into COs", and suggesting that many small ISP's didn't make the right choices there.) (partly because of the routing thrash we're seeing at the interconnect points ... hmmm ...). Exactly... Anyway, apparently connecting to multiple major providers, either directly or through local providers which are connected to multiple major providers, satisfies their needs Well, they *think* it will solve all their reliability problems (or at least some large subset of them). I wonder if it really will, though. Remember the time the backhoe dug up some conduit, and it partitioned the ARPANet because several of it's "independent" links were in the same physical path? connecting to one provider multiply does not. A well-designed multiple connection to one well-designed provider (taking into mind that list of 7 points in that message by Dorian) is probably going to produce a much more reliable service than two kludged up links to separate, poorly-run providers. this trend is based on a strong perceived need by the customers They see problems, yes. However, I doubt customers really have the expertise to figure out what the problem really is, let alone the right solution. Is the lack of connectivity caused by a provider link that's down, or routing screwed up somewhere, or what? I've seen a heck of a lot of black holes, poking around the Internet the last few days. Not ICMP DU's, mind, but "traceroute" just falling into a hole. Not even a routing loop (that would show up). Unless people are using static routing (in which case, multihoming is *not* going to help you), the only way to get this is with bad configurations, *not* links down. If something is off-net because a link failed, sooner or later you should get to some router which knows it can't reach that thing (i.e. no routing table entry for it); i.e. something that can send you a DU (unless it's configured not to, do people do that)? I mean, I can't say for sure what the problem is, in a lot of cases. If I can't, I wonder what percentage of the average Joe customers can? Probably a lot just say "got a connection timeout to foo.bar.zap, must be my provider's fault"... the engineering solution embodied in the document goes against it It does not say you can't multihome, and I listed three approaches (with varying costs/benefit sets) which would allow a *lot* of multihoming. it sets you up for dissatisfaction on all sides. What sets people up for dissatisfaction is having unreasonable hopes raised. This has already been done, by the old Internet address allocation stuff. We're stuck, now... our 2 local commercial ISPs both say potential customers frequently ask them if they're multiply connected. Do the customers say *why* they want them multihomed? Do they know what the cases of service outages are, based on a statistical breakdown of outages? I suspect this multi-homing is just another uninformed checkoff mantra, but one that isn't a real solution, just like ISO was some years ago. Not trying to minimize the problems, just want to make sure we solve the real problem, not some other "problem" that we think is the problem, and looks easy to solve. Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 17:10:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27907; Tue, 5 Sep 1995 17:10:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA09004; Tue, 5 Sep 1995 14:15:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA08760; Tue, 5 Sep 1995 13:39:51 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17370; Tue, 5 Sep 1995 13:38:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26207; Mon, 4 Sep 95 23:38:35 -0400 Date: Mon, 4 Sep 95 23:38:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509050338.AA26207@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur The assumption that everyone will move and if they move they will want to take their addresses with them. Well, if most people won't move, and many of those who do won't take their addresses with them, then we don't have a problem. Good, we can all go home. > Everyone is seeing this capabiltiy of taking an address with you as a > right, and I think that's the wrong model, since if everyone does it, the > routing will fall over. So, it's not a right, it's a privilege. Who are YOU to decide if it is a right or privilege? You keep acting like I'm the one setting, or trying to set, the constraints. You're shooting the messenger. If I went off to Tahiti and was never heard from again, that *still* wouldn't let everyone move and take their address with them, or be widely multihomed with optimal routing at all times, or whatever. It has nothing to do with me, although you don't seem to be able to comprehend that (for reasons I won't speculate on, 'cause DCrocker says it's unprofessional, although I gather from the private comments I've received that most everyone else on the list has their own opinion already), so I'll give up trying to explain it. >> If you read the original IP number documents, it was stated in a manner >> like that. > The people who did that didn't understand that they were writing > something bogus. It does not matter. Unless the Internet goes bankrupt, the original guarantees are valid and all who inherit the Internet have to uphold them. I hope everyone else is as amused by the concept of the Internet going bankrupt as I am. Just out of interest, do you have any idea how ridiculous you're making yourself look? I really don't need to say a thing, you're doing a fantastic job all on your own. > I can write an offical document that says that I'll sell you a perpetual > motion machine for $10, but that doesn't mean I can follow through with > it. You can go to jail for fraud for trying to sell me a perpetual motion machine for $10. Perhaps (I'm not up on fraud law). That doesn't invalidate what I said, though. > To do that, we have to look at what is *feasible*, not what somebody who > didn't understand what they were saying promised. A lot of organizations make that mistake when starting out and have to live with them and not repudiate them. Ah, so all those jailed people who promised to sell perpetual motion machines were forced to keep their promise, eh? But the Internet is NOT a perpetual motion machine. It WORKS now and there ARE way to keep it working If we only wanted an Internet the size of the current one, we'd be fine. Problem is we want a *bigger* Internet. Something that works fine at one level of scale doesn't work at another, which is why insects and vertebrates have very different physiology when it comes to blood, gas exchange, etc. that involve different router technology that you refuse to acknowledge. So, go build them and make a fortune. My solution: Encourage organizations to renumber when changing providers. Do NOT force them to renumber. What do you do if not enough people renumber voluntarily? Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 17:12:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27968; Tue, 5 Sep 1995 17:12:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA08967; Tue, 5 Sep 1995 14:08:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA08763; Tue, 5 Sep 1995 13:39:58 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17426; Tue, 5 Sep 1995 13:39:51 +1000 (from mn@tremere.ios.com) Received: from tremere.ios.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA07485 Tue, 5 Sep 1995 13:39:46 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id XAA01787; Mon, 4 Sep 1995 23:39:50 -0400 Date: Mon, 4 Sep 1995 23:39:49 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Discussing encap/mapping proposal To: Noel Chiappa Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9509041840.AA24747@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk it knows where G is. If no load sharing is required, i.e. A and B are only announced once by G, this is all it needs. If G wants to announce A and B on multiple exits, G must define multiple paths for it. That's where the tag charge can come in. It is a phone system where the same user is reachable under two prefixes. The entity behind the prefixes takes care that then that address is unique under both tags, G and H. The whole address is available at all levels of this hierarchy. In case of multiple paths, it is necessary to evaluate also the next lower layer to define the exit point. In non multi homed cases, only the highest level of the address needs to be looked at, which is stripped at the transit point from the upline provider to the downlind provider. Difficult to clarify without drawing board. When I thought it through, I did not need to evaluate more than the highest or the next lower level at each point in the address hierarchy. And at each level the algorithms are exactly the same. Treenodes. Mike On Mon, 4 Sep 1995, Noel Chiappa wrote: > From: "Michael F. Nittmann" > > do route name tagging in the router, so that wherever I plug the router > in, I tag the route name with a geographical tag and voila, we have full > aggregation. > > I was unable to follow for sure that brief description. I'll go with what I > can glean, and if I went wrong, perhaps you can elaborate on your scheme. > > If you have two routes to otherwise dissimilar addresses, A and B, which have > the same geographic tag G, how do you aggregate those two routes? In other > words, at some distant router, which no longer has A or B in its routing > table, how does it tell that A is at G? > > Noel > > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 17:17:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28113; Tue, 5 Sep 1995 17:17:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA09737; Tue, 5 Sep 1995 17:14:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA09719; Tue, 5 Sep 1995 17:06:03 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27666; Tue, 5 Sep 1995 17:05:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27454; Tue, 5 Sep 95 03:05:47 -0400 Date: Tue, 5 Sep 95 03:05:47 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509050705.AA27454@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Sanjay Kapur My father always told me that a true expert can explain anything in their area of expertise to a lay man succinctly. Oh, but I can do that, viz.: The names used by the routing have to be aggregable for the overhead of routing (e.g. routing table size) to scale reasonably in a large net; i.e. a single routing table entry has to be able to stand for a number of hosts (and the bigger the network, the more hosts). If they are aggregable, that means they have to change when you move to a different location in the network; that's because the things they can be aggregated with have changed, they are no longer next the things they used to be next to. If you don't like that characteristic of routing-names, then you have to provide *another* set of names which don't have this characteristic, and map them into routing-names. The IETF declined, some years ago, to do this, with the result that IPv4 addresses are still routing-names. Hence, IPv4 addresses have to change when you move to a new location in the network. I've succeded in explaining this, quite well, to a number of reports, who aren't exactly deeply technical. The problem is that you seem to refuse to accept this explanation, and keep looking for a way out. However, all the ones you suggest have been tried already, and don't work. In fact, there is good reason to think that no escape can exist. A true expert may be able to explain anything in their area of expertise to a lay person succinctly, but I'm not sure that when the lay person says that the expert is wrong, the expert can always explain to the lay person why they are mistaken quite as easily. E.g. try getting a physicist to explain the EPR paradox to you, and then insist that Einstein was right, and Bohr was wrong, or try telling a mathematician that the proof of the Four-Color theorem is wrong. I just believe that experts, especially those of the intellectual variety, should be consultants to the real decision makers. Ah. Just out of interest, who do you think think it is who is (or ought to be) the "real decision maker" for the Internet? Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 18:38:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01931; Tue, 5 Sep 1995 18:38:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA09852; Tue, 5 Sep 1995 18:34:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA09829; Tue, 5 Sep 1995 18:14:50 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00952; Tue, 5 Sep 1995 18:14:46 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19163 Tue, 5 Sep 1995 18:14:24 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA21149; Tue, 5 Sep 1995 01:12:40 -0700 Date: Tue, 5 Sep 1995 01:12:40 -0700 From: Tony Li Message-Id: <199509050812.BAA21149@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Subject: Re: Charging for routes... Precedence: bulk The distributed design of the Cisco 7500 further extends this idea, with an RP and SSE on the same board, capacity for two such boards such that you can load share CPU's, plus VIP cards that have a sub-IOS on them that grab routing information from the main RP, you have a much better solution than any kind of Unix based workstation/route calculator. Just to be _extremely_ picky, the 7500 does NOT include an SSE. Yes, it still provides distributed switching. Tony From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 18:46:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02252; Tue, 5 Sep 1995 18:46:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA09883; Tue, 5 Sep 1995 18:44:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA09832; Tue, 5 Sep 1995 18:18:21 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01102; Tue, 5 Sep 1995 18:18:08 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19291 Tue, 5 Sep 1995 18:17:41 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA21200; Tue, 5 Sep 1995 01:16:25 -0700 Date: Tue, 5 Sep 1995 01:16:25 -0700 From: Tony Li Message-Id: <199509050816.BAA21200@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Subject: Re: Charging for routes... Precedence: bulk > And if they all collude, we'll be at the federal courthouse 5 minutes later, > hopefully with a bunch of other ISPs to file that restraint-of-trade > lawsuit as a class action. Why, because they didn't all pitch in for the good of the Internet, and adopt a certain pricing strategy based on routes? That's what Avi was talking about. Rather, you seem to imply that if they did all adopt a policy for charging based on routes, you'd take them to court. Which is it, and what's your basis? I suspect it would be the latter. It would be for price fixing under the Taft-Hartley (?) Anti-Trust act. And it would be an extremely strong case, because it would probably be true given the scenarios discussed. Any single provider may decide to charge, but each must be prepared to show that all pricing decisions were made in isolation of other providers. Tony p.s. I'm not a lawyer and I shower after talking to them. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 19:18:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03362; Tue, 5 Sep 1995 19:18:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA09934; Tue, 5 Sep 1995 19:14:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA09917; Tue, 5 Sep 1995 18:56:29 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02617; Tue, 5 Sep 1995 18:56:17 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from rodent.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 5 Sep 1995 09:56:02 +0100 To: big-internet@munnari.OZ.AU Subject: Re: Charging for routes... In-Reply-To: Your message of "Tue, 05 Sep 95 01:16:25 PDT." <199509050816.BAA21200@greatdane.cisco.com> Date: Tue, 05 Sep 95 09:56:00 +0100 Message-Id: <485.810291360@cs.ucl.ac.uk> From: Jon Crowcroft Precedence: bulk of course, a short term charge associated with a route has existed in another placve for some time its called connection oriented networking... j. From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 19:37:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03936; Tue, 5 Sep 1995 19:37:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA09969; Tue, 5 Sep 1995 19:34:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA09965; Tue, 5 Sep 1995 19:28:23 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03780; Tue, 5 Sep 1995 19:28:14 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id CAA21041; Tue, 5 Sep 1995 02:28:08 -0700 From: Dave Siegel Message-Id: <199509050928.CAA21041@seagull.rtd.com> Subject: Re: Charging for routes... To: tli@cisco.com (Tony Li) Date: Tue, 5 Sep 1995 02:28:07 -0700 (MST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199509050816.BAA21200@greatdane.cisco.com> from "Tony Li" at Sep 5, 95 01:16:25 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 955 Precedence: bulk > Rather, you seem to imply that if they did all adopt a policy for > charging based on routes, you'd take them to court. > > I suspect it would be the latter. It would be for price fixing under > the Taft-Hartley (?) Anti-Trust act. And it would be an extremely > strong case, because it would probably be true given the scenarios > discussed. That was my point, though. It would be too much of a competition edge to not charge based on routes, when all your primary competitors are. I can't imagine management at any of these places okay'ing this concept. And if they did, it wouldn't be such a bad thing. Naturally, a fixed cost would never work. Marketing would have a field day, though, that's for sure. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 19:57:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04571; Tue, 5 Sep 1995 19:57:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA10008; Tue, 5 Sep 1995 19:54:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA09977; Tue, 5 Sep 1995 19:36:31 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03929; Tue, 5 Sep 1995 19:36:28 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id CAA22215; Tue, 5 Sep 1995 02:35:50 -0700 Date: Tue, 5 Sep 1995 02:35:50 -0700 From: Tony Li Message-Id: <199509050935.CAA22215@greatdane.cisco.com> To: dsiegel@rtd.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <199509050928.CAA21041@seagull.rtd.com> (message from Dave Siegel on Tue, 5 Sep 1995 02:28:07 -0700 (MST)) Subject: Re: Charging for routes... Precedence: bulk That was my point, though. It would be too much of a competition edge to not charge based on routes, when all your primary competitors are. I can't imagine management at any of these places okay'ing this concept. Depends. If we do get to the point where they see their networks threatened by the amount of routing information, they may start filtering. Then those that want holes in those filters may be encouraged to pay... this works out to be Noel's auction mechanism, tho in a less clean format. Tony From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 20:55:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06452; Tue, 5 Sep 1995 20:55:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA10080; Tue, 5 Sep 1995 20:54:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA10074; Tue, 5 Sep 1995 20:43:54 +1000 Received: from newdev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06118; Tue, 5 Sep 1995 20:43:50 +1000 (from sob@harvard.edu) Received: (from sob@localhost) by newdev.harvard.edu (8.6.9/8.6.9-MT2.02) id GAA10666; Tue, 5 Sep 1995 06:43:35 -0400 (EDT) Date: Tue, 5 Sep 1995 06:43:35 -0400 (EDT) From: Scott Bradner Message-Id: <199509051043.GAA10666@newdev.harvard.edu> To: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Subject: Re: Multihoming and CIDR Cc: big-internet@munnari.OZ.AU Precedence: bulk > Is the whole internet currently not a bandaid? As long as the bandaid works till IPv6 saves the day, what is wrong with it? IPv6 has no new concepts here other than trying to make it easer to renumber as transparently as possible, cidr-type address assignment and renumbering as the topology of the net changes will still be the order of business. Scott From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 21:14:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07052; Tue, 5 Sep 1995 21:14:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA10130; Tue, 5 Sep 1995 21:14:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA10124; Tue, 5 Sep 1995 21:12:01 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06906; Tue, 5 Sep 1995 21:11:54 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id HAA15568 for ; Tue, 5 Sep 1995 07:11:47 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id HAA11860 for ; Tue, 5 Sep 1995 07:16:16 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA13809; Tue, 5 Sep 95 07:21:40 EDT Message-Id: <9509051121.AA13809@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Sep 1995 07:08:29 -0400 To: Scott W Brim , big-internet@munnari.OZ.AU From: Robert Moskowitz Subject: Re: Discussing encap/mapping proposal Precedence: bulk At 10:17 PM 8/30/95 -0400, Scott W Brim wrote: > >At 07:28 08/29/95, Robert Moskowitz wrote: > >Would this still hold true if the only multihoming is at established 'NAP's? > >In otherwords. Only those providers that can afford to hookup to and peer > >at NAPs can multihome. All others cannot. > >The only reason multihoming is an issue is because customers apparently >do not feel that they can depend on a single provider to be reliable >enough for them. Your idea would severely limit the amount of >multihoming, since customers wouldn't be able to afford it, but >allowing customers to make cost-effective use of the Internet would >seem to be an important goal. 'Soory' I am running so far behind, I am suffering from a dying HD. New one enroute... I meant multihoming among providers only. Not end clients. Only those ISPs that can afford to connect to NAPs, multihome. Or perhaps they can not multihome between upstream providers. ?? Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 21:56:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08441; Tue, 5 Sep 1995 21:56:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA10219; Tue, 5 Sep 1995 21:56:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA10177; Tue, 5 Sep 1995 21:43:09 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07920; Tue, 5 Sep 1995 21:42:50 +1000 (from rgm3@is.chrysler.com) Received: from sg543689.eng.chrysler.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA25165 Tue, 5 Sep 1995 21:42:31 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id HAA20201 for ; Tue, 5 Sep 1995 07:41:13 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id HAA11957 for ; Tue, 5 Sep 1995 07:45:42 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA13935; Tue, 5 Sep 95 07:50:49 EDT Message-Id: <9509051150.AA13935@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Sep 1995 07:37:39 -0400 To: Sanjay Kapur , Noel Chiappa From: Robert Moskowitz Subject: Re: Discussing encap/mapping proposal Cc: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Precedence: bulk At 11:50 PM 8/31/95 -0400, Sanjay Kapur wrote: >Has anyone looked at how FCC had to force 800 number portability in the >US and is now expanding that into local telephone number portability? >Customers have demanded this and eventually FCC and the Telcos are >implementing it. > >The analogy to IP providers is that eventually such portability will >have to be retrofitted if it is not provided for in the original design. > >Will the IP community have to relearn the lessons of the telephone community? Phone numbers equate to domain names, and as such we already have protability in most cases. We need to expand the use of domain names and add discovery services that will eliminate the need for any hard coding of addresses. See IPv6 for this work. People view IP addresses like phone numbers for a few reasons, such as the difficulty in getting them, the current hardcoding pactices, and the hype of the scarcity of them. We are doing little to address the causes, spending all of our energy on the effects... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 21:57:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08486; Tue, 5 Sep 1995 21:57:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA10241; Tue, 5 Sep 1995 21:57:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA10180; Tue, 5 Sep 1995 21:52:21 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08157; Tue, 5 Sep 1995 21:52:15 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id HAA01824; Tue, 5 Sep 1995 07:52:53 -0400 Date: Tue, 5 Sep 1995 07:52:52 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Charging for routes... To: Karl Denninger Cc: Avi Freedman , root@kbs.netusa.net, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <199509050229.VAA00620@Jupiter.mcs.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Karl Denninger wrote: > > > > One issue: As with traditional settlement talks, all it takes is one large > > > > player to not go along with the thing and it falls apart. > > > > > > > > Avi > > > > > > > > > > One word: CIX > > > > > > Sanjay Kapur > > > Kapur Business Systems, Inc. > > > > I don't think the CIX really matters at this point. I was talking about > > entities who have exclusive routes to a critical mass of the net. > > > > {Sprint, MCI, ANS, Alternet, PSI, Net99/AGIS} come to mind. Any one of them > > not going along with a settlement (bandwdith-or-route-related) plan would > > scuttle the whole thing. > > > > Avi > > And if they all collude, we'll be at the federal courthouse 5 minutes later, > hopefully with a bunch of other ISPs to file that restraint-of-trade > lawsuit as a class action. not even: the first lawyer who smell the bait. 'on behalf of' gives him 'reasonable expenses' plus 1/3 of everything that eventually comes out of it. Mike > > -- > -- > Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity > Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland > Voice: [+1 312 803-MCS1] | 7 Chicagoland POPs, ISDN, 28.8, much more > Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net > ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 22:15:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08929; Tue, 5 Sep 1995 22:15:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA10287; Tue, 5 Sep 1995 22:14:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA10267; Tue, 5 Sep 1995 22:09:24 +1000 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08840; Tue, 5 Sep 1995 22:09:17 +1000 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id IAA23158; Tue, 5 Sep 1995 08:09:05 -0400 From: Avi Freedman Message-Id: <199509051209.IAA23158@netaxs.com> Subject: Re: Charging for routes... To: mn@ios.com (Michael F. Nittmann) Date: Tue, 5 Sep 1995 08:09:03 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: from "Michael F. Nittmann" at Sep 5, 95 07:52:52 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1828 Precedence: bulk >>> I don't think the CIX really matters at this point. I was talking about >>> entities who have exclusive routes to a critical mass of the net. >>> >>> {Sprint, MCI, ANS, Alternet, PSI, Net99/AGIS} come to mind. Any one of them >>> not going along with a settlement (bandwdith-or-route-related) plan would >>> scuttle the whole thing. >>> >>> Avi >> >>And if they all collude, we'll be at the federal courthouse 5 minutes later, >>hopefully with a bunch of other ISPs to file that restraint-of-trade >>lawsuit as a class action. > > not even: the first lawyer who smell the bait. 'on behalf of' gives him > 'reasonable expenses' plus 1/3 of everything that eventually comes out of it. > > Mike Right, but it's possible that the large transit providers would independently decide that their continued business operation (according to the model they'd like to see) depends on putting a price on {bandwidth, routing table space, etc...}. In that case, if there actually *is* no collusion: (a) Any one of the large providers (who have exclusive routes to many important places) not going along (whose model dictates flat-rate metrics) would scuttle it for the others (b) There might/would be a large, very very critical mass of the 'net that would go another way. There are regional providers with T3s between cities now and very strong no-settlement feelings. Many are disturbed that the "model" of some of the large transit providers is moving towards "we must be able to support live video and business-leased-line-quality service over the Internet, even if it means changing the pricing model of the Internet". But the routing-based settlement issue is different, and I think everyone's hoping a reasonable technical/political compromise can be reached on it. Avi From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 22:16:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09092; Tue, 5 Sep 1995 22:16:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA10307; Tue, 5 Sep 1995 22:16:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA10259; Tue, 5 Sep 1995 21:58:58 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08506; Tue, 5 Sep 1995 21:58:56 +1000 (from huitema@pax.inria.fr) Received: from sophia.inria.fr by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA25478 Tue, 5 Sep 1995 21:57:16 +1000 (from huitema@pax.inria.fr) Received: from [138.96.8.86] by sophia.inria.fr (8.6.12/8.6.12) with SMTP id NAA23890; Tue, 5 Sep 1995 13:49:06 +0200 Date: Tue, 5 Sep 1995 13:49:06 +0200 X-Authentication-Warning: sophia.inria.fr: Host sophmaccdc6.inria.fr claimed to be [138.96.8.86] Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Scott Bradner From: huitema@pax.inria.fr (Christian Huitema) Subject: Re: Multihoming and CIDR Cc: big-internet@munnari.OZ.AU Precedence: bulk At 6:43 AM 5/9/95, Scott Bradner wrote: >> Is the whole internet currently not a bandaid? As long as the bandaid >works till IPv6 saves the day, what is wrong with it? > >IPv6 has no new concepts here other than trying to make it easer to >renumber as transparently as possible, cidr-type address assignment >and renumbering as the topology of the net changes will still be >the order of business. > >Scott Actually, IPv6 does have three notions which could help us solve several of the problem we are currently discussing. The first notion is provider addresses. The initial addresses will be provider based, with a format of . This should bring smiles to the faces of all of you, conspirators, who want to force CIDR down our throat. The smile may fade when you realize that Mom and Pop ISP will end up asking for a provider ID, but this is another story. The second notion is indeed dynamic addressing allocation. There are indeed some gory details, such as how do we exactly interface with the DNS, but the basis is that one can change addresses on the whole network by the turn of a key. One can also manage obsolescence of addresses, or rather "deprecation". The third notion is the relaxation of the "one address per interface" constraint. An address may have several interfaces, a subnet may have several prefixes. In particular, it may have several prefixes that only differ by the tupple. These multiple prefixes may generate multiple addresses through the dynamic addressing allocation procedures. Indeed, there will be some later developments, e.g. a version fo gethostbyname (or name2address) that sorts the list of addresses by "prefered provider of the day". But IPv6 has the basic support which is required for multi-homing. So the solutio may well be to expedite the transition as soon as possible. By the way, you could take a look at http://www.cernet.edu.cn/ which details another real good incentive for moving to IPv6... Christian Huitema From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 22:18:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09147; Tue, 5 Sep 1995 22:18:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA10332; Tue, 5 Sep 1995 22:18:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA10281; Tue, 5 Sep 1995 22:12:19 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08868; Tue, 5 Sep 1995 22:12:07 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id IAA25264 for ; Tue, 5 Sep 1995 08:11:53 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id IAA12175 for ; Tue, 5 Sep 1995 08:16:23 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA16114; Tue, 5 Sep 95 08:21:35 EDT Message-Id: <9509051221.AA16114@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Sep 1995 08:08:25 -0400 To: Masataka Ohta , tli@cisco.com (Tony Li) From: Robert Moskowitz Subject: Re: Multihoming Cc: mn@ios.com, big-internet@munnari.OZ.AU Precedence: bulk At 03:48 PM 9/1/95 JST, Masataka Ohta wrote: > >Of course, what we need is the global reachability. > >For people communicating worldwide, mere local reachability is just >meaningless. I work at a small auto company with its home office in Detroit.... Being small, we long ago realized that a master contract with a moderate sized telco would reduce all of our comm costs, both voice and data. After 6 months of bidding, it was awarded to a smallish provider that made its initial mark in the comm world in the microwave business (i think their name still has 'microwave' buried in it somewhere). Any remote site that needs highly reliable connectivity gets normally 3 T1s for starters. One to the nearest CO for our provider (through the local RBOC), one via microwave to that same CO, and one to another CO. All of these T1s are managed through a T1 switch. The routers (highly redundant units from a major router manufacturer) see this as one connection. We have rarely suffered a loss (other than that famous Myland fiber cut a while back that took out almost everything in SE Mi, ah what one backhoe can do....). For those sites where a single T1 is inadequate, we run a second line. This is not multipathed like the first, as we feel in such a disaster we can run a little slower. For our sites in our metro, we use fiber rings, SMDS, raw SONET, and other such technology. The energy to maintain this central core is considerable. BTW, a plant can be disconnected for about 5 min before very top management kicks in. Around 10 min the decisions have to be made. By 15 min you send the whole shift home; you figure the cost. The last time this happened was 2 years ago, caused by a SNI problem, not IP. Multihoming is VERY important. But you have to look at the total TELCO picture and solve the problem at the proper level(s). For example, we do not design for earthquakes, just backhoes and angry unions... (hey, did I ever relate how good a shot union workers can be with staple guns, targeting overhead broadband cables??? They say it was a great way to get an extra break on a hot day...) Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 22:19:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09199; Tue, 5 Sep 1995 22:19:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA10354; Tue, 5 Sep 1995 22:19:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA10264; Tue, 5 Sep 1995 21:59:53 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08524; Tue, 5 Sep 1995 21:59:46 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id IAA01832; Tue, 5 Sep 1995 08:01:48 -0400 Date: Tue, 5 Sep 1995 08:01:47 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Multihoming To: Dave Siegel Cc: Sanjay Kapur , dsiegel@rtd.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <199509050455.VAA02920@seagull.rtd.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Dave Siegel wrote: > > > That is a completely unrealistic analogy. Let's try a different one. > > > You must get your phone service from a phone company, but if you choose > > > not to buy phone service, you are still free to buy phones. > > > "Hey, look at this nifty intercom system we've got." > > > > If you are bringing in the phone company (again) the analogy should be in > > being able to take your 800 number with you when you switch phone > > companies. And you know what? You can. The internet is like 800 number > > service more than like local telephone service anyway. > > An 800 number is the equivalent of a domain name. A local telephone number > is the equivalent of an IP address. The 800 number can map to any local > telephone number, but if you move locations, you may have to get a different wait: moving isps are not as to be understood isp's that change geographical location, but isps that change uplineprovider. And if I change my long distance carrier 10 times a month, Istill keep my number. That's the point here! stop doing junk analogies , please. Mike > phone number, and you will have to have the phone company remap your 800 > number to your new local phone number. > > Such is the concept behind renumbering. If you change your location in > virtual space, you may have to change your IP address, but you can still > remap your domain name to your new IP address. > > Dave > > -- > Dave Siegel President, RTD Systems & Networking, Inc. > (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco > dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, > http://www.rtd.com/ for an ISP." > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 22:35:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09718; Tue, 5 Sep 1995 22:35:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA10417; Tue, 5 Sep 1995 22:35:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA10387; Tue, 5 Sep 1995 22:25:31 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09371; Tue, 5 Sep 1995 22:25:17 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id IAA01851; Tue, 5 Sep 1995 08:27:27 -0400 Date: Tue, 5 Sep 1995 08:27:27 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Multihoming To: Robert Moskowitz Cc: Masataka Ohta , Tony Li , big-internet@munnari.OZ.AU In-Reply-To: <9509051221.AA16114@clncrdv1.is.chrysler.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk like your staple gun story! another worry,though: now we need sheaths and tubing. thanks for the hint. Mike ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 22:36:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09795; Tue, 5 Sep 1995 22:36:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA10439; Tue, 5 Sep 1995 22:36:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA10392; Tue, 5 Sep 1995 22:31:27 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09635; Tue, 5 Sep 1995 22:31:25 +1000 (from rgm3@is.chrysler.com) Received: from sg543689.eng.chrysler.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26208 Tue, 5 Sep 1995 22:31:05 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id IAA28034 for ; Tue, 5 Sep 1995 08:29:36 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id IAA12335 for ; Tue, 5 Sep 1995 08:34:07 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA18201; Tue, 5 Sep 95 08:39:23 EDT Message-Id: <9509051239.AA18201@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Sep 1995 08:26:13 -0400 To: "Michael F. Nittmann" , Tony Li From: Robert Moskowitz Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk At 08:20 AM 9/1/95 -0400, Michael F. Nittmann wrote: >On Thu, 31 Aug 1995, Tony Li wrote: > >> >> Michael, >> >> Just to be specific, we're talking large scale geographic diversity. >> Not just the next provider over. > >large scale like X.com, Inc, with a fully owned network of Ts from the >west coast to the east coast? Or just NSPs that peer at multiple meetpoints? > >I could not find in my message the 'next provider over'. > >Of course, such a large scale entity could then split their network , >renumber some thousand hosts, and run bgp internally against the two >halves that are connected to two different providers.;-( Been there. Had to do it. Not for public connectivity, just for managing our internal network. Of course we only needed BGP3 internally, for now anyway... Tech Center is 152.116/16, CFC is 162.12/16 (that was clean, at least), Manuf is 151.171/16 (big job), corp sites are 129.9/16, and lots of 1597 nets scattered around... You see, we were seeing router table explosion internally and the Dykstra calcs even on Bay routers was getting to be no fun. Of course we also have to route IPX so the routers were doing double duty with the routing flabs. Actually, Bay was handling it, but the Tymplexs were being severly challenged... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 22:38:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09928; Tue, 5 Sep 1995 22:38:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA10459; Tue, 5 Sep 1995 22:37:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA10325; Tue, 5 Sep 1995 22:17:46 +1000 Received: from Kitten.mcs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09123; Tue, 5 Sep 1995 22:17:34 +1000 (from karl@Mcs.Net) Received: from Jupiter.mcs.net (Jupiter.mcs.net [192.160.127.89]) by kitten.mcs.com (8.6.10/8.6.9) with ESMTP id HAA28645; Tue, 5 Sep 1995 07:17:25 -0500 Received: (from karl@localhost) by Jupiter.mcs.net (8.6.11/8.6.9) id HAA03432; Tue, 5 Sep 1995 07:16:55 -0500 From: Karl Denninger Message-Id: <199509051216.HAA03432@Jupiter.mcs.net> Subject: Re: Charging for routes...u To: dsiegel@rtd.com (Dave Siegel) Date: Tue, 5 Sep 1995 07:16:55 -0500 (CDT) Cc: karl@Mcs.Net, freedman@netaxs.com, root@kbs.netusa.net, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <199509050350.UAA28251@seagull.rtd.com> from "Dave Siegel" at Sep 4, 95 08:50:14 pm X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 1953 Precedence: bulk > > > > I don't think the CIX really matters at this point. I was talking about > > > entities who have exclusive routes to a critical mass of the net. > > > > > > {Sprint, MCI, ANS, Alternet, PSI, Net99/AGIS} come to mind. Any one of them > > > not going along with a settlement (bandwdith-or-route-related) plan would > > > scuttle the whole thing. > > > > And if they all collude, we'll be at the federal courthouse 5 minutes later, > > hopefully with a bunch of other ISPs to file that restraint-of-trade > > lawsuit as a class action. > > Why, because they didn't all pitch in for the good of the Internet, and adopt > a certain pricing strategy based on routes? That's what Avi was talking > about. > > Rather, you seem to imply that if they did all adopt a policy for charging > based on routes, you'd take them to court. > > Which is it, and what's your basis? > > Dave Neither. Collusive behavior in pricing between parties that as a group constitute a significant market force is a per-se violation of the Sherman act. Read the law sometime; if you're in any line of business, its a good thing to know. I'll be posting my treatise on peering, settlements, and the like soon. The "Big guys" aren't going to like this, but with Gordon spouting off at the mouth again, and a number of folks out there being real quiet (and possibly holding their meetings behind closed doors) its time for the ISPs of the world to know what's going on, what you're planning, and start working on forming a cohesive force to *stop it*. One way or another. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 803-MCS1] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! From owner-Big-Internet@munnari.OZ.AU Tue Sep 5 22:55:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10609; Tue, 5 Sep 1995 22:55:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA10495; Tue, 5 Sep 1995 22:54:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA10397; Tue, 5 Sep 1995 22:34:49 +1000 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09707; Tue, 5 Sep 1995 22:34:46 +1000 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id IAA23914; Tue, 5 Sep 1995 08:34:39 -0400 From: Avi Freedman Message-Id: <199509051234.IAA23914@netaxs.com> Subject: Re: Charging for routes... To: root@kbs.netusa.net (Sanjay Kapur) Date: Tue, 5 Sep 1995 08:34:38 -0400 (EDT) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 4, 95 11:06:51 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 437 Precedence: bulk > I really meant to say: > > Five words: Look at why CIX failed. > > CIX is/was a flat fee settlement system. > > Before we try to come up with a settlement system, we should look at a > recent attempt at one and avoid its mistakes. > > Sanjay Kapur > Kapur Business Systems, Inc. Well, the settlement system wasn't at fault, it was a board that didn't listen to the members, coupled with a lack of a CIX-router-east, etc... Avi From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 00:15:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14400; Wed, 6 Sep 1995 00:15:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA10604; Wed, 6 Sep 1995 00:14:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA10585; Tue, 5 Sep 1995 23:55:22 +1000 Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13186; Tue, 5 Sep 1995 23:55:03 +1000 (from hcb@clark.net) Received: (hcb@localhost) by clark.net (8.6.12/8.6.5) id JAA10428; Tue, 5 Sep 1995 09:54:53 -0400 From: Howard Berkowitz Message-Id: <199509051354.JAA10428@clark.net> Subject: Telephony (was geographic addressing) To: dsiegel@rtd.com (Dave Siegel) Date: Tue, 5 Sep 1995 09:54:52 -0400 (EDT) Cc: hcb@clark.net (Howard Berkowitz), big-internet@munnari.OZ.AU In-Reply-To: <199509050443.VAA02128@seagull.rtd.com> from "Dave Siegel" at Sep 4, 95 09:43:30 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1331 Precedence: bulk On your point that the telephone network makes thing work-- True, it works. But less flexibly than the sort of Internet we are discussing. It's basically a hierarchy of static routes, admittedly with preference among static routes, but still not dynamic. Until Signaling System #7 was introduced, there wasn't any practical way to carry dynamic routing. There still isn't any real way to generate dynamic routes in a standard way. Remember that adding a new "end host" (i.e., telephone) takes on the order of days, much of which is order processing. Inserting a new "router" (i.e., PABX) takes even longer, because it does need engineering. Changes to the addressing structure (i.e., new area codes) takes significant coordination time. Then there's the need for compliance with Judge Greene, etc. ( i.e., exterior policy routing at a fairly low level). Again, this is handled in the general case with static routing to one's prefferred interexchange carrier. Alternative providers can be accomodated with what might be called loose source routing (i.e., 1-0-ATT-0 prefixes). No question that the telephone network has a truly respectable tradition of reliability. In the Internet, we are trying to do something much more complex. In the midst of all the routing flames, there's something to be proud of. Howard From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 00:35:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15229; Wed, 6 Sep 1995 00:35:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA11010; Wed, 6 Sep 1995 00:34:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA11004; Wed, 6 Sep 1995 00:30:41 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15074; Wed, 6 Sep 1995 00:30:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28426; Tue, 5 Sep 95 10:30:33 -0400 Date: Tue, 5 Sep 95 10:30:33 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509051430.AA28426@ginger.lcs.mit.edu> To: dsiegel@rtd.com, hcb@clark.net Subject: Re: Telephony (was geographic addressing) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Howard Berkowitz the telephone network makes thing work ... it works. But less flexibly than the sort of Internet we are discussing. It's basically a hierarchy of static routes Err, minor correction. I belive that some of the IEC's use dynamic routing internally to their networks. (I seem to recall that one uses a LS algorithm - one borrowed from computer networking work, actually - I suppose because their routing probably takes load into account, so you want the thing with the shortest stabilization time. Since the network has about 200 switches total, this works fine.) However, your basic point, that the system as a whole basically uses static routing, is correct. No question that the telephone network has a truly respectable tradition of reliability. Yes. It's one that we couldo, *and should*, learn a lot from. They get very good reliability (i.e. how often is there a dial tone there?) without multihoming for dynamic fallback, dynamic routing, etc, etc. Noel From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 00:36:06 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15255; Wed, 6 Sep 1995 00:36:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA11035; Wed, 6 Sep 1995 00:35:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA11001; Wed, 6 Sep 1995 00:28:58 +1000 Received: from netrail.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15032; Wed, 6 Sep 1995 00:28:55 +1000 (from nathan@netrail.net) Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id KAA27721; Tue, 5 Sep 1995 10:28:49 -0400 Date: Tue, 5 Sep 1995 10:28:48 -0400 (EDT) From: Nathan Stratton To: Sanjay Kapur Cc: Noel Chiappa , big-internet@munnari.OZ.AU Subject: Re: Multihoming and CIDR In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 4 Sep 1995, Sanjay Kapur wrote: > I believe that the following model has been proposed many times by many > people: > > Have a routing switch and a routing computer as separate pieces of hardware. > > Store all possible routes in an array of size 256*256*256 (class C) in > the routing switch to make it as fast as possible. > > Have routing computations done on a separate piece of hardware that > updates this array through a fast link to the routing switch. The > routing switch does not need to be updated every time a new route comes > in to the routing computer. If the routing switch has 256 ports, the > size of the routing array would be 16MB and the time it takes to transfer > this information from the routing computer to the routing switch would be > about two seconds for a fast link. This could be done once a day and the > routing switch will be down for about two seconds per day while this happens. Can this be done now with a cisco 4000 and a 486 DX 3 100 with 128 megs or ram running gated? If so how would you set up the cisco and gated? Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 00:55:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15971; Wed, 6 Sep 1995 00:55:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA11105; Wed, 6 Sep 1995 00:54:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA11024; Wed, 6 Sep 1995 00:35:26 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15243; Wed, 6 Sep 1995 00:35:17 +1000 (from louie@uunet.uu.net) Received: from localhost by rodan.UU.NET with SMTP id QQzfws02900; Tue, 5 Sep 1995 10:35:01 -0400 Message-Id: To: Karl Denninger Cc: dsiegel@rtd.com (Dave Siegel), freedman@netaxs.com, root@kbs.netusa.net, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Charging for routes...u In-Reply-To: Your message of "Tue, 05 Sep 1995 07:16:55 CDT." <199509051216.HAA03432@Jupiter.mcs.net> Date: Tue, 05 Sep 1995 10:35:01 -0400 From: "Louis A. Mamakos" Precedence: bulk > I'll be posting my treatise on peering, settlements, and the like soon. > The "Big guys" aren't going to like this, but with Gordon spouting off at > the mouth again, and a number of folks out there being real quiet (and > possibly holding their meetings behind closed doors) its time for the > ISPs of the world to know what's going on, what you're planning, and start > working on forming a cohesive force to *stop it*. Plots and closed door meetings everywhere.. Don't look under the bed! Trying to argue, er, discuss these sorts of things in public, especially on the com-priv list where it usually comes up is pointless. If it doesn't make good press, folks are not interested in hearing about it and it's just a waste of time. The reason we're real quiet out here is that we actually have useful work to get done, and are building and expanding networks just as fast as we can. I'll leave it to the various arm-chair quarterbacks and hangers-on to report on what's `really' going on in the smokey back rooms. Oh, I forget; it's a no-smoking area now.. Louis Mamakos From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 01:15:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16805; Wed, 6 Sep 1995 01:15:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA11158; Wed, 6 Sep 1995 01:14:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA11143; Wed, 6 Sep 1995 01:02:54 +1000 Received: from foo-241-200.Ipsilon.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16243; Wed, 6 Sep 1995 01:02:47 +1000 (from minshall@servo.ipsilon.com) Received: from localhost.ipsilon.com (localhost.ipsilon.com [127.0.0.1]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id IAA23456; Tue, 5 Sep 1995 08:00:38 -0700 Message-Id: <199509051500.IAA23456@servo.ipsilon.com> X-Authentication-Warning: servo.ipsilon.com: Host localhost.ipsilon.com didn't use HELO protocol X-Mailer: exmh version 1.6beta 3/23/95 To: "Brian Carpenter CERN-CN" Cc: big-internet@munnari.OZ.AU Subject: Re: 1. core; 2. conformance Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 05 Sep 1995 08:00:38 -0700 From: Greg Minshall Precedence: bulk Brian, >>In other words, either addressing determines topology, or topology determines >>addressing. > Money determines topology. Lines mainly go in one at a time > in response to perceived operational problems (not only load) > as providers can manage to fund them. I think the net effect is > essentially random topology with a tendency to being provider- > based. Yes, the vast amount of wires are going to be installed as a result of money (and/or load, as someone else mentioned). However, the specific requirement of metro-addressing, say, is something like "no matter how ever many wires there are connecting random bits of the address space (within or between providers, say), there *MUST* be complete connectivity within a metro". This restriction does NOT restrict other connectivity, either "within" or "between" metros (which is, i think, what Scott Brim was saying in trying to explain my cryptic remarks). I believe that the bulk of the internet (wire) capacity will be provided by providers responding to money/load. As far as i can tell, nothing in the metro plan would prevent (or purport to prevent) that from occurring. I hope that makes more sense than my original posting. Greg From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 01:16:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16891; Wed, 6 Sep 1995 01:16:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA11182; Wed, 6 Sep 1995 01:16:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA11138; Wed, 6 Sep 1995 00:56:46 +1000 Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16026; Wed, 6 Sep 1995 00:56:40 +1000 (from hcb@clark.net) Received: (hcb@localhost) by clark.net (8.6.12/8.6.5) id KAA26875; Tue, 5 Sep 1995 10:56:26 -0400 From: Howard Berkowitz Message-Id: <199509051456.KAA26875@clark.net> Subject: Re: Telephony (was geographic addressing) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 5 Sep 1995 10:56:26 -0400 (EDT) Cc: dsiegel@rtd.com, hcb@clark.net, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, hcb@clark.net (Howard Berkowitz) In-Reply-To: <9509051430.AA28426@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 5, 95 10:30:33 am X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2979 Precedence: bulk > > From: Howard Berkowitz > > the telephone network makes thing work ... it works. But less > flexibly than the sort of Internet we are discussing. It's basically a > hierarchy of static routes > > Err, minor correction. I belive that some of the IEC's use dynamic routing > internally to their networks. (I seem to recall that one uses a LS algorithm - > one borrowed from computer networking work, actually - I suppose because their > routing probably takes load into account, so you want the thing with the > shortest stabilization time. Since the network has about 200 switches total, > this works fine.) Good point. Is there not a message here, however, that dynamic routing is needed only in the IXC "cores," and with -- in Internet terms -- a relatively small number of switches? I advise my clients that the best [data] networks often are the ones with the least routers exchanging dynamic routing updates; intelligent static and default routing can handle many customer [CUSTOMER! not ISP!] reliability needs with reduced overhead. > > However, your basic point, that the system as a whole basically uses static > routing, is correct. > > No question that the telephone network has a truly respectable tradition > of reliability. > > Yes. It's one that we couldo, *and should*, learn a lot from. They get very > good reliability (i.e. how often is there a dial tone there?) without > multihoming for dynamic fallback, dynamic routing, etc, etc. Exactly. I'm afraid the current discussion deals too much with solving customer reliability needs at the network layer, without considering telco techniques such as automatic T1 span switching, fallback switched services, local loop diversity, etc. These methods are invisible to the routing system. I was leading a routing seminar recently for a major IXC. In discussion of the reliability of their router network, they mentioned that they recently had had a backhoe cut of a major SONET ring--but the switch to backup paths was done fast enough that the longest user- perceptble loss of service was 55 milliseconds. They wanted to know if this would be a problem for the routers. I sniffled a bit; envy is like that. Perhaps more pertinent to the current discussion, this major IXC is also very reluctant to renumber any of its internal networks. Ironically, the telephony side of a big Internet player is very short on IP address space. Many of their user hosts do not understand VLSM, which is a practical problem. Acccording to the internal networking staff, however, the problem is primarily that their internal customer demand to have in justified why they need to renumber. For this purpose, I was asked repeatedly to give them words that would justify CIDR, in a couple of sentences, to a LAN administrator for a non-IP LAN just beginning to use IP. *sigh* It is for users like that I've drafted the tutorial I sent to the list last week. Howard From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 01:37:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17634; Wed, 6 Sep 1995 01:37:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA11219; Wed, 6 Sep 1995 01:34:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA11213; Wed, 6 Sep 1995 01:30:33 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17406; Wed, 6 Sep 1995 01:30:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28911; Tue, 5 Sep 95 11:29:12 -0400 Date: Tue, 5 Sep 95 11:29:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509051529.AA28911@ginger.lcs.mit.edu> To: dsiegel@rtd.com, tli@cisco.com Subject: Re: Charging for routes... Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Siegel It would be too much of a competition edge to not charge based on routes, when all your primary competitors are. Ah. I was not suggesting that providers charge their *customers* for carrying routes (at least not initially), but rather charge *other providers*. So, I don't see the competitive edge. Yes, if a single provider tries to do this, and all the rest say "Get Stuffed", it won't work; they will have the choice of no connectivity, or buckling under. But you can imagine all sorts of scenarios; e.g. it carries the basic CIDR blocks for all providers for free, just charges for the little portable routes. So, their customers would always be able to get to most places. Also, as Tony says, we could get a creeping sort of "charge per routing table entry" as people pay to get their stuff through routing filters. I dunno, it may never happen, but it makes sense to me. It ties the charges more directly to the resources being used, and economics seems to say that such systems are more efficient (and thus win in the end) since they allow people who are able to use less resources to be charged less. Noel From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 01:54:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18288; Wed, 6 Sep 1995 01:54:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA11257; Wed, 6 Sep 1995 01:54:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA11253; Wed, 6 Sep 1995 01:48:47 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18058; Wed, 6 Sep 1995 01:48:44 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id LAA00720 for ; Tue, 5 Sep 1995 11:48:33 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id LAA14704 for ; Tue, 5 Sep 1995 11:53:18 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA22190; Tue, 5 Sep 95 11:58:31 EDT Message-Id: <9509051558.AA22190@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Sep 1995 11:45:20 -0400 To: Sanjay Kapur , Noel Chiappa From: Robert Moskowitz Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU, mn@ios.com, jnc@ginger.lcs.mit.edu Precedence: bulk At 11:48 PM 9/1/95 -0400, Sanjay Kapur wrote: > >I have a very basic questions: > >Will routers with huge amounts of memory that allows array based routing >allow for a very large number of networks? > You have joined the discussion here rather late. Read the archives. The general view of many is: NO the view of the rest is: Then what else? Big array mapping does not appear to fix anything. Though some argue that they move the workload from the edge to the core. The counter is that the workload would surely break the core. Whatever the core is. But get the archive, just a quick hop down under to Robert's system, and read a little history. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 01:56:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18356; Wed, 6 Sep 1995 01:56:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA11290; Wed, 6 Sep 1995 01:56:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA11221; Wed, 6 Sep 1995 01:35:55 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17574; Wed, 6 Sep 1995 01:35:28 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id LAA27789 for ; Tue, 5 Sep 1995 11:34:08 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id LAA14294 for ; Tue, 5 Sep 1995 11:38:43 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA22059; Tue, 5 Sep 95 11:43:56 EDT Message-Id: <9509051543.AA22059@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Sep 1995 11:30:45 -0400 To: Scott Bradner , root@kbs.netusa.net, sob@newdev.harvard.edu From: Robert Moskowitz Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk At 09:47 PM 9/1/95 -0400, Scott Bradner wrote: > it is not all that hard to renumber a class C-sized net of 15 nodes > it is not all that hard to renumber a net if all the hosts get > their addresses from DHCP > the Internet will double in the next year (i.e. half of the net > of a year from now is not yet on, and in many of these > cases, not now running IP) > most of the new nets will be smallish < 100 hosts (my guess) > if the new nets are helped to set up their nets in a way (such as > using DHCP) to make renumbering easier, they will find > renumbering easier I am attempting to put my money where my mouth is on this one. Forget for a moment that I am writing this from inside a BIG network. At home I am setting up a business. Part of that business will be to teach small professionals how to get LAN connected to the Internet cost effectively (target of $200/mo for 24x7 for entry (varies by region, or rather Telco Tariffs)). I will want my clients to easily move from one provider to another according to their needs. I am looking at the reliablity issue from many sides. Multihoming is only one, and typically too expensive for this class of user. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 02:16:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19141; Wed, 6 Sep 1995 02:16:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA11329; Wed, 6 Sep 1995 02:14:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA11312; Wed, 6 Sep 1995 02:04:09 +1000 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18710; Wed, 6 Sep 1995 02:03:59 +1000 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id MAA01261; Tue, 5 Sep 1995 12:02:39 -0400 From: Avi Freedman Message-Id: <199509051602.MAA01261@netaxs.com> Subject: Re: Charging for routes... To: hcb@clark.net (Howard Berkowitz) Date: Tue, 5 Sep 1995 12:02:38 -0400 (EDT) Cc: big-internet@munnari.OZ.AU, freedman@netaxs.com (Avi Freedman) In-Reply-To: <199509051411.KAA14501@clark.net> from "Howard Berkowitz" at Sep 5, 95 10:11:23 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2013 Precedence: bulk >> (b) There might/would be a large, very very critical mass of the 'net that >> would go another way. There are regional providers with T3s between >> cities now and very strong no-settlement feelings. Many are disturbed >> that the "model" of some of the large transit providers is moving towards >> "we must be able to support live video and business-leased-line-quality >> service over the Internet, even if it means changing the pricing model >> of the Internet". But the routing-based settlement issue is different, >> and I think everyone's hoping a reasonable technical/political compromise >> can be reached on it. >> > > Do you see RSVP-style flow specification as a relatively quick > fix for this several problem? By specifying quality of service > on the initial flow reservation, the local provider might > route the non-live-video-and-business-leased-line traffic > over a less reliable tier than the presumably more expensive > large providers. Only the high-reliability flows would go up > to the what-we-used-to-call-core. > > Howard Well, I would see a separate core for the high-bandwidth or high-reliability data. I would think that if set up properly, the large providers would be able to participate in being key in both worlds (current Internet model and high-availability model). One thing that is sure is that if the large providers abandon the current Internet model totally that the regionals will connect to each other and there will be two nets. Note: I make no statement about whether the new interconnection would work or be viable long-term, but I suspect strongly that it would be. People understand that the route-space issue is a real one, but charging per-route on a multilateral basis may smell as bad as per-packet charging to the most religious among us. Besides, everyone wants to avoid negotiating with everyone else to carry their routes for $$$ - it's a large time sink for people who are already incredibly busy. Avi From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 02:35:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19818; Wed, 6 Sep 1995 02:35:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA11366; Wed, 6 Sep 1995 02:34:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA11349; Wed, 6 Sep 1995 02:20:41 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19286; Wed, 6 Sep 1995 02:20:36 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id MAA06165 for ; Tue, 5 Sep 1995 12:20:35 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id MAA15083 for ; Tue, 5 Sep 1995 12:25:11 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA22547; Tue, 5 Sep 95 12:30:05 EDT Message-Id: <9509051630.AA22547@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 05 Sep 1995 12:16:54 -0400 To: Sanjay Kapur , Tony Li From: Robert Moskowitz Subject: RE: Multihoming Cc: wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU Precedence: bulk At 08:36 PM 9/2/95 -0400, Sanjay Kapur wrote: >On Sat, 2 Sep 1995, Tony Li wrote: > >> >> If Internet service is going to reach the "consumer", it has to have >> reliability similar to or greater than telephone/cable/water/power or any >> other utility. >> >> Consumers will demand that level of reliability. And service providers will >> give it to them through features like multi-homing. >> >> Consumers are not going to multihome. Do you have two water lines to >> your house? >> >> Yes, the provider may be multihomed. That's a _very_ different case. > >In addition to piped water, my house does have a ground water pump in the >basement which has not been turned on for some time now but was in use >some decades back when piped water supply was not as reliable. Most likely because the ground water is now poluted because your neighborhood also use to have septic tanks. We have a major area here in SE Mi like that... >What gave you the idea that consumers will not be multihomed for >reliability? Twenty four hour dedicated connections for Internet >connectivity (or some other version of the Information Superhighway) to >the home is the next growth area for our Industry. As people get more >dependent on the Internet, they will demand reliability and the only way >that they can get it currently is multihoming. Bah hum crud! I will have a principle connection to my provider (ISDN, Cable, Radio, T1, etc) and a backup dial link. Just like we have been doing at for business dedicated lines for years. Why? cost. That phone drop will not cost me anything until I use it (provide it is not a separate line). You are trying to create a business opurtunity where none exist. Or rather where cheaper, proven methods exist. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 03:20:36 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21370; Wed, 6 Sep 1995 03:20:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA11441; Wed, 6 Sep 1995 03:17:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA11418; Wed, 6 Sep 1995 02:57:36 +1000 Received: from relay2.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20739; Wed, 6 Sep 1995 02:57:33 +1000 (from hal9001@panix.com) Received: from panix3.panix.com by relay2.UU.NET with SMTP id QQzfxb01675; Tue, 5 Sep 1995 12:56:50 -0400 Received: (from hal9001@localhost) by panix3.panix.com (8.6.12/8.6.12+PanixU1.1) id MAA18975; Tue, 5 Sep 1995 12:48:07 -0400 X-Sender: hal9001@popserver.panix.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Mac Eudora Pro 2.1.3 Date: Tue, 5 Sep 1995 12:48:07 -0400 To: "Michael F. Nittmann" From: "Robert A. Rosenberg" Subject: Re: Routing tables & what to do about them Cc: Andrew Partan , big-internet@munnari.OZ.AU Precedence: bulk At 09:44 9/4/95, Michael F. Nittmann wrote: >I would say, renumber by putting for this a NAT at a strategical >aggregation point in the network. Everything below is renumbered. I agree. Putting in a SIMPLE NAT on the links that need to be renumbered should take care of the situation. By "SIMPLE" I mean a one-for-one prefix mapping of the old prefix into/from a new prefix in the Provider's CIDR Block. How much overhead is there for a table look up to get the translation before forwarding the packet? It basically is only the same type of lookup that routers are doing NOW but with a much smaller table (ie: Only those prefixes being renumbered). From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 03:37:29 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21957; Wed, 6 Sep 1995 03:37:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA11487; Wed, 6 Sep 1995 03:34:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA11469; Wed, 6 Sep 1995 03:25:46 +1000 Received: from relay2.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21462; Wed, 6 Sep 1995 03:24:06 +1000 (from dave@corecom.com) Received: from tigger.jvnc.net by relay2.UU.NET with SMTP id QQzfxd08079; Tue, 5 Sep 1995 13:22:41 -0400 Received: from [192.67.239.213] (franklin-tty13.jvnc.net) by tigger.jvnc.net with SMTP id AA06431 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Tue, 5 Sep 1995 13:14:38 -0400 Date: Tue, 5 Sep 1995 13:14:38 -0400 X-Sender: corecom@tigger.jvnc.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: amolitor@anubis.network.com (Andrew Molitor), big-internet@munnari.OZ.AU From: dave@corecom.com (David M. Piscitello) Subject: Re: The Conspiracy - Precedence: bulk It's true. I've had dinner with them. They drool... All of them... At 9:33 PM 9/3/95, Andrew Molitor wrote: > You've found us out. We router vendors are a vicious cabal of >drooling idiots out to rule the world through superior CIDRisms or >something. Now you have to be silenced. Expect news reports of network >architects tied found tied to their equipment racks with their own >entrails. > > Tony: The Big Yellow Beetle Squeaks Defiance at Eight Bells. David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA USA 19025 dave@corecom.com 1.215.830.0692 is, probably, is *behind* part of the ISP. That way, >customers who want to renumebr and get out from behind the NAT box can. I think that a NAT on the link between the Customer and the ISP would be very cost effective and non-intrusive (ie: It would have no more overhead than a router or bridge does now). All it would need to do is take every ISP Packet that comes from the Customer side and replace the Customer Prefix with the ISP supplied CIDR Block Prefix (leaving the Host Part alone) before passing it on to the ISP (and vise-a-versa for packets coming from the ISP to the Customer). If the Customer as a /20 from InterNIC then it is given a /20 from the Provider's CIDR Block so there is a one-to-one mapping of the addresses. From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 03:46:50 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22296; Wed, 6 Sep 1995 03:46:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA11541; Wed, 6 Sep 1995 03:43:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA11447; Wed, 6 Sep 1995 03:20:47 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21372; Wed, 6 Sep 1995 03:20:36 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03257 Wed, 6 Sep 1995 03:16:19 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.38] (dial-cup2-8.iway.aimnet.com [204.118.88.38]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA18439; Tue, 5 Sep 1995 10:12:32 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Sep 1995 10:13:46 -0700 To: George Herbert From: Dave Crocker Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk At 11:15 AM 9/4/95, George Herbert wrote: >No. Announcement policies might potentially be a problem for Multihoming, >but CIDR proper is not. The proposal is for addresses to be acquired from upstream providers. This ties the address to that upstream provider. If you multi-home through another provider, you will cause an exception to the aggregation pattern. This is very, very expensive since it directly violates the intent of CIDR. This seems to make multihoming a problem for cidr proper. No? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 03:58:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22784; Wed, 6 Sep 1995 03:58:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA11582; Wed, 6 Sep 1995 03:55:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA11509; Wed, 6 Sep 1995 03:38:04 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21971; Wed, 6 Sep 1995 03:37:36 +1000 (from ses@tipper.oit.unc.edu) Received: (from ses@localhost) by tipper.oit.unc.edu (8.6.12/8.6.10) id NAA01470; Tue, 5 Sep 1995 13:34:42 -0400 Date: Tue, 5 Sep 1995 13:34:40 -0400 (EDT) From: Simon Spero To: Scott Bradner Cc: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net, big-internet@munnari.OZ.AU Subject: Re: Multihoming and CIDR In-Reply-To: <199509051043.GAA10666@newdev.harvard.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 5 Sep 1995, Scott Bradner wrote: > > IPv6 has no new concepts here other than trying to make it easer to > renumber as transparently as possible, cidr-type address assignment > and renumbering as the topology of the net changes will still be > the order of business. I think transparent renumbering counts as a fairly major concept in this context; if renumbering is cheap enough that it can take place several times a month, then aggregation becomes much more feasible. I don't think it's necessarily the best solution, but it does seem to be the best understood solution. (I would have prefered something closer to PIP, and with much more of an emphasis on using flows & on-demand route discovery, but I don't know if we really know how to build something like that yet. Maybe we'll all end up using Virtual Circuses anyway ) Simon // ATM, ATM, it's a twister! It's a twister! From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 04:18:24 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23508; Wed, 6 Sep 1995 04:18:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04337 Wed, 6 Sep 1995 04:18:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA11639; Wed, 6 Sep 1995 04:14:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA11619; Wed, 6 Sep 1995 04:04:03 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22958; Wed, 6 Sep 1995 04:03:58 +1000 (from yakov@cisco.com) Received: from hubbub.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04140 Wed, 6 Sep 1995 04:03:48 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id LAA22173; Tue, 5 Sep 1995 11:01:08 -0700 Message-Id: <199509051801.LAA22173@hubbub.cisco.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Tue, 05 Sep 95 12:58:05 EDT." <9509051658.AA29412@ginger.lcs.mit.edu> Date: Tue, 05 Sep 95 11:01:08 PDT From: Yakov Rekhter Precedence: bulk Noel, > Actually, the NAT solution has a painful problem I keep forgetting about: if > you have your IP addresses in configurations *elsewhere* in the net (e.g. > security filters, etc) a NAT box does you no good at all. You will have > changed addresses as far as they are concerned, even if internal to your site > you are stil using the old ones. And if folks build their security based on source IP addresses of the packets coming from the outside, they probably need to understand that IP addresses could be faked (and it is not even very hard to do). Yakov. From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 04:23:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23889; Wed, 6 Sep 1995 04:23:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA11671; Wed, 6 Sep 1995 04:22:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA11584; Wed, 6 Sep 1995 03:55:01 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22632; Wed, 6 Sep 1995 03:54:36 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03755 Wed, 6 Sep 1995 03:46:11 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.38] (dial-cup2-8.iway.aimnet.com [204.118.88.38]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA22030; Tue, 5 Sep 1995 10:42:01 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Sep 1995 10:43:14 -0700 To: Scott Bradner From: Dave Crocker Subject: Re: Geographinc addressing Cc: big-internet@munnari.OZ.AU Precedence: bulk At 8:28 PM 9/4/95, Scott Bradner wrote: >Supporters of geographinc addressing need to say how this interconnection >will come about. Scott, I agree with you. It is essential that any proposal pay attention to the full range of real-world issues and this is certain a good example. To ask a rhetorical question: does the same requirement for thoroughness apply to other proposals as well? The reason I'm asking and the implication of your answer are presumed to be obvious. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 04:27:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24077; Wed, 6 Sep 1995 04:27:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA11708; Wed, 6 Sep 1995 04:26:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA11604; Wed, 6 Sep 1995 03:58:34 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22775; Wed, 6 Sep 1995 03:58:26 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id KAA13907; Tue, 5 Sep 1995 10:56:20 -0700 From: Dave Siegel Message-Id: <199509051756.KAA13907@seagull.rtd.com> Subject: Re: Multihoming To: mn@ios.com (Michael F. Nittmann) Date: Tue, 5 Sep 1995 10:56:20 -0700 (MST) Cc: dsiegel@rtd.com, root@kbs.netusa.net, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: from "Michael F. Nittmann" at Sep 5, 95 08:01:47 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1033 Precedence: bulk > > An 800 number is the equivalent of a domain name. A local telephone number > > is the equivalent of an IP address. The 800 number can map to any local > > telephone number, but if you move locations, you may have to get a different > > wait: moving isps are not as to be understood isp's that change > geographical location, but isps that change uplineprovider. And if I > change my long distance carrier 10 times a month, Istill keep my number. > That's the point here! stop doing junk analogies , please. To be frank, I don't really care if you can twist the analogy to punch a hole in it. I'm trying to perfect a speech to give to my clients when I tell them they'll need to renumber. As Andrew pointed out, it's not a 1:1 relationship between voice and data. Things don't map out, exactly. -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 04:35:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24462; Wed, 6 Sep 1995 04:35:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA11733; Wed, 6 Sep 1995 04:32:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA11624; Wed, 6 Sep 1995 04:08:08 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23011; Wed, 6 Sep 1995 04:08:03 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id KAA21822; Tue, 5 Sep 1995 10:56:40 -0700 Message-Id: <199509051756.KAA21822@hubbub.cisco.com> To: "Robert A. Rosenberg" Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Tue, 05 Sep 95 12:48:23 EDT." Date: Tue, 05 Sep 95 10:56:39 PDT From: Yakov Rekhter Precedence: bulk Robert, > I think that a NAT on the link between the Customer and the ISP would be > very cost effective and non-intrusive (ie: It would have no more overhead > than a router or bridge does now). All it would need to do is take every > ISP Packet that comes from the Customer side and replace the Customer > Prefix with the ISP supplied CIDR Block Prefix (leaving the Host Part > alone) before passing it on to the ISP (and vise-a-versa for packets coming > from the ISP to the Customer). If the Customer as a /20 from InterNIC then > it is given a /20 from the Provider's CIDR Block so there is a one-to-one > mapping of the addresses. While giving the customer a /20 from the provider's CIDR block is sufficient, it may not be necessary. This is because the total number of hosts within the customer is likely to be less than 2^20, and the NAT that you described has to have 1-to-1 mapping for these hosts. So, for example if the total number of hosts within the customer is 255 (which means 6% address space utilization), you need to give the customer only /24 prefix (rather than /20). Yakov. From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 04:35:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24474; Wed, 6 Sep 1995 04:35:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA11744; Wed, 6 Sep 1995 04:35:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA11658; Wed, 6 Sep 1995 04:19:52 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23582; Wed, 6 Sep 1995 04:19:47 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.38] (dial-cup2-8.iway.aimnet.com [204.118.88.38]) by aimnet.com (8.6.12/8.6.12) with SMTP id LAA27260; Tue, 5 Sep 1995 11:18:25 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Sep 1995 11:19:40 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: Multihoming and CIDR Cc: big-internet@munnari.OZ.AU Precedence: bulk At 11:01 AM 9/5/95, Noel Chiappa wrote: > > Renumbering doesn't have to be a flag day > > how is it that a document which wishes to assert itself as a 'best current > practises' documents none of this? > >I think that perhaps it, or a companion document, should at least point this might be worth proposing to cidrd, dontcha think? >out, at a high level. (Trying to get into the details of how to do this >operationally is not really this document's job, of course, and maybe not >the IETF's job anyway...) a document labels as 'current practises' should go into any subsantial detail about the practises? I don't understand. The issue is technical and has implications. Both are entirely relevant for IETF specification and analysis. That IS what BCPs are for, aren't they? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 04:50:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24946; Wed, 6 Sep 1995 04:50:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA11794; Wed, 6 Sep 1995 04:47:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA11677; Wed, 6 Sep 1995 04:23:24 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23888; Wed, 6 Sep 1995 04:23:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29977; Tue, 5 Sep 95 14:22:59 -0400 Date: Tue, 5 Sep 95 14:22:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509051822.AA29977@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, gherbert@crl.com Subject: Re: Multihoming Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker The proposal is for addresses to be acquired from upstream providers. ... If you multi-home through another provider, you will cause an exception to the aggregation pattern. This is very, very expensive since it directly violates the intent of CIDR. Whether it is expensive depends on a lot of factors, such as how close in the network your two connection points are, 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), etc. As a general rule, "better" multihoming costs more in routing overhead (and multihoming of any kinds costs more than no multihoming), and more widely separated connections can increase the routing overhead with little payback in increased reliability. This seems to make multihoming a problem for cidr proper. No? Nope. As I said to Hal (at a certain point in these Big-I blowups, I find that I can just start recycling old responses :-(: There are at least two ways to provide connectivity via separate transit providers, without causing a routing announcement of global scope. There's another way to connect to several transit providers and use only a small share of a global routing announcement. ... The first way is to impose some aggregation structure above the providers... The second way is to pick an address which is subsidiary to your primary provider. Then, advertisements can be limited to a routing scope which includes you and your secondary. The third way is to form an exchange-point cooperative with some other small ISP's. Now, each has different costs and benefits, and perhaps someone has some operational requirement that wouldn't be met by any of the three schemes, but we can provide a lot of mutihoming quite cheaply using these ideas. Noel From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 04:59:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25221; Wed, 6 Sep 1995 04:59:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA11835; Wed, 6 Sep 1995 04:55:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA11813; Wed, 6 Sep 1995 04:52:00 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24974; Wed, 6 Sep 1995 04:51:52 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03263 Wed, 6 Sep 1995 03:16:26 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.38] (dial-cup2-8.iway.aimnet.com [204.118.88.38]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA18176; Tue, 5 Sep 1995 10:10:38 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Sep 1995 10:11:52 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: Multihoming and CIDR Cc: big-internet@munnari.OZ.AU Precedence: bulk Noel, et al, At 5:41 AM 9/4/95, Noel Chiappa wrote: >1 - Renumbering doesn't have to be a flag day; you can assign multiple many things are possible, of course. how is it that a document which wishes to assert itself as a 'best current practises' documents none of this? in fact, there is no distinction between what is, could be, or should be, other than to propose leasing as a necessary palliative. no real analysis of its implications, either. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 05:02:01 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25292; Wed, 6 Sep 1995 05:02:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03759 Wed, 6 Sep 1995 03:46:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA11535; Wed, 6 Sep 1995 03:43:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA11424; Wed, 6 Sep 1995 03:05:34 +1000 Received: from relay2.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20877; Wed, 6 Sep 1995 03:05:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by relay2.UU.NET with SMTP id QQzfxc03444; Tue, 5 Sep 1995 13:04:05 -0400 Received: by ginger.lcs.mit.edu id AA29412; Tue, 5 Sep 95 12:58:05 -0400 Date: Tue, 5 Sep 95 12:58:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509051658.AA29412@ginger.lcs.mit.edu> To: hal9001@panix.com, jnc@ginger.lcs.mit.edu Subject: Re: Routing tables & what to do about them Cc: asp@uunet.uu.net, big-internet@munnari.OZ.AU Precedence: bulk From: "Robert A. Rosenberg" > Good point, we keep forgetting this solution. NAT's aren't without their > problems, but if the costs of renumbering are too high, perhaps the costs > of NAT's will be acceptable. I think that a NAT on the link between the Customer and the ISP would be very cost effective and non-intrusive Actually, the NAT solution has a painful problem I keep forgetting about: if you have your IP addresses in configurations *elsewhere* in the net (e.g. security filters, etc) a NAT box does you no good at all. You will have changed addresses as far as they are concerned, even if internal to your site you are stil using the old ones. It would have no more overhead than a router or bridge does now). All it would need to do is take every .. Packet that comes from the Customer side and replace the Customer Prefix Err, no. It's more complicated (and thus slower). There are places (e.g. DNS lookups) where applications send IP addresses around *inside* packets. So the NAT has to grovel for them, and fix them up too. Noel From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 05:19:44 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25827; Wed, 6 Sep 1995 05:19:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05553 Wed, 6 Sep 1995 05:18:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA11870; Wed, 6 Sep 1995 05:10:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA11752; Wed, 6 Sep 1995 04:35:21 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24458; Wed, 6 Sep 1995 04:35:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04133 Wed, 6 Sep 1995 04:03:43 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29807; Tue, 5 Sep 95 14:01:04 -0400 Date: Tue, 5 Sep 95 14:01:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509051801.AA29807@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@brandenburg.com Subject: Re: Multihoming and CIDR Cc: jnc@ginger.lcs.mit.edu Precedence: bulk > Renumbering doesn't have to be a flag day how is it that a document which wishes to assert itself as a 'best current practises' documents none of this? I think that perhaps it, or a companion document, should at least point this out, at a high level. (Trying to get into the details of how to do this operationally is not really this document's job, of course, and maybe not the IETF's job anyway...) other than to propose leasing as a necessary palliative. no real analysis of its implications, either. I have no problem, personally, with trying to cover more of the ground (although in which document I'm not sure) of what it means, how to deal with it, ways of doing things that you want to do, etc, etc. I just ask that we all do so within the envelope of realizing and accepting that that the routing has to have network-topology-based "routing-names" if the system is going to scale... Noel From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 05:25:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26089; Wed, 6 Sep 1995 05:25:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA11892; Wed, 6 Sep 1995 05:15:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA11812; Wed, 6 Sep 1995 04:52:00 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24980; Wed, 6 Sep 1995 04:51:55 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03252 Wed, 6 Sep 1995 03:16:01 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.38] (dial-cup2-8.iway.aimnet.com [204.118.88.38]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA18417; Tue, 5 Sep 1995 10:12:15 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Sep 1995 10:13:29 -0700 To: Tony Li From: Dave Crocker Subject: RE: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk At 2:07 AM 9/4/95, Tony Li wrote: >Multihoming is not a serious problem with respect to CIDR. Consistency is nice, but your method of using statistics to prove a particular point continues to need some work. 10% of a small number is a small number. 8% of a huge number is probably a large number. Since the net is growing exponentially the concern, then, should be that multi-homing will grow at a similar rate. While you well might take great comfort in the slight decrease in total percentage of multi-homing, others may wish to note that it is still subject to huge growth. That means a large number of multi-homed addresses. One might also wish to note the comments made on the list here about intent to multi-home. Intent doesn't feel nearly as concrete as history, but history is the past. It's a useful thing to attend to, when looking to the future, but it is, in fact, no more definitive than intent. Why you make such a point at taking history as definitive and ignore statements of intent is curious indeed. We have a market that has shown some interesting and basic changes in the last couple of years. Large numbers of startup ISPs is an example. A startup ISP can't afford dual-homing. Yet various comments have been offered concerning multi-homing as part of ISP growth plans. -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 06:21:04 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28463; Wed, 6 Sep 1995 06:21:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06455 Wed, 6 Sep 1995 06:21:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA11954; Wed, 6 Sep 1995 05:30:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA11819; Wed, 6 Sep 1995 04:52:19 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24990; Wed, 6 Sep 1995 04:52:12 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03247 Wed, 6 Sep 1995 03:15:56 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.38] (dial-cup2-8.iway.aimnet.com [204.118.88.38]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA18377; Tue, 5 Sep 1995 10:11:59 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Sep 1995 10:13:13 -0700 To: huitema@pax.inria.fr (Christian Huitema) From: Dave Crocker Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU Precedence: bulk Christian, At 12:30 AM 9/4/95, Christian Huitema wrote: >At 6:34 PM 31/8/95, Dave Crocker wrote: >> Network numbers are assigned by providers. Local providers will >>get their CIDR block from their transit providers. End-users from their >>attachment providers. Numbers & blocks will be 'leased', that is the >Dave, your assumption that "ISP get their numbering space from the up link >provider" is, IMHO, the core of the problem. To be frank, it is entirely >incompatible with the business plans of the most ambitious ISP. Their I think we are about to have a violent agreement. My description was of the proposal for address leasing using the current style of cidr. In that, down-stream providers get addresses from upstream providers. Otherwise, there is no aggregation benefit. Please note all the comments the cidrd chair has been making about the added aggregation upstream. Multi-homing defeats this. Worse, it means that a downstream provider that changes upstream links must change addresses for all its users. I'd class these as very bad features. >After all, one entry per ISP is a lot better than one entry per user... better, yes. good enough? that depends on the total number. if a flat space for all providers (i.e., no aggregation as one goes upstream) is acceptable then why are the current discussions characterizing things so differently? There is, of course, this small, additional question concerning the definition of an ISP. Seems to me that a proposal which hinges so heavily on such a construct needs a rather precise definition. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 06:51:58 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29592; Wed, 6 Sep 1995 06:51:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06352 Wed, 6 Sep 1995 06:16:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA11924; Wed, 6 Sep 1995 05:25:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA11817; Wed, 6 Sep 1995 04:52:18 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24985; Wed, 6 Sep 1995 04:51:58 +1000 (from dcrocker@brandenburg.com) Received: from aimnet.aimnet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03270 Wed, 6 Sep 1995 03:16:39 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.38] (dial-cup2-8.iway.aimnet.com [204.118.88.38]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA18482; Tue, 5 Sep 1995 10:12:49 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Sep 1995 10:14:03 -0700 To: asp@uunet.uu.net (Andrew Partan) From: Dave Crocker Subject: Re: Routing tables & what to do about them Cc: big-internet@munnari.OZ.AU Precedence: bulk Andrew, At 11:59 PM 9/3/95, Andrew Partan wrote: >Today the only thing that does this is CIDR and renumbering. and the explanation for putting forward the leasing proposal is that cidr is running out of steam based on the original cidr proposal. If this were not true, there wouldn't be a need to put forward the leasing proposal as an official IETF position. (I'd say 'standard' but that would confuse folks that think that a reviewed, official BCP isn't a standard.) if cidr isn't a problem right now then why are the original terms of the cidr plan being modified and why is the leasing proposal being pursued? In other words, CIDR *did* handle things but isn't showing less benefit than anticipated. >However we have to do something now, to make sure that there is a >future. this was the view expressed 3 years ago, also. the reality is that choosing one path restricts people from going down others. We need to be very careful that we don't overuse the sky-is-falling chant. Even if it is true, we need to stop using it as an excuse for making choices that are so clearly deficient. >The enormous growth in the Internet are the singly homed sites. And >most of these are small (in terms of numbers of hosts). True. And important. But why, then, are downstream providers expected to get their numbers from upstream providers? If the additional aggregation that will provide is so minor, why is is being done? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 06:54:56 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29798; Wed, 6 Sep 1995 06:54:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06493 Wed, 6 Sep 1995 06:24:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA11968; Wed, 6 Sep 1995 05:37:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA11845; Wed, 6 Sep 1995 04:57:56 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25208; Wed, 6 Sep 1995 04:57:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: from relay2.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02105 Wed, 6 Sep 1995 02:46:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by relay2.UU.NET with SMTP id QQzfxa28538; Tue, 5 Sep 1995 12:43:37 -0400 Received: by ginger.lcs.mit.edu id AA29307; Tue, 5 Sep 95 12:37:18 -0400 Date: Tue, 5 Sep 95 12:37:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509051637.AA29307@ginger.lcs.mit.edu> To: freedman@netaxs.com, hcb@clark.net Subject: Re: Charging for routes... Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Avi Freedman I would see a separate core for the high-bandwidth or high-reliability data. I would think that if set up properly, the large providers would be able to participate in being key in both worlds (current Internet model and high-availability model). Mmm, I'm not sure it would be separate. Here's why... My crystal ball says that what will likely happen here is that the net of the future will have both models. Per-packet charges for low-b/w applications are more energy to keep track of than they are worth; flat rate will continue there. Start up a reservation, though, and you will probably get charged (perhaps not as detailed as today's phone bills, though). I forsee charging of the customers not because I'm cruel, greedy, heartless and mean, but mainly as a resource-control feedback, to prevent customers from blowing b/w for no good reason. Video, etc, can chew bandwidth like no tomorrow, and if people start opening 1 Gbit/sec streams and leaving them open all day so you can watch their desk, something will need to push back on that. However, I think that everyone will want access to the new applications this new service model allows, so that dual-service-model will extend over the entire Internet, not just a few providers who handle those applications. One thing that is sure is that if the large providers abandon the current Internet model totally that the regionals will connect to each other and there will be two nets. I'm not sure it would technically feasible for the large providers to abandon it. They are still going to need DNS, etc, etc, which need the old service model. Anyway, this is all a bit off the track, so let me stop there. People understand that the route-space issue is a real one, but charging per-route on a multilateral basis may smell as bad as per-packet charging to the most religious among us. Ideology strikes me as lacking utility. I prefer to be practical, and do what works. If charging for routes works, and has more useful results than bad ones, I'm all for it. If not, by all means let's junk it. Besides, everyone wants to avoid negotiating with everyone else to carry their routes for $$$ - it's a large time sink for people who are already incredibly busy. An excellent point. This says that quick, informal, ad-hoc mechanisms are more likely to be used to control routing explosions, like limiting routes to /18's... Of course, such ad-hoc means are likely to have their own down-sidesl. (This one will likely increase the speed at which the IPv4 address space is used up, as people try and get larger blocks so they can get routed portably; so sooner rather than later we will have a market in used IPv4 addresses.) Noel From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 07:15:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00654; Wed, 6 Sep 1995 07:15:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA12116; Wed, 6 Sep 1995 07:15:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA12099; Wed, 6 Sep 1995 07:09:46 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00428; Wed, 6 Sep 1995 07:09:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00832; Tue, 5 Sep 95 17:09:30 -0400 Date: Tue, 5 Sep 95 17:09:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509052109.AA00832@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, huitema@pax.inria.fr Subject: Re: casting your multi-homing/provider-changing vote Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker the proposal for address leasing using the current style of cidr. In that, down-stream providers get addresses from upstream providers. Otherwise, there is no aggregation benefit. ... Multi-homing defeats this. Uh, no. Having an AAB for a multihomed entity which is enough larger than the minimal scope enclosing the connection points to that entity wil provide relatively optimal routes to that entity within the enclosing ANB without having an AAB, in most actual real-world cases, that is anything like as large as the enclosing ANB. it means that a downstream provider that changes upstream links must change addresses for all its users. Depends on which technique you use for supporting multihoming. Two of the the three I listed previously do not have this characteristic. if a flat space for all providers (i.e., no aggregation as one goes upstream) is acceptable That might work too. Depends on how many ISP's we have, and how soon. There is, of course, this small, additional question concerning the definition of an ISP. Seems to me that a proposal which hinges so heavily on such a construct needs a rather precise definition. The routing doesn't know, and doesn't care, if a region of the topology (and its addresses) are an ISP or not. It looks at things in operational terms that affect it, such as multihoming, etc, not whether someone is reselling services. So, this definition is not really of much use to the routing, which is the reason for all this hoo-hah about addresses, neh? Noel From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 07:36:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01364; Wed, 6 Sep 1995 07:36:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA12156; Wed, 6 Sep 1995 07:35:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA12122; Wed, 6 Sep 1995 07:15:41 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00657; Wed, 6 Sep 1995 07:15:27 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id OAA24996; Tue, 5 Sep 1995 14:15:16 -0700 Date: Tue, 5 Sep 1995 14:15:16 -0700 From: Tony Li Message-Id: <199509052115.OAA24996@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Subject: RE: Multihoming Precedence: bulk 10% of a small number is a small number. 8% of a huge number is probably a large number. True, but irrelevant. Perhaps you didn't read all of the mail that I've been sending out about local absorbtion of multihoming. Let's look at George's table again: These guys are dual-homed: count=8 TLG: 4 T1 to mci, 2 T1 to sprint, and T1 peerage with NBN CCnet: cerf, mci Best: mci, net99 Aimnet: mci, sprint Connectivity: mci, tlg Barrnet: mci, willtel zNET: scruz, net99 svpal: sprint, barrnet Now, with the exception of CCnet, these all _appear_ to be fairly local multihomings. Thus, this noise adds nothing to the global routing table. This is clearly bearable. Tony From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 07:55:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02216; Wed, 6 Sep 1995 07:55:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA12209; Wed, 6 Sep 1995 07:55:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA12193; Wed, 6 Sep 1995 07:40:52 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01474; Wed, 6 Sep 1995 07:40:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01082; Tue, 5 Sep 95 17:40:35 -0400 Date: Tue, 5 Sep 95 17:40:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509052140.AA01082@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, yakov@cisco.com Subject: Re: Routing tables & what to do about them Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Yakov Rekhter > the NAT solution has a painful problem I keep forgetting about: if you > have your IP addresses in configurations *elsewhere* in the net (e.g. > security filters, etc) a NAT box does you no good at all. And if folks build their security based on source IP addresses of the packets coming from the outside, they probably need to understand that IP addresses could be faked (and it is not even very hard to do). Good point (can you say "TCP spoofing", anyone)? Still, my point still stands: NAT's are not a painfless panacea which work in all circumstances... Noel From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 07:56:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02265; Wed, 6 Sep 1995 07:56:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA12236; Wed, 6 Sep 1995 07:56:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA12176; Wed, 6 Sep 1995 07:36:49 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01381; Wed, 6 Sep 1995 07:36:45 +1000 (from gherbert@crl.com) Received: from mail.crl.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08233 Wed, 6 Sep 1995 07:36:41 +1000 (from gherbert@crl.com) Received: from crl3.crl.com by mail.crl.com with SMTP id AA19371 (5.65c/IDA-1.5); Tue, 5 Sep 1995 13:02:54 -0700 Message-Id: <199509052002.AA19371@mail.crl.com> To: Dave Crocker Cc: George Herbert , big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Multihoming In-Reply-To: Your message of "Tue, 05 Sep 1995 10:13:46 PDT." Date: Tue, 05 Sep 1995 13:02:53 -0700 From: George Herbert Precedence: bulk Dave Crocker writes: >George Herbert writes: >>No. Announcement policies might potentially be a problem for Multihoming, >>but CIDR proper is not. > > The proposal is for addresses to be acquired from upstream >providers. This ties the address to that upstream provider. If you >multi-home through another provider, you will cause an exception to the >aggregation pattern. This is very, very expensive since it directly >violates the intent of CIDR. > > This seems to make multihoming a problem for cidr proper. No? No, that's address allocation policy (which should be added to the announcement policies problem). In a perfect world, large ISPs will recognize the growth patterns and potential dual-homedness of small ISPs getting connected, and will give them chunks of CIDR blocks which can be dual homed and grown without too much problem rather than out of the middle of large blocks, where it breaks the CIDR concept too badly. Failing to do so is poor planning by the larger ISPs, not a problem with CIDR which is inherent to the system. -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 07:59:29 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02370; Wed, 6 Sep 1995 07:59:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA12261; Wed, 6 Sep 1995 07:57:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA12179; Wed, 6 Sep 1995 07:37:38 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01403; Wed, 6 Sep 1995 07:37:36 +1000 (from gherbert@crl.com) Received: from mail.crl.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08255 Wed, 6 Sep 1995 07:37:31 +1000 (from gherbert@crl.com) Received: from crl3.crl.com by mail.crl.com with SMTP id AA19906 (5.65c/IDA-1.5); Tue, 5 Sep 1995 13:08:34 -0700 Message-Id: <199509052008.AA19906@mail.crl.com> To: asp@uunet.uu.net (Andrew Partan) Cc: root@kbs.netusa.net (Sanjay Kapur), big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Multihoming and CIDR In-Reply-To: Your message of "Mon, 04 Sep 1995 23:11:43 EDT." Date: Tue, 05 Sep 1995 13:08:27 -0700 From: George Herbert Precedence: bulk FYI, we did this discussion once around on the cidrd list. The topic was "Big Honking Routers". Andrew Partan writes: >Sanjay writes: >> Store all possible routes in an array of size 256*256*256 (class C) in >> the routing switch to make it as fast as possible. > >What about the routes that are > /24s? There are 630 of these in my >routers today. This is solvable very easily, actually, without making the main table any bigger. >> Since routing switches are updated only one a day, the potential for >> flaps (jerking strings) is also reduced. > >So a multihomed site that looses one of its links should be prepared to >loose traffic for a full day? This only happens if you do fixed-time updates of the forwarding table. If it's dynamic then you can do forwarding table updates about as fast as you can recompute routes. The only thing which hurts at all is changing a default route when you're forwarding several million packets per second. None of this is applicable to the Router Death Problem of the Day, which is not forwarding capability. The problem today is route calculation and storage capability, which requires crunchies and smart algorithms and lots of RAM. Forwarding is a distinct and different problem, which is not currently the crunch area. -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 08:15:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02943; Wed, 6 Sep 1995 08:15:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA12309; Wed, 6 Sep 1995 08:15:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA12283; Wed, 6 Sep 1995 08:04:43 +1000 Received: from pern.cc.purdue.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02478; Wed, 6 Sep 1995 08:04:26 +1000 (from smb@pern.cc.purdue.edu) Received: from localhost (localhost [127.0.0.1]) by pern.cc.purdue.edu (8.6.12/8.6.12) with ESMTP id RAA01922; Tue, 5 Sep 1995 17:02:46 -0500 Message-Id: <199509052202.RAA01922@pern.cc.purdue.edu> To: big-internet@munnari.OZ.AU Cc: "Scott M. Ballew" Subject: Re: casting your multi-homing/provider-changing vote Date: Tue, 05 Sep 1995 17:02:46 -0500 From: "Scott M. Ballew" Precedence: bulk > Ah, right, the way I ridiculed Scott Ballew for disagreeing with my first > long > analysis of multihoming. > > (For those who don't get it, I don't at all mind people disagreeing with me, > no matter how junior or unknown they are - I'd never heard of Scott before > his message - as long as they have a clue. I think my effusive response to > Scott is pretty good proof that this isn't just talk, but for real.) In fact, Noel was far more positive and accepting of my thoughts than I was at first anticipating. I sent my initial message directly to him rather than "step in it" on a public mailing list exactly because I thought I might be missing something rather obvious. He responded (rather quickly, I might add) with a thoughtful and fair discussion of what I had pointed out and then, God forbid, actually encouraged me to post it to Big-I! This doesn't strike me as a response from someone who has [a] tendency [...] to ridicule those that disagree with [him] However, if you (any you, not just Sanjay) keep beating on the same tired argument with the same stick, I'm surprised anyone has the patience to continue trying to persuade you that you are wrong and point out *why* you are wrong. Scott M. Ballew Purdue Data Network Purdue University P.S. Don't you people ever sleep!? If I ever get caught up on all this mail, I do plan to respond to Noel's request for a followup message, but I do have a life and a job. :-) From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 08:55:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04965; Wed, 6 Sep 1995 08:55:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA12372; Wed, 6 Sep 1995 08:55:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA12355; Wed, 6 Sep 1995 08:53:34 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04833; Wed, 6 Sep 1995 08:53:29 +1000 (from gherbert@crl.com) Received: from crl3.crl.com by mail.crl.com with SMTP id AA01155 (5.65c/IDA-1.5); Tue, 5 Sep 1995 13:52:18 -0700 Message-Id: <199509052052.AA01155@mail.crl.com> To: Robert Moskowitz Cc: Sanjay Kapur , Noel Chiappa , big-internet@munnari.OZ.AU, mn@ios.com, gherbert@crl.com Subject: Re: casting your multi-homing/provider-changing vote In-Reply-To: Your message of "Tue, 05 Sep 1995 11:45:20 EDT." <9509051558.AA22190@clncrdv1.is.chrysler.com> Date: Tue, 05 Sep 1995 13:51:54 -0700 From: George Herbert Precedence: bulk It's not true that big flat array forwarding doesn't solve many problems. But the problems it solves are purely forwarding, not routing, problems. It does nothing to improve the route calculation, routing policy, topology issues, flapping issues, etc. We're going to eventually hit a forwarding wall, but the one in front of us today is the routing wall 8-) -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 09:15:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05943; Wed, 6 Sep 1995 09:15:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA12414; Wed, 6 Sep 1995 09:15:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA12394; Wed, 6 Sep 1995 09:03:26 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05369; Wed, 6 Sep 1995 09:03:24 +1000 (from smart@mel.dit.csiro.au) Received: from koel.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA23310 (5.65c/IDA-1.4.4/DIT-1.3 for big-internet@munnari.oz.au); Wed, 6 Sep 1995 09:03:22 +1000 Message-Id: <199509052303.AA23310@shark.mel.dit.csiro.au> To: big-internet@munnari.OZ.AU Cc: smart@mel.dit.csiro.au Subject: encap implementations? Date: Wed, 06 Sep 1995 09:03:22 +1000 From: Bob Smart Precedence: bulk Encapsulation is a recurring theme on this list as a potential solution to problems from the global to the local. E.g. in the latter category it might allow an organization to only have a few hosts with globally routable addresses and you could get from gateways to those hosts over the net-10 local infrastructure by encapsulating packets. What implementations of IP-in-IP are currently available or in development? I notice that there is no #define for it with the other IPPROTO_etc declarations in netbsd-current. Linux 1.3.23 does have code and a comment saying "maybe this will work soon" :-). Thanks for any information. I will summarize to anyone else who indicates an interest. Bob Smart From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 09:36:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07096; Wed, 6 Sep 1995 09:36:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA12454; Wed, 6 Sep 1995 09:35:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA12434; Wed, 6 Sep 1995 09:20:26 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06071; Wed, 6 Sep 1995 09:19:20 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.38] (dial-cup2-19.iway.aimnet.com [204.118.88.49]) by aimnet.com (8.6.12/8.6.12) with SMTP id QAA03076; Tue, 5 Sep 1995 16:15:32 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 5 Sep 1995 16:16:48 -0700 To: Tony Li From: Dave Crocker Subject: RE: Multihoming Cc: big-internet@munnari.OZ.AU Precedence: bulk At 2:15 PM 9/5/95, Tony Li wrote: > 10% of a small number is a small number. 8% of a huge number is > probably a large number. > >True, but irrelevant. Perhaps you didn't read all of the mail that >I've been sending out about local absorbtion of multihoming. Let's perhaps you didn't read the rest of the note I sent. You are, once again, citing current statistics as a definitive indication of something. "true, but irrelevant" seems apropos of your own response, Tony. I should also note that you've become fond of using the construct of 'local' multi-homings as if there is any documentation about it or any existing or planned policies for doing it. Before asserting that such "higher level" aggregations will occur it would be useful if you would document who will be making them happen. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 09:55:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08224; Wed, 6 Sep 1995 09:55:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA12498; Wed, 6 Sep 1995 09:55:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA12485; Wed, 6 Sep 1995 09:43:48 +1000 Received: from sdg.dra.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07563; Wed, 6 Sep 1995 09:43:39 +1000 (from SEAN@SDG.DRA.COM) Date: Tue, 5 Sep 1995 18:42:36 -0500 (CDT) From: Sean Donelan To: big-internet@munnari.OZ.AU Message-Id: <950905184236.34e7@SDG.DRA.COM> Subject: Poor planning Precedence: bulk >In a perfect world, large ISPs will recognize the growth patterns and >potential dual-homedness of small ISPs getting connected, and will >give them chunks of CIDR blocks which can be dual homed and grown >without too much problem rather than out of the middle of large >blocks, where it breaks the CIDR concept too badly. But we don't live in a perfect world. The current policies actually aggravate the situtation. Whether you're a big or small NSP, the current policies ensure the growth of odd-ball aggregates. The last crisis, the Internet was running out of network numbers. Solution, make it difficult to get network numbers. Instead of a single /15 (or maybe /14) aggregate announcement, we end up announcing a few /24, a few /23, a few /21, a few /20, a few /18, and so forth. This crisis, the Internet is running out of router power. Solution, make it difficult to route network numbers. The concern is whether this "new" policy will make the problem better or worse. Or whether its even worth the effort. The Internet has already started to balkanize. Its going to be just like the old X.25 networks. We used to have a TYMNET PAD, a TELENET PAD, and so forth because you couldn't make calls from one to the other. Speaking of provider-based addressing, take a look at X.121(yeach). Soon, we'll have a MCI Internet link, a Sprint Internet link, etc because routing won't work between them. Looking at the routing today, perhaps that day has already arrived. He's dead Jim. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 11:19:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11889; Wed, 6 Sep 1995 11:19:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA12593; Wed, 6 Sep 1995 11:15:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA12589; Wed, 6 Sep 1995 11:13:23 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11544; Wed, 6 Sep 1995 11:12:06 +1000 (from amolitor@anubis.network.com) Received: from nsco.network.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15111 Wed, 6 Sep 1995 11:11:33 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA24872; Tue, 5 Sep 95 20:28:39 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA08899; Tue, 5 Sep 95 20:08:41 CDT Date: Tue, 5 Sep 95 20:08:41 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9509060108.AA08899@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them Precedence: bulk Actually, you'd be surprised at how expensive it is to modify the addresses in an IP header. Touching the datagram at all is painful when you're really slamming packets through. Which prompts me to also point out that giant arrays of DRAM are also likely to be surprisingly slow as lookup mechanisms, as well. You'd be surprised at how little: routingTableEntry = HugeArray[ip->ip_dst >> 8]; and old = ip->ip->dst; ip->ip_dst = xlate[old >> 8]; updateIpCksum(ip, ip->ip_dst, old); if(ip->ip_p == IPPROTO_UDP) { fixUdpCksum(ip, ip->ip_dst, old); } else if(ip->ip_p == IPPROTO_TCP) { fixTcpCksum(ip, ip->ip_dst, old); } you can get away with when you have a handful of microseconds to get the packet thrown over the wall. NATs and spiffy new routers with huge quantities of RAM and all that aren't quite so easy as they look, if you want them to get reasonable packet rates. Andrew From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 11:33:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB12503; Wed, 6 Sep 1995 11:33:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA12629; Wed, 6 Sep 1995 11:31:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA12575; Wed, 6 Sep 1995 11:08:48 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11404; Wed, 6 Sep 1995 11:07:20 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id VAA07487; Tue, 5 Sep 1995 21:05:36 -0400 Date: Tue, 5 Sep 1995 21:05:35 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Dave Siegel Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Multihoming and CIDR In-Reply-To: <199509050346.UAA28040@seagull.rtd.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > So, if we take this "routing computer," and call it, say, a Router Processor, > and then take this switching device, Let's call it a Silicon Switch Processor. > But, instead of seperating them by something flimsy like an ethernet, or an > FDDI ring, let's build a backplane, put these suckers on cards, and then use > the same bus to load up some interfaces. > > Sounds like the architecture of a Cisco or a Welfleet, to me. Except for two major differences: Software problems with any portion of the router can currently bring it down and Route computation can be done on much faster hardware and at leisure then currently exists in the routers. Also, no one really knows how the routing algorithms are implemented in the Router processer. If they were on an auxillary computer, it is possible that they can be optimized better. The Router processer also suffers from being in effect an embeded system. IF semi-static routing eliminates the "heat death of the Internet", what is so bad about it? > > Dave > > -- > Dave Siegel President, RTD Systems & Networking, Inc. > (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco > dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, > http://www.rtd.com/ for an ISP." > From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 11:38:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12709; Wed, 6 Sep 1995 11:38:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA12646; Wed, 6 Sep 1995 11:35:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA12599; Wed, 6 Sep 1995 11:20:16 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11892; Wed, 6 Sep 1995 11:19:52 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id VAA07645; Tue, 5 Sep 1995 21:18:59 -0400 Date: Tue, 5 Sep 1995 21:18:58 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Andrew Partan Cc: Dave Siegel , big-internet@munnari.OZ.AU Subject: Re: Geographinc addressing In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 5 Sep 1995, Andrew Partan wrote: > Telephone calls are based on circuits, not datagrams. So its entirely > possible for any call to know who placed the call & thus who should get > charged. > > Data is not voice; voice is not data. Repeat. You mean packets are not virtual circuits. I can place a data call on an 800 number and once upon a time X.25 did provide for reverse billing and other fun stuff. The largest networks of the largest organizations are still SNA and they are more or less Virtual circuits. > > Btw, 800 numbers are handled via translation tables. > > And on the subject of telcos; when our company changed it local voice > provider, guess what? All of our phone numbers changed. And when we > moved to a new building, guess what? All of our phone numbers > changed. > But the Telcos are planning in the other direction and will offer local phone number portability in the future. > I sure wish that this accepted telco practice would translate to the > Internet world. I do not believe that it can translate and so any analogy between phone company numbers and IP numbers does not really work. The main feature of the phone company (at least in the US) is its reliability. I sure wish NSPs could be as reliable. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 12:01:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13695; Wed, 6 Sep 1995 12:01:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA12702; Wed, 6 Sep 1995 11:55:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA12666; Wed, 6 Sep 1995 11:39:06 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12651; Wed, 6 Sep 1995 11:37:44 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id VAA07782; Tue, 5 Sep 1995 21:37:00 -0400 Date: Tue, 5 Sep 1995 21:36:59 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: <9509050705.AA27454@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > Oh, but I can do that, viz.: > > The names used by the routing have to be aggregable for the overhead > of routing (e.g. routing table size) to scale reasonably in a large > net; i.e. a single routing table entry has to be able to stand for a > number of hosts (and the bigger the network, the more hosts). If they > are aggregable, that means they have to change when you move to a > different location in the network; that's because the things they can > be aggregated with have changed, they are no longer next the things > they used to be next to. > > If you don't like that characteristic of routing-names, then you have > to provide *another* set of names which don't have this > characteristic, and map them into routing-names. The IETF declined, > some years ago, to do this, with the result that IPv4 addresses are > still routing-names. Hence, IPv4 addresses have to change when you > move to a new location in the network. > > I've succeded in explaining this, quite well, to a number of reports, who > aren't exactly deeply technical. > > The problem is that you seem to refuse to accept this explanation, and keep > looking for a way out. However, all the ones you suggest have been tried > already, and don't work. In fact, there is good reason to think that no > escape can exist. I do not challenge the explanation of the current situation at all. It is very reasonable and easy to understand. What I do challenge is the notion that the only solution is to remove the freedom to move. > > A true expert may be able to explain anything in their area of expertise to a > lay person succinctly, but I'm not sure that when the lay person says that the > expert is wrong, the expert can always explain to the lay person why they are > mistaken quite as easily. E.g. try getting a physicist to explain the EPR > paradox to you, and then insist that Einstein was right, and Bohr was wrong, > or try telling a mathematician that the proof of the Four-Color theorem is > wrong. I am not saying that you are wrong at all. I strongly believe that you have gone over this issue many times and come up with what you believe to be the best/only solution. Sanjay From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 12:18:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14441; Wed, 6 Sep 1995 12:18:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA12746; Wed, 6 Sep 1995 12:15:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA12742; Wed, 6 Sep 1995 12:11:34 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13980; Wed, 6 Sep 1995 12:10:04 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id WAA08024; Tue, 5 Sep 1995 22:06:19 -0400 Date: Tue, 5 Sep 1995 22:06:18 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Avi Freedman Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Charging for routes... In-Reply-To: <199509051234.IAA23914@netaxs.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > Well, the settlement system wasn't at fault, it was a board that didn't > listen to the members, coupled with a lack of a CIX-router-east, etc... > > Avi > Exactly my point. How do we fix those deficiencies (without run afoul of the anti-trust statues in the US)? Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 12:23:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14833; Wed, 6 Sep 1995 12:23:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA12776; Wed, 6 Sep 1995 12:21:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA12708; Wed, 6 Sep 1995 11:57:13 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13426; Wed, 6 Sep 1995 11:55:52 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id SAA17878; Tue, 5 Sep 1995 18:52:38 -0700 From: Dave Siegel Message-Id: <199509060152.SAA17878@seagull.rtd.com> Subject: Re: Geographinc addressing To: root@kbs.netusa.net (Sanjay Kapur) Date: Tue, 5 Sep 1995 18:52:37 -0700 (MST) Cc: asp@uunet.uu.net, dsiegel@rtd.com, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 5, 95 09:18:58 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 731 Precedence: bulk > The main feature of the phone company (at least in the US) > is its reliability. I sure wish NSPs could be as reliable. This is the goal that we are trying to accomplish. Unfortunately, your ideas about these array based routers will NOT accomplish this. If you couldn't call the pizza place down the road, who was MCI connected, because there was a telco outage somewhere, and you have to wait half an hour until the next router update, you'd be pretty pissed...not to mention more hungry. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 12:26:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14907; Wed, 6 Sep 1995 12:26:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA12796; Wed, 6 Sep 1995 12:24:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA12725; Wed, 6 Sep 1995 12:00:51 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13528; Wed, 6 Sep 1995 11:59:31 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id VAA07927; Tue, 5 Sep 1995 21:53:43 -0400 Date: Tue, 5 Sep 1995 21:53:42 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Scott Bradner Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Multihoming and CIDR In-Reply-To: <199509051043.GAA10666@newdev.harvard.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 5 Sep 1995, Scott Bradner wrote: > > Is the whole internet currently not a bandaid? As long as the bandaid > works till IPv6 saves the day, what is wrong with it? > > IPv6 has no new concepts here other than trying to make it easer to > renumber as transparently as possible, cidr-type address assignment > and renumbering as the topology of the net changes will still be > the order of business. > > Scott > Exactly my point. If it is easy to renumber, no one minds doing it and no NSP can hold any customer captive. Let me repeat what I have said before: CIDR in itself a good idea. It is forced renumbering that is a bad idea. The reason it is bad is becuase it can be quite costly to renumber with IPv4. If IPv6 makes it easy, it eliminates the problem. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 12:30:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15083; Wed, 6 Sep 1995 12:30:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA12837; Wed, 6 Sep 1995 12:28:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA12728; Wed, 6 Sep 1995 12:06:22 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13843; Wed, 6 Sep 1995 12:05:37 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id WAA08004; Tue, 5 Sep 1995 22:04:16 -0400 Date: Tue, 5 Sep 1995 22:04:15 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Robert Moskowitz Cc: Noel Chiappa , dcrocker@brandenburg.com, big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal In-Reply-To: <9509051150.AA13935@clncrdv1.is.chrysler.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 5 Sep 1995, Robert Moskowitz wrote: > > Phone numbers equate to domain names, and as such we already have > protability in most cases. Not really. Although the translation does not quite work, phone numbers translate to IP numbers. The telephone directory is more like DNS. You can reach a phone number without knowing the name of someone but if you do not know the number you can look it up int he telephone directory. > We need to expand the use of domain names and > add discovery services that will eliminate the need for any hard coding of > addresses. See IPv6 for this work. > I totally agree. This issue will be moot when (and if) IPv6 comes around. > People view IP addresses like phone numbers for a few reasons, such as the > difficulty in getting them, the current hardcoding pactices, and the hype of > the scarcity of them. > > We are doing little to address the causes, spending all of our energy on the > effects... > > Robert Moskowitz > Chrysler Corporation > (810) 758-8212 > Fortunately, this is just a mailing list. An important mailing list, yes, but still just a mailing list. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 12:37:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15444; Wed, 6 Sep 1995 12:37:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA12861; Wed, 6 Sep 1995 12:35:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA12828; Wed, 6 Sep 1995 12:27:51 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14958; Wed, 6 Sep 1995 12:27:32 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 5 Sep 1995 19:27:23 -0700 Posted-Date: Tue, 5 Sep 1995 19:24:36 -0700 (PDT) Message-Id: <199509060224.AA21148@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 5 Sep 1995 19:24:36 -0700 Subject: Re: Poor planning To: SEAN@SDG.DRA.COM (Sean Donelan) Date: Tue, 5 Sep 1995 19:24:36 -0700 (PDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <950905184236.34e7@SDG.DRA.COM> from "Sean Donelan" at Sep 5, 95 06:42:36 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 516 Precedence: bulk > The Internet has already started to balkanize. Its going to be just > like the old X.25 networks. We used to have a TYMNET PAD, a TELENET PAD, > and so forth because you couldn't make calls from one to the other. Speaking > of provider-based addressing, take a look at X.121(yeach). Soon, we'll have > a MCI Internet link, a Sprint Internet link, etc because routing won't work > between them. Looking at the routing today, perhaps that day has already > arrived. > Multihomeing at its finest! -- --bill From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 12:42:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15628; Wed, 6 Sep 1995 12:42:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA12886; Wed, 6 Sep 1995 12:39:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA12857; Wed, 6 Sep 1995 12:34:36 +1000 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15320; Wed, 6 Sep 1995 12:34:13 +1000 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id WAA23050; Tue, 5 Sep 1995 22:33:58 -0400 From: Avi Freedman Message-Id: <199509060233.WAA23050@netaxs.com> Subject: Re: Charging for routes... To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 5 Sep 1995 22:33:56 -0400 (EDT) Cc: hcb@clark.net, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, freedman@netaxs.com In-Reply-To: <9509051637.AA29307@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 5, 95 12:37:18 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5629 Precedence: bulk > From: Avi Freedman > > I would see a separate core for the high-bandwidth or > high-reliability data. I would think that if set up properly, the large > providers would be able to participate in being key in both worlds > (current Internet model and high-availability model). > > Mmm, I'm not sure it would be separate. Here's why... > > My crystal ball says that what will likely happen here is that the net of the > future will have both models. Per-packet charges for low-b/w applications are > more energy to keep track of than they are worth; flat rate will continue > there. Start up a reservation, though, and you will probably get charged > (perhaps not as detailed as today's phone bills, though). > > I forsee charging of the customers not because I'm cruel, greedy, heartless > and mean, but mainly as a resource-control feedback, to prevent customers from > blowing b/w for no good reason. Video, etc, can chew bandwidth like no > tomorrow, and if people start opening 1 Gbit/sec streams and leaving them open > all day so you can watch their desk, something will need to push back on that. TCP does reasonably well at maintaining good balance between sessions vying for limited (even backbone) links. As long as UDP-based applications (?CUSeeMe?) are prevented from killing links, a best-effort Internet based on the current model would continue to be sufficient for large portions of the Internet population (whose critical apps are telnet, mail, news, and who can deal with slower ftp/web/crude live audio/video stuff). It's tempting to see those two TCP/IP networks (high-availability and best- effort) running over the same infrastructure, as long as the best-effort wouldn't get totally nuked if GM & Xerox & Boeing all wanted to do distributed design videoconferences at the same time. If that was a possibility due to the technical design of the resource-control- for-$$$, then a separate backbone or group of interconnected backbones would probably be better for running an Internet based on the current model. > However, I think that everyone will want access to the new applications this > new service model allows, so that dual-service-model will extend over the > entire Internet, not just a few providers who handle those applications. We see a large base of users who hardly ever use the Web, and for whom mail/news and occasional telnets are sufficient. Obviously the mass market will want better Web and other higher-bandwidth access, but there's already a sustainable market for 'net access without those other (yet to be developed) apps. Nothing is free, and no matter how neat the app, if it costs $$$/hour to use (because it can't be sustained in the current bandwidth model), many will back off to the current level (imo). But this discussion has nothing to do with the route-space/aggregation/ renumbering discussion(s)... > One thing that is sure is that if the large providers abandon > the current Internet model totally that the regionals will connect > to each other and there will be two nets. > > I'm not sure it would technically feasible for the large providers to abandon > it. They are still going to need DNS, etc, etc, which need the old service > model. > > Anyway, this is all a bit off the track, so let me stop there. > > People understand that the route-space issue is a real one, but charging > per-route on a multilateral basis may smell as bad as per-packet charging > to the most religious among us. > > Ideology strikes me as lacking utility. I prefer to be practical, and do > what works. If charging for routes works, and has more useful results than > bad ones, I'm all for it. If not, by all means let's junk it. Undertstood, but idealogy (call it "religion") can select or modify the particular technical implementation choice. (A central party to pay for routes vs. paying each peer); (experimenting harder with other solutions like front-end route processors to the boxes with the interfaces); ... > Besides, everyone wants to avoid negotiating with everyone else > to carry their routes for $$$ - it's a large time sink for people > who are already incredibly busy. > > An excellent point. This says that quick, informal, ad-hoc mechanisms are more > likely to be used to control routing explosions, like limiting routes to > /18's... Yes. But I suspect that at the /21 or /22 level there would be much less objection. And take a look at some stats on #s of routes (pretty rough, but based on a router which had full routing from one direction a week ago): (0 < /8) /8: 26 /9: 1 /10: 4 /11: 3 /12: 9 /13: 19 /14: 66 /15: 129 /16: 5056 /17: 74 /18: 172 /19: 365 /20: 360 /21: 518 /22: 730 /23: 1140 /24: 19079 (and 19 > /25) > Of course, such ad-hoc means are likely to have their own down-sidesl. (This > one will likely increase the speed at which the IPv4 address space is used up, > as people try and get larger blocks so they can get routed portably; so sooner > rather than later we will have a market in used IPv4 addresses.) > > Noel As long as the current metrics of address allocation can be maintained (though convincing the NIC to allocate space to providers starting at /21 but out of a /18 or /16 block would be a grand idea), the traditional customers who have only a *need* for a single /24 block would wind up aggregated, and isps and entities who've already justified the need for a <= /22 block would be able to multi-home without much impact for a very long time to come. Avi From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 12:57:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16303; Wed, 6 Sep 1995 12:57:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA12942; Wed, 6 Sep 1995 12:55:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA12875; Wed, 6 Sep 1995 12:38:29 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15463; Wed, 6 Sep 1995 12:38:13 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 5 Sep 1995 19:37:50 -0700 Posted-Date: Tue, 5 Sep 1995 19:35:02 -0700 (PDT) Message-Id: <199509060235.AA21176@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 5 Sep 1995 19:35:02 -0700 Subject: Re: Multihoming To: tli@cisco.com (Tony Li) Date: Tue, 5 Sep 1995 19:35:02 -0700 (PDT) Cc: root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <199509030002.RAA06781@greatdane.cisco.com> from "Tony Li" at Sep 2, 95 05:02:21 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 421 Precedence: bulk > > > Consumers are not going to multihome. Do you have two water lines to > your house? > > Yes, the provider may be multihomed. That's a _very_ different case. > Sure they are.. In the current hovel, there is public water -and- well water. There is also DPW power and the methane generator (which DPW is required to buy the excess!) Remember that I (as consumer) am also a provider (downstream). -- --bill From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 13:00:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16386; Wed, 6 Sep 1995 13:00:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA12962; Wed, 6 Sep 1995 12:58:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA12922; Wed, 6 Sep 1995 12:45:32 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15812; Wed, 6 Sep 1995 12:45:18 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Tue, 5 Sep 1995 19:45:10 -0700 Posted-Date: Tue, 5 Sep 1995 19:42:23 -0700 (PDT) Message-Id: <199509060242.AA21184@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Tue, 5 Sep 1995 19:42:23 -0700 Subject: Re: Multihoming To: kre@munnari.OZ.AU (Robert Elz) Date: Tue, 5 Sep 1995 19:42:23 -0700 (PDT) Cc: tli@cisco.com, root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, big-internet@munnari.OZ.AU In-Reply-To: <15078.810103716@munnari.OZ.AU> from "Robert Elz" at Sep 3, 95 02:48:36 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 782 Precedence: bulk > I agree completely - but we don't need bizarre rules to > accomplish that, those people won't usually be able to justify > more than a /28 (maybe /26 or /27 in a few odd cases), and often > want just a /30 or even /32. To avoid problems with them we > simply don't let registries with portable numbers allocate a > number to them, it has to come from the provider (which I suspect > it almost always will now anyway). > > kre > Er, Robert. Methinks this is a mistake. The address delegation registries should have -ZERO- to do with which routes get injected and spend their efforts on address conservation/recycling. People who get blocks from registries should be informed that the block allocated has: - a limited lifespan - no implied global reachbility -- --bill From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 13:04:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16585; Wed, 6 Sep 1995 13:04:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA12991; Wed, 6 Sep 1995 13:02:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA12899; Wed, 6 Sep 1995 12:40:52 +1000 Received: from netrail.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15584; Wed, 6 Sep 1995 12:40:37 +1000 (from nathan@netrail.net) Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id WAA13554; Tue, 5 Sep 1995 22:40:42 -0400 Date: Tue, 5 Sep 1995 22:40:40 -0400 (EDT) From: Nathan Stratton To: Sanjay Kapur Cc: Dave Siegel , jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Multihoming and CIDR In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 5 Sep 1995, Sanjay Kapur wrote: > > So, if we take this "routing computer," and call it, say, a Router Processor, > > and then take this switching device, Let's call it a Silicon Switch Processor. > > But, instead of seperating them by something flimsy like an ethernet, or an > > FDDI ring, let's build a backplane, put these suckers on cards, and then use > > the same bus to load up some interfaces. > > > > Sounds like the architecture of a Cisco or a Welfleet, to me. > > Except for two major differences: > > Software problems with any portion of the router can currently bring it > down > Yes, and that if you need to upgrade you do not need to spend 200K for a cisco, you just upgrade the route server or the switching device. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 13:38:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18338; Wed, 6 Sep 1995 13:38:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA13055; Wed, 6 Sep 1995 13:35:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA13035; Wed, 6 Sep 1995 13:20:02 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17439; Wed, 6 Sep 1995 13:19:55 +1000 (from dsiegel@rtd.com) Received: from RTD.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20181 Wed, 6 Sep 1995 13:19:40 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id UAA27894; Tue, 5 Sep 1995 20:13:52 -0700 From: Dave Siegel Message-Id: <199509060313.UAA27894@seagull.rtd.com> Subject: Re: Multihoming and CIDR To: nathan@netrail.net (Nathan Stratton) Date: Tue, 5 Sep 1995 20:13:52 -0700 (MST) Cc: root@kbs.netusa.net, dsiegel@rtd.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: from "Nathan Stratton" at Sep 5, 95 10:40:40 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 587 Precedence: bulk > > Except for two major differences: > > > > Software problems with any portion of the router can currently bring it > > down > > > Yes, and that if you need to upgrade you do not need to spend 200K for a > cisco, you just upgrade the route server or the switching device. If this is starting to boil down to price... ...you get what you pay for. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 13:44:50 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18547; Wed, 6 Sep 1995 13:44:50 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA13088; Wed, 6 Sep 1995 13:42:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA13029; Wed, 6 Sep 1995 13:17:00 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17289; Wed, 6 Sep 1995 13:16:51 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA08415; Tue, 5 Sep 1995 23:16:00 -0400 Date: Tue, 5 Sep 1995 23:15:59 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Andrew Molitor Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <9509060108.AA08899@anubis.network.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 5 Sep 1995, Andrew Molitor wrote: > Actually, you'd be surprised at how expensive it is to modify the > addresses in an IP header. Touching the datagram at all is painful when you're > really slamming packets through. Which prompts me to also point out that giant > arrays of DRAM are also likely to be surprisingly slow as lookup mechanisms, > as well. You'd be surprised at how little: > > Let me display my ignorance. Why would accesing a byte from 16MB of memory (enough to hold routes for a 256 port router for /24 routes) be slower than accessing it from 1MB of memory? Once the routing switch knows which port to push the packet out, what difference is there between the current scheme and a large array scheme? > routingTableEntry = HugeArray[ip->ip_dst >> 8]; > > and > > old = ip->ip->dst; > ip->ip_dst = xlate[old >> 8]; > updateIpCksum(ip, ip->ip_dst, old); > if(ip->ip_p == IPPROTO_UDP) { > fixUdpCksum(ip, ip->ip_dst, old); > } else if(ip->ip_p == IPPROTO_TCP) { > fixTcpCksum(ip, ip->ip_dst, old); > } > > you can get away with when you have a handful of microseconds to get the > packet thrown over the wall. > > NATs and spiffy new routers with huge quantities of RAM and all that > aren't quite so easy as they look, if you want them to get reasonable packet > rates. > > Andrew > Sajay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 14:42:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21280; Wed, 6 Sep 1995 14:42:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA13169; Wed, 6 Sep 1995 14:35:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA13146; Wed, 6 Sep 1995 14:16:33 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20019; Wed, 6 Sep 1995 14:16:13 +1000 (from ses@tipper.oit.unc.edu) Received: from chivalry (chivalry.eit.COM [192.100.58.30]) by tipper.oit.unc.edu (8.6.12/8.6.10) with SMTP id AAA04320; Wed, 6 Sep 1995 00:15:52 -0400 Date: Tue, 5 Sep 1995 21:17:50 -0700 (PDT) From: Simon Spero X-Sender: ses@chivalry To: bmanning@ISI.EDU Cc: Tony Li , root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, big-internet@munnari.OZ.AU Subject: Re: Multihoming In-Reply-To: <199509060235.AA21176@zed.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 5 Sep 1995 bmanning@ISI.EDU wrote: > > Sure they are.. In the current hovel, there is public water -and- well > water. There is also DPW power and the methane generator (which DPW is > required to buy the excess!) Yeah, but what about those of us stuck in glorious Mountain View, (aka Superfund Central), where with a little fractional distillation you can run a fab-plant off the ground water :-) Anyway, getting back to consumer IP multi-homing; hillary, my powerbook, has two IP addresses; one of them at EIT, which is attached to the BARRNet bit of BBN Planet; the other is part of the UNC class B attached to NC-REN (currently not part of BBN Planet. If the one I'm using goes down, I just hang-up the modem, and connect to the other one (serial multi-homing). I only have one phone line at my current address, and even if I did have another, I don't feel any great desire to advertise two 32s globally; I figure if I have to go for something totally unreasonable, I want my own Top Level Domain so I can be ses@web, (saves 4 characters when filling out the blue sheets). Simon From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 14:52:29 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21755; Wed, 6 Sep 1995 14:52:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA13205; Wed, 6 Sep 1995 14:48:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA13149; Wed, 6 Sep 1995 14:21:59 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20382; Wed, 6 Sep 1995 14:21:41 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id AAA08735; Wed, 6 Sep 1995 00:21:14 -0400 Date: Wed, 6 Sep 1995 00:21:13 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: big-internet@munnari.OZ.AU Subject: Conspiracy Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Since I am most probably guilty of starting the conspiracy thread, let me define a few terms. Note that I never said that a conspiracy existed. I do not believe that there is any conspiracy at all. A monopoly situation can exist without a conspiracy. Look at IBM's position in the mainframe business for the last 30 years or Microsoft position in the OS and applications business in the last 10 years. According to Merriam Webster's Collegiate Dictionary, 10th edition: Conspire: PLOT, CONTRIVE 1 a: to join in a secret agreement to do an unlawful or wrongful act or an act which becomes unlawful as a result of the secret agreement. Cabal: the artifices and intrigues of a group of persons secretly united to bring about an overturn or usurpation esp. in public affairs; also: a group engaged in such artifices and intrigues syn see PLOT Cartel: 2: a combination of independent commercial or industrial enterprises designed to limit competition or fix prices. Monopoly: 1: exclusive ownership through legal privilege, command of supply, or concerted action 2: exclusive possession or control 3: a commodity controlled by one party 4: one that has a monopoly. Trust: 3 b: a combination of firms or corporations formed by legal agreement; esp : one that reduces or threatens to reduce competetion. Drool: 1 a : to secrete saliva in anticipation of food b: DRIVEL 2 : to make an efusive show of pleasure or often envious or covetous apreciation 3 : to talk nonsense Idiot: 1 a person affected with idiocy; esp : a feebleminded person having the mental age not exceeding three years and requiring complete custodial care 2: A foolish or stupid person. I know that sometimes I come across as a drooling (3) idiot (2). Maybe I am just frustrated and am not sure that the proposed cure (forced renumbering) is not going to give some entities more power than is good for the Internet. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 15:21:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22956; Wed, 6 Sep 1995 15:21:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA13252; Wed, 6 Sep 1995 15:15:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA13237; Wed, 6 Sep 1995 14:58:46 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21954; Wed, 6 Sep 1995 14:58:34 +1000 (from dsiegel@rtd.com) Received: from RTD.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA24796 Wed, 6 Sep 1995 14:55:26 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id VAA05406; Tue, 5 Sep 1995 21:50:15 -0700 From: Dave Siegel Message-Id: <199509060450.VAA05406@seagull.rtd.com> Subject: Re: Routing tables & what to do about them To: root@kbs.netusa.net (Sanjay Kapur) Date: Tue, 5 Sep 1995 21:50:15 -0700 (MST) Cc: amolitor@anubis.network.com, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 5, 95 11:15:59 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2046 Precedence: bulk > Let me display my ignorance. Why would accesing a byte from 16MB of memory > (enough to hold routes for a 256 port router for /24 routes) be slower than > accessing it from 1MB of memory? Once the routing switch knows which > port to push the packet out, what difference is there between the current > scheme and a large array scheme? This isn't a routing algorithm, it's a translation algorithm, for a Network Application-Layer Translator (NAT) (I think I got the acronym right, anyway). Check out the functions that need to be used. There are two header modifications involved, along with a comparison on TCP vs. UDP. Presumably, this would have to be done with packets going both in and out of the NAT. It looks real expensive. Sounds like you damn near need a quad-piped Alpha just to keep shoveling packets at a reasonable rate. I can only presume that the encapsulation idea would be expensive in overhead as well, since you have to encap packets on the out-bound to the Interconnect, and un-encap on in-bound, but you won't have to make comparisons as to udp, tcp, or icmp, and the like. As pointed out before, though, this places all the load at the Interconnect routers, rather than on the edges (the middle of the Internet vs. the outside) so it is unlikely that this will solve our little CPU problem, though it might solve the RAM problem. > > routingTableEntry = HugeArray[ip->ip_dst >> 8]; > > > > and > > > > old = ip->ip->dst; > > ip->ip_dst = xlate[old >> 8]; > > updateIpCksum(ip, ip->ip_dst, old); > > if(ip->ip_p == IPPROTO_UDP) { > > fixUdpCksum(ip, ip->ip_dst, old); > > } else if(ip->ip_p == IPPROTO_TCP) { > > fixTcpCksum(ip, ip->ip_dst, old); > > } > > > > you can get away with when you have a handful of microseconds to get the > > packet thrown over the wall. -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 16:22:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25742; Wed, 6 Sep 1995 16:22:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA13372; Wed, 6 Sep 1995 16:15:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA13328; Wed, 6 Sep 1995 15:59:53 +1000 Received: from cu.nih.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24776; Wed, 6 Sep 1995 15:58:52 +1000 (from RAF@CU.NIH.GOV) Message-Id: <9509060558.24776@munnari.oz.au> To: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU From: "Roger Fajman" Date: Wed, 06 Sep 1995 01:56:30 EDT Subject: Re: Multihoming Precedence: bulk > Whether it is expensive depends on a lot of factors, such as how close in the > network your two connection points are, 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), etc. > > As a general rule, "better" multihoming costs more in routing overhead (and > multihoming of any kinds costs more than no multihoming), and more widely > separated connections can increase the routing overhead with little payback > in increased reliability. How do you envision this aggregation happening in practice? Is there some routing protocol that does it? Manual configuration doesn't seem like that way to go for the long term. From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 21:38:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08177; Wed, 6 Sep 1995 21:38:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA13716; Wed, 6 Sep 1995 21:35:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA13710; Wed, 6 Sep 1995 21:26:39 +1000 Received: from news.ti.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07781; Wed, 6 Sep 1995 21:26:21 +1000 (from w-rolph@ds.mc.ti.com) Received: from ganesh.mc.ti.com ([157.87.4.175]) by gate.ti.com (8.6.12/) with SMTP id GAA13745; Wed, 6 Sep 1995 06:26:17 -0500 Received: by ganesh.mc.ti.com; id AA00446; Wed, 6 Sep 1995 07:25:45 -0400 Message-Id: <9509061125.AA00446@ganesh.mc.ti.com> X-Sender: a722756@mail-ad.mc.ti.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Sep 1995 07:25:46 -0400 To: Sean Donelan , big-internet@munnari.OZ.AU From: "W. Donald Rolph III" Subject: Re: Poor planning Precedence: bulk >The Internet has already started to balkanize. Its going to be just >like the old X.25 networks. We used to have a TYMNET PAD, a TELENET PAD, >and so forth because you couldn't make calls from one to the other. Speaking >of provider-based addressing, take a look at X.121(yeach). Soon, we'll have >a MCI Internet link, a Sprint Internet link, etc because routing won't work >between them. Looking at the routing today, perhaps that day has already >arrived. > >He's dead Jim. >-- >Sean Donelan, Data Research Associates, Inc, St. Louis, MO > Affiliation given for identification not representation > > > I have been following the general discussions on routing capacity, renumbering etc, and I am concerned since it appears that the discussion has lost sight of the overall objective. We are talking about the Internet, based on comments which have been made. This is arguably one of the most interesting organizational activities humanity has ever pursued, and fundamentally one of the major technological accomplishments in the 20th century. It is based, however, using my admittedly poor insights, on the following assumptions: 1) the Internet is intended to allow communication. Steps which limit the communication capabilities of portions of the Internet would seem to be contradictory to this primary purpose 2) the Internet is intended to be used Steps which greatly reduce the ability of users to access the Internet would appear top be contradictory to this basic purpose There are undoubtedly more assumptions, but these two give a sense of direction to many of my thoughts on this topic, specifically: A) routing solutions which balkanize or limit access to portions of the Internet are what is known as "very bad ideas" B) implementations which place requirements on users which are so onerous that they cant be met are what are known as "very silly ideas" I still have not seen an objective discussion which demonstrates that: 1) growth will indeed be such that we continue to outrun router capacity (given some simple scaling which suggests that a 4X max growth in routes in the moderate term is plausible) 2) that brute force increase in router capacity cant meet the demand 3) that virtualizing the external Internet addresses at the boundary routers for given domains cant achieve the necessary flexibility in routing structures I note in passing that historically a combination of brute force combined with virtualization have been the traditional tools for the computer science world to deal with resource limits. Why is the Internet different? Regards. Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-236-1263 From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 22:17:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09404; Wed, 6 Sep 1995 22:17:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA13780; Wed, 6 Sep 1995 22:15:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA13776; Wed, 6 Sep 1995 22:11:20 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09186; Wed, 6 Sep 1995 22:10:46 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id IAA25869 for ; Wed, 6 Sep 1995 08:08:55 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id GAA20061 for ; Wed, 6 Sep 1995 06:25:50 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA04528; Wed, 6 Sep 95 06:30:30 EDT Message-Id: <9509061030.AA04528@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Sep 1995 06:19:01 -0400 To: "Michael F. Nittmann" From: Robert Moskowitz Subject: Re: Multihoming Cc: Masataka Ohta , Tony Li , big-internet@munnari.OZ.AU Precedence: bulk At 08:27 AM 9/5/95 -0400, Michael F. Nittmann wrote: >like your staple gun story! another worry,though: now we need sheaths and >tubing. thanks for the hint. Fortunately we have improved our relation with the union people and such events are now practically non-existant. But there was a time when the plant support people were VERY good at finding cable shorts... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 22:21:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09660; Wed, 6 Sep 1995 22:21:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA13802; Wed, 6 Sep 1995 22:19:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA13773; Wed, 6 Sep 1995 22:11:06 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09185; Wed, 6 Sep 1995 22:10:45 +1000 (from rgm3@is.chrysler.com) Received: from sg543689.eng.chrysler.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10388 Wed, 6 Sep 1995 22:09:34 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id IAA25780 for ; Wed, 6 Sep 1995 08:08:10 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id HAA20159 for ; Wed, 6 Sep 1995 07:17:42 -0400 Received: from rgm3 (bobsgrid.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA04992; Wed, 6 Sep 95 07:22:26 EDT Message-Id: <9509061122.AA04992@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 06 Sep 1995 07:10:56 -0400 To: Sanjay Kapur , Andrew Partan From: Robert Moskowitz Subject: Re: Geographinc addressing Cc: Dave Siegel , big-internet@munnari.OZ.AU Precedence: bulk At 09:18 PM 9/5/95 -0400, Sanjay Kapur wrote: > >The largest networks of the largest organizations are still SNA and they >are more or less Virtual circuits. > This is changing rapidly as the largest organizations are installing TCP/IP networks to match their size. These networks are moving more data over less bandwidth than the SNA networks BECAUSE THEY DO NOT USE VIRTUAL CIRCUITS. BTW, have you ever configured even a dozen 3745 nodes in an SNA network? Have you ever worked out a SNI interface between two SNA networks? Our SNA network is very stable now and actually shrinking. Back in its hey days, it took 8 people to manage 18 images and around 50 FEPs with about 2 dozen SNI interfaces. How many IP heavyweights do you have???? Oh, and we were able to actually make network changes on a monthly basis (including adding new controllers and changing terminal definitions); our poeple really had their act together! You actually WANT static routing? I'll show you static routing.... Today we have moved around 20,000 of our users from coax attachments to TN3270 via MVS/TCP. One person with a backup supports MVS/TCP on 18 images. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Wed Sep 6 23:58:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13124; Wed, 6 Sep 1995 23:58:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA13938; Wed, 6 Sep 1995 23:55:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA13921; Wed, 6 Sep 1995 23:47:18 +1000 Received: from clark.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12742; Wed, 6 Sep 1995 23:47:14 +1000 (from hcb@clark.net) Received: (hcb@localhost) by clark.net (8.6.12/8.6.5) id JAA26643; Wed, 6 Sep 1995 09:46:50 -0400 From: Howard Berkowitz Message-Id: <199509061346.JAA26643@clark.net> Subject: Re: Routing tables & what to do about them To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 6 Sep 1995 09:46:49 -0400 (EDT) Cc: hal9001@panix.com, jnc@ginger.lcs.mit.edu, asp@uunet.uu.net, big-internet@munnari.OZ.AU In-Reply-To: <9509051658.AA29412@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 5, 95 12:58:05 pm X-Mailer: ELM [version 2.4 PL24alpha3] Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 2576 Precedence: bulk Noel, This may be getting a bit afield of the discussion, but I wonder if there may not be an alternative to the NAT "grovelling," which is truly a lovely word for the concept... > > Actually, the NAT solution has a painful problem I keep forgetting about: if > you have your IP addresses in configurations *elsewhere* in the net (e.g. > security filters, etc) a NAT box does you no good at all. You will have > changed addresses as far as they are concerned, even if internal to your site > you are stil using the old ones. > > > Err, no. It's more complicated (and thus slower). There are places (e.g. DNS > lookups) where applications send IP addresses around *inside* packets. So the > NAT has to grovel for them, and fix them up too. > As far as I remember from the NAT RFC and other NAT discussions I have read, the assumption is that the NAT must fix these complications "on-the-fly." I wonder if an alternative is to define "learning" and "corrective" behavior associated with the NAT, or possibly a proxy server. The NAT would recognize common cases where addresses need to be changed for specific services such as DNS. I don't propose covering everything, just some key well-known services, possibly with "drop-in" modules for user-specific services. Let's take DNS as an example. An "inside" host with the "old" prefix sends a DNS request. The son-of-NAT recognizes in real time that the request is from an old address and to a given server, and logs it. In non-real-time, a processor runs against that log and builds substitution scripts to be run, probably not without manual review, against the server configurations. The son-of-NAT has learned (shades of transparent bridging) that a given host address is inside. It generates a CNAME RR that temporarily aliases the new address to the old, and also generates a A (and probably PTR) records to be run on the cutover date. This is NOT dynamic DNS updating, by design. The inferences drawn need to be reviewed. By making the log analysis decision non-real-time, there is more leisure for analysis. One of the problems for NAT has been DHCP-style dynamically assigned addresses. If the log analyzer has been told which address blocks are dynamic, it will not make inappropriate assumptions of invariane of an address. For example, it would be inappropriate to generate a new DNS record for a static DNS if the address in question will migrate among endpoints. I can see other learning heuristics for SNMP, etc., but the DNS example, I hope, gives a flavor of my initial thinking. Howard From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 00:17:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14181; Thu, 7 Sep 1995 00:17:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA13976; Thu, 7 Sep 1995 00:15:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA13972; Thu, 7 Sep 1995 00:10:24 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13955; Thu, 7 Sep 1995 00:10:16 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id KAA02215; Wed, 6 Sep 1995 10:10:34 -0400 Date: Wed, 6 Sep 1995 10:10:33 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Discussing encap/mapping proposal To: Sanjay Kapur Cc: Robert Moskowitz , Noel Chiappa , dcrocker@brandenburg.com, big-internet@munnari.OZ.AU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Tue, 5 Sep 1995, Sanjay Kapur wrote: > On Tue, 5 Sep 1995, Robert Moskowitz wrote: > > > > Phone numbers equate to domain names, and as such we already have > > protability in most cases. > > Not really. Although the translation does not quite work, phone numbers > translate to IP numbers. The telephone directory is more like DNS. You > can reach a phone number without knowing the name of someone but if you > do not know the number you can look it up int he telephone directory. there is more to the phone system: I do not need to know my whole address: If I do local calls, I only need to know about my local peers. If someone wants to reach me from another prefix area, he can look up where I live and find out the prefix without me telling him. If I know my prefix, ok, but I don't even need to know it. This knowledge is only of interest if I want to advertise it myself, e.g. in a sig. file. Country codes: same on a higher hierarchy. I estimate (that's a guess) that the 1 billion phones in the world use less routing space than the 2 million estimated hosts (last Der Spiegel, German weekly) on the Internet. That's due to a hierarchical addressing scheme, which we will hopefully find when IPv6 addresses are used. Why I am so interested here is more, that such an addressing scheme is painless for the endusers, and maintains the freedom of choice for providers at all levels of the foodchain. Can the authors of the 'leasing' thing of addresses at least limit this to IP4 addresses explicitely, and explicitely state that this is a transitory situation? Mike > > > We need to expand the use of domain names and > > add discovery services that will eliminate the need for any hard coding of > > addresses. See IPv6 for this work. > > > > I totally agree. This issue will be moot when (and if) IPv6 comes around. > > > > People view IP addresses like phone numbers for a few reasons, such as the > > difficulty in getting them, the current hardcoding pactices, and the hype of > > the scarcity of them. > > > > We are doing little to address the causes, spending all of our energy on the > > effects... > > > > Robert Moskowitz > > Chrysler Corporation > > (810) 758-8212 > > > > Fortunately, this is just a mailing list. An important mailing list, > yes, but still just a mailing list. > > Sanjay Kapur > Kapur Business Systems, Inc. > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 00:37:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14912; Thu, 7 Sep 1995 00:37:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA14234; Thu, 7 Sep 1995 00:35:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA14015; Thu, 7 Sep 1995 00:20:07 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14357; Thu, 7 Sep 1995 00:20:03 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 6 Sep 1995 07:19:59 -0700 Posted-Date: Wed, 6 Sep 1995 07:17:11 -0700 (PDT) Message-Id: <199509061417.AA21730@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 6 Sep 1995 07:17:11 -0700 Subject: Re: ISPs & multihoming To: asp@uunet.uu.net (Andrew Partan) Date: Wed, 6 Sep 1995 07:17:11 -0700 (PDT) Cc: dorian@CIC.Net, big-internet@munnari.OZ.AU In-Reply-To: from "Andrew Partan" at Sep 5, 95 00:07:40 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 962 Precedence: bulk > Be careful here - you are mixing sites & ISPs. If sites are all > numbered w/in their ISP's block, then you have just one route per ISP. > > The problem that some people are pointing out is needing to renumber a > whole ISP & all of the ISP's customers - I'm saying that since there > are just not that many ISPs, you should never need to renumber an > entire ISP & all of its customers. > > --asp@uunet.uu.net (Andrew Partan) > Hi, Doesn't this presume that all the ISP's in question have a single block? Most ISPs that I know of have at least a couple, and usually more, due to the process of "slow start" on address delegation. The "leak" in the delegation process is that the registries have not enforced a return of the smaller block when a larger block was requested. This leaves virtually every ISP with ~5 CIDR blocks.... which I think is acceptable, for now. The big hit is the "non-aligned", historical delegations. -- --bill From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 01:18:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16451; Thu, 7 Sep 1995 01:18:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA14311; Thu, 7 Sep 1995 01:15:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA14294; Thu, 7 Sep 1995 01:07:29 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16082; Thu, 7 Sep 1995 01:07:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03278; Wed, 6 Sep 95 11:06:20 -0400 Date: Wed, 6 Sep 95 11:06:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509061506.AA03278@ginger.lcs.mit.edu> To: RAF@cu.nih.gov, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Multihoming Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "Roger Fajman" How do you envision this aggregation happening in practice? Is there some routing protocol that does it? What's at issues is not the aggregation itself, which is trivial (BGP and OSPF already do it), but the setting of the actual boundary at which it happens. I cannot think, off hand, of any algorithm for setting boundaries. The problem is a very complex one, and I'm prety sure there is no optimal solution for routing-table based systems which is purely local (i.e. an algorithm which can look at the routing table in a single node and decide when to aggregate). This is *particularly* true because you want to set the boundaries so that traffic continues to flow after link failures; so a single node would have to be telepathic, or whatever, to know what the routing tables are going to look like after the change happened. I suppose you could try and find an algorithm that sets the boundaries dynamically, based on network conditions, but that is a research topic. I know of a heuristic which does a reasonable job, but I've only studied it in the context of congruent AAB's, and non-partitioned areas, and those constraints are not the ones involved in the multihoming debate. I'd have to think about it for quite a while to see if it can be adapted at all to this situation. Effectively, you're trying to solve the area partition problem with an adjustment to routing scopes, which is not a way that routing experts have explored in detail for attacking partition problems; past approaches included tunnels (as in IS-IS), which is the only fully worked solution I can think of offhand. You're deploying some of the newest, most powerful and more complex tools which have been invented to deal with routing in very large networks, and they just aren't fully understood yet (as the discussion of the last week should have shown). Manual configuration doesn't seem like that way to go for the long term. I agree, but what option do you have? If you want to deploy these tools at all, it has to be with manual configuration. Heck, we totally manually configure addressing boundaries now (something I'd like to throw into the garbage can where it belongs), but almost nobody calls that "no the way to go for the long term". The problems of setting naming boundaries and setting aggregation boundaries are actually very similar, BTW. Anyway, this is not the right forum for these sorts of questions anyway. Noel From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 01:37:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17260; Thu, 7 Sep 1995 01:37:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA14348; Thu, 7 Sep 1995 01:35:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA14325; Thu, 7 Sep 1995 01:20:19 +1000 Received: from pern.cc.purdue.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16498; Thu, 7 Sep 1995 01:20:10 +1000 (from smb@pern.cc.purdue.edu) Received: from localhost (localhost [127.0.0.1]) by pern.cc.purdue.edu (8.6.12/8.6.12) with ESMTP id KAA03846; Wed, 6 Sep 1995 10:19:43 -0500 Message-Id: <199509061519.KAA03846@pern.cc.purdue.edu> To: big-internet@munnari.OZ.AU Cc: "Scott M. Ballew" Subject: Dynamic AABs (Was: Re: Discussing encap/mapping proposal) Date: Wed, 06 Sep 1995 10:19:42 -0500 From: "Scott M. Ballew" Precedence: bulk > [...] > > Also, and equally imporant, his note *also*, it turns out, was not the full > story: see below. (I hope Scott will get a chance to review my comments below > and give an opinion as to their correctness.) Now that I have caught up on Big-I mailings from what was (for the US) a holiday weekend, I think I am ready to comment on Noel's further statements below. > In fact, once that is taken into > account, my original conclusion (that provider-based addresses give > comparable results, often with less routing overhead) not only only > stands, but is reinforced. > > It's also important to realize not only what he did point out, but, morever, > what the wider implications (which he did not state, but I will, > below) are. I probably didn't state them because I didn't pursue it that far. I am not a mathematician, nor a theorist, nor have I really had any formal graph theory training. I am an operator of a reasonably decent-sized campus network with a few regional and one NSP link. But I also tend to have a pretty good grasp of the details below the day-to-day operation, configuration, and engineering that I do that should probably be more valued by my employer than it let's on. :-) For my purposes, once I find a flaw with an idea, the flaw is typically reason enough to back out of a chosen path prior to implementation. If, after thinking about it longer, the problem goes away, then (and only then) can I afford the time to look for broader issues. Ok, enough background. :-) > (His analysis only considers "all-or-nothing" AAB's for routing > advertisements of X, which is probably why he missed this.) Yep. See above. > This points out a bug in a previous statement I made: > > pick an existing abstraction naming boundary which includes your two > connection points ... to make multihoming *keep delivering packets* > when a link fails, a specific route has to be advertised throughout > the smallest enclosing naming [boundary] which contains both (all) > attachment points, irrespective of the form of the address. ... the > AAB of a multihomed entity has to be *at least* the ANB of the > smallest common naming abstraction. > > The correct version actually is somewhat more subtle, and differs for the A.X > and A.P.X address forms. For the A.X form, the version given is correct. For > the A.P.X form, however, the correct form is "a specific route has to be > advertised through a scope which includes the secondary provider as well as > the primary", or "the AAB of the advertisement by a secondary provider of a > multihomed entity with a provider-based address has to include the primary an > d > secondary providers, and a path between them". Agreed. > (Once again we're back into this interesting territory where the shape > of the optimal AAB is also influenced by the topology. Hmm. This needs some > deep pondering to see what it Really Means.) I have some thought on this, and forgive me for presenting them in a rather half-cooked way, but they are only about a day old and my head is spinning enough that I need to get them down before they escape me. Besides, I suspect that others will be more than willing to take some shots and help knock off the rough edges. :-) It has been stated (on this list, if nowhere else) that there is a point in any sufficiently large network where the path to an aggregate route and to a specific route contained in that aggregate have the same next hop. In fact, there is a line in the network that demarcs between the region where this is true and the region where these paths differ. One way to achieve a "dynamic AAB" would be to have routers advertise the prefixes A.P1 and A.P1.X according to the following rules. In all cases, split horizoning can be in effect. 1) if a router knows of a path to only one of the two prefixes, it advertises only that prefix to its neighbors 2) if a router knows of at least one path to each prefix, and the next hop on any path to one of the prefixes differs from the next hop on any path to the other prefix, the router advertises its best path to each prefix to its neighbors 3) if a router knows of at least one path to each prefix, and the next hop on *all* known paths to both prefixes are the same, the router advertises only the aggregate prefix to its neighbors What this boils down to is that the routers that are inside the "split path" region don't know how close they are to the edge of that region, but the routers just outside this region know that they are outside. I drew some pictures of this last night to explore some of this idea, and I found that it does result in an AAB that provides optimal routing to site X within A in the absence of link failure, and reasonably good routing in the presence of failure of the "primary" link to X (via P1). It also tends to result in reasonable traffic sharing between P1 and P2 (no failure case) and correct routing via either P1 or P2 in failure mode. It also beats routing overhead in the A.X case since it is not always necessary to flood information about A.P1.X and A.P1 everywhere in A, but may have more routing overhead than more minimalist AABs. BTW, this seems to scale (perhaps with some tweaking) to work correctly for multi-homing (as opposed to dual-homing) and to cases where X is multi-homed to higher-level providers (ie, A.P1.X is connected to B, a peer of A). Whether it results in manageable routing table growth is another question. :-) Ok, as I said, I know this is half-cooked, and I'm ready for the pot shots. :-) > Anyway, the implications of the above, are, I hope, clear. Multihoming with > provider-based addresses *can* be *functional* in the presence of a lost link > to a primary (albeit not optimal), with an AAB for the advertisement from the > secondary which is much smaller than the entire enclosing ANB. This capabilit > y > is *not* available with addresses of the A.X form. Agreed, and see my half-cooked idea for a way to find a reasonable AAB dynamically that supports this. Scott M. Ballew Purdue Data Network Purdue University From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 02:18:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18725; Thu, 7 Sep 1995 02:18:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA14423; Thu, 7 Sep 1995 02:15:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA14417; Thu, 7 Sep 1995 02:11:55 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18400; Thu, 7 Sep 1995 02:11:41 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzgaq07192; Wed, 6 Sep 1995 12:11:36 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: ISPs & multihoming To: bmanning@ISI.EDU Date: Wed, 6 Sep 1995 12:11:35 -0400 (EDT) Cc: dorian@CIC.Net, big-internet@munnari.OZ.AU In-Reply-To: <199509061417.AA21730@zed.isi.edu> from "bmanning@ISI.EDU" at Sep 6, 95 07:17:11 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 185 Precedence: bulk > The big hit is the "non-aligned", historical delegations. Actually the bigest problem is all of the /24s out there today. If we could get rid of them, we would be just fine. --asp From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 02:22:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18853; Thu, 7 Sep 1995 02:22:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA14443; Thu, 7 Sep 1995 02:20:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA14400; Thu, 7 Sep 1995 02:02:20 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18137; Thu, 7 Sep 1995 02:02:13 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03707; Wed, 6 Sep 95 12:02:09 -0400 Date: Wed, 6 Sep 95 12:02:09 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509061602.AA03707@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, w-rolph@ds.mc.ti.com Subject: Re: Poor planning Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "W. Donald Rolph III" It is based, however, using my admittedly poor insights, on the following assumptions: ... 1) the Internet is intended to allow communication. ... 2) the Internet is intended to be used OK so far... I still have not seen an objective discussion which demonstrates that: 1) growth will indeed be such that we continue to outrun router capacity 2) that brute force increase in router capacity cant meet the demand If the size of the routing tables grows at a rate of 2X, and the capability of the hardware grows at a rate of X, that sounds to me fairly obvious... Noel From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 02:37:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19539; Thu, 7 Sep 1995 02:37:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA14497; Thu, 7 Sep 1995 02:35:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA14482; Thu, 7 Sep 1995 02:31:38 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19317; Thu, 7 Sep 1995 02:31:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04540; Wed, 6 Sep 95 12:31:26 -0400 Date: Wed, 6 Sep 95 12:31:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509061631.AA04540@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Subject: Re: Discussing encap/mapping proposal Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Sanjay Kapur > The names used by the routing have to be aggregable for the overhead > of routing (e.g. routing table size) to scale reasonably in a large > net ... If they are aggregable, that means they have to change when you > move to a different location in the network I do not challenge the explanation of the current situation at all. ... What I do challenge is the notion that the only solution is to remove the freedom to move. Nobody's saying you can't move. All we are saying, in line with the explanation above, is that if you do move, your routing-name has to change. Since IPv4 addresses are currently routing-names, your IPv4 address has to change. Noel From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 02:40:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19608; Thu, 7 Sep 1995 02:40:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA14524; Thu, 7 Sep 1995 02:37:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA14485; Thu, 7 Sep 1995 02:33:27 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19360; Thu, 7 Sep 1995 02:33:23 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.58] (dial-cup2-28.iway.aimnet.com [204.118.88.58]) by aimnet.com (8.6.12/8.6.12) with SMTP id JAA18548; Wed, 6 Sep 1995 09:31:45 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Sep 1995 09:33:00 -0700 To: "W. Donald Rolph III" From: Dave Crocker Subject: Re: Poor planning Cc: big-internet@munnari.OZ.AU Precedence: bulk Donald, At 4:25 AM 9/6/95, W. Donald Rolph III wrote: > 1) the Internet is intended to allow communication. > 2) the Internet is intended to be used >There are undoubtedly more assumptions, but these two give a sense of Indeed there are but the problem has been one of taking only these major requirements and working with them exclusively; it is necessary to juggle a broader list. The concerns I've expressed about cidr are not because the problem of routing table size isn't important. It clearly is. Rather it is that working on the problem requires attending to other basic issues such as effects on end users, support of an open market (i.e., not driving a class of provider out of business) and so on. >I still have not seen an objective discussion which demonstrates that: > 1) growth will indeed be such that we continue to outrun router capacity > 2) that brute force increase in router capacity cant meet the demand > 3) that virtualizing the external Internet addresses at the boundary Exactly right. There has been little discussion about the basics. In fact such discussion has been, shall we say, rather pointedly discouraged. We do not, in fact, have a list of basic requirements. We do not, in fact, have an analysis of tradeoffs. Instead we get a proposal offered in the form of an analysis, but lacking very much meat at all. And we get abuse of most folks trying to attend to that larger set of issues. We get happenstance incorporation of comments, with no apparent accountability. We even get formally moved to a different discussion list. This is all a very curious example of working group process. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 02:57:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20192; Thu, 7 Sep 1995 02:57:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA14581; Thu, 7 Sep 1995 02:55:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA14501; Thu, 7 Sep 1995 02:36:18 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19427; Thu, 7 Sep 1995 02:35:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04598; Wed, 6 Sep 95 12:35:44 -0400 Date: Wed, 6 Sep 95 12:35:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509061635.AA04598@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Time to move on... Cc: jnc@ginger.lcs.mit.edu Precedence: bulk It's pretty clear we are making no headway here. I suggest that all the large providers unilaterally filter smaller routes. When people start losing connectivity, perhaps they will be more inclined to listen. Noel From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 02:59:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20418; Thu, 7 Sep 1995 02:59:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA14606; Thu, 7 Sep 1995 02:57:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA14499; Thu, 7 Sep 1995 02:36:15 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19428; Thu, 7 Sep 1995 02:35:59 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 6 Sep 1995 09:35:34 -0700 Posted-Date: Wed, 6 Sep 1995 09:32:46 -0700 (PDT) Message-Id: <199509061632.AA21920@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 6 Sep 1995 09:32:47 -0700 Subject: Re: ISPs & multihoming To: asp@uunet.uu.net (Andrew Partan) Date: Wed, 6 Sep 1995 09:32:46 -0700 (PDT) Cc: bmanning@ISI.EDU, dorian@CIC.Net, big-internet@munnari.OZ.AU In-Reply-To: from "Andrew Partan" at Sep 6, 95 12:11:35 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 238 Precedence: bulk > > > The big hit is the "non-aligned", historical delegations. > > Actually the bigest problem is all of the /24s out there today. > If we could get rid of them, we would be just fine. > --asp > Didn't I just say that? -- --bill From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 03:17:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20903; Thu, 7 Sep 1995 03:17:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14651; Thu, 7 Sep 1995 03:15:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA14587; Thu, 7 Sep 1995 02:56:26 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20172; Thu, 7 Sep 1995 02:56:23 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzgat14609; Wed, 6 Sep 1995 12:56:14 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: ISPs & multihoming To: bmanning@ISI.EDU Date: Wed, 6 Sep 1995 12:56:14 -0400 (EDT) Cc: dorian@CIC.Net, big-internet@munnari.OZ.AU In-Reply-To: <199509061632.AA21920@zed.isi.edu> from "bmanning@ISI.EDU" at Sep 6, 95 09:32:46 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 596 Precedence: bulk > > > The big hit is the "non-aligned", historical delegations. > > Actually the bigest problem is all of the /24s out there today. > > If we could get rid of them, we would be just fine. > Didn't I just say that? Not quite. 192.*.*.* 6361 /24s 193.*.*.* 1584 /24s 194.*.*.* 1231 /24s 195.*.*.* 1 /24 196.*.*.* 202 /24s 197.*.*.* 1 /24 198.*.*.* 3099 /24s 199.*.*.* 3013 /24s 200.*.*.* 256 /24s 201.*.*.* 1 /24 202.*.*.* 907 /24s 203.*.*.* 542 /24s 204.*.*.* 2604 /24s 205.*.*.* 924 /24s 206.*.*.* 215 /24s 208.*.*.* 3 /24s How many of these are 'historical'? Not that many of them. --asp From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 03:37:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21688; Thu, 7 Sep 1995 03:37:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14700; Thu, 7 Sep 1995 03:35:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14677; Thu, 7 Sep 1995 03:22:56 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21192; Thu, 7 Sep 1995 03:22:43 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05134; Wed, 6 Sep 95 13:22:37 -0400 Date: Wed, 6 Sep 95 13:22:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509061722.AA05134@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, w-rolph@ds.mc.ti.com Subject: Re: Poor planning Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker There has been little discussion about the basics. Oh, the vast amount of mail I've been seeing over the past weeks must have been an optical illusion. Noel From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 03:57:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22351; Thu, 7 Sep 1995 03:57:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA14754; Thu, 7 Sep 1995 03:55:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA14734; Thu, 7 Sep 1995 03:48:43 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22085; Thu, 7 Sep 1995 03:48:41 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.58] (dial-cup2-21.iway.aimnet.com [204.118.88.51]) by aimnet.com (8.6.12/8.6.12) with SMTP id KAA29199; Wed, 6 Sep 1995 10:47:17 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 6 Sep 1995 10:48:33 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: Poor planning Cc: big-internet@munnari.OZ.AU Precedence: bulk At 10:22 AM 9/6/95, Noel Chiappa wrote: > There has been little discussion about the basics. >Oh, the vast amount of mail I've been seeing over the past weeks must have >been an optical illusion. sleight of hand, perhaps. you've been doing theory of routing. I'm talking about requirements for Internet-wide operation. That includes users and local providers. You've focussed only on internal mechanics of switching machinery. I'm trying to broaden the issue to things that might be termed 'environmental impact' and seek a solution which is more balanced. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 04:17:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23154; Thu, 7 Sep 1995 04:17:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA14802; Thu, 7 Sep 1995 04:15:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA14774; Thu, 7 Sep 1995 04:04:20 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22669; Thu, 7 Sep 1995 04:03:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05388; Wed, 6 Sep 95 14:03:52 -0400 Date: Wed, 6 Sep 95 14:03:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509061803.AA05388@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mn@ios.com Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: "Michael F. Nittmann" I estimate ... that the 1 billion phones in the world use less routing space than the 2 million estimated hosts ... on the Internet. I'm assuming here that you mean "routing table space", not "address size". I have no idea how big phone company routing tables are. That's due to a hierarchical addressing scheme Which is what we are trying to introduce here. such an addressing scheme is painless for the endusers, and maintains the freedom of choice for providers at all levels of the foodchain. What? Try moving from the area covered by one exchange to another, and see if you get to keep the same phone number. I won't even talk about switching area codes or countries. Can the authors of the 'leasing' thing of addresses at least limit this to IP4 addresses explicitely, and explicitely state that this is a transitory situation? I believe the IPv6 AD (who ought to know) already indicated the exact opposite. You seem to have not grasped that this is true of all namespaces used by the routing. Noel From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 05:18:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25121; Thu, 7 Sep 1995 05:18:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA14885; Thu, 7 Sep 1995 05:15:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA14866; Thu, 7 Sep 1995 04:58:26 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24505; Thu, 7 Sep 1995 04:58:03 +1000 (from minshall@servo.ipsilon.com) Received: from foo-241-200.Ipsilon.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19518 Thu, 7 Sep 1995 04:57:53 +1000 (from minshall@servo.ipsilon.com) Received: from localhost.ipsilon.com (localhost.ipsilon.com [127.0.0.1]) by servo.ipsilon.com (8.6.11/8.6.10) with SMTP id LAA13943 for ; Wed, 6 Sep 1995 11:54:40 -0700 Message-Id: <199509061854.LAA13943@servo.ipsilon.com> X-Authentication-Warning: servo.ipsilon.com: Host localhost.ipsilon.com didn't use HELO protocol X-Mailer: exmh version 1.6beta 3/23/95 To: big-internet@munnari.OZ.AU Subject: Re: ISPs & multihoming In-Reply-To: Your message of "Wed, 06 Sep 1995 12:56:14 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 06 Sep 1995 11:54:39 -0700 From: Greg Minshall Precedence: bulk All, I wonder if the reason we aren't getting anywhere is that there isn't any room in any of the crevices. Deering's metro stuff was, i believe, aimed at IPv6, not IPv4. I'm pretty sure (but willing to be corrected) that Steve's thought was that 32 bits wasn't enough to have countries and metros, as well as sites, and have any room left over for any actual end systems (but, heck, what do end systems have to do with routing, anyway? :-). On the other hand, various things, including asp's comments: > 192.*.*.* 6361 /24s > 193.*.*.* 1584 /24s > 194.*.*.* 1231 /24s > 195.*.*.* 1 /24 > 196.*.*.* 202 /24s lead me to wonder if CIDR isn't equally ineffective, ultimately, in the context of IPv4 (no matter how useful the CIDR idea is, in any event, either in theory or in actually staving off the issue). So, i'm led back to kre's original proposal. /24's map to 1 or more "pieces of the topology", where the latter are "named" by addresses of order /12 (or so). These mappings can't change any quicker than ~24 hours. You let the mapping be 1:n (i.e., one /24 onto >= one /12) to allow for: 1) multihomed; 2) transitions. You probably order these in "preference" order. Load balancing is left to some future version. You use encapsulation (IP in IP) between the /12 bits, so a /12 receiver "knows" the previous hop (the /12 sender). You define some ICMP "subnet unreachable" messages ("not connected here"), which a /12 receiver can send to a /12 sender. This allows multihomed sites to "fail over" to a backup /12 (but, doesn't solve the "black hole" problem of the primary /12 disappearing -- this is what the /12 routing should be protecting against). These ICMP messages also allow for transitions to have a "cut over" time. (And, of course, FTP as the routing [mapping] distribution protocol.) So, kre, where *is* that I-D? Greg ps - Depressingly (i say in my Eeyore voice), there is *still* the issue of what routing looks like *inside* one of the pieces of the topology named by a /12. I.e., it is totally unstructured inside such a thing. But, /12 * /12 equals /24, though that probably isn't going to make the big players all that happy. From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 05:35:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25740; Thu, 7 Sep 1995 05:35:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA14924; Thu, 7 Sep 1995 05:35:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA14906; Thu, 7 Sep 1995 05:23:47 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25298; Thu, 7 Sep 1995 05:23:44 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 6 Sep 1995 12:23:42 -0700 Posted-Date: Wed, 6 Sep 1995 12:20:54 -0700 (PDT) Message-Id: <199509061920.AA22704@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 6 Sep 1995 12:20:54 -0700 Subject: Re: ISPs & multihoming To: asp@uunet.uu.net (Andrew Partan) Date: Wed, 6 Sep 1995 12:20:54 -0700 (PDT) Cc: bmanning@ISI.EDU, dorian@CIC.Net, big-internet@munnari.OZ.AU In-Reply-To: from "Andrew Partan" at Sep 6, 95 12:56:14 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 797 Precedence: bulk > > > > > The big hit is the "non-aligned", historical delegations. > > > Actually the bigest problem is all of the /24s out there today. > > > If we could get rid of them, we would be just fine. > > Didn't I just say that? > > Not quite. > > 192.*.*.* 6361 /24s > 193.*.*.* 1584 /24s > 194.*.*.* 1231 /24s > 195.*.*.* 1 /24 > 196.*.*.* 202 /24s > 197.*.*.* 1 /24 > 198.*.*.* 3099 /24s > 199.*.*.* 3013 /24s > 200.*.*.* 256 /24s > 201.*.*.* 1 /24 > 202.*.*.* 907 /24s > 203.*.*.* 542 /24s > 204.*.*.* 2604 /24s > 205.*.*.* 924 /24s > 206.*.*.* 215 /24s > 208.*.*.* 3 /24s > > How many of these are 'historical'? Not that many of them. > > --asp Sorry, Using MO's mindset... Everything that was delegated since yesterday is historical. In 5-9 Months, it will have doubled! :) -- --bill From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 06:18:00 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27305; Thu, 7 Sep 1995 06:18:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20892 Thu, 7 Sep 1995 06:17:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA14999; Thu, 7 Sep 1995 06:15:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA14979; Thu, 7 Sep 1995 06:08:35 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26938; Thu, 7 Sep 1995 06:08:33 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 6 Sep 1995 13:08:26 -0700 Posted-Date: Wed, 6 Sep 1995 13:05:34 -0700 (PDT) Message-Id: <199509062005.AA22806@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 6 Sep 1995 13:05:34 -0700 Subject: Re: Multihoming To: ses@tipper.oit.unc.edu (Simon Spero) Date: Wed, 6 Sep 1995 13:05:34 -0700 (PDT) Cc: bmanning@ISI.EDU, tli@cisco.com, root@kbs.netusa.net, wolf@instinet.com, swb1@cornell.edu, big-internet@munnari.OZ.AU In-Reply-To: from "Simon Spero" at Sep 5, 95 09:17:50 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1321 Precedence: bulk > Anyway, getting back to consumer IP multi-homing; hillary, my powerbook, > has two IP addresses; one of them at EIT, which is attached to the BARRNet > bit of BBN Planet; the other is part of the UNC class B attached to NC-REN > (currently not part of BBN Planet. If the one I'm using goes down, I > just hang-up the modem, and connect to the other one (serial multi-homing). > I only have one phone line at my current address, and even if I did have > another, I don't feel any great desire to advertise two 32s globally; I > figure if I have to go for something totally unreasonable, I want my own > Top Level Domain so I can be ses@web, (saves 4 characters when filling > out the blue sheets). > > Simon > Can't help w/ the TLD...:) Cool, very Cool. Hillary has a split persona. Now what happens if the need to "push" the redundant connections out a bit occurs...?? Hillary is joined by Bill (a cast off NEXT) and Spot (your chickencoop IBM 3033!) on a house LAN. Now the house lan has to have a /29 to number these machines. Do you get a /29 from BBN and a /29 from UNC and run virtual interface code on the three platforms? Do you run DHCP? How do you configure Chelse (the house router) to do dial backup with a different block? (hint, you have just become an internet provider! :) -- --bill From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 06:36:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27928; Thu, 7 Sep 1995 06:36:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA15077; Thu, 7 Sep 1995 06:36:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA15027; Thu, 7 Sep 1995 06:16:38 +1000 Received: from chaos.structured.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27259; Thu, 7 Sep 1995 06:16:34 +1000 (from kozowski@structured.net) Received: (from kozowski@localhost) by chaos.structured.net (8.6.10/Structured_8.6.12) id NAA05787 for big-internet@munnari.OZ.AU; Wed, 6 Sep 1995 13:16:27 -0700 Date: Wed, 6 Sep 1995 13:16:27 -0700 From: Eric Kozowski Message-Id: <199509062016.NAA05787@chaos.structured.net> To: big-internet@munnari.OZ.AU Subject: Re: Discussing encap/mapping proposal Precedence: bulk >What? Try moving from the area covered by one exchange to another, and see if >you get to keep the same phone number. I won't even talk about switching area >codes or countries. Except that "500" numbers and cell phone roaming blow holes in that argument. -- Eric Kozowski Structured Network Systems, Inc. kozowski@structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1 From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 06:37:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27951; Thu, 7 Sep 1995 06:37:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA15100; Thu, 7 Sep 1995 06:37:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA15042; Thu, 7 Sep 1995 06:17:22 +1000 From: bmanning@ISI.EDU Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27265; Thu, 7 Sep 1995 06:17:19 +1000 (from bmanning@ISI.EDU) Received: from venera.isi.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20825 Thu, 7 Sep 1995 06:15:37 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 6 Sep 1995 13:12:36 -0700 Posted-Date: Wed, 6 Sep 1995 13:09:43 -0700 (PDT) Message-Id: <199509062009.AA22814@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 6 Sep 1995 13:09:43 -0700 Subject: Re: Multihoming and CIDR To: nectar@communique.net (Jacques Vidrine) Date: Wed, 6 Sep 1995 13:09:43 -0700 (PDT) Cc: root@kbs.netusa.net, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, dhollis@gp.magick.net In-Reply-To: from "Jacques Vidrine" at Sep 2, 95 07:08:02 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 521 Precedence: bulk > > > Indeed, that is the point that I was leading up to. Wouldn't we all be > better off discussing _how_ to renumber, instead of whining that we > _can't_ or that it is too expensive. > > Jacques Vidrine Communique, Inc. > I feel I should inject a pointer to pier-request@isi.edu and a place where one can discuss how to renumber. There is a charter for a proposed WG and at least one attempt to detail renumbering efforts. Your contribution would be welcome. --bill From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 06:39:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27983; Thu, 7 Sep 1995 06:39:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA15124; Thu, 7 Sep 1995 06:38:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA15047; Thu, 7 Sep 1995 06:17:45 +1000 Received: from sdg.dra.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27282; Thu, 7 Sep 1995 06:17:38 +1000 (from SEAN@SDG.DRA.COM) Date: Wed, 6 Sep 1995 15:16:28 -0500 (CDT) From: Sean Donelan To: big-internet@munnari.OZ.AU Message-Id: <950906151628.3897@SDG.DRA.COM> Subject: Time to move on... Precedence: bulk > It's pretty clear we are making no headway here. I suggest that all >the large providers unilaterally filter smaller routes. When people start >losing connectivity, perhaps they will be more inclined to listen. Some big providers have unilaterally filtered smaller routes for some time. Other than causing routing blackholes and more support calls, it didn't seem to cause people to listen to you any more. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 06:55:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28542; Thu, 7 Sep 1995 06:55:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA15182; Thu, 7 Sep 1995 06:55:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA15095; Thu, 7 Sep 1995 06:37:38 +1000 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27945; Thu, 7 Sep 1995 06:37:34 +1000 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id QAA24740; Wed, 6 Sep 1995 16:37:18 -0400 From: Avi Freedman Message-Id: <199509062037.QAA24740@netaxs.com> Subject: Re: Charging for routes... To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 6 Sep 1995 16:37:17 -0400 (EDT) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <9509062009.AA06652@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 6, 95 04:09:27 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1438 Precedence: bulk > > This one will likely increase the speed at which the IPv4 address space > > is used up, as people try and get larger blocks so they can get routed > > portably > > As long as the current metrics of address allocation can be maintained > > Assumption.... > > the traditional customers who have only a *need* for a single /24 block > would wind up aggregated > > Yes, but smart customers might get /23's so they can be portable (at least, > until we move the bar up to /22 or whatever). > > Noel Yes, the whole thing has to stand or neither clause does :) *If* current providers can (which are being good for the most part about at least only allocating a single Class C, and usually [in my experience] about subnetting Class Cs) stay good about allocating address-space that way, then the traditional customers who only need a single /24 block would wind up aggregated - with the exception of ISPs who would get a minimum of N class Cs, with a reservable expansion range to whatever size seems routable in the future (/18, /19, /20, or wahtever). Of course, once providers tell customers "Class Cs aren't portable, but those dual-Class C things called /23 CIDR blocks are"... the economic pressure will be on to cheat. But most of our customers (> 90%) that actually deserve and get a Class C (excluding ISP customers) aren't asking about portability now. Anyway, it was a thought/observation. Avi From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 07:22:51 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28937; Thu, 7 Sep 1995 07:22:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA22426 Thu, 7 Sep 1995 07:17:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA15233; Thu, 7 Sep 1995 07:15:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA15224; Thu, 7 Sep 1995 07:11:13 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28795; Thu, 7 Sep 1995 07:11:02 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 6 Sep 1995 14:08:44 -0700 Posted-Date: Wed, 6 Sep 1995 14:05:51 -0700 (PDT) Message-Id: <199509062105.AA22849@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 6 Sep 1995 14:05:52 -0700 Subject: Re: Provider based addressing vs ... To: peter@cyklop.volvo.se (Peter Hakanson) Date: Wed, 6 Sep 1995 14:05:51 -0700 (PDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199509041952.VAA13047@nike.volvo.se> from "Peter Hakanson" at Sep 4, 95 09:52:26 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 324 Precedence: bulk > > Geografical based addressing would boild down to > assigning large networks to regions in the world, > and applied for , lets say, sweden or scandinavia( > which has fairly good internal connectivity) an A address. > -- > Peter Hakanson VolvoData Dep 2580 phone +46 31 66 74 27 > Please review RFC 1466. -- --bill From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 08:35:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01593; Thu, 7 Sep 1995 08:35:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA15329; Thu, 7 Sep 1995 08:35:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA15312; Thu, 7 Sep 1995 08:20:33 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01007; Thu, 7 Sep 1995 08:20:23 +1000 (from gherbert@crl.com) Received: from crl3.crl.com by mail.crl.com with SMTP id AA21513 (5.65c/IDA-1.5); Wed, 6 Sep 1995 14:50:01 -0700 Message-Id: <199509062150.AA21513@mail.crl.com> To: amolitor@anubis.network.com (Andrew Molitor) Cc: big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Tue, 05 Sep 1995 20:08:41 CDT." <9509060108.AA08899@anubis.network.com> Date: Wed, 06 Sep 1995 14:50:00 -0700 From: George Herbert Precedence: bulk Date: Tue, 5 Sep 95 20:08:41 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9509060108.AA08899@anubis.network.com> To: big-internet@munnari.oz.au Subject: Re: Routing tables & what to do about them Precedence: bulk > Actually, you'd be surprised at how expensive it is to modify the >addresses in an IP header. Touching the datagram at all is painful when you're >really slamming packets through. Which prompts me to also point out that giant >arrays of DRAM are also likely to be surprisingly slow as lookup mechanisms, >as well. You'd be surprised at how little: > > routingTableEntry = HugeArray[ip->ip_dst >> 8]; > >and > [...] > >you can get away with when you have a handful of microseconds to get the >packet thrown over the wall. > >NATs and spiffy new routers with huge quantities of RAM and all that >aren't quite so easy as they look, if you want them to get reasonable packet >rates. Excuse my potential ignorance, but how is looking up 1 value in a flat array going to take longer than traversing a tree to 5 or 8 or more levels deep in RAM of equivalent speed? What is going to keep you from doing forwarding lookups at roughly the RAM access speed in a flat table? [This is re: forwarding, not NATs. I am not disagreeing that NATs are painful to build] -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 08:37:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01651; Thu, 7 Sep 1995 08:37:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA15351; Thu, 7 Sep 1995 08:36:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA15309; Thu, 7 Sep 1995 08:17:47 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00817; Thu, 7 Sep 1995 08:17:39 +1000 (from gherbert@crl.com) Received: from crl3.crl.com by mail.crl.com with SMTP id AA20248 (5.65c/IDA-1.5); Wed, 6 Sep 1995 14:43:14 -0700 Message-Id: <199509062143.AA20248@mail.crl.com> To: Sean Donelan Cc: big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Poor planning In-Reply-To: Your message of "Tue, 05 Sep 1995 18:42:36 CDT." <950905184236.34e7@SDG.DRA.COM> Date: Wed, 06 Sep 1995 14:43:13 -0700 From: George Herbert Precedence: bulk > >In a perfect world, large ISPs will recognize the growth patterns and > >potential dual-homedness of small ISPs getting connected, and will > >give them chunks of CIDR blocks which can be dual homed and grown > >without too much problem rather than out of the middle of large > >blocks, where it breaks the CIDR concept too badly. > >But we don't live in a perfect world. The current policies actually >aggravate the situtation. Whether you're a big or small NSP, the current >policies ensure the growth of odd-ball aggregates. The last crisis, the >Internet was running out of network numbers. Solution, make it difficult >to get network numbers. [...] >This crisis, the Internet is running out of router power. Solution, make >it difficult to route network numbers. The concern is whether this "new" >policy will make the problem better or worse. Or whether its even worth >the effort. > >The Internet has already started to balkanize. Its going to be just >like the old X.25 networks. We used to have a TYMNET PAD, a TELENET PAD, >and so forth because you couldn't make calls from one to the other. Speaking >of provider-based addressing, take a look at X.121(yeach). Soon, we'll have >a MCI Internet link, a Sprint Internet link, etc because routing won't work >between them. Looking at the routing today, perhaps that day has already >arrived. > >He's dead Jim. Why Sean, you've gone and gotten gloomy. 8-) I think, as a community, we're getting much better at identifying and dealing with crisies. This one hasn't bit hard yet, and is being very actively worked on. -george From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 09:18:01 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03353; Thu, 7 Sep 1995 09:18:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26003 Thu, 7 Sep 1995 09:17:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA15425; Thu, 7 Sep 1995 09:15:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA15400; Thu, 7 Sep 1995 08:59:20 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02541; Thu, 7 Sep 1995 08:59:07 +1000 (from gherbert@crl.com) Received: from crl3.crl.com by mail.crl.com with SMTP id AA25459 (5.65c/IDA-1.5); Wed, 6 Sep 1995 15:10:24 -0700 Message-Id: <199509062210.AA25459@mail.crl.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: freedman@netaxs.com, big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Charging for routes... In-Reply-To: Your message of "Wed, 06 Sep 1995 16:09:27 EDT." <9509062009.AA06652@ginger.lcs.mit.edu> Date: Wed, 06 Sep 1995 15:10:23 -0700 From: George Herbert Precedence: bulk >Interesting. So we could chop the table drastically by filtering out /24 >and smaller (although some would aggregate and move up, but even there, >you get at least a 50% savings from the minimum 2:1 aggregration). > >Of course, this is rather Draconian; it means all old allocations (which >probably are not, in the main, aggregable) would have to renumber, and also >there's no way to save deserving /24's (such as mult-homed sites), at leat >without special filter holes. > >Interesting times are coming. One alternative would be to take /24 and down out of the core routers for the most part, with some side-by-side routers handling only the /24's I.e., each provider would carry routes internally for all its /24 customers, and have default routes for the rest of the space pointing to the shared router doing class C's (one each at each connect point). That shared router would have all the Cs and nothing else. One extra hop at each interchange point (ISP_A->MAE_C_RTR->ISP_B instead of ISP_A->ISP_B), but it would work. Maybe... -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 09:35:30 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04331; Thu, 7 Sep 1995 09:35:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA15468; Thu, 7 Sep 1995 09:35:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA15456; Thu, 7 Sep 1995 09:26:46 +1000 Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03790; Thu, 7 Sep 1995 09:26:42 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id TAA07089; Wed, 6 Sep 1995 19:26:22 -0400 Date: Wed, 6 Sep 1995 19:26:22 -0400 From: Vadim Antonov Message-Id: <199509062326.TAA07089@titan.sprintlink.net> To: amolitor@anubis.network.com, gherbert@crl.com Subject: Re: Routing tables & what to do about them Cc: big-internet@munnari.OZ.AU Precedence: bulk >Excuse my potential ignorance, but how is looking up 1 value in >a flat array going to take longer than traversing a tree to 5 or >8 or more levels deep in RAM of equivalent speed? What is going to >keep you from doing forwarding lookups at roughly the RAM access >speed in a flat table? Two words: memory footprint. All the speed of modern CPUs goes down the toilet as soon as you have to talk to RAM. With radix trees the memory footprint is a lot less (heck, a tree for 30000 routes may safely fit into an on-chip cache). Then, as everybody knows it is not forwarding table lookup which takes time. It's checking options, handling queues, etc. Anyway, the forwarding performance is not an issue (modulo not exactly useful architecture of some boxes). The problem is in performance of the routing system, which cannot be really improved by throwing more resources, as the rate of growth of flap is more than the performance growth of the microelectronics. No matter how big the box you put in someday you won't be able to find a box big enough. Also, replacing the entire infrastructure every two-three years won't let core ISPs to turn on profit, which means that they'll eventually get out of business; which will mean the death of non-egalitarian Internet. Then you'll have thirteen hundreds of channels of shit on the TV to choose from. --vadim From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 09:36:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04367; Thu, 7 Sep 1995 09:36:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA15490; Thu, 7 Sep 1995 09:36:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA15462; Thu, 7 Sep 1995 09:34:06 +1000 Received: from mercury.Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04238; Thu, 7 Sep 1995 09:33:37 +1000 (from nordmark@jurassic-248.Eng.Sun.COM) Received: from Eng.Sun.COM by mercury.Sun.COM (Sun.COM) id QAA12530; Wed, 6 Sep 1995 16:33:02 -0700 Received: from jurassic.Eng.Sun.COM (jurassic-50.Eng.Sun.COM) by Eng.Sun.COM (5.x/SMI-5.3) id AA25821; Wed, 6 Sep 1995 16:32:57 -0700 Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id QAA28150; Wed, 6 Sep 1995 16:32:55 -0700 Received: by bobo.Eng.Sun.COM (SMI-8.6/SMI-SVR4) id QAA20149; Wed, 6 Sep 1995 16:32:28 -0700 Date: Wed, 6 Sep 1995 16:32:28 -0700 From: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Message-Id: <199509062332.QAA20149@bobo.Eng.Sun.COM> To: huitema@pax.inria.fr Subject: Re: Multihoming and CIDR Cc: big-internet@munnari.OZ.AU Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Precedence: bulk > From huitema@pax.inria.fr Tue Sep 5 05:19:29 1995 > Date: Tue, 5 Sep 1995 13:49:06 +0200 > X-Authentication-Warning: sophia.inria.fr: Host sophmaccdc6.inria.fr claimed to be [138.96.8.86] > Mime-Version: 1.0 > To: Scott Bradner > From: huitema@pax.inria.fr (Christian Huitema) > Subject: Re: Multihoming and CIDR > Cc: big-internet@munnari.OZ.AU > > At 6:43 AM 5/9/95, Scott Bradner wrote: > >> Is the whole internet currently not a bandaid? As long as the bandaid > >works till IPv6 saves the day, what is wrong with it? > > > >IPv6 has no new concepts here other than trying to make it easer to > >renumber as transparently as possible, cidr-type address assignment > >and renumbering as the topology of the net changes will still be > >the order of business. > > > >Scott > > Actually, IPv6 does have three notions which could help us solve several of > the problem we are currently discussing. > > [...] > > The second notion is indeed dynamic addressing allocation. There are indeed > some gory details, such as how do we exactly interface with the DNS, but > the basis is that one can change addresses on the whole network by the turn > of a key. One can also manage obsolescence of addresses, or rather > "deprecation". As far as I know this work is only doing "host renumbering" and there is no ongoing work on how to autorenumber routers, firewalls etc. I also very concerned about applications that call gethostbyname once and retain the returned address forever. One possibly way to reduce the pain of renumbering is based on figuring out how to use site-local IPv6 addresses. If all the traffic internal to a site uses site-local addresses and only external traffic uses global addresses the issues with retained addresses will be much less severe IMHO. Erik From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 09:55:39 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05121; Thu, 7 Sep 1995 09:55:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA15544; Thu, 7 Sep 1995 09:55:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA15527; Thu, 7 Sep 1995 09:54:25 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04934; Thu, 7 Sep 1995 09:53:53 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 6 Sep 1995 16:53:51 -0700 Posted-Date: Wed, 6 Sep 1995 16:51:02 -0700 (PDT) Message-Id: <199509062351.AA23055@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 6 Sep 1995 16:51:02 -0700 Subject: Re: Routing tables & what to do about them To: root@kbs.netusa.net (Sanjay Kapur) Date: Wed, 6 Sep 1995 16:51:02 -0700 (PDT) Cc: dorian@cic.net, mn@ios.com, asp@uunet.uu.net, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 4, 95 01:03:28 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 492 Precedence: bulk > > The above is an example of why this issue is not a purely technical issue > but one that involves deciding who should bear the burden or the cost of > renumbering. Should it be at the routers or the individual sites forced > to renumber? > ... and I had such a nice weekend... Forced renumbering? Come over here... nope, a bit closer... There, now they can't hear us... (everyone, thats right, everyone will be asked to renumber on a regular and periodic basis. ok?) --bill From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 10:15:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06013; Thu, 7 Sep 1995 10:15:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA15593; Thu, 7 Sep 1995 10:15:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA15584; Thu, 7 Sep 1995 10:13:23 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05801; Thu, 7 Sep 1995 10:12:55 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id UAA02397; Wed, 6 Sep 1995 20:14:55 -0400 Date: Wed, 6 Sep 1995 20:14:50 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Time to move on... To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9509061635.AA04598@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk how about tirst stopping to announce small routes first, then blocking the others? This is again the blame game here:the others. So: first the big ones should STOP to announce themselves small fry. Yes? Mike On Wed, 6 Sep 1995, Noel Chiappa wrote: > It's pretty clear we are making no headway here. I suggest that all > the large providers unilaterally filter smaller routes. When people start > losing connectivity, perhaps they will be more inclined to listen. > > Noel > > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 10:17:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06047; Thu, 7 Sep 1995 10:17:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA15615; Thu, 7 Sep 1995 10:16:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA15587; Thu, 7 Sep 1995 10:14:43 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05840; Thu, 7 Sep 1995 10:14:27 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id UAA02405; Wed, 6 Sep 1995 20:16:37 -0400 Date: Wed, 6 Sep 1995 20:16:36 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: ISPs & multihoming To: Andrew Partan Cc: bmanning@ISI.EDU, dorian@cic.net, big-internet@munnari.OZ.AU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk is then the biggest , 192, coming from who? which small provider announces the most of these 6361 /24s? Mike On Wed, 6 Sep 1995, Andrew Partan wrote: > > > > The big hit is the "non-aligned", historical delegations. > > > Actually the bigest problem is all of the /24s out there today. > > > If we could get rid of them, we would be just fine. > > Didn't I just say that? > > Not quite. > > 192.*.*.* 6361 /24s > 193.*.*.* 1584 /24s > 194.*.*.* 1231 /24s > 195.*.*.* 1 /24 > 196.*.*.* 202 /24s > 197.*.*.* 1 /24 > 198.*.*.* 3099 /24s > 199.*.*.* 3013 /24s > 200.*.*.* 256 /24s > 201.*.*.* 1 /24 > 202.*.*.* 907 /24s > 203.*.*.* 542 /24s > 204.*.*.* 2604 /24s > 205.*.*.* 924 /24s > 206.*.*.* 215 /24s > 208.*.*.* 3 /24s > > How many of these are 'historical'? Not that many of them. > > --asp > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 10:35:30 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06786; Thu, 7 Sep 1995 10:35:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA15655; Thu, 7 Sep 1995 10:35:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA15629; Thu, 7 Sep 1995 10:17:09 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06039; Thu, 7 Sep 1995 10:16:30 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id UAA02412; Wed, 6 Sep 1995 20:17:50 -0400 Date: Wed, 6 Sep 1995 20:17:49 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Discussing encap/mapping proposal To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9509061803.AA05388@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Wed, 6 Sep 1995, Noel Chiappa wrote: > From: "Michael F. Nittmann" > > I estimate ... that the 1 billion phones in the world use less routing > space than the 2 million estimated hosts ... on the Internet. > > I'm assuming here that you mean "routing table space", not "address size". I > have no idea how big phone company routing tables are. > > That's due to a hierarchical addressing scheme > > Which is what we are trying to introduce here. > > such an addressing scheme is painless for the endusers, and maintains the > freedom of choice for providers at all levels of the foodchain. > > What? Try moving from the area covered by one exchange to another, and see if > you get to keep the same phone number. I won't even talk about switching area geographical move is not the question: try to change your long distance carrier, or have your local phone company change their upline: do you get a new number? Mike > codes or countries. > > Can the authors of the 'leasing' thing of addresses at least limit this > to IP4 addresses explicitely, and explicitely state that this is a > transitory situation? > > I believe the IPv6 AD (who ought to know) already indicated the exact > opposite. You seem to have not grasped that this is true of all namespaces > used by the routing. > > Noel > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 11:16:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08611; Thu, 7 Sep 1995 11:16:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA15766; Thu, 7 Sep 1995 11:15:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA15721; Thu, 7 Sep 1995 11:00:50 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07967; Thu, 7 Sep 1995 11:00:35 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Wed, 6 Sep 1995 17:59:53 -0700 Posted-Date: Wed, 6 Sep 1995 17:57:05 -0700 (PDT) Message-Id: <199509070057.AA23102@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Wed, 6 Sep 1995 17:57:05 -0700 Subject: Re: Time to move on... To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 6 Sep 1995 17:57:05 -0700 (PDT) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9509061635.AA04598@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 6, 95 12:35:44 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 696 Precedence: bulk > > It's pretty clear we are making no headway here. I suggest that all > the large providers unilaterally filter smaller routes. When people start > losing connectivity, perhaps they will be more inclined to listen. > > Noel I see two things that will occur here.. - The large crowd will stablize and congratulate themselves for keeping the InterNet alive. - The castoffs will form their own infrastructure and then run into the same sets of problems a few months later. I still tend to think that the better course is to charge for prefix advertizment than to filter routes. That way, the transiant, ever increasing blackhole may be avoided by a very clear chargebacks. --bill From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 11:40:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09867; Thu, 7 Sep 1995 11:40:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA15806; Thu, 7 Sep 1995 11:35:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA15780; Thu, 7 Sep 1995 11:17:57 +1000 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08652; Thu, 7 Sep 1995 11:17:29 +1000 (from kre) Date: Thu, 7 Sep 1995 11:17:29 +1000 From: Robert Elz Message-Id: <9509070117.8652@munnari.oz.au> To: jnc@ginger.lcs.mit.edu, mn@ios.com Subject: Re: Time to move on... Cc: big-internet@munnari.OZ.AU Precedence: bulk Date: Wed, 6 Sep 1995 20:14:50 -0400 (EDT) From: "Michael F. Nittmann" Message-Id: how about tirst stopping to announce small routes first, then blocking the others? If anything ever needs to be stopped at all, this is clearly the way it should be done - rather than blocking some other provider's advertisments, those who believe this is the way forward should block their own advertisments (from being sent out). Apart from simply setting a "good" example, it also makes it a lot easier to implement the occasional exception - a provider that has a small net (long prefix) that really needs to be announced can simply do that, without needing to co-ordinate with everyone else. A very good idea. kre From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 11:57:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10785; Thu, 7 Sep 1995 11:57:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA15856; Thu, 7 Sep 1995 11:55:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA15839; Thu, 7 Sep 1995 11:47:29 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10184; Thu, 7 Sep 1995 11:47:19 +1000 (from gherbert@crl.com) Received: from crl3.crl.com by mail.crl.com with SMTP id AA19485 (5.65c/IDA-1.5); Wed, 6 Sep 1995 17:19:09 -0700 Message-Id: <199509070019.AA19485@mail.crl.com> To: Vadim Antonov Cc: amolitor@anubis.network.com, gherbert@crl.com, big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Wed, 06 Sep 1995 19:26:22 EDT." <199509062326.TAA07089@titan.sprintlink.net> Date: Wed, 06 Sep 1995 17:19:08 -0700 From: George Herbert Precedence: bulk >>Excuse my potential ignorance, but how is looking up 1 value in >>a flat array going to take longer than traversing a tree to 5 or >>8 or more levels deep in RAM of equivalent speed? What is going to >>keep you from doing forwarding lookups at roughly the RAM access >>speed in a flat table? > >Two words: memory footprint. >All the speed of modern CPUs goes down the toilet as soon as >you have to talk to RAM. With radix trees the memory footprint >is a lot less (heck, a tree for 30000 routes may safely fit into >an on-chip cache). I have machines in my lab at work (which are shipping platforms, and not even amazingly fast ones) which can do several million memory lookups/sec in main memory. They're not THAT slow, jeex. 60ns + lock time and such isn't bad at all. One of them has been clocked at over 6 million/sec. I don't have an intimate understanding of how small radix trees can be stored, but I think that your 30k routes in on-chip cache is optimistic... L2 cache, perhaps, but L1? Educate me if I'm wrong... >Then, as everybody knows it is not forwarding table lookup which >takes time. It's checking options, handling queues, etc. Yes, but that can and should be handled other than in CPU on the forwarding lookups. >Anyway, the forwarding performance is not an issue (modulo not >exactly useful architecture of some boxes). The problem is in >performance of the routing system, which cannot be really improved >by throwing more resources, as the rate of growth of flap is more >than the performance growth of the microelectronics. No matter how >big the box you put in someday you won't be able to find a box big >enough. Well, that's not quite true. You're correct that routing system performance is the current problem. You can make things better by throwing more resources at them; the current routers have far less CPU power than is available out in existing workstation/light server systems. The growth curve, however, isn't going to change. We can push a crunch off for some time but it won't go away without some other sort of improvements other than crunchies and ram. >Also, replacing the entire infrastructure every two-three years won't >let core ISPs to turn on profit, which means that they'll eventually >get out of business; which will mean the death of non-egalitarian Internet. >Then you'll have thirteen hundreds of channels of shit on the TV to >choose from. Well, if ASP's numbers are right, we're seeing growth doubling every 5 months or so, which means 3 years 36 months 7 doublings = 128 fold growth. Can you keep up with that without essentially replacing your architecture that often? I've seen backbone growth on that order of magnitude since I started using the Internet... I think that worrying about replacing things too often isn't nearly as bad a problem as failing because we can't keep up at all. -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 12:37:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13020; Thu, 7 Sep 1995 12:37:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA15914; Thu, 7 Sep 1995 12:35:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA15891; Thu, 7 Sep 1995 12:15:24 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11735; Thu, 7 Sep 1995 12:14:45 +1000 (from freedman@netaxs.com) Received: from netaxs.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03175 Thu, 7 Sep 1995 12:13:58 +1000 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id VAA05337; Wed, 6 Sep 1995 21:48:49 -0400 From: Avi Freedman Message-Id: <199509070148.VAA05337@netaxs.com> Subject: Re: Charging for routes... To: gherbert@crl.com (George Herbert) Date: Wed, 6 Sep 1995 21:48:48 -0400 (EDT) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, gherbert@crl.com, freedman@netaxs.com In-Reply-To: <199509062210.AA25459@mail.crl.com> from "George Herbert" at Sep 6, 95 03:10:23 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1902 Precedence: bulk > One alternative would be to take /24 and down out of the core routers > for the most part, with some side-by-side routers handling only the /24's > > I.e., each provider would carry routes internally for all its /24 > customers, and have default routes for the rest of the space pointing > to the shared router doing class C's (one each at each connect point). > That shared router would have all the Cs and nothing else. One extra > hop at each interchange point (ISP_A->MAE_C_RTR->ISP_B instead of > ISP_A->ISP_B), but it would work. Maybe... > > -george william herbert > gherbert@crl.com Interesting... Of course, the RA-type multilateral peering solution is available now @ the NAPs/MAEs and is not being widely used. I see three issues with this solution: (1) So if I'm MCI and I'm feeding my 4900 /24 routes or I'm Sprint and I'm feeding my 5836 /24 routes into the common Class-C router, isn't route flapping if I drop and restart my peering session with the common router still an isue? The Class-C router still has to recompute when it does route insertion and deletion on a mass (multi-thousand-route) scale. (2) One of the advantages (and problems) that core routers have is that they have multiple (4x and up) routes from all of the redistributed peering sessions at all of the exchange points fed into them now. If there was to be redundancy at the NAP, it would be ideal for the Class-C router to have routes to the /24 routes that are redistributed from other exchange points as well. Who feeds those to it? And if that kind of redundancy is built in, don't we aggravate the possibility of router exhaustion when a large player resets a peering session? (3) The political implications of a multilateral peering solution at a place like MAE-East, where the model has been bilateral. Still, an interesting idea. Avi From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 15:41:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21131; Thu, 7 Sep 1995 15:41:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA16100; Thu, 7 Sep 1995 15:35:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA16094; Thu, 7 Sep 1995 15:34:46 +1000 Received: from sdg.dra.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20707; Thu, 7 Sep 1995 15:34:42 +1000 (from SEAN@SDG.DRA.COM) Date: Thu, 7 Sep 1995 0:33:31 -0500 (CDT) From: Sean Donelan To: big-internet@munnari.OZ.AU Message-Id: <950907003331.3655@SDG.DRA.COM> Subject: Re: Routing tables & what to do about them Precedence: bulk >(everyone, thats right, everyone will be asked to renumber on >a regular and periodic basis. ok?) That would be an improvement over the current 'too big to renumber' standard. Let me know when MIT and Sprintlink complete their renumbering. If we're going to gore some people's oxen, better gore them all equally. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 15:58:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21843; Thu, 7 Sep 1995 15:58:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA16133; Thu, 7 Sep 1995 15:54:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA16080; Thu, 7 Sep 1995 15:16:06 +1000 Received: from cu.nih.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19657; Thu, 7 Sep 1995 15:12:52 +1000 (from RAF@CU.NIH.GOV) Message-Id: <9509070512.19657@munnari.oz.au> To: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU From: "Roger Fajman" Date: Thu, 07 Sep 1995 01:10:23 EDT Subject: Re: Multihoming Precedence: bulk > I cannot think, off hand, of any algorithm for setting boundaries. The problem > is a very complex one, and I'm prety sure there is no optimal solution for > routing-table based systems which is purely local (i.e. an algorithm which can > look at the routing table in a single node and decide when to aggregate). This > is *particularly* true because you want to set the boundaries so that traffic > continues to flow after link failures; so a single node would have to be > telepathic, or whatever, to know what the routing tables are going to look > like after the change happened. That's what I thought. Perhaps some algorithm involving a server with a more global view might be possible? > You're deploying some of the newest, most powerful and more complex tools > which have been invented to deal with routing in very large networks, and > they just aren't fully understood yet (as the discussion of the last week > should have shown). > > > Manual configuration doesn't seem like that way to go for the long term. > > I agree, but what option do you have? If you want to deploy these tools at > all, it has to be with manual configuration. Heck, we totally manually > configure addressing boundaries now (something I'd like to throw into the > garbage can where it belongs), but almost nobody calls that "no the way to go > for the long term". It seems to me that as the Internet continues to grow and multihoming continues to grow, that the manual configuration needed to set up the abstraction boundaries the way you propose will soon outgrow the availability of experts to do it. So some automated procedure will be needed, at least in Ipv6. > The problems of setting naming boundaries and setting aggregation boundaries > are actually very similar, BTW. > > Anyway, this is not the right forum for these sorts of questions anyway. > > > Noel Why is this not the right forum? This is the big-internet list and it seems to me to be quite related to the ability of the Internet to continue to grow. It's a future crisis, I guess. :-) From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 17:19:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25324; Thu, 7 Sep 1995 17:19:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA16241; Thu, 7 Sep 1995 17:15:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA16221; Thu, 7 Sep 1995 17:03:56 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24549; Thu, 7 Sep 1995 17:02:37 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzgcy08692; Thu, 7 Sep 1995 03:00:38 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: ISPs & multihoming To: mn@ios.com (Michael F. Nittmann) Date: Thu, 7 Sep 1995 03:00:38 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: from "Michael F. Nittmann" at Sep 6, 95 08:16:36 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1470 Precedence: bulk > is then the biggest , 192, coming from who? > which small provider announces the most of these 6361 /24s? I did some more poking at some bgp tables. Count by prefix Prefix Count 192 6303 193 1517 194 1215 195 1 196 214 197 1 198 3154 199 3022 200 259 201 1 202 911 203 551 204 2594 205 925 206 225 208 3 Count by home AS, for more than 100 /24s per home AS. Count Home-AS 1243 174 1009 97 744 2493 510 568 448 701 428 1717 333 544 317 813 315 560 304 3493 295 517 280 3848 258 1836 244 3561 235 2551 223 4175 218 719 216 3602 190 600 182 1270 181 1790 181 1740 180 1239 170 2386 169 1225 168 549 163 2704 158 86 155 2018 155 200 153 1257 153 1221 146 3258 146 2044 141 279 141 1691 140 1759 139 1899 135 786 135 3301 130 3354 128 1982 121 1849 119 681 115 2907 111 2699 107 5056 104 3576 101 4174 Count by prefix by home AS, for more than 100 /24s per home AS in any particular prefix. Count Prefix Home-AS 447 199 174 419 192 174 389 192 97 244 193 1717 229 205 2493 229 192 701 226 194 517 222 203 4175 215 204 2493 209 198 174 191 192 560 189 202 97 189 192 1836 185 199 568 183 204 3848 163 199 2493 156 192 719 149 198 97 148 204 3602 145 192 568 139 204 174 130 203 97 130 193 544 123 192 1717 121 198 2493 118 198 2044 117 192 1270 114 193 1899 113 198 568 112 194 3258 109 196 2018 109 192 2551 108 192 1221 106 192 279 105 192 544 102 192 200 100 203 4174 100 198 701 --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 20:20:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02022; Thu, 7 Sep 1995 20:20:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA16418; Thu, 7 Sep 1995 20:15:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA16401; Thu, 7 Sep 1995 20:09:59 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01689; Thu, 7 Sep 1995 20:09:56 +1000 (from doleary@cisco.com) Received: from diablo.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA25604 Thu, 7 Sep 1995 20:09:04 +1000 (from doleary@cisco.com) Received: (doleary@localhost) by diablo.cisco.com (8.6.10/CISCO.SERVER.1.1) id DAA27717 for big-internet@munnari.oz.au; Thu, 7 Sep 1995 03:06:05 -0700 Date: Thu, 7 Sep 1995 03:06:05 -0700 From: "Dave O'Leary" Message-Id: <199509071006.DAA27717@diablo.cisco.com> To: big-internet@munnari.OZ.AU Subject: large site renumbering (was Re: Geographic addressing) Precedence: bulk Bob sez: Today we have moved around 20,000 of our users from coax attachments to TN3270 via MVS/TCP. One person with a backup supports MVS/TCP on 18 images. Robert Moskowitz Chrysler Corporation (810) 758-8212 The real question is: now that you are running IP on 20,000 machines, how long would it take you to renumber? (just kidding, but I couldn't resist...) dave From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 21:21:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03500; Thu, 7 Sep 1995 21:21:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA16499; Thu, 7 Sep 1995 21:15:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA16476; Thu, 7 Sep 1995 20:56:07 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03009; Thu, 7 Sep 1995 20:56:01 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id DAA07632; Thu, 7 Sep 1995 03:55:57 -0700 Date: Thu, 7 Sep 1995 03:55:57 -0700 From: Tony Li Message-Id: <199509071055.DAA07632@greatdane.cisco.com> To: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them Precedence: bulk Let me display my ignorance. Why would accesing a byte from 16MB of memory (enough to hold routes for a 256 port router for /24 routes) be slower than accessing it from 1MB of memory? All memory is not created equal. Just off the cuff, there's cache, SRAM, Synchronous DRAM, EODRAM, Page Mode DRAM, Slow old PC Dram, etc. I could probably name 6 more if was a hardware engineer. They vary in cost and sizes. Some combinations simply do not exist (can you say "16Mb of D-cache" with a straight face?). Given an infinite amount of money, time, and talent, I bet you could make it work. But back here in the real world, we get to make a tradeoff between 16Mb of slow old PC DRAM and 1Mb of fast SRAM. This is what takes us back to the fundamental problem of scaling that I see today: we're trying to grow the routing tables, we're trying to switch faster. And the intersection is the fast forwarding table which needs to get exponentially faster and exponentially bigger. Simultaneously. Tony From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 21:27:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03713; Thu, 7 Sep 1995 21:27:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA16523; Thu, 7 Sep 1995 21:20:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA16495; Thu, 7 Sep 1995 21:14:08 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03335; Thu, 7 Sep 1995 21:13:33 +1000 (from rgm3@is.chrysler.com) Received: from sg543689.eng.chrysler.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27955 Thu, 7 Sep 1995 21:13:09 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id HAA15289 for ; Thu, 7 Sep 1995 07:10:35 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id HAA13732 for ; Thu, 7 Sep 1995 07:16:11 -0400 Received: from rgm3 (rgm3.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA00579; Thu, 7 Sep 95 07:20:36 EDT Message-Id: <9509071120.AA00579@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Sep 1995 07:08:48 -0400 To: "Dave O'Leary" , big-internet@munnari.OZ.AU From: Robert Moskowitz Subject: Re: large site renumbering (was Re: Geographic addressing) Precedence: bulk At 03:06 AM 9/7/95 -0700, Dave O'Leary wrote: > >>Bob sez: >> >> >>Today we have moved around 20,000 of our users from coax attachments to >>TN3270 via MVS/TCP. One person with a backup supports MVS/TCP on 18 images. > >The real question is: now that you are running IP on 20,000 machines, >how long would it take you to renumber? > >(just kidding, but I couldn't resist...) Depends on how. We actually did renumber a large part of our network to get to where we are. Here in IS there were 500 machines that were renumbered over 2 weekends as we went from one segment with a 255.255.128.0 mask to 18 segments with 255.255.255.128 masks (and a lot more systems). We have renumbered whole plants as part of plant change-overs; major equipment moves and all of that. Sometimes over 1000 devices. All of this done pretty much by hand, or a least a program that does in and massages the stored address info and then rebooting the system. In '96 we will have three rollouts going on that will give us an opurtunity to make this easy. First is the upgrade from LAN Workplace 4.2 to 5.0. Second is the upgrade from Windows 3.11 to Windows 95, and last is the introduction of NT Workstation. All of these support DHCP. We are looking into our options to add DHCP servers at the same time that we upgrade these items. Our challenge is two fold. Which DHCP server? And how to best handle server location. The latter will mean forwarding DHCP requests across routers. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 23:39:54 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07682; Thu, 7 Sep 1995 23:39:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29949 Thu, 7 Sep 1995 22:20:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA16635; Thu, 7 Sep 1995 22:15:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA16615; Thu, 7 Sep 1995 22:09:07 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04276; Thu, 7 Sep 1995 22:08:43 +1000 (from w-rolph@ds.mc.ti.com) Received: from news.ti.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29420 Thu, 7 Sep 1995 22:07:40 +1000 (from w-rolph@ds.mc.ti.com) Received: from ganesh.mc.ti.com ([157.87.4.175]) by gate.ti.com (8.6.12/) with SMTP id GAA26850; Thu, 7 Sep 1995 06:58:45 -0500 Received: by ganesh.mc.ti.com; id AA31182; Thu, 7 Sep 1995 07:58:14 -0400 Message-Id: <9509071158.AA31182@ganesh.mc.ti.com> X-Sender: a722756@mail-ad.mc.ti.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Sep 1995 07:58:14 -0400 To: Robert Moskowitz , "Dave O'Leary" , big-internet@munnari.OZ.AU From: "W. Donald Rolph III" Subject: Re: large site renumbering (was Re: Geographic addressing) Precedence: bulk >Depends on how. We actually did renumber a large part of our network to get >to where we are. >All of this done pretty much by hand, or a least a program that does in and >massages the stored address info and then rebooting the system. > Our IS&S organization is scheduling 1 hour per machine to support manual renumbering of machines. This includes time to ensure that with the renumbering applications and server which used to be local, but are now behind routers, still work. >Our challenge is two fold. Which DHCP server? A major challenge, particularly when a strict requirement of identifying a particular machine by IP address is imposed so security traceability can be maintained. >And how to best handle >server location. The latter will mean forwarding DHCP requests across >routers. Ah yes. enjoy!!! :-> > >Robert Moskowitz >Chrysler Corporation >(810) 758-8212 > > > We also are looking at DHCP servers, and have several in test. It, however, is not a panacea for wholesale migration of nodes between address spaces, although it clearly will help (since many machines still wont support DHCP and will require manual intervention - and these typically are the big server which can take down hundreds of people). I am still concerned that the DHCP development has been driven by commercial rather than technical interests, and still has several major technical holes which the DHCP committee has not addressed to my satisfaction. Regards. Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-236-1263 From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 23:40:31 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07707; Thu, 7 Sep 1995 23:40:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29192 Thu, 7 Sep 1995 22:00:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA16592; Thu, 7 Sep 1995 21:55:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA16575; Thu, 7 Sep 1995 21:53:44 +1000 Received: from news.ti.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04010; Thu, 7 Sep 1995 21:53:06 +1000 (from w-rolph@ds.mc.ti.com) Received: from ganesh.mc.ti.com ([157.87.4.175]) by gate.ti.com (8.6.12/) with SMTP id GAA24115; Thu, 7 Sep 1995 06:49:51 -0500 Received: by ganesh.mc.ti.com; id AA30389; Thu, 7 Sep 1995 07:49:19 -0400 Message-Id: <9509071149.AA30389@ganesh.mc.ti.com> X-Sender: a722756@mail-ad.mc.ti.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Sep 1995 07:49:19 -0400 To: Tony Li , big-internet@munnari.OZ.AU From: "W. Donald Rolph III" Subject: Re: Routing tables & what to do about them Precedence: bulk >All memory is not created equal. Just off the cuff, there's cache, >SRAM, Synchronous DRAM, EODRAM, Page Mode DRAM, Slow old PC Dram, etc. >I could probably name 6 more if was a hardware engineer. They vary in >cost and sizes. Some combinations simply do not exist (can you say >"16Mb of D-cache" with a straight face?). > >Given an infinite amount of money, time, and talent, I bet you could >make it work. But back here in the real world, we get to make a >tradeoff between 16Mb of slow old PC DRAM and 1Mb of fast SRAM. > >This is what takes us back to the fundamental problem of scaling that >I see today: we're trying to grow the routing tables, we're trying to >switch faster. And the intersection is the fast forwarding table >which needs to get exponentially faster and exponentially bigger. >Simultaneously. > >Tony > > I guess here is part of my concern as I listen to the conversation. My area of expertise is supercomputing applications. My company makes RAM. Two points emerge If you want 16 meg of fast RAM using last years technologies (or even five years ago) you can do it. Cray and Convex did. It "only" costs money. Next - new synchronous RAM technologies are emerging which provide high speed at low cost, as merely one example of changes in RAM technologies in the recent past. I guess I still have not heard a convincing explanation why brute force will not give the immediate speed requirements. I have heard a good story of how router vendors have not talked to supercomputing vendors..... Regards. Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-236-1263 From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 01:20:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11639; Fri, 8 Sep 1995 01:20:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA16980; Fri, 8 Sep 1995 01:15:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA16963; Fri, 8 Sep 1995 00:59:37 +1000 Received: from mach1.gs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10911; Fri, 8 Sep 1995 00:59:33 +1000 (from daniel.padwa@gs.com) Received: from gs.com (postoffice1.gs.com) by gs.com (4.1/SMI-4.1) id AA23699; Thu, 7 Sep 95 10:59:27 EDT Received: from fi.gs.com (fi.fi.gs.com) by gs.com (4.1/GOLDMAN-1.0) id AA28067; Thu, 7 Sep 95 11:00:05 EDT Received: from slsd0.fi.gs.com by fi.gs.com (4.1/SMI-4.2 (FI main hub)) id AA05042; Thu, 7 Sep 95 10:59:20 EDT Received: from sls069.fi.gs.com by slsd0.fi.gs.com (4.1/FIsubhub-2.7) id AA01449; Thu, 7 Sep 95 10:59:14 EDT Received: by sls069.fi.gs.com (4.1/FIclient-2.8) id AA11513; Thu, 7 Sep 95 10:59:10 EDT Date: Thu, 7 Sep 95 10:59:10 EDT Message-Id: <9509071459.AA11513@sls069.fi.gs.com> From: Danny Padwa To: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <199509062351.AA23055@zed.isi.edu> References: <199509062351.AA23055@zed.isi.edu> Precedence: bulk >>>>> "Bill" == bmanning writes: Bill> (everyone, thats right, everyone will be asked to renumber Bill> on a regular and periodic basis. ok?) This brings up an interestig point......should we start pushing vendors to make renumbering an easier task? Technologies like RARP and DHCP should buy us a lot, yet most PC stacks I deal with really like having an IP address configured in. Let's not even talk about the Unix boxes. Seems to me that a little work on autoconfiguration (combined with auto-DNS updates?) should at the very least let us reduce the renumbering problem to be that of updating "address servers" (2? per segment) rather than desktops. Yes, there will always be some older systems that require manual reconfiguration, but some vendor assistance could certainly help the process. - Danny From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 01:37:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12208; Fri, 8 Sep 1995 01:37:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA17019; Fri, 8 Sep 1995 01:35:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA16982; Fri, 8 Sep 1995 01:16:52 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11449; Fri, 8 Sep 1995 01:15:35 +1000 (from rgm3@is.chrysler.com) Received: from sg543689.eng.chrysler.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03995 Fri, 8 Sep 1995 01:10:40 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id LAA21981 for ; Thu, 7 Sep 1995 11:06:46 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id LAA18390 for ; Thu, 7 Sep 1995 11:12:29 -0400 Received: from rgm3 (rgm3.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA16724; Thu, 7 Sep 95 11:16:42 EDT Message-Id: <9509071516.AA16724@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 07 Sep 1995 11:04:54 -0400 To: "W. Donald Rolph III" , "Dave O'Leary" , big-internet@munnari.OZ.AU From: Robert Moskowitz Subject: Re: large site renumbering (was Re: Geographic addressing) Precedence: bulk At 07:58 AM 9/7/95 -0400, W. Donald Rolph III wrote: > >Our IS&S organization is scheduling 1 hour per machine to support manual >renumbering of machines. This includes time to ensure that with the >renumbering applications and server which used to be local, but are now >behind routers, still work. Let's see.... 5 people 2 10 hour workperiods for 500 systems. That was 5 systems an hour average. This included: Running a program that figured out what hub and drop the user was on (needed to know what segment the user would now be in). changing net.cfg via a prompting program. Updating the new hosts file (we are only now getting DNS working :( ). Labling the overhead bookcase and drop box with the IP address. Rebooting the PC and testing basic connectivity. As for hardcoded addresses, everyone was warned a month ahead to get with the program. We handle problems on a case-by-case afterwards. >>Our challenge is two fold. Which DHCP server? > >A major challenge, particularly when a strict requirement of identifying a >particular machine by IP address is imposed so security traceability can be >maintained. IP address locked into MAC address seems to be the only way... >>And how to best handle >>server location. The latter will mean forwarding DHCP requests across >>routers. > >Ah yes. enjoy!!! :-> Particularly when our TCOM people do not currently allow any forwarding. No BOOTP support for our many printers :( >We also are looking at DHCP servers, and have several in test. It, however, >is not a panacea for wholesale migration of nodes between address spaces, >although it clearly will help (since many machines still wont support DHCP >and will require manual intervention - and these typically are the big >server which can take down hundreds of people). I am still concerned that >the DHCP development has been driven by commercial rather than technical >interests, and still has several major technical holes which the DHCP >committee has not addressed to my satisfaction. The big servers can be handled in many ways. Including adding interfaces with new addresses ahead of time. Much cheaper in the long run... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 05:35:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21098; Fri, 8 Sep 1995 05:35:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA17262; Fri, 8 Sep 1995 05:35:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA17256; Fri, 8 Sep 1995 05:33:20 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21007; Fri, 8 Sep 1995 05:33:16 +1000 (from gherbert@crl.com) Received: from crl3.crl.com by mail.crl.com with SMTP id AA24853 (5.65c/IDA-1.5); Thu, 7 Sep 1995 11:23:40 -0700 Message-Id: <199509071823.AA24853@mail.crl.com> To: Tony Li Cc: big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Thu, 07 Sep 1995 03:55:57 PDT." <199509071055.DAA07632@greatdane.cisco.com> Date: Thu, 07 Sep 1995 11:23:39 -0700 From: George Herbert Precedence: bulk Tony writes: >All memory is not created equal. Just off the cuff, there's cache, >SRAM, Synchronous DRAM, EODRAM, Page Mode DRAM, Slow old PC Dram, etc. >I could probably name 6 more if was a hardware engineer. They vary in >cost and sizes. Some combinations simply do not exist (can you say >"16Mb of D-cache" with a straight face?). > >Given an infinite amount of money, time, and talent, I bet you could >make it work. But back here in the real world, we get to make a >tradeoff between 16Mb of slow old PC DRAM and 1Mb of fast SRAM. As a counterexample, look at using Sparc 10 / 20 type memory and memory controllers. It took 2 engineer years (+- a bit) over 6 months for the company I'm contracting at to develop a Sparc MBUS memory controller it's using now. That controller with standard Sparc 10 DSIMMs at 60ns runs at 50mhz bus speed and completes a 64 bit main memory fetch in 6 bus cycles. The actual sustained speed is more like 8 cycles but that's 6.25 million fetches a sec. 32 meg Sparc 10 SIMMs at 60ns will provide 16 interfaces plus (you want 5 bits of interface address space, for ulterior motives) and 11 bits of DLCI/MAC remote address next-hop keying for all of the world's space at /24, for about $1400 per interface. The chip is about $100 in quantity, if I remember right. >which needs to get exponentially faster and exponentially bigger. >Simultaneously. Ayup. But don't knock flat tables. -george From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 05:55:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21888; Fri, 8 Sep 1995 05:55:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA17310; Fri, 8 Sep 1995 05:55:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA17293; Fri, 8 Sep 1995 05:54:33 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21815; Fri, 8 Sep 1995 05:54:31 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id MAA26402; Thu, 7 Sep 1995 12:53:51 -0700 Date: Thu, 7 Sep 1995 12:53:51 -0700 From: Tony Li Message-Id: <199509071953.MAA26402@greatdane.cisco.com> To: w-rolph@ds.mc.ti.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <9509071149.AA30389@ganesh.mc.ti.com> (w-rolph@ds.mc.ti.com) Subject: Re: Routing tables & what to do about them Precedence: bulk I guess I still have not heard a convincing explanation why brute force will not give the immediate speed requirements. The problem is the word "immediate". The development cycle for routers is nontrivial. Yes, brute force would give us tomorrow's needs -- but next week, not tomorrow. And then we'd be catastrophically behind. There is no way that we can compete with Moore's law. Tony From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 06:55:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23903; Fri, 8 Sep 1995 06:55:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA17394; Fri, 8 Sep 1995 06:55:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA17377; Fri, 8 Sep 1995 06:51:22 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23743; Fri, 8 Sep 1995 06:51:20 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id NAA01107; Thu, 7 Sep 1995 13:50:34 -0700 Date: Thu, 7 Sep 1995 13:50:34 -0700 From: Tony Li Message-Id: <199509072050.NAA01107@greatdane.cisco.com> To: w-rolph@ds.mc.ti.com Cc: big-internet@munnari.OZ.AU In-Reply-To: <9509071149.AA30389@ganesh.mc.ti.com> (w-rolph@ds.mc.ti.com) Subject: Re: Routing tables & what to do about them Precedence: bulk I guess I still have not heard a convincing explanation why brute force will not give the immediate speed requirements. I decided that I should reply again and simply present the facts: The routing table can and has doubled every 9-10 months. See RFC 1519, page 8. The routing table is stored in (a) memory. Processing the routing table requires CPU cycles. The aggregate bandwidth as seen at a backbone POP doubles every 18 months. Supporting bandwidth requires switching. The average packet size is roughly constant. Switching requires CPU cycles. Switching references the routing table (sometimes indirectly). Computing power doubles every 24 months. Memory sizes double roughly every 24 months, except they go up by factors of four (and no, that's not 48 months). No one claims that current routers are at the bleeding edge of computer technology today. The long term strategy is the problem. Tony From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 07:53:47 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25610; Fri, 8 Sep 1995 07:53:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA11009 Fri, 8 Sep 1995 07:38:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA17449; Fri, 8 Sep 1995 07:35:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA17443; Fri, 8 Sep 1995 07:33:58 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24967; Fri, 8 Sep 1995 07:33:52 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14181; Thu, 7 Sep 95 17:33:48 -0400 Date: Thu, 7 Sep 95 17:33:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509072133.AA14181@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kre@munnari.OZ.AU, mn@ios.com Subject: Re: Time to move on... Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Robert Elz If anything ever needs to be stopped at all, this is clearly the way it should be done - rather than blocking some other provider's advertisments, those who believe this is the way forward should block their own advertisments (from being sent out). ... A very good idea. I agree, but unfortunately, the real-world reality is that it's even less likely to happen than charging for routes. The bug is that you're asking providers to do things that will cramp their own customers; i.e. the people paying them money, who have some ability to call them up and yell in their ears. If a provider blocks *other provider's* routes, who can yell at the provider, where they have to sit still and listen? The other provider's customers? I doubt it. They will only get heat if one of *their* customers wants to get to one of the locations that is filtered. So, nice idea, but unlikely practically. Noel PS: Same thing for charging for routes; no provider wants to charge their own customers for advertising routes *out*. Hence my new version of this, where providers charge *other providers* for taking routes *in*... Not that any of these are going to happen Real Soon Now, of course... From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 07:56:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25699; Fri, 8 Sep 1995 07:56:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA17503; Fri, 8 Sep 1995 07:55:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA17483; Fri, 8 Sep 1995 07:44:07 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25216; Fri, 8 Sep 1995 07:44:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA11064 Fri, 8 Sep 1995 07:44:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14231; Thu, 7 Sep 95 17:41:31 -0400 Date: Thu, 7 Sep 95 17:41:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509072141.AA14231@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mn@ios.com Subject: Re: Discussing encap/mapping proposal Cc: jnc@ginger.lcs.mit.edu Precedence: bulk geographical move is not the question: try to change your long distance carrier ... do you get a new number? You're ignoring the constraints on the phone system which make this limited class of portability work. In any case, the scope over which you can move, and keep your "address" (phone number) is limited. You guys want an Internet in which you can move *anywhere* and keep your phone number. Not even the phone system does that. Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 07:57:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25717; Fri, 8 Sep 1995 07:57:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA17525; Fri, 8 Sep 1995 07:56:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA17469; Fri, 8 Sep 1995 07:38:36 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25027; Fri, 8 Sep 1995 07:38:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14208; Thu, 7 Sep 95 17:38:23 -0400 Date: Thu, 7 Sep 95 17:38:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509072138.AA14208@ginger.lcs.mit.edu> To: bmanning@isi.edu, jnc@ginger.lcs.mit.edu Subject: Re: Time to move on... Cc: big-internet@munnari.OZ.AU Precedence: bulk From: bmanning@isi.edu I see two things that will occur here ... The castoffs will form their own infrastructure and then run into the same sets of problems a few months later. Right, and even faster since they have a bunch of tiny, unaggregable routes. Just out of interest, how would they communicate back and forth to the rest of the "topologically-addresses" Internet? Sure, inside each half you can run a /0 default pointing to the other half, to catch the stuff that's not in your half, but the routers on the borderline are going to have to have a touting table which contains full data from both sides, no? (Otherwise, stuff to non-existent addresses will loop between two border routers, each of which has a full table for their side, and a default pointing to the rest...) I still tend to think that the better course is to charge for prefix advertizment than to filter routes. I agree. I'm not holding my breath, though. (Which IETF was it when I first stood up and proposed that? Many moons ago, now...) Noel From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 08:15:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26270; Fri, 8 Sep 1995 08:15:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA17571; Fri, 8 Sep 1995 08:15:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA17551; Fri, 8 Sep 1995 08:09:31 +1000 Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26048; Fri, 8 Sep 1995 08:09:16 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id SAA08483; Thu, 7 Sep 1995 18:07:33 -0400 Date: Thu, 7 Sep 1995 18:07:33 -0400 From: Vadim Antonov Message-Id: <199509072207.SAA08483@titan.sprintlink.net> To: SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them Precedence: bulk I renumbered SprintLink backbone once (within the same network # but with radically different numbering plan). So it can be done and was done. Renumbering is not a tragedy, just some work. --vadim From owner-Big-Internet@munnari.OZ.AU Thu Sep 7 02:22:59 1995 Received: from tiny.sprintlink.net (tiny.sprintlink.net [199.0.55.90]) by titan.sprintlink.net (8.6.9/8.6.9) with ESMTP id CAA07912 for ; Thu, 7 Sep 1995 02:22:59 -0400 Received: from murtoa.cs.mu.OZ.AU (murtoa.cs.mu.OZ.AU [128.250.22.5]) by tiny.sprintlink.net (8.6.9/8.6.9) with ESMTP id CAA20249 for ; Thu, 7 Sep 1995 02:22:55 -0400 Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA16104; Thu, 7 Sep 1995 15:39:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA16094; Thu, 7 Sep 1995 15:34:46 +1000 Received: from sdg.dra.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20707; Thu, 7 Sep 1995 15:34:42 +1000 (from SEAN@SDG.DRA.COM) Date: Thu, 7 Sep 1995 0:33:31 -0500 (CDT) From: Sean Donelan To: big-internet@munnari.OZ.AU Message-Id: <950907003331.3655@SDG.DRA.COM> Subject: Re: Routing tables & what to do about them Precedence: bulk Status: R >(everyone, thats right, everyone will be asked to renumber on >a regular and periodic basis. ok?) That would be an improvement over the current 'too big to renumber' standard. Let me know when MIT and Sprintlink complete their renumbering. If we're going to gore some people's oxen, better gore them all equally. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 09:35:54 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29768; Fri, 8 Sep 1995 09:35:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA17669; Fri, 8 Sep 1995 09:35:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA17663; Fri, 8 Sep 1995 09:28:47 +1000 Received: from sdg.dra.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29447; Fri, 8 Sep 1995 09:28:29 +1000 (from SEAN@SDG.DRA.COM) Date: Thu, 7 Sep 1995 18:26:33 -0500 (CDT) From: Sean Donelan To: big-internet@munnari.OZ.AU Message-Id: <950907182633.3b0e@SDG.DRA.COM> Subject: Re: Routing tables & what to do about them Precedence: bulk >I renumbered SprintLink backbone once (within the same >network # but with radically different numbering plan). >So it can be done and was done. Renumbering is not >a tragedy, just some work. So treating others equally, I'll agree an ISP can change its internal backbone numbering plan. Did it effect customers? This debate has been done before. The "little" guys need to renumber, the "big" guys don't. Sometime's life isn't fair, why not simply say so. If you use a "little" ISP, expect to renumber. Who expects all the COREN networks to renumber into MCI's CIDR block? Who expects all the ICP networks to renumber into Sprint's CIDR block? If we're serious about provider based numbering, isn't that what's called for? If all providers are not created equal, then any "policy" method of discriminating will have trouble. But "money" discrimination almost always seems acceptable (except to those without money). -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 10:55:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03633; Fri, 8 Sep 1995 10:55:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA17770; Fri, 8 Sep 1995 10:55:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA17742; Fri, 8 Sep 1995 10:37:20 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02676; Fri, 8 Sep 1995 10:37:00 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id UAA01763; Thu, 7 Sep 1995 20:36:55 -0400 Date: Thu, 7 Sep 1995 20:36:55 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: Sean Donelan Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <950907182633.3b0e@SDG.DRA.COM> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 7 Sep 1995, Sean Donelan wrote: > This debate has been done before. The "little" guys need to renumber, > the "big" guys don't. Sometime's life isn't fair, why not simply say > so. If you use a "little" ISP, expect to renumber. Who expects all > the COREN networks to renumber into MCI's CIDR block? Who expects all > the ICP networks to renumber into Sprint's CIDR block? If we're serious > about provider based numbering, isn't that what's called for? why do we need to renumber everyone to help with the current problem? It seems pretty clear from Andrew's numbers that if we took care of all the /24s that are being announced, that'll give us probably 5 years. If ISPs announced a few /16s, or /17s or /19s or /20s, I don't think we'll be operating in crisis mode right now. Since you mentioned CoREN networks, and we are one of them, let me ask this. Does MCI have enough CIDR blocks to renumber entire CICNet? I'll try to start renumbering as soon as I see enough address space to renumber U of Chicago, Norte Dame, U of Wisconsin-Madison, U of Wisconsin Milwaukee, U of Illinois Urbana- Champagne, U of Illinois-Chicago, Indiana Univ., Ohio State, Penn State, WiscNet, IndNet, etc. After all, let's institute provider based addressing from top to bottom. Then let's see how much address space CoREN networks will need. Since it's virtually impossible to renumber at a drop of the hat, there'll be time when these networks will have their old address blocks and new ones. Do we actually have that much address space left? But seriously, what we need to concentrate, IMO, is to cut down on the /24s. We are one of the culprits. According to the last set of figures, we are responsible for about 1500 /24s that are being announced. Our CIDR blocks have been chopped up like diced onions while going from 3 AS -> 1 AS -> 3 AS transition over last few years, but we are doing something to change this by renumbering. This doesn happen overnight, and it'll take next 6 months or so to get this finished. But, I think we can cut down the announcements of /24s to < 150 or so. Now, let's say that everyone annoucing bunch of /24s cut down their /24 announcement by 66%. That should buy us enough time to develop a less painful alternative. What say you, sirs? -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 11:38:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05459; Fri, 8 Sep 1995 11:38:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA17819; Fri, 8 Sep 1995 11:35:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA17813; Fri, 8 Sep 1995 11:25:48 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04726; Fri, 8 Sep 1995 11:25:37 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id VAA02179; Thu, 7 Sep 1995 21:25:23 -0400 Date: Thu, 7 Sep 1995 21:25:22 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: Sean Donelan , big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 7 Sep 1995, Dorian Rysling Kim wrote: [much ranting and raving deleted] > we are responsible for about 1500 /24s that are being announced. Our CIDR . . . . > < 150 or so. Now, let's say that everyone annoucing bunch of /24s cut Hm... I do believe these two number have the decimal in the wrong place. Make that about 150, and about 15.. :) -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 13:18:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09670; Fri, 8 Sep 1995 13:18:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA17965; Fri, 8 Sep 1995 13:15:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA17936; Fri, 8 Sep 1995 12:55:11 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08712; Fri, 8 Sep 1995 12:54:15 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id WAA19175; Thu, 7 Sep 1995 22:41:56 -0400 Date: Thu, 7 Sep 1995 22:41:55 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Time to move on... In-Reply-To: <9509061635.AA04598@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Wed, 6 Sep 1995, Noel Chiappa wrote: > It's pretty clear we are making no headway here. I suggest that all > the large providers unilaterally filter smaller routes. When people start > losing connectivity, perhaps they will be more inclined to listen. > > Noel > How do you define small? If you are willing to define a small route, you should at the same time define the size of the ISP which is "large enough" to route. Suppose an organization has a class B (/16) address but has two hosts on it. Is such a route "bigger" or "more important" than a class C (/24) address with 200 hosts on the Internet? What you are proposing will solve nothing except create a roaring business in class B (sub-)address trades. In fact I think it might be the up and coming business to be in! An address broker! I think at this time the only solution left is routing advertisement fees. Arbitrary anything will just cause the problem to balloon somewhere else. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 13:37:29 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10620; Fri, 8 Sep 1995 13:37:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19592 Fri, 8 Sep 1995 12:22:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA17882; Fri, 8 Sep 1995 12:15:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA17876; Fri, 8 Sep 1995 12:12:43 +1000 Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06807; Fri, 8 Sep 1995 12:12:36 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (8.6.11/necom-mx-rg); Fri, 8 Sep 1995 11:06:58 +0859 From: Masataka Ohta Message-Id: <199509080207.LAA17836@necom830.cc.titech.ac.jp> Subject: Scalability of routing To: tli@cisco.com (Tony Li) Date: Fri, 8 Sep 95 11:06:56 JST Cc: w-rolph@ds.mc.ti.com, big-internet@munnari.OZ.AU In-Reply-To: <199509072050.NAA01107@greatdane.cisco.com>; from "Tony Li" at Sep 7, 95 1:50 pm X-Mailer: ELM [version 2.3 PL11] Precedence: bulk > I decided that I should reply again and simply present the facts: > > The routing table can and has doubled every 9-10 months. See RFC > 1519, page 8. The routing table is stored in (a) memory. Processing > the routing table requires CPU cycles. > > The aggregate bandwidth as seen at a backbone POP doubles every 18 > months. Supporting bandwidth requires switching. The average packet > size is roughly constant. Switching requires CPU cycles. Switching > references the routing table (sometimes indirectly). > > Computing power doubles every 24 months. Memory sizes double roughly > every 24 months, except they go up by factors of four (and no, that's > not 48 months). That is, routing table size has been successfully scaled to support O(N) flat routing. > No one claims that current routers are at the bleeding edge of > computer technology today. The long term strategy is the problem. The problem is that, complex hierarchical routing protocols makes constant factor large without any benifit. Don't say we need more resource only because your O(log(N)) protocol wastes a lot of resource. 16MB memory can hold 1M entries of 128bit addresses. Use it wisely. With simple addressing architecture, small number of hierarchies and fixed boundary between hierarchies, we can save a lot of CPU and memory resource. Considering that, even in the long term, N is unlikely much greater than 2^32, routing table scalability of O(sqrt(N)), or O(N) with very small constant factor, is enough. That is, provider-level-flat routing scales. Detailed analysis is given in draft-ohta-ipv6-addr-arch-00.txt. And, then, the simplicity allows us to enjoy geographical optimality and multi-homing without magical renumbering. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 14:33:13 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13091; Fri, 8 Sep 1995 14:33:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23546 Fri, 8 Sep 1995 14:01:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA18031; Fri, 8 Sep 1995 13:55:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA18014; Fri, 8 Sep 1995 13:51:36 +1000 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11183; Fri, 8 Sep 1995 13:51:19 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA20605; Thu, 7 Sep 95 23:10:58 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA07301; Thu, 7 Sep 95 22:50:59 CDT Date: Thu, 7 Sep 95 22:50:59 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9509080350.AA07301@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: request for info - Precedence: bulk I'm chewing over some rather fuzzy and possibly not very workable ideas (the good bits are stolen from Noel!), and have generously gotten a few spare cycles from some very overloaded people. At this point, I'd find it useful to have some real data about backbone loads and topology. So, if anyone out there who a) drives default free routers and b) has a few spare cycles (mutually exclusive, I expect, alas) could point me at some information about current backbone topolgy, things like how many routes are used to forward packets over a time frame, in what boxes in the topology, that sort of thing, I would be exceedingly grateful. Pointers to pre-existing reports would be wonderful, or if you could write even some brief impressions in a spare moment, that would be great too. Thanks, Andrew From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 15:42:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB15962; Fri, 8 Sep 1995 15:42:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA18139; Fri, 8 Sep 1995 15:35:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA18133; Fri, 8 Sep 1995 15:34:40 +1000 Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15672; Fri, 8 Sep 1995 15:33:37 +1000 (from bmanning@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-17) id ; Thu, 7 Sep 1995 22:32:51 -0700 From: bmanning@ISI.EDU (Bill Manning) Message-Id: <199509080532.AA25759@zephyr.isi.edu> Subject: Re: Routing tables & what to do about them To: daniel.padwa@gs.com (Danny Padwa) Date: Thu, 7 Sep 1995 22:32:50 -0700 (PDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9509071459.AA11513@sls069.fi.gs.com> from "Danny Padwa" at Sep 7, 95 10:59:10 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 550 Precedence: bulk > > >>>>> "Bill" == bmanning writes: > Bill> (everyone, thats right, everyone will be asked to renumber > Bill> on a regular and periodic basis. ok?) > > > This brings up an interestig point......should we start pushing > vendors to make renumbering an easier task? > > - Danny > Yes. Without any doubt. Perhaps you would like to review ftp.isi.edu:/pub/bill/renumbering And comment. I'd like some feedback on the most efficent way to encourage vendors to make this an easier task. Suggestions? -- --bill From owner-Big-Internet@munnari.OZ.AU Fri Sep 8 20:59:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27403; Fri, 8 Sep 1995 20:59:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA18430; Fri, 8 Sep 1995 20:55:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA18402; Fri, 8 Sep 1995 20:38:45 +1000 Received: from relay2.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26990; Fri, 8 Sep 1995 20:38:41 +1000 (from dsiegel@rtd.com) Received: from seagull.rtd.com by relay2.UU.NET with SMTP id QQzghe16918; Fri, 8 Sep 1995 06:38:39 -0400 Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id DAA22561; Fri, 8 Sep 1995 03:23:27 -0700 From: Dave Siegel Message-Id: <199509081023.DAA22561@seagull.rtd.com> Subject: Re: Routing tables & what to do about them To: bmanning@ISI.EDU (Bill Manning) Date: Fri, 8 Sep 1995 03:23:26 -0700 (MST) Cc: daniel.padwa@gs.com, big-internet@munnari.OZ.AU In-Reply-To: <199509080532.AA25759@zephyr.isi.edu> from "Bill Manning" at Sep 7, 95 10:32:50 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1502 Precedence: bulk > > This brings up an interestig point......should we start pushing > > vendors to make renumbering an easier task? > > Yes. Without any doubt. Perhaps you would like to review > > ftp.isi.edu:/pub/bill/renumbering > > And comment. I'd like some feedback on the most efficent way to > encourage vendors to make this an easier task. Suggestions? We are planning on providing DHCP services *for* our new customers (anybody coming up on 56K or higher) at no cost. Unfortunately, there is no public domain DHCP server for BSDI, FreeBSD, or Solaris (what we run, here), and even commercial versions are hard to find. Chances are, we may be developing one ourself. Chances are, we might distribute it PD. I also plan on writing a number of documents to explain why it is important to the Internet that our customers take us up on our free offering for network design consultation, and free server access. It would be more marketing driven than that last sentence, which sounds terrible to a customer, naturally. I would be willing to share these as well, as they would no doubt be well sought by other ISP's in the same shoes. This is rather academic, of course, but educational tools, as well as utilities to make things easiest, isn't a bad way to start. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 00:21:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02960; Sat, 9 Sep 1995 00:21:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA18630; Sat, 9 Sep 1995 00:15:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA18624; Sat, 9 Sep 1995 00:11:18 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02481; Sat, 9 Sep 1995 00:09:33 +1000 (from w-rolph@ds.mc.ti.com) Received: from news.ti.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA09071 Fri, 8 Sep 1995 21:48:22 +1000 (from w-rolph@ds.mc.ti.com) Received: from ganesh.mc.ti.com ([157.87.4.175]) by gate.ti.com (8.6.12/) with SMTP id GAA06182; Fri, 8 Sep 1995 06:39:43 -0500 Received: by ganesh.mc.ti.com; id AA05170; Fri, 8 Sep 1995 07:39:10 -0400 Message-Id: <9509081139.AA05170@ganesh.mc.ti.com> X-Sender: a722756@mail-ad.mc.ti.com X-Mailer: Windows Eudora Version 2.1.1 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 08 Sep 1995 07:39:11 -0400 To: bmanning@isi.edu (Bill Manning), daniel.padwa@gs.com (Danny Padwa) From: "W. Donald Rolph III" Subject: Re: Routing tables & what to do about them Cc: big-internet@munnari.OZ.AU Precedence: bulk >And comment. I'd like some feedback on the most efficent way to >encourage vendors to make this an easier task. Suggestions? > >-- >--bill > > Bill, I think I learned this from you. If a physical entity's id will change frequently, then it is best to refer to it by an alias. The users hard code the alias, and the network manager changes the alias as needed. If people are going to have to change their local address (a position of which I am still doubtful), then the user must refer to that address with an alias, and the network manager can change the alias as required. Note - DHCP almost does this, but I argue is seriously flawed in its present form, and needs some major work to make it industrial strength. Further, as has been discussed in some of the side conversations, this begs the problems of the large servers. A better approach would be to leave the users ip address constant, but have that be an alias which gets mapped to the "true or present addrress". I still believe that such aliasing can be handled at boundary gatways with little impact, save eliminating the abiltiy to address external entities by numeric ip number. Regards. Don Rolph w-rolph@ds.mc.ti.com WD3 MS10-13 (508)-236-1263 From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 07:35:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18288; Sat, 9 Sep 1995 07:35:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA19117; Sat, 9 Sep 1995 07:35:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA19111; Sat, 9 Sep 1995 07:34:49 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18210; Sat, 9 Sep 1995 07:34:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21086; Fri, 8 Sep 95 17:29:27 -0400 Date: Fri, 8 Sep 95 17:29:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509082129.AA21086@ginger.lcs.mit.edu> To: bass@linux.silkroad.com, bilse@eu.net Subject: Re: oops -- wrong message Cc: bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: Tim Bass please do not call the CIDR solution 'aggregation'. Please refer to it as 'provider based aggregation'. As many of us have tried, falling on ears, to point out, CIDR is not "provider-based aggregation" so much as "topology-based aggregation". It is quite possible, totally within CIDR, to deploy exchange points and assign addresses relative to them. So your contention that CIDR == provider-based addressing is quite incomplete. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 07:55:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18899; Sat, 9 Sep 1995 07:55:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA19168; Sat, 9 Sep 1995 07:55:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA19148; Sat, 9 Sep 1995 07:47:42 +1000 Received: from cu.nih.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18687; Sat, 9 Sep 1995 07:47:39 +1000 (from RAF@CU.NIH.GOV) Message-Id: <9509082147.18687@munnari.oz.au> To: dsiegel@rtd.com Cc: big-internet@munnari.OZ.AU From: "Roger Fajman" Date: Fri, 08 Sep 1995 17:45:37 EDT Subject: Re: Routing tables & what to do about them Precedence: bulk > Unfortunately, there is no public domain DHCP server for BSDI, FreeBSD, or > Solaris (what we run, here), and even commercial versions are hard to find. Have you looked at the ones mentioned in the DHCP FAQ? It's at http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html It lists quite a number of implementations. From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 08:35:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20134; Sat, 9 Sep 1995 08:35:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA19221; Sat, 9 Sep 1995 08:35:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA19203; Sat, 9 Sep 1995 08:17:31 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB19573; Sat, 9 Sep 1995 08:17:29 +1000 (from dsiegel@rtd.com) Received: from RTD.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA21671 Sat, 9 Sep 1995 08:17:26 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id PAA28557; Fri, 8 Sep 1995 15:07:07 -0700 From: Dave Siegel Message-Id: <199509082207.PAA28557@seagull.rtd.com> Subject: Re: oops -- wrong message To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 8 Sep 1995 15:07:06 -0700 (MST) Cc: bass@linux.silkroad.com, bilse@eu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9509082129.AA21086@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 8, 95 05:29:27 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1374 Precedence: bulk > From: Tim Bass > please do not call the CIDR solution 'aggregation'. Please refer to it as > 'provider based aggregation'. > > As many of us have tried, falling on ears, to point > out, CIDR is not "provider-based aggregation" so much as "topology-based > aggregation". It is quite possible, totally within CIDR, to deploy exchange > points and assign addresses relative to them. So your contention that CIDR == > provider-based addressing is quite incomplete. Not that this is worth nit-picking over, but it probably *is* more appropriate to simply refer to CIDR as aggregation. Simply put, it is the ability to "collapse" multiple routes into a single announcement. If the Internic were still assigning addresses to ISP's instead of NSP's, it would not change what CIDR is, and what it allows you to do. How CIDR is implemented determines whether or not it becomes provider-based aggregation, topology-based aggregation, or whatever. It's pretty apparent that the "best" way to implement this tool called "CIDR" is what we are all getting in heated discussions over. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 09:55:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22772; Sat, 9 Sep 1995 09:55:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA19332; Sat, 9 Sep 1995 09:55:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA19315; Sat, 9 Sep 1995 09:52:43 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22579; Sat, 9 Sep 1995 09:52:41 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.59] (dial-cup2-27.iway.aimnet.com [204.118.88.57]) by aimnet.com (8.6.12/8.6.12) with SMTP id QAA24897; Fri, 8 Sep 1995 16:51:13 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Sep 1995 16:52:29 -0700 To: Dave Siegel From: Dave Crocker Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Precedence: bulk At 3:07 PM 9/8/95, Dave Siegel wrote: >Not that this is worth nit-picking over, but it probably *is* more >appropriate to simply refer to CIDR as aggregation. Dave, I think it depends on the conversation. If one wants to talk about general approaches, then yes. If one wants to debate provider-based versus geographic then there is the real and pressing barrier that provider-based is tightly integrated into all aspects of cidr's current details. It doesn't have to be, but it is. It would be helpful if our discussions and debates could make the distinction so that both approaches could comfortably be treated as safely fitting within cidr (since they do or at least can.) >It's pretty apparent that the "best" way to implement this tool called "CIDR" >is what we are all getting in heated discussions over. Well, I think your intent and its objective truth is exactly right. Now, how do we have these discussions conducted in a way that supports your view? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 09:58:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22848; Sat, 9 Sep 1995 09:58:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA19354; Sat, 9 Sep 1995 09:58:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA19312; Sat, 9 Sep 1995 09:52:40 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22572; Sat, 9 Sep 1995 09:52:36 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.59] (dial-cup2-27.iway.aimnet.com [204.118.88.57]) by aimnet.com (8.6.12/8.6.12) with SMTP id QAA24858; Fri, 8 Sep 1995 16:50:51 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 8 Sep 1995 16:52:07 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Precedence: bulk At 2:29 PM 9/8/95, Noel Chiappa wrote: >As many of us have tried, falling on ears, to point >out, CIDR is not "provider-based aggregation" so much as "topology-based >aggregation". It is quite possible, totally within CIDR, to deploy exchange Noel, Sorry, no. Again. CIDR gives no information about the general topology of the net. As a simple example, if I am multihomed it gives information about only one of my connections. Further, it does not necessarily give any indication of the topology of the next "layer" upstream except perhaps one out of many attachments that THAT layer might have, and so on. An alternative term that seemed appealing for awhile was "attchment-based" address, until I realized that it does not reflect all my attachments, only one. If I drop the provider that my cidr address is tied to but keep the others, then I have to give up my cidr address. Hence the single-most crucial characteristic of the cidr address is who the provider is. If that ain't provider-based, what is? d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 10:35:54 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23897; Sat, 9 Sep 1995 10:35:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA19410; Sat, 9 Sep 1995 10:35:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA19392; Sat, 9 Sep 1995 10:24:44 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23585; Sat, 9 Sep 1995 10:24:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21511; Fri, 8 Sep 95 20:24:37 -0400 Date: Fri, 8 Sep 95 20:24:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509090024.AA21511@ginger.lcs.mit.edu> To: dcrocker@brandenburg.com, jnc@ginger.lcs.mit.edu Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: Dave Crocker CIDR gives no information about the general topology of the net. Addresses of any kind never give full and complete topological information. However, CIDR addresses does give some topological information, since unless there has been a partition (and this system does not automatically reasssign addresses as a way of dealing with partitions) A.1 and A.2 are contained within some larger topological entity, A. Etc, etc. if I am multihomed it gives information about only one of my connections. Addresses are only useful insofar as they allow the routing to get packets there. It is perfectly feasible to have a single CIDR address and still get traffic through multiple connections. That's the bottom line. (Also: In geographic addressing, if a site is multihomed in two different geographic regions, its address (singular) will "give information about only one of [its] connections".) Hence the single-most crucial characteristic of the cidr address is who the provider is. Unless you are using CIDR to name other kinds of toplogical aggregate, such as exchange points, in which case there is nothing about providers anywhere in your address. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 10:55:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24535; Sat, 9 Sep 1995 10:55:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA19464; Sat, 9 Sep 1995 10:55:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA19446; Sat, 9 Sep 1995 10:40:25 +1000 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24196; Sat, 9 Sep 1995 10:40:11 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA01253; Fri, 8 Sep 95 20:00:13 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA19042; Fri, 8 Sep 95 19:40:14 CDT Date: Fri, 8 Sep 95 19:40:14 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9509090040.AA19042@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: oops -- wrong message Precedence: bulk I think what Noel meant was 'to the extent that CIDR works it is topology based.' Certainly CIDR is being administrated in a provider based fashion, but I'm not convinced that's relevant. Multi-homing certainly breaks the topological nature of CIDR addressing -- to exactly the extent that it breaks CIDR. CIDR attempts to model the network as a 2^N-ary tree, and succeeds in its goals exactly to the extent that the network's topology can be mapped onto that 2^N-ary tree. That's topological, I'd say. Andrew From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 11:15:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25134; Sat, 9 Sep 1995 11:15:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA19506; Sat, 9 Sep 1995 11:15:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA19478; Sat, 9 Sep 1995 10:57:35 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24564; Sat, 9 Sep 1995 10:57:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21610; Fri, 8 Sep 95 20:57:17 -0400 Date: Fri, 8 Sep 95 20:57:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509090057.AA21610@ginger.lcs.mit.edu> To: RAF@cu.nih.gov, bass@linux.silkroad.com Subject: Re: Keeping the Internet goingOA Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: Tim Bass CIRD was touted as a 'temporary' fix for B address space depletion and has been manuplated into the 'provider based, provider controlled' Interet paradigm Perhaps you could explain (away?) a few inconvenient facts which seem at odds with your somewhat unique view of what's going on. #1 - About your claim that "CIDR was touted as .. a fix for B .. depletion", which makes the implicit claim that later use for controlling routing table growth was a redirection of CIDR, the RFC which makes CIDR an Internet standard, RFC-1519, says: As the Internet has evolved and grown over in recent years, it has become evident that it is soon to face several serious scaling problems. These include: 1. Exhaustion of the class B network address space. ... 2. Growth of routing tables in Internet routers beyond the ability of current software, hardware, and people to effectively manage. 3. Eventual exhaustion of the 32-bit IP address space. ... This memo attempts to deal with these problems by proposing a mechanism to slow the growth of the routing table and the need for allocating new IP network numbers. To most of us, I guess, this shows that the intention to use CIDR to attack two problems, not *just* exhaustion of class B space, was clearly stated in the CIDR document. Also, your use of the word "manipulate" suggests some desire to quietly change the use of CIDR, after sucking people in on some claim that it's intended for some other purpose. Kind of dumb of them to hide their alternative usage like that right up front in the introduction, isn't it? #2 - Your contention that topological aggregation (since this is what CIDR is, really) is some sort of "'provider based, provider controlled' Interet paradigm", implying that it is being pushed because it serves the interests of the large providers. Let's look at the following sentence: "The first step in making routing practical in such a [large] network is to go to an area routing strategy." This is a perfect description of the goal and mechanism of CIDR, and it is from "Adaptive Routing Algorithms for Distributed Computer Networks", John McQuillan's PhD thesis. (I'm not sure if you all know who McQuillan is, but he's the guy who designed the routing algorithm used in the ARPAnet for many years, the "link-state" algorithm, which is the basis for much work in routing since, such as IS-IS, OSPF, and IDPR.) That document is dated May, 1974, i.e. over 20 years ago. So, would you explain to me how this person's description of "area routing" as "the first step in making routing practical in [a large] network" is a recent plot on the part of large providers? (Perhaps they have time-machine technology which they are also hiding from us?) Moving on, we find the thought: "For routing in large networks the reduction of routing information is realized through a hierarchical clustering of network nodes. ... non-optimally selected clustering structures may lead to very little table reduction." This is from "Hierarchical Routing for Large Networks", by Leonard Kleinrock and Farouk Kamoun. (Again, for those of you who don't know who Kleinrock is, he is at UCLA, and has done much imporant work on networks over the years, including his classic on "Queueing Systems".) This document is from 1977. So, once again, we see people pointing to topological aggregation as the solution to making the routing scale in very large networks, 20 years ago. I could go on, but it's pointless. I will close by noting that I've been talking about hierarchical topological aggregation as being needed to make the routing work once the Internet got to global scale for many years now. So I take great personal exception to your charge that this is being put foward to create a "provider controlled" Internet. It is common knowledge that the current CIDR (provider based) paradigm does not require renumbering existing address space in the short term. Oh. So all the providers who say their routing tables are overflowing are just incompetent, and don't know how to make their equipment work right, eh? Never give any organization a blanket card blanche to design any system based on fear... history teaches us that this is very dangerous and the Internet is no exception. Right, so we should avoid basing out designs on fear of provider-based addressing. Almost everyone agrees that: ... 2) There a better alternatives than provider based aggregation; ... 4) Renumbering is not really necessary in the short term. This does not correspond to what I hear, which is the exact opposite; almost everyone agrees that there are no practical alternatives to topology-based addresses, and a certain amount of renumbering (we do *not* have to renumber every last site) will be needed in short order. What is objectionable and continues to be objectionable is the community that supports provider based aggregation telling everyone that disagrees to ... go elsewhere, you are out of order. Discussion of alternatives to CIDR has been placed on the Big-Internet mailing list, which is where the original CIDR discussion was (before there was even a CIDRD). The IETF prefers to keep a given discussion in one place, not let it sprawl over every vaguely related mailing list in sight. Freedom of technical expression seems to have been derailed on the information superhighway. We keep hearing... you can discuss alternative to CIDR and provider based aggregation, but not anyplace with an audience. Thank you for the ' opportunity to express our opinions elsewhere ' ;-) You will discover that the Big-Internet list is as large, and probably larger, forum than CIDRD. I can't be bothered to drag over the lists, and run 'wc' on them, and since you don't appear to believe that anyone who tells you anything has a clue anyway, I suggest you do this yourself so you know we're not trying to con you. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 11:35:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25811; Sat, 9 Sep 1995 11:35:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA19544; Sat, 9 Sep 1995 11:35:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA19526; Sat, 9 Sep 1995 11:20:46 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25284; Sat, 9 Sep 1995 11:20:26 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id SAA10720; Fri, 8 Sep 1995 18:17:49 -0700 From: Dave Siegel Message-Id: <199509090117.SAA10720@seagull.rtd.com> Subject: Re: oops -- wrong message To: dcrocker@brandenburg.com (Dave Crocker) Date: Fri, 8 Sep 1995 18:17:49 -0700 (MST) Cc: dsiegel@rtd.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: from "Dave Crocker" at Sep 8, 95 04:52:29 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4714 Precedence: bulk > >It's pretty apparent that the "best" way to implement this tool called "CIDR" > >is what we are all getting in heated discussions over. > > Well, I think your intent and its objective truth is exactly right. > Now, how do we have these discussions conducted in a way that supports > your view? I think we need to break the problem down into seperate peices, and attack each one as a seperate issue. This seems to be the best way to handle large problems as a general rule. I DO NOT think that we should create multiple work groups, however. That will no doubt be counter productive, which I think is what you are asking above, but I am choosing to ignore that aspect, and get down to work. Breaking the discussions down into categories, I see: CIDR didn't work like we thought it would A. Is the idea a failure at it's most basic level? The answer appears to be no. B. Why didn't it work exactly as we thought it would, though? 1. Because we need more aggregation than we are getting currently. It is less effective because we are still handing out lot's of Class C's, and the networks cannot be aggregated as efficiently when a customer moves. 2. Our initial design for allocation of CIDR blocks turned out to be non-optimal. In specific instances, even dual-homing causes additional routes to be added to the core. C. CIDR didn't affect some 18,000 Class C's already in use. Analyzation: A. CIDR wasn't the failure, the design of the addressing scheme was B. We didn't know what we'd see until we did it. That's fine. How do we proceed with the problems we are seeing. 1. Two possible solutions. Have customers renumber, or adjust ip allocations so that CIDR still fits. The former option is the easy way out for the Internet engineer (this already presumes provider-based addressing), the latter encompasses the geoghraphical assignment vs. provider-based arguments, and other allocations schemes which all of us would like to see, but no one has any ideas on. 2. Noel's discussion of AAB's seems to fit the model well, combined with Sean's idea of a way to implement them using communities, but I suspect the ongoing engineering attention required to setup and maintain these will be overwhelming in practice, unless we can come up with a way to make it almost automatic. We've been talking a lot of theory on this matter, but I suspect it's probably about time to narrow the focus, and look at *actual* ways it could be accomplished, and rather than adjusting the scope (zooming in and out) we need to just take a place like mae-east, and figure out how we might be able to clean up announcements there, and then pick up another isolated case, apply the same design, see how the two might integrate/grate with each other, and then zoom out and look at the big picture. C. The only way to get rid of those 18,000some /24's is to have the customers using those blocks to renumber into a CIDR block. I seriously doubt that any [hairbrained] engineering scheme we come up with will allow signifigant CIDRization of those routes. (but if we decide to look at this, it should be taken completely seperate from the initial view of the usage of an AAB, rather than trying to necessarily apply the AAB model) I don't think this renumbering should be started until we have the details taken care in terms of engineering of address allocations, and/or Abstracted Action Boundaries. It would be helpful to figure out what to renumber them *to* before attempting force renumbering. What we have here is *several* plans of attack. It is my feeling that *all* the options should be approached seriously, and when a workable solution is arrived at, most of the ideas should be implemented. There won't be one catch-all solution. Most likely all of them will have to be used at one level or another in order for growth to be controlled as we'd like. Dave ps. I have not excluded encap as a solution to a few of these problems, but I'm unsure how it could be applied with a "no downtime" scenario, nor if it would solve the problem at all. I could only focus on a couple things, so I decided to let someone else focus on that one. ;-) pps. Please don't hack at the wording, or "in-accurate" phrasing in this message. It only serves to distract from the meaning of the email, which is to show the problem broken down into components, and applications of current discussions to those seperate components. -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 12:16:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26953; Sat, 9 Sep 1995 12:16:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA19621; Sat, 9 Sep 1995 12:15:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA19615; Sat, 9 Sep 1995 12:15:25 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26923; Sat, 9 Sep 1995 12:15:18 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id WAA25354; Fri, 8 Sep 1995 22:14:35 -0400 Date: Fri, 8 Sep 1995 22:14:33 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Robert Moskowitz Cc: Andrew Partan , Dave Siegel , big-internet@munnari.OZ.AU Subject: Re: Geographinc addressing In-Reply-To: <9509061122.AA04992@clncrdv1.is.chrysler.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > This is changing rapidly as the largest organizations are installing TCP/IP > networks to match their size. These networks are moving more data over less > bandwidth than the SNA networks BECAUSE THEY DO NOT USE VIRTUAL CIRCUITS. I can not get my IBM SNA person to agree with the above statement. He insists that SNA is more efficient when it comes to bandwith utilization. I will however not contest your statement since my personal knowledge of SNA internals is extremely limited. > > BTW, have you ever configured even a dozen 3745 nodes in an SNA network? > Have you ever worked out a SNI interface between two SNA networks? Our SNA > network is very stable now and actually shrinking. Back in its hey days, it > took 8 people to manage 18 images and around 50 FEPs with about 2 dozen SNI > interfaces. How many IP heavyweights do you have???? Oh, and we were able > to actually make network changes on a monthly basis (including adding new > controllers and changing terminal definitions); our poeple really had their > act together! > > You actually WANT static routing? I'll show you static routing.... > > > Today we have moved around 20,000 of our users from coax attachments to > TN3270 via MVS/TCP. One person with a backup supports MVS/TCP on 18 images. > When you had SNA, how many "help desk staffers" did you have configuring those 20,000 users terminals? To be fair, you should include the time spent in maintaining the IP addresses and TCP/IP software of the users in the above equation. You have basically shifted the cost from a central department to user departments. I am pretty sure the new solution is MUCH more expensive to the Chrysler Corporation as a whole since I do not believe that all the 20,000 users would have needed a TCP/IP connection otherwise. I have two questions to which I would really want an answer. Are you willing to renumber the IP number of all the 20,000 users? Are you even willing to renumber the IP address of the 18 MVS hosts? Please do not throw stones at others and force them to renumber if you can not honestly answer yes to the above questions. > Robert Moskowitz > Chrysler Corporation > (810) 758-8212 > From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 12:18:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26980; Sat, 9 Sep 1995 12:18:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA19643; Sat, 9 Sep 1995 12:16:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA19612; Sat, 9 Sep 1995 12:11:05 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26744; Sat, 9 Sep 1995 12:10:39 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA04001 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Fri, 8 Sep 1995 22:10:04 -0400 From: Tim Bass Message-Id: <199509090210.AA04001@linux.silkroad.com> Subject: Re: oops -- wrong message To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 8 Sep 1995 22:10:04 -0400 (EDT) Cc: bilse@eu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9509082129.AA21086@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 8, 95 05:29:27 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5388 Precedence: bulk Provider Based Aggregation Paradigm ----------------------------- Provider based (like the current CIDR practice): 1) Address space allocated and assigned by IANA to providers who charge (in the future) for address space. Providers conspire to set pricing for address space and route advertisement (anti-trust). 2) Users of provider based address space must absorb all costs of renumbering (very bad for networks of any size) if users desire to change providers for any reason(s). Result: Most organizations will choose to stay with one service provider that aggregates their routes to avoid service problems. This will work direct against a competitive Internet market. 3) Providers will attempt (and have done so) to register large blocks of classless address space, also making market competition difficult and creates potential for monopoly. Registry based Aggregation (technically more complex) -------------------------- 1) Address space assigned directly to users by IANA; 2) Users choose service provider(s) and register network(s) with a registration authority that aggregates network(s) or other AS within provider AS domain(s). This process is automated and use RSA MD5 and other tools for security. 3) New (yet to be developed) routing protocol routes supernetted AS with modifications to IP header and inter-domain routing algorithm(s) as required. 4) Registration information distributed in the Internet using connection oriented data transfer. Finally, a non-aggregated approach ......... Virtual Route Processor ------------------------ 1) All routing exchange points, FIXs, CIXs, multi-homed AS, MIXs, GIXs, etc. that need full routing information have a robust scalable processor that runs the latest and greatest routing algorithm (BGP today). These processors are not memory nor CPU constrained like the current core commercial routers and are based on an open architecture (UNIX). 2) This processors create a 'virtual routing database' that off-loads the storage of the route table (memory constrants) and route re-calculation (CPU constraints). 3) A new protocol is developed that allowed switched based router to communicate with the 'virtual routing database' in a robust reliable manner (the adjunct processor is physically connected i.e. on an adjacent subnet). 4) This architecture basically moves the 'route processor' off the core routers ( sorry router vendors , you are moving to slow ) and into adjunct UNIX processors. CPU power is increasing at about the same rate or faster than the growth of the Internet. Memory and storage prices are also proportional, but much less of course... BUT any decent modern UNIX platform with a RAM compliment could store the routing tables and do the calculations. 5) The router now does 'fast switching' except when it has to communicate with the adjunct 'route processor'. Of course, this architecture is similar to a major vendors product, except memory and CPU power is not constrained (like the current 64M constraint, et. al.) ________________________________________________________________- The real point is, ladies and gentlemen is that there are much better ways to build a scalable robust Internet than the current proposed CIDR 'best practices' as proposed. CIDR could be modified to not be provider based, but this approach has seen violent resistance time and time again (mostly by providers and router vendors, hmmmm) Provider based 'best practices' are weak technically and socially. Furthermore, commercial router manufactors are lagging far behind the silicon processing power curve and their products are slow to upgrade for a small market. This mandates that for core routers it may be necessary to move route processing off the router platform (even if the Internet community aggregates this is probally the lowest risk way to proceed). There is no rational reason for building a future global Internet based on provider based and controlled route aggregation. Furthermore, it is intolerable that WGs in the IETF call alternative technical solutions 'out of order' yet rarely call low, debasing personal attacks by WG proponents and advocates 'out of order'. These issues concern all users of the network. The Internet Protocol does not belong to the IETF nor the Internet Society nor commercial service providers, it belongs to the users. -Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 12:36:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27680; Sat, 9 Sep 1995 12:36:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA19690; Sat, 9 Sep 1995 12:35:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA19680; Sat, 9 Sep 1995 12:31:04 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27430; Sat, 9 Sep 1995 12:30:59 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id WAA25484; Fri, 8 Sep 1995 22:30:09 -0400 Date: Fri, 8 Sep 1995 22:30:08 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <199509071055.DAA07632@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 7 Sep 1995, Tony Li wrote: > All memory is not created equal. Just off the cuff, there's cache, > SRAM, Synchronous DRAM, EODRAM, Page Mode DRAM, Slow old PC Dram, etc. > I could probably name 6 more if was a hardware engineer. They vary in > cost and sizes. Some combinations simply do not exist (can you say > "16Mb of D-cache" with a straight face?). > OK. Makes sense. One of the larger L2 cache I have seen is 4MB on the DEC Alpha workstations and 112 KB of on-chip caches. Still I am confused as to why one lookup from slow RAM takes more time than several lookups in the RADIX tree from fast RAM. Once the lookup has completed, all the rest of the forwarding computation can be done on much faster hardware, the same as now. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 12:55:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28218; Sat, 9 Sep 1995 12:55:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA19747; Sat, 9 Sep 1995 12:55:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA19726; Sat, 9 Sep 1995 12:44:24 +1000 Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27864; Sat, 9 Sep 1995 12:44:14 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id WAA10349 for big-internet@munnari.oz.au; Fri, 8 Sep 1995 22:44:11 -0400 Date: Fri, 8 Sep 1995 22:44:11 -0400 From: Vadim Antonov Message-Id: <199509090244.WAA10349@titan.sprintlink.net> To: big-internet@munnari.OZ.AU Subject: Re: oops -- wrong message Precedence: bulk How about stopping the silliness? It is as clear as 2x2 that aggregation is equivalent to picking a tree in a graph. Attempting to do "topology independent" aggregation is very similar to attempts to find a planar graph containing C(5). It simply does not work, not because of conspiracy of mathemeticans but because of the logics. The topology of current Internet is very much tree-like, or, more specifically, a tree of "layers", every one is a mesh, not participating in routing between higher-level meshes. No matter how you try to pick a tree in topology like that you end up with "provider-based" aggregations, as those "meshes" generally belong to the providers. Of course, another approach is to fix the topology by adding tunnels but i'm not aware of any piece of hardware able to do encapsulation at even fractional T-3. Also, it leads to other inefficiences, and increases the number of paths, thus loading the routing engines even more. Also, tunnels are very "interesting" economically. The exchange-point-based aggregation is silly, as it breaks down in most spectacular ways in case of trivial single-point failures. So. For now the "provider-based" aggregation is the only solution which does not conflict with elemntary logic and does not require hypothetic hardware or radically new software. If anybody can prove that statement wrong, you're welcome. Critique without offering alternatives which do not contain demonstrable flaws in logic is nothing more than pathetic whining. --vadim From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 12:57:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28304; Sat, 9 Sep 1995 12:57:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA19771; Sat, 9 Sep 1995 12:56:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA19723; Sat, 9 Sep 1995 12:43:00 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27852; Sat, 9 Sep 1995 12:42:56 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id WAA25579; Fri, 8 Sep 1995 22:42:05 -0400 Date: Fri, 8 Sep 1995 22:42:05 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Robert Moskowitz Cc: "Dave O'Leary" , big-internet@munnari.OZ.AU Subject: Re: large site renumbering (was Re: Geographic addressing) In-Reply-To: <9509071120.AA00579@clncrdv1.is.chrysler.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 7 Sep 1995, Robert Moskowitz wrote: > In '96 we will have three rollouts going on that will give us an opurtunity > to make this easy. First is the upgrade from LAN Workplace 4.2 to 5.0. > Second is the upgrade from Windows 3.11 to Windows 95, and last is the > introduction of NT Workstation. All of these support DHCP. We are looking > into our options to add DHCP servers at the same time that we upgrade these > items. > > Our challenge is two fold. Which DHCP server? And how to best handle > server location. The latter will mean forwarding DHCP requests across routers. > > Robert Moskowitz > Chrysler Corporation > (810) 758-8212 > I am curious, have you looked at WINS and how WINS can reply to DNS queries for local machines who obtained their IP address from DHCP? I was at an NT server class the past few days and they went into all the gory details of Microsoft's Domain model(s) and DHCP/WINS. DHCP is fine for small organizations but the instructor said it is not distributed enough to be useful in large organizations. DHCP servers lease out IP addresses to clients for fixed amounts of time. These leases are renewable if both the server and client agree. DHCP servers do not talk to each other and maintain their own sets of IP numbers. At times it is not clear which (if you have more than one) DHCP server will respond to a query. Also free addresses given to one DHCP server for leasing out can not be automatically used by another DHCP server if the second server runs out of numbers. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 12:58:06 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28327; Sat, 9 Sep 1995 12:58:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA19793; Sat, 9 Sep 1995 12:57:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA19732; Sat, 9 Sep 1995 12:50:58 +1000 Received: from ns.crynwr.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28154; Sat, 9 Sep 1995 12:50:46 +1000 (from nelson@crynwr.com) Received: by ns.crynwr.com (Linux Smail3.1.28.1 #4) id m0srFzg-000H97C; Fri, 8 Sep 95 22:50 EDT Message-Id: Date: Fri, 8 Sep 95 22:50 EDT From: nelson@crynwr.com (Russell Nelson) To: jnc@ginger.lcs.mit.edu Cc: RAF@cu.nih.gov, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9509090057.AA21610@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: Keeping the Internet goingOA Precedence: bulk Date: Fri, 8 Sep 95 20:57:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) ... 2) There a better alternatives than provider based aggregation; ... 4) Renumbering is not really necessary in the short term. This does not correspond to what I hear, which is the exact opposite; almost everyone agrees that there are no practical alternatives to topology-based addresses, and a certain amount of renumbering (we do *not* have to renumber every last site) will be needed in short order. But who gets forced to renumber? And why? Seems to me like a hard problem to solve. Why not set the free market to solving it? I've already noted (on com-priv) that one way to get back lots of IP addresses is to charge for them (forcing a below-market price surely creates a shortage). Well, one way to aggregate routes is to charge for unaggregated routes. When I got my leased line from NYSERNet, I offered to let them assign me an aggregated route. They shrugged, and let me keep my non-aggregated network that I'd gotten years ago (192.203.178). So now this route is occupying yet another routing slot on the backbone routers. Didn't cost *me* anything. Didn't cost NYSERNet anything. But I'm getting a direct benefit from that routing slot, because that means that everyone knows how to get to me. And if I'm getting a benefit, that means it has value to me. Value that I ought to be willing to pay for. Value that I might be willing to pay for, if renumbering is too difficult. Only I can make that decision. And only the router owners can decide how much a routing slot is worth. It all adds up: maybe routes are cheaper than renumbering, so not many people will renumber. That means the routes will grow. But that might make routes more expensive, so more people will renumber. Negative feedback, computed in real time using concurrent, distributed processing. -- -russ http://www.crynwr.com/~nelson Crynwr Software | Crynwr Software sells packet driver support | PGP ok 11 Grant St. | +1 315 268 1925 (9201 FAX) | America neither a Christian, Potsdam, NY 13676 | Jewish, Islamic, nor atheist (etc&) nation. This is good. From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 13:17:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28916; Sat, 9 Sep 1995 13:17:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA19845; Sat, 9 Sep 1995 13:15:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA19818; Sat, 9 Sep 1995 13:09:48 +1000 Received: from ns.crynwr.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28745; Sat, 9 Sep 1995 13:09:32 +1000 (from nelson@crynwr.com) Received: by ns.crynwr.com (Linux Smail3.1.28.1 #4) id m0srGGM-000H97C; Fri, 8 Sep 95 23:07 EDT Message-Id: Date: Fri, 8 Sep 95 23:07 EDT From: nelson@crynwr.com (Russell Nelson) To: bass@linux.silkroad.com Cc: jnc@ginger.lcs.mit.edu, bilse@eu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <199509090210.AA04001@linux.silkroad.com> (message from Tim Bass on Fri, 8 Sep 1995 22:10:04 -0400 (EDT)) Subject: Re: oops -- wrong message Precedence: bulk From: Tim Bass Date: Fri, 8 Sep 1995 22:10:04 -0400 (EDT) There is no rational reason for building a future global Internet based on provider based and controlled route aggregation. Sure there is -- it's cheaper. Imagine a different Internet, where CIDR was designed-in, renumbering was an accepted part of life, and we had tools to renumber a network in five seconds. The top-level netmask would be 0xf0.0.0.0. The core routers would have a sixteen-entry routing table. "Is it mine? Nope. Is it MCI's? Nope. Is it Sprintlink's? Ahhhh yes. Throw it out the interface closest to Sprintlink and let them worry about the carriage." At that point, there is no core router complexity problem. There are no fewer routes, but the people maintaining the routes and routers are being paid by their customers. And they're saving money from having simpler routing tables. They can pass these savings on to their customers. Money is not meaningless -- it's meaning comes directly from the life energy that a person trades for it. Wasting money is wasting a part of a person's life. -- -russ http://www.crynwr.com/~nelson Crynwr Software | Crynwr Software sells packet driver support | PGP ok 11 Grant St. | +1 315 268 1925 (9201 FAX) | America neither a Christian, Potsdam, NY 13676 | Jewish, Islamic, nor atheist (etc&) nation. This is good. From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 13:36:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB29596; Sat, 9 Sep 1995 13:36:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA19896; Sat, 9 Sep 1995 13:35:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA19867; Sat, 9 Sep 1995 13:18:33 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28993; Sat, 9 Sep 1995 13:18:22 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA25764; Fri, 8 Sep 1995 23:17:38 -0400 Date: Fri, 8 Sep 1995 23:17:37 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: George Herbert Cc: Tony Li , big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Routing tables & what to do about them In-Reply-To: <199509071823.AA24853@mail.crl.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 7 Sep 1995, George Herbert wrote: > > >which needs to get exponentially faster and exponentially bigger. > >Simultaneously. > > Ayup. But don't knock flat tables. > > -george > I am again confused. How can flat tables of size 256*256*256 grow at all (exponentially or otherwise) ? Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 13:37:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29640; Sat, 9 Sep 1995 13:37:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA19918; Sat, 9 Sep 1995 13:36:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA19873; Sat, 9 Sep 1995 13:24:02 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29243; Sat, 9 Sep 1995 13:23:57 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA25846; Fri, 8 Sep 1995 23:23:08 -0400 Date: Fri, 8 Sep 1995 23:23:08 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Vadim Antonov Cc: SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <199509072207.SAA08483@titan.sprintlink.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 7 Sep 1995, Vadim Antonov wrote: > I renumbered SprintLink backbone once (within the same > network # but with radically different numbering plan). > So it can be done and was done. Renumbering is not > a tragedy, just some work. > > --vadim > Did you also renumber all your SprintLink customers? Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 13:38:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29666; Sat, 9 Sep 1995 13:38:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA19940; Sat, 9 Sep 1995 13:38:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA19890; Sat, 9 Sep 1995 13:35:07 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29577; Sat, 9 Sep 1995 13:34:59 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA25872; Fri, 8 Sep 1995 23:34:17 -0400 Date: Fri, 8 Sep 1995 23:34:16 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Dorian Rysling Kim Cc: Sean Donelan , big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Thu, 7 Sep 1995, Dorian Rysling Kim wrote: > > This doesn happen overnight, and it'll take next 6 months or so to get > this finished. But, I think we can cut down the announcements of /24s to > < 150 or so. Now, let's say that everyone annoucing bunch of /24s cut > down their /24 announcement by 66%. That should buy us enough time to > develop a less painful alternative. What say you, sirs? > EXCELLENT. Can anyone with access to the information actually compute the possible reduction? Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 13:56:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00498; Sat, 9 Sep 1995 13:56:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA19998; Sat, 9 Sep 1995 13:55:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA19977; Sat, 9 Sep 1995 13:48:36 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00146; Sat, 9 Sep 1995 13:47:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22312; Fri, 8 Sep 95 23:46:39 -0400 Date: Fri, 8 Sep 95 23:46:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509090346.AA22312@ginger.lcs.mit.edu> To: bass@linux.silkroad.com, jnc@ginger.lcs.mit.edu Subject: Re: oops -- wrong message Cc: bass@cais.cais.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com Precedence: bulk From: Tim Bass CPU power is increasing at about the same rate or faster than the growth of the Internet. This statement is in direct contradiction to numbers given earlier, which said that routing tables are doubling every 9 months, whereas processor speed seems to double about every two years. Since this doesn't agree with your statement above, which of these is wrong? CIDR could be modified to not be provider based Oh. So what would it be based on? commercial router manufactors are lagging far behind the silicon processing power curve and their products are slow to upgrade for a small market. Since they are so inept, you should start a company to compete. It's a giant market, you should make a mint. Furthermore, it is intolerable that WGs in the IETF call alternative technical solutions 'out of order' As stated, the discussion was moved to Big-I. Post all the alternatives you want there. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 13:57:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00524; Sat, 9 Sep 1995 13:57:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA20022; Sat, 9 Sep 1995 13:56:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA19974; Sat, 9 Sep 1995 13:47:08 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00133; Sat, 9 Sep 1995 13:47:04 +1000 (from asp@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27396 Sat, 9 Sep 1995 13:46:59 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzgjv08341; Fri, 8 Sep 1995 23:45:30 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: oops -- wrong message To: bass@linux.silkroad.com (Tim Bass) Date: Fri, 8 Sep 1995 23:45:30 -0400 (EDT) Cc: jnc@ginger.lcs.mit.edu, bilse@eu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509090210.AA04001@linux.silkroad.com> from "Tim Bass" at Sep 8, 95 10:10:04 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 1340 Precedence: bulk > The real point is, ladies and gentlemen is that there are much better > ways to build a scalable robust Internet than the current proposed > CIDR 'best practices' as proposed. Best *current* practice. There are a lot of pipe dreams & a lot of folks working on things that might be working at some point in the future. However the future is not today; we need to keep things working today so that there will be a future. Current doubling time of the Internet is someplace between 5 & 9 months. Current doubling time of computers is someplace on the order of 18 months. If the Internet is doubling 2 to 3 times faster than computers, we are going to run out, unless we can figure out how to scale certain measures of Internet growth (like routing tables) to double on a slower scale - more like 18-24 months than 5-9 months. The only that that works today is renumbering or otherwise changing the addresses that your hosts appear to have (NAT boxes, various flavors of firewalls, and application level gateways all come to mind). If, in the future, something better comes along (something that permits expanded growth of the Internet with out corresponding growth of the routing tables), we can deploy it & get it working and change the current practice to be what ever the best is at that time. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 14:15:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01062; Sat, 9 Sep 1995 14:15:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA20078; Sat, 9 Sep 1995 14:15:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA20054; Sat, 9 Sep 1995 14:03:48 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00728; Sat, 9 Sep 1995 14:03:20 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzgjw09444; Sat, 9 Sep 1995 00:01:43 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: Routing tables & what to do about them To: root@kbs.netusa.net (Sanjay Kapur) Date: Sat, 9 Sep 1995 00:01:43 -0400 (EDT) Cc: dorian@cic.net, SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 8, 95 11:34:16 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 73 Precedence: bulk > EXCELLENT. I'm glad that you agree that renumbering does help. --asp From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 14:16:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB01090; Sat, 9 Sep 1995 14:16:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA20102; Sat, 9 Sep 1995 14:16:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA20051; Sat, 9 Sep 1995 14:02:22 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00683; Sat, 9 Sep 1995 14:01:52 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzgjw09304; Sat, 9 Sep 1995 00:00:14 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: Routing tables & what to do about them To: root@kbs.netusa.net (Sanjay Kapur) Date: Sat, 9 Sep 1995 00:00:14 -0400 (EDT) Cc: gherbert@crl.com, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: from "Sanjay Kapur" at Sep 8, 95 11:17:37 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 225 Precedence: bulk > I am again confused. How can flat tables of size 256*256*256 grow at all > (exponentially or otherwise) ? As I mentioned before, you need to do this (assuming that it works at all) with a table of 2^32, not 2^24. --asp From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 15:58:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04084; Sat, 9 Sep 1995 15:58:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA20243; Sat, 9 Sep 1995 15:55:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA20228; Sat, 9 Sep 1995 15:50:55 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03953; Sat, 9 Sep 1995 15:50:41 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzgkd20943; Sat, 9 Sep 1995 01:50:28 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: oops -- wrong message To: michael@junction.net (Michael Dillon) Date: Sat, 9 Sep 1995 01:50:27 -0400 (EDT) Cc: bass@linux.silkroad.com, jnc@ginger.lcs.mit.edu, bilse@eu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: from "Michael Dillon" at Sep 8, 95 10:48:05 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 663 Precedence: bulk > When you decouple the route processing boxes from the packet-forwarding Yes, when this is possible (& working) there are all sorts of things that one could do. However, its not there today. Also, what happens when your route processing box runs out of steam? Remember that the Internet is growing 2-3 times faster than computers are. If the stuff that your route processing box is handling is growing 2-3 times faster than you can expand this box, what then? > My understanding is that it is possible today to kludge together a UNIX > box running BGP and a Cisco 7000 as a packet forwarder. Nope; not possible today. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 16:00:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04240; Sat, 9 Sep 1995 16:00:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA20267; Sat, 9 Sep 1995 16:00:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA20225; Sat, 9 Sep 1995 15:41:53 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03761; Sat, 9 Sep 1995 15:41:36 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id WAA32464; Fri, 8 Sep 1995 22:48:06 -0700 Date: Fri, 8 Sep 1995 22:48:05 -0700 (PDT) From: Michael Dillon To: Andrew Partan Cc: Tim Bass , jnc@ginger.lcs.mit.edu, bilse@eu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 8 Sep 1995, Andrew Partan wrote: > Current doubling time of the Internet is someplace between 5 & 9 > months. Current doubling time of computers is someplace on the order > of 18 months. So? > If the Internet is doubling 2 to 3 times faster than computers, we are > going to run out, unless we can figure out how to scale certain > measures of Internet growth (like routing tables) to double on a slower > scale - more like 18-24 months than 5-9 months. When you decouple the route processing boxes from the packet-forwarding boxes you can do lots of nice things to escape from limits seemingly imposed by the increase in CPU speed. For starters, if a slower CPU chip architecture will handle the load today (I understand that a 486/66 will do nicely) you can move up within that CPU architecture (i.e P100) or else you can switch to an inherently faster architecture like Motorola's 604 PowerPC's or DEC's Alpha chips. You can also use SMP to gain even greater scalability by simply adding CPU's to your route processor. All the while, the packet forwarding box that can handle 10 T3's is still going to be able to handle 10 T3's since it's job has not changed. > If, in the future, something better comes along (something that permits > expanded growth of the Internet with out corresponding growth of the > routing tables), we can deploy it & get it working and change the > current practice to be what ever the best is at that time. My understanding is that it is possible today to kludge together a UNIX box running BGP and a Cisco 7000 as a packet forwarder. However, is this option being studied seriously or even experimented with? Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 16:15:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04653; Sat, 9 Sep 1995 16:15:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA20304; Sat, 9 Sep 1995 16:15:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA20298; Sat, 9 Sep 1995 16:15:13 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04618; Sat, 9 Sep 1995 16:15:03 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA21214; Fri, 8 Sep 1995 23:14:59 -0700 Date: Fri, 8 Sep 1995 23:14:59 -0700 From: Tony Li Message-Id: <199509090614.XAA21214@greatdane.cisco.com> To: asp@uunet.uu.net Cc: root@kbs.netusa.net, gherbert@crl.com, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: (asp@uunet.uu.net) Subject: Re: Routing tables & what to do about them Precedence: bulk > I am again confused. How can flat tables of size 256*256*256 grow at all > (exponentially or otherwise) ? As I mentioned before, you need to do this (assuming that it works at all) with a table of 2^32, not 2^24. Excuse me, but if you expect to see any hardware built, you should think about 2^128. Building hardware today for JUST IPv4 would get you accused of planned obsolescence. Tony From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 16:56:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05980; Sat, 9 Sep 1995 16:56:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA20383; Sat, 9 Sep 1995 16:55:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA20345; Sat, 9 Sep 1995 16:37:06 +1000 Received: from cu.nih.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05306; Sat, 9 Sep 1995 16:36:56 +1000 (from RAF@CU.NIH.GOV) Message-Id: <9509090636.5306@munnari.oz.au> To: nelson@crynwr.com Cc: big-internet@munnari.OZ.AU From: "Roger Fajman" Date: Sat, 09 Sep 1995 02:34:25 EDT Subject: Re: Keeping the Internet goingOA Precedence: bulk > But who gets forced to renumber? And why? Seems to me like a hard > problem to solve. > > Why not set the free market to solving it? I've already noted (on > com-priv) that one way to get back lots of IP addresses is to charge > for them (forcing a below-market price surely creates a shortage). > Well, one way to aggregate routes is to charge for unaggregated > routes. I don't have any inherent objection to charging for route advertisements. But it's hard to see how a system like that gets started without running afoul of US antitrust laws. How are the providers convinced to all do it at the same time (or does someone else get paid)? Who gets the money? The cost is incurred by others than just your own provider. Would it be possible to set up a non-profit organization to collect the fees and distribute the money collected in some reasonably equitable way? From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 16:57:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06019; Sat, 9 Sep 1995 16:57:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA20405; Sat, 9 Sep 1995 16:57:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA20365; Sat, 9 Sep 1995 16:50:57 +1000 Received: from europe.std.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05699; Sat, 9 Sep 1995 16:50:55 +1000 (from bzs@world.std.com) Received: from world.std.com by europe.std.com (8.6.12/Spike-8-1.0) id CAA19178; Sat, 9 Sep 1995 02:49:19 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA20684; Sat, 9 Sep 1995 02:49:18 -0400 Date: Sat, 9 Sep 1995 02:49:18 -0400 From: bzs@world.std.com (Barry Shein) Message-Id: <199509090649.AA20684@world.std.com> To: asp@uunet.uu.net (Andrew Partan) Cc: michael@junction.net (Michael Dillon), bass@linux.silkroad.com, jnc@ginger.lcs.mit.edu, bilse@eu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: References: Precedence: bulk I'd really like to see someone seriously address the issue of just charging for IP addresses. I realize this thought isn't real popular and most would rather just ignore the idea hoping for a technological miracle but the more I look at the situation the more it looks like we've just run slam bang into an impossible dream that a resource is infinite when it ain't. I don't think such a charge has to be very large to discourage abuse or just thoughtlessness, it needn't discourage bona-fide usage. Just so long as it recurs (ie, not one-time, hanging onto one has a price.) I guess the only argument I've heard off-hand is that no one has the authority to charge for addresses. I suspect that plays well to those who just don't like the idea but it's balderdash, just a wave of the hand. I dunno, I just sit back and watch these discussions go around and around and something which could probably buy years off this crisis is just staring us all in the face. Does anyone *seriously* believe that there aren't tens of thousands of Class C's which would be returned overnight if a bill showed up? Or probably thousands of Class B's? Hoarding is a behavior that's fired by shortage (or perception thereof) and low-cost (zero in this case, wow.) We have both in a big way, we've created a virtual panic (pardon the expression.) But if word got out that recent charges were making it easy to get addresses and have staved off the crisis and all you have to do is buy one and you can have one in a minute don't you think the problem will calm down real fast? We've created a monster, let's be honest. Drop the charges when the problem is solved. -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 17:18:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06471; Sat, 9 Sep 1995 17:18:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA20443; Sat, 9 Sep 1995 17:15:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA20439; Sat, 9 Sep 1995 17:15:09 +1000 Received: from cesium.clock.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06455; Sat, 9 Sep 1995 17:14:58 +1000 (from smd@cesium.clock.org) Received: by cesium.clock.org id <6191>; Sat, 9 Sep 1995 00:14:33 -0700 From: Sean Doran To: asp@uunet.uu.net, michael@junction.net Subject: Re: oops -- wrong message Cc: bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Message-Id: <95Sep9.001433pdt.6191@cesium.clock.org> Date: Sat, 9 Sep 1995 00:14:31 -0700 Precedence: bulk | > When you decouple the route processing boxes from the packet-forwarding | | Yes, when this is possible (& working) there are all sorts of things | that one could do. However, its not there today. Tsk, Andrew, yes it is and you have 60+ in your backbone. What do you think the Cisco RP+SSP combination is? | Also, what happens when your route processing box runs out of steam? Ah. Well, you and I both know about boxes which are continuously 30-40% there right now... We are due to find out in a scarily short time, it seems. Sean. - -- NETWORK RELIABLITY REPORT September 8th, 1995, ending 6:00am --------- --- ---- ------ - ---- sl-mae-e.sprintlink.net -- --- - ---------- --- Average CPU utilization: 44%. Average free memory: 37.38Mb. Maximal temperature inside the router: 35C. From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 22:57:39 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15506; Sat, 9 Sep 1995 22:57:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA20766; Sat, 9 Sep 1995 22:55:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA20749; Sat, 9 Sep 1995 22:47:55 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15183; Sat, 9 Sep 1995 22:47:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26555; Sat, 9 Sep 95 08:47:29 -0400 Date: Sat, 9 Sep 95 08:47:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509091247.AA26555@ginger.lcs.mit.edu> To: asp@uunet.uu.net, michael@junction.net Subject: Re: oops -- wrong message Cc: bass@linux.silkroad.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: Michael Dillon When you decouple the route processing boxes from the packet-forwarding boxes you can do lots of nice things to escape from limits seemingly imposed by the increase in CPU speed. This whole idea that everyone has to constantly upgrade their hardware because of changes occurring *elsewhere* in the Internet is just such incredibly bad engineering. If you were a phone equipment engineer, and went and told someone who worked for one of the US RBOC's that they'd have to upgrade all their switches because the phone network in China has gotten bigger, they'd look at you and wonder what engineering school let you out the door, and they'd be right. Nonetheless, people in the Internet seem to take it as an article of faith that this is the way to go. To me, this is really bad engineering. Your equipment capital costs ought to be related to what you're doing locally; i.e. how many links, and of what speed, you have, etc, etc, etc. Having it depend on how many customers sign up on the other side of the world is just plain, well, words fail me. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 23:16:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16108; Sat, 9 Sep 1995 23:16:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA20813; Sat, 9 Sep 1995 23:15:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA20783; Sat, 9 Sep 1995 22:57:46 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15511; Sat, 9 Sep 1995 22:57:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA09931 Sat, 9 Sep 1995 22:55:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26578; Sat, 9 Sep 95 08:53:07 -0400 Date: Sat, 9 Sep 95 08:53:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509091253.AA26578@ginger.lcs.mit.edu> To: asp@uunet.uu.net, bzs@world.std.com Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: bzs@world.std.com (Barry Shein) I'd really like to see someone seriously address the issue of just charging for IP addresses. Please don't confuse charging for *addresses* (i.e. the more addresses you have - i.e. the larger a net you have, the more you pay), and charging for routing advertisements. Charging for the former will not help reduce the number of route advertisments, and it's the latter that's really causing problems. There is a case to be made for charging for addresses (2^32 of the is still a limited resource), but please, please, please let's not open that nest of snakes right now? the more it looks like we've just run slam bang into an impossible dream that a resource is infinite when it ain't. Exactly... Does anyone *seriously* believe that there aren't tens of thousands of Class C's which would be returned overnight if a bill showed up? Well, if they are in routing tables they are probably being used. So, turning them in would probably involve renumbering. Then, once you've turned them in, you probanly need new addresses. Do you get charged for them too? If so, what's the incentive to turn the old ones in? Etc, etc. Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 23:17:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16131; Sat, 9 Sep 1995 23:17:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA20837; Sat, 9 Sep 1995 23:16:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA20795; Sat, 9 Sep 1995 23:09:43 +1000 Received: from ns.crynwr.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15877; Sat, 9 Sep 1995 23:09:38 +1000 (from nelson@crynwr.com) Received: by ns.crynwr.com (Linux Smail3.1.28.1 #4) id m0srPeU-000H9HC; Sat, 9 Sep 95 09:08 EDT Message-Id: Date: Sat, 9 Sep 95 09:08 EDT From: nelson@crynwr.com (Russell Nelson) To: bmanning@ISI.EDU Cc: jnc@ginger.lcs.mit.edu, RAF@CU.NIH.GOV, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509091252.AA02071@zed.isi.edu> (bmanning@ISI.EDU) Subject: Re: Keeping the Internet goingOA Precedence: bulk From: bmanning@ISI.EDU Date: Sat, 9 Sep 1995 05:52:47 -0700 (PDT) Charging for IP addresses independently of routing seems a bit silly, "Pssst, Buddy.. want to lease this spiffy 32bit number?" Well sure, a *particular* IP address has little value... unless it happens to be one of a group that you've already assigned to individual machines. No, the whole and complete reason we are running out of IP addresses is that they have much value, and little cost. If a supermarket started selling steak for a penny a pound, don't you think they'd run out pretty fast? Well, we don't even charge that much -- IP addresses are free. Charge a penny/address/month to maintain a routing announcement, and you'll find out pretty darn fast who *really* finds value in having class A and class B networks, and who *really* can and can't renumber. Things that are valuable, and in limited supply, should have a cost. A lack of IP addresses? Hogwash. A lack of IP address cost! -- -russ http://www.crynwr.com/~nelson Crynwr Software | Crynwr Software sells packet driver support | PGP ok 11 Grant St. | +1 315 268 1925 (9201 FAX) | America neither a Christian, Potsdam, NY 13676 | Jewish, Islamic, nor atheist (etc&) nation. This is good. From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 23:18:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16182; Sat, 9 Sep 1995 23:18:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA20859; Sat, 9 Sep 1995 23:18:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA20792; Sat, 9 Sep 1995 23:03:36 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15680; Sat, 9 Sep 1995 23:03:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26605; Sat, 9 Sep 95 09:03:27 -0400 Date: Sat, 9 Sep 95 09:03:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509091303.AA26605@ginger.lcs.mit.edu> To: RAF@CU.NIH.GOV, nelson@crynwr.com Subject: Re: Keeping the Internet goingOA Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Roger Fajman" I don't have any inherent objection to charging for route advertisements. But it's hard to see how a system like that gets started without running afoul of US antitrust laws. How are the providers convinced to all do it at the same time ... Who gets the money? The cost is incurred by others than just your own provider. Would it be possible to set up a non-profit organization to collect the fees and distribute the money collected in some reasonably equitable way? As I said, the way that makes the most sense here is not for your provider to start charging you [which will either i) need some sort of intricate settlements system worked out beforehand, or ii) drive your provider out of business is they do it unilaterally], but for your provider to start charging other providers for carrying *their* routes. If you think about it, this way has a lot less startup transients, and less chance of going screwy... I have left out a lot of detail, but I'm sure it's all prtty obvious. If this caught on, it would eventually lead to customers paying, but only to produce the $$$ for their provider to pay every other provider for carrying your route. If, of course, you as a customer had an address which came out of a block which was advertised as single entry, and shared with other people, you'd save money... Noel From owner-Big-Internet@munnari.OZ.AU Sat Sep 9 23:19:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16215; Sat, 9 Sep 1995 23:19:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA20879; Sat, 9 Sep 1995 23:19:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA20768; Sat, 9 Sep 1995 22:56:16 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15494; Sat, 9 Sep 1995 22:56:10 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Sat, 9 Sep 1995 05:55:51 -0700 Posted-Date: Sat, 9 Sep 1995 05:52:47 -0700 (PDT) Message-Id: <199509091252.AA02071@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Sat, 9 Sep 1995 05:52:47 -0700 Subject: Re: Keeping the Internet goingOA To: nelson@crynwr.com (Russell Nelson) Date: Sat, 9 Sep 1995 05:52:47 -0700 (PDT) Cc: jnc@ginger.lcs.mit.edu, RAF@CU.NIH.GOV, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: from "Russell Nelson" at Sep 8, 95 10:50:00 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1512 Precedence: bulk > everyone agrees that there are no practical alternatives to topology-based > addresses, and a certain amount of renumbering (we do *not* have to renumber > every last site) will be needed in short order. > > But who gets forced to renumber? And why? Seems to me like a hard > problem to solve. > > Why not set the free market to solving it? I've already noted (on > com-priv) that one way to get back lots of IP addresses is to charge > for them (forcing a below-market price surely creates a shortage). > Well, one way to aggregate routes is to charge for unaggregated > routes. > Russell, Noel is correct, not every site -has- to renumber to make things work... now. Those that are willing will find that, if they position themselves to be able to renumber quickly, they are higher in the evolutionary tree, better able to adapt to changing conditions and have a much better chance at long term survival. Longer term, if other solutions to not present themselves, more people will need to renumber. The end result is global, periodic renumbering of the entire Internet. Moving over to charging... Your concept is correct, its the terminology that is getting in the way. I think what you are talking about is charging for route announcement eg the provider should charge the client for injecting a unique prefix into the routing system. Charging for IP addresses independently of routing seems a bit silly, "Pssst, Buddy.. want to lease this spiffy 32bit number?" --bill From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 00:36:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18942; Sun, 10 Sep 1995 00:36:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA21132; Sun, 10 Sep 1995 00:35:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA21128; Sun, 10 Sep 1995 00:28:55 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18724; Sun, 10 Sep 1995 00:28:40 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET id QQzgll04139; Sat, 9 Sep 1995 10:28:25 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: oops -- wrong message To: smd@cesium.clock.org (Sean Doran) Date: Sat, 9 Sep 1995 10:28:24 -0400 (EDT) Cc: michael@junction.net, bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <95Sep9.001433pdt.6191@cesium.clock.org> from "Sean Doran" at Sep 9, 95 00:14:31 am X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 782 Precedence: bulk > | > When you decouple the route processing boxes from the packet-forwarding > | > | Yes, when this is possible (& working) there are all sorts of things > | that one could do. However, its not there today. > > Tsk, Andrew, yes it is and you have 60+ in your backbone. > What do you think the Cisco RP+SSP combination is? A tightly coupled system that a lot of people burned a lot of skull sweat over to make work; not the loosely coupled system that was proposed. > | Also, what happens when your route processing box runs out of steam? > Ah. Well, you and I both know about boxes which are > continuously 30-40% there right now... We are due to find out > in a scarily short time, it seems. No kidding. And the non high end routers are pretty much already dead. --asp From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 01:15:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19992; Sun, 10 Sep 1995 01:15:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA21206; Sun, 10 Sep 1995 01:15:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA21188; Sun, 10 Sep 1995 01:03:27 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19701; Sun, 10 Sep 1995 01:03:19 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA08478 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Sat, 9 Sep 1995 11:02:48 -0400 From: Tim Bass Message-Id: <199509091502.AA08478@linux.silkroad.com> Subject: Re: oops -- wrong message To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Sat, 9 Sep 1995 11:02:47 -0400 (EDT) Cc: asp@uunet.uu.net, michael@junction.net, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9509091247.AA26555@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 9, 95 08:47:29 am X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4282 Precedence: bulk A couple of points.... Decoupling the Route Processor ------------------------------ Decoupling the route processor from the switch processor was a very good engineering design developed our everyones favorite router vendor. The engineers there had the forsight and vision to decouple the two functions for similar reasons, CPU horsepower and memory requirements for route processing via-a-via fast packet-switching between interfaces. The on-board decoupling was a brillant first step and noteworthy and provides more than enough horsepower for the vast majority of the router market ( 99.99... something ). It is only the .00...1 something percent of the router market that is constrained by the in-chassis de-coupling of route processing and switching and could greatly benefit from adjunct external processing. In fact, not ever router at an *IX would have to have one.... it could be a adjunct processor shared by numberous core *IX routers. The overall cost to the Internet is minimal compared to the number of individual IP addresses on user sites. The point is, it is not realistic to demand a router vendor to burden the expense of manufacturing ever changing route processors for a very small market with little, very mimimal return. It does make sense, however to do the upgrades for scalable route processing in a UNIX based scalable adjunct processor that communicates with the switch processor. After all, it is statistically impossible for a router to need to route all possible routes in the Internet at any given moment. Classless Interdomain Routing via-a-via Provider Based Aggregation ------------------------------------------------------------------ There is little doubt that CIDR as 'Classless Interdomain Routing' was and is a great design. This approach solved a mounting problem with V4 address space depletion in the B space. Furthermore, it proved the concept and implementation of 'prefixs' within the IP address space. These two improvements in IP alone make CIDR a very successful initiative. Provider-based aggregation is not congruent with the ideas behind classless interdomain routing. Most agree, albeit not 100 percent, that there are better paradigms to aggregate than the 'current practice' of provider based aggregation. One possible first step might be to decouple the ideas of aggregation vs. classless interdomain routing. CIDR stands as a success on it's own merit certainly in the B space depletion problem. But, classless interdomain routing was not designed to transfer responsibility of all IP address space management to providers and to indirectly mandate the future of engineering new interdomain routing algorithms and systems. To de-couple classless interdomain routing from provider based aggregation has numerous advantages. First, CIDR stands alone as a success in the area it was intended to resolve; and second, the Internet community can begin the very important task of designing and implementing a better aggregation paradigm that minimizes the need for end user renumbering; distributes the responsibility of route processing of large routing table; decouples router vendors from complex scalability issues for a relatively small market. There is a better future for the Internet, many believe, in concentrating on aggregation methods that are independent of IP providers. Technically, politically, socially, and economically.... many are convinced that provider based aggregation is the wrong mountain to climb. The issue is paramount to 'second wave' success and deserves objective unemotional brainstorming, consideration, refinement, possible depolyment. -Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 01:36:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20641; Sun, 10 Sep 1995 01:36:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA21246; Sun, 10 Sep 1995 01:35:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA21242; Sun, 10 Sep 1995 01:34:31 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20551; Sun, 10 Sep 1995 01:34:10 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id LAA27384; Sat, 9 Sep 1995 11:33:35 -0400 Date: Sat, 9 Sep 1995 11:33:34 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Andrew Partan Cc: dorian@cic.net, SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Andrew Partan wrote: > > EXCELLENT. > > I'm glad that you agree that renumbering does help. > --asp > Of course I agree that renumbering helps. I have said so many times. I have also said that NSPs should try to renumber existing customers to compress fragmented routing tables. I have even proposed that NSPs provide incentives (consulting, monetary) to convince customers to renumber. I have also said that renumbering should be made easy by application, OS and network software vendors. I have even proposed charging fees for advertising routing prefixes to encourage users to renumber within a provider's block. I am convinced that the above steps will not only reduce the growth in the routing tables, they may actually reduce the existing size of those tables. Even multi-homing will not really add that much to the size of the tables as will be gained by the steps outlines above. What I am opposed to is FORCED renumbering, especially when changing providers. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 01:55:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21187; Sun, 10 Sep 1995 01:55:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA21303; Sun, 10 Sep 1995 01:55:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA21268; Sun, 10 Sep 1995 01:37:51 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20670; Sun, 10 Sep 1995 01:37:34 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id LAA27400; Sat, 9 Sep 1995 11:36:59 -0400 Date: Sat, 9 Sep 1995 11:36:59 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Andrew Partan Cc: gherbert@crl.com, tli@cisco.com, big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Andrew Partan wrote: > > I am again confused. How can flat tables of size 256*256*256 grow at all > > (exponentially or otherwise) ? > > As I mentioned before, you need to do this (assuming that it works at > all) with a table of 2^32, not 2^24. > --asp > Why? Why can we not get rid of the sub /24 routes? I can understand why users are attached to /24 routes since they were granted those addresses by Internic but why are they attached to sub /24 routes? How did the sub /24 routes come into existence at all? Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 01:57:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21314; Sun, 10 Sep 1995 01:57:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA21327; Sun, 10 Sep 1995 01:57:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA21282; Sun, 10 Sep 1995 01:44:09 +1000 Received: from sabre-wulf.nvg.unit.no by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20772; Sun, 10 Sep 1995 01:44:04 +1000 (from agulbra@nvg.unit.no) Received: from sabre-wulf.nvg.unit.no (agulbra@sabre-wulf.nvg.unit.no [129.241.161.9]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id RAA04197; Sat, 9 Sep 1995 17:43:54 +0200 Received: by sabre-wulf.nvg.unit.no (smallmail v1.18); Sat, 9 Sep 1995 17:43:53 +0200 Date: Sat, 9 Sep 1995 17:43:53 +0200 Message-Id: <29559.4194.810661433@sabre-wulf.nvg.unit.no> From: Arnt Gulbrandsen Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: root@kbs.netusa.net Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Organization: Nettverksgruppa Precedence: bulk In article you write: >On Thu, 7 Sep 1995, George Herbert wrote: >> Ayup. But don't knock flat tables. > >I am again confused. How can flat tables of size 256*256*256 grow at all >(exponentially or otherwise) ? To pick just one way, each table entry needs to grow. In a simple router with two WAN links and a LAN, each entry might be just two bits, but in a big router you'd need lots of big per entry to do load-balancing between several links, point to policy info, count packets to charge by the byte, whatever. Then there's the data structures in the Router Processor, multiprotocol routing, etc, etc. --Arnt From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 02:16:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21679; Sun, 10 Sep 1995 02:16:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA21379; Sun, 10 Sep 1995 02:15:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA21373; Sun, 10 Sep 1995 02:13:30 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21600; Sun, 10 Sep 1995 02:13:24 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id MAA27570; Sat, 9 Sep 1995 12:12:41 -0400 Date: Sat, 9 Sep 1995 12:12:40 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Tony Li Cc: asp@uunet.uu.net, gherbert@crl.com, tli@cisco.com, big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <199509090614.XAA21214@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 8 Sep 1995, Tony Li wrote: > Excuse me, but if you expect to see any hardware built, you should > think about 2^128. Building hardware today for JUST IPv4 would get > you accused of planned obsolescence. > > Tony The routing scheme of IPv6 is totally different in this regard and the above statement is thereful meaningless in that context. It is not even witty enough to pass as a sarcasm. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 02:17:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21731; Sun, 10 Sep 1995 02:17:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA21401; Sun, 10 Sep 1995 02:16:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA21351; Sun, 10 Sep 1995 02:10:01 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21563; Sun, 10 Sep 1995 02:09:56 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id MAA27536; Sat, 9 Sep 1995 12:08:57 -0400 Date: Sat, 9 Sep 1995 12:08:57 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: bass@linux.silkroad.com, jnc@ginger.lcs.mit.edu, bass@cais.cais.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: <9509090346.AA22312@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 8 Sep 1995, Noel Chiappa wrote: > commercial router manufactors are lagging far behind the silicon > processing power curve and their products are slow to upgrade for a small > market. > > Since they are so inept, you should start a company to compete. It's a giant > market, you should make a mint. > As has been stated here many times, it is NOT a giant market. That is the "core" problem. NSPs (for competitive reasons) are unwilling to pay what it would cost to develop the hardware for such a small market. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 02:18:30 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21802; Sun, 10 Sep 1995 02:18:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA21423; Sun, 10 Sep 1995 02:18:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA21347; Sun, 10 Sep 1995 02:01:08 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21340; Sun, 10 Sep 1995 02:01:02 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id MAA27501; Sat, 9 Sep 1995 12:00:22 -0400 Date: Sat, 9 Sep 1995 12:00:21 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Vadim Antonov Cc: big-internet@munnari.OZ.AU Subject: Re: oops -- wrong message In-Reply-To: <199509090244.WAA10349@titan.sprintlink.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 8 Sep 1995, Vadim Antonov wrote: > Critique without offering > alternatives which do not contain demonstrable flaws in logic is > nothing more than pathetic whining. > > --vadim > The demonstratable flaw is not in logic but in the demonstratably bad and unreliable service that NSPs provide. I have a client who has two T1 lines running in parallel to a Sprint POP for load sharing (not multihoming). Sprint could not seem to get one of the lines to work (about two out of every three packets are dropped on the second line). This problem existed for more than a month despite innumerable calls to Sprint and the telco and elevation of the problem. In addition to this problem they have had many other outages. They used to have PSI and it was not much better but were told that SPRINT would be better. It is not. You can call the above "pathetic whining" if you want. This client has over 5000 IP hosts on about almost any hardware that you can think up of and will not be able to renumber without spending an enormous amount of time and effort. This client is also why I joined this forum. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 02:36:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22253; Sun, 10 Sep 1995 02:36:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA21473; Sun, 10 Sep 1995 02:35:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA21469; Sun, 10 Sep 1995 02:34:23 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22231; Sun, 10 Sep 1995 02:34:14 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id JAA03770; Sat, 9 Sep 1995 09:41:22 -0700 Date: Sat, 9 Sep 1995 09:41:20 -0700 (PDT) From: Michael Dillon To: Sean Doran Cc: asp@uunet.uu.net, bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Subject: Re: oops -- wrong message In-Reply-To: <95Sep9.001433pdt.6191@cesium.clock.org> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Sean Doran wrote: > | > When you decouple the route processing boxes from the packet-forwarding > | > | Yes, when this is possible (& working) there are all sorts of things > | that one could do. However, its not there today. > > Tsk, Andrew, yes it is and you have 60+ in your backbone. > What do you think the Cisco RP+SSP combination is? Cisco has separated the functions within their own boxes, but has anyone put these funtions into two separate boxes? I believe that if the route processing was handled in a standard box based on UNIX that problems of CPU power, RAM capacity and the like could be averted. There are SMP versions of UNIX available today from SUN, SCO and others that have enough power to handle route processing for the forseeable future so I don't see any serious possibility that this approach could run out of gas. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 02:56:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22835; Sun, 10 Sep 1995 02:56:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA21536; Sun, 10 Sep 1995 02:55:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA21515; Sun, 10 Sep 1995 02:52:30 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22757; Sun, 10 Sep 1995 02:52:26 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id JAA03962; Sat, 9 Sep 1995 09:59:40 -0700 Date: Sat, 9 Sep 1995 09:59:40 -0700 (PDT) From: Michael Dillon To: Noel Chiappa Cc: asp@uunet.uu.net, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Subject: Re: oops -- wrong message In-Reply-To: <9509091247.AA26555@ginger.lcs.mit.edu> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Noel Chiappa wrote: > If you were a phone equipment engineer, and went and told someone who worked > for one of the US RBOC's that they'd have to upgrade all their switches > because the phone network in China has gotten bigger, they'd look at you > and wonder what engineering school let you out the door, and they'd be right. That's because people in China do not make many phone calls to the USA. > Nonetheless, people in the Internet seem to take it as an article of faith > that this is the way to go. To me, this is really bad engineering. Your > equipment capital costs ought to be related to what you're doing locally; i.e. > how many links, and of what speed, you have, etc, etc, etc. Having it depend > on how many customers sign up on the other side of the world is just plain, > well, words fail me. What if you set up a local WWW server for the local head office of a company whose product is popular throughout the world? Don't you think that you will get high traffic levels 24 hours per day as all the world's citizens go to that server (which is updated daily) to learn about their favourite product. Could be as simple as Dilbert... Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 02:57:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22855; Sun, 10 Sep 1995 02:57:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA21558; Sun, 10 Sep 1995 02:56:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA21518; Sun, 10 Sep 1995 02:54:34 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22773; Sun, 10 Sep 1995 02:54:29 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id MAA09236; Sat, 9 Sep 1995 12:53:12 -0400 Message-Id: <199509091653.MAA09236@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: nelson@crynwr.com (Russell Nelson) Cc: bass@linux.silkroad.com, jnc@ginger.lcs.mit.edu, bilse@eu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Your message of "Fri, 08 Sep 1995 23:07:00 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 09 Sep 1995 12:53:10 -0400 From: "Perry E. Metzger" Precedence: bulk Russell Nelson writes: > There is no rational reason for building a future global Internet > based on provider based and controlled route aggregation. > > Sure there is -- it's cheaper. Imagine a different Internet, where > CIDR was designed-in, renumbering was an accepted part of life, and we > had tools to renumber a network in five seconds. The top-level > netmask would be 0xf0.0.0.0. The core routers would have a > sixteen-entry routing table. "Is it mine? Nope. Is it MCI's? Nope. > Is it Sprintlink's? Ahhhh yes. Throw it out the interface closest to > Sprintlink and let them worry about the carriage." Except that this might be the completely wrong way to do things. It assumes that all connection points you have to sprintlink are identical in quality for all addresses. If you have an exchange point in Denver with sprint and an exchange point in Toronto, and your customer is network equidistant between the exchange points, it probably makes the most sense for you to send packets to Sprintlink customers in Tornoto via the Toronto exchange point and not the Denver exchange point. However, using the CIDR model, we know nothing about topology, only about carriers. This leads you to send packets to Denver when they should be sent to Toronto in order to minimize global resource usage. We are starting to see a lot of this insanity already. I have no conceptual trouble with my packets going from upper manhattan to lower manhattan by way of Maryland, San Francisco, Denver, and Washington (which happens every time I download my email) if that is the best route, except that it happens that a human looking at the connectivity map could tell you that it isn't the best route at all and that my packets could be getting through with a quarter of the latency and far fewer links being loaded with my packets. Incidently, I wonder more and more if we are making many of our decisions on architecture based on the fact that that Cisco 7000 routers contain 25MHZ 68040 processors and can't be expanded to more than 64M of memory. Perry From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 03:15:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23280; Sun, 10 Sep 1995 03:15:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21604; Sun, 10 Sep 1995 03:15:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21580; Sun, 10 Sep 1995 03:04:12 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22991; Sun, 10 Sep 1995 03:04:08 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id NAA09256; Sat, 9 Sep 1995 13:04:04 -0400 Message-Id: <199509091704.NAA09256@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Your message of "Fri, 08 Sep 1995 23:46:39 EDT." <9509090346.AA22312@ginger.lcs.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 09 Sep 1995 13:04:04 -0400 From: "Perry E. Metzger" Precedence: bulk Noel Chiappa writes: > From: Tim Bass > > CPU power is increasing at about the same rate or faster than the growth > of the Internet. > > This statement is in direct contradiction to numbers given earlier, > which said that routing tables are doubling every 9 months, whereas > processor speed seems to double about every two years. Since this > doesn't agree with your statement above, which of these is wrong? Until a week or two ago when Cisco finally announced a new 7500 series router which finally uses a RISC processor at decent speed, their top of the line router used the astonishingly pathetic 25Mhz 68040. Its painful to think about $75K-$100K pieces of equipment using processors that wouldn't be acceptable in bottom of the line video game equipment. Unfortunately, Cisco is basically the only backbone router vendor right now, Bay Networks stuff not being BGP-4 capable. It would be really neat to see how our routers did if they actually kept up with current technology. I don't know how the slopes of the curves compared, but I'll say this -- statements to the effect that our current routers can barely handle the current load should be tempered with realization that our current routers are astonishingly pathetic pieces of equipment. Perry From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 03:35:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23830; Sun, 10 Sep 1995 03:35:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21655; Sun, 10 Sep 1995 03:35:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21626; Sun, 10 Sep 1995 03:22:02 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23485; Sun, 10 Sep 1995 03:21:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27010; Sat, 9 Sep 95 13:21:50 -0400 Date: Sat, 9 Sep 95 13:21:50 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509091721.AA27010@ginger.lcs.mit.edu> To: perry@piermont.com Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Perry E. Metzger" >> CPU power is increasing at about the same rate or faster than the growth >> of the Internet. > This statement is in direct contradiction to numbers given earlier, > which said that routing tables are doubling every 9 months, whereas > processor speed seems to double about every two years. Until a week or two ago when Cisco finally announced a new 7500 series router which finally uses a RISC processor at decent speed, their top of the line router used the astonishingly pathetic 25Mhz 68040. Interesting, but it has nothing to do with the point above. It would be really neat to see how our routers did if they actually kept up with current technology. The point remains that it's not very good engineering to build a system in which you have to deploy new hardware at your site because of things that are happening in a part of the network a long way away. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 03:36:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23851; Sun, 10 Sep 1995 03:36:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21675; Sun, 10 Sep 1995 03:36:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21643; Sun, 10 Sep 1995 03:27:57 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23546; Sun, 10 Sep 1995 03:27:52 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27020; Sat, 9 Sep 95 13:27:50 -0400 Date: Sat, 9 Sep 95 13:27:50 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509091727.AA27020@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, michael@junction.net Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Precedence: bulk From: Michael Dillon > Your equipment capital costs ought to be related to what you're doing > locally; i.e. how many links, and of what speed, you have, etc, etc, > etc. Having it depend on how many customers sign up on the other side > of the world is just plain, well, words fail me. What if you set up a local WWW server for the local head office of a company whose product is popular throughout the world? Don't you think that you will get high traffic levels 24 hours per day as all the world's citizens go to that server (which is updated daily) to learn about their favourite product. You have completely missed my point, which has nothing to do with *local* traffic loads, whether that traffic is headed to far-away points or not. Presumably, if you put in a popular WWW server, you're going to have to make sure the network near you has enough bandwidth capacity to handle the calls, but the same would be true in a phone example, if you set up a major phone order processing center, etc. My point, again, was that it's incredibly bad engineering to design a system in which switches have to be changed because of growth a long way away in the network, *even if that part of the net rarely communicates with this part*. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 03:59:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24383; Sun, 10 Sep 1995 03:59:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21790; Sun, 10 Sep 1995 03:58:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21723; Sun, 10 Sep 1995 03:53:22 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24227; Sun, 10 Sep 1995 03:53:11 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id NAA09338; Sat, 9 Sep 1995 13:53:07 -0400 Message-Id: <199509091753.NAA09338@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Your message of "Sat, 09 Sep 1995 13:21:50 EDT." <9509091721.AA27010@ginger.lcs.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 09 Sep 1995 13:53:06 -0400 From: "Perry E. Metzger" Precedence: bulk Noel Chiappa writes: > The point remains that it's not very good engineering to build a system in > which you have to deploy new hardware at your site because of things that are > happening in a part of the network a long way away. You give the impression that this isn't the case in the phone network. I'm afraid that it *is* the case in the phone network. There are hundreds of thousands of PBXes being upgraded right now because of changes made recently in the North American Numbering Plan to permit area codes with non {0,1} middle digits. There are also similar radical changes that have happened in all long distance carrier's switches to deal with things like making 800 numbers portable between carriers and the like. However, perhaps you are only refering to ongoing continuous changes you need to make in your network because of, say, China coming onto the net. Well, sorry, but when some random country comes on the net I'm afraid that you can't avoid having to negotiate transit agreements and other fun things like that, and such complexities will only increase in the future. If you are talking only about needed hardware because of routing load, well, unfortunately, as I see it, we have several choices. One is to build the network we are trending towards in which addresses only tell you what provider an address is on and all routes end up insanely suboptimal, with packets taking meandering excursions across half the planet, but in which everyone gets to pretend that hardware upgrades aren't needed and in which dual connection is considered unclean somehow. Another is to accept that neither radical agregation nor the other extreme (putting a route in the tables for every host) is going to work and avoid both the scylla of overCIDRization and the charybdis of total non-agregation. A third possibility would have been to go for a a radically new routing architecture, like the "everything is source routed" world that PIP had in mind. Sadly, people were unwilling to try such experiments sufficiently to see how they would have worked -- they certainly had scaling advantages. Unfortunately, we cannot avoid having to upgrade our hardware in response to general increases in routing table size, and if we want to avoid having our packets take utterly insane routes, we are going to have to accept that routing table sizes will never go down to sixteen entries or fifty entries or whatever the magic number people pretend will work might be. Sorry that this is the engineering reality, but its the one that companies accept when they enter the business. Even when we start with a clean slate in v6 world, we are going to find lots and lots of need to punch down the CIDR walls. Perry From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 04:16:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25076; Sun, 10 Sep 1995 04:16:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA21847; Sun, 10 Sep 1995 04:15:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21783; Sun, 10 Sep 1995 03:57:51 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB24372; Sun, 10 Sep 1995 03:57:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27132; Sat, 9 Sep 95 13:57:45 -0400 Date: Sat, 9 Sep 95 13:57:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509091757.AA27132@ginger.lcs.mit.edu> To: root@kbs.netusa.net, tli@cisco.com Subject: Re: Routing tables & what to do about them Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur The routing scheme of IPv6 is totally different in this regard and the above statement is thereful meaningless in that context. Oh? Please enlighten us as to the fundamental difference in how IPv6 is going to handle large-scale routing. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 04:17:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25139; Sun, 10 Sep 1995 04:17:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA21884; Sun, 10 Sep 1995 04:17:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21752; Sun, 10 Sep 1995 03:56:30 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24360; Sun, 10 Sep 1995 03:56:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27119; Sat, 9 Sep 95 13:56:06 -0400 Date: Sat, 9 Sep 95 13:56:06 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509091756.AA27119@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: Sanjay Kapur As has been stated here many times, it is NOT a giant market. Well, routers in general are (look at Cisco's qaurterlies to see how big), but perhaps these Cray-routers aren't. NSPs (for competitive reasons) are unwilling to pay what it would cost to develop the hardware for such a small market. So, start an NSP that is nice to its customers and lets them move around and pays for the giant routers. There are two possibilities. One, it costs the same, and everyone will flock to you since you provide better service. Two, it costs more, and if people really want that level of service, they will pay for it. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 04:17:26 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25174; Sun, 10 Sep 1995 04:17:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15760 Sun, 10 Sep 1995 03:58:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21738; Sun, 10 Sep 1995 03:55:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21720; Sun, 10 Sep 1995 03:52:50 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24221; Sun, 10 Sep 1995 03:52:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27102; Sat, 9 Sep 95 13:52:44 -0400 Date: Sat, 9 Sep 95 13:52:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509091752.AA27102@ginger.lcs.mit.edu> To: michael@junction.net, smd@cesium.clock.org Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: Michael Dillon Cisco has separated the functions within their own boxes, but has anyone put these funtions into two separate boxes? I believe that if the route processing was handled in a standard box based on UNIX that problems of CPU power, RAM capacity and the like could be averted. I agree that this is an interesting and worthwhile experiment, but everyone should remember that the *results* have to be loaded into the forwarding table on the router, which is usually in some sort of fairly fast memory (and thus of limited size) to get the performance. So, putting the routing all in a separate box does not say you can grow the routing table as much as you want with no further reference to the router. There are SMP versions of UNIX available today from SUN, SCO and others that have enough power to handle route processing for the forseeable future I wasn't aware the SMP Unix had the capability to run a single process on multiple CPU's simultaneously, so it's not just a "plug it in and go" operation. Above and beyond that, even assuming we manage to split the routing up among several processors in the trivial way (i.e. have different processors to talk to different peers), now you've got several processors poking into the same database (to figure out who's got the best route to X), so you've got some "interesting" interlock issues. E.g. what % of data accesses are to shared data? What % of them will need to lock it? How much overhead will that lock take (and does your multiprocessor have hardware support for locking), etc, etc, etc. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 04:17:44 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25192; Sun, 10 Sep 1995 04:17:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15790 Sun, 10 Sep 1995 03:59:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA21765; Sun, 10 Sep 1995 03:56:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA21708; Sun, 10 Sep 1995 03:44:03 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24133; Sun, 10 Sep 1995 03:43:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27083; Sat, 9 Sep 95 13:43:56 -0400 Date: Sat, 9 Sep 95 13:43:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509091743.AA27083@ginger.lcs.mit.edu> To: perry@piermont.com Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Perry E. Metzger" It assumes that all connection points you have to sprintlink are identical in quality for all addresses. Which points out an issue with multihoming, in the current addressing system, that most of the multihoming aficionados are ignoring: to get real use out of multihoming, in terms of using your "best" link for outbound traffic, you can no longer get by with just internal routes and default: you have to carry routes about all those external places where you care about the exit link (i.e. instead of just taking the one nearest the source of the traffic). If you get sick of handcrafting filter tables for the 10% of the Internet you care about, and just say "to heck with it, let's just carry the whole routing table", that means all of sudden a whole lot more routers are in the situation where you have to upgrade them because 20K networks got added on the other side of the world. If you have an exchange point in Denver .. and an exchange point in Toronto ... it probably makes the most sense for you to send packets to .. customers in Tornoto via the Toronto exchange point and not the Denver exchange point. However, using the CIDR model, we know nothing about topology, only about carriers. It depends on how you set up the addressing and routing. I don't want to spent 3 pages explaining something that ought to be intuitively obvious after several years of talking about this, but suffice it to say that if the target "network" is really that large, they are probably using topological aggregations of their own internally, and acesss to routing information about them (identical, effectively, to knowing that the Toronto customers are near the Toronto exchange point) allows you to pick the optimal entry point into the other provider's network. (PS: I'll bite: can you explain to me how any other addressing plan tells you more about the network's topology?) I have no conceptual trouble with my packets going from upper manhattan to lower manhattan by way of Maryland, San Francisco, Denver, and Washington ... if that is the best route, except that it happens that a human looking at the connectivity map could tell you that it isn't the best route at all Perhaps you could provide us a traceroute so we can look at why this is happening. Also, what's the source of the connectivity map you're looking at to discover there's a better path? Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 04:56:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26377; Sun, 10 Sep 1995 04:56:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA21965; Sun, 10 Sep 1995 04:55:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA21948; Sun, 10 Sep 1995 04:53:08 +1000 Received: from freeside.fc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26358; Sun, 10 Sep 1995 04:52:59 +1000 (from jerry@fc.net) Received: (from jerry@localhost) by freeside.fc.net (8.6.12/8.6.6) id NAA23294; Sat, 9 Sep 1995 13:52:39 -0500 From: Jeremy Porter Message-Id: <199509091852.NAA23294@freeside.fc.net> Subject: Re: oops -- wrong message To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Sat, 9 Sep 1995 13:52:39 -0500 (CDT) Cc: michael@junction.net, smd@cesium.clock.org, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu, inet-access@earth.com In-Reply-To: <9509091752.AA27102@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 9, 95 01:52:44 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4502 Precedence: bulk > There are SMP versions of UNIX available today from SUN, SCO and others > that have enough power to handle route processing for the forseeable future > >I wasn't aware the SMP Unix had the capability to run a single process on >multiple CPU's simultaneously, so it's not just a "plug it in and go" >operation. > >Above and beyond that, even assuming we manage to split the routing up among >several processors in the trivial way (i.e. have different processors to talk >to different peers), now you've got several processors poking into the same >database (to figure out who's got the best route to X), so you've got some >"interesting" interlock issues. E.g. what % of data accesses are to shared >data? What % of them will need to lock it? How much overhead will that lock >take (and does your multiprocessor have hardware support for locking), etc, >etc, etc. This problem is well addressed in the industry. Any modern SMP box can handle this type of thing. Plus its really not that hard of an engineering effort. With parallel solutions there would really be very little difficulty in putting off the heat death of CIDR by several years. The Processing power difference and memory utilization differences between a Cisco 7000 with a 68040) and a 8 CPU 200mhz RISC processer SMP box is pretty high. And even Non-SMP solutions just multiprocessing (which BTW is what you are talking about with different peers on different CPUs). This problem is really fairly well understood, and I don't feel like spending 3 days explaining it again :-). But seriously MP and SMP solutions have been in production for years. Even with doubling ever 4 months I don't see trouble designing a tightly coupled or loosly couple MP/SMP machine(s) to handled the groth for the next 3-4 years. (two bad design cycles are about 2 years.) Picture a box with 20 CPU slots, currently it can handle full load with one CPU, assuming about 80% effective utiliazation of of SMP/MP techniques, you can withstande 4 doublings in table growth/route-calculation/peering. That gives us a routing table size of something like 480,000 entries. If growth can be slow to doubling every 12 months, this gives us 4 years to get a radical change like IPV6 ready. It seems pretty clear to me that there are hardware solutions to handle the real problems of growth, but there does need to be some effective work done to slow groth. Three cases: 1. multi-homing: Internic should assign large enough blocks for multi-homed sites for approximately 6month to 1 year forcasts. (i.e. each multi-homed site needs to only grow by one CIDR block per 6 months/1 year). This means fairly huge allocations to large backbones. Probably means opening class A address space sooner. 2. entropy of CIDR: Major network providers should announce a policy of non-portable address effective ASAP. (There are some people that may win some money by hearing me say that, because a year ago, I would have told you of the EVILNESS of non-portable addresses). This means increased enginnering costs for customers and backbones with gredards to support issues. Also it means people like Sprint, PSI, should allow TEMPORARY CIDR holes so that changes can be made slowly over a period of 30 days or so. 3. Old space(/24 routes): Audits MUST be conducted on utilization of CIDR space by NSP, small ISPs, and by end customers, to make sure good choices are made for allocation block sizes. Some people would argue that if the Internic had allocated correct sized blockes we might not be having such growth problems with the table size. However (this last assertion is just my feeling based on the numbers present on big-internet). Also allocations of /24s should be stopped. If you are design ing a new network, make a decision about providers and get the allocation block. Otherwise get a RFC1597 net and PLAN for renumbering. I really don't see any solution to the charging for route prefixs, althought it seems a reasonable model, because people being what they are, would scream anti-trust and be technical correct even if it was done to save the net. I don't see any techincal or polical solution to this problem. -- ---------------------------------------------------------------------------- | Jeremy Porter (512)-339-6094 Freeside Communications, Inc. info@fc.net | | jerry@fc.net (512)-339-4466 (data) P.O. Box 530264 Austin, TX 78753 | ---------------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 05:16:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26918; Sun, 10 Sep 1995 05:16:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA22013; Sun, 10 Sep 1995 05:15:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA21987; Sun, 10 Sep 1995 05:09:33 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26791; Sun, 10 Sep 1995 05:09:21 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id MAA05048; Sat, 9 Sep 1995 12:16:28 -0700 Date: Sat, 9 Sep 1995 12:16:26 -0700 (PDT) From: Michael Dillon To: Noel Chiappa Cc: smd@cesium.clock.org, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Subject: Re: oops -- wrong message In-Reply-To: <9509091752.AA27102@ginger.lcs.mit.edu> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Noel Chiappa wrote: > I wasn't aware the SMP Unix had the capability to run a single process on > multiple CPU's simultaneously, so it's not just a "plug it in and go" > operation. As far as I know, no SMP UNIX can run a single process on multiple CPU's. However, it may well be possible to design a route processing algorithm in which the job is handled by multiple symmetric processes which can then be run effectively on an SMP box. > Above and beyond that, even assuming we manage to split the routing up among > several processors in the trivial way (i.e. have different processors to talk > to different peers), now you've got several processors poking into the same > database (to figure out who's got the best route to X), so you've got some > "interesting" interlock issues. E.g. what % of data accesses are to shared > data? What % of them will need to lock it? How much overhead will that lock > take (and does your multiprocessor have hardware support for locking), etc, > etc, etc. But these issues are well understood and implemented on these SMP boxes already. This is the same problem that database vendors such as Oracle, Informix and Progress have already solved to handle massive databases on SMP RAID boxes. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 05:17:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26957; Sun, 10 Sep 1995 05:17:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA22036; Sun, 10 Sep 1995 05:17:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA22007; Sun, 10 Sep 1995 05:11:34 +1000 Received: from netaxs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26840; Sun, 10 Sep 1995 05:11:31 +1000 (from freedman@netaxs.com) Received: (from freedman@localhost) by netaxs.com (8.6.12/8.6.11) id OAA12096; Sat, 9 Sep 1995 14:17:39 -0400 From: Avi Freedman Message-Id: <199509091817.OAA12096@netaxs.com> Subject: Re: oops -- wrong message To: perry@piermont.com Date: Sat, 9 Sep 1995 14:17:39 -0400 (EDT) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509091704.NAA09256@frankenstein.piermont.com> from "Perry E. Metzger" at Sep 9, 95 01:04:04 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2164 Precedence: bulk > > > Noel Chiappa writes: > > From: Tim Bass > > > > CPU power is increasing at about the same rate or faster than the growth > > of the Internet. > > > > This statement is in direct contradiction to numbers given earlier, > > which said that routing tables are doubling every 9 months, whereas > > processor speed seems to double about every two years. Since this > > doesn't agree with your statement above, which of these is wrong? > > Until a week or two ago when Cisco finally announced a new 7500 series > router which finally uses a RISC processor at decent speed, their top > of the line router used the astonishingly pathetic 25Mhz > 68040. Its painful to think about $75K-$100K pieces of equipment using > processors that wouldn't be acceptable in bottom of the line video > game equipment. > > Unfortunately, Cisco is basically the only backbone router vendor > right now, Bay Networks stuff not being BGP-4 capable. It would be > really neat to see how our routers did if they actually kept up with > current technology. > > I don't know how the slopes of the curves compared, but I'll say this > -- statements to the effect that our current routers can barely handle > the current load should be tempered with realization that our current > routers are astonishingly pathetic pieces of equipment. > > Perry I thought that the Wellfleet boxes did do BGP4. The questions I only recently asked their salescritters were: o Does the $5k box really do 45mbits on the serial port? o Can *all* of the features of the boxes be used by command line via telnet? o Do the boxes do BGP4? How old is the implementation? I got a yes answer on all of the above, but still own no Wellfellets :) Of course, even if the boxes do BGP4, a major question is how recent is it, how compatible with the algorithms used by Cisco, esp. with the (one hears) pending release of code to slow the effect of having to delete or insert thousands of routes. The same question can be asked about the gated alpha code that's out there. Look at the arp table at a peering point and you'll see a whole lot of 0000.0Cxx.xxxx ... Avi From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 05:18:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27020; Sun, 10 Sep 1995 05:18:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA22063; Sun, 10 Sep 1995 05:18:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA22004; Sun, 10 Sep 1995 05:11:08 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26830; Sun, 10 Sep 1995 05:11:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27341; Sat, 9 Sep 95 15:10:51 -0400 Date: Sat, 9 Sep 95 15:10:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509091910.AA27341@ginger.lcs.mit.edu> To: perry@piermont.com Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Perry E. Metzger" > The point remains that it's not very good engineering to build a system > in which you have to deploy new hardware at your site because of things > that are happening in a part of the network a long way away. You give the impression that this isn't the case in the phone network. I'm afraid that it *is* the case in the phone network. There are hundreds of thousands of PBXes being upgraded right now because of changes made recently in the North American Numbering Plan ... There are also similar radical changes that have happened in all long distance carrier's switches to deal with things like making 800 numbers portable between carriers Your "counter-examples" are also wrong. Neither involves changes that are "a long way away", but are in fact happening quite locally, in your home part of the phone net. Now, if you had to change your PBX in the US because of changes in the *English* numbering plan, that would be analogous, but of course the phone net doesn't work that way. One is to build the network we are trending towards in which addresses only tell you what provider an address is on This is not true. CIDR is not proposing that addresses be of the form , with only three distinct fields, but rather contain somewhat more structure. all routes end up insanely suboptimal with packets taking meandering excursions across half the planet This is not true (even assuming the above were true); in fact, fewer levels of hierarchy generally results in better routes, not worse, albeit at a cost of much larger routing tables. (See Kleinrock and Kamoun, section 5.2.) *Any* hierarchical routing scheme, be it geographic, or whatever, will result in non-optimal routes. However, with a reasonable hierarhcy, this increase will be minimal. In fact, K+K examined topological hierarchies, and showed that i) one can bound the maximum increase in path length, and ii) for the limit case, in very large networks, the increase tends towards zero. Perhaps you could consult their work and tell us where they went wrong. but in which everyone gets to pretend that hardware upgrades aren't needed Hardware upgrades will be needed as traffic increases. However, we have to build a net in which hardware replacement is driven by local needs, not conditions elsewhere in the network a given site doesn't even care about. in which dual connection is considered unclean somehow. This lame saw again. There is nothing wrong with multihoming (not that it will really make things reliable), and CIDR is no worse at supporting multihoming than any other addressing scheme. Explain to me again how geographic addressing works if you're multihomed to two different geographic areas? Another is to accept that neither radical agregation nor the other extreme (putting a route in the tables for every host) is going to work Something we almost agree on. Radical aggregation would indeed work (K+K shows that the optimal fan-out per level of hierarchy is 2-3), but as a practical matter it has downsides we are unlikely to put up with (such as not providing very good routes). So, yes, the best course is something in the middle; neither the old "flat" system, nor radical aggregation of the kind which would result in dozens of tiny layers. A third possibility would have been to go for a a radically new routing architecture, like the "everything is source routed" world that PIP had in mind. Sadly, people were unwilling to try such experiments sufficiently to see how they would have worked -- they certainly had scaling advantages. You seem to think that some other approach would get rid of the necessity to have aggreable addresses. This is not at all true. If you examine Paul's "landmark routing" work, you wil discover that the same principle is at work, it's just that the area boudnaries are diffuse, making them easier to set up. As for source routes (something I have thought about extensively), how exactly do you think they get computed, etc, etc? Without aggregation, the database used for that will grow, and so will the cost of calculating source routes. There's no free lunch. we cannot avoid having to upgrade our hardware in response to general increases in routing table size Sure, but we can limit the increases in routing table size. if we want to avoid having our packets take utterly insane routes we are going to have to accept that routing table sizes will never go down to sixteen entries or fifty entries or whatever the magic number people pretend will work might be. Yes and no. If you will consult K+K, you will find that a network the size of the Internet (call it 300K actual wires, an off-the-wall guess) could be routed with a routing table of 3*ln(300K) entries, which works out to about 39 entries, the minimal possible routign table size. The increase in average path length over the optimal would be rather large, about a factor of 5. However, by increasing the table size, one can get substantially better paths. E.g., if we are willing to accept 50% greater path lengths, we can get by with a table of about 300 entries in all routers for a network with 300K wires. If we want to make it down to 10%, that would requires about 3000 entries. As the net gets larger, these numbers get comparatively smaller; e.g. a network with 10M wires (an increase of a factor of 30 in network size) would get 50% increase in path lengths with a table of 2000 entries (an increase of less than a factor of 10), whereas a 10% increase in path length would require 20000 entries. Even when we start with a clean slate in v6 world, we are going to find lots and lots of need to punch down the CIDR walls. Such as? I'm afraid I don't see why (other than partitions). Renumbering wil be easy in IPv6, right? Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 05:36:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27504; Sun, 10 Sep 1995 05:36:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA22112; Sun, 10 Sep 1995 05:35:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA22023; Sun, 10 Sep 1995 05:16:15 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26915; Sun, 10 Sep 1995 05:16:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27351; Sat, 9 Sep 95 15:15:55 -0400 Date: Sat, 9 Sep 95 15:15:55 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509091915.AA27351@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, michael@junction.net Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Precedence: bulk From: Michael Dillon it may well be possible to design a route processing algorithm in which the job is handled by multiple symmetric processes which can then be run effectively on an SMP box. When someone has done it, then let's consider it. these issues are well understood and implemented on these SMP boxes already. This is the same problem that database vendors such as Oracle, Informix and Progress have already solved to handle massive databases on SMP RAID boxes. Perhaps. I somehow doubt the data access patterns for multiple parallel routing entities are going to look the same as your average database; remember, if each routing entity is getting a full table from their peers, they are going to be pawing through the entire routing database, not just small sections. The ration of outside_computing/touching_the_database is probably way different. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 05:37:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27533; Sun, 10 Sep 1995 05:37:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA22134; Sun, 10 Sep 1995 05:37:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA22099; Sun, 10 Sep 1995 05:27:55 +1000 Received: from cu.nih.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27297; Sun, 10 Sep 1995 05:27:49 +1000 (from RAF@CU.NIH.GOV) Message-Id: <9509091927.27297@munnari.oz.au> To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU From: "Roger Fajman" Date: Sat, 09 Sep 1995 15:24:47 EDT Subject: Telephone system upgrades Precedence: bulk > If you were a phone equipment engineer, and went and told someone who worked > for one of the US RBOC's that they'd have to upgrade all their switches > because the phone network in China has gotten bigger, they'd look at you > and wonder what engineering school let you out the door, and they'd be right. It may not be because of China, but there are several things like that going on in the telephone system right now: (1) The change in the North American Numbering Plan to area codes that have middle digits other than 0 and 1. All the phone companies had to upgrade to handle this. Owners of private PBXs are also finding that they have to upgrade. (2) The shortage in the NANP of 800 numbers, which is leading to the introduction of additional toll-free area codes, the first being 888. (3) The upcoming change in the maximum length of international phone numbers to 15 digits. This is close to your China example. Some other recent changes in the NANP that required upgrades were (1) The introduction of exchanges with middle digits of 0 and 1. (2) The introduction of 800 number portability. From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 05:39:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27647; Sun, 10 Sep 1995 05:39:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA22156; Sun, 10 Sep 1995 05:39:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA22050; Sun, 10 Sep 1995 05:18:25 +1000 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26999; Sun, 10 Sep 1995 05:18:21 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA03964; Sat, 9 Sep 95 14:38:07 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA22567; Sat, 9 Sep 95 14:18:07 CDT Date: Sat, 9 Sep 95 14:18:07 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9509091918.AA22567@anubis.network.com> To: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message Precedence: bulk It is astonishing how few people seem to grasp the actual problem. The fact that a cisco 7000 'only' has a 68040@25Mhz and 64M of memory doesn't seem to keep them from working out ok. The problems in the current core are not, as I understand it, in any way related to the amount of memory or the CPU power. The problems are in getting the data you need to do switching to the switching hardware. The reason you need piles of data right at the switch, and the reason you need piles of data in a default free routing database, and the reason multihoming is so hard, and the reason for, I expect, a host of other problems, is that we insist on doing hop-by-hop forwarding based on what is essentially a scalar and fixed object (the 'address') defining the destination. Wow, it really sucks. Now, if we were to go to an internet in which everything is loose source routed by the sender to the right place, the entire core could get away with rather small amounts of information. If the source routes were computed at connection establishment time by querying well-known servers for topology information, and working your way down, DNS-like, it might even work. Something that's not quite this is to put some smarts into boxes at the edge of the core to use the same stunt to get things across the core. Sure, this avoids (to some extent) having the core routers doing all kinds of route computation, which is great, but not germane to the problem at hand. The REAL win comes in making it so that any particular router deep in the core is going to be seeing packets, for the most part, with current destination address somewhere else in the core. This means that the switching engine only needs data for core reachability, not all the end nodes on the planet. This is a cheap knockoff of Nimrod, it probably won't work as stated, but hopefully the example shows a real new paradigm (real ones, not a new paradigm in the sense of Same Stuff, RISC processors or Same Stuff, Big Arrays or Same Stuff, bootp on steroids to kludge it) that might actually make some headway. Well, new in the sense of several to many years old. I have some notes on an actual design and deployment strategy, if anyone wants to look at them, by the way. Andrew From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 05:56:35 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28214; Sun, 10 Sep 1995 05:56:35 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA22218; Sun, 10 Sep 1995 05:55:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA22212; Sun, 10 Sep 1995 05:55:21 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28170; Sun, 10 Sep 1995 05:55:17 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id PAA09436; Sat, 9 Sep 1995 15:55:13 -0400 Message-Id: <199509091955.PAA09436@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Your message of "Sat, 09 Sep 1995 13:52:44 EDT." <9509091752.AA27102@ginger.lcs.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 09 Sep 1995 15:55:13 -0400 From: "Perry E. Metzger" Precedence: bulk Noel Chiappa writes: > I wasn't aware the SMP Unix had the capability to run a single process on > multiple CPU's simultaneously, Well, most SMP unixes can indeed run multiple threads in one process on multiple CPUs simultaneously. Perry From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 05:59:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28315; Sun, 10 Sep 1995 05:59:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA22246; Sun, 10 Sep 1995 05:58:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA22198; Sun, 10 Sep 1995 05:53:51 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28122; Sun, 10 Sep 1995 05:53:45 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id PAA09427; Sat, 9 Sep 1995 15:53:40 -0400 Message-Id: <199509091953.PAA09427@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Your message of "Sat, 09 Sep 1995 13:43:56 EDT." <9509091743.AA27083@ginger.lcs.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sat, 09 Sep 1995 15:53:39 -0400 From: "Perry E. Metzger" Precedence: bulk Noel Chiappa writes: > From: "Perry E. Metzger" > > It assumes that all connection points you have to sprintlink are > identical in quality for all addresses. > > Which points out an issue with multihoming, in the current addressing system, > that most of the multihoming aficionados are ignoring: to get real use out of > multihoming, in terms of using your "best" link for outbound traffic, you can > no longer get by with just internal routes and default: you have to carry > routes about all those external places where you care about the exit link > (i.e. instead of just taking the one nearest the source of the traffic). Yup. However, people are willing to do this because of the added reliability it gives them. > If you get sick of handcrafting filter tables for the 10% of the > Internet you care about, and just say "to heck with it, let's just > carry the whole routing table", that means all of sudden a whole lot > more routers are in the situation where you have to upgrade them > because 20K networks got added on the other side of the world. Unfortunately, thats the case. However, many of the clients I work with have decided to live with the situation because it gives them the reliability they need. > If you have an exchange point in Denver .. and an exchange point in > Toronto ... it probably makes the most sense for you to send packets to > .. customers in Tornoto via the Toronto exchange point and not the > Denver exchange point. However, using the CIDR model, we know nothing > about topology, only about carriers. > > It depends on how you set up the addressing and routing. I don't > want to spent 3 pages explaining something that ought to be > intuitively obvious after several years of talking about this, but > suffice it to say that if the target "network" is really that large, > they are probably using topological aggregations of their own > internally, and acesss to routing information about them (identical, > effectively, to knowing that the Toronto customers are near the > Toronto exchange point) allows you to pick the optimal entry point > into the other provider's network. How do you do that if no seperate routes are advertised by the provider into their Toronto subnetwork? The whole point of CIDR seems to be to eliminate all that sort of thing and get us to the word of fifty or ten or whatever number of routes in the routers at our exchange points. > (PS: I'll bite: can you explain to me how any other addressing plan tells you > more about the network's topology?) Much less agressive agregation tells you more about the network's topology by virtue of advertising more routes at the expense of advertising more routes. Perry From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 06:56:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29974; Sun, 10 Sep 1995 06:56:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA22360; Sun, 10 Sep 1995 06:55:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA22332; Sun, 10 Sep 1995 06:39:09 +1000 Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29460; Sun, 10 Sep 1995 06:38:58 +1000 (from barney@databus.databus.com) Date: Sat, 9 Sep 95 16:38 EDT Message-Id: <9509091639.AA17334@databus.databus.com> From: Barney Wolff To: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message Content-Length: 972 Content-Type: text Precedence: bulk > Date: Sat, 09 Sep 1995 15:55:13 -0400 > From: "Perry E. Metzger" > > Noel Chiappa writes: > > I wasn't aware the SMP Unix had the capability to run a single process on > > multiple CPU's simultaneously, > > Well, most SMP unixes can indeed run multiple threads in one process on > multiple CPUs simultaneously. > > Perry Folks, Noel's point, which some seem unwilling or unable to grasp, is that neither BGP4 nor OSPF have been parallelized. Until that's done, you can run them on a million-processor machine with no gain in speed. The voice of experience says that it will not be trivial, nor outstandingly effective, to parallelize route computation. Believe it, or not - your choice. But don't assume that it's been done and is just awaiting the right hardware to run it on. If you can keep your cool while everybody else is running around in circles screaming, you just don't understand the problem. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 07:37:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00974; Sun, 10 Sep 1995 07:37:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA22415; Sun, 10 Sep 1995 07:35:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA22395; Sun, 10 Sep 1995 07:22:25 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00503; Sun, 10 Sep 1995 07:22:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27701; Sat, 9 Sep 95 17:22:17 -0400 Date: Sat, 9 Sep 95 17:22:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509092122.AA27701@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Routing "experts" Cc: jnc@ginger.lcs.mit.edu Precedence: bulk One thing you can do to keep from going totally insane while listening to all this nonsense is something akin to having kids count licence plates on long car rides, which is to try and characterize the complexity of the mental model of routing which various posters are using. Here's what it looks like, in order of increasing complexity. Local Static: This name comes from the apparent tendency of people to not think about what goes on when a topology change happens; they only look at the steady state. These people tend to think the only important measure/limitation of routing is how much memory the routing tables use. Local Dynamic: This name comes from the apparent inability of people to realize that a topology change has consequences in the network which range over a scope, and that here in the real world, it takes real time for this to happen, and for the routing (which is a continuous, distributed, computation) to stabilize again. These people tend to understand that routing changes can use CPU as well, but don't think about the overall stabilization time. Global Dynamic: Now we are operating with a pretty good model, one which considers things like update propogation time, systemwide stabilization time, etc, etc. However, there are still simplifications. The most common big one is the assumption that the routing will stabilize after a topology change before the next one happens. Of course, in a sufficiently large network, depending on what model you are using for topology changes, this may or may not be true. (Hint: Poisson doesn't work when a backhoe hits a major fiber.) Monometric: So, now we are operating with a model which is actually workable for today's network, where all the routing happens in terms of a single metric. Of course, 10 years out, this will not longer be true, and links will be characterized by a whole vector of numbers, at which point you step up into another whole hierarchy of routing difficulty and complexity (as yet just barely scratched), but let's not ascend into the stratosphere until we have to. One of the things which I allow myself to do, which is really dumb and stupid on my part, is to let myself be dragged down some pointless little rathole like arguing simplistic points like memory size, computing power, etc. I.e., I voluntarily step down into some simplistic and unrealistic model. Really pinheaded on my part, and I shouldn't. Stable routing takes a lot more than computing power and memory, as has been known since the early days of the old ARPANet. (See BBN report #3803.) However, this realization appears not to have pentrated all the routing "experts" out there in the Internet. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 07:56:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01294; Sun, 10 Sep 1995 07:56:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA22473; Sun, 10 Sep 1995 07:55:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA22455; Sun, 10 Sep 1995 07:51:46 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01205; Sun, 10 Sep 1995 07:51:41 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA11231 (5.65c/IDA-1.4.4); Sat, 9 Sep 1995 17:51:23 -0400 From: Tim Bass Message-Id: <199509092151.AA11231@linux.silkroad.com> Subject: Re: oops -- wrong message To: barney@databus.com (Barney Wolff) Date: Sat, 9 Sep 1995 17:51:23 -0400 (EDT) Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <9509091638.AA17338@databus.databus.com> from "Barney Wolff" at Sep 9, 95 04:38:00 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1776 Precedence: bulk > > Folks, Noel's point, which some seem unwilling or unable to grasp, is > that neither BGP4 nor OSPF have been parallelized. Until that's done, > you can run them on a million-processor machine with no gain in speed. > Huh? Noboby that I have read is suggesting that BGP4 nor OSPF are inter-domain protocols of the future. The IETF has announced that BGP4 dies in favor for another (still under development) inter-domain routing protocol. It seems somewhat tangential to debate whether high end Intel or RISC processors with 64/32 bit bus architectures and over 512M RAM capable perform better than 68040 chips with 64M memory. Routers are just computers with interfaces for data communications. If the router vendors made such good computers, then we would see them on our desk tops as work stations (a much bigger market than routers :-). Certainly the operating system of a router is not better than a refined UNIX.... Router hardware is not the real issue, it seems, but makes interesting debate (maybe). Any one interesting in discussing the merits of M. Steenstrup IDPR inter-domain policy routing and similar protocols? Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 07:57:36 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01386; Sun, 10 Sep 1995 07:57:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA22495; Sun, 10 Sep 1995 07:57:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA22452; Sun, 10 Sep 1995 07:51:41 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01199; Sun, 10 Sep 1995 07:51:31 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA11231 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Sat, 9 Sep 1995 17:51:23 -0400 From: Tim Bass Message-Id: <199509092151.AA11231@linux.silkroad.com> Subject: Re: oops -- wrong message To: barney@databus.com (Barney Wolff) Date: Sat, 9 Sep 1995 17:51:23 -0400 (EDT) Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <9509091638.AA17338@databus.databus.com> from "Barney Wolff" at Sep 9, 95 04:38:00 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1776 Precedence: bulk > > Folks, Noel's point, which some seem unwilling or unable to grasp, is > that neither BGP4 nor OSPF have been parallelized. Until that's done, > you can run them on a million-processor machine with no gain in speed. > Huh? Noboby that I have read is suggesting that BGP4 nor OSPF are inter-domain protocols of the future. The IETF has announced that BGP4 dies in favor for another (still under development) inter-domain routing protocol. It seems somewhat tangential to debate whether high end Intel or RISC processors with 64/32 bit bus architectures and over 512M RAM capable perform better than 68040 chips with 64M memory. Routers are just computers with interfaces for data communications. If the router vendors made such good computers, then we would see them on our desk tops as work stations (a much bigger market than routers :-). Certainly the operating system of a router is not better than a refined UNIX.... Router hardware is not the real issue, it seems, but makes interesting debate (maybe). Any one interesting in discussing the merits of M. Steenstrup IDPR inter-domain policy routing and similar protocols? Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 07:58:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01489; Sun, 10 Sep 1995 07:58:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA22519; Sun, 10 Sep 1995 07:58:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA22446; Sun, 10 Sep 1995 07:48:34 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01164; Sun, 10 Sep 1995 07:48:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27772; Sat, 9 Sep 95 17:47:41 -0400 Date: Sat, 9 Sep 95 17:47:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509092147.AA27772@ginger.lcs.mit.edu> To: perry@piermont.com Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Perry E. Metzger" many of the clients I work with have decided to live with the situation because it gives them the reliability they need. I hope your clients are also paying attention to the advice coming from a regional network person, who said that in their experience the most important aspect of reliability was to have spares on site, local tail-circuit runs through different paths into different CO's, etc. (I was offline for 36 hours recently when my primary dial-in machine died. Screwed up top-level providers have never had anything like that bad a hit.) Multihoming is *not* a reliability panacea, and any customer who is led to believe that is is will probably be pretty upset when some other unidentified single point of failure (e.g. a big local hub router) goes belly-up and takes them down for a day and more. >> If you have an exchange point in Denver .. and an exchange point in >> Toronto ... it probably makes the most sense for you to send packets to >> .. customers in Tornoto via the Toronto exchange point and not the >> Denver exchange point. How do you do that if no seperate routes are advertised by the provider into their Toronto subnetwork? Your question as stated doesn't make any sense to me; you started off talking about traffic going *to* Toronto, so there's no way routes advertised *into* Toronto can make any difference. Perhaps you meant routes about Toronto advertised into some other exchange points. The whole point of CIDR seems to be to eliminate all that sort of thing and get us to the word of fifty or ten or whatever number of routes in the routers at our exchange points. Then you don't understand what CIDR is trying to do at all (and I'm not talking about the cartoon version in which we get it down to 50 routes in every router). The point of CIDR is to get us to the point where we can have near-optimal routing, with routing tables which are substantially smaller than flat tables. However, to do that, we have to have an addressing hierarchy which is a good match to the topology. This doesn't mean that we immediately aggregate routes to X.[1-9] into a single route to X as soon as we are outside X; this would indeed give us a lot of non-optimal entry point selection. Howver, at some distance away from X, we *would* like to aggregate routes to X.* into a single route to X; when you get far away from X, you can generally do so without making the routes noticably worse. However, unless addresses X.* are assigned with topological significance, so that they *can* be aggregated, we won't be able to, and we'll have to carry them around globally as separate routes. That's all CIDR is, really. > I'll bite: can you explain to me how any other addressing plan tells you > more about the network's topology? Much less agressive agregation tells you more about the network's topology by virtue of advertising more routes at the expense of advertising more routes. This is not a function of the aggressiveness of the *naming aggregation*, as it is of the *routing aggregation*. In case this wasn't clear, look at the example above. Although X.* have been "aggressive aggregated" into X, you still can get "more routes" (and the better routes that result) by control of the scope over which those individual pieces are advertised. In routing jargon, this is called having an "abstraction action boundary" (AAB) which is larger than the "abstraction naming boundary" (ANB). You can set the AAB's *independently* of the ANB's to provide better routes than you get in the simple case where the AAB and the ANB are the same. How much better is a cost/benefit tradeoff each part of the net has to decide on their own, since the larger AAB's are i) more work to configure, and ii) entail more routign overhead. (Technical aside: Note that although K+K only considers the AAB == ANB case, it's not clear how much better than that you can get, since in some sense the larger AAB could be emulated by adding intermediate ANB's. Even More Technical aside: If you start considering non-congruent AAB's - i.e. ones in which the AAB for X.1 is *not* the same as X.2, outside X - you probably can get even better results.) We've had this talk 3 times over on Big-Internet already in *this* round (as well as several preceeding rounds), so I'll stop there. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 08:00:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01514; Sun, 10 Sep 1995 08:00:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA22541; Sun, 10 Sep 1995 08:00:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA22449; Sun, 10 Sep 1995 07:50:51 +1000 Received: from cesium.clock.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01186; Sun, 10 Sep 1995 07:50:41 +1000 (from smd@cesium.clock.org) Received: by cesium.clock.org id <6215>; Sat, 9 Sep 1995 14:50:30 -0700 From: Sean Doran To: jnc@ginger.lcs.mit.edu, perry@piermont.com Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Message-Id: <95Sep9.145030pdt.6215@cesium.clock.org> Date: Sat, 9 Sep 1995 14:50:25 -0700 Precedence: bulk Perry - The 'ideal' of one route per provider is more of a rhetorical device than reality, however let's analyse the direction things are heading in now. First we have a simple model, where providers S and M aggregate all of their customers into precisely one prefix each. Next, pretend that both sides do closest-exit routing, and that the topology of each network looks like this: Chicago || B==========C =================D====Pennsaken || // \\ Mt View==A=========F======================E==Vienna for simplicity. We then add a customer X of S in Toronto and connected to D and a customer Y of M in Denver, connected to F. With this topology, the closest exit from X to M is in Chicago, so traffic from X->Y might go: X->F(S)->C(S)->Chicago->C(M)->D(M)->Y while traffic from Y->X might go: Y->D(M)->Pennsauken->D(S)->C(S)->F(S)->X In this model S and M each only needs to know its internal topology in order to a/ get to the closest peering point where traffic can be handed to the other network and b/ know how to deliver to any subnet of its provider prefix. The bright side to this system is that it scales well to the number of peering points. If one envisages one per LATA or per major city throughout the world, the system improves by keeping local traffic local, and having remote traffic take optimal paths through the network that has the information to make that possible. The two drawbacks are the lack of physical path symmetry (which in practice is not that bad, and has been happening for a couple of years now anyway) and the fact that each provider must provide full redundancy so that the single prefix isn't partitioned. The second part has another side-effect which is unpleasant, and that is if the redundancy in M takes traffic well out of its way during a circuit or router failure, it is probably better to use another exit point from S->M than the closest one. The solution to this is pretty straightforward, and it's something that the bulk of the large providers I know about tend to do, namely, allocate and aggregate on a per-POP basis. That is, instead of S giving M one prefix (1/8), it gives M a prefix per POP (A=1.0/11, B=1.32/11, C=1.64/11, D=1.96/11,E=1.128/11,F=1.160/11, remainder parceled out as needed). If an east<-->west partiton happens in S, then M will hear about D and E in Pennsauken and Vienna, and A B C and F in Chicago and Mt View. M then routes towards the closest exit where it hears the appropriate prefix, and things work OK. In some cases it would be a good idea to provide metrics with prefixes, so that if there is a fall-over of a circuit in S that doesn't lead to an actual partition, such as a failure of A<-->B and C<-->F, S might want to be able to tell M that it should prefer to send traffic to B via some peering point other than Mt View, in order to avoid A->F->E->D->C->B. (This could be done by withdrawing announcements rather than using metrics, though). WRT metrics, one could even go so far as to turn closest-exit on its head and make it mutual best exit. In this case, metrics (MEDs, even) are associated with the per-POP prefixes. In this case, the X<-->Y traffic might be: X->F(S)->E(S)->D(S)->Pennsauken->D(M)->Y and Y->D(M)->C(M)->Chicago->C(S)->F(S)->Y which is roughly the reverse of the closest-exit. This has the most of the same advantages and disadvantages as closest-exit, except that each network is armed only with limited amounts of information about the other, and consequently could make suboptimal routing choices anyway. As an example, if a site is homed to F(S) and A(S) and is addressed as 1.160.2/24, then even if S carries the subnet around itself so that it routes optimally towards it (traffic from A(S) or B(S) to 1.160.2/24 goes through the connection at A(S); traffic from elsewhere goes through the connection to F(S)), M->1.160.2/24 will enter at Chicago. Consider: L->A(M)->B(M)->C(M)->Chicago->C(S)->F(S)->1.160.2/24 vs the closest-exit path of L->A(M)->Mt View->A(S)->1.160.2/24 The only way for the MED system (the reverse of closest-exit that uses metrics) to do the same thing is if M is advertised 1.160.2/24 as well as 1.160/11. Given enough of these exceptions, one either ends up making bad routing decisions in the sending network or the sending network ends up carrying lots of extra routing information. Moreover, for this to work properly, M has to learn S's metrics as they change, which will increase the number of routing updates that M has to process, which may happen even when a change in S's metrics doesn't result in a change of M's routing towards S. This typically scales badly with the number of peering points and the number of prefixes, and with large amounts of both, occasional instability (a DS3 that falls over every so often, for example) in either M or S could seriously hose the other network's routers. So, mutual closest-exit, sans metrics, keeps it simple and _works_, and so long as one is careful about the failure modes, it works well. Moreover, a maximal amount of aggregation can happen, approaching one prefix per provider, possibly preferring one prefix per provider per peering point, and with a maximum of one prefix per POP per provider. Finally, the model is well-deployed (thousands of sites have routing towards each other in this manner) and is working now. Sean. From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 08:56:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02954; Sun, 10 Sep 1995 08:56:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA22644; Sun, 10 Sep 1995 08:55:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA22629; Sun, 10 Sep 1995 08:48:43 +1000 Received: from cesium.clock.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02676; Sun, 10 Sep 1995 08:48:36 +1000 (from smd@cesium.clock.org) Received: by cesium.clock.org id <6213>; Sat, 9 Sep 1995 15:48:23 -0700 From: Sean Doran To: barney@databus.com, bass@linux.silkroad.com Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU Message-Id: <95Sep9.154823pdt.6213@cesium.clock.org> Date: Sat, 9 Sep 1995 15:48:21 -0700 Precedence: bulk [removed com-priv] IDRP is the name you are searching for. It has its pluses and minuses. I suspect, however, (just a gut feeling) that what we'll end up with will more likely be an evolved BGP4 for IPv6. It's hard to say; IDRP is still, as you say, under development. BGP4 is evolving quickly thanks to natural selection pressures. Which one gets used ultimately depends on how quickly IPv6 will be routed in the real world. I wouldn't start holding your breath yet. However, _lots_ of money to pay for deployment and development is an *excellent* selection pressure. Sean. (Internet Darwinist) From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 08:57:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02965; Sun, 10 Sep 1995 08:57:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA22666; Sun, 10 Sep 1995 08:57:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA22606; Sun, 10 Sep 1995 08:35:53 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02381; Sun, 10 Sep 1995 08:35:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27943; Sat, 9 Sep 95 18:35:37 -0400 Date: Sat, 9 Sep 95 18:35:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509092235.AA27943@ginger.lcs.mit.edu> To: barney@databus.com, bass@linux.silkroad.com Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: Tim Bass Noboby that I have read is suggesting that BGP4 nor OSPF are inter-domain protocols of the future. The IETF has announced that BGP4 dies in favor for another (still under development) inter-domain routing protocol. Ah. Very interesting. I'm not sure exactly which future protocol you're referring to, but I can think of 3 candidates. Let me list them, and you can tell me if you're thinking of something else. 1 - IDRP. This is basically BGP-4, and is was done by (among others) Yakov Rekhter. Yakov is one of the authors of the renumbering proposal you don't like, so no joy there. 2 - Unified/SDRP/ERP. This has two modes, one with explicit routes, and one with presetup routes; the presetup mode uses BGP-4/IDRP. Being done by Deborah Estrin, Tony Li, etc. No joy there for you either. 3 - Nimrod. A very different design based solely on map distribution. It's being detailed designed and mplemented by a crew at BBN, but the basic design was done be me. Even less joy for you in that one. So, can you tell me which of these inter-domain protocols of the future it is that is going to save you, it would be most interesting. (Also, AFAIK, the "IETF" has made no decision as to what comes after BGP-4. Efforts #'s 2 and 3 above are just being done by a subset of people who want to work on them, *not* as the officially chosen IETF next step.) (Finally, just out of interest, do you notice anything about the names of the people doing these advanced routing thingys? Rekhter. Li. Chiappa. Any bells starting to go off yet? Hmm, all people who are loudest in favor of topological addresses. Funny thing. Even funnier is that Yakov and I almost totally disagree about how to do the routing, but both agree 100% on the addressing. Mental clones we aren't.) Certainly the operating system of a router is not better than a refined UNIX.... I wouldn't be so sure. Unix was pretty good in its day, for a PDP-11 that is, but those days were long ago. Unix is the Fortran of the 90's... (and 2000's, and....) "refined Unix", now there's any oxymoron for you. Any one interesting in discussing the merits of M. Steenstrup IDPR inter-domain policy routing and similar protocols? I'm not sure if anyone is still working on that. Martha is now PI for the Nimrod project, BTW. Perhaps you could ask her her opinion of CIDR, geographic addresses, etc. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 08:59:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02997; Sun, 10 Sep 1995 08:59:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA22688; Sun, 10 Sep 1995 08:58:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA22626; Sun, 10 Sep 1995 08:40:54 +1000 Received: from cesium.clock.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02485; Sun, 10 Sep 1995 08:40:49 +1000 (from smd@cesium.clock.org) Received: by cesium.clock.org id <6213>; Sat, 9 Sep 1995 15:40:35 -0700 From: Sean Doran To: jnc@ginger.lcs.mit.edu, perry@piermont.com Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Message-Id: <95Sep9.154035pdt.6213@cesium.clock.org> Date: Sat, 9 Sep 1995 15:40:28 -0700 Precedence: bulk Oh, and further to my previous message, something I forgot: we can hide the /11 subnets from places that don't need it via BGP communities. Using a pseudo-language for configuring it: to M advertise 1.0.0.0 255.0.0.0 advertise 1.0.0.0 255.224.0.0 community no-export advertise 1.32.0.0 255.224.0.0 community no-export advertise 1.64.0.0 255.224.0.0 community no-export ... Or even this, given a topology wherein one uses common-AS tricks, such that each POP is its own AS: on customer-access box in A(S): to backbone boxes connected to A(S) advertise 1.1.1.0 255.255.255.0 community no-propagate advertise 1.1.2.0 255.255.255.0 community no-propagate ... advertise 1.1.126.0 255.255.255.0 community no-export on backbone boxes connected to A(S): to all backbone routers advertise 1.0.0.0 255.224.0.0 on customer box connected to F(S): to backbone advertise 1.1.126.0 255.255.255.0 community no-export advertise 1.2.3.0 255.255.255.0 community no-export advertise 1.160.1.0 255.255.255.0 community no-propagate advertise 1.160.2.0 255.255.255.0 community no-propagate ... Notice that we preserve the hole for our dual-homed-to-A(S)-and-F(S) network within the backbone but don't propagate them outside the backbone. (The clever will note that it might be necessary to propagate the hole to A(S) and F(S) for some purposes). I also introduced another hole, just do demonstrate that if someone gets rehomed entirely from A(S) to F(S), this doesn't need to be known globally, just to the backbone. There are shortcuts to this kind of configuration that one can do on real boxes, naturally; this is just for show. (Let's avoid talk about routing databases here, please :) ) A message to CIDRD discussed the practical aspects of implementing this on Ciscos. The theory here was described by Noel using simple lettering: S.[A-F].* -> S.[A-F] S.[A-F] -> S and propagating S to the places that need only S (singly homed connections and things farther away), S.[A-F] to the places that need S.[A-F] (multiply-connected peers), and S.[A-F].* to places that need that kind of detail (which rarely ever will be outside of S's routing domain). With the current communities, one has pretty good control over things; if other syntax is needed, it's easy enough to do. I envisage communities which allow or deny propagation to particular ASes, that put a limit on the number of ASes away the prefix can be propagated and the like, and hope it's never necessary to do anything like that. (cf. my various comments on the Chen/Bates draft) Sean. From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 11:18:48 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06577; Sun, 10 Sep 1995 11:18:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23134 Sun, 10 Sep 1995 11:18:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA22859; Sun, 10 Sep 1995 11:15:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA22853; Sun, 10 Sep 1995 11:10:17 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06460; Sun, 10 Sep 1995 11:10:12 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id SAA07540; Sat, 9 Sep 1995 18:17:22 -0700 Date: Sat, 9 Sep 1995 18:17:21 -0700 (PDT) From: Michael Dillon To: Noel Chiappa Cc: perry@piermont.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Subject: Re: oops -- wrong message In-Reply-To: <9509092147.AA27772@ginger.lcs.mit.edu> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Noel Chiappa wrote: > The whole point of CIDR seems to be to eliminate all that sort of thing > and get us to the word of fifty or ten or whatever number of routes in the > routers at our exchange points. > > Then you don't understand what CIDR is trying to do at all (and I'm not > talking about the cartoon version in which we get it down to 50 routes in > every router). The point of CIDR is to get us to the point where we can have > near-optimal routing, with routing tables which are substantially smaller than > flat tables. However, to do that, we have to have an addressing hierarchy > which is a good match to the topology. On the surface this seems true. Packets follow a default route upstream until they hit a well-connected router, they then get routed based on an aggregate to another well connected router which just happens to be the best choice upstream from the destination. As the packets travel downstream the routers have more finely divided routes pointing to local downstream locations only. But this picture assumes a tree structured topology which is not an accurate mapping of current and future plans for the Internet. What effect will actual topology have on this routing scenario? I'm specifically thinking of more widespread multi-homing because I know most ISP's have this as a goal. Many also have intentions to haul a line into a NAP even if they are still buying transit. And many metropolitan areas are now setting up local exchange points using the NAP model but only for local or regional providers. Have people considered the impact of this on routing? > worse. However, unless addresses X.* are assigned with topological > significance, so that they *can* be aggregated, we won't be able to, and we'll > have to carry them around globally as separate routes. We could always accept a certain amount of sub-optimal routing caused by non-topological aggregation. For instance, if there are significant blocks of /24 addresses we could aggregate them into clocks, choose which sites will route these and divide up those blocks between the core routers so that no router needs the entire details of all /24's and accept sub-optimal routing for these addresses. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 12:16:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08160; Sun, 10 Sep 1995 12:16:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA22937; Sun, 10 Sep 1995 12:15:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA22931; Sun, 10 Sep 1995 12:11:34 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08074; Sun, 10 Sep 1995 12:11:31 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id TAA17172; Sat, 9 Sep 1995 19:10:37 -0700 Date: Sat, 9 Sep 1995 19:10:37 -0700 From: Tony Li Message-Id: <199509100210.TAA17172@greatdane.cisco.com> To: jerry@fc.net (Jeremy Porter) Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), michael@junction.net, smd@cesium.clock.org, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu, inet-access@earth.com Subject: Size of routers Precedence: bulk With parallel solutions there would really be very little difficulty in putting off the heat death of CIDR by several years. There are some problems here: first, the heat death is from the growth of the net. One possible solution is CIDR. Yes, more thrust will delay this. It will not prevent it. The Processing power difference and memory utilization differences between a Cisco 7000 with a 68040) and a 8 CPU 200mhz RISC processer SMP box is pretty high. True. And, gee, it might look like a 7500. Imagine that. ;-) But you're still missing the point: throwing more hardware at the problem is not a reasonable long term solution. The whole reason that we started down this path is that the exponential growth of the net exceeds the rate at which hardware progresses. Just doing SMP only increases things by a constant and that gets gobbled up very quickly. Folks here are missing the strategy for the tactics. If growth can be slow to doubling every 12 months, this gives us 4 years to get a radical change like IPV6 ready. Well, the current, proven technique to slow growth is CIDR. That pretty much stops growth (and has, at times, given us negative growth). It seems pretty clear to me that there are hardware solutions to handle the real problems of growth, but there does need to be some effective work done to slow groth. Well, the latter is what we're after. Given the latter, the former becomes unnecessary. Normal hardware evolution sufficies and hardware heroics are of no benefit. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 12:36:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08771; Sun, 10 Sep 1995 12:36:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA22978; Sun, 10 Sep 1995 12:35:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA22974; Sun, 10 Sep 1995 12:34:37 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08744; Sun, 10 Sep 1995 12:34:35 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id TAA17392; Sat, 9 Sep 1995 19:34:25 -0700 Date: Sat, 9 Sep 1995 19:34:25 -0700 From: Tony Li Message-Id: <199509100234.TAA17392@greatdane.cisco.com> To: michael@junction.net (Michael Dillon) Cc: Sean Doran , asp@uunet.uu.net, bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Subject: Size of routers... Precedence: bulk Cisco has separated the functions within their own boxes, but has anyone put these funtions into two separate boxes? As a matter of fact, yes. I believe that if the route processing was handled in a standard box based on UNIX that problems of CPU power, RAM capacity and the like could be averted. The theory being that Unix systems are not subject to the laws of growth of CPU power or RAM? Sorry, the net still crashes and burns if you do this. Your Unix box still doesn't grow fast enough. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 12:38:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08839; Sun, 10 Sep 1995 12:38:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA23000; Sun, 10 Sep 1995 12:38:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA22968; Sun, 10 Sep 1995 12:29:14 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08664; Sun, 10 Sep 1995 12:29:12 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id TAA17320; Sat, 9 Sep 1995 19:28:35 -0700 Date: Sat, 9 Sep 1995 19:28:35 -0700 From: Tony Li Message-Id: <199509100228.TAA17320@greatdane.cisco.com> To: perry@piermont.com ("Perry E. Metzger") Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Size of routers Precedence: bulk Until a week or two ago when Cisco finally announced a new 7500 series router which finally uses a RISC processor at decent speed, their top of the line router used the astonishingly pathetic 25Mhz 68040. Its painful to think about $75K-$100K pieces of equipment using processors that wouldn't be acceptable in bottom of the line video game equipment. If you're going to dis us, please do it with FACTS. Recall that the 7000 also has one (or more) 70MIPS processors per interface. And the fact that they are not your conventional workstation CPU does not make them ineffective. [For the record: they're VLIW microsequencers. They are most impressive in their efficiency.] Plus the SSP, which defies any conventional characterization but produces over 270k switching decisions per second. You might also recall that when the 7000 (really the CSC/4) came out, the 68040 was pretty much the peak of the CISC microprocessor market. I even recall us having trouble getting them because they were so new. Thus, if you want to dis us, you really should focus on the length of the product cycle: and that's directly tied to the complexity of the problem and the non-volume of this market space. This is not an area where you slap together a motherboard, the latest CPU, some RAM, and ship 200,000 units the first quarter. It would be really neat to see how our routers did if they actually kept up with current technology. Please feel free to purchase a 7500 and find out for yourself. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 12:56:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09361; Sun, 10 Sep 1995 12:56:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA23060; Sun, 10 Sep 1995 12:55:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA23033; Sun, 10 Sep 1995 12:43:19 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09153; Sun, 10 Sep 1995 12:43:15 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id TAA17437; Sat, 9 Sep 1995 19:41:50 -0700 Date: Sat, 9 Sep 1995 19:41:50 -0700 From: Tony Li Message-Id: <199509100241.TAA17437@greatdane.cisco.com> To: asp@uunet.uu.net (Andrew Partan) Cc: smd@cesium.clock.org (Sean Doran), michael@junction.net, bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Subject: Distributed systems Precedence: bulk > Tsk, Andrew, yes it is and you have 60+ in your backbone. > What do you think the Cisco RP+SSP combination is? A tightly coupled system that a lot of people burned a lot of skull sweat over to make work; not the loosely coupled system that was proposed. Let's not quibble over the semantics of "tight" vs. "loose". That's pointless. In the system proposed, the router still gets full routes via BGP. It then still processes them and shoves them into the SSP. Where's the conceptual difference? What's the strategic win? I'll certainly grant you a constant factor of memory savings, where the constant is proportional to the number of peerings. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 12:59:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09398; Sun, 10 Sep 1995 12:59:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA23082; Sun, 10 Sep 1995 12:58:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA23036; Sun, 10 Sep 1995 12:46:52 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09193; Sun, 10 Sep 1995 12:46:49 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id TAA17468; Sat, 9 Sep 1995 19:46:43 -0700 Date: Sat, 9 Sep 1995 19:46:43 -0700 From: Tony Li Message-Id: <199509100246.TAA17468@greatdane.cisco.com> To: root@kbs.netusa.net (Sanjay Kapur) Cc: Andrew Partan , dorian@cic.net, SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them Precedence: bulk Of course I agree that renumbering helps. I have said so many times. I have also said that NSPs should try to renumber existing customers to compress fragmented routing tables. I have even proposed that NSPs provide incentives (consulting, monetary) to convince customers to renumber. I have also said that renumbering should be made easy by application, OS and network software vendors. I have even proposed charging fees for advertising routing prefixes to encourage users to renumber within a provider's block. I am convinced that the above steps will not only reduce the growth in the routing tables, they may actually reduce the existing size of those tables. Even multi-homing will not really add that much to the size of the tables as will be gained by the steps outlines above. What I am opposed to is FORCED renumbering, especially when changing providers. Voluntary renumbering was first requested in RFC 1338 (6/26/1992). Compliance has been "low", with many new sites requesting "portable" addresses. And the routing table again appears to be experiencing exponential growth. Tried that. Didn't work. Next? Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 13:01:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09571; Sun, 10 Sep 1995 13:01:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA23107; Sun, 10 Sep 1995 13:01:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA23045; Sun, 10 Sep 1995 12:54:32 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09341; Sun, 10 Sep 1995 12:54:23 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA13015 (5.65c/IDA-1.4.4 for big-internet@munnari.OZ.AU); Sat, 9 Sep 1995 22:54:05 -0400 From: Tim Bass Message-Id: <199509100254.AA13015@linux.silkroad.com> Subject: Re: oops -- wrong message To: smd@cesium.clock.org (Sean Doran) Date: Sat, 9 Sep 1995 22:54:04 -0400 (EDT) Cc: barney@databus.com, big-internet@munnari.OZ.AU In-Reply-To: <95Sep9.154823pdt.6213@cesium.clock.org> from "Sean Doran" at Sep 9, 95 03:48:21 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2526 Precedence: bulk > > > [removed com-priv] > > IDRP is the name you are searching for. It has its pluses > and minuses. I suspect, however, (just a gut feeling) that > what we'll end up with will more likely be an evolved > BGP4 for IPv6. Sean, there is IDPR and IDRP. Interdomain Policy Routing (IDPR) that is not cited in the Routing (idr) working group (RFCs 1477, 1478, 1479). How do these relate to IDRP? > > It's hard to say; IDRP is still, as you say, under development. > BGP4 is evolving quickly thanks to natural selection pressures. On the surface, without complete knowledge of the past, it seems that BGP4 was pushed out in front of IDR development based on CIDR efforts. IDR seems to move route processing out of the routers and distribute the problem using AD (autonomous domains), ( similar to AS ). It is puzzling to me why some of the core ideas from these RFCs seem to have died in favor of CIDR. The merit archives show that IDR discussions just died and BGP4/CIDR kept moving. I am not convinced, as you know, that this was based solely on technical merit. IDR has a chance to be a basic for distributed non-provider based aggregation..... Excuse me for my ignorance in this area, but as I look into the problem (when I have the time) it seems that many of the ideas discussed by myself, Crocker, KRE, et. al. have been looked into in some shape or form before and stalled due to some reason, probally technical difficulty. Some of the RFCs remind me of the MULTICs UNIX thing, where MULTICs tried to be everything and never worked, but gave birth to a less complex UNIX. Thanks. > > Which one gets used ultimately depends on how quickly > IPv6 will be routed in the real world. I wouldn't > start holding your breath yet. However, _lots_ of money > to pay for deployment and development is an *excellent* > selection pressure. > > Sean. (Internet Darwinist) > Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 13:16:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09905; Sun, 10 Sep 1995 13:16:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA23164; Sun, 10 Sep 1995 13:16:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA23096; Sun, 10 Sep 1995 13:00:53 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09476; Sun, 10 Sep 1995 13:00:47 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id WAA00994; Sat, 9 Sep 1995 22:59:49 -0400 Date: Sat, 9 Sep 1995 22:59:48 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Tony Li Cc: Andrew Partan , dorian@cic.net, SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <199509100246.TAA17468@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Tony Li wrote: > Voluntary renumbering was first requested in RFC 1338 (6/26/1992). > Compliance has been "low", with many new sites requesting "portable" > addresses. And the routing table again appears to be experiencing > exponential growth. > > Tried that. Didn't work. Next? > > Tony > What gives you the idea that there will be any more compliance with forced renumbering? Has any real analysis of the human and technical factors that has resulted in the low level of compliance been done? Anectodal evidence suggests that NSPs do not even try to convince their customers to use a number out of the NSP's block. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 13:18:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09948; Sun, 10 Sep 1995 13:18:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA23191; Sun, 10 Sep 1995 13:18:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA23118; Sun, 10 Sep 1995 13:02:11 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09584; Sun, 10 Sep 1995 13:02:06 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA13066 (5.65c/IDA-1.4.4); Sat, 9 Sep 1995 23:00:50 -0400 From: Tim Bass Message-Id: <199509100300.AA13066@linux.silkroad.com> Subject: Re: Size of routers... To: tli@cisco.com (Tony Li) Date: Sat, 9 Sep 1995 23:00:50 -0400 (EDT) Cc: michael@junction.net, smd@cesium.clock.org, asp@uunet.uu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <199509100234.TAA17392@greatdane.cisco.com> from "Tony Li" at Sep 9, 95 07:34:25 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1545 Precedence: bulk > > The theory being that Unix systems are not subject to the laws of > growth of CPU power or RAM? > > Sorry, the net still crashes and burns if you do this. Your Unix box > still doesn't grow fast enough. > > Tony CPU horsepower is growing at a rate similar to the net. Pentium P5s at 60 to 133 MHz in a few months.... the P6 is on the horizon... it seems every month is a major improvement in CPU performance. It is quite easy to plug and play motherboard swap and RAM upgrades in these boxes much easier and cheaper than a new product development cycle for a commercial router. This is very true considering the size of the market that requires this routing horsepower. (we are talking about IPV4) [ and we haved discussed pthreads and SMP in any real detail] commercial routers use somewhat antiquated CPUs (until recently only the 4500 had a RISC processor in the cisco product line, right?) Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 13:21:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09975; Sun, 10 Sep 1995 13:21:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA23216; Sun, 10 Sep 1995 13:21:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA23113; Sun, 10 Sep 1995 13:01:38 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09569; Sun, 10 Sep 1995 13:01:29 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA13066 (5.65c/IDA-1.4.4 for big-internet@munnari.OZ.AU); Sat, 9 Sep 1995 23:00:50 -0400 From: Tim Bass Message-Id: <199509100300.AA13066@linux.silkroad.com> Subject: Re: Size of routers... To: tli@cisco.com (Tony Li) Date: Sat, 9 Sep 1995 23:00:50 -0400 (EDT) Cc: michael@junction.net, smd@cesium.clock.org, asp@uunet.uu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <199509100234.TAA17392@greatdane.cisco.com> from "Tony Li" at Sep 9, 95 07:34:25 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1545 Precedence: bulk > > The theory being that Unix systems are not subject to the laws of > growth of CPU power or RAM? > > Sorry, the net still crashes and burns if you do this. Your Unix box > still doesn't grow fast enough. > > Tony CPU horsepower is growing at a rate similar to the net. Pentium P5s at 60 to 133 MHz in a few months.... the P6 is on the horizon... it seems every month is a major improvement in CPU performance. It is quite easy to plug and play motherboard swap and RAM upgrades in these boxes much easier and cheaper than a new product development cycle for a commercial router. This is very true considering the size of the market that requires this routing horsepower. (we are talking about IPV4) [ and we haved discussed pthreads and SMP in any real detail] commercial routers use somewhat antiquated CPUs (until recently only the 4500 had a RISC processor in the cisco product line, right?) Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 13:24:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10235; Sun, 10 Sep 1995 13:24:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA23238; Sun, 10 Sep 1995 13:23:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA23154; Sun, 10 Sep 1995 13:13:02 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09829; Sun, 10 Sep 1995 13:12:53 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA13155 (5.65c/IDA-1.4.4 for big-internet@munnari.OZ.AU); Sat, 9 Sep 1995 23:12:18 -0400 From: Tim Bass Message-Id: <199509100312.AA13155@linux.silkroad.com> Subject: Re: Distributed systems To: tli@cisco.com (Tony Li) Date: Sat, 9 Sep 1995 23:12:18 -0400 (EDT) Cc: asp@uunet.uu.net, smd@cesium.clock.org, michael@junction.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <199509100241.TAA17437@greatdane.cisco.com> from "Tony Li" at Sep 9, 95 07:41:50 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1747 Precedence: bulk > pointless. In the system proposed, the router still gets full routes > via BGP. It then still processes them and shoves them into the SSP. > > Where's the conceptual difference? What's the strategic win? I'll > certainly grant you a constant factor of memory savings, where the > constant is proportional to the number of peerings. > The conceptual difference is that the adjunct route processor does not shove the entire routing load into the SSP. Just like dial up access to a provider, you don't need a modem for every dial up customer; or in the Dial Central Office you don't need a telephone port for every customer in the switch.... In the router, you don't require the full Internet routing table at any given moment. When a destination address appears that does not exist in the router cache, the router *then* gets the information from the adjunct route processor. Routes expire is some optimal time period as well. So, with an adjunct route processor to manage route flap, link state, forwarding table for the global net, the router just manages active IP destinations. Tim > Tony -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 13:37:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10549; Sun, 10 Sep 1995 13:37:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA23278; Sun, 10 Sep 1995 13:36:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA23269; Sun, 10 Sep 1995 13:31:49 +1000 Received: from netcom16.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10373; Sun, 10 Sep 1995 13:31:44 +1000 (from bsw@netcom.com) Received: by netcom16.netcom.com (8.6.12/Netcom) id TAA21501; Sat, 9 Sep 1995 19:53:16 -0700 From: bsw@netcom.com (Bruce Sterling Woodcock) Message-Id: <199509100253.TAA21501@netcom16.netcom.com> Subject: Re: oops -- wrong message To: bass@linux.silkroad.com (Tim Bass) Date: Sat, 9 Sep 1995 19:53:15 -0700 (PDT) Cc: jnc@ginger.lcs.mit.edu, bilse@eu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509090210.AA04001@linux.silkroad.com> from "Tim Bass" at Sep 8, 95 10:10:04 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2082 Precedence: bulk > 4) This architecture basically moves the 'route processor' off > the core routers ( sorry router vendors , you are moving to > slow ) and into adjunct UNIX processors. CPU power is increasing > at about the same rate or faster than the growth of the Internet. > Memory and storage prices are also proportional, but much less > of course... BUT any decent modern UNIX platform with a RAM > compliment could store the routing tables and do the calculations. I find this particular part of the entire hypothetical the most difficult to swallow. The idea that the routers of the future will be "open" UNIX platforms with lots of RAM and DISK and so on. Sorry, I just don't see it. Dedicated routers were developed using the appliance philosophy, which is basically the belief that certain functions that are generally segmented on specific servers can be put into an "appliance" that does only that one thing, but does it very well. Although you do lose the "open" standard of a UNIX system, I don't think people will be out distributing plug-and-play source code for kernels to support various routing and transport protocols. The truth is that a dedicated device, properly designed, will always outperform the same device with the same hardware that is tailored for more general functionality. This is true of Cisco routers or NetApp NFS servers. Now, it may be true that the router folks aren't putting out boxes with fast enough CPU (or CPUs) or RAM for the demand, and that it is theoretically possible for a large UNIX box to be coded to do it instead. However, I don't think the router folks would allow that to happen... they'll upgrade their products to match the demand. If Cisco doesn't, Bay Networks will; etc. Bruce -- Bruce Sterling Woodcock --- Systems Administrator ][ sterling@netcom.com The views and opinions expressed in this message ][ sterling@netapp.com are not necessarily those of NETCOM nor of my ][ sterling@well.com current employer, Network Appliance Corporation. ][ sterling@egbt.org From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 14:56:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12842; Sun, 10 Sep 1995 14:56:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA23430; Sun, 10 Sep 1995 14:55:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA23412; Sun, 10 Sep 1995 14:49:48 +1000 Received: from netrail.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12765; Sun, 10 Sep 1995 14:49:45 +1000 (from nathan@netrail.net) Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id AAA04493; Sun, 10 Sep 1995 00:49:40 -0400 Date: Sun, 10 Sep 1995 00:49:40 -0400 (EDT) From: Nathan Stratton To: Tony Li Cc: Sanjay Kapur , Andrew Partan , dorian@cic.net, SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <199509100246.TAA17468@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Tony Li wrote: > Tried that. Didn't work. Next? Can't the InterNIC force people to renumber? Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 14:59:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13070; Sun, 10 Sep 1995 14:59:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA23454; Sun, 10 Sep 1995 14:59:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA23409; Sun, 10 Sep 1995 14:48:37 +1000 Received: from netrail.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12732; Sun, 10 Sep 1995 14:48:18 +1000 (from nathan@netrail.net) Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id AAA04470; Sun, 10 Sep 1995 00:48:11 -0400 Date: Sun, 10 Sep 1995 00:48:11 -0400 (EDT) From: Nathan Stratton To: Tony Li Cc: "Perry E. Metzger" , Noel Chiappa , big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers In-Reply-To: <199509100228.TAA17320@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Tony Li wrote: > Please feel free to purchase a 7500 and find out for yourself. Yes, but say we go out a get it, how long until we need the next cisco. We just can't keep dumping money into hardware such a short life. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 15:01:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13103; Sun, 10 Sep 1995 15:01:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA23476; Sun, 10 Sep 1995 15:01:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA23415; Sun, 10 Sep 1995 14:52:15 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12790; Sun, 10 Sep 1995 14:52:09 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id VAA09031; Sat, 9 Sep 1995 21:59:13 -0700 Date: Sat, 9 Sep 1995 21:59:12 -0700 (PDT) From: Michael Dillon To: Bruce Sterling Woodcock Cc: Tim Bass , jnc@ginger.lcs.mit.edu, bilse@eu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: <199509100253.TAA21501@netcom16.netcom.com> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Bruce Sterling Woodcock wrote: > but does it very well. Although you do lose the "open" standard of a UNIX > system, I don't think people will be out distributing plug-and-play source > code for kernels to support various routing and transport protocols. You would be surprised at just how close to this point we are currently with things like NetBSD. There are definitely people out there taking the open source for a full UNIX system and stripping out functionality they don't need, and modifying the parts they keep in order to build special-purpose operating systems. > The truth is that a dedicated device, properly designed, will always > outperform the same device with the same hardware that is tailored for more > general functionality. This is true of Cisco routers or NetApp NFS servers. No argument there. But there is nothing stopping people from starting with a base like NetBSD and tailoring it specifically for a route processor function. > Now, it may be true that the router folks aren't putting out boxes with > fast enough CPU (or CPUs) or RAM for the demand, and that it is theoretically > possible for a large UNIX box to be coded to do it instead. However, I don't > think the router folks would allow that to happen... they'll upgrade their > products to match the demand. If Cisco doesn't, Bay Networks will; etc. It's not up to Cisco or Bay. It's up to the customers. If NSP's feel that it is to their benefit to run route processors on custom-tailored UNIX boxes, then that's what will happen. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 15:04:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13148; Sun, 10 Sep 1995 15:04:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA23496; Sun, 10 Sep 1995 15:04:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA23406; Sun, 10 Sep 1995 14:40:37 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12505; Sun, 10 Sep 1995 14:40:22 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id VAA08939; Sat, 9 Sep 1995 21:47:23 -0700 Date: Sat, 9 Sep 1995 21:47:20 -0700 (PDT) From: Michael Dillon To: Tony Li Cc: Andrew Partan , Sean Doran , bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Subject: Re: Distributed systems In-Reply-To: <199509100241.TAA17437@greatdane.cisco.com> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Tony Li wrote: > Let's not quibble over the semantics of "tight" vs. "loose". That's > pointless. In the system proposed, the router still gets full routes > via BGP. It then still processes them and shoves them into the SSP. > > Where's the conceptual difference? What's the strategic win? I'll > certainly grant you a constant factor of memory savings, where the > constant is proportional to the number of peerings. Conceptually it is no different from running the route processor in the same box as the SSP. But there are some wins with moving route processing outside the box containing the SSP. One win is that the route processor can be scaled independently of the SSP box and thus independently of the SSP box vendor. For some people this would be a win since it would mean they are not as tied to a single source for equipment and technical advances. Another win would be the ability to accomodate SOME growth in the number of Internet routes. How much growth could be accomodated is presently an unknown because nobody knows how fast a given route processor can process as compared to another. For instance, will the latest Sparcstation running NetBSD handle twice as many routes as the latest Pentium 100 running NetBSD? 1.5 times as many? 0.8 times as many? What about SMP architectures. How many more routes can be handled on an AST Manhattan with 6 Pentium 90's running SCO UNIX with MPX as compared to a single Pentium 90 running SCO UNIX? I don't believe that anybody has data to be able to come up with realistic numbers for any of these scenarios. If there is some serious possibility of being able to ease up the pending crisis by decoupling route processors from SSP's then I think there might well be a possibility of getting free stuff from SUN, SCO, and others to set up a testbed and quantify what is currently just a best guess. Several smaller wins can often help reach the same goal as one big strategic win. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 23:17:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01423; Sun, 10 Sep 1995 23:17:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA23950; Sun, 10 Sep 1995 23:16:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA23943; Sun, 10 Sep 1995 23:13:33 +1000 Received: from netrail.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01204; Sun, 10 Sep 1995 23:13:28 +1000 (from nathan@netrail.net) Received: (from nathan@localhost) by netrail.net (8.6.12/8.6.12) id JAA12589; Sun, 10 Sep 1995 09:13:16 -0400 Date: Sun, 10 Sep 1995 09:13:15 -0400 (EDT) From: Nathan Stratton To: Tony Li Cc: root@kbs.netusa.net, asp@uunet.uu.net, dorian@cic.net, SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <199509100801.BAA00149@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Tony Li wrote: > > > Tried that. Didn't work. Next? > > Can't the InterNIC force people to renumber? > > Just in case you're not joking, no, the InterNIC can't "force" people > to do anything. Why not? When you get a block form the NIC they say it is a lease. So why can't they take blocks back. Nathan Stratton CEO, NetRail, Inc. Your Gateway to the World! --------------------------------------------------------------------------- Phone (703)524-4800 NetRail, Inc. Fax (703)534-5033 2007 N. 15 St. Suite B-5 Email sales@netrail.net Arlington, Va. 22201 WWW http://www.netrail.net/ Access: (703) 524-4802 guest --------------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 23:20:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01653; Sun, 10 Sep 1995 23:20:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA23977; Sun, 10 Sep 1995 23:20:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA23946; Sun, 10 Sep 1995 23:13:57 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01228; Sun, 10 Sep 1995 23:13:43 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08298 Sun, 10 Sep 1995 22:53:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29112; Sun, 10 Sep 95 08:51:14 -0400 Date: Sun, 10 Sep 95 08:51:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509101251.AA29112@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers... Cc: jnc@ginger.lcs.mit.edu Precedence: bulk Ah, the usual IETF "streetlamp" debate. I call them this because it reminds me of the old joke about the drunk who has lost their carkeys. (For those who don't know it, here it is: The police officer rolls up, finds the drunk on their hands and knees, under a streetlamp, looking around. The officer asks what gives, the drunk says "trying to find my carkeys". The officer helpfully asks "where did you drop them", and the drunk points out into the dark. The officer asks "why are you looking here if your keys are out there", and the drunk replies "because there's more light here".) Debating stabilization times, etc, etc; hey, that takes too much real knowledge of routing. But arguing about CPU speeds, hey, any geek can do that until the cows come home. Why argue about the real issues when you can argue about something you actually know something about. Pfagh. Noel From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 23:21:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01718; Sun, 10 Sep 1995 23:21:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA24007; Sun, 10 Sep 1995 23:21:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA23929; Sun, 10 Sep 1995 23:01:15 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00759; Sun, 10 Sep 1995 23:01:12 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29149; Sun, 10 Sep 95 09:00:22 -0400 Date: Sun, 10 Sep 95 09:00:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509101300.AA29149@ginger.lcs.mit.edu> To: bsw@netcom.com, tli@cisco.com Subject: Re: Size of routers... Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: bsw@netcom.com (Bruce Sterling Woodcock) while I've never seen a chart of this, I would expect the "mainstream" computing power, or perhaps as a ration of MIPS/dollar, has probably done at least as well, if not better. To put this to bed, could anyone who has data covering a reasonable range (i.e. more than a few months) post it? It would be nice to go back a ways, and start with things like the 8080, going forward through the 8086, etc. Also, make sure your "speed" data is in Wheatstones, or something, not just cycle times (where the cycle count per instruction can throw you off) or instruction speeds (since this will make RISC machines look faster than they actually are, compared to CISC's). Noel PS: For what it's worth, someone who actually knows something about this stuff says that there are good reasons to believe that we only get a few (like maybe two) more halvings of feature size before we run into some hard physics limits on semiconductor fabrication, at which point we'll be off that curve. Different semiconductor technologies (i.e. not silicon) might offer continued speed advances at that point, but probably not as cheaply. From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 23:36:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02275; Sun, 10 Sep 1995 23:36:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA24070; Sun, 10 Sep 1995 23:36:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA24017; Sun, 10 Sep 1995 23:21:49 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01727; Sun, 10 Sep 1995 23:21:46 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01872 Sun, 10 Sep 1995 18:03:57 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA00149; Sun, 10 Sep 1995 01:01:05 -0700 Date: Sun, 10 Sep 1995 01:01:05 -0700 From: Tony Li Message-Id: <199509100801.BAA00149@greatdane.cisco.com> To: nathan@netrail.net Cc: root@kbs.netusa.net, asp@uunet.uu.net, dorian@cic.net, SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU In-Reply-To: (message from Nathan Stratton on Sun, 10 Sep 1995 00:49:40 -0400 (EDT)) Subject: Re: Routing tables & what to do about them Precedence: bulk > Tried that. Didn't work. Next? Can't the InterNIC force people to renumber? Just in case you're not joking, no, the InterNIC can't "force" people to do anything. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 23:38:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02304; Sun, 10 Sep 1995 23:38:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA24096; Sun, 10 Sep 1995 23:38:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA24022; Sun, 10 Sep 1995 23:22:03 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01732; Sun, 10 Sep 1995 23:21:49 +1000 (from tli@cisco.com) Received: from relay2.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02024 Sun, 10 Sep 1995 18:09:59 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by relay2.UU.NET with SMTP id QQzgoe13082; Sun, 10 Sep 1995 04:07:28 -0400 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA00177; Sun, 10 Sep 1995 01:02:13 -0700 Date: Sun, 10 Sep 1995 01:02:13 -0700 From: Tony Li Message-Id: <199509100802.BAA00177@greatdane.cisco.com> To: nathan@netrail.net Cc: perry@piermont.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: (message from Nathan Stratton on Sun, 10 Sep 1995 00:48:11 -0400 (EDT)) Subject: Re: Size of routers Precedence: bulk > Please feel free to purchase a 7500 and find out for yourself. Yes, but say we go out a get it, how long until we need the next cisco. We just can't keep dumping money into hardware such a short life. That depends WHOLLY on the growth of bandwidth and the routing table. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 23:40:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02325; Sun, 10 Sep 1995 23:40:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA24131; Sun, 10 Sep 1995 23:40:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA23998; Sun, 10 Sep 1995 23:21:14 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01684; Sun, 10 Sep 1995 23:21:11 +1000 (from tli@cisco.com) Received: from shark.mel.dit.CSIRO.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02277 Sun, 10 Sep 1995 18:27:03 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by shark.mel.dit.csiro.au with SMTP id AA23319 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sun, 10 Sep 1995 18:24:26 +1000 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA00307; Sun, 10 Sep 1995 01:20:37 -0700 Date: Sun, 10 Sep 1995 01:20:37 -0700 From: Tony Li Message-Id: <199509100820.BAA00307@greatdane.cisco.com> To: root@kbs.netusa.net Cc: asp@uunet.uu.net, dorian@cic.net, SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU In-Reply-To: (message from Sanjay Kapur on Sat, 9 Sep 1995 22:59:48 -0400 (EDT)) Subject: Re: Routing tables & what to do about them Precedence: bulk What gives you the idea that there will be any more compliance with forced renumbering? Right now, when folks are asked to accept topologically based numbers, they say "why?". We have no document to show them that explains it clearly. The point of the "ownership" BCP was so that address allocation registries could hand it to customers so that they would begin to understand the problem. Anectodal evidence suggests that NSPs do not even try to convince their customers to use a number out of the NSP's block. Some do, some don't. I have anectodal evidence to the contrary. Consistency would really help. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 23:42:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02551; Sun, 10 Sep 1995 23:42:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA24153; Sun, 10 Sep 1995 23:42:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA24004; Sun, 10 Sep 1995 23:21:25 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01693; Sun, 10 Sep 1995 23:21:17 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02320 Sun, 10 Sep 1995 18:30:05 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA00346; Sun, 10 Sep 1995 01:26:22 -0700 Date: Sun, 10 Sep 1995 01:26:22 -0700 From: Tony Li Message-Id: <199509100826.BAA00346@greatdane.cisco.com> To: bsw@netcom.com Cc: bass@linux.silkroad.com, tli@cisco.com, michael@junction.net, smd@cesium.clock.org, asp@uunet.uu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <199509100803.BAA13174@netcom16.netcom.com> (bsw@netcom.com) Subject: Re: Size of routers... Precedence: bulk > CPU horsepower is growing at a rate similar to the net. Pentium P5s at > 60 to 133 MHz in a few months.... the P6 is on the horizon... it > seems every month is a major improvement in CPU performance. There's a "proposed" law for this... the name escapes me... but it's held fairly true for decades. I believe it's that processing power doubles every 2 years. Someone else could probably elaborate on this. It's called Moore's Law, and you've hit it squarely on the head. Note that it describes the peak of computing power, not the peak of the PC world. The 60 Mhz Pentium was never, ever the peak of computing power. ;-) The market for Internet backbone routers is probably fairly small in comparison. Today's understatement. ;-) Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 23:45:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02613; Sun, 10 Sep 1995 23:45:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA24175; Sun, 10 Sep 1995 23:44:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA23964; Sun, 10 Sep 1995 23:19:16 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01499; Sun, 10 Sep 1995 23:19:13 +1000 (from bsw@netcom.com) Received: from netcom16.netcom.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04972 Sun, 10 Sep 1995 20:53:05 +1000 (from bsw@netcom.com) Received: by netcom16.netcom.com (8.6.12/Netcom) id DAA03065; Sun, 10 Sep 1995 03:47:31 -0700 From: bsw@netcom.com (Bruce Sterling Woodcock) Message-Id: <199509101047.DAA03065@netcom16.netcom.com> Subject: Re: Size of routers... To: tli@cisco.com (Tony Li) Date: Sun, 10 Sep 1995 03:47:31 -0700 (PDT) Cc: bsw@netcom.com, bass@linux.silkroad.com, tli@cisco.com, michael@junction.net, smd@cesium.clock.org, asp@uunet.uu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <199509100826.BAA00346@greatdane.cisco.com> from "Tony Li" at Sep 10, 95 01:26:22 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1074 Precedence: bulk > There's a "proposed" law for this... the name escapes me... but it's held > fairly true for decades. I believe it's that processing power doubles every > 2 years. Someone else could probably elaborate on this. > > It's called Moore's Law, and you've hit it squarely on the head. Note > that it describes the peak of computing power, not the peak of the PC > world. The 60 Mhz Pentium was never, ever the peak of computing > power. ;-) True. However, while I've never seen a chart of this, I would expect the "mainstream" computing power, or perhaps as a ration of MIPS/dollar, has probably done at least as well, if not better. You can get a Pentium today for the same price you could get a 486 two years ago, and have more than double the processing power. Bruce -- Bruce Sterling Woodcock --- Systems Administrator ][ sterling@netcom.com The views and opinions expressed in this message ][ sterling@netapp.com are not necessarily those of NETCOM nor of my ][ sterling@well.com current employer, Network Appliance Corporation. ][ sterling@egbt.org From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 23:48:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02658; Sun, 10 Sep 1995 23:48:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA24209; Sun, 10 Sep 1995 23:47:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA24029; Sun, 10 Sep 1995 23:22:11 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01742; Sun, 10 Sep 1995 23:22:08 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02032 Sun, 10 Sep 1995 18:10:27 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA00227; Sun, 10 Sep 1995 01:07:34 -0700 Date: Sun, 10 Sep 1995 01:07:34 -0700 From: Tony Li Message-Id: <199509100807.BAA00227@greatdane.cisco.com> To: michael@junction.net Cc: asp@uunet.uu.net, smd@cesium.clock.org, bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: (message from Michael Dillon on Sat, 9 Sep 1995 21:47:20 -0700 (PDT)) Subject: Re: Distributed systems Precedence: bulk One win is that the route processor can be scaled independently of the SSP box and thus independently of the SSP box vendor. Please explain why this is a win. When you run out of SSP memory, your "distributed system" just stopped scaling. If there is some serious possibility of being able to ease up the pending crisis by decoupling route processors from SSP's then I think there might well be a possibility of getting free stuff from SUN, SCO, and others to set up a testbed and quantify what is currently just a best guess. Several smaller wins can often help reach the same goal as one big strategic win. "The pending crisis" continues to be exponential growth. Small constants don't have a serious effect on long term exponential growth. If you're so concerned about the very short term, you might notice that the fullest 64Mb 7000's are currently just over half full. So there's ten months worst case, and there's reason to believe that we can do better (assuming we can get a few RFCs out the door). And then there's the 7500. Tony From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 23:55:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02891; Sun, 10 Sep 1995 23:55:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA24234; Sun, 10 Sep 1995 23:53:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA24045; Sun, 10 Sep 1995 23:22:58 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01784; Sun, 10 Sep 1995 23:22:50 +1000 (from gherbert@crl.com) Received: from mail.crl.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00847 Sun, 10 Sep 1995 17:30:43 +1000 (from gherbert@crl.com) Received: from crl6.crl.com by mail.crl.com with SMTP id AA06967 (5.65c/IDA-1.5); Sun, 10 Sep 1995 00:01:01 -0700 Message-Id: <199509100701.AA06967@mail.crl.com> To: Sean Doran Cc: Sanjay Kapur , Andrew Partan , gherbert@crl.com, tli@cisco.com, big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Sat, 09 Sep 1995 19:41:55 EDT." <95Sep9.194157-0400_edt.20697+793@chops.icp.net> Date: Sun, 10 Sep 1995 00:01:00 -0700 From: George Herbert Precedence: bulk Regarding table size for IPv4 forwarding, you can get away with a 2^24 table and still handle /25+ addresses at fast speeds if you design cleverly. I will explain further privately to anyone willing to do a NDA, and publically at some point in the not too distant future. Regarding IPv6 and table vs tree routing, I would like to put forth a proposition. IPv6 is intended to do a lot of different things, one of which is have a mostly sparse space. Depending on how it is laid out, it could be very easy to route out of a short table or very hard to route out of a short table. The question is how many bits end up being significant for routing topology. I am not involved in the IPv6 development effort, so I don't know exactly what direction that's headed or why. But if a decision is made to limit routing topology significance to the leading 24 to 32 bits of the address, then it is possible to very easily do flat table routing for it, at least for external routing. If I recall, both the ISP based and geographical-based routes in IPv6 are /3 prefix for type code and then the rest being allocated based on provider / geography. If we (for example) use a 21-bit wide space for the equivalent of ASN assignment we get 2m ISP ASNs and 2m geographical ASNs... if that's not enough, we can go to larger tables (a gig or more of RAM is doable, if expensive). IPv6 does not *have* to break the concept of flat table lookups. I believe it is trivial to demonstrate that it will very effectively end our address space problems for the forseeable future. As we are now seeing routing and forwarding becoming growth curve bounds, then it is incumbent on us to address those issues in the IPv6 deployment when it happens, presuming it does. Sensible use of its space to flatten out forwarding and routing is something which can be done, and barring some issue I am unaware of right now should be done. -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Sun Sep 10 23:59:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02968; Sun, 10 Sep 1995 23:59:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA24269; Sun, 10 Sep 1995 23:58:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA24050; Sun, 10 Sep 1995 23:23:57 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01883; Sun, 10 Sep 1995 23:23:49 +1000 (from marshalj@spots.ab.ca) Received: from ftp.spots.ab.ca by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA00280 Sun, 10 Sep 1995 17:08:01 +1000 (from marshalj@spots.ab.ca) Received: from ftp.spots.ab.ca (ftp.spots.ab.ca [204.191.210.11]) by ftp.spots.ab.ca (8.6.11/8.6.12) with SMTP id XAA27834; Sat, 9 Sep 1995 23:45:27 -0700 Date: Sat, 9 Sep 1995 23:45:27 -0700 (MST) From: Jason Marshall To: Nathan Stratton Cc: big-internet@munnari.OZ.AU, spots@spots.ab.ca Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > > Tried that. Didn't work. Next? > > Can't the InterNIC force people to renumber? Obviously, renumbering will be required. One way to get people to renumber is, if not politically correct, at least sure to be effective. Set a date for people downstream from you to have renumbered, and refuse to advertise their old routes after that date. If the date is reasonable your customers, and their customers, will renumber. If they are unable, for some business/security reason, to renumber, then they should be willing to pay through the teeth for the privelege of having their non-standard route advertised. At large interconnects (if the majority of the Big Providers agree strongly that renumbering must, at all cost, be done) refuse packets from other Big Providers which have not had their downstream customers a) renumber completely, b) stop advertising routes for those who have not forced this, or c) pay a large $sum to some benign organization whose task it is to design cool new router technology (or something). c) is really quite vague, and will likely not work, as everyone will want a piece of the large $sum. But if the people who refuse to play the renumbering game have to shell out Big Bucks, it doesn't really matter who the money goes to, just as long as the privelege of advertising non-standard routes is not free. I am sure that there are enough bugs in this for Noel and Tony (and anyone else who knows what they're talking about) to shoot it apart, but what the heck! That's what we're here for! PS. I suspect that this 'reasonable date' would have to be set not too far into the future for it to work... What are we waiting for? I, for one, would rather renumber a functional Internet than try to revive a nonfunctional one... =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jason Marshall, marshalj@spots.ab.ca. Spots InterConnect, Inc. Calgary, AB | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 00:03:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03594; Mon, 11 Sep 1995 00:03:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA24298; Mon, 11 Sep 1995 00:03:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA23983; Sun, 10 Sep 1995 23:20:36 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01649; Sun, 10 Sep 1995 23:20:33 +1000 (from SEAN@SDG.DRA.COM) Received: from sdg.dra.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03618 Sun, 10 Sep 1995 19:40:11 +1000 (from SEAN@SDG.DRA.COM) Date: Sun, 10 Sep 1995 4:37:39 -0500 (CDT) From: Sean Donelan To: big-internet@munnari.OZ.AU Message-Id: <950910043739.44dd@SDG.DRA.COM> Subject: Re: Routing tables & what to do about them Precedence: bulk >Voluntary renumbering was first requested in RFC 1338 (6/26/1992). >Compliance has been "low", with many new sites requesting "portable" >addresses. And the routing table again appears to be experiencing >exponential growth. > >Tried that. Didn't work. Next? RFC 1338 also suggested that network blocks be allocated to allow for significant growth. That doesn't seem to be happening either. As dorian pointed out, even if sites wanted to renumber, does their provider or provider's provider have big enough network blocks to handle them? We're not that big, yet both our provider and our other provider's provider told us to get future allocations directly from the InterNIC. The slow-start policy gives us a more bunches of little blocks. So the routing tables grow a little more. Would we renumber to decrease the number of routing announcements? Depends on how easy it is to get a block large enough to handle significant growth so we didn't have to do it all over again in six weeks (or whatever time period it takes to renumber). The current policies, and more importantly practices, make me wary. Just the fun interaction of different policies. Address space density or route aggregation. Just making it "hard" to get network numbers only forced the problem in a new direction. If the person had a difficult time getting a network number in the first place, she won't be very willing to give that number up and play provider/InterNIC roulette again. A bird in the hand is worth two in the bush. Human behavior usually has a reason. If you don't understand why compliance with voluntary renumbering has been low, and why many sites have been requesting network numbers from the InterNIC instead of their provider, then any new proposal may meet the same (or worse) fate. On the other hand, maybe the OSI folks were right all along. Have a huge address space, and waste 90% of it on routing. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 00:06:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03643; Mon, 11 Sep 1995 00:06:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA24323; Mon, 11 Sep 1995 00:06:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA24032; Sun, 10 Sep 1995 23:22:17 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01748; Sun, 10 Sep 1995 23:22:13 +1000 (from bsw@netcom.com) Received: from netcom16.netcom.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01487 Sun, 10 Sep 1995 17:53:55 +1000 (from bsw@netcom.com) Received: by netcom16.netcom.com (8.6.12/Netcom) id AAA10537; Sun, 10 Sep 1995 00:48:15 -0700 From: bsw@netcom.com (Bruce Sterling Woodcock) Message-Id: <199509100748.AAA10537@netcom16.netcom.com> Subject: Re: oops -- wrong message To: michael@junction.net (Michael Dillon) Date: Sun, 10 Sep 1995 00:48:15 -0700 (PDT) Cc: bsw@netcom.com, bass@linux.silkroad.com, jnc@ginger.lcs.mit.edu, bilse@eu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: from "Michael Dillon" at Sep 9, 95 09:59:12 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2361 Precedence: bulk > On Sat, 9 Sep 1995, Bruce Sterling Woodcock wrote: > > > but does it very well. Although you do lose the "open" standard of a UNIX > > system, I don't think people will be out distributing plug-and-play source > > code for kernels to support various routing and transport protocols. > > You would be surprised at just how close to this point we are currently > with things like NetBSD. There are definitely people out there taking the > open source for a full UNIX system and stripping out functionality they > don't need, and modifying the parts they keep in order to build > special-purpose operating systems. I would not be surprised at all. However, then you parallel Auspex, with hacks upon hacks on SunOS to provide a dedicated NFS server, instead of writing an OS from scratch like NetApp. I happen to think the NetApp strategy is better for appliance-like services. I'm not saying you can't do it. I'm just saying I doubt the router folks will sit by as people do it with their workstations and say, "Gee, there's just nothing we can do." > > Now, it may be true that the router folks aren't putting out boxes with > > fast enough CPU (or CPUs) or RAM for the demand, and that it is theoretically > > possible for a large UNIX box to be coded to do it instead. However, I don't > > think the router folks would allow that to happen... they'll upgrade their > > products to match the demand. If Cisco doesn't, Bay Networks will; etc. > > It's not up to Cisco or Bay. It's up to the customers. If NSP's feel that > it is to their benefit to run route processors on custom-tailored UNIX > boxes, then that's what will happen. Actually, I think we've been done that road before anyway. I recall some big ANS core routers that were actually RS/6000s with a bunch of disk space for virtual memory. Again, I don't doubt that this is feasible. What I doubt is that it's somehow a better solution than dedicated routers, or that the dedicated router folks will be unable to compete in terms of hardware to remain attractive and viable. Bruce -- Bruce Sterling Woodcock --- Systems Administrator ][ sterling@netcom.com The views and opinions expressed in this message ][ sterling@netapp.com are not necessarily those of NETCOM nor of my ][ sterling@well.com current employer, Network Appliance Corporation. ][ sterling@egbt.org From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 00:10:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03677; Mon, 11 Sep 1995 00:10:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA24357; Mon, 11 Sep 1995 00:09:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA24014; Sun, 10 Sep 1995 23:21:44 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01716; Sun, 10 Sep 1995 23:21:40 +1000 (from bsw@netcom.com) Received: from netcom16.netcom.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02190 Sun, 10 Sep 1995 18:22:36 +1000 (from bsw@netcom.com) Received: by netcom16.netcom.com (8.6.12/Netcom) id BAA13174; Sun, 10 Sep 1995 01:03:31 -0700 From: bsw@netcom.com (Bruce Sterling Woodcock) Message-Id: <199509100803.BAA13174@netcom16.netcom.com> Subject: Re: Size of routers... To: bass@linux.silkroad.com (Tim Bass) Date: Sun, 10 Sep 1995 01:03:30 -0700 (PDT) Cc: tli@cisco.com, michael@junction.net, smd@cesium.clock.org, asp@uunet.uu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <199509100300.AA13066@linux.silkroad.com> from "Tim Bass" at Sep 9, 95 11:00:50 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2729 Precedence: bulk > > The theory being that Unix systems are not subject to the laws of > > growth of CPU power or RAM? > > > > Sorry, the net still crashes and burns if you do this. Your Unix box > > still doesn't grow fast enough. > > CPU horsepower is growing at a rate similar to the net. Pentium P5s at > 60 to 133 MHz in a few months.... the P6 is on the horizon... it > seems every month is a major improvement in CPU performance. There's a "proposed" law for this... the name escapes me... but it's held fairly true for decades. I believe it's that processing power doubles every 2 years. Someone else could probably elaborate on this. > It is quite easy to plug and play motherboard swap and RAM upgrades > in these boxes much easier and cheaper than a new product development cycle > for a commercial router. This is very true considering the size of > the market that requires this routing horsepower. (we are talking > about IPV4) Perhaps you haven't used router hardware in a while, but there are routers that support "plug and play" expansion, adding more memory to slots, or faster route processors, etc. Those that aren't are generally not conceived as needing to be scalable; i.e. they handle only an ethernet on one end and a T1 on the other, for instance. However, there is nothing that prevents big, "core" routers from being designed that allow the same sort of expansion. There's nothing mystical about UNIX or off-the-shelf hardware that allows this. In fact, off-the-shelf hardware tends to have problems of it's own. Every try find an off-the-shelf PC motherboard capable of supporting more than 256 or 512 MB of RAM? Good luck. Maybe once we have 64 Meg SIMMs, but usually you're stuck with 8 SIMM slots. Getting high-performance, off-the-shelf components is often impossible, because the market for them is simply too small. That's why many vendors make their own hardware, at least in part. > commercial routers use somewhat antiquated CPUs (until recently > only the 4500 had a RISC processor in the cisco product line, right?) Remember that the average commercial routing isn't expected to have to handle full Internet routing! All most of them do is shuffle packets back and forth across multiple ethernet interfaces on local LANs. Gigantic routing tables aren't an issue. So you don't *need* that much CPU. The market for Internet backbone routers is probably fairly small in comparison. Bruce -- Bruce Sterling Woodcock --- Systems Administrator ][ sterling@netcom.com The views and opinions expressed in this message ][ sterling@netapp.com are not necessarily those of NETCOM nor of my ][ sterling@well.com current employer, Network Appliance Corporation. ][ sterling@egbt.org From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 00:20:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04028; Mon, 11 Sep 1995 00:20:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA24401; Mon, 11 Sep 1995 00:17:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA24223; Sun, 10 Sep 1995 23:51:10 +1000 Received: from sabre-wulf.nvg.unit.no by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02701; Sun, 10 Sep 1995 23:50:58 +1000 (from agulbra@nvg.unit.no) Received: from sabre-wulf.nvg.unit.no (agulbra@sabre-wulf.nvg.unit.no [129.241.161.9]) by sabre-wulf.nvg.unit.no (8.6.12/8.6.9) with ESMTP id PAA09079; Sun, 10 Sep 1995 15:50:51 +0200 Received: by sabre-wulf.nvg.unit.no (smallmail v1.18); Sun, 10 Sep 1995 15:50:50 +0200 Date: Sun, 10 Sep 1995 15:50:50 +0200 Message-Id: <29559.9076.810741050@sabre-wulf.nvg.unit.no> From: Arnt Gulbrandsen Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: root@kbs.netusa.net Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: References: <199509100246.TAA17468@greatdane.cisco.com> Organization: Nettverksgruppa Precedence: bulk In article you write: >What gives you the idea that there will be any more compliance with forced >renumbering? Either there is or there isn't. If there is, the problem is solved. If there isn't, the problem is temporarily solved (a number of sites choose to leave the net, thus shrinking the routing tables). --Arnt From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 00:28:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04282; Mon, 11 Sep 1995 00:28:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA24678; Mon, 11 Sep 1995 00:25:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA24380; Mon, 11 Sep 1995 00:12:03 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03688; Mon, 11 Sep 1995 00:11:56 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id KAA20487; Sun, 10 Sep 1995 10:11:36 -0400 Date: Sun, 10 Sep 1995 10:11:36 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: Sanjay Kapur Cc: Vadim Antonov , big-internet@munnari.OZ.AU Subject: Re: oops -- wrong message In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Sanjay Kapur wrote: > The demonstratable flaw is not in logic but in the demonstratably bad > and unreliable service that NSPs provide. > > I have a client who has two T1 lines running in parallel to a Sprint > POP for load sharing (not multihoming). Sprint could not seem to get one > of the lines to work (about two out of every three packets are dropped on > the second line). This problem existed for more than a month > despite innumerable calls to Sprint and the telco and elevation of the > problem. First of all, circuit installs can be a major problem at times. Often times, when you are working with bringing up a ckt, you have to work with the LEC, interLATA carrier and the site staff to work out any problems that arises in installs. This doesn't happen all the time, but when it happens, it takes alot of work and time to get things working. The coordination between all the parties involved is not easy. Now, having offered that excuse, once things are fixed, that line should work and not drop packets. If sites are looking to dual home because of NSP unreliability, than it's partially our fault that there are so many sites looking to dual home because of how well we are doing things. > In addition to this problem they have had many other outages. They used > to have PSI and it was not much better but were told that SPRINT would > be better. It is not. But what sort of outages are they? Service and Maintenance outages are inevitable no matter where you go to. Otherwise, I'd just say that you need to pick and choose your NSP carefully, and examine what sort of outages they have and how often. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 00:38:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04625; Mon, 11 Sep 1995 00:38:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA24722; Mon, 11 Sep 1995 00:36:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA24406; Mon, 11 Sep 1995 00:17:37 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03994; Mon, 11 Sep 1995 00:17:31 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from shrew.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sun, 10 Sep 1995 15:17:20 +0100 To: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Sat, 09 Sep 95 23:45:27 PDT." Date: Sun, 10 Sep 95 15:17:19 +0100 Message-Id: <946.810742639@cs.ucl.ac.uk> From: Jon Crowcroft Precedence: bulk a small company here managed to pursuade everyone to renumber last year, even though they will have to do it again in 5 years.... they are called BT number of end system users affected: approx 35 Million (yes, i know a phone isn't an IP host:-) it might be interesting to ask Cable and Wireless and other UK providers how much this hurt or gained them (oh, the reasons for renumbering include: providers asking for blocks of numbers, users askign for globally portable, permanent numbers, subscribers asking for blocks for subaddressing, etc etc etc: sound familiar?) i think we should build all systems on the assumption that renumbering for the convenenience of providers, and the survival of router memory, is a matter of course raterh than exception - note that our users do at least have DNS names to work by, so most joe q public shouldn't know any different, unlike the UK phone users.... meanwhile, what about the old chestnut: it isn't number of routes, its the size of the active traffic matrix in the backbone that matters: how far could you get with a 64kbyte memory cache and 10 Gig worth of disk and plain old virtual memory? i seem to remember werner-braun's last public stats seemed to imply quite a good ratio and disk $ per gig is improving faster than memory or CPU right now... jon From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 01:36:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06421; Mon, 11 Sep 1995 01:36:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA24842; Mon, 11 Sep 1995 01:36:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA24838; Mon, 11 Sep 1995 01:28:47 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06123; Mon, 11 Sep 1995 01:28:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29461; Sun, 10 Sep 95 11:28:41 -0400 Date: Sun, 10 Sep 95 11:28:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509101528.AA29461@ginger.lcs.mit.edu> To: bsw@netcom.com, michael@junction.net Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: bsw@netcom.com (Bruce Sterling Woodcock) > If NSP's feel that it is to their benefit to run route processors on > custom-tailored UNIX boxes, then that's what will happen. Actually, I think we've been done that road before anyway. I recall some big ANS core routers that were actually RS/6000s with a bunch of disk space for virtual memory. Actually, there's an even closer match in the Route Server boxes which are already deployed at major exchange points (MAE-[EW], Sprint-NAP, etc). There's an article about them in the August "Connexions". (Try poking around starting with http://www.merit.edu/routing.arbiter/RA/router.server.html for more info.) They run on a SPARC, and handle only routing; user data traffic does not go through them. So, they thus split the routing and forwarding functions exactly as people have been suggesting. Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 02:18:22 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07540; Mon, 11 Sep 1995 02:18:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA24922; Mon, 11 Sep 1995 02:16:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24902; Mon, 11 Sep 1995 02:07:06 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07206; Mon, 11 Sep 1995 02:07:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29661; Sun, 10 Sep 95 12:07:01 -0400 Date: Sun, 10 Sep 95 12:07:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509101607.AA29661@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, root@kbs.netusa.net Subject: Re: Size of routers... Cc: big-internet@munnari.OZ.AU Precedence: bulk From: Sanjay Kapur Ignoring the monetary and social effects of their recommendation is another hallmark of "experts". Better to be an "expert" who knows something about half the problem than an "expert" who knows nothing at all about anything. Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 02:21:41 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07589; Mon, 11 Sep 1995 02:21:41 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA24947; Mon, 11 Sep 1995 02:19:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24899; Mon, 11 Sep 1995 02:05:46 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07162; Mon, 11 Sep 1995 02:05:41 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id MAA03358; Sun, 10 Sep 1995 12:05:21 -0400 Date: Sun, 10 Sep 1995 12:05:18 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Size of routers... In-Reply-To: <9509101251.AA29112@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Noel Chiappa wrote: > Debating stabilization times, etc, etc; hey, that takes too much real > knowledge of routing. But arguing about CPU speeds, hey, any geek can do that > until the cows come home. Why argue about the real issues when you can argue > about something you actually know something about. Pfagh. > > Noel > Ignoring the monetary and social effects of their recommendation is another hallmark of "experts". Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 02:23:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07711; Mon, 11 Sep 1995 02:23:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA24970; Mon, 11 Sep 1995 02:21:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24916; Mon, 11 Sep 1995 02:13:09 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07380; Mon, 11 Sep 1995 02:13:00 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id LAA03306; Sun, 10 Sep 1995 11:59:55 -0400 Date: Sun, 10 Sep 1995 11:59:53 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Tony Li Cc: asp@uunet.uu.net, dorian@cic.net, SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <199509100820.BAA00307@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Tony Li wrote: > > What gives you the idea that there will be any more compliance with forced > renumbering? > > Right now, when folks are asked to accept topologically based numbers, > they say "why?". We have no document to show them that explains it > clearly. The point of the "ownership" BCP was so that address > allocation registries could hand it to customers so that they would > begin to understand the problem. A two page RFC describing the problem and the recommended (not required) solution would be ideal. Anything longer and everyone's eyes will glaze over and it will just be ignored. Noel, do you want to volunteer to write it? > > Anectodal evidence suggests that NSPs do not even try to convince > their customers to use a number out of the NSP's block. > > Some do, some don't. I have anectodal evidence to the contrary. > Consistency would really help. Yes. > > Tony > Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 02:25:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07737; Mon, 11 Sep 1995 02:25:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA24992; Mon, 11 Sep 1995 02:24:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24895; Mon, 11 Sep 1995 02:02:11 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07100; Mon, 11 Sep 1995 02:02:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29608; Sun, 10 Sep 95 12:01:47 -0400 Date: Sun, 10 Sep 95 12:01:47 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509101601.AA29608@ginger.lcs.mit.edu> To: SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them Cc: jnc@ginger.lcs.mit.edu Precedence: bulk From: Sean Donelan The slow-start policy gives us a more bunches of little blocks. ... The current policies, and more importantly practices, make me wary. When the original change to the allocation policy came down some years ago - to decrease the allocation rate of B's - I went pretty ballistic. It was obviously jumping from the frying pan into the fire, and was clearly going to make the routing situation worse. Unfortunately, to this day, the people allocating addresses often don't seem to have a good grasp of the effects of what they are doing on the routing. On the other hand, maybe the OSI folks were right all along. Have a huge address space, and waste 90% of it on routing. I got rather a good laugh out of that suggestion. OSI addresses were organized to fit the convenience of the allocation authorities (i.e. not the routing) even more so than IP addresses. You did make a good point, though: one of the reasons we are seeing problems now is that we are trying to squeeze a large net into a fixed-size address. Getting the maximal bang out of 32 bits of space means *one more* reason to renumber. Any namespace, used for routing, is going to be less efficiently used than a namespace simply used for naming. This was the a major point behind the idea of EID's and locators, some years back (which the older denizens of this list will remember quite well). They were shot down (in part by a crew which included, for ironic relief, some of the people who are now bitching and moaning about renumbering). Needless to say, I derive a certain amount of grim amusement from watching all this... Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 02:29:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07839; Mon, 11 Sep 1995 02:29:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA25027; Mon, 11 Sep 1995 02:28:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24893; Mon, 11 Sep 1995 02:02:10 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07098; Mon, 11 Sep 1995 02:02:06 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id JAA12235; Sun, 10 Sep 1995 09:09:03 -0700 Date: Sun, 10 Sep 1995 09:09:02 -0700 (PDT) From: Michael Dillon To: Tony Li Cc: asp@uunet.uu.net, smd@cesium.clock.org, bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Subject: Re: Distributed systems In-Reply-To: <199509100807.BAA00227@greatdane.cisco.com> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Tony Li wrote: > > One win is that the route processor can be scaled independently of the > SSP box and thus independently of the SSP box vendor. > > Please explain why this is a win. When you run out of SSP memory, > your "distributed system" just stopped scaling. The route processor is supposed to stop this from happening by feeding the SSP a subset of the full routing table. In this scenario the full routing tables are only found in the route processor. It's also a win for the customer because they are no longer tied to a "single source" for route processors. It seems to me this would be a win for Cisco as well. I'm sure that the market for high-speed SSP's to do packet forwarding is large and growing at about the same rate as the growth of the Internet. However the market for route processors that can handle the full set of Internet routes is not nearly as large nor is it growing as fast as the Internet. Cisco could focus on building SSP boxes and let other people build route processors (i.e. mainstream computer manufacturers). It seems to me that keeping up with the Internet routing problem must cost Cisco a considerable amount in resources that may never be realized in profits from sales of equipments due to the small market size and limited growth of that market. > Several smaller wins can often help reach the same goal as one big > strategic win. > > "The pending crisis" continues to be exponential growth. This may not be true. You are attempting to predict the future here and it is not as simple as looking at the past and saying "more of the same". In fact, strategies such as CIDR and renumbering are already decoupling routing table growth rates from the overall Internet growth rate. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 02:37:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08198; Mon, 11 Sep 1995 02:37:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA25062; Mon, 11 Sep 1995 02:36:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24924; Mon, 11 Sep 1995 02:17:09 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07510; Mon, 11 Sep 1995 02:17:05 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA04377 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Sun, 10 Sep 1995 12:16:56 -0400 From: Tim Bass Message-Id: <199509101616.AA04377@linux.silkroad.com> Subject: Topological vs. Administrative Aggregation To: jnc@ginger.lcs.mit.edu Date: Sun, 10 Sep 1995 12:16:56 -0400 (EDT) Cc: big-internet@munnari.OZ.AU, com-priv@list.psi.com Priority: riv@lists.psi.com In-Reply-To: <9509091915.AA27351@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 9, 95 03:15:55 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2073 Precedence: bulk Noel, Please comment on this simple brief.... Thanks. Topological vs. Administrative Domain Aggregation ------------------------------------------------------------------- Topological based aggregation, in it's current manifestation in the net is a mixture of geographic and provider based aggregation. CIDR is the vehicle that provides this aggregation. BGP4 is the protocol. In provider based aggregation, providers manage address space allocation and management. Changing service providers normally requires network renumbering, DNS syncronization changes, etc. and the costs/responsibilities are shifted to the network users. In Adminstrative Domain Aggregation ( not yet implemented in the net ) the end user registers network addresses (classless or classful) with a Registration Authority ( TBD ) that aggregates networks within Administrative Domains. Interdomain routing is performed differently than today (still under development) but intradomain (internal) routing remains the same or similar. Administrative Domain Aggregation (could be) based on an automated, secure, independent paradigm ( currently unspecified ) that allows users to move their networks easily from provider to provider anywhere in the world, mapping corporate and individually assigned network number to administrative domains. So, my question is, why advocate topologicical based aggregation over administrative domain aggregation? Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 02:41:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08315; Mon, 11 Sep 1995 02:41:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA25101; Mon, 11 Sep 1995 02:40:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25056; Mon, 11 Sep 1995 02:33:43 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07913; Mon, 11 Sep 1995 02:33:33 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id MAA03475; Sun, 10 Sep 1995 12:33:12 -0400 Date: Sun, 10 Sep 1995 12:33:08 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Dorian Rysling Kim Cc: big-internet@munnari.OZ.AU Subject: NSP reliability. In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Dorian Rysling Kim wrote: > First of all, circuit installs can be a major problem at times. Often > times, when you are working with bringing up a ckt, you have to work with > the LEC, interLATA carrier and the site staff to work out any problems > that arises in installs. This doesn't happen all the time, but when it > happens, it takes alot of work and time to get things working. The > coordination between all the parties involved is not easy. Now, having > offered that excuse, once things are fixed, that line should work and not > drop packets. > The circuits had been running for several months although there were one to two hour "slowdowns" at times which the client did not attribute to this problem. Eventually the intermittant problem became non-intermittant. > If sites are looking to dual home because of NSP unreliability, than it's > partially our fault that there are so many sites looking to dual home > because of how well we are doing things. > > > In addition to this problem they have had many other outages. They used > > to have PSI and it was not much better but were told that SPRINT would > > be better. It is not. > > But what sort of outages are they? Service and Maintenance outages are > inevitable no matter where you go to. Otherwise, I'd just say that you > need to pick and choose your NSP carefully, and examine what sort of > outages they have and how often. > I can understand a few short outages. But there were several outages (about once a month) for the last several months that lasted a day or more. Sprint would not even know about the problem till the client called and reported it and even then Sprint takes its own sweet time fixing it. The networking staff at the client has been quite embarrased by all this and some persons at the client want the persons who picked Sprint to be fired. What has saved their jobs is that they had done the research and found that Sprint was one of the better providers. I had supported the decision to go with Sprint. It may just be bad luck but I hope you understand why I feel the way I do about some of the issues discussed here. > -dorian > ______________________________________________________________________________ > Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive > Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 > CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian > From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 02:42:54 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08348; Mon, 11 Sep 1995 02:42:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA25133; Mon, 11 Sep 1995 02:42:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA24949; Mon, 11 Sep 1995 02:20:43 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07568; Mon, 11 Sep 1995 02:20:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29699; Sun, 10 Sep 95 12:19:49 -0400 Date: Sun, 10 Sep 95 12:19:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509101619.AA29699@ginger.lcs.mit.edu> To: michael@junction.net, tli@cisco.com Subject: Re: Distributed systems Cc: big-internet@munnari.OZ.AU, comp-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: Michael Dillon >> the route processor can be scaled independently of the SSP box and thus >> independently of the SSP box vendor. > When you run out of SSP memory, your "distributed system" just stopped > scaling. The route processor is supposed to stop this from happening by feeding the SSP a subset of the full routing table. In this scenario the full routing tables are only found in the route processor. Let me explain this in a little more details; Tony's reply seems to have skipped a few steps you didn't consider. Perhaps some more precise terminology will help avoid future misunderstanding. Yes, the table in the SSP (let's call it the "forwarding table") is not going to contain all the inforamation (such as AS paths, etc, etc) that the routing subsystem(s) are using (let's call all that stuff the "routing database"). However, the box doing the switching still has to have a table which tells it which direction everything is. (Or are you going to have only a cache in the SSP, and load "misses" from some other machine?) Since this table will generally have about the same number of different destinations in it that the full routing database does, it will scale at the same rate. It's this table that Tony is saying may overflow. Cisco could focus on building SSP boxes and let other people build route processors (i.e. mainstream computer manufacturers). It seems to me that keeping up with the Internet routing problem must cost Cisco a considerable amount in resources Ah. So, moving the routing to another box is going to relieve Cisco from the need to have a general purpose CPU in their routers? Also, I assume that the mainstream computer manufacturers will write all the specialised routing software to go on their boxes? Yes, cutting out those two should really cut Cisco's engineering costs... > "The pending crisis" continues to be exponential growth. This may not be true. You are attempting to predict the future here and it is not as simple as looking at the past and saying "more of the same". I see. The people who are predicting that hardware will continue to get faster at a good clip aren't doing this, are they? I'd put a lot more money on the Internet continuing to grow than I would on continued speed increases in hardware. In fact, strategies such as CIDR and renumbering are already decoupling routing table growth rates from the overall Internet growth rate. Yes, and we need to keep applying them. Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 02:56:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08843; Mon, 11 Sep 1995 02:56:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA25197; Mon, 11 Sep 1995 02:56:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25170; Mon, 11 Sep 1995 02:51:10 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08546; Mon, 11 Sep 1995 02:51:00 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id MAA03543; Sun, 10 Sep 1995 12:50:39 -0400 Date: Sun, 10 Sep 1995 12:50:36 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Jon Crowcroft Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <946.810742639@cs.ucl.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Jon Crowcroft wrote: > > a small company here managed to pursuade everyone to renumber last > year, even though they will have to do it again in 5 years.... > > they are called BT > BT is also a government regulated monopoly. Case closed. > number of end system users affected: approx 35 Million > (yes, i know a phone isn't an IP host:-) > Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 02:59:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08884; Mon, 11 Sep 1995 02:59:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA25222; Mon, 11 Sep 1995 02:58:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25117; Mon, 11 Sep 1995 02:41:22 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08322; Mon, 11 Sep 1995 02:41:16 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id MAA11237; Sun, 10 Sep 1995 12:41:09 -0400 Message-Id: <199509101641.MAA11237@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: amolitor@anubis.network.com (Andrew Molitor) Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Your message of "Sat, 09 Sep 1995 14:18:07 CDT." <9509091918.AA22567@anubis.network.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 10 Sep 1995 12:41:05 -0400 From: "Perry E. Metzger" Precedence: bulk Andrew Molitor writes: > It is astonishing how few people seem to grasp the actual problem. > The fact that a cisco 7000 'only' has a 68040@25Mhz and 64M of memory > doesn't seem to keep them from working out ok. The problems in the current > core are not, as I understand it, in any way related to the amount > of memory or the CPU power. The problems are in getting the data you > need to do switching to the switching hardware. Pardon, but with Tony Li of Cisco and others bitching that the machines can't keep up with the BGP4 load, I'd say that the problem is most certainly at least partially weak CPUs. Now, there might be solutions that turn this into a non-problem, but in the current net it is a problem. Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 03:00:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08908; Mon, 11 Sep 1995 03:00:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25249; Mon, 11 Sep 1995 03:00:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25072; Mon, 11 Sep 1995 02:38:22 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08215; Mon, 11 Sep 1995 02:38:16 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id MAA11226; Sun, 10 Sep 1995 12:38:05 -0400 Message-Id: <199509101638.MAA11226@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: Barney Wolff Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Your message of "Sat, 09 Sep 1995 16:38:00 EDT." <9509091638.AA17338@databus.databus.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 10 Sep 1995 12:38:00 -0400 From: "Perry E. Metzger" Precedence: bulk Barney Wolff writes: > > Date: Sat, 09 Sep 1995 15:55:13 -0400 > > From: "Perry E. Metzger" > > > > Noel Chiappa writes: > > > I wasn't aware the SMP Unix had the capability to run a single process on > > > multiple CPU's simultaneously, > > > > Well, most SMP unixes can indeed run multiple threads in one process on > > multiple CPUs simultaneously. > > Folks, Noel's point, which some seem unwilling or unable to grasp, is > that neither BGP4 nor OSPF have been parallelized. Until that's done, > you can run them on a million-processor machine with no gain in speed. These algorithms are all highly parellelizable. I don't think that its even much of a challenge. > The voice of experience says that it will not be trivial, nor > outstandingly effective, to parallelize route computation. Huh? Most of these things come down to graph processing algorithms, almost all of which parallelize very nicely. Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 03:02:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09009; Mon, 11 Sep 1995 03:02:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25271; Mon, 11 Sep 1995 03:01:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25166; Mon, 11 Sep 1995 02:45:31 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08461; Mon, 11 Sep 1995 02:45:27 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id MAA03632; Sun, 10 Sep 1995 12:47:38 -0400 Date: Sun, 10 Sep 1995 12:47:38 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Routing tables & what to do about them To: Tony Li Cc: root@kbs.netusa.net, asp@uunet.uu.net, dorian@cic.net, SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU In-Reply-To: <199509100820.BAA00307@greatdane.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Tony Li wrote: > > What gives you the idea that there will be any more compliance with forced > renumbering? > > Right now, when folks are asked to accept topologically based numbers, > they say "why?". We have no document to show them that explains it > clearly. The point of the "ownership" BCP was so that address > allocation registries could hand it to customers so that they would > begin to understand the problem. > > Anectodal evidence suggests that NSPs do not even try to convince > their customers to use a number out of the NSP's block. we do, and so do most I guess. If a customer comes with an address, the first point of discussion is to find out if the customer can renumber. Most can. I wnat my bb tables small too, that's the first motivation, not sanity on behalf of all the others (but that's a close second). Mike > > Some do, some don't. I have anectodal evidence to the contrary. > Consistency would really help. > > Tony > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 03:05:54 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB09050; Mon, 11 Sep 1995 03:05:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25299; Mon, 11 Sep 1995 03:05:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25165; Mon, 11 Sep 1995 02:45:31 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08459; Mon, 11 Sep 1995 02:45:25 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id MAA03526; Sun, 10 Sep 1995 12:44:58 -0400 Date: Sun, 10 Sep 1995 12:44:57 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Jason Marshall Cc: Nathan Stratton , big-internet@munnari.OZ.AU, spots@spots.ab.ca Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > > > Tried that. Didn't work. Next? > > > > Can't the InterNIC force people to renumber? > > Obviously, renumbering will be required. One way to get people to > renumber is, if not politically correct, at least sure to be effective. > > Set a date for people downstream from you to have renumbered, and refuse > to advertise their old routes after that date. If the date is > reasonable your customers, and their customers, will renumber. If > they are unable, for some business/security reason, to renumber, then > they should be willing to pay through the teeth for the privelege of > having their non-standard route advertised. It would not work as the customer will just go to another NSP willing to do the routing for less money. If they all refuse or charge the same fees, the customer sues them all for collusion. > > At large interconnects (if the majority of the Big Providers agree > strongly that renumbering must, at all cost, be done) refuse packets from > other Big Providers which have not had their downstream customers a) > renumber completely, b) stop advertising routes for those who have not > forced this, or c) pay a large $sum to some benign organization whose > task it is to design cool new router technology (or something). I agree that the only cure at this time to the problem is to charge customers a few thousand dollars for advertising routes. Unfortunately, at least in the US, the only organization that could do it would be the government and many people do not consider it benign. Any other organization would be subject to anti-trust prosecution. > > c) is really quite vague, and will likely not work, as everyone will want > a piece of the large $sum. But if the people who refuse to play the > renumbering game have to shell out Big Bucks, it doesn't really matter > who the money goes to, just as long as the privelege of advertising > non-standard routes is not free. > How about giving it to the Red Cross. They could use the money (and better than any governmental organization :-)) The Internet would get a lot good publicity etc. > I am sure that there are enough bugs in this for Noel and Tony (and > anyone else who knows what they're talking about) to shoot it apart, but > what the heck! That's what we're here for! > > PS. I suspect that this 'reasonable date' would have to be set not too > far into the future for it to work... What are we waiting for? I, for > one, would rather renumber a functional Internet than try to revive a > nonfunctional one... > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > | Jason Marshall, marshalj@spots.ab.ca. Spots InterConnect, Inc. Calgary, AB | > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 03:10:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09241; Mon, 11 Sep 1995 03:10:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25321; Mon, 11 Sep 1995 03:08:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25128; Mon, 11 Sep 1995 02:42:04 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08332; Mon, 11 Sep 1995 02:41:58 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id MAA03626; Sun, 10 Sep 1995 12:43:23 -0400 Date: Sun, 10 Sep 1995 12:43:22 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Size of routers... To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9509101251.AA29112@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk 1) please, please, don't crosspost. 2) not only stabilization times, they are anyways a problem internal to a system (system=nsp with all the stuff hanging off it). What we should also discuss: how can we work together to straighten out traffic patterns: Example: inside, I can determine my own meds. outside, it is only possible for me to steer traffic by as path length. The result is as follows: I have peer A and peer B. I hear routes from peer A at meetpoint a, that I do not hear from peer B. Now, meetpoint b is for me the best exit for everything, and I want to have as much stuff going through it. Provider A sees my preference of meetpoint b, and the A traffic goes wiht the same path length indirectly through meetpoint b. Also for the stuff I only hear from A at meetpoint a. See the big byte circus? currently I see no mechanism to make that routes I hear from A at meetpoint a result in traffic to (trivial, I egress there) and from those locations through meetpoint a . Half of the bandwidth to A is thus unused. Now, please, don't tell me about asking A to do statics etc. Please, REAL stuff. Because this should work without manual intervention on both sides. Did I miss something? please be constructive, I am not the only one that has this problem. You don't understand it because there are phrases with more than 10 words in it? Ask what you don't understand. this problem we all have, and this is a point where we should have a real professional non emotional discussion. We all will profit of the result. Ban flamers now. Mike On Sun, 10 Sep 1995, Noel Chiappa wrote: > Ah, the usual IETF "streetlamp" debate. I call them this because it > reminds me of the old joke about the drunk who has lost their carkeys. > > (For those who don't know it, here it is: The police officer rolls up, > finds the drunk on their hands and knees, under a streetlamp, looking around. > The officer asks what gives, the drunk says "trying to find my carkeys". The > officer helpfully asks "where did you drop them", and the drunk points out > into the dark. The officer asks "why are you looking here if your keys are out > there", and the drunk replies "because there's more light here".) > > Debating stabilization times, etc, etc; hey, that takes too much real > knowledge of routing. But arguing about CPU speeds, hey, any geek can do that > until the cows come home. Why argue about the real issues when you can argue > about something you actually know something about. Pfagh. > > Noel > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 03:18:06 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09449; Mon, 11 Sep 1995 03:18:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25373; Mon, 11 Sep 1995 03:16:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25330; Mon, 11 Sep 1995 03:09:42 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09232; Mon, 11 Sep 1995 03:09:31 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id NAA03633; Sun, 10 Sep 1995 13:09:02 -0400 Date: Sun, 10 Sep 1995 13:09:01 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: bsw@netcom.com, michael@junction.net, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Subject: Re: oops -- wrong message In-Reply-To: <9509101528.AA29461@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Noel Chiappa wrote: > > > If NSP's feel that it is to their benefit to run route processors on > > custom-tailored UNIX boxes, then that's what will happen. > > Actually, I think we've been done that road before anyway. I recall some > big ANS core routers that were actually RS/6000s with a bunch of disk space > for virtual memory. > > Actually, there's an even closer match in the Route Server boxes which are > already deployed at major exchange points (MAE-[EW], Sprint-NAP, etc). There's > an article about them in the August "Connexions". (Try poking around starting > with http://www.merit.edu/routing.arbiter/RA/router.server.html for more > info.) > > They run on a SPARC, and handle only routing; user data traffic does not go > through them. So, they thus split the routing and forwarding functions exactly > as people have been suggesting. > > Noel > I was wondering when someone would bring that up (mischievious smile). I had read about the deployment of those boxes (Communications Week story on NANOG? the exact place escapes me but the story was how these boxes would be a major topic at NANOG) and that is why I made my original "split routing and forwarding post". I laughed everytime "experts" mentioned on this list that it could not be done and that I was stupid for even mentioning it. At first I was incredulous that no one on this list had heard about their deployment but then I could not resist playing along. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 03:22:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09553; Mon, 11 Sep 1995 03:22:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25401; Mon, 11 Sep 1995 03:20:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA25211; Mon, 11 Sep 1995 02:57:40 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08860; Mon, 11 Sep 1995 02:57:37 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id MAA03647; Sun, 10 Sep 1995 12:59:35 -0400 Date: Sun, 10 Sep 1995 12:59:35 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: oops -- wrong message To: Tim Bass Cc: Barney Wolff , big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509092151.AA11231@linux.silkroad.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk my worst ospf convergence time is still below 100ms. I don't care if it would be 10 seconds. tcp can swallow 90 seconds without dropping connections, so all web connections, email, ftp, telnet would still run. tftp's would see some timeouts. Really , processing speed isn't the point here. I prefer, btw., a slower route server. Keeps oscillating serial links out. Mike On Sat, 9 Sep 1995, Tim Bass wrote: > > > > Folks, Noel's point, which some seem unwilling or unable to grasp, is > > that neither BGP4 nor OSPF have been parallelized. Until that's done, > > you can run them on a million-processor machine with no gain in speed. > > > > Huh? Noboby that I have read is suggesting that BGP4 nor OSPF are > inter-domain protocols of the future. The IETF has announced that BGP4 dies > in favor for another (still under development) inter-domain routing > protocol. > > It seems somewhat tangential to debate whether high end Intel or > RISC processors with 64/32 bit bus architectures and over 512M RAM > capable perform better than 68040 chips with 64M memory. Routers > are just computers with interfaces for data communications. If > the router vendors made such good computers, then we would see > them on our desk tops as work stations (a much bigger market > than routers :-). Certainly the operating system of a router > is not better than a refined UNIX.... > > Router hardware is not the real issue, it seems, but makes interesting > debate (maybe). Any one interesting in discussing the merits of > M. Steenstrup IDPR inter-domain policy routing and similar protocols? > > Tim > > > > > > -- > +--------------------------------------------------------------------------+ > | Tim Bass | #include | > | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | > | The Silk Road Group, Ltd. | take_one_down(); | > | | pass_it_around(); | > | http://www.silkroad.com/ | } | > | | back_to_work(); /*never reached */ | > +--------------------------------------------------------------------------+ > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 03:26:39 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09668; Mon, 11 Sep 1995 03:26:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25427; Mon, 11 Sep 1995 03:24:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25367; Mon, 11 Sep 1995 03:15:15 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09291; Mon, 11 Sep 1995 03:15:04 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id NAA11259; Sun, 10 Sep 1995 13:13:39 -0400 Message-Id: <199509101713.NAA11259@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Your message of "Sat, 09 Sep 1995 17:47:41 EDT." <9509092147.AA27772@ginger.lcs.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 10 Sep 1995 13:13:38 -0400 From: "Perry E. Metzger" Precedence: bulk I am not against agregation, at least not in the current version of how the world works -- i.e. with routers making routing decisions along the path of your packets based on advertised routing information. Agregation does indeed buy you something, and classless addresses are obviously the way to go. What I am trying to say, over and over, is that there seems to be this notion that somehow CIDR has solved the problem, and that if we all get agressive we can somehow avoid having routing tables continue to grow and grow. CIDR is *not* a panacea! It is a nice tool, and it can help, but it isn't a fix. I've already mentioned geographic diversity within a provider. As another example, There seems to be the notion on the part of many people that dual homing is some sort of aberation. It isn't. As connections get cheaper, it will become more and more of a standard way of doing business. Today its something any company with over a couple of thousand employees would want to do. Someday, your corner flower shop is going to be very concerned not to lose business on important days of the year and will be willing to pay the extra fifty bucks a month it costs them to get a link to a second provider. Why? Because they can, thats why. Losing an hours business on valentine's day would cost them too much. Today, of course, the companies and organizations that are starting to do this are people like banks that already are used to building high reliability networks and are starting to become dependant on information traveling over the nets, and ISPs, who are in deep trouble with their clients when they have outages -- even brief ones. Noel Chiappa writes: > From: "Perry E. Metzger" > > many of the clients I work with have decided to live with the situation > because it gives them the reliability they need. > > I hope your clients are also paying attention to the advice coming from a > regional network person, who said that in their experience the most important > aspect of reliability was to have spares on site, local tail-circuit runs > through different paths into different CO's, etc. Recent outages in Sprint, MCI, Alternet, and others say that this is wrong and the major problem is usually your provider these days. My clients typically go for fully redundant internal networks already, with no single point of failure in their entire systems (down to power circuits.) However, they have no way to control the way their providers are run. > (I was offline for 36 hours recently when my primary dial-in machine died. Sorry to hear it, but my clients are not generally vulnerable to internal failures at any single point. > Screwed up top-level providers have never had anything like that bad a hit.) When the outage is measured in hours and you are trying to download economic data from DRI, you care about a two hour outage -- even a fifteen minute outage at times. My clients don't rely on the internet nearly as much as they could because of the level of unreliability these days, and they frequently need their multi-homing. I'm really sick of people who think the internet is still some sort of toy where it isn't serious until its down for a day. > Multihoming is *not* a reliability panacea, Its a big help when it comes to provider outages. If you are multihomed, you should be able to get to any provider other than the one that went down on you. > and any customer who is led to believe that is is will probably be > pretty upset when some other unidentified single point of failure > (e.g. a big local hub router) goes belly-up and takes them down for > a day and more. My customers don't have any singly attached internal networks in typical cases so thats not a possibility. > >> If you have an exchange point in Denver .. and an exchange point in > >> Toronto ... it probably makes the most sense for you to send packets t o > >> .. customers in Tornoto via the Toronto exchange point and not the > >> Denver exchange point. > > How do you do that if no seperate routes are advertised by the provider > into their Toronto subnetwork? > > Your question as stated doesn't make any sense to me; you started off talking > about traffic going *to* Toronto, so there's no way routes advertised *into* > Toronto can make any difference. Perhaps you meant routes about Toronto > advertised into some other exchange points. I apologise for using the wrong preposition. It must have been very hard to determine what I was talking about. Not. > The whole point of CIDR seems to be to eliminate all that sort > of thing and get us to the word of fifty or ten or whatever > number of routes in the routers at our exchange points. > > Then you don't understand what CIDR is trying to do at all (and I'm > not talking about the cartoon version in which we get it down to 50 > routes in every router). I'm not the guy promoting the cartoon. Partisans of the CIDR world have been painting that picture. > The point of CIDR is to get us to the point where we can have > near-optimal routing, with routing tables which are substantially > smaller than flat tables. However, to do that, we have to have an > addressing hierarchy which is a good match to the topology. Unfortunately, addressing hierarchy is necessarily a tree, and a network isn't a tree. Its a very, very complicated graph, and it will only get worse with time. > This doesn't mean that we immediately aggregate routes to X.[1-9] > into a single route to X as soon as we are outside X; this would > indeed give us a lot of non-optimal entry point selection. Howver, > at some distance away from X, we *would* like to aggregate routes to > X.* into a single route to X; when you get far away from X, you can > generally do so without making the routes noticably worse. Unfortunately, I can't see how, in the real world of exchange points and providers, we can do that. You speak of China frequently, with statements like "why should China care about topology in the US -- why should they have to buy bigger routers because our routes are expanding". When someday there is one line from China going to one exchange point in the U.S. and another going to another exchange point, you no longer are in a situation where China's routing decisions are unaffected by US local topology. Indeed, as the world gets more and more geodesic, with lines being placed to accomodate load and not to follow geography, the topology looks less and less like a tree and there are fewer and fewer places to agregate routes "when you get far enough away". > In case this wasn't clear, look at the example above. Although X.* > have been "aggressive aggregated" into X, you still can get "more > routes" (and the better routes that result) by control of the scope > over which those individual pieces are advertised. So if I end up advertising the routes in to different portions of the provider anyway, I've eliminated a bunch of the benefits that I was promised, i.e. reduction in the number of advertised routes. Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 03:38:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10121; Mon, 11 Sep 1995 03:38:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25491; Mon, 11 Sep 1995 03:36:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25394; Mon, 11 Sep 1995 03:20:27 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09498; Mon, 11 Sep 1995 03:20:20 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id NAA03695; Sun, 10 Sep 1995 13:20:04 -0400 Date: Sun, 10 Sep 1995 13:20:04 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Noel Chiappa Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Size of routers... In-Reply-To: <9509101607.AA29661@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Noel Chiappa wrote: > Ignoring the monetary and social effects of their recommendation is > another hallmark of "experts". > > Better to be an "expert" who knows something about half the problem than > an "expert" who knows nothing at all about anything. Better to know that you are not an expert than go around thinking that you are an expert because you think you know half of the problem. > > Noel > From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 03:41:18 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10144; Mon, 11 Sep 1995 03:41:18 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25519; Mon, 11 Sep 1995 03:39:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25399; Mon, 11 Sep 1995 03:20:53 +1000 Received: from chaos.structured.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09505; Mon, 11 Sep 1995 03:20:48 +1000 (from kozowski@structured.net) Received: (from kozowski@localhost) by chaos.structured.net (8.6.10/Structured_8.6.12) id KAA05923 for big-internet@munnari.OZ.AU; Sun, 10 Sep 1995 10:20:40 -0700 Date: Sun, 10 Sep 1995 10:20:40 -0700 From: Eric Kozowski Message-Id: <199509101720.KAA05923@chaos.structured.net> To: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them Precedence: bulk > Anectodal evidence suggests that NSPs do not even try to convince > their customers to use a number out of the NSP's block. > >Some do, some don't. I have anectodal evidence to the contrary. >Consistency would really help. I _always_ ask for customers to use addresses out of one of our CIDR blocks. Almost everyone does. Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski@structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1 From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 03:44:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10166; Mon, 11 Sep 1995 03:44:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25558; Mon, 11 Sep 1995 03:42:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25475; Mon, 11 Sep 1995 03:31:18 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09877; Mon, 11 Sep 1995 03:30:57 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id NAA11283; Sun, 10 Sep 1995 13:30:52 -0400 Message-Id: <199509101730.NAA11283@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: Tony Li Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers In-Reply-To: Your message of "Sat, 09 Sep 1995 19:28:35 PDT." <199509100228.TAA17320@greatdane.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 10 Sep 1995 13:30:51 -0400 From: "Perry E. Metzger" Precedence: bulk Tony Li writes: > > Until a week or two ago when Cisco finally announced a new 7500 series > router which finally uses a RISC processor at decent speed, their top > of the line router used the astonishingly pathetic 25Mhz > 68040. Its painful to think about $75K-$100K pieces of equipment using > processors that wouldn't be acceptable in bottom of the line video > game equipment. > > If you're going to dis us, please do it with FACTS. Recall that the > 7000 also has one (or more) 70MIPS processors per interface. Okay, lets also look at the FACTS. That "70MIPS processor" on the interface isn't a generic processor. It cannot run, say, BGP. > And the fact that they are not your conventional workstation CPU > does not make them ineffective. [For the record: they're VLIW > microsequencers. They are most impressive in their efficiency.] They aren't whats running the routing protocol, are they? > You might also recall that when the 7000 (really the CSC/4) came out, > the 68040 was pretty much the peak of the CISC microprocessor market. In an era where you could buy very nice much higher performance RISC workstations, as I recall. I also remember that being many generations of RISC workstation ago. It was even more generations of random Intel processor ago. > Thus, if you want to dis us, you really should focus on the length of > the product cycle: and that's directly tied to the complexity of the > problem and the non-volume of this market space. This is not an area > where you slap together a motherboard, the latest CPU, some RAM, and > ship 200,000 units the first quarter. Well, actually, I seriously wonder why the hell you guys make your own main CPU at all. You need to make your own switch processors, but it would seem to make more sense for you to be buying someone else's CPU board and interfacing it to the rest of the box via the system bus so you can toss the thing out every six months in favor of the fastest thing available. Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 03:47:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10204; Mon, 11 Sep 1995 03:47:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25588; Mon, 11 Sep 1995 03:45:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25440; Mon, 11 Sep 1995 03:25:20 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09650; Mon, 11 Sep 1995 03:25:14 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id NAA03669; Sun, 10 Sep 1995 13:17:25 -0400 Date: Sun, 10 Sep 1995 13:17:24 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: Geographinc addressing To: Sanjay Kapur Cc: Robert Moskowitz , Andrew Partan , Dave Siegel , big-internet@munnari.OZ.AU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Fri, 8 Sep 1995, Sanjay Kapur wrote: > > This is changing rapidly as the largest organizations are installing TCP/IP > > networks to match their size. These networks are moving more data over less > > bandwidth than the SNA networks BECAUSE THEY DO NOT USE VIRTUAL CIRCUITS. > > I can not get my IBM SNA person to agree with the above statement. He > insists that SNA is more efficient when it comes to bandwith > utilization. I will however not contest your statement since my I could not either. But the result of running in fact SNA via an IP network made the customers more happy: their screen responses (last drop on a multidrop) went from 30 seconds to 2. SNA is deterministic, IP is stochastic. SNA people calculate 'utilization' differently. they don't understand how a network can work if the packet propagation time is not exactly known. Putting in an Attachmate gateway and run sna via the LAN instead of extra cards in client PCs and coax infrastructure, made a small bank I dealt with happy too. Give your SNA guy a raise, send him to IP training, and everything is well. Mike > personal knowledge of SNA internals is extremely limited. > > > > > BTW, have you ever configured even a dozen 3745 nodes in an SNA network? > > Have you ever worked out a SNI interface between two SNA networks? Our SNA > > network is very stable now and actually shrinking. Back in its hey days, it > > took 8 people to manage 18 images and around 50 FEPs with about 2 dozen SNI > > interfaces. How many IP heavyweights do you have???? Oh, and we were able > > to actually make network changes on a monthly basis (including adding new > > controllers and changing terminal definitions); our poeple really had their > > act together! > > > > You actually WANT static routing? I'll show you static routing.... > > > > > > Today we have moved around 20,000 of our users from coax attachments to > > TN3270 via MVS/TCP. One person with a backup supports MVS/TCP on 18 images. > > > > When you had SNA, how many "help desk staffers" did you have configuring > those 20,000 users terminals? To be fair, you should include the time > spent in maintaining the IP addresses and TCP/IP software of the users in > the above equation. > > You have basically shifted the cost from a central department to user > departments. I am pretty sure the new solution is MUCH more expensive to > the Chrysler Corporation as a whole since I do not believe that all the > 20,000 users would have needed a TCP/IP connection otherwise. > > I have two questions to which I would really want an answer. > > Are you willing to renumber the IP number of all the 20,000 users? Are > you even willing to renumber the IP address of the 18 MVS hosts? > > Please do not throw stones at others and force them to renumber if you can > not honestly answer yes to the above questions. > > > Robert Moskowitz > > Chrysler Corporation > > (810) 758-8212 > > > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 03:58:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10508; Mon, 11 Sep 1995 03:58:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25642; Mon, 11 Sep 1995 03:56:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25532; Mon, 11 Sep 1995 03:40:27 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10138; Mon, 11 Sep 1995 03:40:24 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id NAA11303; Sun, 10 Sep 1995 13:40:07 -0400 Message-Id: <199509101740.NAA11303@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: Tony Li Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers... In-Reply-To: Your message of "Sat, 09 Sep 1995 19:34:25 PDT." <199509100234.TAA17392@greatdane.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 10 Sep 1995 13:40:07 -0400 From: "Perry E. Metzger" Precedence: bulk Tony Li writes: > I believe that if the route > processing was handled in a standard box based on UNIX that problems of > CPU power, RAM capacity and the like could be averted. > > The theory being that Unix systems are not subject to the laws of > growth of CPU power or RAM? The theory being that DEC, HP and Sun are better at building scalable Unix boxes with lots of flexibility than Cisco, which seems to have too small a volume to keep the CPUs in their boxes hot. Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 04:01:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10756; Mon, 11 Sep 1995 04:01:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA25668; Mon, 11 Sep 1995 03:59:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25564; Mon, 11 Sep 1995 03:43:34 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10162; Mon, 11 Sep 1995 03:43:29 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id NAA11311; Sun, 10 Sep 1995 13:43:24 -0400 Message-Id: <199509101743.NAA11311@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: Nathan Stratton Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers In-Reply-To: Your message of "Sun, 10 Sep 1995 00:48:11 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 10 Sep 1995 13:43:23 -0400 From: "Perry E. Metzger" Precedence: bulk Nathan Stratton writes: > On Sat, 9 Sep 1995, Tony Li wrote: > > > Please feel free to purchase a 7500 and find out for yourself. > > Yes, but say we go out a get it, how long until we need the next cisco. > We just can't keep dumping money into hardware such a short life. I'm afraid that you have to. I'm expecting that the practical lifetime of network hardware will continue to shrink with time. This is to be expected as traffic volume will continue to exponentiate well into the next century and design cycles will continue to shrink. If you are in a computer related business, you should resign yourself now to dealing with depreciating your equipment in under two years and, someday, in under one. I'm sure things were nicer back in the days of the early industrial revolution where mill equipment could last a generation, but that isn't the world we live in. Things move fast. You have to live with it. What worrys me is not having to buy a new Cisco in a year, but having Cisco not have a new system in a year to buy. Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 04:04:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10821; Mon, 11 Sep 1995 04:04:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA25694; Mon, 11 Sep 1995 04:02:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25493; Mon, 11 Sep 1995 03:37:10 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09919; Mon, 11 Sep 1995 03:37:02 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id NAA11292; Sun, 10 Sep 1995 13:36:58 -0400 Message-Id: <199509101736.NAA11292@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: Tony Li Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, inet-access@earth.com Subject: Re: Size of routers In-Reply-To: Your message of "Sat, 09 Sep 1995 19:10:37 PDT." <199509100210.TAA17172@greatdane.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 10 Sep 1995 13:36:57 -0400 From: "Perry E. Metzger" Precedence: bulk Tony Li writes: > But you're still missing the point: throwing more hardware at the > problem is not a reasonable long term solution. The whole reason that > we started down this path is that the exponential growth of the net > exceeds the rate at which hardware progresses. Just doing SMP only > increases things by a constant and that gets gobbled up very quickly. I'll point out as an aside that it is clear that the exponential growth will continue only for a limited period. The net is going to follow an S-curve just like fax machines, telephones, and everything else. We only have to survive for ten years, not forever. It might not be unreasonable to simply throw hardware at the problem for a while. I want to emphasize that I am not arguing that we shouldn't do things like CIDR to reduce the frivolous growth of the routing tables -- things like routes to single-connected networks of ten machines in an office somewhere. What I am trying to say, along with others, however, is that it isn't going to fix the bigger problem. Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 04:07:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB10865; Mon, 11 Sep 1995 04:07:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA25721; Mon, 11 Sep 1995 04:05:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25620; Mon, 11 Sep 1995 03:54:58 +1000 Received: from eunet.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10431; Mon, 11 Sep 1995 03:54:52 +1000 (from bilse@EU.net) Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id TAA05144; Sun, 10 Sep 1995 19:54:43 +0200 Received: by jotun.EU.net id AA12153 (5.67a/IDA-1.5); Sun, 10 Sep 1995 19:54:43 +0200 Message-Id: <199509101754.AA12153@jotun.EU.net> From: Per Gregers Bilse Date: Sun, 10 Sep 1995 19:54:42 +0200 In-Reply-To: <199509101616.AA04377@linux.silkroad.com> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Tim Bass Subject: Re: Topological vs. Administrative Aggregation Cc: big-internet@munnari.OZ.AU, com-priv@list.psi.com Precedence: bulk On Sep 10, 12:16, Tim Bass wrote: > So, my question is, why advocate topologicical based aggregation over > administrative domain aggregation? Quoting from your text, here's why: not yet implemented, to be determined, still under development, currently unspecified. It is extremely easy to outline alternative paradigms and many of them can be made to work one way or another, given time. Once IPv4 is history things -will- be different. But right now and in the near term we don't have anything else -- and this means there's a big, ugly problem in the horizon. The issue under discussion is what to do about that problem. The opponents of the current proposals (including you) have failed to demonstrate any viable alternatives, and yet maintain that the current proposals must not go ahead. This is the same as saying we should do nothing, which is the historical reason why this ugly problem is now heading our way. You want to reapeat history? The remedies in the next round will be much, much less palatable than the ones currently being discussed. -- ====== ___ === Per G. Bilse, Mgr Network Operations Ctr ===== / / / __ ___ _/_ ==== EUnet Communications Services B.V. ==== /--- / / / / /__/ / ===== Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / ====== tel: +31 20 6233803, fax: +31 20 6224657 === ======= 24hr emergency number: +31 20 421 0865 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 04:10:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10889; Mon, 11 Sep 1995 04:10:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA25741; Mon, 11 Sep 1995 04:07:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25508; Mon, 11 Sep 1995 03:38:48 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10122; Mon, 11 Sep 1995 03:38:39 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id KAA07866; Sun, 10 Sep 1995 10:38:24 -0700 From: Dave Siegel Message-Id: <199509101738.KAA07866@seagull.rtd.com> Subject: Re: Keeping the Internet goingOA To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Sun, 10 Sep 1995 10:38:24 -0700 (MST) Cc: RAF@CU.NIH.GOV, nelson@crynwr.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9509091303.AA26605@ginger.lcs.mit.edu> from "Noel Chiappa" at Sep 9, 95 09:03:27 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1585 Precedence: bulk > As I said, the way that makes the most sense here is not for your provider to > start charging you [which will either i) need some sort of intricate > settlements system worked out beforehand, or ii) drive your provider out of > business is they do it unilaterally], but for your provider to start charging > other providers for carrying *their* routes. > > If this caught on, it would eventually lead to customers paying, but only to > produce the $$$ for their provider to pay every other provider for carrying > your route. If, of course, you as a customer had an address which came out of > a block which was advertised as single entry, and shared with other people, > you'd save money... This is, of course, the problem. Nationwide providers will *have* to charge their customers for routes, since they will be charged based on each peer they have. This will have two effects. 1) Prices for ISP net access will go up fairly signifigantly accross the United States. 2) Larger providers wil be less apt to peer with smaller providers, since it will cost the larger provider *more* to peer with the smaller guy. It's bad enough trying to get time out of the larger peers to set up a bgp session, can you imagine how much longer this process would take if you had to get sales plus a pre-sales engineer (a route adder) involved in this process? Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 04:19:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11273; Mon, 11 Sep 1995 04:19:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA25801; Mon, 11 Sep 1995 04:16:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA25789; Mon, 11 Sep 1995 04:14:30 +1000 Received: from cesium.clock.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11031; Mon, 11 Sep 1995 04:14:22 +1000 (from smd@cesium.clock.org) Received: by cesium.clock.org id <6248>; Sun, 10 Sep 1995 11:14:14 -0700 From: Sean Doran To: michael@junction.net, tli@cisco.com Subject: Re: Distributed systems Cc: asp@uunet.uu.net, bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Message-Id: <95Sep10.111414pdt.6248@cesium.clock.org> Date: Sun, 10 Sep 1995 11:14:10 -0700 Precedence: bulk Oh, also, what do you do if routing suddenly changes and a hundred thousand or more packets per second to some 13-16k prefixes per second wants to route through a box that previously had only a very small subset of routes in the cache? Sean. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 04:22:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11487; Mon, 11 Sep 1995 04:22:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA25831; Mon, 11 Sep 1995 04:20:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA25754; Mon, 11 Sep 1995 04:10:02 +1000 Received: from cesium.clock.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB10884; Mon, 11 Sep 1995 04:09:57 +1000 (from smd@cesium.clock.org) Received: by cesium.clock.org id <6248>; Sun, 10 Sep 1995 11:09:33 -0700 From: Sean Doran To: michael@junction.net, tli@cisco.com Subject: Re: Distributed systems Cc: asp@uunet.uu.net, bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Message-Id: <95Sep10.110933pdt.6248@cesium.clock.org> Date: Sun, 10 Sep 1995 11:09:19 -0700 Precedence: bulk Um, with respect to subsets of routing tables in a switching engine, given a need to do longest-match routing and a need to be able to move many packets very quickly to /30s and /32s for IPv4, how does one know when there is a cache miss that has to be answered by the main processor if the cache is not fully populated? Sean. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 04:26:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11581; Mon, 11 Sep 1995 04:26:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA25871; Mon, 11 Sep 1995 04:25:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA25640; Mon, 11 Sep 1995 03:56:35 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10483; Mon, 11 Sep 1995 03:56:30 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id NAA11342; Sun, 10 Sep 1995 13:56:26 -0400 Message-Id: <199509101756.NAA11342@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers... In-Reply-To: Your message of "Sun, 10 Sep 1995 09:00:22 EDT." <9509101300.AA29149@ginger.lcs.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 10 Sep 1995 13:56:26 -0400 From: "Perry E. Metzger" Precedence: bulk Noel Chiappa writes: > PS: For what it's worth, someone who actually knows something about > this stuff says that there are good reasons to believe that we only > get a few (like maybe two) more halvings of feature size before we > run into some hard physics limits on semiconductor fabrication, at > which point we'll be off that curve. Different semiconductor > technologies (i.e. not silicon) might offer continued speed advances > at that point, but probably not as cheaply. There is, however, plenty of room "at the bottom". Current designs for molecular computers are theoretical, but by the time everything else runs out of steam they are likely to come to pass. The real limits will probably end up being the kT limit on the amount of energy an individual non-reversable computation consumes. We are likely to get around this by starting to use machines that do reversable computations, but that is going to involve a number of real revolutions in the way we do things. Luckily, we have another twenty years before this problem comes into sight. Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 04:29:05 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11634; Mon, 11 Sep 1995 04:29:05 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA25895; Mon, 11 Sep 1995 04:27:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA25747; Mon, 11 Sep 1995 04:09:19 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10880; Mon, 11 Sep 1995 04:09:13 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id LAA09542; Sun, 10 Sep 1995 11:09:01 -0700 From: Dave Siegel Message-Id: <199509101809.LAA09542@seagull.rtd.com> Subject: Re: oops -- wrong message To: perry@piermont.com Date: Sun, 10 Sep 1995 11:09:01 -0700 (MST) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509091704.NAA09256@frankenstein.piermont.com> from "Perry E. Metzger" at Sep 9, 95 01:04:04 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1532 Precedence: bulk > Until a week or two ago when Cisco finally announced a new 7500 series > router which finally uses a RISC processor at decent speed, their top > of the line router used the astonishingly pathetic 25Mhz > 68040. Its painful to think about $75K-$100K pieces of equipment using > processors that wouldn't be acceptable in bottom of the line video > game equipment. > > Unfortunately, Cisco is basically the only backbone router vendor > right now, Bay Networks stuff not being BGP-4 capable. It would be > really neat to see how our routers did if they actually kept up with > current technology. Ah, but Bay Networks DOES support bgp4, and it'll even link up okay with a Cisco running BGP4. The problem is configuration. Designing the filter-lists using a Windows Interface is a real pain in the neck. The Bay Networks has a fairly intelligent design, hardware wise. The BN holds 4 cards, and has a 68040 w/32Megs of RAM on each board, plus an RP on a seperate board. The Systems Engineer we had on site said they were not planning on providing 64meg capability anytime soon...most of their efforts were on releasing the next release of the software, which would be completely configurable from the command line. It's been a while since I've talked to them...they might have this out now. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 04:57:10 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12481; Mon, 11 Sep 1995 04:57:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA25972; Mon, 11 Sep 1995 04:56:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA25957; Mon, 11 Sep 1995 04:53:52 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12368; Mon, 11 Sep 1995 04:53:45 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id LAA11404; Sun, 10 Sep 1995 11:53:30 -0700 From: Dave Siegel Message-Id: <199509101853.LAA11404@seagull.rtd.com> Subject: Re: Size of routers... To: tli@cisco.com (Tony Li) Date: Sun, 10 Sep 1995 11:53:29 -0700 (MST) Cc: michael@junction.net, smd@cesium.clock.org, asp@uunet.uu.net, bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu In-Reply-To: <199509100234.TAA17392@greatdane.cisco.com> from "Tony Li" at Sep 9, 95 07:34:25 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 928 Precedence: bulk > Cisco has separated the functions within their own boxes, but has anyone > put these funtions into two separate boxes? > > As a matter of fact, yes. > > I believe that if the route > processing was handled in a standard box based on UNIX that problems of > CPU power, RAM capacity and the like could be averted. > > The theory being that Unix systems are not subject to the laws of > growth of CPU power or RAM? > > Sorry, the net still crashes and burns if you do this. Your Unix box > still doesn't grow fast enough. And depending on what OS you use, you might want to reboot it at midnight once a week just to make sure it doesn't decide to dump during peak. ;-) Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 05:25:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13276; Mon, 11 Sep 1995 05:25:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA26037; Mon, 11 Sep 1995 05:24:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA26008; Mon, 11 Sep 1995 05:08:41 +1000 Received: from zeus.NIC.DTAG.DE by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12761; Mon, 11 Sep 1995 05:08:37 +1000 (from rv@zeus.NIC.DTAG.DE) Received: from zeus.NIC.DTAG.DE (localhost.NIC.DTAG.DE [127.0.0.1]) by zeus.NIC.DTAG.DE (8.6.12/8.6.12) with ESMTP id VAA20314; Sun, 10 Sep 1995 21:05:14 +0200 To: Sanjay Kapur Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Sun, 10 Sep 1995 12:50:36 EDT." Date: Sun, 10 Sep 1995 21:05:14 +0200 Message-Id: <20312.810759914@zeus.NIC.DTAG.DE> From: Ruediger Volk Precedence: bulk Sanjay, your remark > BT is also a government regulated monopoly. Case closed. makes me wonder whether you have received any news from the British Isles after the recent coronation of their young queen Elizabeth (the second - of course) :-) Which case should I be closing now? BTW I would expect that some government body will be at least monitoring any major overhaul of telephone numbering plans even in so called deregulated environments. Ruediger Volk From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 05:27:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13311; Mon, 11 Sep 1995 05:27:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA26073; Mon, 11 Sep 1995 05:26:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA25996; Mon, 11 Sep 1995 05:02:39 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12533; Mon, 11 Sep 1995 05:02:36 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id MAA11797; Sun, 10 Sep 1995 12:02:24 -0700 From: Dave Siegel Message-Id: <199509101902.MAA11797@seagull.rtd.com> Subject: Re: Size of routers To: nathan@netrail.net (Nathan Stratton) Date: Sun, 10 Sep 1995 12:02:24 -0700 (MST) Cc: tli@cisco.com, perry@piermont.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: from "Nathan Stratton" at Sep 10, 95 00:48:11 am X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 610 Precedence: bulk > > Please feel free to purchase a 7500 and find out for yourself. > > Yes, but say we go out a get it, how long until we need the next cisco. > We just can't keep dumping money into hardware such a short life. How is this different then upgrading your P133 w/256 megs to a quad-piped 200MHz Alpha w/ 512Megs of RAM, to a 4 processor alpha, to a 20 processor Sun, to a ..... Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 05:29:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13355; Mon, 11 Sep 1995 05:29:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA26095; Mon, 11 Sep 1995 05:28:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA26002; Mon, 11 Sep 1995 05:04:43 +1000 Received: from [204.71.127.3] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12675; Mon, 11 Sep 1995 05:04:34 +1000 (from carl@intrepid.net) Received: (from carl@localhost) by loki.intrepid.net (8.6.12/8.6.9) id PAA32538; Sun, 10 Sep 1995 15:04:54 -0400 Date: Sun, 10 Sep 1995 15:04:54 -0400 From: Carl Hillsman Subject: Re: Routing tables & what to do about them To: "Michael F. Nittmann" Cc: big-internet@munnari.OZ.AU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Michael F. Nittmann wrote: > > Anectodal evidence suggests that NSPs do not even try to convince > > their customers to use a number out of the NSP's block. > > we do, and so do most I guess. If a customer comes with an address, the > first point of discussion is to find out if the customer can renumber. > Most can. I wnat my bb tables small too, that's the first motivation, not > sanity on behalf of all the others (but that's a close second). for an isp that is planning on having multiple pops, being dual homed, offering both dedicated and dialup access, where sould they get the addresses from? the current upstream provider or the nic? carl From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 05:36:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13578; Mon, 11 Sep 1995 05:36:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA26116; Mon, 11 Sep 1995 05:36:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA26025; Mon, 11 Sep 1995 05:19:36 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13017; Mon, 11 Sep 1995 05:19:31 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id PAA04751; Sun, 10 Sep 1995 15:19:13 -0400 Date: Sun, 10 Sep 1995 15:19:12 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Ruediger Volk Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <20312.810759914@zeus.NIC.DTAG.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Ruediger Volk wrote: > Sanjay, > > your remark > > BT is also a government regulated monopoly. Case closed. > > makes me wonder whether you have received any news from the British Isles > after the recent coronation of their young queen Elizabeth (the second > - of course) :-) > Which case should I be closing now? > > BTW I would expect that some government body will be at least monitoring > any major overhaul of telephone numbering plans even in so called deregulated > environments. > > > Ruediger Volk > I did not say "Government Owned", not "Tightly Regulated", just simply "Government regulated". BTW what can be deregulated quickly can be reregulated even faster if enough voters complain. What was the purpose of the renumbering by BT? Allow for more competition or less competition? Deregulation also implies that there is effective competition and new monopolies do not develop. With NSPs there is absolutely no consumer protection (at least in the US). Forced renumbering will give NSPs a monopoly position that they do not enjoy at this time. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 05:39:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13632; Mon, 11 Sep 1995 05:39:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA26147; Mon, 11 Sep 1995 05:39:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA26032; Mon, 11 Sep 1995 05:23:52 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13122; Mon, 11 Sep 1995 05:23:41 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id MAA12977; Sun, 10 Sep 1995 12:23:08 -0700 From: Dave Siegel Message-Id: <199509101923.MAA12977@seagull.rtd.com> Subject: Re: oops -- wrong message To: mn@ios.com (Michael F. Nittmann) Date: Sun, 10 Sep 1995 12:23:07 -0700 (MST) Cc: bass@linux.silkroad.com, barney@databus.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: from "Michael F. Nittmann" at Sep 10, 95 12:59:35 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1179 Precedence: bulk > my worst ospf convergence time is still below 100ms. I don't care if it > would be 10 seconds. tcp can swallow 90 seconds without dropping > connections, so all web connections, email, ftp, telnet would still run. > tftp's would see some timeouts. > > Really , processing speed isn't the point here. I prefer, btw., a slower > route server. Keeps oscillating serial links out. Not necessarily...it might just be behind the ball. It'll catch, but not calculate the down, process the down, recieve the new up oscillation, send the down message to the router, process the up message. If you bump up the keepalive on the bgp session through the serial link, or static null route the larger sbunet'd block for the serial IP's (for static'd customers) you'll see little oscilation. If you can heavily CIDRize your announcements, the effects of your network on outside networks will be small, regardless of what's happening inside your core. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 05:56:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14051; Mon, 11 Sep 1995 05:56:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA26212; Mon, 11 Sep 1995 05:56:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA26183; Mon, 11 Sep 1995 05:48:23 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13919; Mon, 11 Sep 1995 05:48:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00599; Sun, 10 Sep 95 15:48:13 -0400 Date: Sun, 10 Sep 95 15:48:13 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509101948.AA00599@ginger.lcs.mit.edu> To: perry@piermont.com Subject: Re: Size of routers Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Perry E. Metzger" It might not be unreasonable to simply throw hardware at the problem for a while. This might be true is the *only* effect of the net getting larger is that is uses more table space, but unfortunately there is a lot more going on than just that. For instance, why don't you write down a back-of-the-envelope version for the stabilization time for the routing after a topology change, for a network using a destination vector routing system? (Let's ignore the dynamics of multiple simultaneous changes for now, to make it easy.) You will notice, if you do, that things like propogation time enter into it. Now, if you will explain to me how "throw[ing] [more] hardware" at the problem will cause light to move faster, then maybe I will believe your assertion. Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 06:16:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14800; Mon, 11 Sep 1995 06:16:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA26268; Mon, 11 Sep 1995 06:16:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA26261; Mon, 11 Sep 1995 06:10:18 +1000 Received: from zeus.NIC.DTAG.DE by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14588; Mon, 11 Sep 1995 06:10:14 +1000 (from rv@zeus.NIC.DTAG.DE) Received: from zeus.NIC.DTAG.DE (localhost.NIC.DTAG.DE [127.0.0.1]) by zeus.NIC.DTAG.DE (8.6.12/8.6.12) with ESMTP id WAA22503; Sun, 10 Sep 1995 22:07:01 +0200 To: Sanjay Kapur Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Sun, 10 Sep 1995 15:19:12 EDT." Date: Sun, 10 Sep 1995 22:07:01 +0200 Message-Id: <22501.810763621@zeus.NIC.DTAG.DE> From: Ruediger Volk Precedence: bulk > I did not say "Government Owned", not "Tightly Regulated", just simply > "Government regulated". hmmm, I guess there are not that many areas that are *completely* without Government regulation. But anyway - it was your claim of BT being a monopoly that triggered my response... Ruediger Volk From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 06:18:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14831; Mon, 11 Sep 1995 06:18:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA26290; Mon, 11 Sep 1995 06:17:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA26235; Mon, 11 Sep 1995 06:00:21 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14239; Mon, 11 Sep 1995 06:00:17 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id PAA05049; Sun, 10 Sep 1995 15:59:49 -0400 Date: Sun, 10 Sep 1995 15:59:49 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: "Michael F. Nittmann" Cc: Tim Bass , Barney Wolff , big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Michael F. Nittmann wrote: > my worst ospf convergence time is still below 100ms. I don't care if it > would be 10 seconds. tcp can swallow 90 seconds without dropping > connections, so all web connections, email, ftp, telnet would still run. > tftp's would see some timeouts. > > Really , processing speed isn't the point here. I prefer, btw., a slower > route server. Keeps oscillating serial links out. > > Mike > It becomes important in real time applications like video that NSPs want to get into. I think NSPs should stick to using pure ATM (virtual circuits?) for video type applications (real time, high bandwith, point to point or point to multipoint) and not layer TCP/IP and routing on top of ATM. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 06:19:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14876; Mon, 11 Sep 1995 06:19:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA26314; Mon, 11 Sep 1995 06:19:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA26247; Mon, 11 Sep 1995 06:08:21 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14356; Mon, 11 Sep 1995 06:08:18 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id NAA14303; Sun, 10 Sep 1995 13:15:19 -0700 Date: Sun, 10 Sep 1995 13:15:17 -0700 (PDT) From: Michael Dillon To: Dave Siegel Cc: Nathan Stratton , tli@cisco.com, perry@piermont.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers In-Reply-To: <199509101902.MAA11797@seagull.rtd.com> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Dave Siegel wrote: > > > Please feel free to purchase a 7500 and find out for yourself. > > > > Yes, but say we go out a get it, how long until we need the next cisco. > > We just can't keep dumping money into hardware such a short life. > > How is this different then upgrading your P133 w/256 megs to a quad-piped > 200MHz Alpha w/ 512Megs of RAM, to a 4 processor alpha, to a 20 processor > Sun, to a ..... The P133/Alpha/Sun is a general purpose computer that has resale value and potentially has other uses in your organization, thus it does not need to be discarded in the same way that a high-end Cisco might. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 06:21:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14989; Mon, 11 Sep 1995 06:21:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA26342; Mon, 11 Sep 1995 06:20:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA26264; Mon, 11 Sep 1995 06:13:57 +1000 Received: from eunet.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14680; Mon, 11 Sep 1995 06:13:53 +1000 (from bilse@EU.net) Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id WAA09810; Sun, 10 Sep 1995 22:13:49 +0200 Received: by jotun.EU.net id AA12770 (5.67a/IDA-1.5); Sun, 10 Sep 1995 22:13:47 +0200 Message-Id: <199509102013.AA12770@jotun.EU.net> From: Per Gregers Bilse Date: Sun, 10 Sep 1995 22:13:47 +0200 In-Reply-To: Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Sanjay Kapur Subject: Re: Routing tables & what to do about them Cc: big-internet@munnari.OZ.AU Precedence: bulk On Sep 10, 15:19, Sanjay Kapur wrote: > Forced renumbering will give NSPs a monopoly position that they do > not enjoy at this time. This is a ghost if ever there was one. The big explosion in the Internet business is small companies and home users; they can renumber with great ease (dial-up users typically have dynamic addresses anyway). Moreover, a manageable and slow-growing routing table will allow entry to the business without excessive capital costs. A totally uncontrolled and out-of-bound growth, with route processors assembled from hand-crafted supercomputer hardware and upgraded with the latest technology every six months, will push the costs sky high. This is clearly to the advantage of the established and well-capitalized players. Hmmm ... some people might argue that this ain't so bad. -- ====== ___ === Per G. Bilse, Mgr Network Operations Ctr ===== / / / __ ___ _/_ ==== EUnet Communications Services B.V. ==== /--- / / / / /__/ / ===== Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / ====== tel: +31 20 6233803, fax: +31 20 6224657 === ======= 24hr emergency number: +31 20 421 0865 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 06:23:12 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15037; Mon, 11 Sep 1995 06:23:12 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA26362; Mon, 11 Sep 1995 06:23:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA26214; Mon, 11 Sep 1995 05:56:26 +1000 Received: from zeus.NIC.DTAG.DE by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14034; Mon, 11 Sep 1995 05:56:13 +1000 (from rv@zeus.NIC.DTAG.DE) Received: from zeus.NIC.DTAG.DE (localhost.NIC.DTAG.DE [127.0.0.1]) by zeus.NIC.DTAG.DE (8.6.12/8.6.12) with ESMTP id VAA22036; Sun, 10 Sep 1995 21:52:55 +0200 To: Tim Bass Cc: big-internet@munnari.OZ.AU Subject: Re: Topological vs. Administrative Aggregation In-Reply-To: Your message of "Sun, 10 Sep 1995 12:16:56 EDT." <199509101616.AA04377@linux.silkroad.com> Date: Sun, 10 Sep 1995 21:52:55 +0200 Message-Id: <22034.810762775@zeus.NIC.DTAG.DE> From: Ruediger Volk Precedence: bulk Tim, > Noel, maybe I have to regret making the following unsolicited comments since Noel certainly has much more credentials and experience for judging your proposal than me... > Please comment on this simple brief.... Thanks. it looks like a good base for writing a research proposal. It's not quite clear whether it should be considered for "basic" or "applied" research considering the number and seeming severity of "not yet implemented", "TBD", "still under development", "could be", "paradigm currently unspecified"; I assume the answer will be quite easy after you add the usual paragraph about "previous & other research in the field". If you consider this to be "applied" you probably can improve your chances to get funding by adding a paragraph outlining the time line till expected production use deployment (you might want to call it "time to market"). BTW I note that you do not include any claim of your proposal to produce an optimal solution; claiming and proving optimality of the resulting design under most metrics would make the research even more interesting. However if you actually consider the proposal just an engineering challenge of course the question of the "optimal" solution is moot, because engineers are supposed to create solutions that are just solidly working in time and on budget - not taking infinite time and budget to approximate some kind of perfect thing. Good luck, Ruediger Volk :-) From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 06:36:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15477; Mon, 11 Sep 1995 06:36:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA26414; Mon, 11 Sep 1995 06:36:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA26322; Mon, 11 Sep 1995 06:19:39 +1000 Received: from ftp.spots.ab.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14869; Mon, 11 Sep 1995 06:19:31 +1000 (from marshalj@spots.ab.ca) Received: from ftp.spots.ab.ca (ftp.spots.ab.ca [204.191.210.11]) by ftp.spots.ab.ca (8.6.11/8.6.12) with SMTP id NAA29538; Sun, 10 Sep 1995 13:23:25 -0700 Date: Sun, 10 Sep 1995 13:23:25 -0700 (MST) From: Jason Marshall To: Sanjay Kapur Cc: Nathan Stratton , big-internet@munnari.OZ.AU, spots@spots.ab.ca Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > It would not work as the customer will just go to another NSP willing to > do the routing for less money. If they all refuse or charge the same fees, > the customer sues them all for collusion. If the customer is offered a new set of addresses for 'free' and he refuses them, or is unable to accept them for business reasons, then they have no ground to stand on in court if the/any NSP decides to charge them for the privelege (NOT THE RIGHT) of having their old route advertised. > I agree that the only cure at this time to the problem is to charge > customers a few thousand dollars for advertising routes. But using the current mess of routes, this doesn't solve anything. It will only prolong the agony IF this charge for advertising routes can be used to improve router technology; something that many people believe will never keep up with the growth of the Net at the current rates. > Unfortunately, at least in the US, the only organization that could do it > would be the government and many people do not consider it benign. Any other > organization would be subject to anti-trust prosecution. > How about giving it to the Red Cross. They could use the money (and better > than any governmental organization :-)) The Internet would get a lot > good publicity etc. Sure. I don't care who it goes to. Any mono-national organization (like a government) is out of the question. How about a huge internationsl TV ad campaign detailing the Evils of Advertising Old Routes so no one is caught by surprise? *8-)))) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jason Marshall, marshalj@spots.ab.ca. Spots InterConnect, Inc. Calgary, AB | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 06:56:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16251; Mon, 11 Sep 1995 06:56:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA26489; Mon, 11 Sep 1995 06:56:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA26468; Mon, 11 Sep 1995 06:43:41 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15854; Mon, 11 Sep 1995 06:43:32 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id QAA05376; Sun, 10 Sep 1995 16:43:16 -0400 Date: Sun, 10 Sep 1995 16:43:11 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Ruediger Volk Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <22501.810763621@zeus.NIC.DTAG.DE> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Ruediger Volk wrote: > hmmm, I guess there are not that many areas that are *completely* without > Government regulation. > > But anyway - it was your claim of BT being a monopoly that triggered my > response... > > Ruediger Volk > You may want to look up the definition of "monopoly". By a monopoly I mean any single entity or group of entities acting together that has a significant enough market share to effectively control the industry it is in. Any company that controls the industry enough to force a renumbering of all the phones of a whole country is almost by any definition a monopoly. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 06:57:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16266; Mon, 11 Sep 1995 06:57:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA26513; Mon, 11 Sep 1995 06:57:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA26453; Mon, 11 Sep 1995 06:40:51 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15581; Mon, 11 Sep 1995 06:40:47 +1000 (from gherbert@crl.com) Received: from crl2.crl.com by mail.crl.com with SMTP id AA19314 (5.65c/IDA-1.5); Sun, 10 Sep 1995 13:37:49 -0700 Message-Id: <199509102037.AA19314@mail.crl.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: perry@piermont.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, gherbert@crl.com Subject: Re: Size of routers In-Reply-To: Your message of "Sun, 10 Sep 1995 15:48:13 EDT." <9509101948.AA00599@ginger.lcs.mit.edu> Date: Sun, 10 Sep 1995 13:37:48 -0700 From: George Herbert Precedence: bulk Noel writes: > From: "Perry E. Metzger" > It might not be unreasonable to simply throw hardware at the problem for a > while. > >This might be true is the *only* effect of the net getting larger is that is >uses more table space, but unfortunately there is a lot more going on than >just that. > >For instance, why don't you write down a back-of-the-envelope version for the >stabilization time for the routing after a topology change, for a network >using a destination vector routing system? (Let's ignore the dynamics of >multiple simultaneous changes for now, to make it easy.) You will notice, if >you do, that things like propogation time enter into it. > >Now, if you will explain to me how "throw[ing] [more] hardware" at the problem >will cause light to move faster, then maybe I will believe your assertion. We have a number of problems facing us, from forwarding capability to routing calculations to stabilization times after failures. There is obviously not going to be a single panacea for all of them. Throwing more hardware at the problem can solve a number of these, but not all. The stabilization times issue is and will remain a sticky problem. -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 06:59:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16273; Mon, 11 Sep 1995 06:59:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA26533; Mon, 11 Sep 1995 06:58:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA26439; Mon, 11 Sep 1995 06:39:21 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15526; Mon, 11 Sep 1995 06:39:11 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA11676 (5.65c/IDA-1.4.4); Sun, 10 Sep 1995 16:38:00 -0400 From: Tim Bass Message-Id: <199509102038.AA11676@linux.silkroad.com> Subject: Re: Topological vs. Administrative Aggregation To: bilse@eu.net (Per Gregers Bilse) Date: Sun, 10 Sep 1995 16:38:00 -0400 (EDT) Cc: big-internet@munnari.OZ.AU, com-priv@list.psi.com In-Reply-To: <199509101754.AA12153@jotun.EU.net> from "Per Gregers Bilse" at Sep 10, 95 07:54:42 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2333 Precedence: bulk > The opponents of the current proposals (including you) have failed to > demonstrate any viable alternatives, and yet maintain that the > current proposals must not go ahead. This is the same as saying we The key word seems to be 'timely' not viable. Actually, recently I have been considering the "provider based aggregation" vis-a-vis "administrative domain aggregation" and there seems to be simple congruency emerging that is probally old new to many of the veterans. Provider based aggregation and administrate domain aggregation are actually the same thing when providers aggregate as administrative domains (which they most certainly do, with one or more AS numbers). Why not just simply aggregate the networks into the provider AS (s) and develop a simple Inter-domain routing protocol that aggregates both CIDR and classeful addresses into some provider "autonomous AD". The Inter-domain gateways would route on AD path vectors etc. etc. My question then is.... what is considered 'demonstration of viable alternatives' to paraphrase. It appears as if IDPR incorportated many of the idea that the current proponents of alternatives are advocating ( assuming I read 1478 correctly ). But when I look in the Routing WGs in the IETF for Interdomain Routing .... references to 1477,1478, 1479, etc. are absent and only CIDR based BGP4 remains. It does appear that some very good alternatives have been presented years ago and the ideas are resurfacing from new observers and players. These well doumented ideas seemed very viable in 1993 and were somehow judged, too slow? Too complex? What is wrong with moving forward the ideas of AD and policy based interdomain routing? Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 07:00:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16295; Mon, 11 Sep 1995 07:00:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA26561; Mon, 11 Sep 1995 07:00:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA26456; Mon, 11 Sep 1995 06:40:56 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15580; Mon, 11 Sep 1995 06:40:47 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA11676 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Sun, 10 Sep 1995 16:38:00 -0400 From: Tim Bass Message-Id: <199509102038.AA11676@linux.silkroad.com> Subject: Re: Topological vs. Administrative Aggregation To: bilse@eu.net (Per Gregers Bilse) Date: Sun, 10 Sep 1995 16:38:00 -0400 (EDT) Cc: big-internet@munnari.OZ.AU, com-priv@list.psi.com In-Reply-To: <199509101754.AA12153@jotun.EU.net> from "Per Gregers Bilse" at Sep 10, 95 07:54:42 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2333 Precedence: bulk > The opponents of the current proposals (including you) have failed to > demonstrate any viable alternatives, and yet maintain that the > current proposals must not go ahead. This is the same as saying we The key word seems to be 'timely' not viable. Actually, recently I have been considering the "provider based aggregation" vis-a-vis "administrative domain aggregation" and there seems to be simple congruency emerging that is probally old new to many of the veterans. Provider based aggregation and administrate domain aggregation are actually the same thing when providers aggregate as administrative domains (which they most certainly do, with one or more AS numbers). Why not just simply aggregate the networks into the provider AS (s) and develop a simple Inter-domain routing protocol that aggregates both CIDR and classeful addresses into some provider "autonomous AD". The Inter-domain gateways would route on AD path vectors etc. etc. My question then is.... what is considered 'demonstration of viable alternatives' to paraphrase. It appears as if IDPR incorportated many of the idea that the current proponents of alternatives are advocating ( assuming I read 1478 correctly ). But when I look in the Routing WGs in the IETF for Interdomain Routing .... references to 1477,1478, 1479, etc. are absent and only CIDR based BGP4 remains. It does appear that some very good alternatives have been presented years ago and the ideas are resurfacing from new observers and players. These well doumented ideas seemed very viable in 1993 and were somehow judged, too slow? Too complex? What is wrong with moving forward the ideas of AD and policy based interdomain routing? Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 07:02:42 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16323; Mon, 11 Sep 1995 07:02:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA26583; Mon, 11 Sep 1995 07:02:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA26411; Mon, 11 Sep 1995 06:36:13 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15462; Mon, 11 Sep 1995 06:36:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00791; Sun, 10 Sep 95 16:35:11 -0400 Date: Sun, 10 Sep 95 16:35:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509102035.AA00791@ginger.lcs.mit.edu> To: perry@piermont.com Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Perry E. Metzger" What I am trying to say, over and over, is that there seems to be this notion that somehow CIDR has solved the problem, and that if we all get agressive we can somehow avoid having routing tables continue to grow and grow. Well, yes, even with CIDR routing tables will still grow as the network grows, if we want to maintain the same ratio of actual path length to optimal path length (as I mentioned in a previous message). However, that growth rate is reasonably slow; growth of O(lnN) means that you go from 3,000 entries with a network with 300K physical networks (for an average path length increase of 10%) to 20,000 entries for a network with 10M physical networks (all assuming fairly optimal addressing hierarchies). In other words, an increase of a factor of over 30 in network size means an increase of less than a factor of 10 in routing table size. CIDR is *not* a panacea! It is a nice tool, and it can help, but it isn't a fix. There is no "fix". Routing tables are always going to get larger as a network gets larger, if you want to maintain the same ratio of actual path length to optimal path length. > Multihoming is *not* a reliability panacea, Its a big help when it comes to provider outages. If you are multihomed, you should be able to get to any provider other than the one that went down on you. Fine, but it's not without an overhead cost if you expect the routing to be the one to swap in the second link for you. If we had another layer of mapping in the system (i.e. more than just DNS name -> routing-name) it might be cheaper in terms of system overhead, but we have no EID's. > The point of CIDR is to get us to the point where we can have > near-optimal routing, with routing tables which are substantially > smaller than flat tables. However, to do that, we have to have an > addressing hierarchy which is a good match to the topology. Unfortunately, addressing hierarchy is necessarily a tree, and a network isn't a tree. Its a very, very complicated graph, and it will only get worse with time. No. An irregular graph with no discernable structure can still have a tree- structed addresing hierarchy. (See the example on page 158 of Kleinrock and Kamoun.) If you had bothered to read the explanation, and example, I sent to Ohta-san about how the topology and the addressing hierarchy are not related in the way you think it is, you'd have known this statement is completely wrong. I will dig the example up and send it to you. (In fact, I'm amazed and apalled that anyone who's trying to participate in this debate doesn't understand the difference. I wish in future you wouldn't waste everyone's time like this; making yourself look clueless to the many people here who do understand the distinction is your own lookout.) > This doesn't mean that we immediately aggregate routes to X.[1-9] > into a single route to X as soon as we are outside X Unfortunately, I can't see how, in the real world of exchange points and providers, we can do that. I gather BGP communities do this just fine. When someday there is one line from China going to one exchange point in the U.S. and another going to another exchange point, you no longer are in a situation where China's routing decisions are unaffected by US local topology. If you had understood the point about AAB's, you'd understand how this works. Indeed, as the world gets more and more geodesic, with lines being placed to accomodate load and not to follow geography, the topology looks less and less like a tree and there are fewer and fewer places to agregate routes "when you get far enough away". I can't find this result off the top of my head in any of my graph theory books, but my recollection is that in a random graph (which is approximately what we've got here), average pairwise path lengths increase as the graph gets larger, unless the average degree of the graph (i.e. average number of links to a node) goes up. This means that there are, indeed, places that are "far away", since you can always redraw the graph with the "viewpoint" at the center, and the further-away stuff on the outside. There's a second-order effect here, since the network is not a truly random graph. Such non-random graphs have a measure I have called "separation", which does influence average path length. However, it's still the case that you can construct abstraction hierarchies for such a graph. This is easy enough to see in planar graphs; if you're on one side of a big sheet of paper, you can draw a circle around stuff on the other side which is "far away". It's harder to visualize for non-planar graphs, since you have to visualize a 3D representation of the graph, but you can visualize wrapping "surfaces" around "subspaces" of the graph for that one, instead of "boundaries" around "areas". > Although X.* have been "aggressive aggregated" into X, you still can get > "more routes" (and the better routes that result) by control of the > scope over which those individual pieces are advertised. So if I end up advertising the routes in to different portions of the provider anyway, I've eliminated a bunch of the benefits that I was promised, i.e. reduction in the number of advertised routes. You really should try drawing some pictures, so you'd understand this stuff without wasting everyone's time. An AAB for an area X, which is less than the size of the enclosing ANB (the global scope, if there is no enclosing ANB) will still give substantially better selection of entry points into X, and thus more optimal routes overall, than an AAB for X which is set to be the same as the ANB of X, and at far less routing overhead (i.e. outside X and inside the enclosing ANB). If you didn't understand what that said, you should be listening more, and talking less. Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 07:16:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16669; Mon, 11 Sep 1995 07:16:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA26640; Mon, 11 Sep 1995 07:16:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA26631; Mon, 11 Sep 1995 07:15:20 +1000 Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16637; Mon, 11 Sep 1995 07:15:12 +1000 (from barney@databus.databus.com) Date: Sun, 10 Sep 95 17:15 EDT Message-Id: <9509101715.AA20375@databus.databus.com> From: Barney Wolff To: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message Content-Length: 1034 Content-Type: text Precedence: bulk > Date: Sun, 10 Sep 1995 12:38:00 -0400 > From: "Perry E. Metzger" > > > Folks, Noel's point, which some seem unwilling or unable to grasp, is > > that neither BGP4 nor OSPF have been parallelized. Until that's done, > > you can run them on a million-processor machine with no gain in speed. > > These algorithms are all highly parellelizable. I don't think that its > even much of a challenge. > > > The voice of experience says that it will not be trivial, nor > > outstandingly effective, to parallelize route computation. > > Huh? > > Most of these things come down to graph processing algorithms, almost > all of which parallelize very nicely. Glad to hear that your Parallel-GateD-95 is going into beta. Think you'll get it widely adopted before the core routers fall over? If you really want to be a hero, work out a mechanism to get the fees for advertising routes funneled to router development. I suppose we could always send a grant application to NSF ... Barney Wolff From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 07:19:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16700; Mon, 11 Sep 1995 07:19:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA26660; Mon, 11 Sep 1995 07:18:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA26554; Mon, 11 Sep 1995 07:00:10 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16287; Mon, 11 Sep 1995 07:00:04 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id QAA05516; Sun, 10 Sep 1995 16:59:49 -0400 Date: Sun, 10 Sep 1995 16:59:48 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Jason Marshall Cc: Nathan Stratton , big-internet@munnari.OZ.AU, spots@spots.ab.ca Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Jason Marshall wrote: > > It would not work as the customer will just go to another NSP willing to > > do the routing for less money. If they all refuse or charge the same fees, > > the customer sues them all for collusion. > > If the customer is offered a new set of addresses for 'free' and he > refuses them, or is unable to accept them for business reasons, then they > have no ground to stand on in court if the/any NSP decides to charge them > for the privelege (NOT THE RIGHT) of having their old route advertised. > I only said if the charge the SAME fee. If the fee is different and not "price fixed", it does not matter. I also never said that the customer will win or collect anything. Why do you thing legal tort reform is so popular with businesses in the US? The cost of fighting even a frivilous lawsuit is high. In the current system people have actually collected a few hundred thousand dollars because McDonalds served them coffee that was too hot and they spilled it on themselves. Do you think upper level management at an NSP will take the chance of loosing a suit like this and possible criminal anti-trust prosecution? That said, I still believe that charging a high enough route advertising fee so as to discourage frivilous growth but still allow those that absolutely need it is the only viable answer. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 07:36:36 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17227; Mon, 11 Sep 1995 07:36:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA26715; Mon, 11 Sep 1995 07:36:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA26691; Mon, 11 Sep 1995 07:23:24 +1000 Received: from eunet.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16842; Mon, 11 Sep 1995 07:23:13 +1000 (from bilse@EU.net) Received: from jotun.EU.net (jotun.EU.net [193.242.90.24]) by eunet.EU.net (8.6.10/8.6.10) with SMTP id XAA12262; Sun, 10 Sep 1995 23:23:10 +0200 Received: by jotun.EU.net id AA13020 (5.67a/IDA-1.5); Sun, 10 Sep 1995 23:23:09 +0200 Message-Id: <199509102123.AA13020@jotun.EU.net> From: Per Gregers Bilse Date: Sun, 10 Sep 1995 23:23:09 +0200 In-Reply-To: <199509102038.AA11676@linux.silkroad.com> Organization: EUnet Communications Services BV X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: Tim Bass Subject: Re: Topological vs. Administrative Aggregation Cc: big-internet@munnari.OZ.AU Precedence: bulk On Sep 10, 16:38, Tim Bass wrote: > My question then is.... what is considered 'demonstration of viable > alternatives' to paraphrase. Can be developed and deployed before we have a really serious problem on our hands. > It does appear that some very good alternatives have been presented > years ago and the ideas are resurfacing from new observers and players. > These well doumented ideas seemed very viable in 1993 and were > somehow judged, too slow? Too complex? You have to look back into history to find out. There has never been a lack of ideas, but this is irrelevant -- ideas have no value if they are not implemented and deployed. Much like recipes don't generate food. > What is wrong with moving forward the ideas of AD and policy based > interdomain routing? Absolutely nothing, provided you are talking about future, experimental developments. Or you can demonstrate that this will eliminate the impending problem before it's too late. -- ====== ___ === Per G. Bilse, Mgr Network Operations Ctr ===== / / / __ ___ _/_ ==== EUnet Communications Services B.V. ==== /--- / / / / /__/ / ===== Singel 540, 1017 AZ Amsterdam, NL === /___ /__/ / / /__ / ====== tel: +31 20 6233803, fax: +31 20 6224657 === ======= 24hr emergency number: +31 20 421 0865 === Connecting Europe since 1982 === http://www.EU.net; e-mail: bilse@EU.net From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 07:56:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17840; Mon, 11 Sep 1995 07:56:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA26778; Mon, 11 Sep 1995 07:56:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA26743; Mon, 11 Sep 1995 07:38:08 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17272; Mon, 11 Sep 1995 07:38:01 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00832; Sun, 10 Sep 95 16:43:15 -0400 Date: Sun, 10 Sep 95 16:43:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509102043.AA00832@ginger.lcs.mit.edu> To: gherbert@crl.com, jnc@ginger.lcs.mit.edu Subject: Re: Size of routers Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu, perry@piermont.com Precedence: bulk From: George Herbert We have a number of problems facing us ... There is obviously not going to be a single panacea for all of them. Throwing more hardware at the problem can solve a number of these, but not all. Yes, and what some of us keep trying to explain (to those of you who don't have the time, energy, inclination, etc to actually go study routing theory and read all those papers like K+K, etc, etc, etc) is that the best solution to a lot of them is to reduce the routing table size by deploying a topologically based addressing hierarchy. If anyone wants to argue about it, fine, but they'd better be prepared to put in the work thinking, and studying the field first, so they know what they are talking about. I don't mind debating, but I hate wasting everyone's time while some clueless newbie gets up to speed on elementary stuff. Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 07:58:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB17873; Mon, 11 Sep 1995 07:58:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA26803; Mon, 11 Sep 1995 07:57:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA26729; Mon, 11 Sep 1995 07:37:03 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17238; Mon, 11 Sep 1995 07:36:57 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA13530 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Sun, 10 Sep 1995 17:36:45 -0400 From: Tim Bass Message-Id: <199509102136.AA13530@linux.silkroad.com> Subject: Re: Topological vs. Administrative Aggregation To: bilse@eu.net (Per Gregers Bilse) Date: Sun, 10 Sep 1995 17:36:45 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <199509102123.AA13020@jotun.EU.net> from "Per Gregers Bilse" at Sep 10, 95 11:23:09 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1513 Precedence: bulk > > You have to look back into history to find out. There has never been > a lack of ideas, but this is irrelevant -- ideas have no value if > they are not implemented and deployed. Much like recipes don't > generate food. Thanks, I like your analogy about recipes and food. Based on what I've read, my opinions are starting to mellow a little. I think I will take some time and read more historical documents as well as the Merit/ISI docs on their route server more carefully. Also, I think maybe I am beginning to get a better feeling on the problems of implementing recipes in the Internet. Complex recipes require numberous cooks with a lot of time (and money) on their hands. Given that most of the IETF work is volunteer engineering and funding is a problem (not to mention real paying jobs with families to care for) just keeping the net going is a remarkable task. Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 07:59:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17892; Mon, 11 Sep 1995 07:59:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA26828; Mon, 11 Sep 1995 07:59:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA26760; Mon, 11 Sep 1995 07:48:33 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17546; Mon, 11 Sep 1995 07:48:29 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id OAA15054; Sun, 10 Sep 1995 14:55:41 -0700 Date: Sun, 10 Sep 1995 14:55:40 -0700 (PDT) From: Michael Dillon To: Noel Chiappa Cc: gherbert@crl.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, perry@piermont.com Subject: Re: Size of routers In-Reply-To: <9509102043.AA00832@ginger.lcs.mit.edu> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Noel Chiappa wrote: > From: George Herbert > > We have a number of problems facing us ... There is obviously not going to > be a single panacea for all of them. Throwing more hardware at the > problem can solve a number of these, but not all. > > Yes, and what some of us keep trying to explain (to those of you who don't > have the time, energy, inclination, etc to actually go study routing theory > and read all those papers like K+K, etc, etc, etc) is that the best solution > to a lot of them is to reduce the routing table size by deploying a > topologically based addressing hierarchy. You are implying here that the solution to the problems of growth is to reduce routing table size and that the way to do this is to apply the lessons of routing theory. What you are forgetting is that not all people agree that reducing routing table size is the only solution. Furthermore, even when we do move towards implementing reductions in routing table size (either absolute or relative to growth) the problem is much larger than merely a problem in routing theory. The problem has legal aspects, marketing aspects, cost aspects, etc... If the people who are customers of NSP's refuse to accept topological addressing due to a perception that it is restraint of trade, then there will *NEVER* be topological addressing on the IPv4 Internet. Period. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 08:17:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18351; Mon, 11 Sep 1995 08:17:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA26879; Mon, 11 Sep 1995 08:16:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA26817; Mon, 11 Sep 1995 07:58:39 +1000 Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17880; Mon, 11 Sep 1995 07:58:35 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id RAA12416; Sun, 10 Sep 1995 17:58:23 -0400 Date: Sun, 10 Sep 1995 17:58:23 -0400 From: Vadim Antonov Message-Id: <199509102158.RAA12416@titan.sprintlink.net> To: michael@junction.net, tli@cisco.com Subject: Re: Distributed systems Cc: asp@uunet.uu.net, bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu, smd@cesium.clock.org Precedence: bulk >The route processor is supposed to stop this from happening by feeding >the SSP a subset of the full routing table. Yet another myth. The cache footprint for core routes is at about 40% of the full table. It may as well be that *not* doing cacheing will actually save memory in the forwarding tables (and would certainly make the whole design a lot more robust). The bugs in software seem to be in the top three reasons for the Internet's unrealiability. SL-MAE-E#sh ip ca IP routing cache 12686 entries, 1859004 bytes Minimum invalidation interval 2 seconds, maximum interval 5 seconds, quiet interval 3 seconds, threshold 0 requests Invalidation rate 0 in last second, 0 in last 3 second .... the rest skipped .... script done on Sun Sep 10 17:52:23 1995 --vadim From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 08:18:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18386; Mon, 11 Sep 1995 08:18:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA26899; Mon, 11 Sep 1995 08:17:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA26850; Mon, 11 Sep 1995 08:07:25 +1000 Received: from blob.best.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18100; Mon, 11 Sep 1995 08:07:16 +1000 (from jim@SmallWorks.COM) Received: from hosaka.smallworks.com (hosaka.SmallWorks.COM [192.207.126.1]) by blob.best.net (8.6.12/8.6.5) with SMTP id PAA17377 for ; Sun, 10 Sep 1995 15:07:13 -0700 Received: by hosaka.smallworks.com (5.x/SMI-SVR4) id AA06715; Sun, 10 Sep 1995 17:06:29 -0500 From: "Jim Thompson" Message-Id: <9509101706.ZM6713@hosaka.smallworks.com> Date: Sun, 10 Sep 1995 17:06:28 -0500 In-Reply-To: Michael Dillon "Re: oops -- wrong message" (Sep 9, 9:59pm) References: To: Michael Dillon , Bruce Sterling Woodcock Subject: Re: oops -- wrong message Cc: Tim Bass , jnc@ginger.lcs.mit.edu, bilse@eu.net, bass@cais.cais.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com X-Mailer: Z-Mail (3.2.0 06sep94) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Precedence: bulk On Sep 9, 9:59pm, Michael Dillon wrote: > You would be surprised at just how close to this point we are currently > with things like NetBSD. There are definitely people out there taking the > open source for a full UNIX system and stripping out functionality they > don't need, and modifying the parts they keep in order to build > special-purpose operating systems. Quick, anyone remember C-gateway? :-) > It's not up to Cisco or Bay. It's up to the customers. If NSP's feel that > it is to their benefit to run route processors on custom-tailored UNIX > boxes, then that's what will happen. Sun tried this for years on their internal network. It doesn't work. Sun is now (or has now, I haven't checked recently) deploying Wellfleet routers on its internal network. Its been done before kids. At one time I thought it was kinda neat, and a nice way to go. It doesn't work. Jim -- Jim Thompson jim@SmallWorks.COM From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 08:19:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18407; Mon, 11 Sep 1995 08:19:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA26926; Mon, 11 Sep 1995 08:19:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA26873; Mon, 11 Sep 1995 08:11:54 +1000 Received: from ftp.spots.ab.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18151; Mon, 11 Sep 1995 08:11:48 +1000 (from marshalj@spots.ab.ca) Received: from ftp.spots.ab.ca (ftp.spots.ab.ca [204.191.210.11]) by ftp.spots.ab.ca (8.6.11/8.6.12) with SMTP id PAA30523; Sun, 10 Sep 1995 15:15:57 -0700 Date: Sun, 10 Sep 1995 15:15:56 -0700 (MST) From: Jason Marshall To: Sanjay Kapur Cc: Nathan Stratton , big-internet@munnari.OZ.AU, spots@spots.ab.ca Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > > If the customer is offered a new set of addresses for 'free' and he > > refuses them, or is unable to accept them for business reasons, then they > > have no ground to stand on in court if the/any NSP decides to charge them > > for the privelege (NOT THE RIGHT) of having their old route advertised. > I only said if the charge the SAME fee. If the fee is different and not > "price fixed", it does not matter. You've apparently missed the point. It's not the NSP who would charge this fee. It would be this 'benign' organization, or watchdog organization I was referring to before. Therefore, it would be the same 'penalty' for anyone who decided to not obey the rules of the new renumbering. Hey, I never said it would work, but it DEFINATELY will never work if it's charged by the NSPs. You can't have competition where penalties are concerned. > I also never said that the customer will win or collect anything. Why do > you thing legal tort reform is so popular with businesses in the US? The Who knows? I'm no lawyer. All I know is you guys are always suing each other down there *8-) > people have actually collected a few hundred thousand dollars because > McDonalds served them coffee that was too hot and they spilled it on (see what I mean?) > themselves. Do you think upper level management at an NSP will take the > chance of loosing a suit like this and possible criminal anti-trust > prosecution? Yes, I think that if the choices are a) be a nice guy and watch as the Internet falls on its ass, and b) don't be so nice, but give everyone an equal opportunity to conform, and get a good lawyer if someone decides to sue you, then anyone with 1/2 a brain will choose the latter, if only because it postpones the collapse of his business (possibly indefinately). > That said, I still believe that charging a high enough route advertising > fee so as to discourage frivilous growth but still allow those that > absolutely need it is the only viable answer. With proper renumbering in place, and someone to discourage frivilous growth, life would be wonderful. With either (or both) of those components missing, we'll all be looking for work elsewhere in 2 years (optimistically). I disagree that EVERY route needs to be charged for, as the only reason to charge people is to reduce the growth that would no longer be a threat (an immediate one at least) after renumbering properly. But if that's what it takes to prevent frivilous growth, then so be it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jason Marshall, marshalj@spots.ab.ca. Spots InterConnect, Inc. Calgary, AB | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 08:36:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18861; Mon, 11 Sep 1995 08:36:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA26976; Mon, 11 Sep 1995 08:36:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA26936; Mon, 11 Sep 1995 08:19:43 +1000 Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18421; Mon, 11 Sep 1995 08:19:37 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id SAA12567; Sun, 10 Sep 1995 18:19:27 -0400 Date: Sun, 10 Sep 1995 18:19:27 -0400 From: Vadim Antonov Message-Id: <199509102219.SAA12567@titan.sprintlink.net> To: mn@ios.com, root@kbs.netusa.net Subject: Re: oops -- wrong message Cc: barney@databus.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com Precedence: bulk Sanjay Kapur wrote: >It becomes important in real time applications like video that NSPs want >to get into. I think NSPs should stick to using pure ATM (virtual >circuits?) for video type applications (real time, high bandwith, point >to point or point to multipoint) and not layer TCP/IP and routing on top of >ATM. Congratulations! You finally admitted that you're a lemming. ATM will fix everything magically. Sure, dude. Now take two seconds to compare route flap problems with per-prefix (as in IP) and per-connection (as in ATM) route announcements. --vadim PS By some estimates the number of TCP connections crossing the busiest Sprint's router simultaneously can be exceeding a million, and *that* grows superlinearly with the growth of the Internet. Whoever thinks that connection-oriented model will work with data even at the present scale is an imbecile. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 08:56:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19585; Mon, 11 Sep 1995 08:56:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA27039; Mon, 11 Sep 1995 08:56:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA27021; Mon, 11 Sep 1995 08:47:31 +1000 Received: from gatekeeper.zeitgeist.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19217; Mon, 11 Sep 1995 08:47:28 +1000 (from spector@gatekeeper.zeitgeist.com) Received: from zeitgeist.zeitgeist.com (zeitgeist.zeitgeist.com [192.124.49.10]) by gatekeeper.zeitgeist.com (8.6.12/8.6.9) with ESMTP id SAA16729; Sun, 10 Sep 1995 18:47:21 -0400 Received: from zeitgeist.com (localhost [127.0.0.1]) by zeitgeist.zeitgeist.com (8.6.10/8.6.9) with ESMTP id SAA00299; Sun, 10 Sep 1995 18:47:20 -0400 Message-Id: <199509102247.SAA00299@zeitgeist.zeitgeist.com> To: comp-priv@psi.com Cc: big-internet@munnari.OZ.AU Subject: Router discussion, multiple lists, etc Date: Sun, 10 Sep 1995 18:47:20 -0400 From: David HM Spector Precedence: bulk Folks, It should be tres obvious by now that this has spilled over waaaay to far into Com-Priv; we are probably boring the rest of the com-priv folks to tears... (I'm sure they want to get back to the discussions of the cost-benefit issues of Libertarianism .vs. everything eslse that were interrupted by this technical discussion :-) I am on both com-priv and the Big Internet list, and although I really love getting lots of mail, and especially two copies of things, would it be possible for folks to stop cross-posting this discussion..? thangsalot... _DHMS ------------------------------------------------------------------------- David HM Spector Software Developer & Nice Guy Zeitgeist Information Systems Spector@zeitgeist.com voice: +1 212.721.6974 fax: +1 212.721.9084 -------- SJM, 32, seeks SJF for meaningful rel... What? This ISN'T the VOICE personals?! From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 08:57:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19609; Mon, 11 Sep 1995 08:57:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA27061; Mon, 11 Sep 1995 08:57:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA27015; Mon, 11 Sep 1995 08:43:11 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19160; Mon, 11 Sep 1995 08:43:05 +1000 (from louie@uunet.uu.net) Received: from localhost by rodan.UU.NET with SMTP id QQzgqk24780; Sun, 10 Sep 1995 18:42:39 -0400 Message-Id: To: Michael Dillon Cc: Dave Siegel , Nathan Stratton , tli@cisco.com, perry@piermont.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, com-priv@lists.psi.com From: "Louis A. Mamakos" Subject: Re: Size of routers In-Reply-To: Your message of "Sun, 10 Sep 1995 13:15:17 PDT." Date: Sun, 10 Sep 1995 18:42:39 -0400 Sender: louie@uunet.uu.net Precedence: bulk > On Sun, 10 Sep 1995, Dave Siegel wrote: > > > > > Please feel free to purchase a 7500 and find out for yourself. > > > > > > Yes, but say we go out a get it, how long until we need the next cisco. > > > We just can't keep dumping money into hardware such a short life. > > > > How is this different then upgrading your P133 w/256 megs to a quad-piped > > 200MHz Alpha w/ 512Megs of RAM, to a 4 processor alpha, to a 20 processor > > Sun, to a ..... > > The P133/Alpha/Sun is a general purpose computer that has resale value > and potentially has other uses in your organization, thus it does not > need to be discarded in the same way that a high-end Cisco might. Ah, pardon me, but how much do I have to pay for a box like this which is as reliable as the RP in the Cisco router? I've spent considerable sums of money for dual-power supplies (-48VDC) for all my routers; do I have to settle for some desk-top box that won't run off the the DC power available in the POP? This is a very real consideration; we've spent a considerable time trying to select and qualify a Pentium-class box with -48V DC power supplies, RAID disk, serial console, etc. which we'll place in our POPs for more mundane purposes like NNTP feeds, etc. I'm not at all keen to have a box with $@&($%!! *moving* *parts* in such a critical application as the routing brain for a core backbone router. I'm not really happy that fans are required for this hardware; a disk drive is absolutely begging for trouble. Louis A. Mamakos, Manager of Network Engineering louie@uu.net, uunet!louie UUNET Technologies, Inc. Voice: +1 703 206 5823 3060 Williams Drive Fax: +1 703 206 5908 Fairfax, VA 22031 From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 09:18:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20382; Mon, 11 Sep 1995 09:18:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA27109; Mon, 11 Sep 1995 09:16:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA27088; Mon, 11 Sep 1995 09:09:34 +1000 Received: from netcom2.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19866; Mon, 11 Sep 1995 09:09:31 +1000 (from bsw@netcom.com) Received: by netcom2.netcom.com (8.6.12/Netcom) id QAA25662; Sun, 10 Sep 1995 16:06:17 -0700 From: bsw@netcom.com (Bruce Sterling Woodcock) Message-Id: <199509102306.QAA25662@netcom2.netcom.com> Subject: Re: Size of routers To: michael@junction.net (Michael Dillon) Date: Sun, 10 Sep 1995 16:06:17 -0700 (PDT) Cc: dsiegel@rtd.com, nathan@netrail.net, tli@cisco.com, perry@piermont.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: from "Michael Dillon" at Sep 10, 95 01:15:17 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 856 Precedence: bulk > > How is this different then upgrading your P133 w/256 megs to a quad-piped > > 200MHz Alpha w/ 512Megs of RAM, to a 4 processor alpha, to a 20 processor > > Sun, to a ..... > > The P133/Alpha/Sun is a general purpose computer that has resale value > and potentially has other uses in your organization, thus it does not > need to be discarded in the same way that a high-end Cisco might. Uhh... yeah right. Hey folks, Michael says some of you out there are looking to discard your high-end Ciscos. Give me a call; I'll take them off your hands. Bruce -- Bruce Sterling Woodcock --- Systems Administrator ][ sterling@netcom.com The views and opinions expressed in this message ][ sterling@netapp.com are not necessarily those of NETCOM nor of my ][ sterling@well.com current employer, Network Appliance Corporation. ][ sterling@egbt.org From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 09:56:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22042; Mon, 11 Sep 1995 09:56:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA27183; Mon, 11 Sep 1995 09:56:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA27166; Mon, 11 Sep 1995 09:49:13 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21660; Mon, 11 Sep 1995 09:49:04 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id TAA11529; Sun, 10 Sep 1995 19:47:23 -0400 Message-Id: <199509102347.TAA11529@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: "Michael F. Nittmann" Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Your message of "Sun, 10 Sep 1995 12:59:35 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 10 Sep 1995 19:47:22 -0400 From: "Perry E. Metzger" Precedence: bulk "Michael F. Nittmann" writes: > my worst ospf convergence time is still below 100ms. I don't care if it > would be 10 seconds. tcp can swallow 90 seconds without dropping > connections, so all web connections, email, ftp, telnet would still run. > tftp's would see some timeouts. Someday in the future your network is going to be used for carrying realtime telephony and video. People will notice ten second dropouts. As CPUs become faster and links give better and better information on outage, one would expect that routing could switch to alternate paths faster -- or, put better, one would hope that it would. Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 10:56:36 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24357; Mon, 11 Sep 1995 10:56:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA27261; Mon, 11 Sep 1995 10:56:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA27244; Mon, 11 Sep 1995 10:44:16 +1000 Received: from relay2.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23899; Mon, 11 Sep 1995 10:44:06 +1000 (from mn@tremere.ios.com) Received: from tremere.ios.com by relay2.UU.NET with ESMTP id QQzgqs22070; Sun, 10 Sep 1995 20:43:58 -0400 Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id UAA03769; Sun, 10 Sep 1995 20:40:55 -0400 Date: Sun, 10 Sep 1995 20:40:54 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: oops -- wrong message To: Dave Siegel Cc: big-internet@munnari.OZ.AU In-Reply-To: <199509101923.MAA12977@seagull.rtd.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Dave Siegel wrote: > > my worst ospf convergence time is still below 100ms. I don't care if it > > would be 10 seconds. tcp can swallow 90 seconds without dropping > > connections, so all web connections, email, ftp, telnet would still run. > > tftp's would see some timeouts. > > > > Really , processing speed isn't the point here. I prefer, btw., a slower > > route server. Keeps oscillating serial links out. > > Not necessarily...it might just be behind the ball. It'll catch, but not > calculate the down, process the down, recieve the new up oscillation, > send the down message to the router, process the up message. right, this is a sampling beat that results here. > > If you bump up the keepalive on the bgp session through the serial link, or > static null route the larger sbunet'd block for the serial IP's (for static'd > customers) you'll see little oscilation. If you can heavily CIDRize your > announcements, the effects of your network on outside networks will be small, > regardless of what's happening inside your core. > that's the goal of the game. Of course, to the outside the connection will sink at one of my routers. some don't like to admit that something is broken on their side and want to pull it down immediately at the meetpoint, so the the other's routers show !H. No? If it's a transcient, it is just some dropped packets. I hope to run new gated soon with dampening (oh yes, what else, if 24hr day is not enough I take the night too ...). And don't come , people, and call it 'advertizing lies'. A flapping link is DOWN because it is unusable for real traffic. Mike > Dave > > -- > Dave Siegel President, RTD Systems & Networking, Inc. > (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco > dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, > http://www.rtd.com/ for an ISP." > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 11:17:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25162; Mon, 11 Sep 1995 11:17:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA27299; Mon, 11 Sep 1995 11:16:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA27292; Mon, 11 Sep 1995 11:10:40 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24901; Mon, 11 Sep 1995 11:10:31 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id VAA11664; Sun, 10 Sep 1995 21:08:40 -0400 Message-Id: <199509110108.VAA11664@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: "Michael F. Nittmann" Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Your message of "Sun, 10 Sep 1995 21:05:31 EDT." Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Sun, 10 Sep 1995 21:08:39 -0400 From: "Perry E. Metzger" Precedence: bulk "Michael F. Nittmann" writes: > > > my worst ospf convergence time is still below 100ms. I don't care if it > > > would be 10 seconds. tcp can swallow 90 seconds without dropping > > > connections, so all web connections, email, ftp, telnet would still run. > > > tftp's would see some timeouts. > > > > Someday in the future your network is going to be used for carrying > > realtime telephony and video. People will notice ten second dropouts. > > Right. But this is now the same case: such realtime support cannot be > addressed by rerouting, which will always give a hit. The question is, how big a hit? If you lose a frame or two, no one cares. Ten seconds is, however, an eternity. I'll point out that we are not currently working very hard in the routing world to try to get re-routing to happen in faster and faster intervals. We should. Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 11:19:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25269; Mon, 11 Sep 1995 11:19:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA27321; Mon, 11 Sep 1995 11:19:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA27295; Mon, 11 Sep 1995 11:13:21 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24989; Mon, 11 Sep 1995 11:13:17 +1000 (from mn@tremere.ios.com) Received: from tremere.ios.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27425 Mon, 11 Sep 1995 11:06:17 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id VAA03791; Sun, 10 Sep 1995 21:05:32 -0400 Date: Sun, 10 Sep 1995 21:05:31 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: oops -- wrong message To: "Perry E. Metzger" Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509102347.TAA11529@frankenstein.piermont.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Perry E. Metzger wrote: > > "Michael F. Nittmann" writes: > > my worst ospf convergence time is still below 100ms. I don't care if it > > would be 10 seconds. tcp can swallow 90 seconds without dropping > > connections, so all web connections, email, ftp, telnet would still run. > > tftp's would see some timeouts. > > Someday in the future your network is going to be used for carrying > realtime telephony and video. People will notice ten second dropouts. Right. But this is now the same case: such realtime support cannot be addressed by rerouting, which will always give a hit. For full realtime realiable support there will also be a fully redundant network standing by. And we have the same nearly every evening in newscasts when the link is not there. Never saw a CNN guy waiting for a picture that did not come up? Current OSPF would get it faster. Satellite uplinks cannot reroute easily. Phone rerouting is not instantaneous either. In 800 call rerouting, e.g., some calls are cut (not interrupted). Just, please, put this dumb Cisco HW discussion on the Cisco list. Mike > > As CPUs become faster and links give better and better information on > outage, one would expect that routing could switch to alternate paths > faster -- or, put better, one would hope that it would. > > Perry > ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 11:38:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26187; Mon, 11 Sep 1995 11:38:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA27364; Mon, 11 Sep 1995 11:36:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA27343; Mon, 11 Sep 1995 11:24:18 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25505; Mon, 11 Sep 1995 11:24:04 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id VAA06944; Sun, 10 Sep 1995 21:23:33 -0400 Date: Sun, 10 Sep 1995 21:23:33 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Jason Marshall Cc: Nathan Stratton , big-internet@munnari.OZ.AU, spots@spots.ab.ca Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Jason Marshall wrote: > > I disagree that EVERY route needs to be charged for, as the only reason > to charge people is to reduce the growth that would no longer be a threat > (an immediate one at least) after renumbering properly. But if that's > what it takes to prevent frivilous growth, then so be it. Only route prefixes need to be charged for. If a route is within an NSP's block then the cost can be split among the possibly hundreds of customers that share that routing prefix. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 11:43:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26406; Mon, 11 Sep 1995 11:43:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA27397; Mon, 11 Sep 1995 11:41:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA27360; Mon, 11 Sep 1995 11:32:21 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25879; Mon, 11 Sep 1995 11:32:13 +1000 (from gherbert@crl.com) Received: from crl6.crl.com by mail.crl.com with SMTP id AA23908 (5.65c/IDA-1.5); Sun, 10 Sep 1995 18:28:03 -0700 Message-Id: <199509110128.AA23908@mail.crl.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: gherbert@crl.com, big-internet@munnari.OZ.AU Subject: Re: Size of routers In-Reply-To: Your message of "Sun, 10 Sep 1995 16:43:15 EDT." <9509102043.AA00832@ginger.lcs.mit.edu> Date: Sun, 10 Sep 1995 18:28:02 -0700 From: George Herbert Precedence: bulk [com-priv removed from cc: list] Noel writes: > From: George Herbert > > We have a number of problems facing us ... There is obviously not going to > be a single panacea for all of them. Throwing more hardware at the > problem can solve a number of these, but not all. > >Yes, and what some of us keep trying to explain (to those of you who don't >have the time, energy, inclination, etc to actually go study routing theory >and read all those papers like K+K, etc, etc, etc) is that the best solution >to a lot of them is to reduce the routing table size by deploying a >topologically based addressing hierarchy. > >If anyone wants to argue about it, fine, but they'd better be prepared to put >in the work thinking, and studying the field first, so they know what they are >talking about. I don't mind debating, but I hate wasting everyone's time while >some clueless newbie gets up to speed on elementary stuff. Some of us have, over the last few months, been spending a lot of time listening and looking at papers and books and such trying to get a better handle on theory and practice of routing and network design. The only conclusion I have come to so far is that there is nowhere near the impetus out there to start over from scratch and renumber the world into a new, topological addressing heirarchy. While that is a trivial example of how easy routing could be, it's not going to happen. It might happen with the next protocol, but not IPv4. I think continuing to insist that it's the holy grail which will save our hides is ignoring the operational considerations which currently are the fire under people's toes... This is not a scholarly debate on how networks can be done best from a clean slate. This is a discussion on what ways can work to go from where we are now to where we are going to be tomorrow and next week and next year. Junking everything and starting over again is out of the question. We can't ignore the existing problem. We can contain it (CIDR), we can hit it with more brute force (C7500, big-honking-router), we can sidestep it's bigger nastier brother (do topological addressing in IPv6), but we can't make current crisis simply go away. This is not a classroom, we are not being graded on ellegance. This is real life. -george william herbert gherbert@crl.com From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 12:19:06 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28071; Mon, 11 Sep 1995 12:19:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA27468; Mon, 11 Sep 1995 12:16:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA27459; Mon, 11 Sep 1995 12:12:01 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27684; Mon, 11 Sep 1995 12:11:51 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA21512 (5.65c/IDA-1.4.4 for big-internet@munnari.OZ.AU); Sun, 10 Sep 1995 22:11:02 -0400 From: Tim Bass Message-Id: <199509110211.AA21512@linux.silkroad.com> Subject: Re: Size of routers To: bsw@netcom.com (Bruce Sterling Woodcock) Date: Sun, 10 Sep 1995 22:11:02 -0400 (EDT) Cc: michael@junction.net, dsiegel@rtd.com, nathan@netrail.net, tli@cisco.com, perry@piermont.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509102306.QAA25662@netcom2.netcom.com> from "Bruce Sterling Woodcock" at Sep 10, 95 04:06:17 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1950 Precedence: bulk To summarize: 1) A new administrative domain aggregation paradigm with policy routing is just in the early development stages and is no where close to prime time networking; 2) CIDR and BGP4 may not be the most optimal aggregation paradigm but it is the "best current practice" we have available today; 3) De-coupling route processing and full forwarding tables from the switching function has considerable merit, and can ease hardware constraints but there is currently no reliable UNIX based route processing that also communicates with BB routers; furthermore there is some doubt if caching route forwarding tables gains anything significant; Did I miss anything? Tim +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 12:25:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28282; Mon, 11 Sep 1995 12:25:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA27491; Mon, 11 Sep 1995 12:22:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA27436; Mon, 11 Sep 1995 11:56:04 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27005; Mon, 11 Sep 1995 11:55:00 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id VAA07079; Sun, 10 Sep 1995 21:53:59 -0400 Date: Sun, 10 Sep 1995 21:53:59 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Vadim Antonov Cc: mn@ios.com, barney@databus.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: <199509102219.SAA12567@titan.sprintlink.net> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Vadim Antonov wrote: > Sanjay Kapur wrote: > >It becomes important in real time applications like video that NSPs want > >to get into. I think NSPs should stick to using pure ATM (virtual > >circuits?) for video type applications (real time, high bandwith, point > >to point or point to multipoint) and not layer TCP/IP and routing on top of > >ATM. > > Congratulations! You finally admitted that you're a lemming. Another name caller. I do not think you are an expert in anything except name calling. Are you friends with Mark Fuhrman? > > ATM will fix everything magically. Sure, dude. > For limited point to point communications. Not for general use. I agree that ATM will not work at all on a large scale. I have tried TCP/IP over ATM in a limited wide area trial and it just did not work right even there despite the best efforts of the telco and the hardware vendor. ATM has one thing going for it though: Guaranteed bandwith. This would be needed in any real time application and is not available in TCP/IP at this time. > Now take two seconds to compare route flap problems with per-prefix > (as in IP) and per-connection (as in ATM) route announcements. > We are talking two different worlds. ATM is for the people with lots of money to burn and who want high bandwith. It is not for the millions and never will be. ATM will need a separate, much smaller, network distinct from the Internet. I also agree with you that ATM is more hype than substance. > --vadim > > PS By some estimates the number of TCP connections crossing the > busiest Sprint's router simultaneously can be exceeding a million, > and *that* grows superlinearly with the growth of the Internet. > > Whoever thinks that connection-oriented model will work with data > even at the present scale is an imbecile. > Vadim, The following assumes that since you are posting from a Sprint address, you are still employed there and have not left that company as has been rumored. You are upset at me because I pointed out Sprint's inability to keep connections up and other serious problems that Sprint has in supporting its customers. Rather than answer that you call me an imbecile and a lemming. I now understand how Sprint treats its customers. This arrogance on the side of NSPs leads to extremely bad and unreliable service and is the lead cause for ISPs not trusting NSPs. The quoted post above from Vadim the Arrogant is a prime example of why I am totally opposed to forced renumbering. NSPs desperately need an attitude adjustment and forced renumbering will just make their attitude even worse. Sanjay Kapur Kapur Business Systems, Inc. P.S.: It is not directly relevant but I am curious: Does anyone know how many simultaneous non-local phone calls are in place at any time throughout the World. It would surely be a very large number. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 13:22:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01335; Mon, 11 Sep 1995 13:22:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA27580; Mon, 11 Sep 1995 13:16:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA27557; Mon, 11 Sep 1995 13:02:49 +1000 Received: from ftp.spots.ab.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00339; Mon, 11 Sep 1995 13:02:25 +1000 (from marshalj@spots.ab.ca) Received: from ftp.spots.ab.ca (ftp.spots.ab.ca [204.191.210.11]) by ftp.spots.ab.ca (8.6.11/8.6.12) with SMTP id UAA31406; Sun, 10 Sep 1995 20:06:30 -0700 Date: Sun, 10 Sep 1995 20:06:29 -0700 (MST) From: Jason Marshall To: Sanjay Kapur Cc: Nathan Stratton , big-internet@munnari.OZ.AU, spots@spots.ab.ca Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk > > I disagree that EVERY route needs to be charged for, as the only reason > > to charge people is to reduce the growth that would no longer be a threat > > (an immediate one at least) after renumbering properly. But if that's > > what it takes to prevent frivilous growth, then so be it. > > Only route prefixes need to be charged for. If a route is within an > NSP's block then the cost can be split among the possibly hundreds of > customers that share that routing prefix. Exactly. But if you have some customer who cannot renumber to use your address block, then you are going to have to advertise another route prefix specially for him if it doesn't fit in with your NSP's prefixes. Anyway, these details are becoming less and less relevant the deeper we get into them, so let's leave it where it is. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- | Jason Marshall, marshalj@spots.ab.ca. Spots InterConnect, Inc. Calgary, AB | =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 16:20:40 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10169; Mon, 11 Sep 1995 16:20:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA27790; Mon, 11 Sep 1995 16:16:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27754; Mon, 11 Sep 1995 16:03:31 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09410; Mon, 11 Sep 1995 16:03:17 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10004 Mon, 11 Sep 1995 15:58:28 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA20985; Sun, 10 Sep 1995 22:56:16 -0700 Date: Sun, 10 Sep 1995 22:56:16 -0700 From: Tony Li Message-Id: <199509110556.WAA20985@greatdane.cisco.com> To: perry@piermont.com Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509101740.NAA11303@frankenstein.piermont.com> (perry@piermont.com) Subject: Re: Size of routers... Precedence: bulk The theory being that DEC, HP and Sun are better at building scalable Unix boxes with lots of flexibility than Cisco, which seems to have too small a volume to keep the CPUs in their boxes hot. If you think that the 7500 isn't hot, you've obviously been nowhere near one. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 16:23:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10374; Mon, 11 Sep 1995 16:23:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA27820; Mon, 11 Sep 1995 16:19:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27786; Mon, 11 Sep 1995 16:13:17 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09839; Mon, 11 Sep 1995 16:12:57 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id CAA13288; Mon, 11 Sep 1995 02:09:39 -0400 Message-Id: <199509110609.CAA13288@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: Tony Li Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers... In-Reply-To: Your message of "Sun, 10 Sep 1995 22:56:16 PDT." <199509110556.WAA20985@greatdane.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Sep 1995 02:09:39 -0400 From: "Perry E. Metzger" Precedence: bulk Tony Li writes: > > The theory being that DEC, HP and Sun are better at building scalable > Unix boxes with lots of flexibility than Cisco, which seems to have > too small a volume to keep the CPUs in their boxes hot. > > If you think that the 7500 isn't hot, you've obviously been nowhere > near one. Thank you for the advertising promotional, Tony, but lets face facts -- for years you sold a box witha a 25Mhz '040 in it. The ink is barely dry on the ads for the 7500. Who knows how long it will be until another upgrade to your CPU? Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 16:26:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10541; Mon, 11 Sep 1995 16:26:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA27842; Mon, 11 Sep 1995 16:22:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27772; Mon, 11 Sep 1995 16:09:55 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09540; Mon, 11 Sep 1995 16:07:40 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA21198; Sun, 10 Sep 1995 23:02:40 -0700 Date: Sun, 10 Sep 1995 23:02:40 -0700 From: Tony Li Message-Id: <199509110602.XAA21198@greatdane.cisco.com> To: perry@piermont.com Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509110559.BAA12004@frankenstein.piermont.com> (perry@piermont.com) Subject: Re: Size of routers Precedence: bulk Ignoring the question of caching forwarding tables (which I think is of limited utility given how big the caches get), I think that building routers out of stock hardware to do routing protocols tightly coupled to custom hardware to do the packet switching is far more likely to yield designs that can be easily upgraded to the hottest extant processors than the current methodology of building fully custom computers. Oh, so you like our design? ;-) A standard unix box that handles the BGP portion of the routing problem and downloads full routing tables into a custom switch processor via a PCI bus or S-Bus or whateverbus interface has the distinct advantage that you can keep replacing the unix box with better faster ones that have a mass market. And cisco can keep producing new boards that have later chips on them too. So what? You're still up against Moore's law. Fix the strategy. Then we will build the right hardware. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 16:30:28 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10698; Mon, 11 Sep 1995 16:30:28 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA27876; Mon, 11 Sep 1995 16:25:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27757; Mon, 11 Sep 1995 16:03:36 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09419; Mon, 11 Sep 1995 16:03:23 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id BAA12004; Mon, 11 Sep 1995 01:59:01 -0400 Message-Id: <199509110559.BAA12004@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: Tony Li Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers In-Reply-To: Your message of "Sun, 10 Sep 1995 22:43:34 PDT." <199509110543.WAA20632@greatdane.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Sep 1995 01:58:57 -0400 From: "Perry E. Metzger" Precedence: bulk Ignoring the question of caching forwarding tables (which I think is of limited utility given how big the caches get), I think that building routers out of stock hardware to do routing protocols tightly coupled to custom hardware to do the packet switching is far more likely to yield designs that can be easily upgraded to the hottest extant processors than the current methodology of building fully custom computers. A standard unix box that handles the BGP portion of the routing problem and downloads full routing tables into a custom switch processor via a PCI bus or S-Bus or whateverbus interface has the distinct advantage that you can keep replacing the unix box with better faster ones that have a mass market. At the very least, such a design would have avoided the "joke processor you wouldn't put in a video game running BGP-4 in a router that costs the same as a Rolls Royce" problem that the Cisco 7000 had. Perry Tony Li writes: > 3) De-coupling route processing and full forwarding tables from the > switching function has considerable merit, and can ease hardware > constraints but there is currently no reliable UNIX based > route processing that also communicates with BB routers; furthermore > there is some doubt if caching route forwarding tables gains > anything significant; > > Did I miss anything? > > You miss the fact that the current cisco routers also cache routes. > And that the resulting behavior is NOT appreciated by customers. > Increasing the delay of a route-fault by a couple of orders of > magnitude is not likely to improve this situation or the operator's > attitudes. > > Tony > From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 16:34:37 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB10983; Mon, 11 Sep 1995 16:34:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10186 Mon, 11 Sep 1995 16:01:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA27744; Mon, 11 Sep 1995 15:56:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA27729; Mon, 11 Sep 1995 15:46:24 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08674; Mon, 11 Sep 1995 15:46:08 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id WAA20632; Sun, 10 Sep 1995 22:43:34 -0700 Date: Sun, 10 Sep 1995 22:43:34 -0700 From: Tony Li Message-Id: <199509110543.WAA20632@greatdane.cisco.com> To: bass@linux.silkroad.com Cc: bsw@netcom.com, michael@junction.net, dsiegel@rtd.com, nathan@netrail.net, tli@cisco.com, perry@piermont.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509110211.AA21512@linux.silkroad.com> (message from Tim Bass on Sun, 10 Sep 1995 22:11:02 -0400 (EDT)) Subject: Re: Size of routers Precedence: bulk 3) De-coupling route processing and full forwarding tables from the switching function has considerable merit, and can ease hardware constraints but there is currently no reliable UNIX based route processing that also communicates with BB routers; furthermore there is some doubt if caching route forwarding tables gains anything significant; Did I miss anything? You miss the fact that the current cisco routers also cache routes. And that the resulting behavior is NOT appreciated by customers. Increasing the delay of a route-fault by a couple of orders of magnitude is not likely to improve this situation or the operator's attitudes. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 16:39:08 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11144; Mon, 11 Sep 1995 16:39:08 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA27911; Mon, 11 Sep 1995 16:36:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27898; Mon, 11 Sep 1995 16:30:46 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10704; Mon, 11 Sep 1995 16:30:32 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA21661; Sun, 10 Sep 1995 23:28:29 -0700 Date: Sun, 10 Sep 1995 23:28:29 -0700 From: Tony Li Message-Id: <199509110628.XAA21661@greatdane.cisco.com> To: nathan@netrail.net Cc: root@kbs.netusa.net, asp@uunet.uu.net, dorian@cic.net, SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU In-Reply-To: (message from Nathan Stratton on Sun, 10 Sep 1995 09:13:15 -0400 (EDT)) Subject: Re: Routing tables & what to do about them Precedence: bulk > > Tried that. Didn't work. Next? > > Can't the InterNIC force people to renumber? > > Just in case you're not joking, no, the InterNIC can't "force" people > to do anything. Why not? When you get a block form the NIC they say it is a lease. So why can't they take blocks back. "No, you can't have them." "Take them and I'll sue." You have to at least give them a written policy to work from. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 16:42:25 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11257; Mon, 11 Sep 1995 16:42:25 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA27947; Mon, 11 Sep 1995 16:40:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27804; Mon, 11 Sep 1995 16:18:51 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10028; Mon, 11 Sep 1995 16:18:01 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10685 Mon, 11 Sep 1995 16:16:16 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA21373; Sun, 10 Sep 1995 23:13:10 -0700 Date: Sun, 10 Sep 1995 23:13:10 -0700 From: Tony Li Message-Id: <199509110613.XAA21373@greatdane.cisco.com> To: perry@piermont.com Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509110609.CAA13288@frankenstein.piermont.com> (perry@piermont.com) Subject: Re: Size of routers... Precedence: bulk > If you think that the 7500 isn't hot, you've obviously been nowhere > near one. Thank you for the advertising promotional, Tony, Someday, when you get a sense of humor installed, you'll realize that was a joke. but lets face facts -- for years you sold a box witha a 25Mhz '040 in it. The ink is barely dry on the ads for the 7500. Who knows how long it will be until another upgrade to your CPU? I know. But of course, I can't tell you, and since I'm an Evil Conspirator, you wouldn't believe me anyhow.... Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 16:45:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11504; Mon, 11 Sep 1995 16:45:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA27972; Mon, 11 Sep 1995 16:43:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27907; Mon, 11 Sep 1995 16:34:19 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10932; Mon, 11 Sep 1995 16:33:51 +1000 (from perry@frankenstein.piermont.com) Received: from frankenstein.piermont.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10699 Mon, 11 Sep 1995 16:16:23 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id CAA13299; Mon, 11 Sep 1995 02:13:39 -0400 Message-Id: <199509110613.CAA13299@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: Tony Li Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers In-Reply-To: Your message of "Sun, 10 Sep 1995 23:02:40 PDT." <199509110602.XAA21198@greatdane.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Sep 1995 02:13:38 -0400 From: "Perry E. Metzger" Precedence: bulk Tony Li writes: > A standard unix box that handles the BGP portion of > the routing problem and downloads full routing tables into a custom > switch processor via a PCI bus or S-Bus or whateverbus interface has > the distinct advantage that you can keep replacing the unix box with > better faster ones that have a mass market. > > And cisco can keep producing new boards that have later chips on them > too. You *could*, but you haven't done so in the past. For how many years did you sell 25Mhz '040s in your top of the line routers? Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 16:50:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11618; Mon, 11 Sep 1995 16:50:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA27996; Mon, 11 Sep 1995 16:47:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27811; Mon, 11 Sep 1995 16:19:36 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10087; Mon, 11 Sep 1995 16:18:51 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by shark.mel.dit.csiro.au with SMTP id AA06752 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 11 Sep 1995 16:15:19 +1000 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA21315; Sun, 10 Sep 1995 23:09:59 -0700 Date: Sun, 10 Sep 1995 23:09:59 -0700 From: Tony Li Message-Id: <199509110609.XAA21315@greatdane.cisco.com> To: perry@piermont.com Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, inet-access@earth.com In-Reply-To: <199509101736.NAA11292@frankenstein.piermont.com> (perry@piermont.com) Subject: Re: Size of routers Precedence: bulk I'll point out as an aside that it is clear that the exponential growth will continue only for a limited period. The net is going to follow an S-curve just like fax machines, telephones, and everything else. We only have to survive for ten years, not forever. It might not be unreasonable to simply throw hardware at the problem for a while. Very reasonable question. If you look at Frank Solensky's logistic curves on the growth of the net, you'll find that we have a problem tho: things don't flatten out for at least a decade. And, as you probably know, predicting logistic curves while you're in the very early part of the 'S' is extremely tricky. The knee of the curve isn't always apparent. I want to emphasize that I am not arguing that we shouldn't do things like CIDR to reduce the frivolous growth of the routing tables -- things like routes to single-connected networks of ten machines in an office somewhere. What I am trying to say, along with others, however, is that it isn't going to fix the bigger problem. What do you think the bigger problem is? Seems to me that if we can control the frivolous growth of the routing tables, then we can get on with making things more _stable_, refined, and faster. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 16:53:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11738; Mon, 11 Sep 1995 16:53:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA28018; Mon, 11 Sep 1995 16:50:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27852; Mon, 11 Sep 1995 16:23:53 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB10375; Mon, 11 Sep 1995 16:23:08 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA21519; Sun, 10 Sep 1995 23:21:17 -0700 Date: Sun, 10 Sep 1995 23:21:17 -0700 From: Tony Li Message-Id: <199509110621.XAA21519@greatdane.cisco.com> To: perry@piermont.com Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509101730.NAA11283@frankenstein.piermont.com> (perry@piermont.com) Subject: Re: Size of routers Precedence: bulk Okay, lets also look at the FACTS. That "70MIPS processor" on the interface isn't a generic processor. It cannot run, say, BGP. Bullshit. It certainly could. Recall something called "Turing equivalent"? Admittedly programming it would be a bitch. See earlier points about paralleling BGP in the first place. In an era where you could buy very nice much higher performance RISC workstations, as I recall. I also remember that being many generations of RISC workstation ago. It was even more generations of random Intel processor ago. Your memory is faulty. The Sparc 2 was JUST coming out. RISC processors were extremely expensive for low volume applications. As to Intel procesors, I suppose you LIKE hurting yourself with byte ordering problems. Well, actually, I seriously wonder why the hell you guys make your own main CPU at all. You need to make your own switch processors, but it would seem to make more sense for you to be buying someone else's CPU board and interfacing it to the rest of the box via the system bus so you can toss the thing out every six months in favor of the fastest thing available. Well, you might look harder. We take other people's CPUs, and weld them onto our bus. You might note the infamous legend of the CSC/1 being the same as the original Sun-1 CPU. The CSC/4 is the _same_ basic design, turned to accept an EC040. Turning the board every six months simply isn't required. It's not a win for our customers. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 17:22:24 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12999; Mon, 11 Sep 1995 17:22:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA28111; Mon, 11 Sep 1995 17:18:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA28088; Mon, 11 Sep 1995 17:07:56 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12339; Mon, 11 Sep 1995 17:07:37 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id AAA22623; Mon, 11 Sep 1995 00:03:49 -0700 Date: Mon, 11 Sep 1995 00:03:49 -0700 From: Tony Li Message-Id: <199509110703.AAA22623@greatdane.cisco.com> To: perry@piermont.com Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, inet-access@earth.com In-Reply-To: <199509110654.CAA13364@frankenstein.piermont.com> (perry@piermont.com) Subject: Re: Size of routers Precedence: bulk I see no real evidence that the transcontinental links are going to go above OC12 any time soon. Hee hee. You DO have a sense of humor. I also don't see much evidence of technologies that can switch packets at above OC12. Hee hee hee. Hint: how fast do you have to switch to do OC12? Consider average Internet packet sizes. Thats less than one order of magnitude growth from where we are now. I *do* see lots of evidence that the end users are about to go up two orders of magnitude growth or more very, very fast. This is where the problem lies. Correct. Put More Fiber In Your Diet. ;-) I fully expect the second. I'm not sure the first is going to be able to keep up. The problem is pent-up demand. People have been stuck behind bad 50 year old copper pairs for a long time even as much, much better stuff has matured. Well, I can't say that I completely disagree. However, I see little point in arguing about this. It's certainly not going to get solved here... Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 17:27:47 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13213; Mon, 11 Sep 1995 17:27:47 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA28149; Mon, 11 Sep 1995 17:24:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27925; Mon, 11 Sep 1995 16:39:35 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11145; Mon, 11 Sep 1995 16:39:09 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id CAA13336; Mon, 11 Sep 1995 02:38:21 -0400 Message-Id: <199509110638.CAA13336@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: Tony Li Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers In-Reply-To: Your message of "Sun, 10 Sep 1995 23:21:17 PDT." <199509110621.XAA21519@greatdane.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Sep 1995 02:38:20 -0400 From: "Perry E. Metzger" Precedence: bulk Tony Li writes: > > Okay, lets also look at the FACTS. That "70MIPS processor" on the > interface isn't a generic processor. It cannot run, say, BGP. > > Bullshit. It certainly could. Recall something called "Turing > equivalent"? Admittedly programming it would be a bitch. See earlier > points about paralleling BGP in the first place. Fine, Tony. Show me the Cisco 7000 with one of the interface processors running BGP. We are talking about your real product here, not something theoretical. Your real product ran routing on a really slow processor. Luckily you have no real competitors in that market. BTW, I *like* Ciscos. The CPU in the 7000 was a joke, though. > In an era where you could buy very nice much higher performance RISC > workstations, as I recall. I also remember that being many generations > of RISC workstation ago. It was even more generations of random Intel > processor ago. > > Your memory is faulty. The Sparc 2 was JUST coming out. And it was much higher performance than a 25Mhz '040. And that was indeed many generations of RISC ago -- you only came out with your own RISC high-end router a week or two ago. What, exactly, is faulty about my memory? > Well, actually, I seriously wonder why the hell you guys make your own > main CPU at all. You need to make your own switch processors, but it > would seem to make more sense for you to be buying someone else's CPU > board and interfacing it to the rest of the box via the system bus so > you can toss the thing out every six months in favor of the fastest > thing available. > > Well, you might look harder. We take other people's CPUs, and weld > them onto our bus. Thats different from plopping an Alpha or Sparc workstation inside your router and just having it talk to the switch via a card on its normal bus. Its the difference between the low cost/ high performance of stock hardware, and what you guys do with your fully custom stuff. > Turning the board every six months simply isn't required. It's not > a win for our customers. Using a 25Mhz '040 for running BGP-4 was a huge win for your customers up until now? Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 17:36:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13637; Mon, 11 Sep 1995 17:36:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA28059; Mon, 11 Sep 1995 16:59:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27949; Mon, 11 Sep 1995 16:40:54 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11232; Mon, 11 Sep 1995 16:40:50 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id XAA21874; Sun, 10 Sep 1995 23:39:36 -0700 Date: Sun, 10 Sep 1995 23:39:36 -0700 From: Tony Li Message-Id: <199509110639.XAA21874@greatdane.cisco.com> To: perry@piermont.com Cc: big-internet@munnari.oz.au, com-priv@lists.psi.com, inet-access@earth.com In-Reply-To: <199509110629.CAA13317@frankenstein.piermont.com> (perry@piermont.com) Subject: Re: Size of routers Precedence: bulk We have to prevent ourselves from constructing network choke points by producing a "treework" instead of a network. [Long explanation mostly elided...] ... our exchange points get to use nice exotic technologies like FDDI that run faster than even our transcontinental links. Minor quibble: FDDI is hardly exotic at this point and the transcontinental links are now T3 (90Mbps) in migration to OC-3 (300Mbps). The ratio of the fastest available commercial high speed interconnect technology to the speed of the average end user link is going to fall radically in coming years. Not if we can help it. For obvious engineering reasons, you get choke points if your traffic funnel isn't substantially higher than your end station access. Expect to see rapid growth in bandwidth and switching rates. Expect to see the number of exchange points proliferate. As all this starts to happen, we are either going to have to route in a much more densely interconnected net with a lot flatter "top" to the global routing pyramid -- i.e. far more exchange points and a lot more advertisements to keep the routes efficient -- or we are going to end up with choke points instead of exchange points. This is the crisis that I am anticipating. And it's not clear that this doesn't devolve pretty quickly into topological assignment with proxy aggregation for routing efficiency. Frivolous growth in the routing tables I will happily agree should be controlled. My problem is that I'm not sure all the growth is going to be frivolous. Well, no one is suggesting that things will not grow some. Just no faster than Moore's law, please.... Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 17:43:40 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14039; Mon, 11 Sep 1995 17:43:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA14312 Mon, 11 Sep 1995 17:42:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA28187; Mon, 11 Sep 1995 17:37:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA28131; Mon, 11 Sep 1995 17:21:42 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12934; Mon, 11 Sep 1995 17:20:41 +1000 (from perry@frankenstein.piermont.com) Received: from frankenstein.piermont.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12357 Mon, 11 Sep 1995 16:55:52 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id CAA13364; Mon, 11 Sep 1995 02:54:22 -0400 Message-Id: <199509110654.CAA13364@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: Tony Li Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, inet-access@earth.com Subject: Re: Size of routers In-Reply-To: Your message of "Sun, 10 Sep 1995 23:39:36 PDT." <199509110639.XAA21874@greatdane.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Sep 1995 02:54:21 -0400 From: "Perry E. Metzger" Precedence: bulk Tony Li writes: > The ratio of the fastest available commercial high speed interconnect > technology to the speed of the average end user link is going to fall > radically in coming years. > > Not if we can help it. I see no real evidence that the transcontinental links are going to go above OC12 any time soon. I also don't see much evidence of technologies that can switch packets at above OC12. Thats less than one order of magnitude growth from where we are now. I *do* see lots of evidence that the end users are about to go up two orders of magnitude growth or more very, very fast. This is where the problem lies. > For obvious engineering reasons, you get choke points if your > traffic funnel isn't substantially higher than your end station > access. Expect to see rapid growth in bandwidth and switching > rates. Expect to see the number of exchange points proliferate. I fully expect the second. I'm not sure the first is going to be able to keep up. The problem is pent-up demand. People have been stuck behind bad 50 year old copper pairs for a long time even as much, much better stuff has matured. Perry ing fees is not delivering what I'm being required to pay for. From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 17:49:16 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14233; Mon, 11 Sep 1995 17:49:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA28067; Mon, 11 Sep 1995 17:00:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA27901; Mon, 11 Sep 1995 16:31:23 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10729; Mon, 11 Sep 1995 16:30:57 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id CAA13317; Mon, 11 Sep 1995 02:29:21 -0400 Message-Id: <199509110629.CAA13317@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: Tony Li Cc: big-internet@munnari.oz.au, com-priv@lists.psi.com, inet-access@earth.com Subject: Re: Size of routers In-Reply-To: Your message of "Sun, 10 Sep 1995 23:09:59 PDT." <199509110609.XAA21315@greatdane.cisco.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Sep 1995 02:29:20 -0400 From: "Perry E. Metzger" Precedence: bulk Tony Li writes: > I want to emphasize that I am not arguing that we shouldn't do things > like CIDR to reduce the frivolous growth of the routing tables -- > things like routes to single-connected networks of ten machines in an > office somewhere. What I am trying to say, along with others, however, > is that it isn't going to fix the bigger problem. > > What do you think the bigger problem is? We have to prevent ourselves from constructing network choke points by producing a "treework" instead of a network. Exchange points are of critical importance because there is almost no locality of reference in the internet. Once you cross your corporate gateway, you are no more likely to talk to someone on your provider than you are to talk to someone off it. Exchange points end up carrying virtually all inter-entity traffic. Right now, we are spoiled. End users come in to the net at nice low speeds -- T1 being the fastest thats common, 56k being very usual, and many small users even coming in at 28.8k and less -- and our exchange points get to use nice exotic technologies like FDDI that run faster than even our transcontinental links. The ratio of the fastest available commercial high speed interconnect technology to the speed of the average end user link is going to fall radically in coming years. It's true that the exotic technologies will go up in speed by an order of magnitude, but as cable companies and phone companies race to improve the connections to the end users they are going to leap a whole generation in speed. Commercial users in large cities are also going to start getting far more choices in carrier diversity -- in places like NYC it is likely that you will have four or five different phone companies willing to give you connectivitity to your provider, so going by diverse paths to diverse providers may become very common even for fairly small businesses. As all this starts to happen, we are either going to have to route in a much more densely interconnected net with a lot flatter "top" to the global routing pyramid -- i.e. far more exchange points and a lot more advertisements to keep the routes efficient -- or we are going to end up with choke points instead of exchange points. This is the crisis that I am anticipating. > Seems to me that if we can control the frivolous growth of the > routing tables, then we can get on with making things more _stable_, > refined, and faster. Frivolous growth in the routing tables I will happily agree should be controlled. My problem is that I'm not sure all the growth is going to be frivolous. Perry From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 18:03:39 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14903; Mon, 11 Sep 1995 18:03:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA28286; Mon, 11 Sep 1995 18:00:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA28241; Mon, 11 Sep 1995 17:54:33 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14497; Mon, 11 Sep 1995 17:54:01 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 11 Sep 1995 08:52:39 +0100 To: Sanjay Kapur Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Sun, 10 Sep 95 16:43:11 EDT." Date: Mon, 11 Sep 95 08:52:38 +0100 Message-Id: <954.810805958@cs.ucl.ac.uk> From: Jon Crowcroft Precedence: bulk >You may want to look up the definition of "monopoly". >By a monopoly I mean any single entity or group of entities acting >together that has a significant enough market share to effectively >control the industry it is in. you mean like cisco? jon p.s. BT has around 50% of the uk data market, though it does have around 98% of the uk POTS market... From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 18:39:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16679; Mon, 11 Sep 1995 18:39:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA28368; Mon, 11 Sep 1995 18:36:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA28332; Mon, 11 Sep 1995 18:18:06 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15581; Mon, 11 Sep 1995 18:16:54 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by shark.mel.dit.csiro.au with SMTP id AA08452 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 11 Sep 1995 18:13:55 +1000 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA29882; Mon, 11 Sep 1995 01:08:53 -0700 Date: Mon, 11 Sep 1995 01:08:53 -0700 From: Tony Li Message-Id: <199509110808.BAA29882@greatdane.cisco.com> To: perry@piermont.com ("Perry E. Metzger") Cc: amolitor@anubis.network.com (Andrew Molitor), big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message Precedence: bulk [Rerun time...] Pardon, but with Tony Li of Cisco and others bitching that the machines can't keep up with the BGP4 load, I'd say that the problem is most certainly at least partially weak CPUs. Please get my bitching right: "The routing table can and has doubled every 9-10 months. See RFC 1519, page 8. The routing table is stored in (a) memory. Processing the routing table requires CPU cycles. The aggregate bandwidth as seen at a backbone POP doubles every 18 months. Supporting bandwidth requires switching. The average packet size is roughly constant. Switching requires CPU cycles. Switching references the routing table (sometimes indirectly). Computing power doubles every 24 months. Memory sizes double roughly every 24 months, except they go up by factors of four (and no, that's not 48 months). No one claims that current routers are at the bleeding edge of computer technology today. The long term strategy is the problem." Got it? Good. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 18:45:30 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16895; Mon, 11 Sep 1995 18:45:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15248 Mon, 11 Sep 1995 18:02:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA28264; Mon, 11 Sep 1995 17:57:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA28232; Mon, 11 Sep 1995 17:46:21 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14121; Mon, 11 Sep 1995 17:45:49 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from bells.cs.ucl.ac.uk by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA14394 Mon, 11 Sep 1995 17:43:35 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 11 Sep 1995 08:40:11 +0100 To: Sanjay Kapur Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Sun, 10 Sep 95 12:50:36 EDT." Date: Mon, 11 Sep 95 08:40:07 +0100 Message-Id: <624.810805207@cs.ucl.ac.uk> From: Jon Crowcroft Precedence: bulk >On Sun, 10 Sep 1995, Jon Crowcroft wrote: >> >> a small company here managed to pursuade everyone to renumber last >> year, even though they will have to do it again in 5 years.... >> >> they are called BT >BT is also a government regulated monopoly. Case closed. wrong: BT is one of 17 (last tiem i looked) licensed telcos in the UK jon From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 18:59:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17498; Mon, 11 Sep 1995 18:59:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA28422; Mon, 11 Sep 1995 18:56:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA28407; Mon, 11 Sep 1995 18:52:32 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17160; Mon, 11 Sep 1995 18:52:28 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA16799 Mon, 11 Sep 1995 18:52:26 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id BAA00422; Mon, 11 Sep 1995 01:48:58 -0700 Date: Mon, 11 Sep 1995 01:48:58 -0700 From: Tony Li Message-Id: <199509110848.BAA00422@greatdane.cisco.com> To: mn@ios.com ("Michael F. Nittmann") Cc: Noel Chiappa , big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: Size of routers... Precedence: bulk What we should also discuss: how can we work together to straighten out traffic patterns: Example: inside, I can determine my own meds. outside, it is only possible for me to steer traffic by as path length. The result is as follows: I have peer A and peer B. I hear routes from peer A at meetpoint a, that I do not hear from peer B. Now, meetpoint b is for me the best exit for everything, and I want to have as much stuff going through it. Provider A sees my preference of meetpoint b, and the A traffic goes wiht the same path length indirectly through meetpoint b. Also for the stuff I only hear from A at meetpoint a. See the big byte circus? I don't quite follow you. Why is A seeing the same path length via meetpoint b? In any case, if you want more traffic to come directly from A, you can advertise more specifics to A using the no-export community. You can also try to convince A to configure internal preferances to prefer meetpoint A. And you can always increase your AS path length on the direction that you dislike. Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 19:19:31 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18320; Mon, 11 Sep 1995 19:19:31 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id TAA28471; Mon, 11 Sep 1995 19:16:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA28450; Mon, 11 Sep 1995 19:00:17 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17542; Mon, 11 Sep 1995 19:00:12 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id CAA00503; Mon, 11 Sep 1995 02:00:06 -0700 Date: Mon, 11 Sep 1995 02:00:06 -0700 From: Tony Li Message-Id: <199509110900.CAA00503@greatdane.cisco.com> To: bass@linux.silkroad.com (Tim Bass) Cc: bilse@eu.net (Per Gregers Bilse), big-internet@munnari.OZ.AU Subject: Re: Topological vs. Administrative Aggregation Precedence: bulk Why not just simply aggregate the networks into the provider AS (s) and develop a simple Inter-domain routing protocol that aggregates both CIDR and classeful addresses into some provider "autonomous AD". The Inter-domain gateways would route on AD path vectors etc. etc. This has been proposed many times before. The latest iteration is basically kre's. The general problem is that you still have to have a mapping from the IPv4 address space to whatever other space you're routing on. And that mapping table has the standard scaling problems if you're not ALSO doing CIDR. If you're doing CIDR, then whatcha need other stuff for? It does appear that some very good alternatives have been presented years ago and the ideas are resurfacing from new observers and players. These well doumented ideas seemed very viable in 1993 and were somehow judged, too slow? Too complex? What is wrong with moving forward the ideas of AD and policy based interdomain routing? You might note that it's not new players. I was one of the implementors on the IDPR prototype and contributed to the design. There were numerous issues, including speed, complexity, transition (a solution that you can't get to from here is NOT useful -- no matter how wonderful it is) and (drum roll, please) scaling (rim shot). You'll note that some of the other players were Noel ("but it's got a mongo scaling problem") and Yakov ("how do you do route selection efficiently?"). You'll note that Martha Steenstrup is now working on Nimrod (and I'll risk a Noelgram by comparing this to IDPRv2) and that Deborah Estrin is quietly sitting on the sidelines worrying about multicasting now. As Unicast is a solved problem that only requires political and implementation work. Big wheel keeps on turnin'... Tony From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 22:20:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23807; Mon, 11 Sep 1995 22:20:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id WAA28666; Mon, 11 Sep 1995 22:16:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA28651; Mon, 11 Sep 1995 22:07:46 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23294; Mon, 11 Sep 1995 22:07:25 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA25308 (5.65c/IDA-1.4.4 for big-internet@munnari.OZ.AU); Mon, 11 Sep 1995 08:04:44 -0400 From: Tim Bass Message-Id: <199509111204.AA25308@linux.silkroad.com> Subject: Re: Topological vs. Administrative Aggregation To: tli@cisco.com (Tony Li) Date: Mon, 11 Sep 1995 08:04:44 -0400 (EDT) Cc: bilse@eu.net, big-internet@munnari.OZ.AU In-Reply-To: <199509110900.CAA00503@greatdane.cisco.com> from "Tony Li" at Sep 11, 95 02:00:06 am X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1088 Precedence: bulk > > Big wheel keeps on turnin'... > > Tony ... big Internet keeps on growin' :-) Thanks Tony for the professional and candid discussions... I am beginning to understand that there is a lot more to solving this problem than sitting on the sidelines calling out plays in a championship game to experienced players. ( please extend my apologies to CIDRD-WG for my limited view of the 'provider based aggregation' issue and not the larger picture ) Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 23:43:01 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26160; Mon, 11 Sep 1995 23:43:01 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA28785; Mon, 11 Sep 1995 23:36:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA28778; Mon, 11 Sep 1995 23:29:06 +1000 Received: from chaos.structured.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25881; Mon, 11 Sep 1995 23:28:52 +1000 (from kozowski@structured.net) Received: (from kozowski@localhost) by chaos.structured.net (8.6.10/Structured_8.6.12) id GAA18561; Mon, 11 Sep 1995 06:27:27 -0700 Date: Mon, 11 Sep 1995 06:27:27 -0700 From: Eric Kozowski Message-Id: <199509111327.GAA18561@chaos.structured.net> To: tli@cisco.com Subject: Re: Size of routers Cc: big-internet@munnari.OZ.AU Precedence: bulk [com-priv removed from cc: line. I'm tired of seeing this in both lists] >> And cisco can keep producing new boards that have later chips on them >> too. > >You *could*, but you haven't done so in the past. For how many years >did you sell 25Mhz '040s in your top of the line routers? I'm no hardware expert (and probably not an expert at anything), but it seems to me that it wouldn't have been too hard to come out with a CPU upgrade for the 7000. Either a faster 040 or an 060. Was there some reason that it wasn't offered? Just curious. Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski@structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1 From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 23:50:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26381; Mon, 11 Sep 1995 23:50:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA28838; Mon, 11 Sep 1995 23:48:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA28764; Mon, 11 Sep 1995 23:17:40 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25519; Mon, 11 Sep 1995 23:17:36 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02330; Mon, 11 Sep 95 09:17:32 -0400 Date: Mon, 11 Sep 95 09:17:32 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509111317.AA02330@ginger.lcs.mit.edu> To: bass@linux.silkroad.com, tli@cisco.com Subject: Re: Topological vs. Administrative Aggregation Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Tony Li You'll note that some of the other players were Noel ("but it's got a mongo scaling problem") Actually, as I recall, I think the main reason I wasn't totally thrilled with IDPR was that it perpetuated this silly (well, *I* think it's silly :-) distinction between EGP's and IGP's. (I seem to recall some chant about "running it straight on the metal"! :-) Also, IDPR was sort of grafted onto the side of the current routing/addressing architecture, which I just want to rip up and throw out completely... Martha Steenstrup is now working on Nimrod (and I'll risk a Noelgram by comparing this to IDPRv2) No, no disagreement here. It's in the same design space (a map distribution system with unitary/explicity routing), and draws a lot from the IDPR work. It has a number of very major differences (runs on the metal, yahhhh!), though. Noel From owner-Big-Internet@munnari.OZ.AU Mon Sep 11 23:53:02 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26458; Mon, 11 Sep 1995 23:53:02 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA28860; Mon, 11 Sep 1995 23:50:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA28781; Mon, 11 Sep 1995 23:29:10 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25883; Mon, 11 Sep 1995 23:29:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA25614 Mon, 11 Sep 1995 23:28:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02396; Mon, 11 Sep 95 09:25:49 -0400 Date: Mon, 11 Sep 95 09:25:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509111325.AA02396@ginger.lcs.mit.edu> To: bmanning@isi.edu, hal9001@panix.com Subject: Re: Keeping the Internet goingOA Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Robert A. Rosenberg" This is going to run into a MAJOR roadblock called FRAUD. ... Once I must pay my uplink provider for advertising my Network, things change since he is now selling me a service whose functioning he has no control over ... If I have my own /19 .. and SprintNet is blocking anything longer than an /18 then this is fraud by my provider It's only fraud if your provider represented to you that by paying that fee they would get your network advertised throughout the Internet. If the only representation they made was they'd they'd give your advert to their provider, and they do that, you have no case. (Anyone who makes guarantees about things they "[have] no control over" will likely wind up in a heap of trouble, BTW..) or do I have to also pay a bribe to SprintNet to carry my "too long" prefix if I am not a SprintNet linking customer. Well, this is the whole "routing settlements issue". Your provide would have to pay all the major transit providers. Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 01:10:17 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28825; Tue, 12 Sep 1995 01:10:17 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA29629; Tue, 12 Sep 1995 01:06:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA29566; Tue, 12 Sep 1995 00:53:24 +1000 Received: from aimnet.aimnet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28480; Tue, 12 Sep 1995 00:52:58 +1000 (from dcrocker@brandenburg.com) Received: from [204.118.88.39] (dial-cup2-9.iway.aimnet.com [204.118.88.39]) by aimnet.com (8.6.12/8.6.12) with SMTP id HAA15655; Mon, 11 Sep 1995 07:50:52 -0700 X-Sender: dcrocker@mailhub.aimnet.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Sep 1995 07:52:30 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Dave Crocker Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Precedence: bulk At 5:24 PM 9/8/95, Noel Chiappa wrote: >(Also: In geographic addressing, if a site is multihomed in two different >geographic regions, its address (singular) will "give information about only >one of [its] connections".) In the absence of a detail spec, your conclusion is a reasonable and even natural guess. My own thoughts have been that the placement of the attachment to the provider would NOT determine the geographic reference but, rather, the location of the user site would determine it. At the least, this would be beneficial to overcome exactly the concern you've raised. As with provider-based addressing, the goal is not reaching "total" routing table compression but rather to reach a level which is reasonable and sufficient. Any scheme that is used will have exceptions in the table, the question is what kind and how many (or, what percentage). I believe that using user-location for geographic will cause the provider having the long-haul line to the user to carry an exception but am presuming that such topological arrangements will be low-percentage. (But note that I didn't say 'rare'.) If the construct of a "virtual" MIX is viable then it may well be that the end result is to have this example fully integrated rather than appear as an exception. For comparison, we need to look at the overhead of the current and projected use of provider-based multi-homing. d/ -------------------- Dave Crocker +1 408 246 8253 Brandenburg Consulting fax: +1 408 249 6205 675 Spruce Dr. page: +1 408 581 1174 Sunnyvale, CA 94086 USA dcrocker@brandenburg.com From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 01:11:26 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28858; Tue, 12 Sep 1995 01:11:26 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA29649; Tue, 12 Sep 1995 01:09:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA29563; Tue, 12 Sep 1995 00:51:52 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28432; Tue, 12 Sep 1995 00:51:20 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id KAA29924 for ; Mon, 11 Sep 1995 10:49:19 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id KAA12600 for ; Mon, 11 Sep 1995 10:57:17 -0400 Received: from rgm3 (rgm3.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA21486; Mon, 11 Sep 95 10:59:15 EDT Message-Id: <9509111459.AA21486@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Sep 1995 10:48:10 -0400 To: Sanjay Kapur From: Robert Moskowitz Subject: Re: Geographinc addressing Cc: Andrew Partan , Dave Siegel , big-internet@munnari.OZ.AU Precedence: bulk At 10:14 PM 9/8/95 -0400, Sanjay Kapur wrote: >> This is changing rapidly as the largest organizations are installing TCP/IP >> networks to match their size. These networks are moving more data over less >> bandwidth than the SNA networks BECAUSE THEY DO NOT USE VIRTUAL CIRCUITS. > >I can not get my IBM SNA person to agree with the above statement. He >insists that SNA is more efficient when it comes to bandwith >utilization. I will however not contest your statement since my >personal knowledge of SNA internals is extremely limited. A debate that I have been through more than a dozen times. Depends on how you want to slice an atom. > >When you had SNA, how many "help desk staffers" did you have configuring >those 20,000 users terminals? To be fair, you should include the time >spent in maintaining the IP addresses and TCP/IP software of the users in >the above equation. Given the rate of rollout of the two, they are very comparable. TCP/IP is really a nit in everything that goes into rolling out an OA environment. Last year we had our only valid comparision. We took out the old 286s with coax cards in our zone offices and replaced them with 386s with LAN cards. The controllers and 9600bps multidrop lease lines were replaced with hubs, routers, and 56Kb frame relay circuits. The big cost was the rewiring from subgrade UDP for coax to CAT 3. But these offices were getting PBX upgrades too so it was rolled together. 1000 PCs were installed over 3 months. You backed up your 286 on friday and came in on monday to restore your data to your new system. On friday you used IRMA 3278 as a TSR; on monday you got your Rumba TN3270 training. One part of the equation that we were not allowed to include in our budget, but kicked in later was when the to 3745s that supported the zone offices were upgraded a few months later, they each came in with 2 LECs fewer which is a BIG chunk of change. >You have basically shifted the cost from a central department to user >departments. I am pretty sure the new solution is MUCH more expensive to >the Chrysler Corporation as a whole since I do not believe that all the >20,000 users would have needed a TCP/IP connection otherwise. Nope. User departments are doing OA admin, not TCP/IP admin. That is centrally controlled. Yes departmental computing costs more. Everyone with any brains knew that and said that. IP was brought in for C/S. TN3270 was an additional benefit. >I have two questions to which I would really want an answer. > >Are you willing to renumber the IP number of all the 20,000 users? Are >you even willing to renumber the IP address of the 18 MVS hosts? Sections of those 20,000 users get renumbered every month. If we needed a plan for another major shift (as we did when many users moved from 151.171/16 to 129.9/16). We'd do it. Meanwhile, energy is gathering for a DHCP pilot. Oh, and yes we have already renumbered a couple of those MVS sites. It is really quite easy. Install yet another 3271 and bring up a new MVS/TCP region. Move all the users off the old. Then decommision the old 3271. Done it already. Hats off to my colleague's whose job that is... >Please do not throw stones at others and force them to renumber if you can >not honestly answer yes to the above questions. If I were an EDUCATED TCP/IP consumer with 1,000 nodes, looking for assistance to get going. I'd only choose from a company that will make renumbering as planless as possible. Oh, one final comment. All of our technical people here work on the following principle: Any numbering scheme can only be good enough to last 2 to 3 years. At which point everything may change. Plan for it. Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 01:19:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29042; Tue, 12 Sep 1995 01:19:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA29691; Tue, 12 Sep 1995 01:16:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA29655; Tue, 12 Sep 1995 01:10:03 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28814; Tue, 12 Sep 1995 01:09:58 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id LAA03548 for ; Mon, 11 Sep 1995 11:08:36 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id LAA13046 for ; Mon, 11 Sep 1995 11:16:35 -0400 Received: from rgm3 (rgm3.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA21836; Mon, 11 Sep 95 11:18:27 EDT Message-Id: <9509111518.AA21836@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Sep 1995 11:07:23 -0400 To: "Michael F. Nittmann" , Sanjay Kapur From: Robert Moskowitz Subject: Re: Geographinc addressing Cc: Andrew Partan , Dave Siegel , big-internet@munnari.OZ.AU Precedence: bulk At 01:17 PM 9/10/95 -0400, Michael F. Nittmann wrote: > >Give your SNA guy a raise, send him to IP training, and everything is well. Gee that is a funny idea. That is EXACTLY what we did. She still pointly shows where IP falls short, but we are working on those points... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 01:22:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29259; Tue, 12 Sep 1995 01:22:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA29713; Tue, 12 Sep 1995 01:19:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA29651; Tue, 12 Sep 1995 01:09:17 +1000 Received: from ns.pilot.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28749; Tue, 12 Sep 1995 01:09:07 +1000 (from patrick@Verity.COM) Received: from verity.com (unknown-143-5.verity.com [192.187.143.5]) by mail.pilot.net (8.7.Beta.12/8.7.Beta.12) with SMTP id IAA20614; Mon, 11 Sep 1995 08:01:43 -0700 (PDT) Received: from cantina.verity.com by verity.com (4.1/SMI-4.1_Verity-Main-950202) id AA29815; Mon, 11 Sep 95 08:00:49 PDT Received: by cantina.verity.com (5.x/SMI-SVR4) id AA00606; Mon, 11 Sep 1995 07:58:33 -0700 Date: Mon, 11 Sep 1995 07:58:33 -0700 From: patrick@Verity.COM (Patrick Horgan) Message-Id: <9509111458.AA00606@cantina.verity.com> To: perry@piermont.com, tli@cisco.com Subject: Re: Size of routers... Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com X-Sun-Charset: US-ASCII Precedence: bulk Y'all aren't getting anywhere except closer to flame-city with this one, why don't you shake hands, call it a day, or take it to private email;) Patrick > > but lets face facts > -- for years you sold a box witha a 25Mhz '040 in it. The ink is > barely dry on the ads for the 7500. Who knows how long it will be > until another upgrade to your CPU? > > I know. But of course, I can't tell you, and since I'm an Evil > Conspirator, you wouldn't believe me anyhow.... > > Tony > > > _______________________________________________________________________ / These opinions are mine, and not Verity's (except by coincidence;). \ | (\ | | Patrick J. Horgan Verity Inc. \\ Have | | patrick@verity.com 1550 Plymouth Street \\ _ Sword | | Phone : (415)960-7600 Mountain View \\/ Will | | FAX : (415)960-7750 California 94303 _/\\ Travel | \___________________________________________________________\)__________/ From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 01:38:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB29952; Tue, 12 Sep 1995 01:38:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA29766; Tue, 12 Sep 1995 01:36:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA29759; Tue, 12 Sep 1995 01:32:33 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29697; Tue, 12 Sep 1995 01:32:28 +1000 (from louie@uunet.uu.net) Received: from localhost by rodan.UU.NET with SMTP id QQzgsz09494; Mon, 11 Sep 1995 11:29:41 -0400 Message-Id: To: Karl Denninger Cc: perry@piermont.com, tli@cisco.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, inet-access@earth.com From: "Louis A. Mamakos" Subject: Re: Size of routers In-Reply-To: Your message of "Mon, 11 Sep 1995 08:31:19 CDT." <199509111331.IAA12279@Jupiter.mcs.net> Date: Mon, 11 Sep 1995 11:29:41 -0400 Sender: louie@uunet.uu.net Precedence: bulk > This is one of the reasons that I initiated discussions, and ultimately got > MFS to back, MAE-Chicago, now called "Mae-Central". > > Now, why is it that all the big guys have yet to show interest and/or sign > up for service there? You might argue that the NAP does what they need, but > that's not (obviously) true -- just from the participant list alone. > > If the nationals aren't going to make a REAL effort at diversity and > locality of routing, then their backbones ARE going to melt. They *have > to*, as capacity which seems volumnous today will look constrained tomorrow > and like a little garden hose in a year. Part of this is a marketing issue with MFS. UUNET/Alternet will connect to MAE-Chicago of some of the other major backbone operators do as well. I don't know if, for example, ANS, MCI, PSI, or Sprintlink have announced their intentions or not. Louis A. Mamakos, Manager of Network Engineering louie@uu.net, uunet!louie UUNET Technologies, Inc. Voice: +1 703 206 5823 3060 Williams Drive Fax: +1 703 206 5908 Fairfax, VA 22031 From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 01:42:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00347; Tue, 12 Sep 1995 01:42:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA29810; Tue, 12 Sep 1995 01:40:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA29762; Tue, 12 Sep 1995 01:36:19 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29856; Tue, 12 Sep 1995 01:36:10 +1000 (from rgm3@is.chrysler.com) Received: from sg543689.eng.chrysler.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27638 Tue, 12 Sep 1995 00:58:15 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id KAA00715 for ; Mon, 11 Sep 1995 10:55:40 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id LAA12774 for ; Mon, 11 Sep 1995 11:03:39 -0400 Received: from rgm3 (rgm3.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA21604; Mon, 11 Sep 95 11:05:41 EDT Message-Id: <9509111505.AA21604@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Sep 1995 10:54:37 -0400 To: Sanjay Kapur From: Robert Moskowitz Subject: Re: large site renumbering (was Re: Geographic addressing) Cc: "Dave O'Leary" , big-internet@munnari.OZ.AU Precedence: bulk At 10:42 PM 9/8/95 -0400, Sanjay Kapur wrote: > >I was at an NT server class the past few days and they went into all the >gory details of Microsoft's Domain model(s) and DHCP/WINS. DHCP is fine >for small organizations but the instructor said it is not distributed >enough to be useful in large organizations. DHCP servers lease out IP >addresses to clients for fixed amounts of time. These leases are >renewable if both the server and client agree. DHCP servers do not talk >to each other and maintain their own sets of IP numbers. At times it is >not clear which (if you have more than one) DHCP server will respond to a >query. Also free addresses given to one DHCP server for leasing out can not >be automatically used by another DHCP server if the second server runs >out of numbers. That is one of the major problems with the MS implementation of DHCP. They worked from the basis that IP addresses are scarce commodities and have to be leased. With OSPF variable subnetting, we have lots of addresses for systems (I recently helped Ford Hospital renumber their WAN links to recover about 75% of their address space. Oh no connection to FORD Motor Co; an old friend is in charge of their WAN and called me for help in getting another address block. And she is an OSPF "expert"!). So we are looking for DHCP software that maps an IP address permanently to a system 'cookie', most likely a MAC address. This means we can maintain a distributed database for all systems known to all DHCP servers. Now just to find such an implementation. Oh, yes, you change the MAC address, you change the DHCP database, but then we do this anyway for our hardware inventory... Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 01:44:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00408; Tue, 12 Sep 1995 01:44:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA29833; Tue, 12 Sep 1995 01:42:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA29756; Tue, 12 Sep 1995 01:29:38 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29521; Tue, 12 Sep 1995 01:29:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03418; Mon, 11 Sep 95 11:28:40 -0400 Date: Mon, 11 Sep 95 11:28:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509111528.AA03418@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, michael@junction.net Subject: Re: Size of routers Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Michael Dillon You are implying here that the solution to the problems of growth is to reduce routing table size and that the way to do this is to apply the lessons of routing theory. Not just implying; and the way to do it is topology-based addresses. What you are forgetting is that not all people agree that reducing routing table size is the only solution. Some people have all sorts of, errr, infeasible ideas (and I won't be obnoxious and name any). Just because people don't think that topology-based addressing is the only solution, that doesn't mean their ideas hold water. Furthermore, even when we do move towards implementing reductions in routing table size .. the problem is much larger than merely a problem in routing theory. The problem has legal aspects, marketing aspects, cost aspects, etc... Absolutely. However, believe it or not, I'm not insensitive to them, or unwilling to talk about them, as long as everyone understands the technical "envelope" (in the sense of a plane's performance "envelope") we are, like it or not, constrained within. If the people who are customers of NSP's refuse to accept topological addressing due to a perception that it is restraint of trade, then there will *NEVER* be topological addressing on the IPv4 Internet. Period. I think you're mistaken there. Customers who refuse to accept topological addresses may find a provider to take them, but they may also find themselves with large portions of the Internet that they cannot reach, due to their addresses being filtered out of routing tables in large parts of the 'net. The 'net is, after all, a trans-national cooperative anarchy; who are you going to call to enforce putting your route in their tables? Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 01:59:29 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01142; Tue, 12 Sep 1995 01:59:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA29882; Tue, 12 Sep 1995 01:56:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA29835; Tue, 12 Sep 1995 01:43:40 +1000 Received: from sg543689.eng.chrysler.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00383; Tue, 12 Sep 1995 01:43:33 +1000 (from rgm3@is.chrysler.com) Received: from sg5382na.eng.chrysler.com (sg5382na.eng.chrysler.com [152.116.1.30]) by sg543689.eng.chrysler.com (8.6.10/8.6.9) with ESMTP id LAA09452 for ; Mon, 11 Sep 1995 11:43:32 -0400 Received: from clncrdv1.is.chrysler.com ([129.9.241.19]) by sg5382na.eng.chrysler.com (8.6.10/8.6.9) with SMTP id LAA13911 for ; Mon, 11 Sep 1995 11:51:32 -0400 Received: from rgm3 (rgm3.is.chrysler.com) by clncrdv1.is.chrysler.com (4.1/SMI-4.1) id AA22182; Mon, 11 Sep 95 11:53:34 EDT Message-Id: <9509111553.AA22182@clncrdv1.is.chrysler.com> X-Sender: t3125rm@clncrdv1.is.chrysler.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Sep 1995 11:42:29 -0400 To: Sanjay Kapur From: Robert Moskowitz Subject: Re: Geographinc addressing Cc: Andrew Partan , Dave Siegel , big-internet@munnari.OZ.AU Precedence: bulk At 10:48 AM 9/11/95 -0400, Robert Moskowitz wrote: >> >>When you had SNA, how many "help desk staffers" did you have configuring >>those 20,000 users terminals? To be fair, you should include the time >>spent in maintaining the IP addresses and TCP/IP software of the users in >>the above equation. > >Given the rate of rollout of the two, they are very comparable. TCP/IP is >really a nit in everything that goes into rolling out an OA environment. >Last year we had our only valid comparision. We took out the old 286s with >coax cards in our zone offices and replaced them with 386s with LAN cards. >The controllers and 9600bps multidrop lease lines were replaced with hubs, >routers, and 56Kb frame relay circuits. Oh, I left out that I have 7 years of working with SNA on my history. Most of my work is on PU2, LU0,1,2,3, and LU6.2 devices. I had to know a lot about PU4 and PU5 stuff to get changes in approaches done. Back in the late 80s we had a whole isle of people (actually 2 if you count the VTAMers) supporting terminal deployment. It was a MAJOR sell job to get them to move to DFT support and Dynamic Logmode (that took a major controller upgrade too, sound familiar?). Oh how they fought defining 5 LUs for every terminal in the company just incase multisession might be needed. the memory hit to the 3745s was substantial. Also the controllers. Ah those were the days. THose were the meaningful technology debates...... You WANT static routing????????? You should be putting every erg of energy you've got to move any static portion of IP off the dime! Long live EIDS!!!!!!!! Robert Moskowitz Chrysler Corporation (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 02:02:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01202; Tue, 12 Sep 1995 02:02:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA29919; Tue, 12 Sep 1995 02:00:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA29878; Tue, 12 Sep 1995 01:55:46 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00988; Tue, 12 Sep 1995 01:55:18 +1000 (from spector@gatekeeper.zeitgeist.com) Received: from gatekeeper.zeitgeist.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA25760 Mon, 11 Sep 1995 23:34:03 +1000 (from spector@gatekeeper.zeitgeist.com) Received: from zeitgeist.zeitgeist.com (zeitgeist.zeitgeist.com [192.124.49.10]) by gatekeeper.zeitgeist.com (8.6.12/8.6.9) with ESMTP id JAA17616; Mon, 11 Sep 1995 09:28:36 -0400 Received: from zeitgeist.com (localhost [127.0.0.1]) by zeitgeist.zeitgeist.com (8.6.10/8.6.9) with ESMTP id JAA10406; Mon, 11 Sep 1995 09:28:36 -0400 Message-Id: <199509111328.JAA10406@zeitgeist.zeitgeist.com> To: big-internet@munnari.OZ.AU Subject: Re: size of routers Cc: perry@piermont.com Date: Mon, 11 Sep 1995 09:28:35 -0400 From: David HM Spector Precedence: bulk > Perry writes: > We have to prevent ourselves from constructing network choke points > by producing a "treework" instead of a network. > > Exchange points are of critical importance because there is almost no > locality of reference in the internet. Once you cross your corporate > gateway, you are no more likely to talk to someone on your provider > than you are to talk to someone off it. Exchange points end up > carrying virtually all inter-entity traffic. > Ah! this IS the crux of the biscuit... unfortunately, we're there right now, and it's NOT a technology problem, but a political one. The network is currently bound to one or two major choke points: the most visible of which, ath the moment, is MAE-EAST. Not a day passses when there is not an effective partition of one major backbone provider from the rest. This affects millions of people and even though there may be another exchange (i.e., the CIX, or MAE-WEST) since there are very few peering agreements in place between the major carriers when a problem happens at MAE-EAST, everything stops. Routing protocols have nothing to do with the problem.... In my other life as the owner of the Internet at J.P. Morgan, we see this every day -- the response from a carrier we can't get to because of THEIR problem at MAE-EAST (which is usually a small pipe, loose cable, etc) is "well, if you were on OUR network you wouldn't have this problem." Huh. Gee, thanks...Not exactly helpful in a crisis... I would contend that although we WILL need more versatile routing protocols for all the video, telephony, etc the biggest problems will be getting the current plays just to talk to each other and use existing routing protocols so they will be as effective as they were when we had the ARPAnet -- i.e., automatic recovery after an exchange goes away. David From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 02:06:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01433; Tue, 12 Sep 1995 02:06:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA29941; Tue, 12 Sep 1995 02:04:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA29864; Tue, 12 Sep 1995 01:50:51 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00633; Tue, 12 Sep 1995 01:50:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26703 Tue, 12 Sep 1995 00:13:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02664; Mon, 11 Sep 95 10:11:21 -0400 Date: Mon, 11 Sep 95 10:11:21 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509111411.AA02664@ginger.lcs.mit.edu> To: gherbert@crl.com, jnc@ginger.lcs.mit.edu Subject: Re: Size of routers Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: George Herbert The only conclusion I have come to so far is that there is nowhere near the impetus out there to start over from scratch and renumber the world into a new, topological addressing heirarchy. I'm not suggesting that (at least not yet; before I would suggest it there would have to be a reason that would make the cost worth it, and so far I know of none). What I *am* saying is that *most* (i.e. not *all*) of the people who move, come onto the net, etc, will have to renumber. If most people *do not*, the routing will croak. How to decide who the lucky few (if any) are who don't have to renumber is a policy probem I won't touch with a 20-foot pole. My *suggestions* are i) charge, ii) disallow it completely. Both of these get rid of the fights over "fairness", etc. It might happen with the next protocol, but not IPv4. How optimal the addresing hierarchy has to be is related to how much routing overhead you can stand. We can apparently withstand enough to get by with a relatively inefficient addressing hierarchy, at least for mono-metric routing, and this degree of scale. Make the network 100 times bigger, and we may have to create a better addressing hierarchy. Of course, that growth wil take some time, and at the end of it, we'll probably have better renumbering tools. This is not a scholarly debate on how networks can be done best from a clean slate. No, indeed. That's some of my *really* "crazy" ideas, like flow-based networks, variable length locators, etc, etc. Junking everything and starting over again is out of the question. You seem not to realize this, but I understand this. Hard to believe, I know... We can't ignore the existing problem ... we can't make current crisis simply go away. Indeed, and CIDR and renumbering are the best solution. This is not a classroom, we are not being graded on ellegance. If I were in CS Professor mode, I'd give IPv4 addresses as a whole a D, so any discussion of how to keep them running is necessarily "non-academic". CIDR is about as good as you're going to get within the context of a 32-bit field which is used as a globally visible routing-name. So, I'd give it an A within those limits (it's sure an improvement over A/B/C, and also over subnets, which were a reasonable intermediate step). Now that you're done insulting me for being "too academic", can we get back to the technical, engineering issues at hand? Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 02:18:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01944; Tue, 12 Sep 1995 02:18:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA29992; Tue, 12 Sep 1995 02:16:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29943; Tue, 12 Sep 1995 02:04:48 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB01388; Tue, 12 Sep 1995 02:04:41 +1000 (from ses@tipper.oit.unc.edu) Received: from chivalry (chivalry.eit.COM [192.100.58.30]) by tipper.oit.unc.edu (8.6.12/8.6.10) with SMTP id MAA28990 for ; Mon, 11 Sep 1995 12:04:31 -0400 Date: Mon, 11 Sep 1995 09:06:30 -0700 (PDT) From: Simon Spero X-Sender: ses@chivalry To: big-internet@munnari.OZ.AU Subject: Saving the InterNet Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk Now that the CIDR and renumbering fun has passed the 1,000 message mark counting just those messages sent to big-internet, maybe it's time for a little change of pace. Although routing and addressing are important parts of a balanced breakfast, there are several other things that can/must be done to keep the network regular. Here's a brief list of some of them. * Specify and deploy a replacement for HTTP that doesn't use a separate TCP connection for every single request. This is the aim of the HTTP-NG project, and should reduce the number of HTTP connections by an order of magnitude. * Build and deploy a network of caching servers for the WWW to reduce traffic over congested links. * build and deploy a network of high performance mail exploders connected by application and/or internet level multicast, and provide delivery agents capable of using this network to operators of large, high-volume mailing lists. Even when BI isn't thrashing as it has since 8/22, the vast bulk of incoming mail I recieve is from mailing lists. * build and distribute a modern DNS server. A BIND replacement using multi-threading and a decent data storage model will make deploying dnsind and dnssec much nicer, and will make it easier to use the name service for other directory applications. Remember, a packet saved is a packet earned. Simon From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 02:19:40 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01979; Tue, 12 Sep 1995 02:19:40 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27716 Tue, 12 Sep 1995 01:02:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA29581; Tue, 12 Sep 1995 00:56:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA29560; Tue, 12 Sep 1995 00:49:24 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28364; Tue, 12 Sep 1995 00:49:13 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03096; Mon, 11 Sep 95 10:49:11 -0400 Date: Mon, 11 Sep 95 10:49:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509111449.AA03096@ginger.lcs.mit.edu> To: comp-priv@psi.com, spector@gatekeeper.zeitgeist.com Subject: Re: Router discussion, multiple lists, etc Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: David HM Spector It should be tres obvious by now that this has spilled over waaaay to far into Com-Priv; we are probably boring the rest of the com-priv folks to tears ... would it be possible for folks to stop cross-posting this discussion..? Sure, provided everyone who's on Com-Priv, and not on Big-I, promises to be nice little Internauts and i) not throw a fit and start a giant argument when the IETF-wide call for the address non-ownership document goes out, and ii) dutifully renumber when they change their location in the network. (Translation: we'll stop posting to Com-Priv, but *if you care about this*, get on Big-I.) It's *soooo* boring to have the exact same argument all over again on Yet One More Mailing List. Hence the temptation to do them all at one fell swoop. Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 02:19:43 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01983; Tue, 12 Sep 1995 02:19:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27934 Tue, 12 Sep 1995 01:08:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA29605; Tue, 12 Sep 1995 01:04:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA29546; Tue, 12 Sep 1995 00:37:49 +1000 Received: from csunb0.leeds.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27884; Tue, 12 Sep 1995 00:37:33 +1000 (from jj@scs.leeds.ac.uk) Received: from csparc23.scs.leeds.ac.uk (csparc23.leeds.ac.uk [129.11.144.63]) by csunb0.leeds.ac.uk (8.6.9/8.6.9) with SMTP id PAA22027; Mon, 11 Sep 1995 15:32:30 +0100 Date: Mon, 11 Sep 1995 15:32:29 +0100 (BST) From: Jim Jackson Subject: Re: Routing tables & what to do about them To: Sanjay Kapur Cc: Ruediger Volk , big-internet@munnari.OZ.AU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Sanjay Kapur wrote: > On Sun, 10 Sep 1995, Ruediger Volk wrote: > > > hmmm, I guess there are not that many areas that are *completely* without > > Government regulation. > > > > But anyway - it was your claim of BT being a monopoly that triggered my > > response... > > > > Ruediger Volk > > > > You may want to look up the definition of "monopoly". > > By a monopoly I mean any single entity or group of entities acting > together that has a significant enough market share to effectively > control the industry it is in. > > Any company that controls the industry enough to force a renumbering of > all the phones of a whole country is almost by any definition a monopoly. > I believe that, technically, it was not BT that did the change but one of the regulatory bodies. But given that BT controls the vast majority of phones in the UK, such niceties are pretty academic :-) But the change did affect Hull - who have (always have had) an entirely different Telco. Jim From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 02:20:42 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02019; Tue, 12 Sep 1995 02:20:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26348 Tue, 12 Sep 1995 00:01:22 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA28912; Mon, 11 Sep 1995 23:56:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA28790; Mon, 11 Sep 1995 23:38:49 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26050; Mon, 11 Sep 1995 23:37:59 +1000 (from karl@Mcs.Net) Received: from Kitten.mcs.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA25791 Mon, 11 Sep 1995 23:34:52 +1000 (from karl@Mcs.Net) Received: from Jupiter.mcs.net (Jupiter.mcs.net [192.160.127.89]) by kitten.mcs.com (8.6.10/8.6.9) with ESMTP id IAA07060; Mon, 11 Sep 1995 08:32:03 -0500 Received: (from karl@localhost) by Jupiter.mcs.net (8.6.11/8.6.9) id IAA12279; Mon, 11 Sep 1995 08:31:19 -0500 From: Karl Denninger Message-Id: <199509111331.IAA12279@Jupiter.mcs.net> Subject: Re: Size of routers To: perry@piermont.com Date: Mon, 11 Sep 1995 08:31:19 -0500 (CDT) Cc: tli@cisco.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, inet-access@earth.com In-Reply-To: <199509110629.CAA13317@frankenstein.piermont.com> from "Perry E. Metzger" at Sep 11, 95 02:29:20 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2311 Precedence: bulk > Tony Li writes: > > I want to emphasize that I am not arguing that we shouldn't do things > > like CIDR to reduce the frivolous growth of the routing tables -- > > things like routes to single-connected networks of ten machines in an > > office somewhere. What I am trying to say, along with others, however, > > is that it isn't going to fix the bigger problem. > > > > What do you think the bigger problem is? > > We have to prevent ourselves from constructing network choke points > by producing a "treework" instead of a network. Agreed. ... > As all this starts to happen, we are either going to have to route in > a much more densely interconnected net with a lot flatter "top" to the > global routing pyramid -- i.e. far more exchange points and a lot more > advertisements to keep the routes efficient -- or we are going to end > up with choke points instead of exchange points. This is one of the reasons that I initiated discussions, and ultimately got MFS to back, MAE-Chicago, now called "Mae-Central". Now, why is it that all the big guys have yet to show interest and/or sign up for service there? You might argue that the NAP does what they need, but that's not (obviously) true -- just from the participant list alone. If the nationals aren't going to make a REAL effort at diversity and locality of routing, then their backbones ARE going to melt. They *have to*, as capacity which seems volumnous today will look constrained tomorrow and like a little garden hose in a year. > > Seems to me that if we can control the frivolous growth of the > > routing tables, then we can get on with making things more _stable_, > > refined, and faster. > > Frivolous growth in the routing tables I will happily agree should be > controlled. My problem is that I'm not sure all the growth is going to > be frivolous. > > Perry I would argue that most of it is not and will not be frivolous. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 803-MCS1] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 02:21:11 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02046; Tue, 12 Sep 1995 02:21:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26440 Tue, 12 Sep 1995 00:04:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA28939; Mon, 11 Sep 1995 23:59:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA28787; Mon, 11 Sep 1995 23:38:17 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26061; Mon, 11 Sep 1995 23:38:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02314; Mon, 11 Sep 95 09:10:34 -0400 Date: Mon, 11 Sep 95 09:10:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509111310.AA02314@ginger.lcs.mit.edu> To: perry@piermont.com Subject: Re: Size of routers Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Precedence: bulk From: "Perry E. Metzger" We have to prevent ourselves from constructing network choke points by producing a "treework" instead of a network. Nobody is suggesting we do. I think the most people are going to create is a system in which there is a system of high-speed trunks overlaid with a lower-speed mesh (imagine the network equivalent of the US road system, with a high-speed Interstate system overlaid, and tied to, the local road system). Ironically enough, a very "localized" mesh (i.e. most links are to "local" destinations in the graph - imagine the US road system with no Interstates) is *easier* to route in (in terms of how much routing overhead you have to have to get a given degree of path optimality) than one which has a few high-speed routes which connect together widely separated parts of the mesh. (This is because to get more optimal routes, you need larger AAB's, and more widely separated connections make the AAB's larger.) Of course, since average path lengths in the latter are lower to begin with, you can withstand a higher degree of non-optimality and still have lower path lengths overall. However, as far as I can see, the future of routing, and the network as a whole, is really quite murky, because I'm convinced that down the road we will have a single intergrated data-voice-video net, and that net is going to look way different, in addition to needing more more sophisticated routing. So, let's just "band-aid" this one together for now, and move on... The ratio of the fastest available commercial high speed interconnect technology to the speed of the average end user link is going to fall radically in coming years. If this is true it will create a different, and interesting, network. Look for a network which does not have an "Interstate" like part of the system, but is more homogeneous. It won't be purely "local" (as defined above), since you don't want to take multi-multi-hop paths through many AS's to get to somewhere far away, but the "long-distance" mesh will be a lot more parallel to provide the needed bandwidth. Actually, there's another good question; what will the local/distant traffic ratio be in the future? I keep hearing claims on both sides, don't know who's correct. As all this starts to happen, we are either going to have to route in a much more densely interconnected net with a lot flatter "top" to the global routing pyramid Well drawn naming boundaries for parts of the topology will help a lot here. (I suspect the drawing of boundaries, and putting high-level structure into them, will be a topic of much work in years to come.) You have to visualize this complex graph in 3D (maybe some "Foundation Trilogy" type display technology will help us here :-), and see how you can enclose chunks of it in "naming surfaces". Actually, in my crystal ball, we will want to set naming boundaries based also on areas of the net about which one can make policy, etc, statements, so that non-mono-metric routing also has good scaling properties. But let's put off that level of complexity until we have to! This is the crisis that I am anticipating. It is not unanticipated elsewhere... :-) Frivolous growth in the routing tables I will happily agree should be controlled. My problem is that I'm not sure all the growth is going to be frivolous. No, of course, in a growing net, the tables will grow. Let's just not put in growth that doesn't *do* anything *useful*, just burns computrons for no good reason, eh? Noel From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 02:38:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02971; Tue, 12 Sep 1995 02:38:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA00148; Tue, 12 Sep 1995 02:36:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA00123; Tue, 12 Sep 1995 02:24:50 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02214; Tue, 12 Sep 1995 02:24:45 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id MAA13630; Mon, 11 Sep 1995 12:24:35 -0400 Message-Id: <199509111624.MAA13630@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers In-Reply-To: Your message of "Mon, 11 Sep 1995 09:10:34 EDT." <9509111310.AA02314@ginger.lcs.mit.edu> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Sep 1995 12:24:34 -0400 From: "Perry E. Metzger" Precedence: bulk Noel Chiappa writes: > However, as far as I can see, the future of routing, and the network > as a whole, is really quite murky, because I'm convinced that down > the road we will have a single intergrated data-voice-video net, I quite agree. > and that net is going to look way different, in addition to needing > more more sophisticated routing. It is certainly going to need to be far more stable. I'm not sure that it is going to be "different" in the sense of being fundamentally different from the sort of net we have now. > Actually, there's another good question; what will the local/distant traffic > ratio be in the future? I keep hearing claims on both sides, don't know who's > correct. For data traffic, there is very little locality. There is a lot of transfer inside an organization, but once you leave the organization stuff goes fairly far. For video traffic in the future, there will probably be some locality on picturephone type traffic, but one-way video is unlikely to experience any more locality than current data traffic. Since video is likely to dominate the bandwidth consumption, this is going to produce very interesting traffic patterns indeed. Perry From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 02:43:48 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03217; Tue, 12 Sep 1995 02:43:48 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA00186; Tue, 12 Sep 1995 02:41:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA00126; Tue, 12 Sep 1995 02:24:58 +1000 Received: from [166.45.2.40] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02223; Tue, 12 Sep 1995 02:24:55 +1000 (from dennis@mci.net) Received: from localhost ([127.0.0.1]) by romford.reston.mci.net with ESMTP id <196374>; Mon, 11 Sep 1995 12:24:05 -0400 To: avg@sprint.net (Vadim Antonov) Cc: michael@junction.net, tli@cisco.com, asp@uunet.uu.net, bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, jnc@ginger.lcs.mit.edu, smd@cesium.clock.org Subject: Re: Distributed systems In-Reply-To: Your message of "Sun, 10 Sep 1995 17:58:23 EDT." <199509102158.RAA12416@titan.sprintlink.net> Date: Mon, 11 Sep 1995 12:23:49 -0400 From: Dennis Ferguson Message-Id: <95Sep11.122405-0400_edt.196374+9@romford.reston.mci.net> Precedence: bulk >>The route processor is supposed to stop this from happening by feeding >>the SSP a subset of the full routing table. > > Yet another myth. The cache footprint for core routes is at about 40% > of the full table. It may as well be that *not* doing cacheing will > actually save memory in the forwarding tables (and would certainly make > the whole design a lot more robust). The bugs in software seem to > be in the top three reasons for the Internet's unrealiability. > > SL-MAE-E#sh ip ca > IP routing cache 12686 entries, 1859004 bytes > Minimum invalidation interval 2 seconds, maximum interval 5 seconds, MCI's hottest routers run with closer to 80% of the full table in the cache, e.g. core.wtn#show ip ca IP routing cache 23911 entries, 3545372 bytes This fraction has continuously grown over the 6 months I've been paying attention, from about 65% in April. Not that this necessarily tells you a whole lot, since that number does depend critically on the strategy used for flushing entries out of the cache as well, but I do have another data point. If you stay up until the wee hours of the morning (to avoid breaking anything), and flush the cache on one of those routers, the load won't come off the RP until over 50% of the full forwarding table is back in the cache. This result is a direct contradiction to work done by Bilal Chinoy and Hans-Werner Braun some time ago using data sampled on the T1 NSFnet, which suggested that forwarding-path caching was indeed attractive with respect to the size of the full forwarding table. The fact that this has changed may be a result of changing characteristics of applications people use, or may be a consequence of the relative success of CIDR at keeping the growth rate of the forwarding table below the growth rate of the Internet as a whole. We're getting increasingly less dead weight in forwarding tables. In any case suggesting a scheme which relies on forwarding-path demand caching for some benefit, without presenting supporting data concerning the traffic carried by the network being designed for, is engineering something without any evidence of it being useful. All the indications I have suggest that forwarding-path caching is no longer of any benefit when building high-end routers, and has considerable drawbacks. Dennis Ferguson P.S. I also agree about the software complexity of caching. Despite having burned months, or years, of good quality programmer time in efforts to keep it functioning I think the fact that Cisco 7000's do demand caching in the forwarding path is the root cause of about 80% of all evils with those boxes for high-end uses. Life is too short... From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 02:48:38 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03536; Tue, 12 Sep 1995 02:48:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA00214; Tue, 12 Sep 1995 02:45:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA00116; Tue, 12 Sep 1995 02:22:21 +1000 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02101; Tue, 12 Sep 1995 02:22:13 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA11191; Mon, 11 Sep 95 11:42:09 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA03709; Mon, 11 Sep 95 11:22:08 CDT Date: Mon, 11 Sep 95 11:22:08 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9509111622.AA03709@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: some notions on a routing architecture - Precedence: bulk This is a set of random notes I've been working on in my spare time. It draws some ideas from Nimrod (and may also resemble PIP, which I am unfamiliar with, though obviously I should -- copious free time issues rear ugly heads). It's actually a rather crude horrid hack, sort of an un-dead zombie Nimrod, come to feed on the flesh of the living. I doubt that the scheme will actually work, but I'm interested in any comments on why, since I can't see any problems that I know for sure make it silly. I've tried to reason out some of the potential show stoppers, and written then in as questions. It's also possible that somewhere in the details there's some misunderstanding I have about BGP's AS's that makes the whole thing really dumb. Most likely of all, I have completely missed some gaping gargantuan hole in the logic which makes the whole thing quite ludicrous. I *think* it has reasonably good scaling properties, and uses more or less currently deployed technology, and can be deployed incrementally. --------- The object here would be to make BGP pull data more or less on demand instead of pushing everything always. The basic elements of the strategy might work out to be: - teach BGP to forget things it can get from other BGP speakers as needed. - teach BGP to query remote peers for information as needed. - teach the forwarding path how to use either a 2-hop LSRR or an IP-in-IP encap to get packets to an egress router, where said router's forwarding path knows to strip the LSRR or de-encap the packet. In more detail: Forgetting Using published and globally agreed upon hash functions, any IPv4 address can be hashed to a list or group of BGP speakers, based on something like the top 3 octets of the address. Boxes in this list are 'authorities' for networks hashing to them. Every BGP speaker should remember: - stuff for its one AS, anything attached to it, anything it learns via its own IGP, in short. - stuff discussing networks which contain nodes which hash to this speaker (not every BGP speaker need be in the hash, presumably a smaller set of the core routers will serve routes on demand, and these need to maintain that portion of BGP data is sees which pertains to the networks it will serve routes for). - stuff for backbone networks. Anything else it learns should be used to build forwarding data 'as if' it were to be used, and then that forwarding data should be re-advertised, and then flushed. This means that the stuff advertised will be similar to, but not the same as, what is currently advertised, since routes which would not normally be used to forward (if only we remembered the better one we forgot a moment ago) will be advertised. This may or may not have serious impacts, I have no real idea. Q: is the additional overhead of re-advertising essentially everything consistant with our policy, as opposed to only the 'best of' such, a show stopper? Can it be fixed? The upshot here is that something roughly similar to the current BGP advertisements and policy will take place, but BGP speakers are free to discard chunks of their BGP databases, and not even bother really installing many routes into their forwarding tables. Further, every core router will have a complete forwarding table for networks attached to its AS, and for the networks comprising the core. Inter-AS traffic and Inter-core traffic will forward as always, therefore. I think that the routers which maintain BGP data for networks that they are a hashed authority for will be able to construct optimal routes, since the should be seeing everything. This isn't very important now, since all we really need is the egress AS for a given network, but is a nice feature to keep in one's back pocket. I might be wrong, my tiny little brain isn't entirely convinced of this. Querying In place of a default route, in a default free router, software for handling packets destined for somewhere not in the forwarding table will generate a query. The globally agreed upon hashes are computed for the destination address of the packet, to generate a list of core routers to query. Something like a UDP datagram gets heaved to one or more of these routers, triggering something like an UPDATE packed into another UDP datagram in response. The essential information in this response is the IP address of a suitable router in the AS attached to the destination network, this is all that's needed. This information is installed in a new forwarding path data structure, handled cache-like. A sticky bit here is what to do when topology changes occur. Would it be reasonable to have the BGP' agent snoop on the query cache and flush entries which appear to no longer be valid, based on BGP PDUs flying into the box? Remember that everyone sees everything, more or less, and can fiddle around with the information for a while before forgetting it. The response to topology changes is rather unclear to me, and is obviously of extreme importance. Forwarding The forwarding path first does the usual thing, and if it finds the 'faux default' route, falls into some additional code, which queries the cache-like structure mentioned above. If there's a hit, it either stamps a suitable LSRR, or does IP-in-IP encapsulation, in either case arranging to send the packet to the egress router learned through the new BGP querying, for subsequent forwarding to the final destination. In the event of a miss, a query is generated, and the packet queued pending a response. Routers need, in addition, to be able to detect the presence of the LSRR or the IP-in-IP business, and removing the option, or de-encapsulating suitably. Q: Is it really hard to add the stamping/encapsulating and unstamping/de-encap to the forwarding path of various vendor's routers? (I know of one where it's not all that tricky, but that vendor's not super interested in the backbone market). Deployment This can be deployed incrementally, though no major benefits would be seen until deployment is wide-scale. Owners of core routers need to indicate willingness to be authorities for groups of hash values. When any owner of a default free router knows about 'enough' authorities for a given hash (2 or 3), they may configure their routers to forget forwarding information for networks that hash to that value, and to query instead. Thus, there is an initial (presumably small) memory hit for deploying the new BGP with some additional data structures and code, thereafter you may trade off routing/forwarding database space for LSRR/encap cache space, in a presumably positive fashion. Scaling Properties The architecture lives and dies by the hit ratio in the LSRR/encap cache. If that hit ratio becomes substantially less than 100%, instant congestion and death by queuing ensues. By intelligent deployment, the cache hit ratios may be raised, one hopes to reasonable levels. This deployment strategy would involve placing the caches in the routers as close to the edges of the backbone as possible. In the interior, there is traffic to many destination networks flowing through the T3 mesh, with the obvious cache busting behaviors. By getting the tranist frames LSRRd or encapped as early as possible, the load on the interior routers drops as more traffic has immediate destination in the set of routers on the edge of the core. By doing the encapsulations close to the edge, the number of different final destinations active (the required cache size) should go down as the number of source networks sending traffic through an edge router is presumably smaller. By splitting the edge up, using more routers on the edge, the number of speakers is reduced, and (one hopes) the number of destination networks per router, and hence the necessary LSRR/encap cache size, is reduced. Q: Is this analysis even close? From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 02:59:59 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04175; Tue, 12 Sep 1995 02:59:59 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA00256; Tue, 12 Sep 1995 02:56:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA00207; Tue, 12 Sep 1995 02:45:24 +1000 Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03135; Tue, 12 Sep 1995 02:42:13 +1000 (from dhaskin@BayNetworks.com) Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA09915; Mon, 11 Sep 95 12:38:24 EDT Received: from andover.engeast by BayNetworks.com (4.1/SMI-4.1) id AA14451; Mon, 11 Sep 95 12:39:31 EDT Date: Mon, 11 Sep 95 12:39:31 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9509111639.AA14451@BayNetworks.com> To: jnc@ginger.lcs.mit.edu, perry@piermont.com Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Precedence: bulk > > Perry E. Metzger writes: > > Unfortunately, Cisco is basically the only backbone router vendor > right now, Bay Networks stuff not being BGP-4 capable. > Wrong! Bay Networks has been supporting BGP-4 and classless routing for quite a while. > Noel Chiappa writes: > > Above and beyond that, even assuming we manage to split the routing up among > several processors in the trivial way (i.e. have different processors to talk > to different peers), now you've got several processors poking into the same > database (to figure out who's got the best route to X), so you've got some > "interesting" interlock issues. E.g. what % of data accesses are to shared > data? What % of them will need to lock it? How much overhead will that lock > take (and does your multiprocessor have hardware support for locking), etc, > etc, etc. > > And then Barney Wolff writes: > > Folks, Noel's point, which some seem unwilling or unable to grasp, is > that neither BGP4 nor OSPF have been parallelized. Until that's done, > you can run them on a million-processor machine with no gain in speed. > > The voice of experience says that it will not be trivial, nor > outstandingly effective, to parallelize route computation. Believe it, > or not - your choice. But don't assume that it's been done and is > just awaiting the right hardware to run it on. > There is nothing to assume -- it has been done! Parallel routing has always been the focus of Bay Networks architecture. On some Bay's systems you can install up to 13 identical processor card which are capable to perform coordinated routing computations. It is like having a few highly coordinated routers in the same box. In particular, the Bay's BGP-4 is highly parallelized: bgp connections can be distributed among multiple processor card with each processor performing only protocol functions and route processing associated with the bgp peers assigned to it. It also possible to leave some processor cards to perform only forwarding functions utilizing routing information which has been processed on other cards. From what I can see from field deployments and intensive in-house simulations such a distributed architecture scales very well in the presence of big routing tables and heavy routing flaps. Dimitry From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 03:02:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04235; Tue, 12 Sep 1995 03:02:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA00282; Tue, 12 Sep 1995 03:00:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA00188; Tue, 12 Sep 1995 02:42:23 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03136; Tue, 12 Sep 1995 02:42:14 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id JAA07051; Mon, 11 Sep 1995 09:48:33 -0700 Date: Mon, 11 Sep 1995 09:48:32 -0700 (PDT) From: Michael Dillon To: Noel Chiappa Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: Size of routers In-Reply-To: <9509111528.AA03418@ginger.lcs.mit.edu> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 11 Sep 1995, Noel Chiappa wrote: > If the people who are customers of NSP's refuse to accept topological > addressing due to a perception that it is restraint of trade, then there > will *NEVER* be topological addressing on the IPv4 Internet. Period. > > I think you're mistaken there. Customers who refuse to accept topological > addresses may find a provider to take them, but they may also find themselves > with large portions of the Internet that they cannot reach, due to their > addresses being filtered out of routing tables in large parts of the 'net. > > The 'net is, after all, a trans-national cooperative anarchy; who are you > going to call to enforce putting your route in their tables? Big money customers have all sorts of levers that they can use to get NSP's to do what they want. If they sign a contract with NSP A that isn't bulletproof because the marketroids who wrote it don't fully understand the cooperative anarchy, then a big money customer may very well start throwing their weight around with threats of lawsuits at NSP A. If NSP A then claims that our agreements with NSP B do not require them to do thus and such, then Big Money customer may be able to demand and get copies of the contracts between NSP A and NSP B. Once again, if the contract language was not carefully chosen, NSP A and B may both find themselves under threat of lawsuit from Big Money customer, or worse, they may find themselves subject to anti-trust or RICO type investigations. As long as Internet connectivity delivers access to the global Internet there is little chance of this happening. I keep thinking that there must be some way to solve this problem by applying parallelism that would allow much larger routing tables than we have at present. Some way of partitioning the tables so that all routers do not require the same tables. Put the shorter prefixes in one set of routers and deliver optimal routes, shunt the longer prefixes off to other routers that deliver slightly less than optimal routes. In a sense, this is what Cisco has done in their boxes by supplying a separate route processor which works in parallel with the SSP. We like to think that the size and power of the route processor should be similar to that of the SSP because it always has been, but why should this be a given. One way to deal with a globally pervasive IPv4 Internet is to work on partitioning the task of the route processor in such a way that we can grow it orders of magnitude beyond the size of the SSP's. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 03:41:27 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05929; Tue, 12 Sep 1995 03:41:27 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA00353; Tue, 12 Sep 1995 03:36:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA00322; Tue, 12 Sep 1995 03:19:12 +1000 Received: from frankenstein.piermont.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05084; Tue, 12 Sep 1995 03:19:03 +1000 (from perry@frankenstein.piermont.com) Received: from localhost (perry@localhost) by frankenstein.piermont.com (8.6.12/8.6.12) with SMTP id NAA13755; Mon, 11 Sep 1995 13:18:44 -0400 Message-Id: <199509111718.NAA13755@frankenstein.piermont.com> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol To: dhaskin@baynetworks.com (Dimitry Haskin) Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: oops -- wrong message In-Reply-To: Your message of "Mon, 11 Sep 1995 12:39:31 EDT." <9509111639.AA14451@BayNetworks.com> Reply-To: perry@piermont.com X-Reposting-Policy: redistribute only with permission Date: Mon, 11 Sep 1995 13:18:36 -0400 From: "Perry E. Metzger" Precedence: bulk Dimitry Haskin writes: > > Perry E. Metzger writes: > > > > Unfortunately, Cisco is basically the only backbone router vendor > > right now, Bay Networks stuff not being BGP-4 capable. > > Wrong! Bay Networks has been supporting BGP-4 and classless routing > for quite a while. Can the things take enough memory to play core router? Perry From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 03:51:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06386; Tue, 12 Sep 1995 03:51:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id DAA00407; Tue, 12 Sep 1995 03:47:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA00347; Tue, 12 Sep 1995 03:34:56 +1000 Received: from Kitten.mcs.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05642; Tue, 12 Sep 1995 03:34:50 +1000 (from karl@Mcs.Net) Received: from Jupiter.mcs.net (Jupiter.mcs.net [192.160.127.89]) by kitten.mcs.com (8.6.10/8.6.9) with ESMTP id MAA16950; Mon, 11 Sep 1995 12:34:40 -0500 Received: (from karl@localhost) by Jupiter.mcs.net (8.6.11/8.6.9) id MAA21201; Mon, 11 Sep 1995 12:34:05 -0500 From: Karl Denninger Message-Id: <199509111734.MAA21201@Jupiter.mcs.net> Subject: Re: Size of routers To: louie@uu.net (Louis A. Mamakos) Date: Mon, 11 Sep 1995 12:34:00 -0500 (CDT) Cc: karl@Mcs.Net, perry@piermont.com, tli@cisco.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, inet-access@earth.com In-Reply-To: from "Louis A. Mamakos" at Sep 11, 95 11:29:41 am X-Mailer: ELM [version 2.4 PL24] Content-Type: text Content-Length: 2366 Precedence: bulk > > > > This is one of the reasons that I initiated discussions, and ultimately got > > MFS to back, MAE-Chicago, now called "Mae-Central". > > > > Now, why is it that all the big guys have yet to show interest and/or sign > > up for service there? You might argue that the NAP does what they need, but > > that's not (obviously) true -- just from the participant list alone. > > > > If the nationals aren't going to make a REAL effort at diversity and > > locality of routing, then their backbones ARE going to melt. They *have > > to*, as capacity which seems volumnous today will look constrained tomorrow > > and like a little garden hose in a year. > > Part of this is a marketing issue with MFS. UUNET/Alternet will > connect to MAE-Chicago of some of the other major backbone operators > do as well. I don't know if, for example, ANS, MCI, PSI, or > Sprintlink have announced their intentions or not. > > Louis A. Mamakos, Manager of Network Engineering louie@uu.net, uunet!louie > UUNET Technologies, Inc. Voice: +1 703 206 5823 > 3060 Williams Drive Fax: +1 703 206 5908 > Fairfax, VA 22031 That's enlightening, even if disheartening. The fact is that geographic routing is good for *everyone* out here, large national and smaller regionals alike. We'd LOVE to offload our traffic to you, and for you to do so to us, here in Chicago. It would be good for our customers, and good for *your customers*, including one who is REALLY upset at the poor connectivity that your backbone has exhibited when seen from our network lately (due to the problems at Mae-East). This isn't just a "national guys only club" -- the regional carriers must also be included, and peered with, if we are all to survive the next few years. Alternet is physically about 50' away from the Chicago MAE in their cage -- why not call up MFS and order up that circuit today? Our Cisco 7000 stands ready to talk to you. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice: [+1 312 803-MCS1] | 7 Chicagoland POPs, ISDN, 28.8, much more Fax: [+1 312 248-9865] | Email to "info@mcs.net" WWW: http://www.mcs.net ISDN - Get it here TODAY! | Home of Chicago's *Three STAR A* Clarinet feed! From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 04:22:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08144; Tue, 12 Sep 1995 04:22:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA00496; Tue, 12 Sep 1995 04:16:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA00471; Tue, 12 Sep 1995 04:00:25 +1000 Received: from serendip.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06712; Tue, 12 Sep 1995 04:00:22 +1000 (from bac@serendip.sdsc.edu) Received: by serendip.sdsc.edu (940816.SGI.8.6.9/920502.SGI.AUTO) id KAA00587; Mon, 11 Sep 1995 10:59:04 -0700 From: bac@serendip.sdsc.edu (Bilal Chinoy) Message-Id: <199509111759.KAA00587@serendip.sdsc.edu> Subject: Re: Distributed systems To: dennis@mci.net (Dennis Ferguson) Date: Mon, 11 Sep 1995 10:58:58 -0700 (PDT) Cc: avg@sprint.net, michael@junction.net, tli@cisco.com, asp@uunet.uu.net, bass@cais.cais.com, bass@linux.silkroad.com, big-internet@munnari.OZ.AU, bilse@eu.net, jnc@ginger.lcs.mit.edu, smd@cesium.clock.org In-Reply-To: <95Sep11.122405-0400_edt.196374+9@romford.reston.mci.net> from "Dennis Ferguson" at Sep 11, 95 12:23:49 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 4364 Precedence: bulk Dennis: (The paper you are referring to is "Injecting Inter-AS routes into Intra-AS routing: A performance analysis", written by Yakov and I, circa 1991. Can be retrieved from http://www.nlanr.net/Papers/isr.html). We studied NSFnet backbone traces across all 16 ingress/egress points and, based on route "productivity", found that approx 85 % of desinations could be served by 5 % of route table size, which was, if i remember right, about 2000 entries. A significant win ! Cache update bandwidth etc. were studied as functions of update timeouts. Yes, I too have been tracking the locality of destination references in traffic at aggregation points , and have seen a *marked decrease* in concentration. I attribute this mainly to a) The growing ubiquity of the Internet. When .edu ruled the world, most traffic went to a handful of class A/B's at MIT, Stanford, WU, etc. The big guys were much bigger than the small guys, in a traffic source/sink sense. b) The Web. Our local Fire Department runs a Web server, seeing HTTP requests from all over the world. Kinda spoils destination concentration, does'nt it ? More importantly, this trend continues, as you also point out. This fundamental traffic characteristic has changed quite dramatically over the last few years. In addition, the added complexity of aggregated FIB entries, longest match, and route fault determination makes an active cache based FIB limiting strategy questionable, IMHO. Any distributed route processor-forwarding engine solution will have to contend with the above trend. Tnx, --Bilal > > >>The route processor is supposed to stop this from happening by feeding > >>the SSP a subset of the full routing table. > > > > Yet another myth. The cache footprint for core routes is at about 40% > > of the full table. It may as well be that *not* doing cacheing will > > actually save memory in the forwarding tables (and would certainly make > > the whole design a lot more robust). The bugs in software seem to > > be in the top three reasons for the Internet's unrealiability. > > > > SL-MAE-E#sh ip ca > > IP routing cache 12686 entries, 1859004 bytes > > Minimum invalidation interval 2 seconds, maximum interval 5 seconds, > > MCI's hottest routers run with closer to 80% of the full table in the > cache, e.g. > > core.wtn#show ip ca > IP routing cache 23911 entries, 3545372 bytes > > This fraction has continuously grown over the 6 months I've been paying > attention, from about 65% in April. > > Not that this necessarily tells you a whole lot, since that number does > depend critically on the strategy used for flushing entries out of the > cache as well, but I do have another data point. If you stay up until > the wee hours of the morning (to avoid breaking anything), and flush > the cache on one of those routers, the load won't come off the RP > until over 50% of the full forwarding table is back in the cache. > > This result is a direct contradiction to work done by Bilal Chinoy > and Hans-Werner Braun some time ago using data sampled on the T1 NSFnet, > which suggested that forwarding-path caching was indeed attractive with > respect to the size of the full forwarding table. The fact that this > has changed may be a result of changing characteristics of applications > people use, or may be a consequence of the relative success of CIDR > at keeping the growth rate of the forwarding table below the growth > rate of the Internet as a whole. We're getting increasingly less dead > weight in forwarding tables. > > In any case suggesting a scheme which relies on forwarding-path demand > caching for some benefit, without presenting supporting data concerning > the traffic carried by the network being designed for, is engineering > something without any evidence of it being useful. All the indications > I have suggest that forwarding-path caching is no longer of any benefit > when building high-end routers, and has considerable drawbacks. > > Dennis Ferguson > > P.S. I also agree about the software complexity of caching. Despite > having burned months, or years, of good quality programmer time in > efforts to keep it functioning I think the fact that Cisco 7000's > do demand caching in the forwarding path is the root cause of about > 80% of all evils with those boxes for high-end uses. Life is too short... > From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 04:38:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09000; Tue, 12 Sep 1995 04:38:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA00573; Tue, 12 Sep 1995 04:36:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA00559; Tue, 12 Sep 1995 04:31:52 +1000 Received: from hubbub.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB08541; Tue, 12 Sep 1995 04:31:48 +1000 (from yakov@cisco.com) Received: from puli.cisco.com (puli.cisco.com [171.69.1.174]) by hubbub.cisco.com (8.6.12/CISCO.GATE.1.1) with SMTP id LAA03977; Mon, 11 Sep 1995 11:31:43 -0700 Message-Id: <199509111831.LAA03977@hubbub.cisco.com> To: bac@serendip.sdsc.edu (Bilal Chinoy) Cc: big-internet@munnari.OZ.AU Subject: Re: Distributed systems In-Reply-To: Your message of "Mon, 11 Sep 95 10:58:58 PDT." <199509111759.KAA00587@serendip.sdsc.edu> Date: Mon, 11 Sep 95 11:31:42 PDT From: Yakov Rekhter Precedence: bulk Bilal, > Yes, I too have been tracking the locality of destination > references in traffic at aggregation points , and > have seen a *marked decrease* in concentration. I attribute > this mainly to > > a) The growing ubiquity of the Internet. When .edu ruled > the world, most traffic went to a handful of class A/B's > at MIT, Stanford, WU, etc. The big guys were much bigger than > the small guys, in a traffic source/sink sense. > > b) The Web. Our local Fire Department runs a Web server, > seeing HTTP requests from all over the world. Kinda spoils > destination concentration, does'nt it ? > > More importantly, this trend continues, as you also > point out. This fundamental traffic characteristic has > changed quite dramatically over the last few years. > > In addition, the added complexity of aggregated FIB > entries, longest match, and route fault determination makes an > active cache based FIB limiting strategy questionable, IMHO. > Any distributed route processor-forwarding engine solution will > have to contend with the above trend. Just to add, I think one of the reasons we see this trend is that a CIDR-aggregated route can cover many more destinations than a single class C network. That is, CIDR caused an increase in the number of destinations covered by a route. Yakov. From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 04:41:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09136; Tue, 12 Sep 1995 04:41:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA00593; Tue, 12 Sep 1995 04:39:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA00525; Tue, 12 Sep 1995 04:24:04 +1000 Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08145; Tue, 12 Sep 1995 04:22:45 +1000 (from dhaskin@BayNetworks.com) Received: from BayNetworks.com (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA13911; Mon, 11 Sep 95 14:20:36 EDT Received: from andover.engeast by BayNetworks.com (4.1/SMI-4.1) id AA20237; Mon, 11 Sep 95 14:21:46 EDT Date: Mon, 11 Sep 95 14:21:46 EDT From: dhaskin@BayNetworks.com (Dimitry Haskin) Message-Id: <9509111821.AA20237@BayNetworks.com> To: perry@piermont.com Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Precedence: bulk > From perry@frankenstein.piermont.com Mon Sep 11 13:19:25 1995 > X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol > To: dhaskin@BayNetworks.com (Dimitry Haskin) > Cc: big-internet@munnari.oz.au, com-priv@lists.psi.com > Subject: Re: oops -- wrong message > Reply-To: perry@piermont.com > X-Reposting-Policy: redistribute only with permission > Date: Mon, 11 Sep 1995 13:18:36 -0400 > From: "Perry E. Metzger" > Content-Length: 346 > > > Dimitry Haskin writes: > > > Perry E. Metzger writes: > > > > > > Unfortunately, Cisco is basically the only backbone router vendor > > > right now, Bay Networks stuff not being BGP-4 capable. > > > > Wrong! Bay Networks has been supporting BGP-4 and classless routing > > for quite a while. > > Can the things take enough memory to play core router? > > Perry > They definitely can. Our routers with 32M of memory boards has been tested with more than 50,000 unique routes. See the Bradner test report on ndtl/harvard.edu in pub/ndtl/results/test_lab/Wellfleet/routing. Internally, we also have tested our routers with more than 500,000 redundant routes; i.e. 10 bgp peers, each one connected to a different processor card and each one advertising an identical set of 60,000 routes. Dimitry From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 04:58:55 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09863; Tue, 12 Sep 1995 04:58:55 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id EAA00670; Tue, 12 Sep 1995 04:56:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA00566; Tue, 12 Sep 1995 04:36:40 +1000 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08894; Tue, 12 Sep 1995 04:36:28 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA12556; Mon, 11 Sep 95 13:56:27 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA06461; Mon, 11 Sep 95 13:36:26 CDT Date: Mon, 11 Sep 95 13:36:26 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9509111836.AA06461@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: Distributed systems Precedence: bulk It's worth pointing out that caching will work better for routers at the edges of the core than in the middle, and in the early days, I suspect there was a lot less core and a lot more edge. At least, the naive analysis suggests that this is the case. Am I wrong in guessing that these 80% of forwarding table in cache boxes are more or less way in the middle? By middle, I think I mean something like equidistant from all routers with a default route, or some such thing. Andrew From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 05:57:09 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12197; Tue, 12 Sep 1995 05:57:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA00761; Tue, 12 Sep 1995 05:56:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA00743; Tue, 12 Sep 1995 05:41:40 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11594; Tue, 12 Sep 1995 05:41:34 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id MAA27037; Mon, 11 Sep 1995 12:40:57 -0700 Date: Mon, 11 Sep 1995 12:40:57 -0700 From: Tony Li Message-Id: <199509111940.MAA27037@greatdane.cisco.com> To: kozowski@structured.net Cc: big-internet@munnari.OZ.AU In-Reply-To: <199509111327.GAA18561@chaos.structured.net> (message from Eric Kozowski on Mon, 11 Sep 1995 06:27:27 -0700) Subject: Re: Size of routers Precedence: bulk >> And cisco can keep producing new boards that have later chips on them >> too. > >You *could*, but you haven't done so in the past. For how many years >did you sell 25Mhz '040s in your top of the line routers? I'm no hardware expert (and probably not an expert at anything), but it seems to me that it wouldn't have been too hard to come out with a CPU upgrade for the 7000. Either a faster 040 or an 060. Was there some reason that it wasn't offered? Just curious. You'll note that our hardware boys have been rather busy with some other projects... ;-) You should also note that they turned out the 64Mb RP and the 2Mb SSP just for us. Tony From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 06:00:20 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12339; Tue, 12 Sep 1995 06:00:20 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA00783; Tue, 12 Sep 1995 05:58:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA00741; Tue, 12 Sep 1995 05:41:32 +1000 Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11588; Tue, 12 Sep 1995 05:41:28 +1000 (from louie@uunet.uu.net) Received: from localhost by rodan.UU.NET with SMTP id QQzgtq22813; Mon, 11 Sep 1995 15:41:19 -0400 Message-Id: To: Karl Denninger Cc: perry@piermont.com, tli@cisco.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, inet-access@earth.com From: "Louis A. Mamakos" Subject: Re: Size of routers In-Reply-To: Your message of "Mon, 11 Sep 1995 12:34:00 CDT." <199509111734.MAA21201@Jupiter.mcs.net> Date: Mon, 11 Sep 1995 15:41:18 -0400 Sender: louie@uunet.uu.net Precedence: bulk > That's enlightening, even if disheartening. > > The fact is that geographic routing is good for *everyone* out here, large > national and smaller regionals alike. We'd LOVE to offload our traffic to > you, and for you to do so to us, here in Chicago. It would be good for our > customers, and good for *your customers*, including one who is REALLY upset > at the poor connectivity that your backbone has exhibited when seen from > our network lately (due to the problems at Mae-East). > > This isn't just a "national guys only club" -- the regional carriers must > also be included, and peered with, if we are all to survive the next few > years. > > Alternet is physically about 50' away from the Chicago MAE in their cage -- > why not call up MFS and order up that circuit today? Connections to these things are made for sound business and engineering reasons. I also have to rank the priorities of various expansions that we're in the process of doing, and if I can get a big portion of traffic off-loaded by connecting to MAE-Chicago, then we'll do it sooner rather than later. There's no "national guys only club" going on here, there's just too much to do, and it all can't be done first. It would also be nice to know who's going to appear at the peering point, which makes the justification of another monthly expenditure for "backbone" costs easier to conjure up. Louis A. Mamakos, Manager of Network Engineering louie@uu.net, uunet!louie UUNET Technologies, Inc. Voice: +1 703 206 5823 3060 Williams Drive Fax: +1 703 206 5908 Fairfax, VA 22031 From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 06:17:37 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13115; Tue, 12 Sep 1995 06:17:37 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA00832; Tue, 12 Sep 1995 06:16:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA00803; Tue, 12 Sep 1995 06:06:17 +1000 Received: from greatdane.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12504; Tue, 12 Sep 1995 06:04:57 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id NAA28696; Mon, 11 Sep 1995 13:03:32 -0700 Date: Mon, 11 Sep 1995 13:03:32 -0700 From: Tony Li Message-Id: <199509112003.NAA28696@greatdane.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: bass@linux.silkroad.com, tli@cisco.com, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9509111317.AA02330@ginger.lcs.mit.edu> (jnc@ginger.lcs.mit.edu) Subject: Re: Topological vs. Administrative Aggregation Precedence: bulk You'll note that some of the other players were Noel ("but it's got a mongo scaling problem") Actually, as I recall, I think the main reason I wasn't totally thrilled with IDPR was that it perpetuated this silly (well, *I* think it's silly :-) distinction between EGP's and IGP's. (I seem to recall some chant about "running it straight on the metal"! :-) I also recall that you thought that the lack of hierarchy was a serious drawback. And superdomains didn't get added until much later... I should note that I agree about the distinction between EGP's and IGP's. However, what's NOT silly is the administrative separation between inter-domain and intra-domain information. This doesn't really need to be reflected in the global routing architecture tho. One might simply posit features added to the protocol(s) to make the distinction of trustworthiness clear. For generalities sake, you'd want to do this by designating certain areas as intra-domain. Tony From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 06:20:14 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13324; Tue, 12 Sep 1995 06:20:14 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA00854; Tue, 12 Sep 1995 06:18:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA00820; Tue, 12 Sep 1995 06:10:56 +1000 Received: from netcom2.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12870; Tue, 12 Sep 1995 06:10:21 +1000 (from bsw@netcom.com) Received: by netcom2.netcom.com (8.6.12/Netcom) id NAA05173; Mon, 11 Sep 1995 13:04:53 -0700 From: bsw@netcom.com (Bruce Sterling Woodcock) Message-Id: <199509112004.NAA05173@netcom2.netcom.com> Subject: Re: Size of routers... To: perry@piermont.com Date: Mon, 11 Sep 1995 13:04:53 -0700 (PDT) Cc: tli@cisco.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509110609.CAA13288@frankenstein.piermont.com> from "Perry E. Metzger" at Sep 11, 95 02:09:39 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1553 Precedence: bulk > > If you think that the 7500 isn't hot, you've obviously been nowhere > > near one. > > Thank you for the advertising promotional, Tony, but lets face facts > -- for years you sold a box witha a 25Mhz '040 in it. The ink is > barely dry on the ads for the 7500. Who knows how long it will be > until another upgrade to your CPU? And how long was it before there was a substantial market that *needed* as faster router? Even the current 7000s are not usually fully utilized, even on backbone routers. The new 7500 is, at the most, a year late. That's not too bad, especially considering it would be hard to sell the product *before* people thought they needed it. Very few people 2-3 years ago were honestly believing the growth rate would be this high. Few people expected Al Gore and Tom Brokaw to be telling people to get on the Internet. Again, perhaps you have a specific problem with Cisco. Fine. Perhaps they won't be able to keep up with "standard UNIX hardware" and will ultimately go out of business. That's the way the market works. But I think they'll give it a shot rather than conceed defeat now. I also don't think that it's any sort of triumph of "staandard UNIX hardware" over a dedicated appliance design like a router. Bruce -- Bruce Sterling Woodcock --- Systems Administrator ][ sterling@netcom.com The views and opinions expressed in this message ][ sterling@netapp.com are not necessarily those of NETCOM nor of my ][ sterling@well.com current employer, Network Appliance Corporation. ][ sterling@egbt.org From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 06:20:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13332; Tue, 12 Sep 1995 06:20:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA00876; Tue, 12 Sep 1995 06:19:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA00805; Tue, 12 Sep 1995 06:06:58 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12547; Tue, 12 Sep 1995 06:05:16 +1000 (from bsw@netcom.com) Received: from netcom2.netcom.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03644 Tue, 12 Sep 1995 06:04:57 +1000 (from bsw@netcom.com) Received: by netcom2.netcom.com (8.6.12/Netcom) id MAA04454; Mon, 11 Sep 1995 12:59:05 -0700 From: bsw@netcom.com (Bruce Sterling Woodcock) Message-Id: <199509111959.MAA04454@netcom2.netcom.com> Subject: Re: Size of routers To: perry@piermont.com Date: Mon, 11 Sep 1995 12:59:04 -0700 (PDT) Cc: tli@cisco.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509110559.BAA12004@frankenstein.piermont.com> from "Perry E. Metzger" at Sep 11, 95 01:58:57 am X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1911 Precedence: bulk > Ignoring the question of caching forwarding tables (which I think is > of limited utility given how big the caches get), I think that > building routers out of stock hardware to do routing protocols tightly > coupled to custom hardware to do the packet switching is far more > likely to yield designs that can be easily upgraded to the hottest > extant processors than the current methodology of building fully > custom computers. A standard unix box that handles the BGP portion of > the routing problem and downloads full routing tables into a custom > switch processor via a PCI bus or S-Bus or whateverbus interface has > the distinct advantage that you can keep replacing the unix box with > better faster ones that have a mass market. Again, there is nothing about a "standard UNIX box" (whatever that is... does the PDP-11 qualify?) that makes it magically more upgradable than a piece of dedicated network appliance hardware. For instance, the original FAServer used a off-the-shelf ASUS 486 motherboard with EISA slots. The current F330 uses a Pentium with PCI. We do have to qualify boards from other vendors (because frankly, they often don't work under high loads), but they are otherwise as upgradable as any other PC or UNIX box. You seem to have a gripe against Cisco's hardware design in general, or the 68040 in specific. Or perhaps CISC vs. RISC. But these are all beside the point. You may doubt the ability of Cisco to deliver a faster router over the years, but that doesn't mean that router vendors in general cannot, or that "standard UNIX boxes" are the only means to do so. Bruce -- Bruce Sterling Woodcock --- Systems Administrator ][ sterling@netcom.com The views and opinions expressed in this message ][ sterling@netapp.com are not necessarily those of NETCOM nor of my ][ sterling@well.com current employer, Network Appliance Corporation. ][ sterling@egbt.org From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 07:17:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15406; Tue, 12 Sep 1995 07:17:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA00975; Tue, 12 Sep 1995 07:16:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA00960; Tue, 12 Sep 1995 06:58:22 +1000 Received: from rainbow.dgsys.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14895; Tue, 12 Sep 1995 06:58:19 +1000 (from justin@rainbow.dgsys.com) Received: (from justin@localhost) by rainbow.dgsys.com (8.6.11/8.6.9) id RAA04049; Sun, 10 Sep 1995 17:06:14 -0400 Date: Sun, 10 Sep 1995 17:06:04 -0400 (EDT) From: Justin Newton To: Noel Chiappa Cc: perry@piermont.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com, jnc@ginger.lcs.mit.edu Subject: Re: oops -- wrong message In-Reply-To: <9509091910.AA27341@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sat, 9 Sep 1995, Noel Chiappa wrote: > > Now, if you had to change your PBX in the US because of changes in the > *English* numbering plan, that would be analogous, but of course the phone > net doesn't work that way. > That is because phone systems work on the equivalent of a "default route" setup. If the phone number isn't local, then it goes to Bell Atlantic (or whoever). Bell Atlantic then routes it to Sprint, MCI, if it is long distance. It is all working on default pre-defined routes. Noone's PBX is multi-homed between, say, Bell Atlantic and Ameritech. They just aren't When they are you can argue your point. If you want a multi-homed provider you pay for it. If you want default route, well then do it. Justin Newton * You have to change just to stay caught up. Vice President/ * System Administrator * Digital Gateway Systems * From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 07:25:36 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15710; Tue, 12 Sep 1995 07:25:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04933 Tue, 12 Sep 1995 07:21:16 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA00997; Tue, 12 Sep 1995 07:18:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA00957; Tue, 12 Sep 1995 06:57:35 +1000 Received: from linux.silkroad.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14886; Tue, 12 Sep 1995 06:57:30 +1000 (from bass@linux.silkroad.com) Received: by linux.silkroad.com id AA03003 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Mon, 11 Sep 1995 16:57:18 -0400 From: Tim Bass Message-Id: <199509112057.AA03003@linux.silkroad.com> Subject: Re: Topological vs. Administrative Aggregation To: tli@cisco.com (Tony Li) Date: Mon, 11 Sep 1995 16:57:18 -0400 (EDT) Cc: jnc@ginger.lcs.mit.edu, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <199509112003.NAA28696@greatdane.cisco.com> from "Tony Li" at Sep 11, 95 01:03:32 pm X-Mailer: ELM [version 2.4 PL24 PGP2] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1510 Precedence: bulk Thanks for the initial open discussions on IDPR vis-a-via Nimrod. I have not had the privilege to read any drafts on Nimrod and am just finding time to read the historical docs on IDPR; and therefore don't have any preference or opinions toward one or the other, except some initial reactions: 1) IDPR appears to be an excellent work that was (is) more complex to implement during the early address-space panic days; 2) BGP4 would have probally been judged at the time to be 'faster to the rescue' than IDPR and therefore BGP4 received more immediate attention from the net and router vendor gurus; 3) Nimrod and IDPR seem to have very similar roots based on the same concept, but there are historical and technical differences that I would like to understand more about ... Guess I'll start at http://nimrod-www.bbn.com:8000/Nimrod/front.html Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+ From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 07:59:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16911; Tue, 12 Sep 1995 07:59:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA01071; Tue, 12 Sep 1995 07:56:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA01054; Tue, 12 Sep 1995 07:49:24 +1000 Received: from ns.iij.ad.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16521; Tue, 12 Sep 1995 07:48:37 +1000 (from davidc@iij.ad.jp) Received: from shiosai.iij.ad.jp (shiosai.iij.ad.jp [192.244.176.35]) by ns.iij.ad.jp (8.6.12+2.4W/3.3W9-NS) with SMTP id GAA21182; Tue, 12 Sep 1995 06:47:18 +0900 Message-Id: <199509112147.GAA21182@ns.iij.ad.jp> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: SEAN@SDG.DRA.COM, big-internet@munnari.OZ.AU, davidc@ns.iij.ad.jp Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Sun, 10 Sep 1995 12:01:47 -0400." <9509101601.AA29608@ginger.lcs.mit.edu> Date: Tue, 12 Sep 1995 06:47:18 +0900 From: David R Conrad Precedence: bulk >Unfortunately, to this day, the people >allocating addresses often don't seem to have a good grasp of the effects of >what they are doing on the routing. I think all allocation registries are quite aware of what the allocations do to the routing, namely nothing. Allocation affects the free pool of IPv4 address space. The only way an allocation can affect routing is if the people with the routers accept the network for routing. Only at that point does the allocation affect routing. [As an aside, I'd claim the current policy of allocating a /24 regardless of whether or not the request justifies a /24 is wasting ridiculous amounts of address space, but I've argued this before and gotten nowhere] However, with that said, APNIC guarantees (as much as it guarantees anything) that an allocation to a service provider is at least a /19 (generally shorter). I believe InterNIC and RIPE-NCC is operating in a similar fashion (with minor differences). Further, in the case of provider-independent allocations, all registries explicitly state the addresses allocated may not be routable on the Internet. Given that the IAB has indicated that registries must allocate addresses to those who ask, I'm not exactly sure what else we (the registries) can do. One could argue the position of the IAB is not in the best interests of an operational Internet in the near term, but I'm tired of tilting after that particular windmill. Regards, -drc From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 08:17:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17813; Tue, 12 Sep 1995 08:17:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA01111; Tue, 12 Sep 1995 08:16:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA01089; Tue, 12 Sep 1995 07:58:33 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16865; Tue, 12 Sep 1995 07:58:17 +1000 (from gherbert@crl.com) Received: from crl3.crl.com by mail.crl.com with SMTP id AA10609 (5.65c/IDA-1.5); Mon, 11 Sep 1995 13:54:02 -0700 Message-Id: <199509112054.AA10609@mail.crl.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: gherbert@crl.com, big-internet@munnari.OZ.AU Subject: Re: Size of routers In-Reply-To: Your message of "Mon, 11 Sep 1995 10:11:21 EDT." <9509111411.AA02664@ginger.lcs.mit.edu> Date: Mon, 11 Sep 1995 13:54:02 -0700 From: George Herbert Precedence: bulk Noel writes: >Now that you're done insulting me for being "too academic", can we get back >to the technical, engineering issues at hand? I was replying to some mail which indicated that you thought some of us weren't up on the relevant theory, which I believe was at least partially incorrect and somewhat irrelevant. That aside, my response was excessively argumentative and I appologize to you and the list. -george william herbert From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 08:57:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19619; Tue, 12 Sep 1995 08:57:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id IAA01183; Tue, 12 Sep 1995 08:56:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA01177; Tue, 12 Sep 1995 08:55:28 +1000 Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19420; Tue, 12 Sep 1995 08:55:10 +1000 (from smart@mel.dit.csiro.au) Received: from koel.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA15796 (5.65c/IDA-1.4.4/DIT-1.3 for big-internet@munnari.oz.au); Tue, 12 Sep 1995 08:54:39 +1000 Message-Id: <199509112254.AA15796@shark.mel.dit.csiro.au> To: mobile-ip@tadpole.com, mbone@isi.edu, big-internet@munnari.OZ.AU Cc: postel@isi.edu Subject: Standardizing IPIP usage. Date: Tue, 12 Sep 1995 08:54:39 +1000 From: Bob Smart Precedence: bulk IP encapsulation is being used or proposed for: - experimental protocols, notably multicast and IPng experiments. - mobile IP. - improving the scalability of the Internet. - full packet encryption for ESP. [This uses the protocol code for IPIP but no IPIP packet need be created. However if there is a working IPIP subsystem then blindly copying the protocol field and sending the packet back to the IP subsystem will work.] Perhaps the time has come to think about how IPIP should be implemented in hosts and routers to a. Ensure that all these applications co-operate. b. Address the extra security problems associated with IPIP. Maybe there is already work on this. If so then let me know. If not then read on. One of the security risks is that users will use IPIP to sneak in protocols that Network Managers don't trust. At the moment we filter IPIP based on destination because we know that if it goes to a multicast tunnel then the tunnel will discard any non-multicast IPIP packets. More sophisticated filtering will be needed in the future if Network Managers are going to restrict IPIP to only some specific applications. At the end system there should to be a single point for incoming IPIP packets. [The alternative is a nit-style interface where, for example, the mobile and multicast systems both receive all the packets and discard the ones they don't want. This is much more error-prone: e.g. who sends "dest unreachable" for packets which are discarded by both?] Incoming packets need to be filtered before being decapsulated and dropped into the IP subsystem. Machines which are not meant to be routers should only accept packets meant for themselves. It is also quite likely that some machines should only forward certain types of packets: perhaps only multicast or perhaps only certain mobile destinations. Perhaps the kernels need to be enhanced so that IP forwarding is not just an on/off thing, or perhaps this check needs to be done in the IPIP filter. The filtering of incoming packets needs to look at the degree of authentication of the packet and of the encapsulated packet. For the encapsulated packet this will probably be the AH authentication. For the outer packet this could be the AH authentication or could just be that it comes from a local machine and the combination of router filtering and physical security gives you confidence in packets from that machine. At any rate the normal rule for filtering needs to be: accept packets for protocols which are harmless or which come from trusted hosts with appropriate authentication. There may not be any need for a unified system for outgoing encapsulated packets. Each subsystem that wants to do encapsulation can have its own code to do it, presumably in what seems to the IP system to be an interface. However having a unified output path for encapsulations would avoid some code duplication, for example in fragmentation. One of the options we should be able to specify is fragmentation behaviour. The "IP within IP" Internet Draft from the Mobile-IP group (ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-ip4inip4-00.txt) says the "don't fragment" bit should be copied from the inner packet. However it is highly desirable for the sender to do MTU discovery and then pre-fragment the inner packet so that the outer packet won't need to be fragmented. One can imagine situations where the destination in the outer packet is an anycast address (i.e. there are various routers which will accept that address as their own and decapsulate and forward the packet) in which case it is essential that the "don't fragment" bit be set on the outer packet because the fragments might otherwise arrive at different routers. --------------------------------------------------------------------------- Is all this is obvious? Or would it be useful to have some standards or at least an informational RFC about it? Bob Smart Robert.Smart@dit.csiro.au Network Services Group CSIRO Division of Information Technology phone: +61 3 9282 2625 723 Swanston St, Carlton VIC 3053, Australia fax: +61 3 9282 2600 P.S. Jon Postel is in the Cc list because he is listed in the Assigned Numbers RFC (1700) as the owner of the IPIP protocol number. From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 09:17:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20413; Tue, 12 Sep 1995 09:17:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id JAA01228; Tue, 12 Sep 1995 09:16:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA01222; Tue, 12 Sep 1995 09:15:59 +1000 Received: from chaos.structured.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20252; Tue, 12 Sep 1995 09:15:16 +1000 (from kozowski@structured.net) Received: (from kozowski@localhost) by chaos.structured.net (8.6.10/Structured_8.6.12) id QAA25115; Mon, 11 Sep 1995 16:13:37 -0700 Date: Mon, 11 Sep 1995 16:13:37 -0700 From: Eric Kozowski Message-Id: <199509112313.QAA25115@chaos.structured.net> To: tli@cisco.com Subject: Re: Size of routers Cc: big-internet@munnari.OZ.AU Precedence: bulk > >> And cisco can keep producing new boards that have later chips on them > >> too. > > > >You *could*, but you haven't done so in the past. For how many years > >did you sell 25Mhz '040s in your top of the line routers? > > I'm no hardware expert (and probably not an expert at anything), but it > seems to me that it wouldn't have been too hard to come out with a CPU > upgrade for the 7000. Either a faster 040 or an 060. Was there some > reason that it wasn't offered? Just curious. > >You'll note that our hardware boys have been rather busy with some >other projects... ;-) You should also note that they turned out the >64Mb RP and the 2Mb SSP just for us. No, I realize the situation. I just thought (which doesn't mean a whole lot) that sropping in a faster 040 would have been a fairly easy task. Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski@structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1 From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 11:01:58 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25592; Tue, 12 Sep 1995 11:01:58 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id KAA01349; Tue, 12 Sep 1995 10:56:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA01330; Tue, 12 Sep 1995 10:45:44 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24931; Tue, 12 Sep 1995 10:45:23 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12616 Tue, 12 Sep 1995 10:44:37 +1000 (from tli@cisco.com) Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id RAA23462; Mon, 11 Sep 1995 17:41:04 -0700 Date: Mon, 11 Sep 1995 17:41:04 -0700 From: Tony Li Message-Id: <199509120041.RAA23462@greatdane.cisco.com> To: mobile-ip@Tadpole.COM Cc: mobile-ip@Tadpole.COM, mbone@isi.edu, big-internet@munnari.OZ.AU, postel@isi.edu In-Reply-To: <199509112254.AA15796@shark.mel.dit.csiro.au> (message from Bob Smart on Tue, 12 Sep 1995 08:54:39 +1000) Subject: Re: (mobile-ip) Standardizing IPIP usage. Precedence: bulk Perhaps the time has come to think about how IPIP should be implemented in hosts and routers Little late... We shipped it quite a while ago. ;-) a. Ensure that all these applications co-operate. b. Address the extra security problems associated with IPIP. Maybe there is already work on this. If so then let me know. If not then read on. One of the security risks is that users will use IPIP to sneak in protocols that Network Managers don't trust. At the moment we filter IPIP based on destination because we know that if it goes to a multicast tunnel then the tunnel will discard any non-multicast IPIP packets. More sophisticated filtering will be needed in the future if Network Managers are going to restrict IPIP to only some specific applications. One might do this by terminating the tunnel in a box and then filtering the output of the tunnel. Already shipped. ;-) At the end system there should to be a single point for incoming IPIP packets. [The alternative is a nit-style interface where, for example, the mobile and multicast systems both receive all the packets and discard the ones they don't want. This is much more error-prone: e.g. who sends "dest unreachable" for packets which are discarded by both?] Isn't this an implementation issue? One of the options we should be able to specify is fragmentation behaviour. The "IP within IP" Internet Draft from the Mobile-IP group (ftp://ds.internic.net/internet-drafts/draft-ietf-mobileip-ip4inip4-00.txt) says the "don't fragment" bit should be copied from the inner packet. However it is highly desirable for the sender to do MTU discovery and then pre-fragment the inner packet so that the outer packet won't need to be fragmented. I don't see these as being in conflict. If the host sets the DF bit, it's presumably doing MTU discovery. If it's a legacy host, then things still work. One can imagine situations where the destination in the outer packet is an anycast address (i.e. there are various routers which will accept that address as their own and decapsulate and forward the packet) in which case it is essential that the "don't fragment" bit be set on the outer packet because the fragments might otherwise arrive at different routers. While there's no true anycast in IPv4, yes that would be a problem. This seems sufficiently obscure that it could become text in the existing draft. Tony From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 11:21:21 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26505; Tue, 12 Sep 1995 11:21:21 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA01384; Tue, 12 Sep 1995 11:16:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA01333; Tue, 12 Sep 1995 10:52:32 +1000 Received: from balder.ssds.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25136; Tue, 12 Sep 1995 10:51:15 +1000 (from chris.swanson@ssds.com) Received: (from mail@localhost) by balder.ssds.com (8.6.9/8.6.9.SSDSnet-hub) id SAA06098; Mon, 11 Sep 1995 18:50:47 -0600 Received: from denver(134.127.16.1) by balder via smap (V1.3) id sma006093; Mon Sep 11 18:50:33 1995 Received: from freke.ssds.com (pc_cds.minneapolis.ssds.com [134.127.38.53]) by denver.ssds.com (8.6.9/8.6.9.SSDSnet-hub) with SMTP id SAA25568; Mon, 11 Sep 1995 18:50:27 -0600 Message-Id: <199509120050.SAA25568@denver.ssds.com> X-Sender: cds@sanjose.ssds.com X-Mailer: Windows Eudora Pro Version 2.1.2 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 11 Sep 1995 19:45:41 -0500 To: dhaskin@BayNetworks.com (Dimitry Haskin), perry@piermont.com From: Chris Swanson Subject: Re: oops -- wrong message Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Precedence: bulk Greetings, Having worked with Bay BCN's at SuperComputing and at Interop, I can say that I have seen them behaving quite nicely as BGP-4 classless peers with the backbone. Regards, -+Chris At 14.21 95-09-11 EDT, Dimitry Haskin wrote: > >> From perry@frankenstein.piermont.com Mon Sep 11 13:19:25 1995 >> X-Authentication-Warning: frankenstein.piermont.com: Host localhost didn't use HELO protocol >> To: dhaskin@BayNetworks.com (Dimitry Haskin) >> Cc: big-internet@munnari.oz.au, com-priv@lists.psi.com >> Subject: Re: oops -- wrong message >> Reply-To: perry@piermont.com >> X-Reposting-Policy: redistribute only with permission >> Date: Mon, 11 Sep 1995 13:18:36 -0400 >> From: "Perry E. Metzger" >> Content-Length: 346 >> >> >> Dimitry Haskin writes: >> > > Perry E. Metzger writes: >> > > >> > > Unfortunately, Cisco is basically the only backbone router vendor >> > > right now, Bay Networks stuff not being BGP-4 capable. >> > >> > Wrong! Bay Networks has been supporting BGP-4 and classless routing >> > for quite a while. >> >> Can the things take enough memory to play core router? >> >> Perry >> > >They definitely can. Our routers with 32M of memory boards has been tested >with more than 50,000 unique routes. See the Bradner test report on ndtl/harvard.edu >in pub/ndtl/results/test_lab/Wellfleet/routing. Internally, we also have tested >our routers with more than 500,000 redundant routes; i.e. 10 bgp peers, each one connected >to a different processor card and each one advertising an identical set of 60,000 routes. > >Dimitry > > / Chris Swanson ____/ ____/ ___ / ____/ Engineer ____ / ____ / /__/ / ____ / 8400 Normandale Lake Blvd #993 _______/ _______/ _______/ _______/ Bloomington, MN 55473 business driven technology solutions. (612) 921-2392 FAX (612) 921-2395 Um Yah Yah! From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 11:57:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28228; Tue, 12 Sep 1995 11:57:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA01447; Tue, 12 Sep 1995 11:56:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA01430; Tue, 12 Sep 1995 11:51:06 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27914; Tue, 12 Sep 1995 11:50:58 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id SAA13344; Mon, 11 Sep 1995 18:59:14 -0700 Date: Mon, 11 Sep 1995 18:59:12 -0700 (PDT) From: Michael Dillon To: Bruce Sterling Woodcock Cc: perry@piermont.com, tli@cisco.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Re: Size of routers In-Reply-To: <199509111959.MAA04454@netcom2.netcom.com> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 11 Sep 1995, Bruce Sterling Woodcock wrote: > Again, there is nothing about a "standard UNIX box" (whatever that is... > does the PDP-11 qualify?) that makes it magically more upgradable than > a piece of dedicated network appliance hardware. For instance, the > original FAServer used a off-the-shelf ASUS 486 motherboard with EISA > slots. The current F330 uses a Pentium with PCI. We do have to qualify > boards from other vendors (because frankly, they often don't work under > high loads), but they are otherwise as upgradable as any other PC or > UNIX box. Can I put an Alpha in a FASserver? Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 11:58:56 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28348; Tue, 12 Sep 1995 11:58:56 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id LAA01469; Tue, 12 Sep 1995 11:58:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA01427; Tue, 12 Sep 1995 11:48:41 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27704; Tue, 12 Sep 1995 11:48:18 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id SAA13322; Mon, 11 Sep 1995 18:56:46 -0700 Date: Mon, 11 Sep 1995 18:56:44 -0700 (PDT) From: Michael Dillon To: Bruce Sterling Woodcock Cc: perry@piermont.com, tli@cisco.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com Subject: Standard UNIX hardware is red herring In-Reply-To: <199509112004.NAA05173@netcom2.netcom.com> Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 11 Sep 1995, Bruce Sterling Woodcock wrote: > I also don't think that it's any sort of triumph of "staandard UNIX hardware" > over a dedicated appliance design like a router. I think that my suggestion of giving people the ABILITY to use standard UNIX hardware has created somewhat of a red herring here. Just because standard UNIX hardware is supported as a route processor doesn't mean that people MUST use standard UNIX hardware. There is still room for a route processing appliance if it can achieve significant gains over a standard UNIX system. I happen to believe that the appliance approach is not neccessary or beneficial in regards to route processors. On the other hand, switching and packet forwarding applications can clearly benefit from the appliance approach, i.e. Cisco's SSP. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 12:17:45 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29215; Tue, 12 Sep 1995 12:17:45 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA01512; Tue, 12 Sep 1995 12:16:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA01495; Tue, 12 Sep 1995 12:07:09 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28755; Tue, 12 Sep 1995 12:06:55 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id WAA05415; Mon, 11 Sep 1995 22:06:34 -0400 Date: Mon, 11 Sep 1995 22:06:34 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: Carl Hillsman Cc: "Michael F. Nittmann" , big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Sun, 10 Sep 1995, Carl Hillsman wrote: > On Sun, 10 Sep 1995, Michael F. Nittmann wrote: > for an isp that is planning on having multiple pops, being dual homed, > offering both dedicated and dialup access, where sould they get the > addresses from? the current upstream provider or the nic? Hopefully, your uptream provider will have a CIDR block they reserve for dual homed customers... Yeah, it's pipe dreams, but I'm going to try to do this soon. -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 12:58:33 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01443; Tue, 12 Sep 1995 12:58:33 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA01587; Tue, 12 Sep 1995 12:56:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA01570; Tue, 12 Sep 1995 12:45:32 +1000 Received: from cesium.clock.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00870; Tue, 12 Sep 1995 12:45:29 +1000 (from smd@cesium.clock.org) Received: by cesium.clock.org id <6172>; Mon, 11 Sep 1995 19:43:59 -0700 From: Sean Doran To: bmanning@isi.edu, hal9001@panix.com, jnc@ginger.lcs.mit.edu Subject: Re: Keeping the Internet goingOA Cc: big-internet@munnari.OZ.AU, com-priv@lists.psi.com Message-Id: <95Sep11.194359pdt.6172@cesium.clock.org> Date: Mon, 11 Sep 1995 19:43:51 -0700 Precedence: bulk | or do I have to also pay a bribe to SprintNet to carry my "too long" | prefix if I am not a SprintNet linking customer. | | Well, this is the whole "routing settlements issue". Your provide would have | to pay all the major transit providers. I accept truckloads of good chocolate delivered to my home address. Sean. From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 12:58:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01459; Tue, 12 Sep 1995 12:58:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id MAA01610; Tue, 12 Sep 1995 12:58:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA01550; Tue, 12 Sep 1995 12:38:27 +1000 Received: from [204.71.127.3] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00450; Tue, 12 Sep 1995 12:38:15 +1000 (from carl@intrepid.net) Received: (from carl@localhost) by loki.intrepid.net (8.6.12/8.6.9) id WAA08633; Mon, 11 Sep 1995 22:25:35 -0400 Date: Mon, 11 Sep 1995 22:25:35 -0400 From: Carl Hillsman Subject: Re: Routing tables & what to do about them To: Dorian Rysling Kim Cc: "Michael F. Nittmann" , big-internet@munnari.OZ.AU In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 11 Sep 1995, Dorian Rysling Kim wrote: > On Sun, 10 Sep 1995, Carl Hillsman wrote: > > > On Sun, 10 Sep 1995, Michael F. Nittmann wrote: > > for an isp that is planning on having multiple pops, being dual homed, > > offering both dedicated and dialup access, where sould they get the > > addresses from? the current upstream provider or the nic? > > Hopefully, your uptream provider will have a CIDR block they reserve for > dual homed customers... Yeah, it's pipe dreams, but I'm going to try to > do this soon. what if your upstream provider is one of the big six? carl From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 13:37:15 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03378; Tue, 12 Sep 1995 13:37:15 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id NAA01675; Tue, 12 Sep 1995 13:36:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA01666; Tue, 12 Sep 1995 13:32:30 +1000 Received: from nic.hq.cic.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03019; Tue, 12 Sep 1995 13:32:16 +1000 (from dorian@CIC.Net) Received: (from dorian@localhost) by nic.hq.cic.net (8.6.12/8.6.12) id XAA06051; Mon, 11 Sep 1995 23:31:58 -0400 Date: Mon, 11 Sep 1995 23:31:58 -0400 (EDT) From: Dorian Rysling Kim X-Sender: dorian@nic.hq.cic.net To: Carl Hillsman Cc: "Michael F. Nittmann" , big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 11 Sep 1995, Carl Hillsman wrote: > > Hopefully, your uptream provider will have a CIDR block they reserve for > > dual homed customers... Yeah, it's pipe dreams, but I'm going to try to > > do this soon. > > what if your upstream provider is one of the big six? Well, then they should have at least /14 reserved for something like this, won't they? ;) -dorian ______________________________________________________________________________ Dorian Kim Email: dorian@cic.net 2901 Hubbard Drive Network Engineer Phone: (313)998-6976 Ann Arbor MI 48105 CICNet Network Systems Fax: (313)998-6105 http://www.cic.net/~dorian From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 14:37:23 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06538; Tue, 12 Sep 1995 14:37:23 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA01757; Tue, 12 Sep 1995 14:36:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA01736; Tue, 12 Sep 1995 14:18:41 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05473; Tue, 12 Sep 1995 14:17:57 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id XAA12329; Mon, 11 Sep 1995 23:50:31 -0400 Date: Mon, 11 Sep 1995 23:50:30 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Jon Crowcroft Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <624.810805207@cs.ucl.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 11 Sep 1995, Jon Crowcroft wrote: > > >BT is also a government regulated monopoly. Case closed. > > wrong: > > BT is one of 17 (last tiem i looked) licensed telcos in the UK > > jon > AT&T has a larger competition in the US but is still regulated as a monopoly because of it's commanding influence. Did BT renumber on it's own or in concert with the other 17? Were they acting as one on this issue? If they were then for all practical matters, they are one organization and not separately competing telcos on this issue. Sanjay Kapur From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 14:57:13 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07601; Tue, 12 Sep 1995 14:57:13 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA01810; Tue, 12 Sep 1995 14:56:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA01771; Tue, 12 Sep 1995 14:37:45 +1000 Received: from kbs.netusa.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06552; Tue, 12 Sep 1995 14:37:31 +1000 (from root@kbs.netusa.net) Received: (from root@localhost) by kbs.netusa.net (8.6.12/8.6.10) id AAA12480; Tue, 12 Sep 1995 00:10:17 -0400 Date: Tue, 12 Sep 1995 00:10:16 -0400 (EDT) From: Sanjay Kapur X-Sender: root@kbs To: Jon Crowcroft Cc: big-internet@munnari.OZ.AU Subject: Re: Routing tables & what to do about them In-Reply-To: <954.810805958@cs.ucl.ac.uk> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 11 Sep 1995, Jon Crowcroft wrote: > >together that has a significant enough market share to effectively > >control the industry it is in. > > you mean like cisco? > > jon > p.s. BT has around 50% of the uk data market, though it does have around > 98% of the uk POTS market... > cisco almost qualifies as a monopoly except that the existence of other vendors like Bay and Livingston give it enough competition for it to escape the scrutiny of the Justice Department in the US. Sanjay Kapur Kapur Business Systems, Inc. From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 16:21:06 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11723; Tue, 12 Sep 1995 16:21:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA01906; Tue, 12 Sep 1995 16:17:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01900; Tue, 12 Sep 1995 16:12:36 +1000 Received: from netcom7.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11226; Tue, 12 Sep 1995 16:12:02 +1000 (from bsw@netcom.com) Received: by netcom7.netcom.com (8.6.12/Netcom) id XAA29451; Mon, 11 Sep 1995 23:08:05 -0700 From: bsw@netcom.com (Bruce Sterling Woodcock) Message-Id: <199509120608.XAA29451@netcom7.netcom.com> Subject: Re: Size of routers To: michael@junction.net (Michael Dillon) Date: Mon, 11 Sep 1995 23:08:04 -0700 (PDT) Cc: bsw@netcom.com, perry@piermont.com, tli@cisco.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: from "Michael Dillon" at Sep 11, 95 06:59:12 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1384 Precedence: bulk > Can I put an Alpha in a FASserver? According to a recent article in one of the trade mags (no, I don't recall which one... we're in almost all of them the past week or two, announcing the F330), NetApp is working on an alpha FAServer. However, the CPU isn't exactly the issue. You can run into the same problems with "standard UNIX hardware"; i.e. "Can I put an Alpha in my Sun?" Well, perhaps not, but you can put more memory in your Sun, and put in an CDDI card, and so on. You can even put more processors in your Sun. You can upgrade the processor to faster versions of the SPARC, tho. By the same token, you could theoretically upgrade your FAServer 1400 to a 486DX4, but there are other limitations that you could run into, such as the speed of the EISA bus. Upgrading PC hardware, if that's being used for UNIX hardware, is also not always as easy as it sounds. You could wind up needing entirely new SIMMs, or new cards if your bus changes as well, etc. I see no reasons why routers can't be any different. And today, they already are, at least to some extent. Bruce -- Bruce Sterling Woodcock --- Systems Administrator ][ sterling@netcom.com The views and opinions expressed in this message ][ sterling@netapp.com are not necessarily those of NETCOM nor of my ][ sterling@well.com current employer, Network Appliance Corporation. ][ sterling@egbt.org From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 16:40:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12691; Tue, 12 Sep 1995 16:40:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA01942; Tue, 12 Sep 1995 16:36:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01936; Tue, 12 Sep 1995 16:29:28 +1000 Received: from netcom7.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11980; Tue, 12 Sep 1995 16:26:36 +1000 (from bsw@netcom.com) Received: by netcom7.netcom.com (8.6.12/Netcom) id XAA29613; Mon, 11 Sep 1995 23:09:54 -0700 From: bsw@netcom.com (Bruce Sterling Woodcock) Message-Id: <199509120609.XAA29613@netcom7.netcom.com> Subject: Re: Standard UNIX hardware is red herring To: michael@junction.net (Michael Dillon) Date: Mon, 11 Sep 1995 23:09:54 -0700 (PDT) Cc: bsw@netcom.com, perry@piermont.com, tli@cisco.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: from "Michael Dillon" at Sep 11, 95 06:56:44 pm X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 887 Precedence: bulk > There is still room for a > route processing appliance if it can achieve significant gains over a > standard UNIX system. I happen to believe that the appliance approach is > not neccessary or beneficial in regards to route processors. It may not be necessary. And the benefit might be too minor to make a difference. But, I think it's possible. This is just a disagreement of opinion here; nothing fundamental. > On the other hand, switching and packet forwarding applications can > clearly benefit from the appliance approach, i.e. Cisco's SSP. We definitely agree here. Bruce -- Bruce Sterling Woodcock --- Systems Administrator ][ sterling@netcom.com The views and opinions expressed in this message ][ sterling@netapp.com are not necessarily those of NETCOM nor of my ][ sterling@well.com current employer, Network Appliance Corporation. ][ sterling@egbt.org From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 17:19:34 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14232; Tue, 12 Sep 1995 17:19:34 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA02008; Tue, 12 Sep 1995 17:16:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA02004; Tue, 12 Sep 1995 17:14:29 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14093; Tue, 12 Sep 1995 17:14:26 +1000 (from tli@cisco.com) Received: from relay1.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01167 Tue, 12 Sep 1995 17:13:34 +1000 (from tli@cisco.com) Received: from greatdane.cisco.com by relay1.UU.NET with SMTP id QQzgvk19986; Tue, 12 Sep 1995 03:10:41 -0400 Received: (tli@localhost) by greatdane.cisco.com (8.6.8+c/8.6.5) id AAA13012; Tue, 12 Sep 1995 00:06:29 -0700 Date: Tue, 12 Sep 1995 00:06:29 -0700 From: Tony Li Message-Id: <199509120706.AAA13012@greatdane.cisco.com> To: huitema@pax.inria.fr Cc: big-internet@munnari.OZ.AU In-Reply-To: (huitema@pax.inria.fr) Subject: Re: Topological vs. Administrative Aggregation Precedence: bulk Size may well be the same, as in same number of lines in the table. Each line is a bit different though - don't need all these BGP-4 control informations. But most important are the dynamics. Mappings don't flap. Your switching tables still don't scale. Mappings would only work, however, if we can exhibit some form of "working set" effect. According to Vadim, there is no real benefit in caching in the core of the Internet. If I understand him correctly, the addresses he sees on transat links covers are spread all over the range. The only solution could be to perform the mapping near the fringes of the network, where you still have locality and working sets, and combine it with encapsulation so that the core routers don't have to look at anything but proper CIDR addresses. Swapping state in the (core) routers for state in the packets. An old trick. Correct. Thereby expanding the core significantly. Tony From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 17:26:44 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14568; Tue, 12 Sep 1995 17:26:44 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id RAA02032; Tue, 12 Sep 1995 17:23:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01990; Tue, 12 Sep 1995 16:59:18 +1000 Received: from sophia.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13420; Tue, 12 Sep 1995 16:58:50 +1000 (from huitema@pax.inria.fr) Received: from [45.190.136.23] by sophia.inria.fr (8.6.12/8.6.12) with SMTP id IAA25481; Tue, 12 Sep 1995 08:58:05 +0200 Date: Tue, 12 Sep 1995 08:58:05 +0200 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Tony Li From: huitema@pax.inria.fr (Christian Huitema) Subject: Re: Topological vs. Administrative Aggregation Cc: big-internet@munnari.OZ.AU Precedence: bulk At 2:00 AM 11/9/95, Tony Li wrote: >The general problem is that you still have to have a mapping from the >IPv4 address space to whatever other space you're routing on. And >that mapping table has the standard scaling problems if you're not >ALSO doing CIDR. If you're doing CIDR, then whatcha need other stuff >for? Size may well be the same, as in same number of lines in the table. Each line is a bit different though - don't need all these BGP-4 control informations. But most important are the dynamics. Mappings don't flap. Mappings would only work, however, if we can exhibit some form of "working set" effect. According to Vadim, there is no real benefit in caching in the core of the Internet. If I understand him correctly, the addresses he sees on transat links covers are spread all over the range. The only solution could be to perform the mapping near the fringes of the network, where you still have locality and working sets, and combine it with encapsulation so that the core routers don't have to look at anything but proper CIDR addresses. Swapping state in the (core) routers for state in the packets. An old trick. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 19:00:07 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18902; Tue, 12 Sep 1995 19:00:07 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id SAA02177; Tue, 12 Sep 1995 18:56:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA02148; Tue, 12 Sep 1995 18:35:20 +1000 Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17631; Tue, 12 Sep 1995 18:34:10 +1000 (from gherbert@crl.com) Received: from crl8.crl.com by mail.crl.com with SMTP id AA28139 (5.65c/IDA-1.5); Tue, 12 Sep 1995 00:42:09 -0700 Message-Id: <199509120742.AA28139@mail.crl.com> To: Sanjay Kapur Cc: Jon Crowcroft , big-internet@munnari.OZ.AU, gherbert@crl.com Subject: Re: Routing tables & what to do about them In-Reply-To: Your message of "Tue, 12 Sep 1995 00:10:16 EDT." Date: Tue, 12 Sep 1995 00:41:57 -0700 From: George Herbert Precedence: bulk Cisco doesn't qualify as a monopoly. Boeing wasn't a monopoly on making large jetliners. It was just the only company which bothered to make a 747-class plane. As recent events have shown (A330/340, MD-11) other companies can enter that market and compete once they decide they want to and it's worth it... same with Cisco. Other companies have solutions. They aren't being held back technically or by artificial means. -george From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 22:00:32 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25367; Tue, 12 Sep 1995 22:00:32 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id VAA02416; Tue, 12 Sep 1995 21:57:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA02399; Tue, 12 Sep 1995 21:49:50 +1000 Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25002; Tue, 12 Sep 1995 21:49:24 +1000 (from valdis@black-ice.cc.vt.edu) Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.Beta.14/8.7.Beta.14) with ESMTP id HAA16744; Tue, 12 Sep 1995 07:48:38 -0400 Message-Id: <199509121148.HAA16744@black-ice.cc.vt.edu> To: Simon Spero Cc: big-internet@munnari.OZ.AU Subject: Re: Saving the InterNet In-Reply-To: Your message of "Mon, 11 Sep 1995 09:06:30 PDT." From: Valdis.Kletnieks@vt.edu Date: Tue, 12 Sep 1995 07:48:37 -0400 Precedence: bulk On Mon, 11 Sep 1995 09:06:30 PDT, you said: > * build and deploy a network of high performance mail exploders > connected by application and/or internet level multicast, and > provide delivery agents capable of using this network to > operators of large, high-volume mailing lists. Even when BI > isn't thrashing as it has since 8/22, the vast bulk of incoming > mail I recieve is from mailing lists. Done. Eric Thomas' Listserv software definitely counts as high performance, using application level multicast. Contact sales@lsoft.com for more information. Valdis Kletnieks Computer Systems Engineer Virginia Tech P.S. Disclosure time: I know Eric, have dealt with him for over a decade, and we use his software to move well over a quarter of a million pieces of mail a day... From owner-Big-Internet@munnari.OZ.AU Tue Sep 12 23:40:19 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29201; Tue, 12 Sep 1995 23:40:19 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id XAA02585; Tue, 12 Sep 1995 23:36:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA02579; Tue, 12 Sep 1995 23:36:02 +1000 Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28946; Tue, 12 Sep 1995 23:35:35 +1000 (from Z.Wang@cs.ucl.ac.uk) Message-Id: <9509121335.28946@munnari.oz.au> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 12 Sep 1995 14:33:32 +0100 To: Valdis.Kletnieks@vt.edu Cc: Simon Spero , big-internet@munnari.OZ.AU Subject: Re: Saving the InterNet In-Reply-To: Your message of "Tue, 12 Sep 95 07:48:37 EDT." <199509121148.HAA16744@black-ice.cc.vt.edu> Date: Tue, 12 Sep 95 14:33:28 +0100 From: Zheng Wang Precedence: bulk >On Mon, 11 Sep 1995 09:06:30 PDT, you said: >> * build and deploy a network of high performance mail exploders >> connected by application and/or internet level multicast, and >> provide delivery agents capable of using this network to >> operators of large, high-volume mailing lists. Even when BI >> isn't thrashing as it has since 8/22, the vast bulk of incoming >> mail I recieve is from mailing lists. > >Done. Eric Thomas' Listserv software definitely counts as high >performance, using application level multicast. Contact >sales@lsoft.com for more information. Which version of listserv supports multicast? I did a search on lsoft's web page and could not find any reference to multicast (even in the full users manual). Cheers Zheng From owner-Big-Internet@munnari.OZ.AU Wed Sep 13 00:19:46 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01189; Wed, 13 Sep 1995 00:19:46 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA02688; Wed, 13 Sep 1995 00:16:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02650; Wed, 13 Sep 1995 00:09:40 +1000 Received: from tigger.jvnc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00647; Wed, 13 Sep 1995 00:08:49 +1000 (from dave@corecom.com) Received: from [192.67.239.213] (franklin-tty15.jvnc.net) by tigger.jvnc.net with SMTP id AA23603 (5.65c/IDA-1.4.4 for big-internet@munnari.OZ.AU); Tue, 12 Sep 1995 10:05:45 -0400 Date: Tue, 12 Sep 1995 10:05:45 -0400 X-Sender: corecom@tigger.jvnc.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Sanjay Kapur , Jon Crowcroft From: dave@corecom.com (David M. Piscitello) Subject: Re: Routing tables & what to do about them Cc: big-internet@munnari.OZ.AU Precedence: bulk Look, this is a silly exchange. It certainly has nothing to do with the subject line. Take it to com-priv... and *please* don't cross-post! At 12:10 AM 9/12/95, Sanjay Kapur wrote: >On Mon, 11 Sep 1995, Jon Crowcroft wrote: >> >together that has a significant enough market share to effectively >> >control the industry it is in. >> >> you mean like cisco? >> >> jon >> p.s. BT has around 50% of the uk data market, though it does have around >> 98% of the uk POTS market... >> > >cisco almost qualifies as a monopoly except that the existence of other >vendors like Bay and Livingston give it enough competition for it to >escape the scrutiny of the Justice Department in the US. > > >Sanjay Kapur >Kapur Business Systems, Inc. David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA USA 19025 dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Wed Sep 13 00:26:57 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01455; Wed, 13 Sep 1995 00:26:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA03216; Wed, 13 Sep 1995 00:24:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02643; Wed, 13 Sep 1995 00:01:23 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00273; Wed, 13 Sep 1995 00:01:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13301; Tue, 12 Sep 95 10:00:48 -0400 Date: Tue, 12 Sep 95 10:00:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509121400.AA13301@ginger.lcs.mit.edu> To: bass@linux.silkroad.com Subject: Re: Topological vs. Administrative Aggregation Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Precedence: bulk From: Tim Bass I have been considering the "provider based aggregation" vis-a-vis "administrative domain aggregation" ... Why not just simply aggregate the networks into the provider AS (s) and develop a simple Inter-domain routing protocol This is a mapping solution. Many have been discussed over the years. I personally still prefer ones that totally liberate the IPv4 "address" from any routing function at all, since that's what will give us the most flexibility down the line. (I.e. it's very powerful if 1.2.3.4 and 1.2.3.5 can be in totally different places.) Also, it allows us to get the largest possible bang out of our 32-bit buck (better even than CIDR, which does about as good as you can at using the 32-bits as a routing-name). The problem is that there's no way to do that total disconnect with a simple table (as KRE's scheme did). TANSTAAFL.... Then you get into the question of what to map into. Again, to me, the form that a routing-name ought to have (for reasons that I won't get into now, but they include ease of growing parts of the net without readdressing) is a variable length thing with a variable number of elements (like a file-name). The problem there is that means you have to have a whole bunch of new technology (you can't recycle stuff the way KRE's proposal did). TANSTAAFL.... So, the bottom line is, if you do a mapping solution, how radical a one do you pick; you have to analyse the cost/benefit tradeoffs. Doing a smaller (and cheaper and less painful) change may hand you a system you have to change again in a few years. Doing a larger one may mean you go off in the wrong direction. Etc, etc, etc... So, you either: - i) get into a very complicated optimization problem where you have to a) figure out where you want to be eventually (as best you can with your misty crystal ball), and b) figure out the best set of steps to get this large, working, system there; or - ii) throw up your hands and say "our vision isn't good enough, let's just take what looks like a good step". That's where I suspect we will not get any agreement by just debating here on Big-I. The IETF is a *wonderful* mechanism for *creating* open standards. It's a *horrible* mechanism for *picking* open standards... I think such choices are best left to the "open market" of the Internet as a whole. What gets deployed and used, wins. It appears as if IDPR incorportated many of the idea that the current proponents of alternatives are advocating ... But when I look in the Routing WGs in the IETF for Interdomain Routing .... references to 1477,1478, 1479, etc. are absent and only CIDR based BGP4 remains. It does appear that some very good alternatives have been presented years ago and the ideas are resurfacing from new observers and players. These well doumented ideas seemed very viable in 1993 and were somehow judged, too slow? Too complex? Hmmm. IDPR was a lot more than just a mapping scheme, it included some rather radical new directions in routing technology, and so why it didn't catch on is not a simple question. I called Martha to see what she thought, rather than give you my view from outside. She pointed to four factors: First, the size of the change. To go with IDPR, you had to be willing to buy into some pretty major changes. First, there was just a lot of stuff you had to do, and it wasn't a simple tweak. Then, there were radical and controversial technical aspects. There was the whole mapping from IPv4 addresses to AS's. In the tests they did, this was done with a table, but they also looked at keeping the mappings in the DNS. This is rather scary to people, that before you can forward a packet the DNS has to be up. (I know, there is a dependency loop issue, let's not get into the technical details now.) Then there was the whole notion of a setup, which is again rather radical. Etc, etc. Second, the capabilities that IDPR offered, over and above the other alternatives, were not seen as that important at the time. The ability to to policy/QOS/routing was not that interesting at that point. The business of the mapping meaning no renumbering for the routign to scale was just not anything people clued in on. Third, the lack of a big push, and someone to do the pushing, to convince the IETF that this was something they needed, wanted, should try, should use, etc, etc. Finally, "competition" (I put this in quotes since the protocols didn't really do the same thing) from BGP, which was seen as the alternative to IDPR. I think that this list is pretty accurate; individuals may have their own reasons why they weren't interested in IDPR, but I think this is a good summary of the reactions of the IETF as a whole. Noel From owner-Big-Internet@munnari.OZ.AU Wed Sep 13 01:25:10 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03513; Wed, 13 Sep 1995 01:25:10 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12612 Wed, 13 Sep 1995 00:44:57 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA03297; Wed, 13 Sep 1995 00:36:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA02851; Wed, 13 Sep 1995 00:20:56 +1000 Received: from ginger.lcs.mit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01286; Wed, 13 Sep 1995 00:20:48 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13377; Tue, 12 Sep 95 10:20:37 -0400 Date: Tue, 12 Sep 95 10:20:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9509121420.AA13377@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Reference list Cc: jnc@ginger.lcs.mit.edu Precedence: bulk For the benefit of those who are interested, here's a refernce list of material on hierarchical routing, put together after consulting with other people. There's not very much written, sigh. I have a few routing books, but very few have much in the way of coverage of hierarchical routing. (Routing as a whole would take forever to cover; there's a lot more stuff, but the CIDR argument is mostly about hierarchical.) The best of the lot is "Data Networks", by Bertsekas and Gallagher, which has about 4 pages. :-( That book does have the best coverage of routing theory of any of the books I have, though. Martha Steenstrup's new book (which I haven't seen yet) is also good on routing in general. Warning: the most detailed books on this are fairly dry and formal, so expect it to put you to sleep... A lot of the routing stuff (e.g. on stabilization times, etc) can be generalized to hierarchical schemes with a little work, so it's important to have a good grounding in general routing stuff. Anyway, that leaves you falling back onto academic papers. The Kleinrock and Kamoun paper is pretty fundamental, and is the place to start. Here's the citation: [Kleinrock] Leonard Kleinrock and Farouk Kamoun, "Hierarchical Routing for Large Networks: Performance Evaluation and Optimization", Computer Networks 1 (1977), North-Holland Publishing Co., pp. 155- 174. Any good CS library should have that. There is also McQuillan's PhD thesis, which has a rather large section (4.2, pp 325-377) on hierarchial routing: [McQuillan 74] John M. McQuillan, "Adaptive Routing Algorithms for Distributed Computer Networks", Report #2831, Bolt, Beranek and Newman, Cambridge, May 1974. That's available from the NTIS as AD-781 467 as well. There's another PhD thesis, but I don't know how to get ahold of it: [Hagouel] J. Hagouel, "Issues in Routing for Large and Dynamic Networks", Columbia University, New York, 1983. It is reported to be so-so. There is some more stuff, but it's pretty much dribs and drabs. There was some good work produced by the Survivable Packet Radio Network project at BBN about 15 years ago, but I don't have (as yet) any citations for tehm. As I mentnioned, I'm working on an Informational RFC called "Fundamentals of Routing and Addressing In Extremely Large Networks", which covers all this in English, to make this material all easily available to a wide audience (both distribution-wise, and comprehensibility-wise). It's incomplete, but it's up to 80K characters (I have a lot to add as a result of recent email :-). I hope to have an I-D out in a few months. Noel From owner-Big-Internet@munnari.OZ.AU Wed Sep 13 05:20:30 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12519; Wed, 13 Sep 1995 05:20:30 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA03855; Wed, 13 Sep 1995 05:17:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA03813; Wed, 13 Sep 1995 04:59:51 +1000 Received: from tremere.ios.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11793; Wed, 13 Sep 1995 04:59:39 +1000 (from mn@tremere.ios.com) Received: (from mn@localhost) by tremere.ios.com (8.6.9/8.6.9) id PAA04745; Tue, 12 Sep 1995 15:00:28 -0400 Date: Tue, 12 Sep 1995 15:00:27 -0400 (EDT) From: "Michael F. Nittmann" Subject: Re: some notions on a routing architecture - To: Andrew Molitor Cc: big-internet@munnari.OZ.AU In-Reply-To: <9509111622.AA03709@anubis.network.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 11 Sep 1995, Andrew Molitor wrote: > This is a set of random notes I've been working on in my spare > time. It draws some ideas from Nimrod (and may also resemble PIP, which > I am unfamiliar with, though obviously I should -- copious free time issues . . . > --------- > > The object here would be to make BGP pull data more or less on demand > instead of pushing everything always. The basic elements of the strategy might > work out to be: > > - teach BGP to forget things it can get from other BGP speakers as > needed. Good idea, it looks then like this: one router has the full alternates' set: *>i39.2.48.0/24 204.193.128.254 10 50 100 4136 3561 560 ? * 137.39.229.1 25 701 560 ? *>i39.2.189.0/24 204.193.128.254 10 50 100 4136 701 i * 137.39.229.1 25 701 i *> 39.2.254.0/24 137.39.229.1 25 701 1800 1804 1128 2043 766 i * 39.4.79.0/24 137.39.229.1 25 701 690 1128 1103 i *>i 204.193.128.254 15 50 100 4136 690 1128 1103 i *> 39.7.8.0/24 137.39.229.1 25 701 1800 i *> 39.7.88.0/24 137.39.229.1 25 701 1800 1883 1880 i *>i39.9.193.0/24 204.193.128.254 10 50 100 4136 701 2509 2497 i * 137.39.229.1 25 701 2509 2497 i *>i39.11.22.0/24 204.193.128.254 15 50 100 4136 690 1800 2838 i * 137.39.229.1 25 701 1800 2838 i *>i39.13.5.0/24 204.193.128.254 the other has: *> 39.0.174.0/24 204.193.128.254 10 0 4136 3673 1280 174 ? *> 39.1.28.0/24 204.193.128.254 10 0 4136 701 i *> 39.1.30.0/24 204.193.128.254 10 0 4136 701 286 286 i *> 39.2.5.0/24 204.193.128.254 0 4136 690 1800 1755 517 i *> 39.2.48.0/24 204.193.128.254 10 0 4136 3561 560 ? *> 39.2.189.0/24 204.193.128.254 10 0 4136 701 i *>i39.2.254.0/24 137.39.229.1 50 10 0 701 1800 1804 1128 2043 766 i *> 39.4.79.0/24 204.193.128.254 0 4136 690 1128 1103 i *>i39.7.8.0/24 137.39.229.1 50 10 0 701 1800 i *>i39.7.88.0/24 137.39.229.1 50 10 0 701 1800 1883 1880 i *> 39.9.193.0/24 204.193.128.254 10 0 4136 701 2509 2497 i *> 39.11.22.0/24 204.193.128.254 0 4136 690 1800 2838 i *> 39.13.5.0/24 204.193.128.254 0 4136 690 1128 3333 i *>i39.13.135.0/24 137.39.229.1 50 10 0 701 1239 1795 3463 i *> 39.13.229.0/24 204.193.128.254 10 0 4136 701 3557 i *> 39.13.233.0/24 204.193.128. The unused alternates are squeezed out. (this is not edited) > - teach BGP to query remote peers for information as needed. The emphasis should be also on remote here, not just adjacents. Although you might refer to your later discussed query-caching methodology. > - teach the forwarding path how to use either a 2-hop LSRR or > an IP-in-IP encap to get packets to an egress router, where > said router's forwarding path knows to strip the LSRR or > de-encap the packet. This will 1) keep the backbone IGP pond shallow and 2) could it have a hook to prefer paths for certain destinations? e.g. if there is a real time pipe desired, it should be kept on a fast track and not wiggle depending on the current load; should evenbe able to diaplace other traffic. > > In more detail: > > Forgetting > > Using published and globally agreed upon hash functions, any IPv4 > address can be hashed to a list or group of BGP speakers, based on something > like the top 3 octets of the address. Boxes in this list are 'authorities' > for networks hashing to them. Every BGP speaker should remember: > > - stuff for its one AS, anything attached to it, anything it learns > via its own IGP, in short. > - stuff discussing networks which contain nodes which hash to this > speaker (not every BGP speaker need be in the hash, presumably > a smaller set of the core routers will serve routes on demand, > and these need to maintain that portion of BGP data is sees > which pertains to the networks it will serve routes for). > - stuff for backbone networks. > > Anything else it learns should be used to build forwarding data > 'as if' it were to be used, and then that forwarding data should be > re-advertised, and then flushed. This means that the stuff advertised will You lost me here: re-advertise back to the sender? I don't do that and I don't let it in if anybody would. Where would this be necessary for? > be similar to, but not the same as, what is currently advertised, since > routes which would not normally be used to forward (if only we remembered > the better one we forgot a moment ago) will be advertised. This may or > may not have serious impacts, I have no real idea. I would like this idea: this enables to prep an alternate table on a route server which can be queried in case of a topology change. Would this not be flushed out for 'normal' routers, as in a couple of phrases before? > > Q: is the additional overhead of re-advertising essentially everything > consistant with our policy, as opposed to only the 'best of' such, > a show stopper? Can it be fixed? > > The upshot here is that something roughly similar to the current > BGP advertisements and policy will take place, but BGP speakers are free to > discard chunks of their BGP databases, and not even bother really installing > many routes into their forwarding tables. Further, every core router will The advantage is again the depth of the igp pond in the backbone, since less external stuff is added to the internal routing set. A real advantage if you do not run fully meshed BGP. But as show the tables before, squeezed tables save (some) memory too. > have a complete forwarding table for networks attached to its AS, and for > the networks comprising the core. Inter-AS traffic and Inter-core traffic > will forward as always, therefore. I guess this is already the case, at least if you run ospf and bgp only at the corners. I have no idea how this looks with is-is or so. > > I think that the routers which maintain BGP data for networks that > they are a hashed authority for will be able to construct optimal routes, > since the should be seeing everything. This isn't very important now, since ^^^^^^^^^^^^^^ isn't it only everything necessary for -this- network/AS ? > all we really need is the egress AS for a given network, but is a nice feature > to keep in one's back pocket. I might be wrong, my tiny little brain isn't > entirely convinced of this. > > Querying > > In place of a default route, in a default free router, software > for handling packets destined for somewhere not in the forwarding table > will generate a query. The globally agreed upon hashes are computed for I would be careful here: if someone sprays a nonexistant host this might result in a major meltdown. But we can put time locks on it: e.g., same algorigthm as for route dampening: some sawtooth rising with number of queries until it is not queried any longer at all,but with a constant breakthrough, say every 3 minutes, so we won't miss it when it actually comes up. > the destination address of the packet, to generate a list of core routers > to query. Something like a UDP datagram gets heaved to one or more of these > routers, triggering something like an UPDATE packed into another UDP datagram > in response. The essential information in this response is the IP address > of a suitable router in the AS attached to the destination network, this I would also keep the origin of the info that creates the cache entry, see later... > is all that's needed. This information is installed in a new forwarding > path data structure, handled cache-like. > > A sticky bit here is what to do when topology changes occur. Would > it be reasonable to have the BGP' agent snoop on the query cache and flush > entries which appear to no longer be valid, based on BGP PDUs flying into > the box? Remember that everyone sees everything, more or less, and can fiddle > around with the information for a while before forgetting it. The response > to topology changes is rather unclear to me, and is obviously of extreme > importance. ... if we cache the origin of the info in the cache entry to confirm or discard, we have a short path. Query right back and confirm. Yes, this can stick a route on a less favorable path. A new,better one might come up from a different router. But we would learn about that (that's why we still need some push for new routes). Only after this your algorithm should kick in as a default. If one of the originators of cache entries vanishes, the cache entries should be flagged right away as , but keep them in mind, to consolidate when the candidate wakes up again (time it out with a day or so). > > Forwarding > > The forwarding path first does the usual thing, and if it finds > the 'faux default' route, falls into some additional code, which queries > the cache-like structure mentioned above. If there's a hit, it either > stamps a suitable LSRR, or does IP-in-IP encapsulation, in either case > arranging to send the packet to the egress router learned through the new > BGP querying, for subsequent forwarding to the final destination. In the > event of a miss, a query is generated, and the packet queued pending a > response. I like the lsrr/ip-in-ip stuff, but I would rather treat those acquired routes exactly like all others and announce them to the bb igp. But: can we have such a lsrr/ip-in-ip to predefine certain paths. For bandwidth balancing between send/receive on the same Ts, and for preprogramming a path for data between centers that want some better real time performance. This would also allow for transit paths between NSPs, which could then even be bandwidth controlled. And for those who like the $ signs, charged for in a good way too. > > Routers need, in addition, to be able to detect the presence > of the LSRR or the IP-in-IP business, and removing the option, or > de-encapsulating suitably. > I would do this part on the route servers, until the router vendors do something like this. BTW: even within corporate networks, such a capability can be used for real time paths (robot control, video conferencing, flight simulators), and can piggyback virtual private networks over trusted physical paths. There is more interest to that than just the 'small' market of NSPs. If you bring a feature, there comes a use for it ... > Q: Is it really hard to add the stamping/encapsulating and unstamping/de-encap > to the forwarding path of various vendor's routers? (I know of one where > it's not all that tricky, but that vendor's not super interested in the > backbone market). > > Deployment > > This can be deployed incrementally, though no major benefits would be > seen until deployment is wide-scale. Owners of core routers need to indicate > willingness to be authorities for groups of hash values. When any owner of a > default free router knows about 'enough' authorities for a given hash (2 or > 3), they may configure their routers to forget forwarding information for > networks that hash to that value, and to query instead. Thus, there is an > initial (presumably small) memory hit for deploying the new BGP with some > additional data structures and code, thereafter you may trade off > routing/forwarding database space for LSRR/encap cache space, in a presumably > positive fashion. > > Scaling Properties > > The architecture lives and dies by the hit ratio in the LSRR/encap > cache. If that hit ratio becomes substantially less than 100%, instant you lost me here: I would have thought 'not less than 100%', because of that extra processing overhead on both ends and in the lsrr path (ip-in-ip is better in that part of the path, probably also at the end points, since it should be able to use canned headers here). > congestion and death by queuing ensues. By intelligent deployment, the > cache hit ratios may be raised, one hopes to reasonable levels. This > deployment strategy would involve placing the caches in the routers as > close to the edges of the backbone as possible. In the interior, there > is traffic to many destination networks flowing through the T3 mesh, with This is why I prefer bgp on the edges and an igp in the interior. I don't like fully meshed bgp for a lot of reasons, this here is one more. > the obvious cache busting behaviors. By getting the tranist frames LSRRd > or encapped as early as possible, the load on the interior routers drops > as more traffic has immediate destination in the set of routers on the > edge of the core. By doing the encapsulations close to the edge, the > number of different final destinations active (the required cache size) > should go down as the number of source networks sending traffic through > an edge router is presumably smaller. > > By splitting the edge up, using more routers on the edge, the > number of speakers is reduced, and (one hopes) the number of destination > networks per router, and hence the necessary LSRR/encap cache size, is > reduced. > Here I would even go further and use some integer number crunchers (yes, you don't need floating point for route processing) to do all this processing, and to route the encapsulated traffic. This would then make route servers that would be endpoints for certain special traffic. Needs more than a PC of course, multi processor sparc 10 should already be near what we need. Probably needs some extra tender love and care. (no, no serial interfaces from that box, all via LAN structures). The corresponding endpoint engines would then be within the AS at major aggregation points, because you need endpoints for that encapsulated stuff. Yes, this goes further than using those boxes just for transit through AS's to reach remote ones. That's the industrial application part of it. > Q: Is this analysis even close? > Looks very usable, and feasible in the short time (using rs topologies) to me. ------------------------------------------------------------------- Michael F. Nittmann mn@ios.com Senior Network Architect ------------ IDT/IOS - Internet Online Services ---------- 294 State Street -------- Hackensack, NJ 07601 ------ ---- +1 (201) 928 1000 xt. 500 -- +1 (201) 928 1057 FAX +1 (201) 441 5861 Pager \/ From owner-Big-Internet@munnari.OZ.AU Wed Sep 13 06:17:04 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14805; Wed, 13 Sep 1995 06:17:04 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA04024; Wed, 13 Sep 1995 06:16:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA03986; Wed, 13 Sep 1995 06:01:14 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14190; Wed, 13 Sep 1995 06:01:07 +1000 (from avg@sprint.net) Received: from titan.sprintlink.net by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA20609 Wed, 13 Sep 1995 06:01:03 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.9) id PAA15281; Tue, 12 Sep 1995 15:55:46 -0400 Date: Tue, 12 Sep 1995 15:55:46 -0400 From: Vadim Antonov Message-Id: <199509121955.PAA15281@titan.sprintlink.net> To: bass@linux.silkroad.com, jnc@ginger.lcs.mit.edu Subject: Re: Topological vs. Administrative Aggregation Cc: big-internet@munnari.OZ.AU Precedence: bulk Noel wrote: >I personally still prefer ones that totally liberate the IPv4 "address" from >any routing function at all, since that's what will give us the most >flexibility down the line. (I.e. it's very powerful if 1.2.3.4 and 1.2.3.5 can >be in totally different places.) Well, fixing DNS is easier than introducing one more level of indirection with all associated administrative overhead. It makes the system more complicated and as a result, less reliable. >Also, it allows us to get the largest >possible bang out of our 32-bit buck (better even than CIDR, which does about >as good as you can at using the 32-bits as a routing-name). You can map 32-bit "cookies" into TLAs in host software. >- ii) throw up your hands and say "our vision isn't good enough, let's just >take what looks like a good step". It is not the option. Or do you want M$ to run the show? They will produce all the visions of the "vision" the public wants. >That's where I suspect we will not get any agreement by just debating here on >Big-I. The IETF is a *wonderful* mechanism for *creating* open standards. It's >a *horrible* mechanism for *picking* open standards... I think such choices are >best left to the "open market" of the Internet as a whole. What gets deployed >and used, wins. Yep. And that means that providers will chose the technology they want to offer to the customers. Losers will lose. > [IDPR] >Third, the lack of a big push, and someone to do the pushing, to convince the >IETF that this was something they needed, wanted, should try, should use, >etc, etc. Hm. I've got the impression that the problem was in the complexity of the proposal, not the lack of "push". --vadim From owner-Big-Internet@munnari.OZ.AU Wed Sep 13 07:17:43 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16800; Wed, 13 Sep 1995 07:17:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA04183; Wed, 13 Sep 1995 07:16:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA04148; Wed, 13 Sep 1995 06:58:13 +1000 Received: from faline.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16232; Wed, 13 Sep 1995 06:58:06 +1000 (from little@faline.bellcore.com) Received: from faline (localhost [127.0.0.1]) by faline.bellcore.com (8.6.9/8.6.10) with ESMTP id QAA17048; Tue, 12 Sep 1995 16:57:52 -0400 Message-Id: <199509122057.QAA17048@faline.bellcore.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: Reference list In-Reply-To: Your message of "Tue, 12 Sep 1995 10:20:37 EDT." <9509121420.AA13377@ginger.lcs.mit.edu> Date: Tue, 12 Sep 1995 16:57:50 -0400 From: Mike Little Precedence: bulk Noel, Gee it's fun to see this routing discussion again ;-) To help out with your references I took a look in my routing folder and came up with: Greg Lauer's paper (Greg was at BBN) - "Hierarchical Routing Design For SURAN", Proceedings of 1986 IEEE Military Communications Conference, Oct 1986, pp. 4.2.1-4.2.10. I had always found this paper to be illustrative and useful. You may have seen this as a BBN report but I don't have a reference for it in that form. Kamoun and Klienrock, "Stochastic Performance Evaluation of Hierarchical Routing for Large Networks", Computer Networks, Vol. 3, 1979, pp 337-353. This paper and the one you mention should be considered together. Burchfiel, J., J. Westcott and G. Lauer, "Clustering Algorithms for Adaptive Hierarchical Organization of Large Networks", SRNTN-5, October 1983, BBN Laboratories Inc. Ramamoorthy, C. V. and W. Tsai, "An Adaptive Hierarchical Routing Algorithm", Proceedings of IEEE COMPSAC '83, Chicago, IL, Nov. 1983, pp. 93-104. Aceves, J., "A New Approach to Hierarchical Routing in Large Networks", Proceedings of 1987 IEEE Military Communications Conference, Oct 1987, pp. 10.7.1-10.7.7. Westcott, J. and G. Lauer, "Hiearchical Routing for Very Large Networks", Proceedings of 1984 IEEE Military Communications Conference, October 1984, pp. 16.1.1-16.1.5. The group of papers above provide background on features and considerations to be given in hierarchical routing design and evaluation. They also provide additional references that one might find useful after starting with the basics. The above group and many of the papers they reference probably fall into what you referred to as "more stuff, but it's pretty much dribs and drabs". And we shouldn't forget the work on hierarchical routing viz landmarks that Paul Tsuchiya and Bob Stine worked on, published by Paul as a pair of Mitre Reports (I could only located draft copies, one with an MTR-87W00174 designation). As always, it is unclear how far the current crop of routing aficionados are interested in pursuing the topic, but I remember how hard it was to dig up a lot of this information. The BBN report you may have been thinking of, if not the one above, could possibly one of the pair done by Ross and Greg: Callon, R. and G. Lauer, "Hierarchical Routing for Packet Radio Networks", SRNTN 31, June 1985, BBN Labs Inc. Callon, R. and G. Lauer, "More Issues in Hierarchical Routing", SRNTN 34, November 1985, BBN Labs Inc. Your forhtcoming RFC on routing in extremely large networks should be interesting as most of the work to date that deals with large networks consider networks of sizes we think of today as contemporary. Good luck. -Mike From owner-Big-Internet@munnari.OZ.AU Thu Sep 14 03:04:49 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04634; Thu, 14 Sep 1995 03:04:49 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA05262; Thu, 14 Sep 1995 02:57:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA05247; Thu, 14 Sep 1995 02:47:34 +1000 Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03958; Thu, 14 Sep 1995 02:47:30 +1000 (from valdis@black-ice.cc.vt.edu) Received: from localhost (LOCALHOST [127.0.0.1]) by black-ice.cc.vt.edu (8.7.Beta.14/8.7.Beta.14) with ESMTP id MAA17956; Wed, 13 Sep 1995 12:41:09 -0400 Message-Id: <199509131641.MAA17956@black-ice.cc.vt.edu> To: Zheng Wang Cc: big-internet@munnari.OZ.AU Subject: Re: Saving the InterNet In-Reply-To: Your message of "Tue, 12 Sep 1995 14:33:28 BST." <199509121334.JAA16578@black-ice.cc.vt.edu> From: Valdis.Kletnieks@vt.edu Date: Wed, 13 Sep 1995 12:41:09 -0400 Precedence: bulk On Tue, 12 Sep 1995 14:33:28 BST, Zheng Wang said: > Which version of listserv supports multicast? I did a search > on lsoft's web page and could not find any reference to > multicast (even in the full users manual). Umm.. the Listserv 'distribute' function is essentially application-level multicast, and has been working since 1985 or so. It computes a spanning tree across all the known Listserv servers. It's pretty well hidden away from users, you post to a mailing list and get it "free of charge". /Valdis From owner-Big-Internet@munnari.OZ.AU Thu Sep 14 14:42:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06471; Thu, 14 Sep 1995 14:42:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA05880; Thu, 14 Sep 1995 14:37:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA05874; Thu, 14 Sep 1995 14:31:23 +1000 Received: from RTD.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05941; Thu, 14 Sep 1995 14:30:34 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id VAA23161; Wed, 13 Sep 1995 21:29:36 -0700 From: Dave Siegel Message-Id: <199509140429.VAA23161@seagull.rtd.com> Subject: Re: oops -- wrong message To: mn@ios.com (Michael F. Nittmann) Date: Wed, 13 Sep 1995 21:29:36 -0700 (MST) Cc: dsiegel@rtd.com, big-internet@munnari.OZ.AU In-Reply-To: from "Michael F. Nittmann" at Sep 10, 95 08:40:54 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 930 Precedence: bulk > that's the goal of the game. Of course, to the outside the connection > will sink at one of my routers. some don't like to admit that something > is broken on their side and want to pull it down immediately at the > meetpoint, so the the other's routers show !H. No? > If it's a transcient, it is just some dropped packets. I hope to run new > gated soon with dampening (oh yes, what else, if 24hr day is not enough I > take the night too ...). And don't come , people, and call it > 'advertizing lies'. A flapping link is DOWN because it is unusable for > real traffic. yes, but should that customer be dual homed, you have just disallowed backup routing to kick in for Xperiod of time. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Thu Sep 14 15:08:09 1995 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07517; Thu, 14 Sep 1995 15:08:09 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from murtoa.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03365 Thu, 14 Sep 1995 15:06:29 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id OAA05922; Thu, 14 Sep 1995 14:57:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA05882; Thu, 14 Sep 1995 14:38:50 +1000 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06289; Thu, 14 Sep 1995 14:38:28 +1000 (from dsiegel@rtd.com) Received: from RTD.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01949 Thu, 14 Sep 1995 14:37:35 +1000 (from dsiegel@rtd.com) Received: (from dsiegel@localhost) by seagull.rtd.com (8.6.12/8.6.9.1) id VAA23230; Wed, 13 Sep 1995 21:31:57 -0700 From: Dave Siegel Message-Id: <199509140431.VAA23230@seagull.rtd.com> Subject: Re: oops -- wrong message To: perry@piermont.com Date: Wed, 13 Sep 1995 21:31:56 -0700 (MST) Cc: mn@ios.com, big-internet@munnari.OZ.AU, com-priv@lists.psi.com In-Reply-To: <199509110108.VAA11664@frankenstein.piermont.com> from "Perry E. Metzger" at Sep 10, 95 09:08:39 pm X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1071 Precedence: bulk > > > > my worst ospf convergence time is still below 100ms. I don't care if it > > > > would be 10 seconds. tcp can swallow 90 seconds without dropping > > > > > > Someday in the future your network is going to be used for carrying > > > realtime telephony and video. People will notice ten second dropouts. > > > > Right. But this is now the same case: such realtime support cannot be > > addressed by rerouting, which will always give a hit. > > The question is, how big a hit? If you lose a frame or two, no one > cares. Ten seconds is, however, an eternity. yep. > I'll point out that we are not currently working very hard in the > routing world to try to get re-routing to happen in faster and faster > intervals. We should. Actually, with route dampening, we are currently trying to do the opposite to avoid CPU overload.. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP." From owner-Big-Internet@munnari.OZ.AU Thu Sep 14 17:04:03 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12996; Thu, 14 Sep 1995 17:04:03 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id QAA06060; Thu, 14 Sep 1995 16:57:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA06054; Thu, 14 Sep 1995 16:57:08 +1000 Received: from diablo.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12658; Thu, 14 Sep 1995 16:56:20 +1000 (from doleary@cisco.com) Received: (doleary@localhost) by diablo.cisco.com (8.6.10/CISCO.SERVER.1.1) id XAA27576 for big-internet@munnari.oz.au; Wed, 13 Sep 1995 23:53:03 -0700 Date: Wed, 13 Sep 1995 23:53:03 -0700 From: "Dave O'Leary" Message-Id: <199509140653.XAA27576@diablo.cisco.com> To: big-internet@munnari.OZ.AU Subject: a couple more for the reference list Precedence: bulk Both of these are slightly historic, too.... Principles of Computer Communication Network Design J. Seidler, John Wiley and Sons, 1983. ISBN 0-85312-241-5 Two chapters on routing (about 140 pages), basic graph theory, network flows stuff. Path selection algorithms, about 2 pages on hierarchical routing which basically point to the K&K paper. Modeling and Analysis of Computer Communications Networks Jeremiah F. Hayes, Plenum Press, 1984. ISBN 0-306-41782-0 One chapter on routing/flow allocation. I don't think there is too much in here of relevance that isn't in Bertsekas and Gallager and B&G is probably a lot easier to find... dave From owner-Big-Internet@munnari.OZ.AU Sun Sep 17 03:05:00 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00963; Sun, 17 Sep 1995 03:05:00 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA09198; Sun, 17 Sep 1995 02:58:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA09181; Sun, 17 Sep 1995 02:47:49 +1000 Received: from okjunc.junction.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00237; Sun, 17 Sep 1995 02:47:45 +1000 (from michael@junction.net) Received: (from michael@localhost) by okjunc.junction.net (8.6.11/8.6.11) id JAA10043; Sat, 16 Sep 1995 09:56:35 -0700 Date: Sat, 16 Sep 1995 09:56:33 -0700 (PDT) From: Michael Dillon To: big-internet@munnari.OZ.AU Subject: New top level domains? Message-Id: Organization: we provide consulting re: Internet servers Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk If anyone is interested in discussing the procedures IANA should use for allocating and delegating new top-level domains there is a mailing list specifically for that discussion newdom@iiia.org send the following message subscribe newdom to the address newdom-request@iiia.org This would include things like competing registries (other than Internic) and possible changes to the system of root nameservers in order to deal with multiple competing name registries and to deal with scaling issues. It is hoped that newdom@iiia.org will be able to put together an Internet Draft document for consideration by IANA and that the list will be able to focus the discussions on constructive actions rather than debating whether past events are right or wrong. Thank you. Michael Dillon Voice: +1-604-546-8022 Memra Software Inc. Fax: +1-604-542-4130 http://www.memra.com E-mail: michael@memra.com From owner-Big-Internet@munnari.OZ.AU Wed Sep 20 02:05:52 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09397; Wed, 20 Sep 1995 02:05:52 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA12753; Wed, 20 Sep 1995 01:59:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA12736; Wed, 20 Sep 1995 01:48:10 +1000 Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08453; Wed, 20 Sep 1995 01:47:58 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA03476; Tue, 19 Sep 95 11:08:07 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA28160; Tue, 19 Sep 95 10:48:00 CDT Date: Tue, 19 Sep 95 10:48:00 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9509191548.AA28160@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: caching unreachable networks - Precedence: bulk Does anyone have some idea of how much of the cache (if any) next to the interfaces on core routers is devoted to holding entries pointing at unreachable networks? This has some relation to how much core traffic is goobers flailing away at things that don't exist. I'd expect none in the middle, and something between 'very few' and 'quite a few' in the routers near the edge. No particular reason beyond curiosity. These are things which appear in the cache that do NOT appear in the forwarding table, for the most part, so they're interesting. Andrew P.S. by the way, did I neglect some paperwork? Is there a form one needs to fill out to have one's pet deployment of trained seals theory of saving the internet cut to ribbons? From owner-Big-Internet@munnari.OZ.AU Sat Sep 23 15:43:53 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23142; Sat, 23 Sep 1995 15:43:53 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id PAA17189; Sat, 23 Sep 1995 15:40:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA17161; Sat, 23 Sep 1995 15:24:15 +1000 Received: from ACADEM.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22418; Sat, 23 Sep 1995 15:24:09 +1000 (from sob@academ.com) Received: (from sob@localhost) by academ.com (8.6.12/8.6.9) id AAA22898; Sat, 23 Sep 1995 00:23:59 -0500 Message-Id: <199509230523.AAA22898@academ.com> From: sob@academ.com (Stan Barber) Date: Sat, 23 Sep 1995 00:23:58 CDT X-Mailer: Mail User's Shell (7.2.5 10/14/92) To: big-internet@munnari.OZ.AU Subject: Recent discussion on address ownership from the latest NANOG Cc: nanog@merit.edu, pier@isi.edu Precedence: bulk For those of you who are interested, a set of notes I took during the last NANOG which (I hope) capture a discussion on address ownership. The URL for this page is: http://www.academ.com/nanog/sept1995/addresses.html Enjoy.... -- Stan | Academ Consulting Services |internet: sob@academ.com Olan | For more info on academ, see this |uucp: amdahl!academ!sob Barber | URL- http://www.academ.com/academ |Opinions expressed are only mine. From owner-Big-Internet@munnari.OZ.AU Tue Sep 26 00:28:11 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02328; Tue, 26 Sep 1995 00:28:11 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id AAA20043; Tue, 26 Sep 1995 00:20:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA20021; Tue, 26 Sep 1995 00:08:25 +1000 From: bmanning@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01512; Tue, 26 Sep 1995 00:08:21 +1000 (from bmanning@ISI.EDU) Received: from zed.isi.edu by venera.isi.edu (5.65c/5.61+local-22) id ; Mon, 25 Sep 1995 07:08:00 -0700 Posted-Date: Mon, 25 Sep 1995 07:04:59 -0700 (PDT) Message-Id: <199509251405.AA07596@zed.isi.edu> Received: by zed.isi.edu (5.65c/4.0.3-4) id ; Mon, 25 Sep 1995 07:05:00 -0700 Subject: Moores Law revisited To: big-internet@munnari.OZ.AU Date: Mon, 25 Sep 1995 07:04:59 -0700 (PDT) X-Mailer: ELM [version 2.4 PL24] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 293 Precedence: bulk "For the last five years, the number of machines on the network has been rising between five and 10 times faster than the number of transistors on a chip." `THE COMING SOFTWARE SHIFT' by George Gilder, Forbes, 8/8/95 Now if we can trust the data ol'George was working with... :) --bill From owner-Big-Internet@munnari.OZ.AU Tue Sep 26 06:41:51 1995 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB15232; Tue, 26 Sep 1995 06:41:51 +1000 (from owner-Big-Internet@munnari.OZ.AU) Return-Path: Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id GAA20418; Tue, 26 Sep 1995 06:41:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20397; Tue, 26 Sep 1995 06:35:55 +1000 Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15006; Tue, 26 Sep 1995 06:35:45 +1000 (from ses@tipper.oit.unc.edu) Received: from chivalry (chivalry.eit.COM [192.100.58.30]) by tipper.oit.unc.edu (8.6.12/8.6.10) with SMTP id QAA03530; Mon, 25 Sep 1995 16:35:37 -0400 Date: Mon, 25 Sep 1995 13:37:36 -0700 (PDT) From: Simon Spero X-Sender: ses@chivalry To: bmanning@ISI.EDU Cc: big-internet@munnari.OZ.AU Subject: Re: Moores Law revisited In-Reply-To: <199509251405.AA07596@zed.isi.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On Mon, 25 Sep 1995 bmanning@ISI.EDU wrote: > "For the last five years, the number of machines on the network has been > rising between five and 10 times faster than the number of transistors > on a chip." `THE COMING SOFTWARE SHIFT' by George Gilder, Forbes, 8/8/95 "With a rebel yell, she cried Moore, Moore, Moore".... Of course, the _real_ problem is that not only are we adding more networks, but we also want to do more complicated routing- policy based, more redundancy, load-balancing, etc. My general belief is that not only is renumbering going to be necessary, but we're also going to need FBSR (F... er Fairly Big Scale Routers), and better routing architectures (Nimrod, etc). More law: user expectations double every 3-6 magazine articles. Simon