From owner-Big-Internet@munnari.OZ.AU Fri Jun 3 02:14:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08894; Fri, 3 Jun 1994 01:00: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 AAA09781; Fri, 3 Jun 1994 00:59:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA09767; Fri, 3 Jun 1994 00:41:22 +1000 Precedence: list Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08099; Fri, 3 Jun 1994 00:41:15 +1000 (from mfox@wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA06824; Thu, 2 Jun 94 10:40:32 EDT Received: from urkel.wellfleet.com by pobox.wellfleet (4.1/SMI-4.1) id AA14828; Thu, 2 Jun 94 10:37:27 EDT Received: from mfox-en ([192.32.129.71]) by urkel.wellfleet.com (4.1/SMI-4.1) id AA22425; Thu, 2 Jun 94 10:40:50 EDT Message-Id: <9406021440.AA22425@urkel.wellfleet.com> X-Sender: mfox@urkel Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 02 Jun 1994 09:40:49 -0500 To: tcp-ip@nic.ddn.mil, ospf@gated.cornell.edu, bgpd@merit.edu, big-internet@munnari.OZ.AU, regional-techs@merit.edu From: mfox@wellfleet.com (Michael E. Fox) Subject: Route path simulator X-Mailer: Sorry for the cross posting but I thought input from all these groups might be beneficial. I'm looking for some type of simulation program that would enable a network manager to view the route taken by packets in a complex IP network that utilizes more than just hop-count metrics. Imagine a 100+ node network with link metrics ranging from 1 to 2000. The goal is to determine (quickly and easily) the path taken by a packet from any particular source point to any particular destination point without having to manually add up all of the metric combinations to determine the least cost path. Another goal is to be able to create a link failure and observe the new least cost path. Another goal is to be allow what-if scenarios where the network manager can change the metric on a given link(s) and see the result. Input to the simulation could be as simple as a flat file of point-to-point links and their associated metrics. Output could also be a character-based flat file. Graphical I/O would be ideal. Note: I'm not particularly interested in simulating traffic patterns with varying inter-arrival rates so something like Bones or CACI Network-II might be overkill. Besides, I don't even know if they can provide what I'm looking for above (can they?). On the other hand, viewing traffic patterns might come in handy later. Hmmmmm. Any suggestions? Michael Fox From owner-Big-Internet@munnari.OZ.AU Fri Jun 3 05:40:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21683; Fri, 3 Jun 1994 05:40: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 FAA10024; Fri, 3 Jun 1994 05:39:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA10021; Fri, 3 Jun 1994 05:25:44 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21020; Fri, 3 Jun 1994 05:25:40 +1000 (from sidhu@umbc.edu) Received: from umbc7.umbc.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA13070 Fri, 3 Jun 1994 05:25:31 +1000 (from sidhu@umbc.edu) Received: (from sidhu@localhost) by umbc7.umbc.edu (8.6.9/8.6.9) id PAA08599; Thu, 2 Jun 1994 15:24:05 -0400 Date: Thu, 2 Jun 1994 15:24:05 -0400 From: "Dr. Deepinder Sidhu (CMSC)" Message-Id: <199406021924.PAA08599@umbc7.umbc.edu> To: mfox@wellfleet.com (Michael E. Fox), regional-techs@merit.edu, big-internet@munnari.OZ.AU, bgpd@merit.edu, ospf@gated.cornell.edu, tcp-ip@nic.ddn.mil Subject: Re: Route path simulator Such a tool exists for seeing a packet path from any point to any point in large internets. For information about this tool, write to telenix@access.digex.net or call 410-750-2253 This tool has powerful features to specify scenarios and capacity planning and management features. From owner-Big-Internet@munnari.OZ.AU Fri Jun 3 17:00:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16521; Fri, 3 Jun 1994 17:00: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 RAA10616; Fri, 3 Jun 1994 17:00:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA10602; Fri, 3 Jun 1994 16:53:18 +1000 Precedence: list From: lazear@dockside.mitre.org Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13496; Fri, 3 Jun 1994 02:51:06 +1000 (from lazear@dockside.mitre.org) Received: from gateway.mitre.org by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA04486 Fri, 3 Jun 1994 02:50:55 +1000 (from lazear@dockside.mitre.org) Received: from dockside.mitre.org by gateway.mitre.org (5.61/SMI-2.2) id AA02912; Thu, 2 Jun 94 12:48:18 -0400 Received: by dockside.mitre.org.mitre.org (4.1/SMI-4.1) id AA13798; Thu, 2 Jun 94 12:46:19 EDT Message-Id: <9406021646.AA13798@dockside.mitre.org.mitre.org> To: mfox@wellfleet.com (Michael E. Fox) Cc: tcp-ip@nic.ddn.mil, ospf@gated.cornell.edu, bgpd@merit.edu, big-internet@munnari.OZ.AU, regional-techs@merit.edu, lazear@dockside.mitre.org Subject: Re: Route path simulator In-Reply-To: Your message of "Thu, 02 Jun 94 09:40:49 CDT." <9406021440.AA22425@urkel.wellfleet.com> Date: Thu, 02 Jun 94 12:46:17 -0400 As one approach to seeing whether a group of routers were acting correctly, I wrote some code to trace all possible routings in a network. The basic approach was to gather (via SNMP) all the routing tables of all the routers (SNMPv2 GetBulk could help keep this reasonable) and run through the routes for each subscriber net to every other subscriber net. This presumed a backbone set of routers and a known set of networks behind each "POP" router. The program took less than a second on a Sparc ELC, for 30+ routers and 100+ subscriber nets. The program highlighted long routes, loops (such as when defaults point to defaults that point back...), and dead ends. The diameter of the network was settable and "long" was defined as some amount above the diameter. The intent was to discover that "reasonable" routing was happening...there was no intent to insist on optimal routing. The snapshot of routing tables could be a blurred one, as dynamic routing protocols could be changing routing tables during the period of table collection. The same effect could be achieved by doing "traceroutes" from every subscriber network, but this gets messy. Overall, it was a fun exercise and the operational requirement was that you identify where each network attached to your backbone. Then you look at actual routing tables to see that your routing protocols were being reasonable about service. The program has been packaged and is available online: ftp://aelred-3.ie.org/pub/chkrtr.tar Enjoy and let me know any reactions to the scheme. Walt From owner-Big-Internet@munnari.OZ.AU Fri Jun 3 17:22:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15066; Fri, 3 Jun 1994 16:25: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 QAA10559; Fri, 3 Jun 1994 16:20:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA10556; Fri, 3 Jun 1994 16:17:23 +1000 Precedence: list Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03678; Fri, 3 Jun 1994 11:46:35 +1000 (from frankel@yu1.yu.edu) Received: from alsys1.aecom.yu.edu by shark.mel.dit.csiro.au with SMTP id AA27298 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 3 Jun 1994 11:46:08 +1000 Received: from yu1.yu.edu by alsys1.aecom.yu.edu with SMTP id AA27832 (5.67b/IDA-1.5/AECOM-RIT for ); Thu, 2 Jun 1994 21:40:57 -0400 Received: by yu1.yu.edu (AIX 3.2/UCB 5.64/4.03) id AA36853; Thu, 2 Jun 1994 21:40:39 -0400 Date: Thu, 2 Jun 1994 21:40:39 -0400 (EDT) From: Mervyn Frankel Subject: mailing list Cc: ospf@gated.cornell.edu, bgpd@merit.edu, big-internet@munnari.OZ.AU, regional-techs@merit.edu In-Reply-To: <9406021440.AA22425@urkel.wellfleet.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Please provide details of your mail list and how to subscribe From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 05:15:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11091; Tue, 7 Jun 1994 04: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 EAA14788; Tue, 7 Jun 1994 04:20:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA14780; Tue, 7 Jun 1994 04:10:43 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10230; Tue, 7 Jun 1994 04:10:16 +1000 (from crawdad@munin.fnal.gov) Received: from fnal.fnal.gov by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19209 Tue, 7 Jun 1994 04:10:00 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HD816SIH7400471C@FNAL.FNAL.GOV>; Mon, 6 Jun 1994 13:02:50 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA09749; Mon, 6 Jun 94 13:01:40 CDT Date: Mon, 06 Jun 1994 13:01:40 -0500 From: Matt Crawford Subject: Re: 8+8 addressing..... In-Reply-To: Your message of Mon, 06 Jun 94 17:11:36 -0100. <2543.bill.simpson@um.cc.umich.edu> To: bsimpson@morningstar.com Cc: sipp@sunroof.Eng.Sun.COM, big-internet@munnari.OZ.AU Message-Id: <9406061801.AA09749@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > Do we have rough consensus that 8 bytes is enough to identify all nodes, > and then can limit argument to whether or not to have a variable size > for the "locator" part? No. Nobody has given even a rough outline of a scheme for assigning globally unique identifiers of any particular size, given the widely (but not universally) held belief that IEEE 802 addresses are not It. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 05:26:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13725; Tue, 7 Jun 1994 05: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 FAA14868; Tue, 7 Jun 1994 05:20:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA14856; Tue, 7 Jun 1994 05:14:57 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06906; Tue, 7 Jun 1994 03:32:32 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-00.dialip.mich.net (pm002-00.dialip.mich.net [35.1.48.81]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA02873 for ; Mon, 6 Jun 1994 13:31:51 -0400 Date: Mon, 6 Jun 94 17:11:36 GMT From: "William Allen Simpson" Message-Id: <2544.bill.simpson@um.cc.umich.edu> To: sipp@sunroof.eng.sun.com Cc: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: 8+8 addressing..... > From: mo@uunet.uu.net (Mike O'Dell) > Folks, this is our big chance to make mobililty work really *right* > without complex cushion-shot routing tricks and other silliness. In my > mind, this is the *one* thing that makes EIDs worth having today, and > the 8+8 structure gives the routing richness which would allow lots of > cool ideas to be pursued with complete impunity. > > 8+8 - it's good for what ails us...... > > -Mike > I agree. Mobility is a strong concern of mine, too. Several folks sent messages to the SIPP list arguing for 8+8. I just disagree that both parts should be in one field. Frank K had an interesting analysis on the SIPP list that we need 8 to 24 bytes for the "locator" part of the address. Do we have rough consensus that 8 bytes is enough to identify all nodes, and then can limit argument to whether or not to have a variable size for the "locator" part? (In SIPP, the variable length locator is called a Routing Header.) Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 05:26:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13732; Tue, 7 Jun 1994 05:22: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 FAA14883; Tue, 7 Jun 1994 05:22:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA14862; Tue, 7 Jun 1994 05:15:53 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12227; Tue, 7 Jun 1994 04:48:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27805; Mon, 6 Jun 94 14:48:32 -0400 Date: Mon, 6 Jun 94 14:48:32 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406061848.AA27805@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, sipp@sunroof.eng.sun.com Subject: Re: 8+8 addressing..... Cc: jnc@ginger.lcs.mit.edu Nobody has given even a rough outline of a scheme for assigning globally unique identifiers of any particular size, given the widely (but not universally) held belief that IEEE 802 addresses are not It. The issue is not so much guaranteeing uniqueness (which you can't really do anyway), but i) how often collisions happen, ii) what the bad effects of such collisions are, and iii) what the recovery mechanism is. I include the first point since any numbering/naming system has a probablity (through human or equipment failure) of generating duplicate numbers. This exists, e.g., with IPv4, where you can assign the same number to two different hosts on an Ethernet... (The intermeshing of locators and EID's in addresses may make it less likely you'll have duplicates, but doesn't guarantee it...) The consequences of collisions need to be thought about, since, e.g., if the only time duplicate EID's are a problem is when those two things try and communicate, you can get away with a higher incidence of duplicates, which means you can probably use less heavy-duty mechanisms to prevent duplicates. The recovery mechanism in such cases might include notifying a human, etc. If you want to try and guarantee uniqueness, you can have a registry, which we might want for other reasons, giving us duplicate detection "for free". For instance, duplicate DNS names tend not to be a problem since you quickly discover the collision. None of which is a complete answer to your question; I'm just not sure how critical a question it is. Noel From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 05:26:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13767; Tue, 7 Jun 1994 05:23: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 FAA14898; Tue, 7 Jun 1994 05:23:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA14865; Tue, 7 Jun 1994 05:16:06 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13200; Tue, 7 Jun 1994 05:09:22 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA12945; Mon, 6 Jun 94 15:07:19 -0400 Message-Id: <9406061907.AA12945@rodan.UU.NET> To: bsimpson@morningstar.com Cc: sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Mon, 06 Jun 1994 17:11:36 GMT." <2543.bill.simpson@um.cc.umich.edu> Date: Mon, 06 Jun 1994 15:07:18 -0400 From: "Mike O'Dell" If we use 8 bytes of EID, we get an insanely large number of hosts, even if they are not densely allocated...... Enough for everyone in the world to have a network of equal size. (Unless you intend to assign IPng addresses to individual genes....) as for huge locators used with EIDs - remember that the "number of hosts on a net" becomes irrelevant - they could all be on one network and not effect the network-context component. you just need to get to the neighborhood - then the EID does the job locally. Yes, I'm assuming that we have local virtual addressing, but then that's what ARP does right now, so I see no problem keeping the notion alive and functioning - this level of indirection is terribly useful. so if the "network context" (I don't like "locator" because I mean something different, it would seem) does not have to enumerate the hosts, then it can be much smaller. 8 bytes of network context is huge, almost beyond reason just to start with. Actually, in some fashion, the is arguing for treating the entire 16-byte "address" as a locator, but a two-part address - one of "network context" which identifies how (or more accurately, where) one should try to evaluate the EID component. The EIDs are globally unique, but you need the hint as to where to look if you really want to communicate with it. With the hint, though, you can use the local binding machinery (aka ARP, for example) to locate the EID in the neighborhood identified by the "network context" component. so use virtual addressing locally and save the freight in the network context - i mean the bits are going anyway - use 'em. (but keep the bloody network context OUT of the upper level protocol control blocks!!!!!) but use the network context to find where to go looking for the EID. -Mike From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 05:47:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13968; Tue, 7 Jun 1994 05:27: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 FAA14913; Tue, 7 Jun 1994 05:24:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA14859; Tue, 7 Jun 1994 05:15:35 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10701; Tue, 7 Jun 1994 04:15:57 +1000 (from mo@uunet.uu.net) Received: from shark.mel.dit.CSIRO.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA10874 Tue, 7 Jun 1994 02:21:48 +1000 (from mo@uunet.uu.net) Received: from rodan.UU.NET by shark.mel.dit.csiro.au with SMTP id AA11073 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 7 Jun 1994 00:57:15 +1000 Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA18435; Mon, 6 Jun 94 10:51:57 -0400 Date: Mon, 6 Jun 94 10:51:57 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: <9406061451.AA18435@rodan.UU.NET> To: sipp@sunroof.eng.sun.com Subject: addressing..... Cc: big-internet@munnari.OZ.AU well, by my math, an 8+8 format with the upper 8 bytes encoding "network context" and the lower 8 bytes carring a unique identifier, gives us 2^64 distinct hosts, which is about 16*10^18 distinct hosts (using the 2^10 = 10^3 approximation), and this is just the hosts, which are effectively at the bottom level of whatever structure is encoded in the 8 bytes of "network context". We can speculate about how one might code the 8 bytes of network context: The simplest would be 4 bytes of "carrier locator" and 4 bytes of "carrier-specific locator". this would allow 4 billion carriers - enough for most of the existing world's population to found an internet service provider business. then the carriers can use the next 4 bytes to do interior routing down to some "neighborhood". I know I could live with that (!!). Of course, we can fiddle about with encoding within the "carrier locator" portion, say setting aside half of the space for "carriers" and half of the space for "geo-locators". only half the population can be IP providers, but that's probably ok, and we can resolve 3D lat/lon/alt data to say, 10 bits each (or 11,11,9) , but that's plenty good for simply identifying a "cell" upon which the "carrier-specific" routing can operate. this could even support large airborne mobile networks with no problem, much less slower moving surface mobile applications. Within the carrier-specific part, one could simply flat-route it so a provider could identify 4 billion customer networks - enough for most of the world's population to have an arbitrarily-large network, and for all of them to subscribe to one provider. seems like enough, even when one contemplates "world domination." of course, adding internal structure to do regional routing would be an internal matter, but the structure is large enough to be incredibly rich...... So, again, I argue for 8+8. it gives us a huge number of distinct endpoint identifiers, and it gives us incredible routing flexibility EXACTLY because ONLY the EIDs are used in the upper-level protocol blocks. thereby changes to the lower level adjacency do NOT effect the upper level protocols, and in particular, they don't effect existing connections. Folks, this is our big chance to make mobililty work really *right* without complex cushion-shot routing tricks and other silliness. In my mind, this is the *one* thing that makes EIDs worth having today, and the 8+8 structure gives the routing richness which would allow lots of cool ideas to be pursued with complete impunity. 8+8 - it's good for what ails us...... -Mike D From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 09:25:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18310; Tue, 7 Jun 1994 07:27: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 HAA15073; Tue, 7 Jun 1994 07:22:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA15044; Tue, 7 Jun 1994 07:14:28 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14410; Tue, 7 Jun 1994 05:39:51 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA13188; Mon, 6 Jun 94 12:31:33 -0700 Received: by xirtlu.zk3.dec.com; id AA23281; Mon, 6 Jun 1994 15:31:13 -0400 Message-Id: <9406061931.AA23281@xirtlu.zk3.dec.com> To: "Mike O'Dell" Cc: bsimpson@morningstar.com, sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Mon, 06 Jun 94 15:07:18 EDT." <9406061907.AA12945@rodan.UU.NET> Date: Mon, 06 Jun 94 15:31:07 -0400 X-Mts: smtp >so use virtual addressing locally and save the freight in the network >context - i mean the bits are going anyway - use 'em. (but keep the >bloody network context OUT of the upper level protocol control >blocks!!!!!) but use the network context to find where to go looking >for the EID. Exactly and well said. Something a colleague stated to me today who has many years in both IP and OSI network kernels on UNIX I thought I would share with ya all. "Forcing IPng to what is today's state of the art will force IPng to be tomorrow's state of the mediocrity." /jim From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 11:38:54 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19411; Tue, 7 Jun 1994 08:13: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 AA03207 Tue, 7 Jun 1994 07:23:36 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA15058; Tue, 7 Jun 1994 07:20:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA15038; Tue, 7 Jun 1994 07:13:36 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13601; Tue, 7 Jun 1994 05:18:27 +1000 (from mo@uunet.uu.net) Received: from rodan.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA24261 Tue, 7 Jun 1994 05:18:09 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA13593; Mon, 6 Jun 94 15:15:27 -0400 Date: Mon, 6 Jun 94 15:15:27 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: <9406061915.AA13593@rodan.UU.NET> To: big-internet@munnari.OZ.AU, sipp@sunroof.eng.sun.com Subject: 8+8 and EID collissions.... well, given my proposed coding and resolution algorithm (network context plus dynamic resolution of EID), even if there is a collision, if the network context is right, it will still work and you won't actually have to care very much. only if they both get in the same neighborhood will it matter, and then you'll find that pretty fast. -mo D From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 11:41:14 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19413; Tue, 7 Jun 1994 08:13: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 AA03378 Tue, 7 Jun 1994 07:26:06 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id HAA15088; Tue, 7 Jun 1994 07:23:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA15041; Tue, 7 Jun 1994 07:13:55 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13674; Tue, 7 Jun 1994 05:20:24 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA11934; Mon, 6 Jun 94 12:14:53 -0700 Received: by xirtlu.zk3.dec.com; id AA22719; Mon, 6 Jun 1994 15:14:40 -0400 Message-Id: <9406061914.AA22719@xirtlu.zk3.dec.com> To: bsimpson@morningstar.com Cc: sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Mon, 06 Jun 94 17:11:36 GMT." <2543.bill.simpson@um.cc.umich.edu> Date: Mon, 06 Jun 94 15:14:34 -0400 X-Mts: smtp >Do we have rough consensus that 8 bytes is enough to identify all nodes, >and then can limit argument to whether or not to have a variable size >for the "locator" part? Well we don't have rough consensus yet. But I sure think this is a good way to begin to define the address. Regardless of whether we have defined an addressing plan for EIDs. If we could reach consensus on this expediently we could go back to enhancing our prototypes to do the interoperability testing part between implementations. Plus it lets us revisit specs like autoconfig, transition, etc. which all need updates now. I think DNS is the way to avoid collisions. /jim From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 11:43:25 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19355; Tue, 7 Jun 1994 08:11:33 +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 AA03459 Tue, 7 Jun 1994 07:27: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 HAA15103; Tue, 7 Jun 1994 07:24:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA15047; Tue, 7 Jun 1994 07:14:55 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17201; Tue, 7 Jun 1994 06:46:19 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HD86V6YE6O004BFC@FNAL.FNAL.GOV>; Mon, 6 Jun 1994 15:45:18 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA11225; Mon, 6 Jun 94 15:44:06 CDT Date: Mon, 06 Jun 1994 15:44:04 -0500 From: Matt Crawford Subject: Re: 8+8 addressing..... In-Reply-To: <9406061451.AA18435@rodan.UU.NET> To: sipp@sunroof.eng.sun.com Cc: big-internet@munnari.OZ.AU Message-Id: <9406062044.AA11225@munin.fnal.gov> Content-Transfer-Encoding: 7BIT A lot of people have a lot of ideas for geographic/provider/customer based locators, many of which apply comfortably in the "upper half" of an 8+8 address format. I'm concerned about the lower 8 bytes right now since, if they are to be a globally unique EID, then the uniqueness scheme has an effect, probably negative, on my ability to use the lower 8 for local topological structure. I suggest breaking the lower half further, probably into 4+4, maybe 3+5, where the "upper 4 (or 3)" designates a registry that helps assure uniqueness of the lower 8 and provides DNS delegation, and the "lowest 4 (or 5)" is locally assigned. Having at least 4 bytes under complete local control allows us to use our IPv4 addresses as the locally-assigned portion of our SIPP-16 addresses. I'm sure this has to be good for the transition! (If something like a C-bit is still needed, perhaps it can be the bit just above the locally-assigned part.) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | | | | | | | | | | | | | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ <-- geo/provider/subscriber --> <--admin part-> <--local part-> DNS lookups on hostnames would provide the admin+local parts and/or the entire SIPP-16 addresses. Reverse lookups on the admin+local part would get you hostnames as well as a set of geo/provider/ subscriber prefixes. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 13:01:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28427; Tue, 7 Jun 1994 13:01: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 NAA15432; Tue, 7 Jun 1994 13:00:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA15418; Tue, 7 Jun 1994 12:44:12 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22698; Tue, 7 Jun 1994 10:18:24 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA16106; Mon, 6 Jun 94 17:20:22 -0700 Date: Mon, 6 Jun 94 17:20:22 -0700 From: Eric Fleischman Message-Id: <9406070020.AA16106@atc.boeing.com> To: crawdad@munin.fnal.gov, sipp@sunroof.Eng.Sun.COM Subject: Re: 8+8 addressing..... Cc: big-internet@munnari.OZ.AU It is my belief that large end user companies have at least an equivalent need for routing hierarchy within their own private networks than the Internet itself. In fact, the need is greater for large corporations which may need to distinguish between continents, regions, cities, buildings, and networks within buildings. This observation makes me uncomfortable with the 8+8 concept as I currently understand it. I would appreciate advocates of the 8+8 concept to address my concern. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 15:54:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29028; Tue, 7 Jun 1994 13:20: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 NAA15471; Tue, 7 Jun 1994 13:20:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA15440; Tue, 7 Jun 1994 13:01:46 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28441; Tue, 7 Jun 1994 13:01:39 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA18935; Mon, 6 Jun 94 23:01:34 -0400 Date: Mon, 6 Jun 94 23:01:34 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: <9406070301.AA18935@rodan.UU.NET> To: big-internet@munnari.OZ.AU Subject: lower 8 bits of 8+8 format Cc: sipp@sunroof.eng.sun.com I suggest that the lower 8 bits be flat, generated by an 8-byte exor folding of the MD5 hash of the per-host key assigned to each host. either this has an incredible likelyhood of being unique, or something is rotten in denmark (to borrow from the bard). -mo D From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 16:07:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29070; Tue, 7 Jun 1994 13:22: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 NAA15486; Tue, 7 Jun 1994 13:22:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA15468; Tue, 7 Jun 1994 13:14:56 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28912; Tue, 7 Jun 1994 13:14:44 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA19599; Mon, 6 Jun 94 23:14:42 -0400 Date: Mon, 6 Jun 94 23:14:42 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: <9406070314.AA19599@rodan.UU.NET> To: big-internet@munnari.OZ.AU, sipp@sunroof.eng.sun.com Subject: companies needing lots of internal routing...... well, give 2 billion "providers", one might imagine that a large enough group might be able to get virtual provider status with relative ease. the real issue is how to wittle up the network-specific-context under that. the traditional subnet bogusness practiced by many sites simply cannot be done - you can't simply waste bits to nice byte boundaries to make things easy to type. there are tools available right now to do subnet allocation and design which will maintain high address density. these tools allow the University of Illinois to maintain 30% address density of their subnetted class B. this is between one and two orders of magnitude better than most subnetted networks. again, these tools are simple and reasonably available. we can certainly work to make them better and easier to use. the way the address space gets administered at local sites is FAR more important than the global bit whittling. In fact, I'm really fond of doing MINIMAL global address whittling, thereby leaving the most room for designating "local neighborhoods". In my 8+8 outline, assuming a 4+4 split of the "network context", given the upper 4 designate the "large organization", they still have 4 bytes of networks. even if they flat address it, they get 4 BILLION networks. One would assume they will apply a modicum of CIDRization and presto, you get cables, floors, buildings, and campuses with no problem. anyone who can't make this work is REALLY off in the weeds. in fact, this is really squanderous, but slop seems to make people feel safe, so here it is. -Mike From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 16:48:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24420; Tue, 7 Jun 1994 11:03: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 LAA15316; Tue, 7 Jun 1994 11:00:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA15301; Tue, 7 Jun 1994 10:50:09 +1000 Precedence: list From: smb@research.att.com Received: from ninet.research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18865; Tue, 7 Jun 1994 07:51:29 +1000 (from smb@research.att.com) Message-Id: <9406062151.18865@munnari.oz.au> Received: by gryphon; Mon Jun 6 17:47:17 EDT 1994 To: bound@zk3.dec.com Cc: bsimpson@MorningStar.Com, sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... Date: Mon, 06 Jun 94 17:47:16 EDT I think DNS is the way to avoid collisions. That may not work. If the EID uses the MAC address for part of it, as some folks have suggested, there's no easy administrative division for DNS zones, as there is with IPv4 addresses. Of course, one can define an EID that doesn't use the MAC addresss, but some folks have assumed that it would. --Steve Bellovin From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 16:49:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01322; Tue, 7 Jun 1994 14:21: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 OAA15559; Tue, 7 Jun 1994 14:20:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA15556; Tue, 7 Jun 1994 14:18:56 +1000 Precedence: list From: jallard@microsoft.com Received: from netmail2.microsoft.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23449; Tue, 7 Jun 1994 10:37:47 +1000 (from jallard@microsoft.com) Received: by netmail2.microsoft.com (5.65/25-eef) id AA20178; Mon, 6 Jun 94 16:39:21 -0700 Message-Id: <9406062339.AA20178@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Mon, 06 Jun 94 16:39:21 PDT X-Msmail-Message-Id: DB3C0DBF X-Msmail-Conversation-Id: DB3C0DBF To: owner-Big-Internet@munnari.OZ.AU, sipp@sunroof.eng.sun.com Date: Mon, 6 Jun 94 17:32:41 TZ Subject: RE: addressing..... Cc: big-internet@munnari.OZ.AU | well, by my math, an 8+8 format with the upper 8 bytes encoding | "network context" and the lower 8 bytes carring a unique identifier, | gives us 2^64 distinct hosts, which is about 16*10^18 distinct hosts | (using the 2^10 = 10^3 approximation), and this is just the hosts, | which are effectively at the bottom level of whatever structure is | encoded in the 8 bytes of "network context". We can speculate about | how one might code the 8 bytes of network context: | | The simplest would be 4 bytes of "carrier locator" and 4 bytes of | "carrier-specific locator". this would allow 4 billion carriers - | enough for most of the existing world's population to found an internet | service provider business. then the carriers can use the next 4 bytes | to do interior routing down to some "neighborhood". I know I could | live with that (!!). this is of a very "public internet" centric view of the world, where i too can see a potential for limited 2- or 3-layer hierarchies. within private organizations though, esp those which grow, reorganize, or merge with other enterprises, the rules aren't as simple or as pre-planned. we already have net, subnet, and host which practically all organizations leverage. 2^32 isn't our problem - it's the efficiency associated with the structure that we've been given. it worked pretty well for general purpose computers within a certain culture. once you introduce *classes* of devices which need to be addressed to be the average businessowner and home users, there will be a need for more than 2- or 3-levels and the efficiency will be very poor. this will be a reality 5 years from now. already airplanes are running ip, the utility companies want it, your cable box will have it, and your pda's will have them as well. throw all of these devices into a 50,000 employee company and see how they solve the addressing problem. it wont be 4+4+8. then, merge them with a manufacturing company. then split them apart and introduce a new class of devices. i doubt that 8+8 will work. one thing you can be sure of. people will use what you give them until they exhaust it. if we believe that 4+4+8 or 8+8 will work for the next 5 years, then do it. we can't anticipate much further down the road anyway, and any guess we make will be wrong. i don't believe that 8+8 is sufficient for today's corporate networks and the type of addressing they want - i think they need more flexibility. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 18:48:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10257; Tue, 7 Jun 1994 18:41: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 SAA15803; Tue, 7 Jun 1994 18:40:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA15786; Tue, 7 Jun 1994 18:31:02 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05249; Tue, 7 Jun 1994 16:14:38 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 7 Jun 94 15:07:57 +0859 From: Masataka Ohta Message-Id: <9406070608.AA14364@necom830.cc.titech.ac.jp> Subject: Re: addressing..... To: mo@uunet.uu.net (Mike O'Dell) Date: Tue, 7 Jun 94 15:07:55 JST Cc: sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU In-Reply-To: <9406061451.AA18435@rodan.UU.NET>; from "Mike O'Dell" at Jun 6, 94 10:51 am X-Mailer: ELM [version 2.3 PL11] > Folks, this is our big chance to make mobililty work really *right* > without complex cushion-shot routing tricks and other silliness. With new terminologies of EID and locator, you can rename "dynamic IP address change" "dynamic locator change". You can also rename "routing tricks" "locator change propagation tricks". Such renaming solves nothing, of course. The currently proposed mobility (with additional properly secure triangle elimination) is, IMHO, just fine. The only problem of it is that it makes existing security issues of immobile IP obvious to everyone. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 18:48:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10503; Tue, 7 Jun 1994 18:44: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 SAA15818; Tue, 7 Jun 1994 18:44:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA15789; Tue, 7 Jun 1994 18:31:28 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05583; Tue, 7 Jun 1994 16:24:38 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 7 Jun 94 15:16:29 +0900 From: Masataka Ohta Message-Id: <9406070616.AA14413@necom830.cc.titech.ac.jp> Subject: Re: 8+8 addressing..... To: smb@research.att.com Date: Tue, 7 Jun 94 15:16:27 JST Cc: bound@zk3.dec.com, bsimpson@MorningStar.Com, sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU In-Reply-To: <9406062151.18865@munnari.oz.au>; from "smb@research.att.com" at Jun 6, 94 5:47 pm X-Mailer: ELM [version 2.3 PL11] > I think DNS is the way to avoid collisions. I think SECURE DNS is the way. > That may not work. If the EID uses the MAC address for part of it, > as some folks have suggested, there's no easy administrative > division for DNS zones, as there is with IPv4 addresses. We, anyway, must have DNS forward and reverse mapping for IPng. > Of course, one can define an EID that doesn't use the MAC addresss, but > some folks have assumed that it would. With SIPP, MAC based address is not EID and is not collision free. With NSAP with lower 6 bytes of MAC, it is expected that several middle bytes give room for the required division to ease administration. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 18:49:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10540; Tue, 7 Jun 1994 18:45: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 SAA15833; Tue, 7 Jun 1994 18:45:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA15780; Tue, 7 Jun 1994 18:30:30 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02832; Tue, 7 Jun 1994 14:59:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01973; Tue, 7 Jun 94 00:59:15 -0400 Date: Tue, 7 Jun 94 00:59:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406070459.AA01973@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, sipp@sunroof.eng.sun.com Subject: Re: 8+8 addressing..... Cc: jnc@ginger.lcs.mit.edu From: bound@zk3.dec.com > Do we have rough consensus that 8 bytes is enough to identify all nodes, > and then can limit argument to whether or not to have a variable size > for the "locator" part? I sure think this is a good way to begin to define the address. Regardless of whether we have defined an addressing plan for EIDs. You really meant to say "assignment plan" here, right? From: smb@research.att.com Of course, one can define an EID that doesn't use the MAC addresss, but some folks have assumed that it would. I don't think anyone proposed that we depend solely and strongly on MAC addresses for EID's. They just seemed like an easy-to-use set of numbers lying around that were pretty much assigned uniquely, and with a 64-bit EID space, you can embed them all by using 1/65Kth of your total space; i.e. it's a snap to do. We could equally easily embed all existing IPv4 "addresses", for people who want to generate them that way. They are both cheap (in terms of O&M overhead) ways to bootstrap EID allocation. It now appears there might be some problems with duplicates of MAC addresses, but a requirement to register them (which of course has its own problems) would go a long way to fixing that. Noel From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 19:30:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10653; Tue, 7 Jun 1994 18: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 SAA15848; Tue, 7 Jun 1994 18:47:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA15783; Tue, 7 Jun 1994 18:30:45 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03269; Tue, 7 Jun 1994 15:12:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02028; Tue, 7 Jun 94 01:12:30 -0400 Date: Tue, 7 Jun 94 01:12:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406070512.AA02028@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: lower 8 bits of 8+8 format Cc: jnc@ginger.lcs.mit.edu, sipp@sunroof.eng.sun.com From: mo@uunet.uu.net (Mike O'Dell) I suggest that the lower 8 bits be flat, generated by an 8-byte exor folding of the MD5 hash of the per-host key assigned to each host. You meant "lower 8 *bytes*", no? Hmmm. I like this... Since almost every host is going to need a private key anyway, and we're then faced with the necessity of providing a secure binding between the EID and the private key, I've heard suggestions that we simply make the private key the EID, getting rid of the possibility of errors in the binding, all the hassle of building the binding and securing it, the separate EID allocation mechanism, etc, etc. This solution effectively does that... I'd be tempted to hash it into 7 bytes, though (that way, you can embed them all by using .5% of your total space), so that you can change your mind about how you allocate EID's down the road, if that becomes useful for some as yet unforseen reason. I don't think there'd be substantially higher chances of collisions with a 7-byte hash than an 8-byte one. Don't I recall that DEC wanted to make the 48-bit addresses assigned randomly, but people freaked out, so they went to an allocation scheme? Also, maybe the "formal" EID is still the full key, but this "compressed" version is used wherever you need to stick it in packet headers. You could define several different hash algorithms, so that if you get a collision on the primary hash (i.e. you and your correspondant happened to hash to the same), one of you (picked in some arbitrary way) calculates a new "compressed EID" via a backup. Noel From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 21:21:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB15614; Tue, 7 Jun 1994 21: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 VAA16005; Tue, 7 Jun 1994 21:20:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA15999; Tue, 7 Jun 1994 21:10:16 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15240; Tue, 7 Jun 1994 21:09:57 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 7 Jun 94 20:03:18 +0900 From: Masataka Ohta Message-Id: <9406071103.AA15951@necom830.cc.titech.ac.jp> Subject: Re: lower 8 bits of 8+8 format To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 7 Jun 94 20:03:16 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, sipp@sunroof.eng.sun.com In-Reply-To: <9406070512.AA02028@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 7, 94 1:12 am X-Mailer: ELM [version 2.3 PL11] > From: mo@uunet.uu.net (Mike O'Dell) > > I suggest that the lower 8 bits be flat, generated by an 8-byte > exor folding of the MD5 hash of the per-host key assigned to > each host. > > You meant "lower 8 *bytes*", no? Hmmm. I like this... I've forgot the basic mathematical theorem but it is well known in cryptography that the scheme does not assure uniqueness so much. Uniqueness of N bit hashes is broken with fairly large probability (e^(-1/2)=0.6) when there are 2^(N/2) hashes, which is why MDs are 128bit long (see RFCs: 1319, 1320, 1321). Thus, with 2^32 population of the world, EID of 64 bit hash is not enough. The scheme has another problem that reverse mapping of EIDs is virtually impossible. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jun 7 21:23:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15652; Tue, 7 Jun 1994 21:23: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 VAA16020; Tue, 7 Jun 1994 21:23:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA16002; Tue, 7 Jun 1994 21:18:20 +1000 Precedence: list From: smb@research.att.com Received: from ninet.research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15487; Tue, 7 Jun 1994 21:18:16 +1000 (from smb@research.att.com) Message-Id: <9406071118.15487@munnari.oz.au> Received: by gryphon; Tue Jun 7 07:17:31 EDT 1994 To: Masataka Ohta Cc: bound@zk3.dec.com, bsimpson@MorningStar.Com, sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... Date: Tue, 07 Jun 94 07:17:30 EDT > I think DNS is the way to avoid collisions. I think SECURE DNS is the way. > That may not work. If the EID uses the MAC address for part of it, > as some folks have suggested, there's no easy administrative > division for DNS zones, as there is with IPv4 addresses. We, anyway, must have DNS forward and reverse mapping for IPng. Obvious -- but it's not clear that these need be on EIDs. > Of course, one can define an EID that doesn't use the MAC addresss, but > some folks have assumed that it would. With SIPP, MAC based address is not EID and is not collision free. With NSAP with lower 6 bytes of MAC, it is expected that several middle bytes give room for the required division to ease administration. One of the things that was very apparent (to me, at any rate) from the Big 10 workshop was that there were a fair number of different uses for the EID, and that the proper allocation strategy depended on the intended use. If you just want a unique, random-seeming number, the MD5 of the host's key is fine. Or use the public key, or a function of it, if you want some way to look up a host by name, and determine its EID. If you want easy autoconfiguration, MAC addresses are good, so long as a site prefix is used when you talk non-locally. If an EID is, in some sense, a name, then you need a hierarchical scheme, so that reverse DNS works. And there are probably a few I forgot. But my basic point is this: one of the reason we're having so much trouble agreeing on whether or not we need EIDs, and on what they should look like, is that we each have a different mental model of their intended uses. --Steve Bellovin From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 01:17:01 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23428; Wed, 8 Jun 1994 01:07: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 AA10702 Wed, 8 Jun 1994 01:06: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 BAA16268; Wed, 8 Jun 1994 01:03:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA16248; Wed, 8 Jun 1994 00:58:20 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17838; Tue, 7 Jun 1994 22:27:40 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA16325; Tue, 7 Jun 94 05:23:09 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA21486; Tue, 7 Jun 1994 08:25:28 -0400 Message-Id: <9406071225.AA21486@skidrow.lkg.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM Subject: Re: lower 8 bits of 8+8 format In-Reply-To: Your message of "Tue, 07 Jun 94 01:12:30 EDT." <9406070512.AA02028@ginger.lcs.mit.edu> Date: Tue, 07 Jun 94 08:25:28 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Precedence: list To: big-internet@munnari.OZ.AU Cc: jnc@ginger.lcs.mit.edu, sipp@sunroof.eng.sun.com > From: mo@uunet.uu.net (Mike O'Dell) > > I suggest that the lower 8 bits be flat, generated by an 8-byte > exor folding of the MD5 hash of the per-host key assigned to > each host. > >You meant "lower 8 *bytes*", no? Hmmm. I like this... > >Since almost every host is going to need a private key anyway, and we're then >faced with the necessity of providing a secure binding between the EID and the >private key, I've heard suggestions that we simply make the private key the >EID, getting rid of the possibility of errors in the binding, all the hassle >of building the binding and securing it, the separate EID allocation mechanism, >etc, etc. This solution effectively does that... You mean every host will need a public/private pair. The EID could be based on a hash of the public or the private key but it won't be reasonably assured of uniqueness unless you got to at least 128 bits. >I'd be tempted to hash it into 7 bytes, though (that way, you can embed them >all by using .5% of your total space), so that you can change your mind about >how you allocate EID's down the road, if that becomes useful for some as yet >unforseen reason. I don't think there'd be substantially higher chances of >collisions with a 7-byte hash than an 8-byte one. Don't I recall that DEC >wanted to make the 48-bit addresses assigned randomly, but people freaked >out, so they went to an allocation scheme? I would agree that you don't want to fence yourself in to a single scheme. For EID's or provider versus geographic versus ? locators, I think the same thing. Let a thousand flowers bloom. The scheme needs to accomodate alternatives. >Also, maybe the "formal" EID is still the full key, but this "compressed" >version is used wherever you need to stick it in packet headers. You could >define several different hash algorithms, so that if you get a collision on >the primary hash (i.e. you and your correspondant happened to hash to the >same), one of you (picked in some arbitrary way) calculates a new "compressed >EID" via a backup. Even with a big hash or the full key, I bet you would get some collisions due to idiots who search for the next two primes after 2**511 or some other very obvious round starting place and then multiplied them. And you can't have a central allocating authority to assure uniqueness as that compromises the security of the system. It's hard to make thing foolproof since fools are so ingenious... > Noel If you are willing to disambiguate these "EID"s with a prefix, then it may bound the area enough that you can just, for example, use the 56 bits of the public key that are just above the low order byte (the low order byte is not randomly distributed). True, its easy to construct public/private key pairs where this duplicates but in a local area you can enforce uniqueness. Donald From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 01:20:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19757; Tue, 7 Jun 1994 23:21: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 XAA16142; Tue, 7 Jun 1994 23:20:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA16139; Tue, 7 Jun 1994 23:11:08 +1000 Precedence: list Received: from sundance.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19307; Tue, 7 Jun 1994 23:11:04 +1000 (from atkinson@sundance.itd.nrl.navy.mil) From: Ran Atkinson Message-Id: <9406070909.ZM12353@sundance.itd.nrl.navy.mil> Date: Tue, 7 Jun 1994 09:09:12 -0500 Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: big-Internet@munnari.OZ.AU Subject: dotted notation considered awkward Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil The dotted notation for IPv4 addresses makes it harder for mere mortals to subnet along arbitrary bit boundaries (and have better address space utilisation) than to subnet along 8-bit boundaries (and have low address space utilisation). This is a human-factors issue, not strictly a bit-twiddling issue. Perhaps IPng should use a different human-readable notation that would tend to encourage variable-length subnetting and higher address density. Hexadecimal would at least make nibble (4-bit) alignment much easier to read. There are probably better ideas out there. We should consider these human factors issues as we ponder selection and deployment of IPng. Ran atkinson@itd.nrl.navy.mil -- From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 02:41:30 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26020; Wed, 8 Jun 1994 02:37: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 AA13944 Wed, 8 Jun 1994 01:43:38 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA16371; Wed, 8 Jun 1994 01:40:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA16351; Wed, 8 Jun 1994 01:39:14 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21762; Wed, 8 Jun 1994 00:09:11 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HD971JV0XS004FBK@FNAL.FNAL.GOV>; Tue, 7 Jun 1994 09:01:12 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA19637; Tue, 7 Jun 94 09:00:03 CDT Date: Tue, 07 Jun 1994 09:00:02 -0500 From: Matt Crawford Subject: Re: lower 8 bits of 8+8 format In-Reply-To: Your message of Tue, 07 Jun 94 20:03:16 +0800. <9406071103.AA15951@necom830.cc.titech.ac.jp> To: sipp@sunroof.eng.sun.com Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU, Masataka Ohta Message-Id: <9406071400.AA19637@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > I've forgot the basic mathematical theorem but ... > Uniqueness of N bit hashes is broken with fairly large probability > (e^(-1/2)=0.6) when there are 2^(N/2) hashes, which is why MDs > are 128bit long (see RFCs: 1319, 1320, 1321). It's easy to see that the chance of a duplicate when picking M items from a set of cardinality N, if M << N, is approximately M^2/2N. So as Masataka says, there is significant chance of duplicates among 2^32 EIDs quasi-randomly assigned in a 64 bit space. And I, for one, would like to have at least 2 or 3 bytes to use for local topology, and Eric Fleischman would like even more than that. I'd also like to know what lookups I'd be able to do on the information available to me when a packet comes in from the wide world. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 02:41:52 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26032; Wed, 8 Jun 1994 02: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 AA14174 Wed, 8 Jun 1994 01:46: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 BAA16405; Wed, 8 Jun 1994 01:43:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA16345; Wed, 8 Jun 1994 01:38:50 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19294; Tue, 7 Jun 1994 23:09:46 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 7 Jun 1994 09:09:41 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 7 Jun 1994 09:09:41 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA08150; Tue, 7 Jun 94 09:08:01 EDT Date: Tue, 7 Jun 94 09:08:01 EDT Message-Id: <9406071308.AA08150@mailserv-D.ftp.com> To: mo@uunet.uu.net Subject: Re: addressing..... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Content-Length: 1508 > well, by my math, an 8+8 format with the upper 8 bytes encoding > "network context" and the lower 8 bytes carring a unique identifier, > gives us 2^64 distinct hosts, which is about 16*10^18 distinct hosts > (using the 2^10 = 10^3 approximation), and this is just the hosts, > which are effectively at the bottom level of whatever structure is > encoded in the 8 bytes of "network context". We can speculate about > how one might code the 8 bytes of network context: > The simplest would be 4 bytes of "carrier locator" and 4 bytes of > "carrier-specific locator". this would allow 4 billion carriers - > enough for most of the existing world's population to found an internet > service provider business. then the carriers can use the next 4 bytes > to do interior routing down to some "neighborhood". I know I could > live with that (!!). let's see here. you propose 2 levels of hierarchy. if we assume that the ipng criteria document's goal of 10E12 networks is correct, this requires that the 2 levels contain, on average, 10E6 networks -- that is to say, there would be 10E6 top-level ("carriers" in your terminology) entities each of which would 'contain' 10E6 (on average) lower-layer entities. please describe how you would do routing among all these entities, including analysis of the expected size of routing data structures and routing protocol packet sizes and traffic rates. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 02:41:59 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26027; Wed, 8 Jun 1994 02:37:34 +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 AA14068 Wed, 8 Jun 1994 01:44:54 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA16387; Wed, 8 Jun 1994 01:42:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA16348; Wed, 8 Jun 1994 01:39:03 +1000 Precedence: list Received: from inesc.inesc.pt by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20906; Tue, 7 Jun 1994 23:57:15 +1000 (from prc@avila.inesc.pt) Received: from avila.inesc.pt by inesc.inesc.pt with SMTP; id AA01525 (5.67a/SunOS4.1.3); Tue, 7 Jun 1994 15:53:47 +0200 Received: by avila.inesc.pt (4.1/SunOS4.1.2) id AA18075; Tue, 7 Jun 94 15:56:30 +0200 From: prc@avila.inesc.pt (Pedro Ramalho Carlos) Message-Id: <9406071356.AA18075@avila.inesc.pt> Subject: Re: dotted notation considered awkward To: atkinson@itd.nrl.navy.mil Date: Tue, 7 Jun 1994 15:56:29 +0200 (MET DST) Cc: big-Internet@munnari.OZ.AU In-Reply-To: <9406070909.ZM12353@sundance.itd.nrl.navy.mil> from "Ran Atkinson" at Jun 7, 94 09:09:12 am X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Content-Length: 1373 > > > The dotted notation for IPv4 addresses makes it harder for mere > mortals to subnet along arbitrary bit boundaries (and have better > address space utilisation) than to subnet along 8-bit boundaries (and > have low address space utilisation). This is a human-factors issue, > not strictly a bit-twiddling issue. > > Perhaps IPng should use a different human-readable notation that > would tend to encourage variable-length subnetting and higher address > density. Hexadecimal would at least make nibble (4-bit) alignment > much easier to read. There are probably better ideas out there. What about having the configuration software generating bitmasks from the number of netmask bits specified by the "bit-arithmetic-impaired" mere mortal? For example, the classic bsd ifconfig could look something like: ifconfig hippi5 netmaskbits 56 -trailers ;-) instead of ifconfig hippi5 netmask 255.255.255.255.255.255.255 It's easy to code and it seems basically an implementation issue not a Big-I problem. cheers > > We should consider these human factors issues as we ponder selection > and deployment of IPng. > > Ran > atkinson@itd.nrl.navy.mil > > > > -- > > --- pedro ramalho carlos email: prc@inesc.pt INESC tel: +351-1-3100050 Av. Duque de Avila, 23 fax: +351-1-3100008 1017 Lisboa Codex - PORTUGAL From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 02:42:09 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25976; Wed, 8 Jun 1994 02:36:15 +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 AA14282 Wed, 8 Jun 1994 01:47: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 BAA16421; Wed, 8 Jun 1994 01:44:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA16354; Wed, 8 Jun 1994 01:39:22 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21770; Wed, 8 Jun 1994 00:09:27 +1000 (from kasten@mailserv-D.ftp.com) Received: from wd40.ftp.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA06033 Wed, 8 Jun 1994 00:09:20 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 7 Jun 1994 10:06:46 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 7 Jun 1994 10:06:46 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA09157; Tue, 7 Jun 94 10:05:07 EDT Date: Tue, 7 Jun 94 10:05:07 EDT Message-Id: <9406071405.AA09157@mailserv-D.ftp.com> To: big-internet@munnari.OZ.AU Subject: Locator Sizes From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 4463 I sent the following to the SIPP mailing list yesterday, but given the current spirited debate on big-i, it probably ought to be here as well. ========================================================================= I've been watching this discussion go by for a few days now and have been suitably motivated to do a little analysis and math. In figuring out how big locators should be, how much space a level requires, how many levels are needed, and so on, it all comes down to 2 questions: 1) Aggregation Efficiency -- that is to say, how many "lower-level" networks get glommed together by the "higher-level" network. Does each level of hierarchy glom together 10 "sub-networks"? 100? 1000? Granted, this will depend on where you are in the system -- some places may aggregate 2 networks per level, others may aggregate 10,000. But in order to figure out how much space we want/need, we have to take a guess at an average. This gives the number of levels of hierarchy. 2) Space Utilization - given that each level of the locators aggregates 'n' "sub-networks", how many bits should be assigned to each level? This will mostly be a psychological question -- I'd bet that network administrators will want to do it in at least 1-byte hunks. Furthermore, network administrators, being a conservative bunch of people, would certainly want some 'extra' room -- maybe enough bytes to hold the aggregation, plus one or 2 bytes. This gives the number of bytes/level. If you multiply the answer to question 1 by the answer to question 2 you get the size of the address. So, let's do a little math here. We want to be able to support 10E12 end networks (the criteria document says 10E9 is the absolute minimum, 10E12 is really really really nice...) I'll do all the math assuming 10E12 end networks - better safe than sorry. If we assume the following aggregation efficiencies, we get the following 'level counts': Average Aggregation Efficiency Level Count 1:10 12 1:20 9+ 1:50 7+ 1:100 6 1:1000 4 I do not think that 1:10 is useful. I do not think that we will see 1:1000 aggregation. I'd bet that the maximum level of aggregation we will see, _on_average_ over the network, will be between 1:50 and 1:100. This tells me that we will need from 6 to 8 levels of hierarchy in the locator. Now the question is "how many bytes/level" do we need? Well, we need at least one byte. However, one byte per level would mean that we use between 20% and 40% of the 'space' available at each level: assume from 50 to 100 elements 'aggregated' at each level, 1 byte per level gives at most 256 (let's use 250 to make the math easier) uniquely identifiable entities at each level and 50/250 is 0.20, 100/250 is 0.40. Will administrators feel safe with 1 byte per level? Maybe. Maybe not. I'd guess that they would feel safe with 2 bytes per level. So, with 6-8 levels, and 1-2 bytes/level we get a locator that requires from 6 to 16 bytes. But, I was just talking about identifying the individual NETWORKS that comprise The Internet. This 6-16 bytes just gets you to the network, still need to get to the host on the network. The criteria take a guess that we will want up to 10E15 hosts -- which is 3 orders of magnitude more than the number of networks. So we will need to address, on average, 1,000 hosts per network -- which will require at least 2 bytes. However, we are talking about using longer numbers to id the host -- EIDS, 802 addresses, frotzes. So, if it is an 802 address, 6 bytes for the 'host id' are needed, some have suggested that the host-id should be 8-bytes (into which we can embed the 802 address if desired). So, the host-id is from 2 to 8 bytes long. Locators need to be from 8 to 24 bytes long. Whichever one you 'believe' in depends on the assumptions that you make. AND, all this is without any margin of 'safety' on our part. If you believe that 8 bytes is enough, then how sure are you that we will achieve the 100:1 aggregation? That administrators will be 'happy' with minimally sized fields? And so on... If I were King, I'd do the math to come up with a number based on some quantitative criteria, and then double it to be safe. But I'm not King. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 02:42:14 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25990; Wed, 8 Jun 1994 02:36:39 +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 AA14398 Wed, 8 Jun 1994 01:49: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 BAA16436; Wed, 8 Jun 1994 01:46:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA16357; Wed, 8 Jun 1994 01:39:31 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21768; Wed, 8 Jun 1994 00:09:23 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05752 Wed, 8 Jun 1994 00:05:44 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 7 Jun 1994 10:03:10 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 7 Jun 1994 10:03:10 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA09075; Tue, 7 Jun 94 10:01:24 EDT Date: Tue, 7 Jun 94 10:01:24 EDT Message-Id: <9406071401.AA09075@mailserv-D.ftp.com> To: bsimpson@morningstar.com Subject: Re: 8+8 addressing..... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Content-Length: 6968 > Do we have rough consensus that 8 bytes is enough to identify all nodes, > and then can limit argument to whether or not to have a variable size > for the "locator" part? Not until you define the characteristics and uses of the Identifier. Does a node have exactly one ID? Or more than one? Can IDs move around on the network with their node? Can IDs move around on the net independant of the node? What does the ID identify? Does it identify the node, or does it identify some set of communication endpoints on the node? Is the ID globally or subnet-locally unique? What is the expected administrative plan for IDs? Are they assigned by the system owners or by manufacturers? What is the interrelationship between IDs and DNS? Can I map from domain name to ID? From ID to name? From ID to locator? Locator to ID? Are IDs just for 'nodes' or can other things have them such as processes? Interfaces? Processors? People? Networks? Subnetworks? Aggregates? etc. Are IDs used in the packet forwarding process? Where? How? What is the relationship between IDs and Security? What is the relationship between IDs and Integrated Network Services (e.g., resource reservation, TOS/QOS routing, and so on)? What relationship is there between IDs and routing policies? What is the relationship between IDs and the protocols and applications that are layered directly on top of IP (such as ICMP, TCP, etc)? What is the relationship between IDs and auto-configuration? What is the relationship between IDs and network management? How long is an ID in existance? Are IDs carried in each packet? (And at the end of each question, append "why?") Now that I asked the questions, I'll give _my_ answers to some of them (others I have not thought much about...) Does a node have exactly one ID? Or more than one? Any node on the network must have at least one ID. One ID is permanently "bound" to the node. This ID is used in things like auto-configuration to let the node say "I am foo" and then the configuration server can map "foo" to the config parameters needed for the node. Can IDs move around on the network with their node? Yes. This is how we would do mobility. If there are functions that support quering the mapping of an ID to a locator and registering a binding of a locator to an ID ("What is the locator for ID foo?" and "ID foo is now at locator bar") Can IDs move around on the net independant of the node? I would like them to. If there is a function supported _someplace_ in the network of the form "What is the locator for ID foo?" then the thing to which the ID is bound can move through the net, meaning we could do things like mobile processes. (Of course, this also implies a registration service -- "ID foo is now at locator bar"). Is the ID globally or subnet-locally unique? I think that IDs should be globally unique. Or at least unique throughout the entire internet on which they exist. If they are unique to only a particular subnet then they can't be used for mobility (process or node) since there might be a collision. Are IDs used in the packet forwarding process? Where? How? IDs can be used in the packet forwarding process at two points. Once the packet is at the destination subnetwork and you have to get it to the destination node, the ID would disambiguate the destination node from all other nodes on the subnetwork. Also, when doing mobility, at some point there would be an element of the network that would see that the destination subnetwork for the packet has changed, and then forward the packet on in the right manner. What relationship is there between IDs and routing policies? If IDs are assigned by the owners of the hardware (rather than the manufacturers) and are somewhat 'hierarchical' in nature in this regard, then the policy routing subsystem could easily use the IDs as the 'inputs' to the policy routing algorithms. What does the ID identify? Does it identify the node, or does it identify some set of communication endpoints on the node? An ID should identify anything for which an identification is needed. I realize that this is sort of circular, but I don't really know how to put it any other way. What is the interrelationship between IDs and DNS? Can I map from domain name to ID? From ID to name? From ID to locator? Locator to ID? I'd like to be able to do any mapping. If we can't do a particular mapping then we will not be able to build an application that uses that mapping. What is the relationship between IDs and Security? Since IDs define the 'association' between two network entities, they could well be used, at least, as the security context identifier (i.e. indicating which algorithms, etc, are used for this association). The ID could also be an index into a public-key database/directory. What is the relationship between IDs and auto-configuration? I'd imagine that the System ID be used as the key into a local configuration database. But I have not thought much about it. How long is an ID in existance? An ID is in existance for as long as the thing which it identifies is in existance. Changing location on the network does not mean that the thing 'stopped existing'. This is somewhat of a fuzzy definition. For example, if the PC on my desk is taken away from me and assigned to someone else in the company, would it retain the same 'System ID' or not? I'd think not since, if the machine has a new user, it would probably have a different configuration (remember, System ID is used as the key into the configuration database), might end up requiring different policies, and so on. Furthermore, we would not want any 'associations' that are bound to the 'old ID' of the machine (i.e. the one it had when it was my machine) So it seems to me that ID lifetime is more a local administrative issue rather than a technical one. What is the expected administrative plan for IDs? Are they assigned by the system owners or by manufacturers? I think that they should be assigned by the owners of the systems, not the manufacturers. This makes it easy to correct duplicates (it's easier to change a line in a config file than it is to change a serial-number prom on a mother board), not all systems will have manufacturer assigned numbers, and owner-assignment allows ids to be used as an input to the policy routing subsystem. This would indicate that IDs have 2 or 3 levels of 'hierarchy': owner.machine or owner.sublevel.machine. And if there are multiple IDs on a machine then there is an additional level tacked on to the end: owner.sublevel.machine.sub-machine And the 'owner' space might get kind of big, so there might want to be some hierarchy there to assist an building distributed mapping algorithms (e.g. using DNS to go from id to locator): o.w.n.e.r.sublevel.machine.sub-machine -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 03:15:58 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27545; Wed, 8 Jun 1994 03:12:03 +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 AA10510 Wed, 8 Jun 1994 01:03:43 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id BAA16251; Wed, 8 Jun 1994 01:00:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA16245; Wed, 8 Jun 1994 00:55:29 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18171; Tue, 7 Jun 1994 22:38:04 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA16854; Tue, 7 Jun 94 05:33:06 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA21728; Tue, 7 Jun 1994 08:35:25 -0400 Message-Id: <9406071235.AA21728@skidrow.lkg.dec.com> To: smb@research.att.com Cc: sipp@sunroof.Eng.Sun.COM, big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Mon, 06 Jun 94 17:47:16 EDT." <9406062151.AA03304@Sun.COM> Date: Tue, 07 Jun 94 08:35:25 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: smb@research.att.com To: bound@zk3.dec.com Cc: bsimpson@MorningStar.Com, sipp@sunroof.Eng.Sun.COM, big-internet@munnari.oz.au Sender: sipp-request@sunroof.Eng.Sun.COM > I think DNS is the way to avoid collisions. > >That may not work. If the EID uses the MAC address for part of it, >as some folks have suggested, there's no easy administrative >division for DNS zones, as there is with IPv4 addresses. ? I don't know why you say that. There is the obvious split of global MAC addresses with vendor part and the low order part. If you just chop each of these in half, you end up with nothing wider than 4,096, which is prefectly reasonable, and in reality most narrower. >Of course, one can define an EID that doesn't use the MAC addresss, but >some folks have assumed that it would. > > --Steve Bellovin Donald From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 03:21:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27945; Wed, 8 Jun 1994 03:21: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 DAA16558; Wed, 8 Jun 1994 03:20:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA16535; Wed, 8 Jun 1994 03:06:16 +1000 Precedence: list From: bound@zk3.dec.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25988; Wed, 8 Jun 1994 02:36:35 +1000 (from bound@zk3.dec.com) Received: from inet-gw-3.pa.dec.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12868 Wed, 8 Jun 1994 01:31:22 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA02936; Tue, 7 Jun 94 08:04:30 -0700 Received: by xirtlu.zk3.dec.com; id AA12972; Tue, 7 Jun 1994 11:04:19 -0400 Message-Id: <9406071504.AA12972@xirtlu.zk3.dec.com> To: smb@research.att.com Cc: sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Mon, 06 Jun 94 17:47:16 EDT." <9406062151.AA26409@decvax.dec.com> Date: Tue, 07 Jun 94 11:04:13 -0400 X-Mts: smtp = I think DNS is the way to avoid collisions. = =That may not work. If the EID uses the MAC address for part of it, =as some folks have suggested, there's no easy administrative =division for DNS zones, as there is with IPv4 addresses. = =Of course, one can define an EID that doesn't use the MAC addresss, but =some folks have assumed that it would. = = --Steve Bellovin Good point Steve. So obvious I never thought of it. thanks /jim From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 03:32:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28153; Wed, 8 Jun 1994 03:23: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 DAA16575; Wed, 8 Jun 1994 03:22:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA16538; Wed, 8 Jun 1994 03:06:33 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26158; Wed, 8 Jun 1994 02:40:12 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from bridge2.NSD.3Com.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA12356 Wed, 8 Jun 1994 01:25:08 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA02115 (5.65c/IDA-1.4.4nsd for ); Tue, 7 Jun 1994 08:08:38 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA00471 (5.65c/IDA-1.4.4-910725); Tue, 7 Jun 1994 08:08:37 -0700 Message-Id: <199406071508.AA00471@remmel.NSD.3Com.COM> To: sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Tue, 07 Jun 94 10:01:24 EDT." <9406071401.AA09075@mailserv-D.ftp.com> Date: Tue, 07 Jun 94 08:08:35 -0700 From: tracym@NSD.3Com.COM Folks, Please note that we are once again flooding two lists. The topic is psuedo-SIPP addressing, but the context is big-i. (Or is it the other way 'round?-) The SIPP list has better turnaround times (at least for US west coast sites), but a narrower audience. It may also be cheaper, if there are any connect time or (heaven forbid!) packet charges on the long-haul down-under. (kre?) However, I'd suggest big-i is the proper place unless everyone who's contributed is on the sipp list. Tracy From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 03:33:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28199; Wed, 8 Jun 1994 03:24: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 DAA16598; Wed, 8 Jun 1994 03:24:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA16541; Wed, 8 Jun 1994 03:06:46 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26008; Wed, 8 Jun 1994 02:37:09 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA13004 Wed, 8 Jun 1994 01:32:45 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 7 Jun 1994 11:13:04 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 7 Jun 1994 11:13:04 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA10640; Tue, 7 Jun 94 11:11:24 EDT Date: Tue, 7 Jun 94 11:11:24 EDT Message-Id: <9406071511.AA10640@mailserv-D.ftp.com> To: dee@skidrow.lkg.dec.com Subject: Re: 8+8 addressing..... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: smb@research.att.com, sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Content-Length: 975 > > I think DNS is the way to avoid collisions. > > > >That may not work. If the EID uses the MAC address for part of it, > >as some folks have suggested, there's no easy administrative > >division for DNS zones, as there is with IPv4 addresses. > > ? I don't know why you say that. There is the obvious split of global MAC > addresses with vendor part and the low order part. If you just chop each > of these in half, you end up with nothing wider than 4,096, which is prefectly > reasonable, and in reality most narrower. is it possible that the eid-to-foo mapping in the dns should be 'organized' based on the owner of the eid, not the manufacturer of the ethernet card? that is to say, my machine's eid(s) should live under some 'ftp.com' domain (the folks who own the machine) and not under a '3com.com' domain (the folks who made the enet card). -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 03:33:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28290; Wed, 8 Jun 1994 03:26: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 DAA16626; Wed, 8 Jun 1994 03:26:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA16555; Wed, 8 Jun 1994 03:15:35 +1000 Precedence: list From: smb@research.att.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27620; Wed, 8 Jun 1994 03:13:55 +1000 (from smb@research.att.com) Received: from ninet.research.att.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA08483 Wed, 8 Jun 1994 00:39:45 +1000 (from smb@research.att.com) Message-Id: <9406071439.8483@mulga.cs.mu.OZ.AU> Received: by gryphon; Tue Jun 7 10:32:15 EDT 1994 To: "Donald E. Eastlake 3rd (Beast)" Cc: sipp@sunroof.eng.sun.com, big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... Date: Tue, 07 Jun 94 10:32:14 EDT >That may not work. If the EID uses the MAC address for part of it, >as some folks have suggested, there's no easy administrative >division for DNS zones, as there is with IPv4 addresses. ? I don't know why you say that. There is the obvious split of global MAC addresses with vendor part and the low order part. If you just chop each of these in half, you end up with nothing wider than 4,096, which is prefectly reasonable, and in reality most narrower. But neither vendor/low-order nor either chopped in half correspond to administrative divisions, as most current in-addr records do. That was a key design goal of the DNS -- that the zone delegations correspond to administrative boundaries, which means that the updates take place reasonably close to the end system. If I buy a new machine today, and plug it in to my friendly neighborhood LAN, I just walk down the hall, or at most across campus, to the zone administrator to get the forward and inverse map entries created. With your model, I'd have to contact the board manufacturer -- who probably is neither the system manufacturer nor the retailer for most PCs, and with whom I therefore have no a priori relationship -- to have one entry made. This sounds timeconsuming, frustrating, and expensive. (The forward map entry, of course, is installed in the usual fashion.) --Steve Bellovin From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 03:41:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29026; Wed, 8 Jun 1994 03:41: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 DAA16710; Wed, 8 Jun 1994 03:40:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA16682; Wed, 8 Jun 1994 03:32:04 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28564; Wed, 8 Jun 1994 03:31:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05931; Tue, 7 Jun 94 13:31:43 -0400 Date: Tue, 7 Jun 94 13:31:43 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406071731.AA05931@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, sipp@sunroof.eng.sun.com Subject: Re: lower 8 bits of 8+8 format Cc: jnc@ginger.lcs.mit.edu From: smb@research.att.com my basic point is this: one of the reason we're having so much trouble agreeing on whether or not we need EIDs, and on what they should look like, is that we each have a different mental model of their intended uses. Excellent point. On a similar note, the discussion about EID's might be more constructive if we first think about what they do, and put off thinking (and debating) about the details of what they look like in packets, and where they go, if they go in all packets or just some (if they aren't used as part of the flow-id, there may be no reason to include them in all packets), etc, to get this straight first. I'd always gone with the model that an EID was a "computer friendly", location indpendant name for an end-end entity; to be used to identify said entity in end-end communications (e.g. in the TCP pseudo-checksum). As the inventor of the term, I'd like to claim that anything which didn't meet this basic definition, while perhaps a useful thing, is not an EID; also, we may decide we don't need EID's (as defined here), but that's a separate question. If an EID is, in some sense, a name, then you need a hierarchical scheme, so that reverse DNS works. In line with the above, I didn't think we'd be looking up EID's in a directory; it only served an identification purpose, not a cataloguing purpose. If you were a client, you'd get it when you did the DNS lookup on the name the user provided, and if you were a server, you'd get that, with other info, in the ICP. (Speaking of which, one big reason you don't get DNS names in the ICP is that DNS was grafted on at a later stage. It would clearly be helpful to get it as part of the ICP.) From: Matt Crawford there is significant chance of duplicates among 2^32 EIDs quasi-randomly assigned in a 64 bit space. True, but if they are only used for identificataion purposes, this would only be a problem if you have a collision on two hosts which wish to communicate. It is, of course, more of a problem if you want to use them for cataloguing purposes, but a catalogue of a radomly, sparsely, populated ID-space would be tricky anyway. And I, for one, would like to have at least 2 or 3 bytes to use for local topology, and Eric Fleischman would like even more than that. I don't know what you've got in mind here, but this is severely out of phase with the initial conception of EID's, which was that they explicitly and deliberately *did not* carry *any* kind of topological information (local or otherwise); to do so would defeat the entire purpose of EID's, which is to provide a location-independant name. You and Eric may have some useful idea in mind, but please pick a separate name (at least, if it's not a "locator"). Noel From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 04:01:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00257; Wed, 8 Jun 1994 04:01: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 EAA16746; Wed, 8 Jun 1994 04:00:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA16728; Wed, 8 Jun 1994 03:44:10 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29152; Wed, 8 Jun 1994 03:44:07 +1000 (from kre@munnari.OZ.AU) To: sipp@sunroof.Eng.Sun.COM, big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Tue, 07 Jun 1994 08:08:35 MST." <199406071508.AA00471@remmel.NSD.3Com.COM> Date: Wed, 08 Jun 1994 03:44:02 +1000 Message-Id: <21880.771011042@munnari.OZ.AU> From: Robert Elz Date: Tue, 07 Jun 94 08:08:35 -0700 From: tracym@NSD.3Com.COM Message-ID: <199406071508.AA00471@remmel.NSD.3Com.COM> The SIPP list has better turnaround times Mostly - I occasionally get B-I messages before their SIPP equivalents. Munnari is a bit overloaded at times .. [Any of you hardware vendor types have any spare boxes lying around? Doesn't even need to be this year's model... (or last years!)] Apart from load (and mail delays flowing from it) on munnari, I suspect that the perceived delay depends more on how far down each of the lists your name happens to be. It may also be cheaper, if there are any connect time or (heaven forbid!) packet charges on the long-haul down-under. (kre?) No, no time or packet costs (or not at the minute anyway). However, I'd suggest big-i is the proper place I'd tend to agree. kre From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 04:21:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01270; Wed, 8 Jun 1994 04:21: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 EAA16785; Wed, 8 Jun 1994 04:20:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA16762; Wed, 8 Jun 1994 04:05:49 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00361; Wed, 8 Jun 1994 04:05:05 +1000 (from kre@munnari.OZ.AU) To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Tue, 07 Jun 1994 10:01:24 EDT." <9406071401.AA09075@mailserv-D.ftp.com> Date: Wed, 08 Jun 1994 04:04:59 +1000 Message-Id: <21886.771012299@munnari.OZ.AU> From: Robert Elz Date: Tue, 7 Jun 94 10:01:24 EDT From: kasten@ftp.com (Frank Kastenholz) Message-ID: <9406071401.AA09075@mailserv-D.ftp.com> [ I have deleted the sipp list from this ...] Not until you define the characteristics and uses of the Identifier. [list of questions deleted] Now that I asked the questions, I'll give _my_ answers to some of them I agree with essentially all of Frank's answers, with a few comments ... Does a node have exactly one ID? Or more than one? Any node on the network must have at least one ID. When considering EIDs in the abstract, I'd totally forget the notion of "node" (and "host"), they don't help. With IPv4 munnari.oz.au has 2 addresses, but is it one node (host) with 2 interfaces, or two (replicated) hosts? How can you tell? Does it matter? Is ns.uu.net the same thing as ftp.uu.net, they have different addresses, but are they two interfaces on one host or two hosts? How can you tell? For purposes of rough thinking, and probably for most proctical purposes its probably reasonable to think of one EID per box, but nothing should ever actually be assuming that. One ID is permanently "bound" to the node. I think I know what you mean, but I don't agree with this as written. "node", as in "piece of hardware" is pretty much irrelevant. I see EIDs as being a short (comparatively) fixed name for nodes (in a binary form), with approximately the same characteristics as DNS names (so where you'd move a DNS name today, you'd move an EID as well) - except they're not human visible in general, and in any case meaningless, so there's no political pressire to change them because of company mergers, splits, etc - EIDs can survive all of that unscathed. This ID is used in things like auto-configuration to let the node say "I am foo" Here I don't agree at all, the EID should be a result of auto-config, not a parameter to it. Auto-config has to be based on characteristics of the hardware, as that's all that exists when a box first comes out of the box - that means based on manufacturer assigned data. I agree with a later comment of yours that EIDs shoudl be owner assigned. What is the interrelationship between IDs and DNS? Can I map from domain name to ID? From ID to name? From ID to locator? Locator to ID? I'd like to be able to do any mapping. If we can't do a particular mapping then we will not be able to build an application that uses that mapping. I don't think locators should map into anything (which of course has nothing to do with EIDs at all). Mapping from locator imposes restrictions on its form, which ideally, should be optimised to supporting routing, and nothing else. How long is an ID in existance? An ID is in existance for as long as the thing which it identifies is in existance. I agree here, just keep in mind that the "thing" being identified is an abstract idea, not something physical. EIDs should remain as long as DNS type names do assuming no political influences causing them to be changed without other causes. What is the expected administrative plan for IDs? Are they assigned by the system owners or by manufacturers? I think that they should be assigned by the owners of the systems, not the manufacturers. ... This would indicate that IDs have 2 or 3 levels of 'hierarchy': owner.machine or owner.sublevel.machine. I don't think it indicates anything like this at all. Or not necessarily, and the less hierarchy we can build in the better, as the hierarchy wastes space. Still there will be hierarchies of assignment within organisations, and from super-nics to local nics - none of this needs to be fixed however, any more than it is now, or ever was, for IPv4 addresses - once there was one NIC handing out all numbers, now big blocks are allocated to more localised NICS - nothing about the numbers had to change to make that happen. Sim, some organisations have centralised number allocations, others distribute blocks to local departments or groups. From the outside you can't tell. EIDs will have all of those properties. And the 'owner' space might get kind of big, so there might want to be some hierarchy there to assist an building distributed mapping algorithms (e.g. using DNS to go from id to locator): o.w.n.e.r.sublevel.machine.sub-machine This isn't hierarchy, this is just a lexical convention. Something like this will be needed, yes. kre From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 04:41:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02175; Wed, 8 Jun 1994 04:41: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 EAA16848; Wed, 8 Jun 1994 04:40:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA16817; Wed, 8 Jun 1994 04:36:53 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01558; Wed, 8 Jun 1994 04:28:52 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 7 Jun 1994 14:28:48 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 7 Jun 1994 14:28:48 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA14253; Tue, 7 Jun 94 14:27:10 EDT Date: Tue, 7 Jun 94 14:27:10 EDT Message-Id: <9406071827.AA14253@mailserv-D.ftp.com> To: kre@munnari.OZ.AU Subject: Re: 8+8 addressing..... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 2824 > [ I have deleted the sipp list from this ...] kre, you are no fun at all :-) > Does a node have exactly one ID? Or more than one? > Any node on the network must have at least one ID. > > When considering EIDs in the abstract, I'd totally forget > the notion of "node" (and "host"), they don't help. With yeah, you are probably right, except that i sort of see at least one id being 'permanently' bound to a box, uniquely identifying the 'end points' in the box that are permanently associated with that box - for example, the ones for auto configuration, maybe for network management (more specifically, inventory management). in the abstract, you are right i think. however, i see that there will be some endpoints permanently bound to a box, and made the leap of logic to say that there will be endpoint ids bound to the box. > > What is the interrelationship between IDs and DNS? Can I map from domain name > to ID? From ID to name? From ID to locator? Locator to ID? > I'd like to be able to do any mapping. If we can't do a particular mapping > then we will not be able to build an application that uses that > mapping. > > I don't think locators should map into anything (which of course > has nothing to do with EIDs at all). Mapping from locator > imposes restrictions on its form, which ideally, should be > optimised to supporting routing, and nothing else. well, i'd like to be able to take a packet, pull the source locator out of it, and then see where that packet came from. except, i guess i can also do that from the source eid (and it is more likely that a shortish eid will be in all packets than a longish locator). so finding the source node of a packet doesn't need the locator. however, i might want to know who is 'at' some position -- who owns which network and the like -- perhaps as a function of managing the routing subsystem. so if it is possible to do a reverse mapping from locator to some administrative tag (e.g. domain name) without sacrificing the routing functions, then i'd like to see it available. but we digress from ids... > And the 'owner' space might get kind of big, so there might want to > be some hierarchy there to assist an building distributed mapping > algorithms (e.g. using DNS to go from id to locator): > o.w.n.e.r.sublevel.machine.sub-machine > > This isn't hierarchy, this is just a lexical convention. > Something like this will be needed, yes. it would be hierarchical since it is something that i can feed into a distributed database system ala dns and get answers (e.g. locators, 'owning' domains, etc) back with reasonable efficiency. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 05:07:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03092; Wed, 8 Jun 1994 05:01: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 FAA16882; Wed, 8 Jun 1994 05:00:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA16866; Wed, 8 Jun 1994 04:55:00 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02883; Wed, 8 Jun 1994 04:54:57 +1000 (from kre@munnari.OZ.AU) To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Tue, 07 Jun 1994 14:27:10 EDT." <9406071827.AA14253@mailserv-D.ftp.com> Date: Wed, 08 Jun 1994 04:54:50 +1000 Message-Id: <21931.771015290@munnari.OZ.AU> From: Robert Elz Date: Tue, 7 Jun 94 14:27:10 EDT From: kasten@ftp.com (Frank Kastenholz) Message-ID: <9406071827.AA14253@mailserv-D.ftp.com> kre, you are no fun at all :-) Yeah - I also like to pull the wings off helpless NSAPs... well, i'd like to be able to take a packet, pull the source locator out of it, I have this half baked idea floating around in my head that source locators are a waste of time, and shouln't be in random packets in any case (they would appear in request type icmp's, and in some form of orderly route finding packets, etc, but that's about all). however, i might want to know who is 'at' some position -- who owns which network and the like That's more a function os a whois type server, than of DNS. You don't need to get a specific node name from a locator to do this - what's more, if you do, there's no guarantee that it would have the info that you require, node names don't necessarily reflect the owner of the net on which they reside. Whois databases are much more centralised, need to be updated much less often, and can use more imaginative techniques to perform searches than the DNS (or any other hugely distributed database) realistically can. Further, for this if you have to hunt a little to find te right server to ask, that's OK too. but we digress from ids... Yes. it would be hierarchical since it is something that i can feed into a distributed database yes, but this kind of hierarchy can be extracted out of anything. Eg: the netnumber here is 128.250 - that's a single number, however it can be decomposed into two, or if you wanted, even four (8.0.F.A) - or other numbers of components for the purposes of distributing the database. This stuff is too trivial to bother with - its obviously needed, but is just as obviously easy to devise. kre From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 05:21:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03889; Wed, 8 Jun 1994 05:21: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 FAA16921; Wed, 8 Jun 1994 05:20:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA16915; Wed, 8 Jun 1994 05:16:10 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02484; Wed, 8 Jun 1994 04:48:27 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA09618; Tue, 7 Jun 94 11:36:42 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA26012; Tue, 7 Jun 1994 14:39:02 -0400 Message-Id: <9406071839.AA26012@skidrow.lkg.dec.com> To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Tue, 07 Jun 94 11:11:24 EDT." <9406071511.AA10640@mailserv-D.ftp.com> Date: Tue, 07 Jun 94 14:39:02 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: kasten@ftp.com (Frank Kastenholz) To: dee Reply-To: kasten@ftp.com Cc: smb@research.att.com, sipp@sunroof.Eng.Sun.COM, big-internet@munnari.oz.au Content-Length: 975 Sender: sipp-request@sunroof.Eng.Sun.COM > > > I think DNS is the way to avoid collisions. > > > > > >That may not work. If the EID uses the MAC address for part of it, > > >as some folks have suggested, there's no easy administrative > > >division for DNS zones, as there is with IPv4 addresses. > > > > ? I don't know why you say that. There is the obvious split of global MAC > > addresses with vendor part and the low order part. If you just chop each > > of these in half, you end up with nothing wider than 4,096, which is prefectly > > reasonable, and in reality most narrower. > >is it possible that the eid-to-foo mapping in the dns should be >'organized' based on the owner of the eid, not the manufacturer of >the ethernet card? > >that is to say, my machine's eid(s) should live under some 'ftp.com' >domain (the folks who own the machine) and not under a '3com.com' >domain (the folks who made the enet card). That's fine if you want ftp.com to be part of the EID. I would assume it should all be under in-eid.arpa or something shorter. >-- >Frank Kastenholz >FTP Software >2 High Street >North Andover, Mass. USA 01845 >(508)685-4000 Donald From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 05:32:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03982; Wed, 8 Jun 1994 05:23: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 FAA16936; Wed, 8 Jun 1994 05:23:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA16918; Wed, 8 Jun 1994 05:16:26 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01567; Wed, 8 Jun 1994 04:29:29 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA08241; Tue, 7 Jun 94 11:15:55 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA25669; Tue, 7 Jun 1994 14:18:12 -0400 Message-Id: <9406071818.AA25669@skidrow.lkg.dec.com> To: smb@research.att.com Cc: "Donald E. Eastlake 3rd (Beast)" , big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Tue, 07 Jun 94 10:32:14 EDT." <9406071439.8483@mulga.cs.mu.OZ.AU> Date: Tue, 07 Jun 94 14:18:12 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp From: smb@research.att.com Precedence: list To: "Donald E. Eastlake 3rd (Beast)" Cc: sipp@sunroof.eng.sun.com, big-internet@munnari.oz.au > >That may not work. If the EID uses the MAC address for part of it, > >as some folks have suggested, there's no easy administrative > >division for DNS zones, as there is with IPv4 addresses. > > ? I don't know why you say that. There is the obvious split > of global MAC addresses with vendor part and the low order > part. If you just chop each of these in half, you end up with > nothing wider than 4,096, which is prefectly reasonable, and > in reality most narrower. > >But neither vendor/low-order nor either chopped in half correspond to >administrative divisions, as most current in-addr records do. That was >a key design goal of the DNS -- that the zone delegations correspond to >administrative boundaries, which means that the updates take place >reasonably close to the end system. I don't think its that essential to have inverse DNS lookup be very close. If EIDs are flat via MAC or hashed key or hierarchial by some assignment tree that does not correspond to deployment, its all the same. The manufacturer at least has some encentive to run a DNS to support their product. I suspect that vandor sorted MAC numbers are not uniformly distributed over the world in any case. >If I buy a new machine today, and plug it in to my friendly neighborhood >LAN, I just walk down the hall, or at most across campus, to the zone >administrator to get the forward and inverse map entries created. With >your model, I'd have to contact the board manufacturer -- who probably >is neither the system manufacturer nor the retailer for most PCs, and >with whom I therefore have no a priori relationship -- to have one >entry made. This sounds timeconsuming, frustrating, and expensive. >(The forward map entry, of course, is installed in the usual fashion.) If people wanted to construct and inverse map of IEEE MAC addresses in DNS, I'm sure this would all be overcome. Maybe some manufacturers would like to run such a service as a value added. Maybe in other cases, someone would do so on a volunteer or commercial basis. While I'm in favor of continuing on a volunteer non-commerical basis as long as possible, I would not be surprised to find the maintenance of the root DNS server database being eventually done on a fee basis. > --Steve Bellovin Donald From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 06:01:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05727; Wed, 8 Jun 1994 06:01: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 GAA17002; Wed, 8 Jun 1994 06:00:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA16983; Wed, 8 Jun 1994 05:46:38 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04810; Wed, 8 Jun 1994 05:43:47 +1000 (from kre@munnari.OZ.AU) To: "Donald E. Eastlake 3rd (Beast)" Cc: smb@research.att.com, big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Tue, 07 Jun 1994 14:18:12 -0400." <9406071818.AA25669@skidrow.lkg.dec.com> Date: Wed, 08 Jun 1994 05:43:43 +1000 Message-Id: <21948.771018223@munnari.OZ.AU> From: Robert Elz Date: Tue, 07 Jun 94 14:18:12 -0400 From: "Donald E. Eastlake 3rd (Beast)" Message-ID: <9406071818.AA25669@skidrow.lkg.dec.com> I don't think its that essential to have inverse DNS lookup be very close. That's right, its not too important where the lookup is performed. It is important where DNS updates are performed however, they do need to be as close as possible to the systems involved. Local staff tend to be able to be persuaded to make necessary updates quickly, remote ones much less easily. It is also convenient, if not essential, if the server for lookups is close to the source of most queries - both for keeping traffic as close as possible, and so that network outages have less impact (I know I wouldn't much like it if my lookups depended upon a server the other side of some slip link). kre From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 07:21:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08460; Wed, 8 Jun 1994 07:21: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 HAA17083; Wed, 8 Jun 1994 07:20:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA17080; Wed, 8 Jun 1994 07:20:25 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08430; Wed, 8 Jun 1994 07:20:18 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA04021; Tue, 7 Jun 94 17:20:10 -0400 Date: Tue, 7 Jun 94 17:20:10 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: <9406072120.AA04021@rodan.UU.NET> To: big-internet@munnari.OZ.AU Subject: 2 levels of heirarchy???? No, I did not propose just two levels of heirarchy - I proposed 2 levels that would be recognized universally, and left 4 lower 4 bytes of the upper 8 to be sliced and diced as needed within an organization. -mo From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 07:41:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09027; Wed, 8 Jun 1994 07:41: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 HAA17128; Wed, 8 Jun 1994 07:40:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA17112; Wed, 8 Jun 1994 07:34:30 +1000 Precedence: list Received: from nic.dsi.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07962; Wed, 8 Jun 1994 07:00:15 +1000 (from @gaak.bbn.com:MAP=Bounce@nic.dsi.net) Received: from GAAK.BBN.COM by nic.dsi.net id aa09835; 7 Jun 94 17:01 EDT Date: Tue, 7 Jun 1994 16:59:15 EDT Message-Id: To: atkinson@itd.nrl.navy.mil Cc: big-Internet@munnari.OZ.AU In-Reply-To: <9406070909.ZM12353@sundance.itd.nrl.navy.mil> (message from Ran Atkinson on Tue, 7 Jun 1994 09:09:12 -0500) Subject: Re: dotted notation considered awkward Reply-To: MAP=Reply@nic.dsi.net From: "Michael A. Patton" I very much agree with Ran. I'm in the process of writing (as I [was] volunteered to do at the last IETF :-) a document describing one aspect of this which many have even thought impossible (not just hard to understand, but technically undoable) which is DNS delegation. It's actually caused me to think quite a bit about the human factors of representations that are byte-aligned when the underlying data isn't. (and it hasn't hurt that my home net is a subnetted class C which occasionally causes _me_ problems in address mapping :-) I've been batting around an idea in the back of my head to retrofit a better human factors address representation in IPv4 (which may extend into any of the IPng candidates). The interesting point to note is that this is actually a purely local user-interface matter. I could solve it on my system(*), without any one else needing to participate. I just need to fix the parser to recognize the new form and the address printer to print it (then make sure all the programs use the library rather than having their own parser routines). -MAP (*) The specific scheme I've been working on (which depends a bit on Kampai [I think that was what it was called], but not much) could locally PARSE any numbers, and print out formatted numbers it knew the mask for, but it would also only take local action to define this for the ones where I'm liable to care anyway (my local nets). The main reason I don't describe the specific scheme for IPv4 here is that I don't have time right now, and I believe the total cost to refit IPv4 would cost too much for the limited life. On the other hand, if there's an outcry... From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 08:43:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01094; Wed, 8 Jun 1994 08:41: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 IAA17216; Wed, 8 Jun 1994 08:40:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA17183; Wed, 8 Jun 1994 08:29:05 +1000 Precedence: list Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00453; Wed, 8 Jun 1994 08:29:00 +1000 (from barney@databus.databus.com) Date: Tue, 7 Jun 94 18:35 EDT Message-Id: <9406071835.AA09052@databus.databus.com> From: Barney Wolff To: big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... Content-Length: 1653 Content-Type: text > Date: Wed, 08 Jun 1994 04:04:59 +1000 > From: Robert Elz > > I don't think it indicates anything like this at all. Or > not necessarily, and the less hierarchy we can build in the > better, as the hierarchy wastes space. Still there will be > hierarchies of assignment within organisations, and from > super-nics to local nics - none of this needs to be fixed > however, any more than it is now, or ever was, for IPv4 > addresses - once there was one NIC handing out all numbers, now > big blocks are allocated to more localised NICS - nothing about > the numbers had to change to make that happen. Sim, some > organisations have centralised number allocations, others > distribute blocks to local departments or groups. From the > outside you can't tell. EIDs will have all of those properties. > > And the 'owner' space might get kind of big, so there might want to > be some hierarchy there to assist an building distributed mapping > algorithms (e.g. using DNS to go from id to locator): > o.w.n.e.r.sublevel.machine.sub-machine > > This isn't hierarchy, this is just a lexical convention. > Something like this will be needed, yes. Either we give up on reverse lookups, or there is explicit, fixed, hierarchy in the EID. The notion that somebody other than the org that owns an EID will be running the name server that holds the in-addr.arpa++ domain for it just falls apart, imho, when we are planning for 1e15 EIDs. So I have to know how to parse it, to find the right name server. Or are we saying that with >= 8 bytes, byte boundaries are good enough? Barney Wolff From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 10:21:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05522; Wed, 8 Jun 1994 10:21: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 KAA17334; Wed, 8 Jun 1994 10:21:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA17320; Wed, 8 Jun 1994 10:01:42 +1000 Precedence: list Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04578; Wed, 8 Jun 1994 10:01:19 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA13167; Tue, 7 Jun 94 20:00:47 EDT Message-Id: <9406080000.AA13167@tipper.oit.unc.edu> To: Barney Wolff Cc: big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Tue, 07 Jun 94 18:35:00 EDT." <9406071835.AA09052@databus.databus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Jun 94 20:00:46 -0400 From: Simon E Spero I've been working on reverse lookups for 64bit randomly distributed EIDs, and I've got a scheme that looks like it'll work, based on centroids and chunking the EID in various ways (there's a whole bunch of tradeoffs that can balance time, space, and bandwidth , and it looks like there's a nice space of solutions to handle different scaling points). I haven't got anything I can post (a truly remarkable proof, which the battery of my powerbook was too small to contain), but I'll try and get something before Interop Berlin finishes. Simon From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 10:59:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01972; Wed, 8 Jun 1994 09: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 JAA17250; Wed, 8 Jun 1994 09:00:59 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA17232; Wed, 8 Jun 1994 08:44:26 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09479; Wed, 8 Jun 1994 07:53:31 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HD9NILLT2O004EGZ@FNAL.FNAL.GOV>; Tue, 7 Jun 1994 16:53:04 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA24097; Tue, 7 Jun 94 16:53:00 CDT Date: Tue, 07 Jun 1994 16:53:00 -0500 From: Matt Crawford Subject: Re: lower 8 bits of 8+8 format In-Reply-To: Your message of Tue, 07 Jun 94 13:31:43 EDT. <9406071731.AA05931@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM Message-Id: <9406072153.AA24097@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > And I, for one, would like to have at least 2 or 3 bytes to use for > local topology, and Eric Fleischman would like even more than that. > > I don't know what you've got in mind here, but this is severely out of phase > with the initial conception of EID's, ... I didn't mean to appear so terminologically impaired as to suggest doing locator-things with my EIDs. I was trying to say that I want to have some bits in the IPng address which are *mine* to assign for my own nefarious purposes. Practically as soon as SIPP adopted 16 byte addresses in the smoke-filled room, people were talking of dividing them into 8+8, with the upper 8 assigned along geo/provider/subscriber lines. The next thing we saw was people wanting to allocate the remaining 8 as EIDs, leaving nothing in between! _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 11:21:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08257; Wed, 8 Jun 1994 11:21: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 LAA17428; Wed, 8 Jun 1994 11:21:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA17423; Wed, 8 Jun 1994 11:13:50 +1000 Precedence: list Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04103; Wed, 8 Jun 1994 09:49:26 +1000 (from hughf@cs.anu.edu.au) Received: from yildun.anu.edu.au by shark.mel.dit.csiro.au with SMTP id AA00390 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 8 Jun 1994 09:49:23 +1000 Received: (from hughf@localhost) by yildun.anu.edu.au (8.6.9/8.6.9) id JAA05186 for big-internet@munnari.oz.au; Wed, 8 Jun 1994 09:42:04 +1000 From: Hugh Fisher Message-Id: <199406072342.JAA05186@yildun.anu.edu.au> Subject: CLNP with IP addressing & routing? To: big-internet@munnari.OZ.AU Date: Wed, 8 Jun 1994 09:41:58 +1000 (EST) X-Face: IzZbOk_&E(oY<6o8_9:zVxVbU&@T&']zY6~vlKeu<%Xnr"f4F?+_bAEjZ4as%{W*pufyaPP AN7-\xfyYr$}N4+_%c.5"P~jpS3c+*Mp'\k5cU1U_yX=OS&'='U>U}\HJXl!Vn(#$q38k~VKU^m|q- JAfcGK(n=ytcde8m9^1NJ X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 842 Has anyone tried running CLNP using Internet addressing and routing? What I'm thinking of is the NSAP as an eight byte "Internet CLNP" address: length AFI/IDI DSP 7 <2 byte value> IP address.PROTO or perhaps have the PROTO field first so that it is in the same spot even if the addresses get longer: 7 <2 byte value> PROTO.IP address (The AFI/IDI is 2 bytes 'cause that makes it a nice 8 byte field - can you have such a thing? Or would you have to decree the Internet a private organisation and use 49.00?) Seems to me that with something like this you could introduce CLNP as a new packet format that works with existing routing tables and DNS entries. Just curious - if it's a stupid question, please flame me privately rather than wasting big-internet bandwith. Hugh Fisher From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 11:23:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08297; Wed, 8 Jun 1994 11:23: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 LAA17443; Wed, 8 Jun 1994 11:22:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA17409; Wed, 8 Jun 1994 11:09:52 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01968; Wed, 8 Jun 1994 09:04:57 +1000 (from kre@munnari.OZ.AU) To: Barney Wolff Cc: big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Tue, 07 Jun 1994 18:35:00 EDT." <9406071835.AA09052@databus.databus.com> Date: Wed, 08 Jun 1994 09:01:03 +1000 Message-Id: <22100.771030063@munnari.OZ.AU> From: Robert Elz Date: Tue, 7 Jun 94 18:35 EDT From: Barney Wolff Message-ID: <9406071835.AA09052@databus.databus.com> Either we give up on reverse lookups, or there is explicit, fixed, hierarchy in the EID. Yes (though it could be an explicit parseable hierarchy, much like class A/B/C addresses can be recognised, though I doubt anyone wants that). So I have to know how to parse it, to find the right name server. Yes - that basically means you need to know how to divide the ascii representation of the EID into things that look like (or are) domains. That's what I meant by a "lexical convention". It does need to be established, and defined, but doing that shouldn't be difficult. Or are we saying that with >= 8 bytes, byte boundaries are good enough? For the purpose of the rest of this message, it doesn't matter. Byte boundaries are one lexical convention, nybble boundaries would be another, writing the whole address in binary, and putting domain boundaries after each bit would be another. In any case it certainly has to be defined. As it happens, for EIDs I think that byte boundaries would be just fine - they're essentially a flat space, allocating them in units of 256 (note: no restrictions on using 0 or all 1's in EIDs) seems like a suitable allocation unit, and allocating those units in groups of 256 to large organisations of small NICs, and those in groups of 256 to large NICs seems sensible. When you run out of one allocation, you simply get another. The DNS tree may be a bit bushier than we're used to with IN-ADDR.ARPA but it would still be perfectly functional. On the other hand, for locators I very much don't think that byte boundaries are meaningful for anything at all, and its attempts to make things fit nicely on byte boundaries that waste excessive amounts of address space. Further, I don't believe that any fixed partitioning at all can work while not being overly wasteful - each hierarchy has to have the flexibility to break up its own part of the space however it suits the local area. That's one reason why I don't believe that ain in-addr.arpa equivalent for locators makes sense. Attempting to reconcile the lexical conventions for the DNS lookup, and the sliding boundaries you want for routing is just too difficult - just as the vast majority of sites with class B (or A) numbers subnet them neatly on byte boundaris, as that fits with the lexical conventions for in-addr.arpa. kre From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 13:01:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12365; Wed, 8 Jun 1994 13:01: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 NAA17578; Wed, 8 Jun 1994 13:01:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA17561; Wed, 8 Jun 1994 12:44:21 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06287; Wed, 8 Jun 1994 10:39:08 +1000 (from Erik.Nordmark@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA03829; Tue, 7 Jun 94 17:38:49 PDT Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1/SMI-4.1) id AA25168; Tue, 7 Jun 94 17:41:04 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA11791; Tue, 7 Jun 1994 17:38:43 -0700 Date: Tue, 7 Jun 1994 17:38:43 -0700 From: Erik.Nordmark@Eng.Sun.COM (Erik Nordmark) Message-Id: <9406080038.AA11791@jurassic.Eng.Sun.COM> To: jnc@ginger.lcs.mit.edu Subject: Re: lower 8 bits of 8+8 format Cc: big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM Mime-Version: 1.0 > there is significant chance of duplicates among 2^32 EIDs quasi-randomly > assigned in a 64 bit space. > > True, but if they are only used for identificataion purposes, this would only > be a problem if you have a collision on two hosts which wish to communicate. If the EID is used for TCP connection identification (as you state) then collisions between two hosts will cause problems if these two hosts communicate with a third host at the same time. The third host's TCP would not be able to distiguish between the two connections (assuming the port numbers are the same). The above case, which will be common if there are some very popular information service providers out there, will be difficult to diagnose and rectify since it will be transient in nature and it has global scope. Erik From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 13:03:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07326; Wed, 8 Jun 1994 11:01: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 LAA17391; Wed, 8 Jun 1994 11:01:00 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA17377; Wed, 8 Jun 1994 10:52:46 +1000 Precedence: list Received: from achilles.ctd.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02054; Wed, 8 Jun 1994 09:07:35 +1000 (from b30118@achilles.ctd.anl.gov) Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA26359; Tue, 7 Jun 94 18:02:27 CDT Date: Tue, 7 Jun 94 18:02:27 CDT Message-Id: <9406072302.AA26359@achilles.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... From: "Richard Carlson" >Date: Wed, 08 Jun 1994 04:04:59 +1000 >Message-Id: <21886.771012299@munnari.OZ.AU> >From: Robert Elz >When considering EIDs in the abstract, I'd totally forget >the notion of "node" (and "host"), they don't help. With >IPv4 munnari.oz.au has 2 addresses, but is it one node (host) >with 2 interfaces, or two (replicated) hosts? How can you tell? >Does it matter? Never having seen an offical definition of EID's, references please, I had always assumed they were as Robert describes. But it's not clear to me what you get by using them if they are just coded DNS names. Why, and how, should they be be used? If they are to be used to provide CIDR like routing, (i.e. they identify an orgination) then they have a definite hierarchical structure. If they don't provide any routing information, and I don't think they should, then why are they taking up space in the network layer address. I would like to propose that EID's be used assigned to the TCP layer of a node. Nodes would communicate by building TCP packets with source and destination EID addresses. These packets would be passed down to the IP layer for routing and delivery. The problem of hosts having multiple interfaces would be eliminated. EID's would be globaly unique, contain now routing information, and are passed between communicating nodes. Isn't this what EID's are suppose to do? Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 13:03:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12420; Wed, 8 Jun 1994 13:03: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 NAA17595; Wed, 8 Jun 1994 13:03:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA17564; Wed, 8 Jun 1994 12:50:37 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11997; Wed, 8 Jun 1994 12:50:30 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA24882; Tue, 7 Jun 94 19:47:22 -0700 Received: by xirtlu.zk3.dec.com; id AA27754; Tue, 7 Jun 1994 22:47:10 -0400 Message-Id: <9406080247.AA27754@xirtlu.zk3.dec.com> To: "Richard Carlson" Cc: big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Tue, 07 Jun 94 18:02:27 CDT." <9406072302.AA26359@achilles.ctd.anl.gov> Date: Tue, 07 Jun 94 22:47:04 -0400 X-Mts: smtp >Never having seen an offical definition of EID's, references please, I >had always assumed they were as Robert describes. But it's not clear to >me what you get by using them if they are just coded DNS names. Why, and >how, should they be be used? If they are to be used to provide CIDR like >routing, (i.e. they identify an orgination) then they have a definite >hierarchical structure. If they don't provide any routing information, >and I don't think they should, then why are they taking up space in the >network layer address. If they are not in the network layer address how would they ever get delivered? >I would like to propose that EID's be used assigned to the TCP layer of >a node. Nodes would communicate by building TCP packets with source and >destination EID addresses. These packets would be passed down to the >IP layer for routing and delivery. The problem of hosts having multiple >interfaces would be eliminated. EID's would be globaly unique, contain >now routing information, and are passed between communicating nodes. Isn't >this what EID's are suppose to do? If they are passed between communicating nodes how? What about the mobile case? But I like where your headed. thanks /jim Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 13:08:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09090; Wed, 8 Jun 1994 11:41: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 LAA17492; Wed, 8 Jun 1994 11:41:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA17470; Wed, 8 Jun 1994 11:28:31 +1000 Received: from olympus.wustl.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08575; Wed, 8 Jun 1994 11:28:27 +1000 (from daemon@olympus.wustl.edu) Received: (from daemon@localhost) by olympus.wustl.edu (8.6.8.1/8.6.6.yuck) id UAA22795 for big-internet@munnari.oz.au; Tue, 7 Jun 1994 20:27:14 -0500 To: big-internet@munnari.OZ.AU Path: wuccrc!big-internet From: RACarlson@anl.gov (Richard Carlson) Newsgroups: ccrc.mlists.big-internet Subject: Re: 8+8 addressing..... Message-Id: <80794@olympus.wustl.edu> Date: 8 Jun 94 01:27:13 GMT Sender: daemon@dworkin.wustl.edu Lines: 34 Precedence: list >Message-Id: <21886.771012299@munnari.OZ.AU> >From: Robert Elz Distribution: ccrc Approved: usenet >When considering EIDs in the abstract, I'd totally forget >the notion of "node" (and "host"), they don't help. With >IPv4 munnari.oz.au has 2 addresses, but is it one node (host) >with 2 interfaces, or two (replicated) hosts? How can you tell? >Does it matter? Never having seen an offical definition of EID's, references please, I had always assumed they were as Robert describes. But it's not clear to me what you get by using them if they are just coded DNS names. Why, and how, should they be be used? If they are to be used to provide CIDR like routing, (i.e. they identify an orgination) then they have a definite hierarchical structure. If they don't provide any routing information, and I don't think they should, then why are they taking up space in the network layer address. I would like to propose that EID's be used assigned to the TCP layer of a node. Nodes would communicate by building TCP packets with source and destination EID addresses. These packets would be passed down to the IP layer for routing and delivery. The problem of hosts having multiple interfaces would be eliminated. EID's would be globaly unique, contain now routing information, and are passed between communicating nodes. Isn't this what EID's are suppose to do? Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 15:41:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18282; Wed, 8 Jun 1994 15:41: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 PAA17750; Wed, 8 Jun 1994 15:41:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA17736; Wed, 8 Jun 1994 15:37:51 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18047; Wed, 8 Jun 1994 15:37:40 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 8 Jun 94 14:30:00 +0900 From: Masataka Ohta Message-Id: <9406080530.AA19504@necom830.cc.titech.ac.jp> Subject: Re: Locator Sizes To: kasten@ftp.com Date: Wed, 8 Jun 94 14:29:58 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9406071405.AA09157@mailserv-D.ftp.com>; from "Frank Kastenholz" at Jun 7, 94 10:05 am X-Mailer: ELM [version 2.3 PL11] > Average Aggregation > Efficiency Level Count > 1:10 12 > 1:20 9+ > 1:50 7+ > 1:100 6 > 1:1000 4 > > I do not think that 1:10 is useful. I do not think that we will see 1:1000 > aggregation. I'd bet that the maximum level of aggregation we will > see, _on_average_ over the network, will be between 1:50 and 1:100. Why? Even RIP can handle 1:1000. Considering the today's operation of BGP, aggregation of 1:10,000 or even 1:100,000 is not so unrealistic, I think. That is, routers can maitain 100,000 routing entries. > Now the question is "how many bytes/level" do we need? 8 to make SIPP simple. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 16:21:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20031; Wed, 8 Jun 1994 16:21: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 QAA17803; Wed, 8 Jun 1994 16:21:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA17797; Wed, 8 Jun 1994 16:16:49 +1000 Precedence: list Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19866; Wed, 8 Jun 1994 16:16:44 +1000 (from barney@databus.databus.com) Date: Wed, 8 Jun 94 02:23 EDT Message-Id: <9406080223.AA10180@databus.databus.com> From: Barney Wolff To: big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... Content-Length: 457 Content-Type: text Count me in the camp that says EIDs should have at least a few bits that say how to parse the rest. Call it insurance against lack of foresight. Most routines which look at the EID wouldn't care, but it might be an occasional lifesaver. I also worry, with very bushy trees, about load on root nameservers and how much my local one has to cache so it's not forever asking a root for info. But I guess that's off topic. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 18:54:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20106; Wed, 8 Jun 1994 16:23: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 QAA17818; Wed, 8 Jun 1994 16:23:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA17800; Wed, 8 Jun 1994 16:19:23 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19935; Wed, 8 Jun 1994 16:19:14 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 8 Jun 94 15:13:34 +0900 From: Masataka Ohta Message-Id: <9406080613.AA19780@necom830.cc.titech.ac.jp> Subject: Re: 8+8 addressing..... To: big-internet@munnari.OZ.AU Date: Wed, 8 Jun 94 15:13:32 JST In-Reply-To: <9406071401.AA09075@mailserv-D.ftp.com>; from "Frank Kastenholz" at Jun 7, 94 10:01 am X-Mailer: ELM [version 2.3 PL11] > Does a node have exactly one ID? Or more than one? > Can IDs move around on the network with their node? > Can IDs move around on the net independant of the node? > What does the ID identify? Does it identify the node, or does it identify > some set of communication endpoints on the node? > Is the ID globally or subnet-locally unique? > What is the expected administrative plan for IDs? Are they assigned > by the system owners or by manufacturers? > What is the interrelationship between IDs and DNS? Can I map from domain name > to ID? From ID to name? From ID to locator? Locator to ID? > Are IDs just for 'nodes' or can other things have them such as processes? > Interfaces? Processors? People? Networks? Subnetworks? Aggregates? etc. > Are IDs used in the packet forwarding process? Where? How? > What is the relationship between IDs and Security? > What is the relationship between IDs and Integrated Network Services (e.g., > resource reservation, TOS/QOS routing, and so on)? > What relationship is there between IDs and routing policies? > What is the relationship between IDs and the protocols and applications that > are layered directly on top of IP (such as ICMP, TCP, etc)? > What is the relationship between IDs and auto-configuration? > What is the relationship between IDs and network management? > How long is an ID in existance? > Are IDs carried in each packet? > (And at the end of each question, append "why?") And the metaquestion is Should we provide different kinds of IDs for different requirements? I think the answer is "Yes". Today, MAC address and IP address are acting as datalink and network layer EIDs, IP address combined with port number is acting as transport layer EID. BTW, why should we determine the length of EID or locator now? SIPP with IPAE has 4+4 locator/EID structure until 32 bit space is full, and ASEQ mechanism can support 8*n+8*m locator/EID in the future. NSAP with general purpose and, as a result, stiff structure, has more limitations. But, with source routing, it is not impossible to have 20+20 locator/EID. So, can't we make decision after we have experiences with working code? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 21:08:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25028; Wed, 8 Jun 1994 18:23: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 SAA17940; Wed, 8 Jun 1994 18:21:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA17926; Wed, 8 Jun 1994 18:07:42 +1000 Precedence: list Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11788; Wed, 8 Jun 1994 12:45:10 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA24165; Tue, 7 Jun 94 22:44:43 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9406080244.AA24165@wizard.gsfc.nasa.gov> Subject: Re: 8+8 addressing..... To: kre@munnari.OZ.AU (Robert Elz) Date: Tue, 7 Jun 1994 22:44:43 -0400 (EDT) Cc: dee@skidrow.lkg.dec.com, smb@research.att.com, big-internet@munnari.OZ.AU In-Reply-To: <21948.771018223@munnari.OZ.AU> from "Robert Elz" at Jun 8, 94 05:43:43 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: 1309 > Date: Tue, 07 Jun 94 14:18:12 -0400 > From: "Donald E. Eastlake 3rd (Beast)" > Message-ID: <9406071818.AA25669@skidrow.lkg.dec.com> > > I don't think its that essential to have inverse DNS lookup > be very close. > > That's right, its not too important where the lookup is > performed. > > It is important where DNS updates are performed however, they > do need to be as close as possible to the systems involved. > Local staff tend to be able to be persuaded to make necessary > updates quickly, remote ones much less easily. > > It is also convenient, if not essential, if the server for > lookups is close to the source of most queries - both for > keeping traffic as close as possible, and so that network > outages have less impact (I know I wouldn't much like it if > my lookups depended upon a server the other side of some slip > link). > > kre Also, let's remember that the Internet isn't the entire IP universe either. There are lots of isolated internets out there and things have to work for them too. Thus a vendor registry of MAC addresses on the Internet for doing reverse DNS queries just doesn't cut it for the isolated folks. And then there's the problem of what happens when companies go out of business. -Bill From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 21:09:10 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26128; Wed, 8 Jun 1994 18:49: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 AA21758 Wed, 8 Jun 1994 18:46: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 SAA17987; Wed, 8 Jun 1994 18:41:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA17973; Wed, 8 Jun 1994 18:37:38 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18678; Wed, 8 Jun 1994 15:49:17 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 8 Jun 94 14:43:33 +0900 From: Masataka Ohta Message-Id: <9406080543.AA19563@necom830.cc.titech.ac.jp> Subject: Re: lower 8 bits of 8+8 format To: big-internet@munnari.OZ.AU Date: Wed, 8 Jun 94 14:43:31 JST In-Reply-To: <9406071731.AA05931@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 7, 94 1:31 pm X-Mailer: ELM [version 2.3 PL11] > there is significant chance of duplicates among 2^32 EIDs quasi-randomly > assigned in a 64 bit space. > > True, but if they are only used for identificataion purposes, this would only > be a problem if you have a collision on two hosts which wish to communicate. Then, we need only a single bit for EID but considering future extension, let's assign 8 bits to EID. A caller is assigned EID of 1 and a callee 3. You may call it variant of X.25. Of course such EID is useless because identification on the routers along the path is often required. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jun 8 21:21:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00924; Wed, 8 Jun 1994 21: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 VAA18131; Wed, 8 Jun 1994 21:21:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18117; Wed, 8 Jun 1994 21:08:01 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00561; Wed, 8 Jun 1994 21:07:57 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA05237; Wed, 8 Jun 94 06:09:09 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id af19247; 8 Jun 94 11:06 GMT Date: Wed, 8 Jun 94 06:06 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: atkinson To: big Internet Subject: Re: dotted notation considered awkward Message-Id: <03940608110630/0003858921NA3EM@mcimail.com> Ran said: > The dotted notation for IPv4 addresses makes it harder for mere >mortals to subnet along arbitrary bit boundaries (and have better >address space utilisation) than to subnet along 8-bit boundaries (and >have low address space utilisation). This is a human-factors issue, >not strictly a bit-twiddling issue. > Perhaps IPng should use a different human-readable notation that >would tend to encourage variable-length subnetting and higher address >density. Hexadecimal would at least make nibble (4-bit) alignment >much easier to read. There are probably better ideas out there. > We should consider these human factors issues as we ponder selection >and deployment of IPng. I am very far behind and should be responding to the 8x8 thread, but this one I had to comment on. Ran is understating the problem! For many reasons here at Chrysler we have had multiple mask levels since day one. Now with OSPF variable masks, we have all masks from bit 23 (512-2 hosts per subnet) to bit 27 (32-2 hosts per subnet). This drove router vendors crazy in the early days with RIP. Many could not support this until we 'showed them how'. Only a few of us in Tech Support and TCOM can banter about with masks, most of the support people handle it by rote and have given up understanding anymore than, say a mask of 255.255.255.196 is 64-2 hosts per subnet. Fortunately we have a standard for the address of the default router for a subnet! For IPv4, a better human representation would have been the tuple format of (net, subnet, host) so that an address of 129.9.247.247 with a mask of 255.255.255.128 would have been (129.9, 496, 118) with a mask of (255.255, 512, 0). I can more easily explain tuples to people than the current notation! Also this format makes it clearer about the RFC 1122 limitation that subnet and host cannot have values of 0 or -1! We would have avoided that disaster last year! Bob Moskowitz Chrysler Corp From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 00:12:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05199; Wed, 8 Jun 1994 23:41: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 XAA18270; Wed, 8 Jun 1994 23:41:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA18256; Wed, 8 Jun 1994 23:26:50 +1000 Precedence: list Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04839; Wed, 8 Jun 1994 23:26:45 +1000 (from dee@skidrow.lkg.dec.com) Received: from skidrow.lkg.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA26201; Wed, 8 Jun 94 06:20:19 -0700 Received: by skidrow.lkg.dec.com (5.65/MS-081993); id AA10312; Wed, 8 Jun 1994 09:22:23 -0400 Message-Id: <9406081322.AA10312@skidrow.lkg.dec.com> To: "Robert G. Moskowitz" <0003858921@mcimail.com> Cc: big Internet Subject: Re: dotted notation considered awkward In-Reply-To: Your message of "Wed, 08 Jun 94 06:06:00 EST." <03940608110630/0003858921NA3EM@mcimail.com> Date: Wed, 08 Jun 94 09:22:22 -0400 From: "Donald E. Eastlake 3rd (Beast)" X-Mts: smtp Human beings almost never need to see the inverse address tree. There is no particular reason, if you want arbirary bit boundaries, to not simply go to a 1.0.1.0.0.1.1.1...in-whatever.mumble type notation where you just write the thingie in reversed binary. Donald From: "Robert G. Moskowitz" <0003858921@mcimail.com> Precedence: list To: atkinson To: big Internet >Ran said: > >> The dotted notation for IPv4 addresses makes it harder for mere >>mortals to subnet along arbitrary bit boundaries (and have better >>address space utilisation) than to subnet along 8-bit boundaries (and >>have low address space utilisation). This is a human-factors issue, >>not strictly a bit-twiddling issue. > >> Perhaps IPng should use a different human-readable notation that >>would tend to encourage variable-length subnetting and higher address >>density. Hexadecimal would at least make nibble (4-bit) alignment >>much easier to read. There are probably better ideas out there. > >> We should consider these human factors issues as we ponder selection >>and deployment of IPng. > >I am very far behind and should be responding to the 8x8 thread, but this >one I had to comment on. > >Ran is understating the problem! > >... > >Bob Moskowitz >Chrysler Corp From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 00:34:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07177; Thu, 9 Jun 1994 00: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 AAA18321; Thu, 9 Jun 1994 00:21:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA18318; Thu, 9 Jun 1994 00:12:21 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05153; Wed, 8 Jun 1994 23:37:48 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 8 Jun 1994 09:37:43 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 8 Jun 1994 09:37:43 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA22359; Wed, 8 Jun 94 09:36:04 EDT Date: Wed, 8 Jun 94 09:36:04 EDT Message-Id: <9406081336.AA22359@mailserv-D.ftp.com> To: kre@munnari.OZ.AU Subject: Re: 8+8 addressing..... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 825 > well, i'd like to be able to take a packet, pull the > source locator out of it, > > I have this half baked idea floating around in my head that > source locators are a waste of time, and shouln't be in random > packets in any case (they would appear in request type icmp's, > and in some form of orderly route finding packets, etc, but > that's about all). If a packet did not include the source locator (or equivalent mechanism) then to where would a router send an ICMPng error message (eg TTL expired)? Eliminating the source information would be detrimental to network robustness. > This stuff is too trivial to bother with - its obviously > needed, but is just as obviously easy to devise. Agreed -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 01:57:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09427; Thu, 9 Jun 1994 01:21: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 BAA18411; Thu, 9 Jun 1994 01:21:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA18408; Thu, 9 Jun 1994 01:17:58 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09197; Thu, 9 Jun 1994 01:17:50 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA04283; Wed, 8 Jun 94 08:10:35 -0700 Received: by xirtlu.zk3.dec.com; id AA09072; Wed, 8 Jun 1994 11:10:19 -0400 Message-Id: <9406081510.AA09072@xirtlu.zk3.dec.com> To: Erik.Nordmark@eng.sun.com (Erik Nordmark) Cc: big-internet@munnari.OZ.AU Subject: Re: lower 8 bits of 8+8 format In-Reply-To: Your message of "Tue, 07 Jun 94 17:38:43 PDT." <9406080038.AA11791@jurassic.Eng.Sun.COM> Date: Wed, 08 Jun 94 11:10:13 -0400 X-Mts: smtp [I have take this to Big-I list not to SIPP list too} >If the EID is used for TCP connection identification (as you state) >then collisions between two hosts will cause problems if these two hosts >communicate with a third host at the same time. The third host's TCP would not be >able to distiguish between the two connections (assuming the port numbers are the same). I can't parse your concern here? If the EIDs are globally unique and contain their own locator information I can't see the collision between any hosts unless for some reason there is a duplicate EID used. So the problem is one of defining the assignment plan of globally unique EIDs, not a technical problem for connection if the EIDs are globally unique? >The above case, which will be common if there are >some very popular information service providers out there, will be difficult to >diagnose and rectify since it will be transient in nature and it has global >scope. If someone does not follow the rules and adds their own IPv4 address to the network today its a problem too. Do you perceive a different problem because of EIDs. Both problems require analysis. We can't avoid that fact. thanks /jim From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 01:59:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07219; Thu, 9 Jun 1994 00:23: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 AAA18336; Thu, 9 Jun 1994 00:22:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA18315; Thu, 9 Jun 1994 00:10:30 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05155; Wed, 8 Jun 1994 23:37:48 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 8 Jun 1994 09:37:42 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 8 Jun 1994 09:37:42 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA22352; Wed, 8 Jun 94 09:36:00 EDT Date: Wed, 8 Jun 94 09:36:00 EDT Message-Id: <9406081336.AA22352@mailserv-D.ftp.com> To: mohta@necom830.cc.titech.ac.jp Subject: Re: Locator Sizes From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 1578 > > Average Aggregation > > Efficiency Level Count > > 1:10 12 > > 1:20 9+ > > 1:50 7+ > > 1:100 6 > > 1:1000 4 > > > > I do not think that 1:10 is useful. I do not think that we will see 1:1000 > > aggregation. I'd bet that the maximum level of aggregation we will > > see, _on_average_ over the network, will be between 1:50 and 1:100. > > Why? Even RIP can handle 1:1000. Considering the today's operation of > BGP, aggregation of 1:10,000 or even 1:100,000 is not so unrealistic, I > think. That is, routers can maitain 100,000 routing entries. This is not a function so much of the routing protocols as it is a function of the structure of the network. For example, suppose that FTP Software receives a locator prefix from its service provider (e.g. 99.98.97). Only networks (and their locators) that are within FTP Software could be aggregated into FTP's locator prefix. So, if FTP has three internal networks, one for sales, one for marketing, and one for engineering, then only those three networks (and their locators) would be aggregated into FTP's 99.98.97 prefix. If those three FTP-internal networks are assigned 'local' locators 1, 2, and 3 (for sales, marketing, and engineering, respectively) then locators 99.98.97.1, 99.98.97.2, and 99.98.97.3, and only those locators, would be aggregated into 99.98.97. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 02:15:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10636; Thu, 9 Jun 1994 02:01: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 CAA18477; Thu, 9 Jun 1994 02:01:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA18465; Thu, 9 Jun 1994 01:58:15 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10291; Thu, 9 Jun 1994 01:54:40 +1000 (from kre@munnari.OZ.AU) To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... In-Reply-To: Your message of "Wed, 08 Jun 1994 09:36:04 EDT." <9406081336.AA22359@mailserv-D.ftp.com> Date: Thu, 09 Jun 1994 01:54:36 +1000 Message-Id: <22152.771090876@munnari.OZ.AU> From: Robert Elz Date: Wed, 8 Jun 94 09:36:04 EDT From: kasten@ftp.com (Frank Kastenholz) Message-ID: <9406081336.AA22359@mailserv-D.ftp.com> If a packet did not include the source locator (or equivalent mechanism) then to where would a router send an ICMPng error message (eg TTL expired)? Those things wouldn't be sent at all. Eliminating the source information would be detrimental to network robustness. My general impression is that icmp error messages are more harmful to network robustness than the problems they are diagnosing in most cases. kre From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 02:15:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10676; Thu, 9 Jun 1994 02:03: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 CAA18492; Thu, 9 Jun 1994 02:03:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA18468; Thu, 9 Jun 1994 01:59:39 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08193; Thu, 9 Jun 1994 00:47:38 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 8 Jun 94 23:41:21 +0900 From: Masataka Ohta Message-Id: <9406081441.AA22205@necom830.cc.titech.ac.jp> Subject: Re: Locator Sizes To: kasten@ftp.com Date: Wed, 8 Jun 94 23:41:19 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9406081336.AA22352@mailserv-D.ftp.com>; from "Frank Kastenholz" at Jun 8, 94 9:36 am X-Mailer: ELM [version 2.3 PL11] > > Why? Even RIP can handle 1:1000. Considering the today's operation of > > BGP, aggregation of 1:10,000 or even 1:100,000 is not so unrealistic, I > > think. That is, routers can maitain 100,000 routing entries. > > This is not a function so much of the routing protocols as it is a function > of the structure of the network. > > For example, suppose that FTP Software receives a locator prefix from > its service provider (e.g. 99.98.97). Only networks (and their > locators) that are within FTP Software could be aggregated into FTP's > locator prefix. So, if FTP has three internal networks, one for > sales, one for marketing, and one for engineering, then only those > three networks (and their locators) would be aggregated into FTP's > 99.98.97 prefix. If those three FTP-internal networks are assigned > 'local' locators 1, 2, and 3 (for sales, marketing, and engineering, > respectively) then locators 99.98.97.1, 99.98.97.2, and 99.98.97.3, > and only those locators, would be aggregated into 99.98.97. You are considering very strict source routing. The service provider, having right to assign locators 12345.6000~12345.6999, can give FTP software three locators: 12345.6789 12345.6790 12345.6791 Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 02:15:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10700; Thu, 9 Jun 1994 02:05: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 CAA18507; Thu, 9 Jun 1994 02:05:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA18471; Thu, 9 Jun 1994 02:00:07 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08278; Thu, 9 Jun 1994 00:50:40 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 8 Jun 1994 10:50:36 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 8 Jun 1994 10:50:36 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA23865; Wed, 8 Jun 94 10:48:57 EDT Date: Wed, 8 Jun 94 10:48:57 EDT Message-Id: <9406081448.AA23865@mailserv-D.ftp.com> To: mohta@necom830.cc.titech.ac.jp Subject: Re: Locator Sizes From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 1634 > > > Why? Even RIP can handle 1:1000. Considering the today's operation of > > > BGP, aggregation of 1:10,000 or even 1:100,000 is not so unrealistic, I > > > think. That is, routers can maitain 100,000 routing entries. > > > > This is not a function so much of the routing protocols as it is a function > > of the structure of the network. > > > > For example, suppose that FTP Software receives a locator prefix from > > its service provider (e.g. 99.98.97). Only networks (and their > > locators) that are within FTP Software could be aggregated into FTP's > > locator prefix. So, if FTP has three internal networks, one for > > sales, one for marketing, and one for engineering, then only those > > three networks (and their locators) would be aggregated into FTP's > > 99.98.97 prefix. If those three FTP-internal networks are assigned > > 'local' locators 1, 2, and 3 (for sales, marketing, and engineering, > > respectively) then locators 99.98.97.1, 99.98.97.2, and 99.98.97.3, > > and only those locators, would be aggregated into 99.98.97. > > You are considering very strict source routing. I am considering 'very strict hierarchical addressing' :-) > > The service provider, having right to assign locators 12345.6000~12345.6999, > can give FTP software three locators: > > 12345.6789 > 12345.6790 > 12345.6791 True, but then if FTP software decides that it needs another subnet, it has to get another locator from its provider, yes? This would be unacceptable. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 02:15:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10840; Thu, 9 Jun 1994 02:07: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 CAA18522; Thu, 9 Jun 1994 02:06:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA18474; Thu, 9 Jun 1994 02:00:20 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10477; Thu, 9 Jun 1994 01:56:05 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA02026; Wed, 8 Jun 94 08:58:02 -0700 Date: Wed, 8 Jun 94 08:58:02 -0700 From: Eric Fleischman Message-Id: <9406081558.AA02026@atc.boeing.com> To: big-internet@munnari.OZ.AU, mo@uunet.uu.net, sipp@sunroof.Eng.Sun.COM Subject: Re: companies needing lots of internal routing...... Dear Mike, I fully agree with your statement that >the way the address space gets administered at local sites is FAR more >important than the global bit whittling. In fact, I'm really fond of >doing MINIMAL global address whittling, thereby leaving the >most room for designating "local neighborhoods". However, your subsequent paragraph does not allow enough space for end systems to be autoaddressed by a serverless scheme which uses the MAC addresses. Thus, your approach necessitates that autoaddressing be solely done via servers -- if at all. This is a constraint I would prefer not to see imposed. >In my 8+8 outline, >assuming a 4+4 split of the "network context", given the upper 4 >designate the "large organization", they still have 4 bytes of >networks. even if they flat address it, they get 4 BILLION networks. >One would assume they will apply a modicum of CIDRization and presto, >you get cables, floors, buildings, and campuses with no problem. >anyone who can't make this work is REALLY off in the weeds. >in fact, this is really squanderous, but slop seems to make people >feel safe, so here it is. My naive impression of your 8+8 approach is that it substantiates Paul Francis' argument against variable length addressing: it expands to fill all of the maximum available space. In the 8+8 case, you use the upper 8 bytes to ensure that the Internet Service Providers have more than enough space to handle all of their future needs -- thereby forcing end users such as us to be needlessly constrained. I call "foul". Any viable addressing scheme must either satisfy the entire community or else fairly and equally constrain the whole community. By this definition your 8+8 is not viable. Sincerely yours, --Eric Fleischman BTW: Let's begin to define our terms. A "large organization" to me has several hundred thousand networked devices. I realize that some may call this a small network, but that merely shows that the terms "large", "small", etc. have meanings which vary upon where we are standing. For the purposes of addressing, please consider that large user may need to be able to expand their networked devices to a million addressed devices over the next decade or so. Such a consideration would "bound" our discussion and perhaps ensure that the results will scale to meet real end users needs in 2010. From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 04:01:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14770; Thu, 9 Jun 1994 04: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 EAA18738; Thu, 9 Jun 1994 04:01:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA18724; Thu, 9 Jun 1994 03:52:14 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14375; Thu, 9 Jun 1994 03:52:10 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-11.dialip.mich.net (pm002-11.dialip.mich.net [35.1.48.92]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA19818 for ; Wed, 8 Jun 1994 13:52:05 -0400 Date: Wed, 8 Jun 94 17:09:05 GMT From: "William Allen Simpson" Message-Id: <2576.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: packets without locators > From: kasten@ftp.com (Frank Kastenholz) > > well, i'd like to be able to take a packet, pull the > > source locator out of it, > > > > I have this half baked idea floating around in my head that > > source locators are a waste of time, and shouln't be in random > > packets in any case (they would appear in request type icmp's, > > and in some form of orderly route finding packets, etc, but > > that's about all). > > If a packet did not include the source locator (or equivalent > mechanism) then to where would a router send an ICMPng error message > (eg TTL expired)? Eliminating the source information would be > detrimental to network robustness. > I disagree. I would propose the same solution I suggested a couple of years back, when we had this same discussion with Noel. Regular traffic needs to be fast path. ICMP, DNS, and such traffic can be slow path. Assume we have administrative ownership information in the EID (this was my argument with Noel at the time, who wanted no structure at all). So, in the case of a packet with only an EID and no locators, the ICMP message would go back to the site based on the "ownership" of the EID. The owner DNS database has the locator information. The owner DNS-based "slow path" server then forwards the ICMP message to the true destination. The same function is needed to bootstrap the EID -> locator in the first place. If you know the EID, but don't know the locators, the DNS query goes to the owner. The owner forwards to the correct DNS server, which responds to the query. (They are probably in the same box, anyway.) The same function could be used for resource location servers. This is one of the reasons I agree with Frank that there needs to be ownership (rather than manufacturer) information in the EID. I also agree with the others recently posted, especially "... if the manufacturer goes out of business". Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 04:41:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16175; Thu, 9 Jun 1994 04:41: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 EAA18798; Thu, 9 Jun 1994 04:41:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA18784; Thu, 9 Jun 1994 04:26:12 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15527; Thu, 9 Jun 1994 04:26:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14105; Wed, 8 Jun 94 14:26:03 -0400 Date: Wed, 8 Jun 94 14:26:03 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406081826.AA14105@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: dotted notation considered awkward Cc: jnc@ginger.lcs.mit.edu From: "Robert G. Moskowitz" <0003858921@mcimail.com> I am very far behind and should be responding to the 8x8 thread, but this one I had to comment on. Likewise! :-) For IPv4, a better human representation would have been the tuple format of (net, subnet, host) so that an address of 129.9.247.247 with a mask of 255.255.255.128 would have been (129.9, 496, 118) with a mask of (255.255, 512, 0). I agree, it would have been a better notation. The only problem is that the dotted decimal version *preceded* the adoption of subnets, and was widespread by that time. MIT, the first place to use subnets in the modern style, used an comma'd octal notation (PDP-11 influence :-), which made it a little easier to decipher, but this never caught on. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 05:01:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16687; Thu, 9 Jun 1994 05:01: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 FAA18833; Thu, 9 Jun 1994 05:01:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA18814; Thu, 9 Jun 1994 04:48:11 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16325; Thu, 9 Jun 1994 04:48:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14324; Wed, 8 Jun 94 14:48:04 -0400 Date: Wed, 8 Jun 94 14:48:04 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406081848.AA14324@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: lower 8 bits of 8+8 format Cc: jnc@ginger.lcs.mit.edu From: bound@zk3.dec.com If the EIDs ... contain their own locator information TILT! Repeat to yourself 100 times (I won't try and get you to write it on the blackboard :-) the phrase "EID's contain no topological information". :-) Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 06:03:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16815; Thu, 9 Jun 1994 05:02: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 FAA18850; Thu, 9 Jun 1994 05:02:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA18830; Thu, 9 Jun 1994 05:00:20 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16668; Thu, 9 Jun 1994 05:00:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14481; Wed, 8 Jun 94 15:00:13 -0400 Date: Wed, 8 Jun 94 15:00:13 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406081900.AA14481@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... Cc: jnc@ginger.lcs.mit.edu From: RACarlson@anl.gov (Richard Carlson) Never having seen an offical definition of EID's, references please I'm being bad. I have an I-D 50+% done, just never finished it. Someone else should feel free to write one. If they don't provide any routing information, and I don't think they should, then why are they taking up space in the network layer address. I would like to propose that EID's be used assigned to the TCP layer of a node. I agree, they should not be part of the locator, and maybe should not even appear in all packets. The reason I think they belong at the internetwork layer (perhaps conceptually as a sublayer on top) is so that multiple different client transport protocols don't have to go out and reinvent the same wheel. Unlike ports, where you could make a reasonable case that different protocols might want to use different lengths, etc, I think that a single naming space for endpoints (approximately hosts, but let's skip the definition for now) is the way to go; there's even the possibility that different transport protocols might want to have a single name for a given entity. EID's would be globaly unique, contain now routing information, and are passed between communicating nodes. Yes. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 06:21:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19546; Thu, 9 Jun 1994 06:21: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 GAA18934; Thu, 9 Jun 1994 06:21:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA18920; Thu, 9 Jun 1994 06:06:23 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18975; Thu, 9 Jun 1994 06:06:15 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA20940; Wed, 8 Jun 94 12:58:09 -0700 Received: by xirtlu.zk3.dec.com; id AA16899; Wed, 8 Jun 1994 15:57:57 -0400 Message-Id: <9406081957.AA16899@xirtlu.zk3.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: lower 8 bits of 8+8 format In-Reply-To: Your message of "Wed, 08 Jun 94 14:48:04 EDT." <9406081848.AA14324@ginger.lcs.mit.edu> Date: Wed, 08 Jun 94 15:57:51 -0400 X-Mts: smtp > From: bound@zk3.dec.com > If the EIDs ... contain their own locator information >TILT! Repeat to yourself 100 times (I won't try and get you to write it on the >blackboard :-) the phrase "EID's contain no topological information". :-) Hmmmmmmmmmmm slip of the key pad Wherever you retrieve an EID you should have the option of obtaining the locators for that EID if you need them. Yes they should be on the same linked list in some order and I might add this should be a doubly linked list, so I can traverse either direction. /jim From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 06:23:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19607; Thu, 9 Jun 1994 06:23: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 GAA18949; Thu, 9 Jun 1994 06:23:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA18917; Thu, 9 Jun 1994 06:04:11 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17145; Thu, 9 Jun 1994 05:14:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14642; Wed, 8 Jun 94 15:14:29 -0400 Date: Wed, 8 Jun 94 15:14:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406081914.AA14642@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: lower 8 bits of 8+8 format Cc: jnc@ginger.lcs.mit.edu From: Erik.Nordmark@eng.sun.com (Erik Nordmark) >> there is significant chance of duplicates among 2^32 EIDs quasi-randomly >> assigned in a 64 bit space. > True, but if they are only used for identification purposes, this would > only be a problem if you have a collision on two hosts which wish to > communicate. ... collisions between two hosts will cause problems if these two hosts communicate with a third host at the same time. The third host's TCP would not be able to distiguish between the two connections (assuming the port numbers are the same) ... will be difficult to diagnose and rectify since it will be transient in nature and it has global scope. Ouch. Good thing you're awake; I totally missed that one. :-) Hmm, so duplicate EID's are a potential problem, in the rare case where the foreign/destination port pair (remember TCP looks at them both, which is how it distinguished multiple connections to a service from the same client) is the same. Is this case going to happen enough that we need to figure out how to detect it, and do something about it? I can't offhand think of a way of distinguishing that two identical EID's refer to different things (other than directly asking "hey, do you also have a TCP connection such-and-so to me"); they could legitimately have different locators (if the host is dual-interfaced) or even different DNS names. Of course, right now, if two hosts have the same address, we've got the same problem, albeit over a more restricted scope, and it's more likely to break something (in a bizarre way). Let's see, what would happen if this happened? When the second SYN arrived, you should note that it's coming from a different locator, and complain since you didn't get an "I am moving" ICMP message. Also, if the initial sequence numbers are picked randomly, they way they're supposed to, the second SYN should provoke a RST. This is in TCP of course, but similar things ought to happen in other transports. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 06:42:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20387; Thu, 9 Jun 1994 06:41: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 GAA18994; Thu, 9 Jun 1994 06:41:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA18976; Thu, 9 Jun 1994 06:39:07 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20208; Thu, 9 Jun 1994 06:39:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15418; Wed, 8 Jun 94 16:38:56 -0400 Date: Wed, 8 Jun 94 16:38:56 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406082038.AA15418@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Locator Sizes Cc: jnc@ginger.lcs.mit.edu From: kasten@ftp.com (Frank Kastenholz) > The service provider, having right to assign locators > 12345.6000~12345.6999, can give FTP software three locators: > 12345.6789 > 12345.6790 > 12345.6791 True, but then if FTP software decides that it needs another subnet, it has to get another locator from its provider, yes? This would be unacceptable. What's even worse is that unless the FTP locators are assigned along a CIDR-izable boundary, routing inside the provider has to track each of them separately, the old ones *and* the new one(s). (I suppose we could do ranges, the way Appletalk does it, though...) Repeat 100 times "the chief job of locators is to be assigned in such a way that they minimize the routing overhead"! :-) Actually, that's why I like very flexible locator syntax (as opposed to the "fixed-length-and-mask" approach); it makes it really easy to draw a line around some piece of topology and label it as a single entity (without necessarily giving a lot of attention to, or disturbing, what has already been done elsewhere). This process of drawing lines around groups of stuff, and giving the result a single name, is the key step, of course, in controlling the routing overhead. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 10:23:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24845; Thu, 9 Jun 1994 09:03: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 JAA19120; Thu, 9 Jun 1994 09:01:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA19106; Thu, 9 Jun 1994 08:44:36 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21862; Thu, 9 Jun 1994 07:47:58 +1000 (from Erik.Nordmark@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA05575; Wed, 8 Jun 94 14:43:37 PDT Received: from jurassic.Eng.Sun.COM (jurassic-52) by Eng.Sun.COM (4.1/SMI-4.1) id AA27540; Wed, 8 Jun 94 14:46:02 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA11739; Wed, 8 Jun 1994 14:43:31 -0700 Date: Wed, 8 Jun 1994 14:43:31 -0700 From: Erik.Nordmark@Eng.Sun.COM (Erik Nordmark) Message-Id: <9406082143.AA11739@jurassic.Eng.Sun.COM> To: bound@zk3.dec.com Subject: Re: lower 8 bits of 8+8 format Cc: big-internet@munnari.OZ.AU Mime-Version: 1.0 > >If the EID is used for TCP connection identification (as you state) > >then collisions between two hosts will cause problems if these two hosts > >communicate with a third host at the same time. The third host's TCP would not be > >able to distiguish between the two connections (assuming the port numbers are the same). > > I can't parse your concern here? If the EIDs are globally unique and Stop. The context of the discussion was EID collisions i.e. the EIDs are not guaranteed ti be globally unique. > If someone does not follow the rules and adds their own IPv4 address to > the network today its a problem too. Do you perceive a different > problem because of EIDs. Both problems require analysis. We can't > avoid that fact. If two machine on the same wire pick the same IP address the problem is normally detected as complete failure to communicate. Many arp implementations detect this and log an error message. But the main difference between IPv4 address collisions and EID collisions is that the former is a local problem; it is restricted to a single subnet. Erik From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 12:04:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04536; Thu, 9 Jun 1994 12:04: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 MAA19302; Thu, 9 Jun 1994 12:03:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA19269; Thu, 9 Jun 1994 11:48:37 +1000 Precedence: list Received: from achilles.ctd.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01050; Thu, 9 Jun 1994 10:53:32 +1000 (from b30118@achilles.ctd.anl.gov) Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA08313; Wed, 8 Jun 94 19:53:27 CDT Date: Wed, 8 Jun 94 19:53:27 CDT Message-Id: <9406090053.AA08313@achilles.ctd.anl.gov> To: bound@zk3.dec.com Subject: New TCP (was Re: 8+8 addressing..... Cc: big-internet@munnari.OZ.AU From: "Richard Carlson" In-Reply-To: Your message of "Tue, 7 Jun 1994 22:47:10 -0400" <9406072302.AA26359@achilles.ctd.anl.gov> >If they are passed between communicating nodes how? The vision I have is that EID's should be part of the TCP header. (I realize that this is a big change, but bear with me for a minute.) The purpose of the EID is to provide a globally unique address to an Internet node. This address provides no routing information, just end node identification. However, the 2 communicating nodes will need to use the EID's to identify each other. This means that the EID's must be sent over the underlying network. So how can we send information over the network without using the network address? Simple, by using the network data field instead of the header field. This means that the TCP header must be used to carry the EID (or my term is Transport Address (TA)). I believe that the TCP header must be modified to handle high bandwidth-delay networks. An IPng network will also require TCP header changes. If this is correct, then adding Src & Dest TA fields isn't that far fetched. Socket communications would then use a Src/dest TA.port notation instead of the current IP.port one. Users would never see the EID, but would use DNS names. As I said, a big change from the current structure. >What about the mobile case? I view mobility as a network layer problem with the associated locating and routing problems. This is not a task EID's should handle. The existance of an EID would just indicate that a destination exists somewhere on the Internet. The source would build a packet and pass this down to the network layer for delivery. I can easily see a node supporting multiple network layers, IPv4 and IPng for instance. You can even route TCP packets between different network layers. This would allow the IPv4 to IPng transition period to progress smoothly without the IPng protocol having to worry about supporting the IPv4 addresses. >But I like where your headed. Thanks, I hope this is still true .-) From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 15:57:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04455; Thu, 9 Jun 1994 12:01: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 MAA19286; Thu, 9 Jun 1994 12:01:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA19272; Thu, 9 Jun 1994 11:49:05 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02457; Thu, 9 Jun 1994 11:18:49 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 9 Jun 94 10:11:27 +0900 From: Masataka Ohta Message-Id: <9406090111.AA24151@necom830.cc.titech.ac.jp> Subject: Re: Locator Sizes To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 9 Jun 94 10:11:25 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406082038.AA15418@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 8, 94 4:38 pm X-Mailer: ELM [version 2.3 PL11] > > The service provider, having right to assign locators > > 12345.6000~12345.6999, can give FTP software three locators: > > 12345.6789 > > 12345.6790 > > 12345.6791 > > True, but then if FTP software decides that it needs another subnet, Subnet? Network. > it has to get another locator from its provider, yes? Yes, if the forth network also needs its own locator. Actually, in SIPP case, the upper 4 bytes of EID can also acts as a local locator. No, I'm not confusing the COCEPTUAL difference between a locator and EID. But there is no reason to restrict IMPLEMENATION not to share some information between a locator and EID. > This would be unacceptable. Why? > What's even worse is that unless the FTP locators are assigned along a > CIDR-izable boundary, routing inside the provider has to track each of them > separately, the old ones *and* the new one(s). (I suppose we could do ranges, > the way Appletalk does it, though...) CIDRization is done 12345.6791 ^^^^^ HERE! OK? Within a layer, flat routing is done. So, FTP software may have locators: 12345.6791 12345.6872 12345.6503 > Repeat 100 times "the chief job of locators is to be assigned in such a way > that they minimize the routing overhead"! :-) We are talkiing about minimization of routing overhead with 10^9 to 10^12 networks. Flat routing with 10,000 or 100,000 entities, even today, is doable and will be considered to be minimal in the near future. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 16:21:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17148; Thu, 9 Jun 1994 16: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 QAA19546; Thu, 9 Jun 1994 16:21:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA19543; Thu, 9 Jun 1994 16:18:06 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06616; Thu, 9 Jun 1994 12:51:07 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA09735; Wed, 8 Jun 94 19:49:12 -0700 Received: by xirtlu.zk3.dec.com; id AA22515; Wed, 8 Jun 1994 22:48:55 -0400 Message-Id: <9406090248.AA22515@xirtlu.zk3.dec.com> To: Masataka Ohta Cc: big-internet@munnari.OZ.AU Subject: Re: Locator Sizes In-Reply-To: Your message of "Thu, 09 Jun 94 10:11:25 +0200." <9406090111.AA24151@necom830.cc.titech.ac.jp> Date: Wed, 08 Jun 94 22:48:49 -0400 X-Mts: smtp >Yes, if the forth network also needs its own locator. Actually, in SIPP case, >the upper 4 bytes of EID can also acts as a local locator. No, I'm not >confusing the COCEPTUAL difference between a locator and EID. But there >is no reason to restrict IMPLEMENATION not to share some information >between a locator and EID. I agree. I liked Frank's analysis on this in his mail whats an EID. For example suppose I want to provide a cluster for my customer. The EID of the cluster (identifying that thing) does not have to be the same as the EID of each cluster member. /jim From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 16:29:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06198; Thu, 9 Jun 1994 12: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 MAA19359; Thu, 9 Jun 1994 12:41:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA19345; Thu, 9 Jun 1994 12:37:46 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05983; Thu, 9 Jun 1994 12:37:42 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA08600; Wed, 8 Jun 94 19:28:58 -0700 Received: by xirtlu.zk3.dec.com; id AA22384; Wed, 8 Jun 1994 22:28:47 -0400 Message-Id: <9406090228.AA22384@xirtlu.zk3.dec.com> To: Erik.Nordmark@eng.sun.com (Erik Nordmark) Cc: big-internet@munnari.OZ.AU Subject: Re: lower 8 bits of 8+8 format In-Reply-To: Your message of "Wed, 08 Jun 94 14:43:31 PDT." <9406082143.AA11739@jurassic.Eng.Sun.COM> Date: Wed, 08 Jun 94 22:28:41 -0400 X-Mts: smtp >Stop. The context of the discussion was EID collisions i.e. the EIDs >are not guaranteed ti be globally unique. Re-Boot. I believe we had consensus that EIDs must be globally unique. I see no point in the discussion of EIDs unless they are globally unique. I was not 100% sure 2 weeks ago. But I am now. /jim From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 22:02:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19062; Thu, 9 Jun 1994 17:01: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 RAA19601; Thu, 9 Jun 1994 17:01:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA19587; Thu, 9 Jun 1994 16:51:46 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06355; Thu, 9 Jun 1994 12:46:12 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA09398; Wed, 8 Jun 94 19:43:14 -0700 Received: by xirtlu.zk3.dec.com; id AA22474; Wed, 8 Jun 1994 22:43:01 -0400 Message-Id: <9406090243.AA22474@xirtlu.zk3.dec.com> To: "Richard Carlson" Cc: big-internet@munnari.OZ.AU Subject: Re: New TCP (was Re: 8+8 addressing..... In-Reply-To: Your message of "Wed, 08 Jun 94 19:53:27 CDT." <9406090053.AA08313@achilles.ctd.anl.gov> Date: Wed, 08 Jun 94 22:42:55 -0400 X-Mts: smtp Richard, =>If they are passed between communicating nodes how? >The vision I have is that EID's should be part of the TCP header. (I realize >that this is a big change, but bear with me for a minute.) The purpose >of the EID is to provide a globally unique address to an Internet node. This >address provides no routing information, just end node identification. >However, the 2 communicating nodes will need to use the EID's to identify >each other. This means that the EID's must be sent over the underlying >network. So how can we send information over the network without using the >network address? >Simple, by using the network data field instead of the header field. This >means that the TCP header must be used to carry the EID (or my term is >Transport Address (TA)). I believe that the TCP header must be modified to >handle high bandwidth-delay networks. An IPng network will also require >TCP header changes. If this is correct, then adding Src & Dest TA fields >isn't that far fetched. Socket communications would then use a Src/dest >TA.port notation instead of the current IP.port one. Users would never see >the EID, but would use DNS names. As I said, a big change from the >current structure. I like your vision. It gets to the heart of what part of EIDs I like most and what made me jump on this word invented by Noel. I also like the idea of your term TA if we are going to get into a urinary contest over the name and copyrights or I could say write on the blackboard 100 times do not have urinary contest in the wind. I still like where your headed. >What about the mobile case? >I view mobility as a network layer problem with the associated locating and >routing problems. This is not a task EID's should handle. The existance of >an EID would just indicate that a destination exists somewhere on the Internet. >The source would build a packet and pass this down to the network layer for >delivery. I can easily see a node supporting multiple network layers, IPv4 >and IPng for instance. You can even route TCP packets between different >network layers. This would allow the IPv4 to IPng transition period to >progress smoothly without the IPng protocol having to worry about supporting >the IPv4 addresses. I agree again. In fact I really am pleased with the way you stated that "....you can even route TCP packets between different network layers" which is what we need to do and your statement is more precise than other ways I have seen this defined with much hand waving. =>But I like where your headed. >Thanks, I hope this is still true .-) Yep. thank you, /jim From owner-Big-Internet@munnari.OZ.AU Thu Jun 9 23:01:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01451; Thu, 9 Jun 1994 23:01: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 XAA19910; Thu, 9 Jun 1994 23:01:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA19893; Thu, 9 Jun 1994 22:52:48 +1000 Precedence: list Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17444; Thu, 9 Jun 1994 16:29:17 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA19288 (5.65c/IDA-1.4.4nsd for ); Wed, 8 Jun 1994 23:29:01 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA05955 (5.65c/IDA-1.4.4-910725 for ); Wed, 8 Jun 1994 23:28:58 -0700 Message-Id: <199406090628.AA05955@remmel.NSD.3Com.COM> To: big-internet@munnari.OZ.AU Subject: Re: Locator Sizes In-Reply-To: Your message of "Thu, 09 Jun 94 10:11:25 +0200." <9406090111.AA24151@necom830.cc.titech.ac.jp> Date: Wed, 08 Jun 94 23:28:57 -0700 From: tracym@NSD.3Com.COM > Flat routing with 10,000 or 100,000 entities, even today, is doable > and will be considered to be minimal in the near future. I'd hop that folks would stop minimizing the costs/effort of near-term flat routing for large numbers of entities. It is not "minimal" today, and is unlikely to be minimal in 3 years. The price of memory, while steadily declining, is not yet free (nor is bandwidth, though we keep hoping it will happen any day...) If low-end routers need to support such address spaces, they are unlikely to become quite as inexpensive as folks would like. One recent message pointed out that larger routers will have to support a number of such address spaces(3-5), so memory will have to get even cheaper before "minimal" becomes operative." Tracy From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 00:33:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01550; Thu, 9 Jun 1994 23:05: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 XAA19925; Thu, 9 Jun 1994 23:05:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA19896; Thu, 9 Jun 1994 22:52:51 +1000 Precedence: list Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26349; Thu, 9 Jun 1994 20:22:51 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (5.61/1.34) id AA12449; Thu, 9 Jun 94 05:22:29 -0500 Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA10030; Thu, 9 Jun 94 05:22:38 CDT Date: Thu, 9 Jun 94 05:22:38 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9406091022.AA10030@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: New TCP (was Re: 8+8 addressing..... Cool. Y'all have invented the TSAP again! It's a worthy concept, to be sure, but it doesn't have a lot to do with EIDs and how big they ought to be. Really, this whole thread and its spawn is haring rapidly down the classic IP path toward a muddle-headed and vague notion of 'address'. The difference now seems to be that instead of one murky 'address' of 32 bits, we now have several murky objects like 'addresses', all of which seem to be enormous. I think we've arrived at the following: - EIDs, the quasi-randomly assigned network layer entities w/o topology information need to be globally administered, and bigger than MAC addresses. Possibly quite a lot bigger, so MAC addresses can be embedded in the EID space conveniently, and without using much of it. They may be structured, but for administrative convenience and unforseen database lookups rather than for an intended computer parsability. - Locators, the things that tell you where the thing identified by and EID (and a structured name) is right now, need to be something else, and probably pretty big. - Ditto routing information, the thing that says how to get to the thing identified by the EID, if different from locators. - A TSAP that's a bit like an EID is useful. Perhaps, the network layer EID could be recycled as the TSAP. Perhaps not, however. - There are some persistance issues. How long does an EID live? (just as long as the endpoint in question belongs to the same 'organisation', probably?) How long does a TSAP live? (I haven't the foggiest, but if it's different from the lifetime of an EID, TSAPs can't be EIDs). Locators are quite volatile, to serve the needs to mobility. It's all very well to say 'Hey, let's not having a pissing contest over little details like what words mean,' but it sure doesn't improve communication when we all have different ideas about terminology. Make up a new word if you think you mean something new. Andrew From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 01:21:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05934; Fri, 10 Jun 1994 01: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 BAA20149; Fri, 10 Jun 1994 01:21:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA20142; Fri, 10 Jun 1994 01:17:09 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05846; Fri, 10 Jun 1994 01:16:55 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA11613; Thu, 9 Jun 1994 17:16:42 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA23145; Thu, 9 Jun 1994 17:16:41 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406091516.AA23145@dxcoms.cern.ch> Subject: The provider/subscriber boundary To: big-internet@munnari.OZ.AU (bigi) Date: Thu, 9 Jun 1994 17:16:41 +0200 (MET DST) Cc: =bigi@dxcoms.cern.ch Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 5954 On the boundary between the provider prefix and the local address ================================================================= (Or: renumbering is bad for my health) This note defines a number of requirements on any IPng addressing scheme from the viewpoint of the owner/operator of a large campus network with a loose managerial culture. "Large" campus network: 8000 active hosts today, and increasing. Two class B's active and about 30 class C's, increasing. "Loose" managerial culture: many departments buy and run their own hosts. Outside user groups bring their own equipment on site. Managerial edicts cannot be enforced. Equipment database is always out of date. Requirements - 1. Multiple service providers. The campus must be connected to more than one Internet service provider. (In the case of CERN we are connected to four or five, according to how you count.) Routing policies must be implemented with a fine grain (e.g., choice of provider depends on remote subnet number). 2. Independent address allocation. Ignoring the provider "prefix" (whatever it may be), the campus must be able to allocate addresses to its hosts according to an internally determined scheme without reference to the outside world. (We can do that with our Class B's. In effect we can't do it with Class C's and this is a pain.) 3. Topologically meaningful address allocation. With only a few Class B's this is not an issue; one can even use a default router and static routes. However to subnet the network significantly one needs an n-level hierarchy of subnets. Obviously, this topology should be reflected in the locator part of the address. (From the topology of our current network, most of which is bridged rather than routed, we need the backbone plus up to four levels of subnet.) 4. Automatic configuration may be dangerous. In a loosely managed environment, where unknown equipment is always present, it is essential to know the correspondence between hardware address, network name and address, physical location, and person responsible. It is only with all these data that operational problems can be diagnosed efficiently. Network name and address are forced into correspondence by DNS; even the least disciplined user cannot cheat on this. Furthermore the fact that users can only obtain a DNS entry by asking for it ensures that the name of the person initially responsible for a host is known. The correspondence between hardware address and physical location can (with modern hubs) be determined automatically. To complete the chain of knowledge it is essential that the correspondence between hardware address and network address is known at all times (especially when the network is down). Automatic configuration of network addresses is potentially unacceptable for this reason. Needless to say, any auto configuration procedure that ever allows a duplicate address, or that is not reflected instantly by the DNS, is broken in any case. Security is another problem. Any security technique that depends on the network address may be broken by auto configuration. 5. It is acceptable to manually allocate network numbers to new hosts when they arrive; this is a very minor part of creating a database entry and configuring a new system. However, mass re-numbering by humans is OUT. Any scheme which potentially requires human intervention to re-number all hosts because of a trivial event such as changing, adding or removing an Internet service provider is of course unacceptable. (We did it once when we had about 1000 active hosts. We don't plan to do it again.) 6. Prefix changes must be automatic. A consequence of the above is that when the provider prefix(es) change in any way (including change of size), this change must be propagated within the campus both transparently to users and automatically. Ideally of course the prefix(es) would be inserted or removed by the campus border router(s). 7. Prefix changes must not change the campus addressing scheme in any way. (Apart of course from the change to the prefix itself.) Obviously not. Of course not. We are not going to change a complicated topology-based scheme just because the XYZ company has become a cheaper IPng provider than the ZYX company. 8. Apart from IPng it is highly desirable that other network level address schemes in use on the campus can be mapped into a subset of the local IPng address space. This allows (but does not require) a future move towards integrated routing architectures. DISCUSSION All of the above do not require an EID. As long as the name/network address/hardware address correspondence is known at all times, I don't actually care about the EID. If I get only 8 bytes for on-campus addressing I will need 4 of them for the hierarchical locator, leaving only 4 bytes for the host ID. Also, 8 bytes are precisely sufficient to map the useful bits of a DECnet/OSI NSAPA, i.e., 2 bytes for the area number and 6 bytes for the IEEE address. Eight bytes are insufficient for an IPX address (4 bytes network number and 6 bytes IEEE address). Appletalk addresses (2 bytes network number and one byte host number) are the only ones that fit readily inside an 8 bytes campus addressing scheme. My conclusion is that any large (a few thousand nodes) campus, or a fortiori a corporate network, requires more than 8 bytes of local address space under its own control. Nothing about this local address space can change due to any change of the service provider prefix(es) attached to it. It seems to be a logical conclusion from this that either (1) the prefix and the local address are of fixed lengths (e.g. 4+12 bytes) or (2) the address length is variable, but the prefix can be algorithmically distinguished from the local address. ACKNOWLEDGMENT Eric Fleischman helped me to clarify this text. Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 02:11:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04492; Fri, 10 Jun 1994 00:42: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 AAA20031; Fri, 10 Jun 1994 00:41:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA20017; Fri, 10 Jun 1994 00:34:22 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03536; Fri, 10 Jun 1994 00:13:51 +1000 (from kasten@mailserv-D.ftp.com) Received: from wd40.ftp.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01863 Fri, 10 Jun 1994 00:13:46 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Thu, 9 Jun 1994 10:09:43 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 9 Jun 1994 10:09:43 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA09071; Thu, 9 Jun 94 10:08:04 EDT Date: Thu, 9 Jun 94 10:08:04 EDT Message-Id: <9406091408.AA09071@mailserv-D.ftp.com> To: kre@munnari.OZ.AU Subject: Re: 8+8 addressing..... From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 439 kre writes: > My general impression is that icmp error messages are more > harmful to network robustness than the problems they are > diagnosing in most cases. I think that the problem isn't that the error messages harm the network, but rather that they tend to be ignored by the hosts which then persist in their antisocial behavior... -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 02:11:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05104; Fri, 10 Jun 1994 01:02: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 BAA20063; Fri, 10 Jun 1994 01:01:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA20058; Fri, 10 Jun 1994 00:57:10 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29747; Thu, 9 Jun 1994 21:59:37 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA29935; Thu, 9 Jun 94 07:59:13 -0400 Message-Id: <9406091159.AA29935@rodan.UU.NET> To: Eric Fleischman Cc: big-internet@munnari.OZ.AU Subject: Re: companies needing lots of internal routing...... crying foul.. In-Reply-To: Your message of "Wed, 08 Jun 1994 08:58:02 PDT." <9406081558.AA02026@atc.boeing.com> Date: Thu, 09 Jun 1994 07:59:12 -0400 From: "Mike O'Dell" firstly, my proposal is not particularly motivated by "providerhood". I fully appreciate the fact that I may have customers with a one or two orders of magnitude more internal hosts than I have customers. This is why I'm not worried too much about large organizations getting their own network context - they have them now - it works fine. Note that I'm not *forcing* my customers to have network contexts which are "within" mine - there will always be cases where you cannot CIDRize all the routes. As for "not enough bytes for server-free addressing" - I think we're straining at gnats and passing elephants here. Orgnizations that large are going to have routers and/or servers which can do address assignment - they have them now and I think bending over backwards to not need them is more than makes sense, given other constraints. The *REAL* way to do what you want with the MAC address is to use it as an EID. I know people keep whining about how the IEEE MAC address isn't sufficiently perfect, but I keep claiming they aren't gonna get anything materially better. Every other scheme I've seen described here will botch-up some way or another because something will get screwed sometime, somewhere, and believing you can have some weird mathematical perfection in this is just *fantasy*. Yes, there will be occassional collisions, and yes, they will be a bitch to deal with, just like busted cables, marginal 10baseT hubs, and connectors with a thermal problem. I believe all these ills happen with about the same frequency, except the assigment collisions will happen a LOT less frequently, so what the big deal? It's a price of doing business. You might as well get ready because you won't do noticably better. So, that's myh solution for folks who want to run serverless - just use the MAC Address as the EID and you're home free. And if Boeing wants a top-level network-context, tell 'em I sent you over for one. Cheers, -mo PS - lest anyone think otherwise, I think it's great that some of the *large* organizations like Boeing are willing to take the time to participate in this. I know it's enlightened self-interest, but the calibration is very important. From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 02:12:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06686; Fri, 10 Jun 1994 01:44: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 BAA20192; Fri, 10 Jun 1994 01:41:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA20154; Fri, 10 Jun 1994 01:21:50 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05925; Fri, 10 Jun 1994 01:21:33 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HDC2ETSVYO004UT5@FNAL.FNAL.GOV>; Thu, 9 Jun 1994 10:20:43 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA15493; Thu, 9 Jun 94 10:20:37 CDT Date: Thu, 09 Jun 1994 10:20:37 -0500 From: Matt Crawford Subject: EID in 16 byte SIPP address?? To: big-internet@munnari.OZ.AU Message-Id: <9406091520.AA15493@munin.fnal.gov> Content-Transfer-Encoding: 7BIT If the 16 byte SIPP address is to contain an EID, and if that EID is 8 bytes or more, then there will be 8 bytes or fewer for the locator function.[*] Didn't the IPng AD insist that "eight isn't enough" for a locator? In the context of SIPP, isn't the current discussion somewhat contradictory? (Except for the branch that holds that the EID is in the transport layer only.) In the spirit of contradiction, here's a tin-man proposal for EIDs in 16 byte SIPP addresses. (A tin-man is like a straw-man, but not afraid of an open flame. :-) I propose that the last seven (ugh! Yes, seven) bytes be used as an endpoint identifier with administrative but not topological significance. If the first of the seven bytes has the value 0, the other 6 are an IEEE 48-bit address, which need not be the MAC address of any network interface used by the identified endpoint. The small but nonzero risk of both global and local non-uniqueness must be recognized by users of IEEE-based EIDs, and no provisions are made for DNS lookups keyed on an IEEE-based EID. For that reason, routers MUST provide the options of blocking packets containing IEEE-based EIDs in either the source or the destination address fields. If the first of the seven bytes has the value 10 (decimal), the last four bytes are an IPv4 address and some IPAE-like scheme to be determined governs the translation. If the first of the seven bytes has any other value, then the first one, two or three bytes of the seven form an IPv4 *network number* which governs the delegation of authority for DNS lookups keyed on EID. (Of course there may be further delegations in the lowest 32 bits.) If more distinguished code points are needed, 127 and 255 are obvious candidates. I suggest that the upper nine pure-locator bytes be allocated in such a way that the common code path in backbone routers need not examine the ninth byte. This probably means that it would always be under the subscriber's control. _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab (* Well, I suppose an EID carried at the internetwork layer does supplant the byte or so that would identify a host on a given subnet, so you'd have effectively a 9-or-so byte locator with an 8 byte EID.) From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 02:41:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08710; Fri, 10 Jun 1994 02:41: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 CAA20279; Fri, 10 Jun 1994 02:41:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA20252; Fri, 10 Jun 1994 02:24:34 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03584; Fri, 10 Jun 1994 00:15:17 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Thu, 9 Jun 1994 10:09:37 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 9 Jun 1994 10:09:37 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA09065; Thu, 9 Jun 94 10:07:58 EDT Date: Thu, 9 Jun 94 10:07:58 EDT Message-Id: <9406091407.AA09065@mailserv-D.ftp.com> To: bsimpson@MorningStar.Com Subject: Re: packets without locators From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 5298 > > > well, i'd like to be able to take a packet, pull the > > > source locator out of it, > > > > > > I have this half baked idea floating around in my head that > > > source locators are a waste of time, and shouln't be in random > > > packets in any case (they would appear in request type icmp's, > > > and in some form of orderly route finding packets, etc, but > > > that's about all). > > > > If a packet did not include the source locator (or equivalent > > mechanism) then to where would a router send an ICMPng error message > > (eg TTL expired)? Eliminating the source information would be > > detrimental to network robustness. > > > I disagree. I would propose the same solution I suggested a couple of > years back, when we had this same discussion with Noel. Regular traffic > needs to be fast path. ICMP, DNS, and such traffic can be slow path. > > Assume we have administrative ownership information in the EID (this was > my argument with Noel at the time, who wanted no structure at all). > > So, in the case of a packet with only an EID and no locators, the ICMP > message would go back to the site based on the "ownership" of the EID. > The owner DNS database has the locator information. The owner DNS-based > "slow path" server then forwards the ICMP message to the true > destination. This requires that when routers have problems, they must do an EID->Locator lookup in order to send the error report. While this lookup would take place in the 'slow path', it will take some resources (cpu cycles and buffer memory) to do the lookup, which are resources that are not available for the 'fast path' to use. The questions are why and how often will these need to be done? I can see several 'classes' of operations: 1. Management operations (such as PING and SNMP operations). These are idempotent operations. When a request comes in, the request must contain all information needed to get a response back. I'd imagine that as the network gets more and more complext, we will be using more automated management and control tools (i.e. more PINGs, SNMPs, Traceroutes, and things yet to be invented). 2. First Hop Selection. When a node first sends a packet to another node, how is the first-hop selection done? How does that node know whether to send the packet to a router (and which one) or directly to the destination? Will we always send packets to a local router, relying on redirects to get to the proper first hop? This could place quite an additional load on the router -- gets a packet, forwards it back out locally, looks up the source eid to get the source's locator, sends a redirect. 3. Other packet error. This is the classic case which you are no doubt thinking of. This also would imply that routers may have to hold on to a packet for a while before they can process the packet. They have to 'ask a question' ("What is the Locator for Eid FOO?") and they have to wait for the response ("Eid FOO is at Locator BAR"). The router will need to do things like time-out and retransmit these requests (N times, before deciding to dump the packet and forget about it). The router will need to support full DNS resolution - it will have to be able to traverse the DNS tree until it finds a server which can answer its question. Finally, I suspect that there may be some subtle interactions or lockups here. I have to sit and think about it for a while, but it might be possible that there are failure modes involving multiple routers and DNS servers whereby they get into an infinite loop each trying to do a DNS lookup to tell the other about a DNS lookup that it can't do.... Maybe: Dns_Server_A---- ----Router_B----Router_A----- -----Dns_Server_B A has a packet to send an error message for (Destination Unreachable). To do this, it needs to map the packet's Source EID to a locator. A tries to query its DNS server, Dns_Server_A (which is 'behind' Router B). It can't because the link from Router_B to the server is down. B wants to send a Destination Unreachable message to the source of a packet it has (A's DNS request) but to do so it has to get to its DNS Server -- Dns_Server_B (which is behind router A). And the link from Router_A to Dns_Server_B is down. A gets B's DNS request, tries to forward it, and can't so A wants to send a Destination Unreachable message to the source -- but it has to map the packet's Source EID to a Locator. So it sends another DNS request off to its server, through B but which can't make it so B wants to send a dest-un, but has to map the... Basically, each router is trying to get through the 'other' router to its DNS server and can't. > The same function is needed to bootstrap the EID -> locator in the first > place. If you know the EID, but don't know the locators, the DNS query > goes to the owner. The owner forwards to the correct DNS server, which > responds to the query. (They are probably in the same box, anyway.) > > The same function could be used for resource location servers. I'm not arguing against EID-Locator mapping services. I am arguing against requiring routers to do it in handling errors. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 03:47:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07988; Fri, 10 Jun 1994 02:21: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 CAA20236; Fri, 10 Jun 1994 02:21:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA20233; Fri, 10 Jun 1994 02:11:42 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03516; Fri, 10 Jun 1994 00:12:46 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: from necom830.cc.titech.ac.jp by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA01738 Fri, 10 Jun 1994 00:12:40 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 9 Jun 94 23:04:00 +0900 From: Masataka Ohta Message-Id: <9406091404.AA01646@necom830.cc.titech.ac.jp> Subject: Re: Locator Sizes To: tracym@NSD.3Com.COM Date: Thu, 9 Jun 94 23:03:58 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <199406090628.AA05955@remmel.NSD.3Com.COM>; from "tracym@NSD.3Com.COM" at Jun 8, 94 11:28 pm X-Mailer: ELM [version 2.3 PL11] > > Flat routing with 10,000 or 100,000 entities, even today, is doable > > and will be considered to be minimal in the near future. > It is not > "minimal" today, and is unlikely to be minimal in 3 years. The price > of memory, while steadily declining, is not yet free (nor is > bandwidth, though we keep hoping it will happen any day...) Within 3 years, we won't need locators of 12 layers of 2 bytes, either. According to ALE, SIPP address can work as 4/4 byte locator/EID for about 10 years. > If low-end routers need to support such address spaces, they are > unlikely to become quite as inexpensive as folks would like. > One recent message pointed out that larger routers will have to > support a number of such address spaces(3-5), so memory will have to > get even cheaper before "minimal" becomes operative." According to ALE, it is expected that, within two years, even high-end routers can't support flat routing with 1,000,000 entities. So, my huumble estimation is that, five years later, even low-end IPng routers can support three or five spaces with flat routing with 10,000 entities. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 04:21:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13447; Fri, 10 Jun 1994 04:21: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 EAA20398; Fri, 10 Jun 1994 04:21:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA20377; Fri, 10 Jun 1994 04:09:12 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12934; Fri, 10 Jun 1994 04:09:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23597; Thu, 9 Jun 94 14:09:05 -0400 Date: Thu, 9 Jun 94 14:09:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406091809.AA23597@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: lower 8 bits of 8+8 format Cc: jnc@ginger.lcs.mit.edu From: bound@zk3.dec.com I believe we had consensus that EIDs must be globally unique. I see no point in the discussion of EIDs unless they are globally unique. I think we'd all like to have globally unique EID's. However, that may not be trivial to arrange, is the problem! :-) Due to the fact there EID's have no topological locality built into them, the scope for potential collisions in case of error (and errors are inevitable) is much larger. We were just exploring the difficulties which happen when you get non-unique ones, and how you might handle such collisions, something which seems likely to happen. I'm starting to see the value of EID's which are allocated in an organizational hierarchy, something KRE and others have been saying for a long time. The thing is that we already have such a hierarchy; DNS names. Now I start to wonder if you need two separate hierarchies that do the same thing, and if there's some way to use one for both... Hmmm. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 04:25:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13502; Fri, 10 Jun 1994 04:25: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 EAA20427; Fri, 10 Jun 1994 04:25:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA20360; Fri, 10 Jun 1994 04:01:40 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12654; Fri, 10 Jun 1994 04:01:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23497; Thu, 9 Jun 94 14:01:28 -0400 Date: Thu, 9 Jun 94 14:01:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406091801.AA23497@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: New TCP (was Re: 8+8 addressing..... Cc: jnc@ginger.lcs.mit.edu From: "Richard Carlson" The vision I have is that EID's should be part of the TCP header. What's wrong with putting them below TCP, so that various different transport protocols can all use the same mechanism? the EID (or my term is Transport Address (TA)) I realize that names aren't critical, but they may denote an important difference in thinking. EID stands for "endpoint ID", where an endpoint is the basic actor of reliable end-end communication; i.e. it's a name for a single entity (such as a garden variety host). This would be a significant difference from a transport level name which is local to that particular transport level. adding Src & Dest TA fields isn't that far fetched. Socket communications would then use a Src/dest TA.port notation instead of the current IP.port one. If the routers don't make decisions based on the TA's, then there's no need to put the destination TA in every packet, unless you expect multiple TA's on the same host. (I.e. you can't disambiguate packets based on the src/dest port and src TA alone...) Sure, you include it in the checksum, to make sure the packet was destined for this TA, but you don't need to actually ship the dest TA bits over the wire. They are of no value in fault detection, and since I doubt anyone's actually going to look at packets which fail the TCP checksum, there's no other use for them. I view mobility as a network layer problem with the associated locating and routing problems. This is not a task EID's should handle. One of the basic reasons to have EID's is to have a name for an entity which doesn't depend on where the entity is (or what interface you use to get to it). The internetwork layer needs names for things so that it can realize that endpoint A, which is now at locator X, is the same thing as it was when it was at locator Y. EID's don't provide mobility, they are a constant name for a potentially mobile object (the endpoint), something of great use in providing mobility. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 04:41:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14055; Fri, 10 Jun 1994 04:41: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 EAA20458; Fri, 10 Jun 1994 04:41:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA20406; Fri, 10 Jun 1994 04:22:43 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08377; Fri, 10 Jun 1994 02:33:55 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA02137; Thu, 9 Jun 94 09:35:48 -0700 Date: Thu, 9 Jun 94 09:35:48 -0700 From: Eric Fleischman Message-Id: <9406091635.AA02137@atc.boeing.com> To: ericf@atc.boeing.com, mo@uunet.uu.net Subject: Re: companies needing lots of internal routing...... crying foul.. Cc: big-internet@munnari.OZ.AU Dear Mike, I would like to express a contrary viewpoint to a few of your statements: >firstly, my proposal is not particularly motivated by "providerhood". >I fully appreciate the fact that I may have customers with a one or two >orders of magnitude more internal hosts than I have customers. This is >why I'm not worried too much about large organizations getting their >own network context - they have them now - it works fine. This is the first time I have heard somebody actually state that IPv4 addressing works fine for large organizations. [Perhaps I was asleep at the wheel and missed the earlier statements to that effect?] As a point of fact, there is a great deal wrong with IPv4 addressing. For example, we are beginning to worry about the same router aggregation problems within our internal networks that the Internet has been experiencing -- and there is no intra-domain version of CIDR to rescue us. I could say more but the bottom line is that IPv4 addressing does NOT work fine: it is badly broken and needs a great deal of "care and feeding" to successfully deploy in large numbers. >Note that I'm not *forcing* my customers to have network contexts which >are "within" mine - there will always be cases where you cannot CIDRize >all the routes. Unless large companies are treated like network service providers in their own right, your scheme (as I understand it) is effectively forcing your customers to have network contexts "within" yours -- or some other network service provider or groups of providers. >As for "not enough bytes for server-free addressing" - I think we're >straining at gnats and passing elephants here. Orgnizations that large >are going to have routers and/or servers which can do address >assignment - they have them now and I think bending over backwards to >not need them is more than makes sense, given other constraints. Boeing was one of a handful of companies to have participated in the IETF's DHCP efforts from nearly the beginning by writing code. We are (as a company) immensely sincere and aggressive in deploying and using this helpful technology. DHCP represents a significant advance over what was available before. Even so, it is not a panacea and more powerful and much more adequate technologies will be necessary to resolve our addresswing needs in accordance with the optimism expressed in your previous paragraph. The autoregistration omission is particularly troubling at this time as is the current address server placement requirements. >The *REAL* way to do what you want with the MAC address is to use it as >an EID. I know people keep whining about how the IEEE MAC address >isn't sufficiently perfect, but I keep claiming they aren't gonna get >anything materially better. Every other scheme I've seen described >here will botch-up some way or another because something will get >screwed sometime, somewhere, and believing you can have some weird >mathematical perfection in this is just *fantasy*. Yes, there will be >occassional collisions, and yes, they will be a bitch to deal with, >just like busted cables, marginal 10baseT hubs, and connectors with a >thermal problem. I believe all these ills happen with about the same >frequency, except the assigment collisions will happen a LOT less >frequently, so what the big deal? It's a price of doing business. You >might as well get ready because you won't do noticably better. >So, that's myh solution for folks who want to run serverless - just use >the MAC Address as the EID and you're home free. And if Boeing wants a >top-level network-context, tell 'em I sent you over for one. Your 8+8 scheme does not provide enough bytes for the end user to embed the IEEE MAC addresses into our addresses: You are requiring end users to solely have 8 bytes of addressing. An IEEE MAC address is 6 bytes long. Are you now going to claim that end users can comfortable have 5 levels of hierarchy with the remaining 16 bytes your schema gives them to work with? Even if completely dense addressing were possible and we had a completely flat network, that only gives us 65,000 subnetworks to play with. Networks with more than a million end systems will need more than 65,000 subnetworks -- and will DEFINITELY need to provide some routing hierarchy within those subnetworks. Now mind you, Mike, I may be guilty of misunderstanding your 8+8 approach. Thus, please feel free to correct me of any misperceptions which I may have. However, as I understand your 8+8 from my knot hole, it simply does not give enough addressing space for the large end user. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 05:21:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15260; Fri, 10 Jun 1994 05:21: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 FAA20504; Fri, 10 Jun 1994 05:21:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA20501; Fri, 10 Jun 1994 05:19:18 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15203; Fri, 10 Jun 1994 05:19:06 +1000 (from nordmark@jurassic-248.Eng.Sun.COM) Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA28637; Thu, 9 Jun 94 12:18:59 PDT Received: from jurassic.eng.sun.com by Eng.Sun.COM (8.6.9/SMI-4.1) id MAA04989; Thu, 9 Jun 1994 12:18:22 -0700 Received: from bobo.Eng.Sun.COM by jurassic.eng.sun.com (5.x/SMI-SVR4) id AA28081; Thu, 9 Jun 1994 12:18:45 -0700 Received: by bobo.Eng.Sun.COM (5.x/SMI-SVR4) id AA00575; Thu, 9 Jun 1994 12:18:46 -0700 Date: Thu, 9 Jun 1994 12:18:46 -0700 From: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Message-Id: <9406091918.AA00575@bobo.Eng.Sun.COM> To: kre@munnari.OZ.AU Subject: Re: 8+8 addressing..... Cc: big-internet@munnari.OZ.AU Mime-Version: 1.0 > My general impression is that icmp error messages are more > harmful to network robustness than the problems they are > diagnosing in most cases. Excapt for ICMP 'packet too big' which is required for IP Path MTU discovery. Thus anybody declaring that ICMP errors are useless better propose a different mechanism for pmtu discovery. Erik From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 05:35:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12754; Fri, 10 Jun 1994 04:03: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 EAA20358; Fri, 10 Jun 1994 04:01:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA20344; Fri, 10 Jun 1994 03:52:03 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12108; Fri, 10 Jun 1994 03:51:59 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-23.dialip.mich.net (pm002-23.dialip.mich.net [35.1.48.104]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id NAA29029 for ; Thu, 9 Jun 1994 13:51:51 -0400 Date: Thu, 9 Jun 94 16:30:37 GMT From: "William Allen Simpson" Message-Id: <2591.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: packets without locators > From: kasten@ftp.com (Frank Kastenholz) > > Assume we have administrative ownership information in the EID (this was > > my argument with Noel at the time, who wanted no structure at all). > > > > So, in the case of a packet with only an EID and no locators, the ICMP > > message would go back to the site based on the "ownership" of the EID. > > The owner DNS database has the locator information. The owner DNS-based > > "slow path" server then forwards the ICMP message to the true > > destination. > > This requires that when routers have problems, they must do an > EID->Locator lookup in order to send the error report. While this > lookup would take place in the 'slow path', it will take some > resources (cpu cycles and buffer memory) to do the lookup, which are > resources that are not available for the 'fast path' to use. > I'm sorry, Frank, but you have misread my message. The router does not do an EID->locator lookup. It forwards the slow path message based on the "ownership" of the EID. That implies that the direction to owners is carried in routing updates, as it currently is in BGP and IDRP. Only when it reaches the owner is the EID->locator lookup done, and the message forwarded to the final destination. Since the ownership information is non-topological, the path the message takes to the owner is likely to be non-optimal. That is what I meant by "slow-path". The path through the network the message takes is slow, not the path through the routing code. > I'm not arguing against EID-Locator mapping services. I am arguing > against requiring routers to do it in handling errors. > I agree. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 05:41:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15793; Fri, 10 Jun 1994 05:41: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 FAA20547; Fri, 10 Jun 1994 05:41:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA20509; Fri, 10 Jun 1994 05:22:02 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15266; Fri, 10 Jun 1994 05:21:56 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (engmail2.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA29320; Thu, 9 Jun 94 12:21:43 PDT Received: from jurassic.eng.sun.com by Eng.Sun.COM (8.6.9/SMI-4.1) id MAA05493; Thu, 9 Jun 1994 12:21:05 -0700 Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA20302; Thu, 9 Jun 1994 10:03:47 -0700 Date: Thu, 9 Jun 1994 10:03:47 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406091703.AA20302@jurassic.Eng.Sun.COM> To: Matt Crawford Cc: big-internet@munnari.OZ.AU In-Reply-To: <9406091520.AA15493@munin.fnal.gov> Subject: re: EID in 16 byte SIPP address?? Matt, > If the 16 byte SIPP address is to contain an EID, and if that EID is > 8 bytes or more, then there will be 8 bytes or fewer for the locator > function.[*] > > Didn't the IPng AD insist that "eight isn't enough" for a locator? > In the context of SIPP, isn't the current discussion somewhat > contradictory? (Except for the branch that holds that the EID is in > the transport layer only.) In the current SIPP specifications an 8 byte SIPP address includes both location and identification semantics. There was a range of 4 to 6 bytes of location information depending how they were used. My understanding was that the IPng directorate was concerned that was not enough. This lead to the proposal to increase the size of SIPP addresses to 16 bytes. It is far from clear to me that we need a clean separation of EID and Location information in SIPP addresses. My view is that it creates more problems than it solves. Bob From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 11:02:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28023; Fri, 10 Jun 1994 11:02: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 LAA20841; Fri, 10 Jun 1994 11:01:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA20824; Fri, 10 Jun 1994 10:52:34 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27463; Fri, 10 Jun 1994 10:51:42 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (engmail1-bb.Corp.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA02069; Thu, 9 Jun 94 17:51:37 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1(1/24/94)/SMI-4.1) id AA11482; Thu, 9 Jun 94 17:51:35 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA19032; Thu, 9 Jun 1994 17:50:46 -0700 Date: Thu, 9 Jun 1994 17:50:46 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406100050.AA19032@jurassic.Eng.Sun.COM> To: big-internet@munnari.OZ.AU In-Reply-To: <9406091918.AA00575@bobo.Eng.Sun.COM> Subject: Re: 8+8 addressing..... > > > My general impression is that icmp error messages are more > > harmful to network robustness than the problems they are > > diagnosing in most cases. > > Excapt for ICMP 'packet too big' which is required for IP Path > MTU discovery. Thus anybody declaring that ICMP errors are useless > better propose a different mechanism for pmtu discovery. Also TTL Expired is used in traceroute. A substitute would have to found for that too. Bob From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 13:21:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03858; Fri, 10 Jun 1994 13:21: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 NAA20987; Fri, 10 Jun 1994 13:21:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA20984; Fri, 10 Jun 1994 13:10:44 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03330; Fri, 10 Jun 1994 13:10:40 +1000 (from kre@munnari.OZ.AU) To: Big-Internet@munnari.OZ.AU Subject: What is "serverless autoconfiguration" ? Date: Fri, 10 Jun 1994 13:10:34 +1000 Message-Id: <22304.771217834@munnari.OZ.AU> From: Robert Elz The term "serverless autoconfiguration" has been bandied around a lot recently, and I've just realised that I don't know what it means, or perhaps, if it means what I think it means, or maybe thought it means, I don't see how it can possibly work. To me, "serverless autoconfiguration" (in the sense we're using it, I don't care about things like finding default filesystems to mount and such) must mean obtaining the node's IPng (or whatever) address without help from any external entity, so that the system can be booted without the network connected, without a knowledgeable human around, the first time it comes out of the box from the manufacturer, and when its finished it will have its address ready to use as soon as the net is eventually plugged in. An alternative is that it requires a net, but it can be a "null net", as it sends some kind of "address reservation" packets ala appletalk. I don't see how that can possibly work at all. On the other hand, if some external system is assumed, to provide some assistance in generating the address - perhaps by sending periodic "the net number is X" packets or something, then I no longer see that as "serverless", whatever is sending the assistance packets - either unsolicited, or upon request, is an address server in my terminology - if you're willing to believe that such a thing exists, then is there some problem with making better use of that server than simply having it send out some dummy packet from time to time? Before I stop, I also understand that in some camps its OK for a node to work out of the box with an address that can only function "locally" (however that is defined) - and that some other address is required to communicate further. That's probably something I could live with (by inventing smart net terminators, that simply jammed the net for 5 minutes if they ever saw such a "local" address to discourage their use...) but doesn't get us a lot further, as realistically everything is going to need one of the more mature addresses to do any sane work in anything but the very smallest of organisations. (Is address configuration, even manually, really a problem in very small organisations? Assume some software help exists for the administrator, not that a local expert in other fields who just happens to be the site admin has to type 99 bytes of hex). I would like to clear this up, as I have a half impression that in some people's minds the opposite of "severless" autoconfiguration is a file that's edited by some human (like traditional bootp servers), or isn't autoconfiguration at all, neither of which I believe is true - ie: "serverless" is not the only kind of "automatic" autoconfiguration. kre From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 13:58:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21872; Fri, 10 Jun 1994 08:43: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 IAA20708; Fri, 10 Jun 1994 08:41:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA20683; Fri, 10 Jun 1994 08:22:25 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20889; Fri, 10 Jun 1994 08:22:06 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA07158; Thu, 9 Jun 94 15:23:42 -0700 Date: Thu, 9 Jun 94 15:23:42 -0700 From: Eric Fleischman Message-Id: <9406092223.AA07158@atc.boeing.com> To: big-internet@munnari.OZ.AU, ericf@atc.boeing.com, rcallon@pobox.wellfleet.com, sipp@sunroof.Eng.Sun.COM Subject: Re: companies needing lots of internal routing...... Dear Ross, >I assume that when you say "MAC addresses", you really mean >"some unique value which has been assigned to the host as an >aid to address autoconfiguration". You and I have discussed this issue before. We are in total agreement. Your words above are fine. However, if you remember your DEC days, and the way DECnet/OSI does autoconfiguration, I was also meaning that. Also, if your remember the autoconfiguration schema which you presented to the TUBA working group, I was also meaning that. However, if you recall some of the linkage of IEEE MAC addresses with EIDs, and the various discussions within the community about that, I was potentially meaning that as well but I wouldn't want to admit to that possibility in public [i.e., Big TEN made me think that there is too much disagreement about what is meant by the term "EID" and how it will actually be used for the term to be intelligibly discussed today]. In any case, the key point I was making -- and this was the "bottom line" of my original posting -- was that I like the option of serverless autoconfiguration and I would like an addressing schema which would permit that option to exist. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 14:00:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28420; Fri, 10 Jun 1994 11:12: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 LAA20867; Fri, 10 Jun 1994 11:11:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA20838; Fri, 10 Jun 1994 10:58:14 +1000 Precedence: list Received: from lobster.wellfleet.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19627; Fri, 10 Jun 1994 07:53:08 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22595; Thu, 9 Jun 94 17:52:01 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA16542; Thu, 9 Jun 94 17:49:03 EDT Date: Thu, 9 Jun 94 17:49:03 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9406092149.AA16542@pobox.wellfleet> To: big-internet@munnari.OZ.AU, ericf@atc.boeing.com, sipp@sunroof.Eng.Sun.COM Subject: Re: companies needing lots of internal routing...... Dear Mike, I fully agree with your statement that >the way the address space gets administered at local sites is FAR more >important than the global bit whittling. In fact, I'm really fond of >doing MINIMAL global address whittling, thereby leaving the >most room for designating "local neighborhoods". However, your subsequent paragraph does not allow enough space for end systems to be autoaddressed by a serverless scheme which uses the MAC addresses. Thus, your approach necessitates that autoaddressing be solely done via servers -- if at all. This is a constraint I would prefer not to see imposed. Eric; I assume that when you say "MAC addresses", you really mean "some unique value which has been assigned to the host as an aid to address autoconfiguration". There has been a lot of confusion caused by folks mistaking the use of an IEEE 48-bit ID as "some already administered value which can be pre-assigned to a host" with the use of an IEEE 48-bit ID as "the address which is actually used on the subnet". I agree totally with the need for "serverless address autoconfiguration". Ross From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 14:42:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06153; Fri, 10 Jun 1994 14:22: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 OAA21095; Fri, 10 Jun 1994 14:21:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA21078; Fri, 10 Jun 1994 14:07:42 +1000 Precedence: list Received: from usage.csd.unsw.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23262; Fri, 10 Jun 1994 09:13:18 +1000 (from paul@atlas.dev.abccomp.oz.au) Received: by usage.csd.unsw.OZ.AU id AA03306 (5.65c/IDA-1.4.4 for big-internet%munnari.oz.au); Fri, 10 Jun 1994 09:12:45 +1000 Received: by atlas (4.1/1.35) id AA28135; Fri, 10 Jun 94 09:27:49 EST Message-Id: <9406092327.AA28135@atlas> From: paul@atlas.abccomp.oz.au Date: Fri, 10 Jun 1994 09:27:47 -0500 X-Mailer: Mail User's Shell (7.2.2 4/12/91) To: big-internet@munnari.OZ.AU Subject: Re: 8+8 addressing..... Cc: big-internet@munnari.OZ.AU Thus expounded Erik Nordmark on Jun 9,12:18pm: /-------------------- | |> My general impression is that icmp error messages are more |> harmful to network robustness than the problems they are |> diagnosing in most cases. | |Excapt for ICMP 'packet too big' which is required for IP Path |MTU discovery. Thus anybody declaring that ICMP errors are useless |better propose a different mechanism for pmtu discovery. Speaking as one who has been bitten, from my point of view its not so much the error reports that cause problems, but how broken implementations interpret them. BSD Unix has (or had not so long ago) an unfortunate habit of breaking off every existing TCP connection to a remote host when it received an ICMP PORT unreachable (which must have come from the same host) for a new attempted connection. It doesn't come to light very often, because any new implementation that returns ICMP Port unreachable as well as the TCP RST soon learns to not bother. This is a broken implementation, not a broken spec. - and no amount of discussion about error codes and their meaning can guard against the ability of broken/lazy programmers to produce broken/lazy implementations. -- Paul Brooks |paul@abccomp.oz.au |Emerging Standard: TurboSoft Pty Ltd |pwb@newt.phys.unsw.edu.au| one that has not yet 579 Harris St., Ultimo | | been superseded. Sydney Australia 2007 |ph: +61 2 281 3155 | From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 14:42:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06178; Fri, 10 Jun 1994 14:23: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 OAA21110; Fri, 10 Jun 1994 14:23:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA21081; Fri, 10 Jun 1994 14:07:46 +1000 Precedence: list Received: from achilles.ctd.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01781; Fri, 10 Jun 1994 12:29:57 +1000 (from b30118@achilles.ctd.anl.gov) Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA23040; Thu, 9 Jun 94 21:28:27 CDT Date: Thu, 9 Jun 94 21:28:27 CDT Message-Id: <9406100228.AA23040@achilles.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: New TCP (was Re: 8+8 addressing..... From: "Richard Carlson" > Cool. Y'all have invented the TSAP again! It's a worthy concept, >to be sure, but it doesn't have a lot to do with EIDs and how big they >ought to be. I don't think I buy this. The TSAP is the network address and TSEL concatenated together. (This sounds an awful lot like a socket to me). I don't want to use the network address, which has imbedded routing information, I want an address that simply identifies the node. The size is important as this address is included in every TCP packet. What that size is and who controls it is of great concern. > Really, this whole thread and its spawn is haring rapidly down the >classic IP path toward a muddle-headed and vague notion of 'address'. The >difference now seems to be that instead of one murky 'address' of 32 bits, we >now have several murky objects like 'addresses', all of which seem to be >enormous. What I see making the addresses 'murky' is trying to force a network address to be all things to all people. This is making it extremely large and complex. If we break the functions up, node identification and routing, then we can simplify both. The total length might be the same, or larger, but it's presented as peices that are easier to handle. Just let the IP(ng) address do it's thing, move packets from one node to another over a single unified internet. This is what IPv4 did. Let the TCP/UDP address determine the endpoints of a communications channel. Finally the specific port numbers identify the application using the data. (Just don't try concatenating them all together). > It's all very well to say 'Hey, let's not having a pissing contest >over little details like what words mean,' but it sure doesn't improve >communication when we all have different ideas about terminology. Make up >a new word if you think you mean something new. Yes we need to agree on what the terms mean. After we agree on that we may even get something that will work. :-) But so far I'm happy with the term EID and I don't think were arguing over how many angles can dance on the head of a pin just yet. Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 16:22:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11276; Fri, 10 Jun 1994 16:22: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 QAA21226; Fri, 10 Jun 1994 16:21:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA21223; Fri, 10 Jun 1994 16:14:01 +1000 Precedence: list Received: from achilles.ctd.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05328; Fri, 10 Jun 1994 14:00:17 +1000 (from b30118@achilles.ctd.anl.gov) Received: by achilles.ctd.anl.gov (4.1/SMI-4.1) id AA29587; Thu, 9 Jun 94 23:00:12 CDT Date: Thu, 9 Jun 94 23:00:12 CDT Message-Id: <9406100400.AA29587@achilles.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: New TCP (was Re: 8+8 addressing..... From: "Richard Carlson" >From: jnc@ginger.lcs.mit.edu (Noel Chiappa) >What's wrong with putting them below TCP, so that various different transport >protocols can all use the same mechanism? > >I realize that names aren't critical, but they may denote an important >difference in thinking. EID stands for "endpoint ID", where an endpoint is the >basic actor of reliable end-end communication; i.e. it's a name for a single >entity (such as a garden variety host). This would be a significant difference >from a transport level name which is local to that particular transport level. Well I have to agree that names are important. The question is are we using different names to mean different things, or just 2 sides of the same coin. Thanks for defining EID, I had assumed the E stood for extended. I intended to define an address for the generic transport layer of a node, not caring what transport protocol was used (though I assume TCP or UDP for Internet traffic). So I think we are looking at 2 sides of the same coin and aren't too far apart. My problem with having the EID below TCP how will this address be used. I feel that if it's in the network layer, someone will try and use it for routing purposes. Even though you didn't intend this, I think it will happen. >If the routers don't make decisions based on the TA's, then there's no need to >put the destination TA in every packet, unless you expect multiple TA's on the >same host. (I.e. you can't disambiguate packets based on the src/dest port and >src TA alone...) Sure, you include it in the checksum, to make sure the packet >was destined for this TA, but you don't need to actually ship the dest TA bits >over the wire. They are of no value in fault detection, and since I doubt >anyone's actually going to look at packets which fail the TCP checksum, there's >no other use for them. I agree that routers should be looking at the network addresses not transport addresses there job is to move packets between communicating nodes. But the end stations don't need to know how the packet was routed so why include the dest IP address on the last hop? Routers shouldn't be looking at EIDs in any case, no routing information right, so why stuff them into the network address? The Src & Dest TA's allow the end nodes to guarantee that the arriving packet is what its suppose to be (reliable service). The idea of skipping the dest TA and just using it in the checksum is intriguing, I never thought of that. The problem is that without it, there's no way to allow for level 4 routing. Something I think makes IPv4 and IPng compatablity simple. I don't expect multiple TA's, in fact that should never be allowed, I do expect some nodes to have multiple network stacks (IPv4 & IPng). With TA's you can let these nodes move packets from one stack to the other without the usual problems associated with level 4 routers. I admit that the cost of doing this is going to be quite high, but only a few specilized machines will be doing this. The benefit is that the network routers only need to deal with one kind of address. No elaborate rules need to be setup to decide if this is an IPv4 or IPng packet. Interoperability is also maintained by using the level 4 routing function. >One of the basic reasons to have EID's is to have a name for an entity which >doesn't depend on where the entity is (or what interface you use to get to it). >The internetwork layer needs names for things so that it can realize that >endpoint A, which is now at locator X, is the same thing as it was when it was >at locator Y. EID's don't provide mobility, they are a constant name for a >potentially mobile object (the endpoint), something of great use in providing >mobility. Again I completely agree. The EID is just a machine language version of the DNS name because we don't want to carry variable length DNS names around in data packets. (If we wanted variable length addresses then we could probably use the DNS name and skip one mapping issue altogether.) How you map between EID and locator address is a very complex issue for a mobile node, how mobile is mobile (i.e. how often does the locator addr change). I will have to give this some more thought, but right now I still feel that getting to a node, fixed or mobile, and identifying that that node exists are 2 seperate issues and this is not true for IPv4 nodes. Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 19:42:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19092; Fri, 10 Jun 1994 19:42: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 TAA21412; Fri, 10 Jun 1994 19:41:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA21387; Fri, 10 Jun 1994 19:23:23 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12478; Fri, 10 Jun 1994 16:47:21 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA04775; Fri, 10 Jun 1994 08:47:15 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA15460; Fri, 10 Jun 1994 08:47:13 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406100647.AA15460@dxcoms.cern.ch> Subject: Hurrah!! To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 10 Jun 1994 08:47:13 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406091809.AA23597@ginger.lcs.mit.edu> from "Noel Chiappa" at Jun 9, 94 02:09:05 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 488 Thank you Noel, I'm glad somebody finally said it! Brian >--------- Text sent by Noel Chiappa follows: ... > > I'm starting to see the value of EID's which are allocated in an > organizational hierarchy, something KRE and others have been saying for a long > time. The thing is that we already have such a hierarchy; DNS names. Now I > start to wonder if you need two separate hierarchies that do the same thing, > and if there's some way to use one for both... Hmmm. > > Noel > From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 21:22:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21943; Fri, 10 Jun 1994 21:22: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 VAA21511; Fri, 10 Jun 1994 21:21:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA21508; Fri, 10 Jun 1994 21:16:33 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19789; Fri, 10 Jun 1994 20:05:27 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA02609; Fri, 10 Jun 1994 12:06:01 +0200 Message-Id: <199406101006.AA02609@mitsou.inria.fr> To: Robert Elz Cc: Big-Internet@munnari.OZ.AU Subject: Re: What is "serverless autoconfiguration" ? In-Reply-To: Your message of "Fri, 10 Jun 1994 13:10:34 +1000." <22304.771217834@munnari.OZ.AU> Date: Fri, 10 Jun 1994 12:06:01 +0200 From: Christian Huitema Robert, Serverless identification refers to the "dentist shop" problem. If the dentist is not connected to the Internet and buys two PCs and plugs both to an Ethernet, then the two PCs should be able to talk IPng between themselves without any configuration. That works with SIPP, so is probably possible. Christian Huitema From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 21:23:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22013; Fri, 10 Jun 1994 21:23: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 VAA21526; Fri, 10 Jun 1994 21:23:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA21505; Fri, 10 Jun 1994 21:14:57 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12916; Fri, 10 Jun 1994 16:58:45 +1000 (from brian@dxcoms.cern.ch) Received: from dxmint.cern.ch by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA16842 Fri, 10 Jun 1994 16:57:23 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA09711; Fri, 10 Jun 1994 08:54:43 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA15775; Fri, 10 Jun 1994 08:54:43 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406100654.AA15775@dxcoms.cern.ch> Subject: Re: What is "serverless autoconfiguration" ? To: kre@munnari.OZ.AU (Robert Elz) Date: Fri, 10 Jun 1994 08:54:42 +0200 (MET DST) Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <22304.771217834@munnari.OZ.AU> from "Robert Elz" at Jun 10, 94 01:10:34 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 336 I must confess that I don't know why serverless autoconfig is a requirement. Every network I know of today has at least one server (in a generic sense, i.e. a distinguished machine that is properly managed). Every network that is networked has at least one router. So you can always find a box to act as the autoconfig server. Brian From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 21:24:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22029; Fri, 10 Jun 1994 21:24: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 VAA21541; Fri, 10 Jun 1994 21:24:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA21502; Fri, 10 Jun 1994 21:14:53 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08752; Fri, 10 Jun 1994 15:27:33 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14442(2)>; Thu, 9 Jun 1994 22:27:04 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Thu, 9 Jun 1994 22:27:01 -0700 To: Robert Elz Cc: Big-Internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: What is "serverless autoconfiguration" ? In-Reply-To: kre's message of Thu, 09 Jun 94 20:10:34 -0800. <22304.771217834@munnari.OZ.AU> Date: Thu, 9 Jun 1994 22:26:58 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jun9.222701pdt.12171@skylark.parc.xerox.com> > The term "serverless autoconfiguration" has been bandied around > a lot recently, and I've just realised that I don't know what > it means, or perhaps, if it means what I think it means, or > maybe thought it means, I don't see how it can possibly work. Robert, Since I coined the phrase (actually, the complete phrase is "serverless autoconfiguration of host addresses"), I'll tell you what I meant. Feel free to invent a different term, if you find mine confusing. I meant the method whereby a host generates a unique internet address for itself at start-up time by concatenating two parts: where: is the prefix that identifies the network/subnet/area in which the host resides, which the host learns by listening to or querying a neighboring router. is a value known to the host to be unique within the given network/subnet/area. The most commonly used value is an Ethernet/ IEEE-802 address, which being (in theory) globally unique, is thus unique within any network/subnet/area. When no routers are present when a host starts up, the host may use a "null" , e.g., all-zeros, for local communication; if and when a router eventually shows up, the host then learns a non-null from which it can fabricate a global address for itself. I exclude LocalTalk-style address autoconfiguration from my definition, because it uses values that are small random numbers and, therefore, not apriori known to be unique. (A host must query the net, to learn if a chosen is already in use; as we all know, this is much less robust than the approach based on known-unique values.) I used the qualifier "serverless" to contrast it with approaches that require a host to obtain its address from a third-party (i.e., not the host and not necessarily a router), e.g., a BOOTP or DHCP server. I had not meant to distinguish between servers that hand-out manually assigned addresses (e.g., BOOTP) and those that hand out automatically assigned addresses (e.g., DHCP). Perhaps you would prefer the term "IPX-style autoconfiguration", since IPX is the best-known example of an internet protocol that uses the "serverless" approach to host address configuration. Now that you know what the term means, let the debate continue. From the poll I took just before the IPng Directorate meeting in Chicago, it seems that some people love it, some people hate it, but most people think it's a reasonable capability to have as long as a network manager can disable or ignore it on any given network. I consider this to be a crucial debate, because the need to do IPX-style autoconfiguration is, in my mind, the only technical motivation for having addresses bigger than 8 bytes. Steve From owner-Big-Internet@munnari.OZ.AU Fri Jun 10 21:41:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22695; Fri, 10 Jun 1994 21:41: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 VAA21588; Fri, 10 Jun 1994 21:41:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA21574; Fri, 10 Jun 1994 21:38:31 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12554; Fri, 10 Jun 1994 16:49:19 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 10 Jun 94 15:42:14 +0900 From: Masataka Ohta Message-Id: <9406100642.AA04399@necom830.cc.titech.ac.jp> Subject: Re: lower 8 bits of 8+8 format To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 10 Jun 94 15:42:12 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406091809.AA23597@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 9, 94 2:09 pm X-Mailer: ELM [version 2.3 PL11] > I'm starting to see the value of EID's which are allocated in an > organizational hierarchy, something KRE and others have been saying for a long > time. The thing is that we already have such a hierarchy; DNS names. Now I > start to wonder if you need two separate hierarchies that do the same thing, > and if there's some way to use one for both... Hmmm. Actually, there are three hierarchies some of which can be merged. Locators have hierarchy for hierarchical routing with topological locality. EIDs have hierarchy for hierarchical assignment with organizational hierarchy. The problem with IPv4 is that 3 (for class Cs and 2 for class Bs) level hierarchy of DNS is not enough for fine interorganizational hierarchy. With 8 bytes of EIDs with byte-wise or hexadecimal-wise hierarchy gives a lot more room for hierarchical delegation. We should minimize the levels of hierarchy to suppress inefficient use of the EID space. Perhaps, hexadecimal-wise is too aggressive and byte-wise delegation is the best. Some bits of a locator are used for local flat routing. Some bits of an EID are used for local assignment within an organization. These bits may overlap. Of course, excessive overlapping imposes a lot restriction on routing and EID assinment and should be avoided. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 00:02:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27731; Sat, 11 Jun 1994 00:02: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 AAA21739; Sat, 11 Jun 1994 00:01:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA21736; Sat, 11 Jun 1994 00:00:45 +1000 Precedence: list Received: from FRED.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27560; Sat, 11 Jun 1994 00:00:40 +1000 (from craig@BBN.COM) Message-Id: <9406101400.27560@munnari.oz.au> To: Robert Elz Cc: Big-Internet@munnari.OZ.AU Subject: re: What is "serverless autoconfiguration" ? Date: Fri, 10 Jun 94 09:20:01 -0400 From: Craig Partridge Robert: I don't have the criteria docs in front of me because I'm travelling, but my recollection is that our goal in the criteria document (and I don't recall if we used the term "serverless" or not) was the following: No one should have to buy a special box to get an IPng network to run. You should be able to plug in two hosts on an isolated Ethernet and make them work. This may happen by hand configuring a boot file, but it should work. Craig From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 00:15:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24094; Fri, 10 Jun 1994 22:24: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 WAA21632; Fri, 10 Jun 1994 22:21:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA21618; Fri, 10 Jun 1994 22:04:21 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20903; Fri, 10 Jun 1994 20:43:49 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA11173; Fri, 10 Jun 94 05:45:10 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ad12318; 10 Jun 94 10:42 GMT Date: Fri, 10 Jun 94 05:41 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Eric Fleischman To: big internet Subject: Re: companies needing lots of internal routing...... crying foul.. Message-Id: <34940610104143/0003858921NA5EM@mcimail.com> >This is the first time I have heard somebody actually state that IPv4 >addressing works fine for large organizations. [Perhaps I was asleep >at the wheel and missed the earlier statements to that effect?] As a >point of fact, there is a great deal wrong with IPv4 addressing. For >example, we are beginning to worry about the same router aggregation >problems within our internal networks that the Internet has been >experiencing -- and there is no intra-domain version of CIDR to rescue us. >I could say more but the bottom line is that IPv4 addressing does NOT work >fine: it is badly broken and needs a great deal of "care and feeding" >to successfully deploy in large numbers. Well we are not quite as large of a network as Boeing, yet :) But IPv4 will carry us a while longer. Of course nothing is perfect in this world. The alternative to CIDR in a corporation is OSPF address aggregation. We are using it here to address our routing table explosion. Of course this only works within a net, but considering how many subnets we have within some of our B class networks, this is very valuable... Bob Moskowitzz Chrysler From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 01:02:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00280; Sat, 11 Jun 1994 01:02: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 BAA21863; Sat, 11 Jun 1994 01:01:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA21840; Sat, 11 Jun 1994 00:59:31 +1000 Precedence: list From: jallard@microsoft.com Received: from netmail2.microsoft.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00141; Sat, 11 Jun 1994 00:59:24 +1000 (from jallard@microsoft.com) Received: by netmail2.microsoft.com (5.65/25-eef) id AA17189; Fri, 10 Jun 94 07:00:56 -0700 Message-Id: <9406101400.AA17189@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Fri, 10 Jun 94 07:00:56 PDT X-Msmail-Message-Id: B8F9A7BA X-Msmail-Conversation-Id: B8F9A7BA To: Big-Internet@munnari.OZ.AU, owner-Big-Internet@munnari.OZ.AU Date: Fri, 10 Jun 94 07:53:46 TZ Subject: RE: What is "serverless autoconfiguration" ? | The term "serverless autoconfiguration" has been bandied around | a lot recently, and I've just realised that I don't know what | it means, or perhaps, if it means what I think it means, or | maybe thought it means, I don't see how it can possibly work. perhaps a more appropriate term is "serverless automatic host addressing", although not as catchy. the intention was to shove some responsibility onto the router vendors, or smarts in the client, to get end systems configured w/ unique (net+host ids) successfully w no end user intervention. this solves only a subset of the problem that bootp/dhcp attempts to solve (serverful automatic host configuration+addressing), but does not mandate that a bootp/dhcp server be available to get the basic datagram transport service up (at least on the local network). novell has done this w/ netware. the host learns the netid from the router, if no router is present the host uses netid 0 (local net) until the router comes back. hostid is simply macaddr. this solves the unique flat addressing problem for non-routed local nets as well as the hierarchical addressing problem for routed nets. serverful host configuration (a la dhcp) is also of great interest. by year end '94 a number of corporate ipv4 nets will be using dhcp in some capacity for new systems and will want to be able to centrally manage workstation transport configuration using a similar technology until an ipng infrastructure exists which permits ubiquitous service location (e.g., dns, print servers, nis, default mounts, etc..). _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 01:21:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01051; Sat, 11 Jun 1994 01:21: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 BAA21909; Sat, 11 Jun 1994 01:21:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA21906; Sat, 11 Jun 1994 01:19:44 +1000 Precedence: list Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00976; Sat, 11 Jun 1994 01:19:37 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA29008; Fri, 10 Jun 94 11:18:32 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA27343; Fri, 10 Jun 94 11:15:35 EDT Date: Fri, 10 Jun 94 11:15:35 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9406101515.AA27343@pobox.wellfleet> To: deering@parc.xerox.com, kre@munnari.OZ.AU Subject: Re: What is "serverless autoconfiguration" ? Cc: Big-Internet@munnari.OZ.AU Since I coined the phrase (actually, the complete phrase is "serverless autoconfiguration of host addresses"), I'll tell you what I meant. Feel free to invent a different term, if you find mine confusing. I meant the method whereby a host generates a unique internet address for itself at start-up time by concatenating two parts: where: is the prefix that identifies the network/subnet/area in which the host resides, which the host learns by listening to or querying a neighboring router. is a value known to the host to be unique within the given network/subnet/area. The most commonly used value is an Ethernet/ IEEE-802 address, which being (in theory) globally unique, is thus unique within any network/subnet/area. When no routers are present when a host starts up, the host may use a "null" , e.g., all-zeros, for local communication; if and when a router eventually shows up, the host then learns a non-null from which it can fabricate a global address for itself. I exclude LocalTalk-style address autoconfiguration from my definition, because it uses values that are small random numbers and, therefore, not apriori known to be unique. (A host must query the net, to learn if a chosen is already in use; as we all know, this is much less robust than the approach based on known-unique values.) I used the qualifier "serverless" to contrast it with approaches that require a host to obtain its address from a third-party (i.e., not the host and not necessarily a router), e.g., a BOOTP or DHCP server. I had not meant to distinguish between servers that hand-out manually assigned addresses (e.g., BOOTP) and those that hand out automatically assigned addresses (e.g., DHCP). I like the term "stateless", since this style of autoconfiguration does not require any per-host state to be maintained for the purpose of address autoconfiguration. However, since I think that Steve's definition is very well stated, it doesn't really matter much whether we call this "serverless" or "stateless", as long as we agree on what the term means. One advantage of this form of address autoconfiguration is that if a system goes away for a while (I take my laptop with me for a trip), then when the system comes back it will have the same address. Also, it avoids the problems with server replication and the requirement to maintain per-host state relating to addresses. Let's assume that you want to avoid having a single point of failure. Suppose we use "active server-based auto- configuration", in which a server has to actually assign an address to a host when it first comes up (and maintain a table entry providing the host-handle to host-address mapping). Then we would presumeably need two of these servers in a network (in case one fails). This means that we need protocols for the two to coordinate -- when one server assigns an address to a host, it needs to make sure that the other knows about the assignment. When I take my laptop away for a trip, the server needs to somehow figure out whether I have left for good (and it can purge its state), or I am just off for a trip (and it needs to maintain its state). Thus the "active server keeps state" form of address autoconfiguration is considerably more complex. In a home network (of the year 2000), who is going to manage this address server? (the average person doesn't know how to program a VCR, so it better be simpler than a VCR to operate). Thus, stateless / serverless address autoconfiguration is a whole lot simpler and easier to manage. I think that this is more important than saving 16 bytes per packet (8 each for source and destination address), particularly for networks sold to "normal folks" (homes and small businesses). Perhaps you would prefer the term "IPX-style autoconfiguration", since IPX is the best-known example of an internet protocol that uses the "serverless" approach to host address configuration. IPX has been *very* successful, and ease of configuration is a *big* part of this. Now that you know what the term means, let the debate continue. From the poll I took just before the IPng Directorate meeting in Chicago, it seems that some people love it, some people hate it, but most people think it's a reasonable capability to have as long as a network manager can disable or ignore it on any given network. I consider this to be a crucial debate, because the need to do IPX-style autoconfiguration is, in my mind, the only technical motivation for having addresses bigger than 8 bytes. I love it. I feel that we have to start thinking about how to make networks a lot easier to manage, and we should plan on making networks that can be sold to non-technical folks in small businesses and homes, who don't have any professional network manager available. Ross From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 02:01:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02440; Sat, 11 Jun 1994 02:01: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 CAA21964; Sat, 11 Jun 1994 02:01:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA21961; Sat, 11 Jun 1994 02:00:37 +1000 Precedence: list Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02429; Sat, 11 Jun 1994 02:00:32 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA09948 (InterLock SMTP Gateway 1.1); Fri, 10 Jun 1994 11:59:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 10 Jun 1994 11:59:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 10 Jun 1994 11:59:57 -0400 Message-Id: <199406101556.AA129343@foo.ans.net> To: Christian Huitema Cc: Robert Elz , Big-Internet@munnari.OZ.AU Subject: Re: What is "serverless autoconfiguration" ? In-Reply-To: Your message of "Fri, 10 Jun 1994 10:06:01 GMT." <199406101006.AA02609@mitsou.inria.fr> Date: Fri, 10 Jun 1994 11:56:35 -0400 From: Dennis Ferguson Christian, > Serverless identification refers to the "dentist shop" problem. > If the dentist is not connected to the Internet and buys two PCs and > plugs both to an Ethernet, then the two PCs should be able > to talk IPng between themselves without any configuration. That > works with SIPP, so is probably possible. The part I am curious about is the "what next?" part. Now that the dentist has these two PCs up and running with their own self-determined addresses, what does he do with them? Not type `telnet' followed by 16 bytes worth of hex digits which he discovered by looking at his ARP cache, I hope. It seems to me that for serverless identification to be useful there needs to be an application infrastructure which supports machines which know nothing other than an address for themselves, so a machine which knows nothing but its address can do something useful. It also seems to me this may not be the Internet application infrastructure we have today. By bearing the cost of supporting serverless/configuration free identification at the network layer, are we signing up to do the rest of the work which appears to be needed to make this useful? Dennis Ferguson From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 02:27:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28154; Sat, 11 Jun 1994 00:05: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 AAA21754; Sat, 11 Jun 1994 00:05:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA21720; Fri, 10 Jun 1994 23:50:26 +1000 Precedence: list Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26985; Fri, 10 Jun 1994 23:50:08 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA20800 (InterLock SMTP Gateway 1.1); Fri, 10 Jun 1994 09:49:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 10 Jun 1994 09:49:23 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 10 Jun 1994 09:49:23 -0400 Message-Id: <199406101346.AA55390@foo.ans.net> To: Steve Deering Cc: Robert Elz , Big-Internet@munnari.OZ.AU Subject: Re: What is "serverless autoconfiguration" ? In-Reply-To: Your message of "Fri, 10 Jun 1994 05:26:58 GMT." <94Jun9.222701pdt.12171@skylark.parc.xerox.com> Date: Fri, 10 Jun 1994 09:46:03 -0400 From: Dennis Ferguson Steve, > I used the qualifier "serverless" to contrast it with approaches that require > a host to obtain its address from a third-party (i.e., not the host and > not necessarily a router), e.g., a BOOTP or DHCP server. I had not meant > to distinguish between servers that hand-out manually assigned addresses > (e.g., BOOTP) and those that hand out automatically assigned addresses (e.g., > DHCP). I don't have strong opinions about any of this, but I am honestly curious about the "what next?" question. For example, is a host with an address but without a name which can be associated with the address useful for anything given our current applications infrastructure? If so, how much? What about some future applications infrastructure where stronger authentication might be a more ordinary requirement? My concern is that we might be going to considerable expense to permit "serverless autoconfiguration of host addresses", just to end up in a situation where the first thing a host which has just autoconfigured its own address without the help of a server is going to have to do is find a server, perhaps to register its name with its address-de-jour (which it will be if the host ID changes at the whim of your hardware repair person), or perhaps to find someone who'll handle DNS requests, or whatever else I seem to end up configuring manually on hosts I use. Since "serverless autoconfiguration of host addresses" does not seem to be equivalent to "serverless autoconfiguration", and "autoconfiguration" may imply "server" in any case, I can't help but wonder if being able to determine a host address without the server is really enough of an advantage to justify the cost. You certainly can always get by without a server, but the minute you need to type in anything to make your host work it seems to me you might just as well type in an address at the same time and be done with it. If you do need a server, though, it doesn't necessarily seem like a hardship to have the server tell you your address at the same time it tells you whatever else you need to know. So I guess this amounts to two questions: (a) Are there important situations where being able to determine a host address in the absence of a server will allow you to get useful work done in the absence of a server, without additional manual configuration? (b) If not (a), then is there some important advantage in being able to determine an address before you deal with servers to discover additional configuration, such that relying on a server to hand you an address would be a disadvantage? Dennis Ferguson From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 02:33:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03157; Sat, 11 Jun 1994 02:22: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 CAA21996; Sat, 11 Jun 1994 02:21:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA21991; Sat, 11 Jun 1994 02:15:18 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02975; Sat, 11 Jun 1994 02:15:14 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA16420; Fri, 10 Jun 1994 02:19:03 -0700 Date: Fri, 10 Jun 1994 02:19:03 -0700 From: Tony Li Message-Id: <199406100919.CAA16420@lager.cisco.com> To: big-internet@munnari.OZ.AU Cc: SIPP Mailing list , tuba@Lanl.GOV, tli@cisco.com, yakov@watson.ibm.com Reply-To: big-internet@munnari.OZ.AU, tli@cisco.com, yakov@watson.ibm.com Subject: BigTen addressing drafts Folks, As part of the IPng Directorate meeting May 19 & 20 in Chicago, the Directorate and its guests had a general discussion of alternative designs. Discussion focused around a hypothetical proposal which, for the lack of a better name, we call BigTen, after the conference center where the meeting was held. One of the more interesting features about BigTen is that it does use variable length addresses in a way unlike any of the current proposals. Subsequent to the meeting, Yakov and I were asked by the area directors to look into an addressing architecture and plan for such addresses. These documents are now available as Internet drafts: draft-rekhter-bigten-addr-arch-00.txt draft-li-bigten-addr-format-00.txt Please note that these are CRUDE first drafts subject to major revisions. For example, it's not clear if the length bits should have routing significance. Please direct any comments to Yakov and myself. Public discussion should occur on the big-internet mailing list. Thanks, Tony From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 03:21:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05386; Sat, 11 Jun 1994 03:21: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 DAA22106; Sat, 11 Jun 1994 03:21:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA22100; Sat, 11 Jun 1994 03:10:21 +1000 Precedence: list Received: from netcom12.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03807; Sat, 11 Jun 1994 02:36:31 +1000 (from kck@netcom.com) Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id JAA21314; Fri, 10 Jun 1994 09:36:35 -0700 Date: Fri, 10 Jun 1994 09:36:35 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199406101636.JAA21314@netcom.com> To: Big-Internet@munnari.OZ.AU Subject: Re: What is "serverless autoconfiguration" ? >Now that you know what the term means, let the debate continue. From the >poll I took just before the IPng Directorate meeting in Chicago, it seems >that some people love it, some people hate it, but most people think it's >a reasonable capability to have as long as a network manager can disable >or ignore it on any given network. I consider this to be a crucial debate, >because the need to do IPX-style autoconfiguration is, in my mind, the >only technical motivation for having addresses bigger than 8 bytes. > >Steve If this last statement is true, then I vote we stay with 8 byte addresses and stop extending the address. First off, almost all networks have a server of some sort on it, usually on the same subnet. So lets not design for the very infrequent incounter. Amd for the infrequent incounter we should be able to steal a prefix value in one of the field splits in the address that says I am autoconfiguring. This really shouldn't require 8 more bytes! -r From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 03:32:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03952; Sat, 11 Jun 1994 02: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 CAA22042; Sat, 11 Jun 1994 02:41:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA22023; Sat, 11 Jun 1994 02:25:44 +1000 Precedence: list Received: from POSTOFFICE3.MAIL.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03338; Sat, 11 Jun 1994 02:25:08 +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.5/8.6.5) with SMTP id MAA05463; Fri, 10 Jun 1994 12:23:58 -0400 Message-Id: <199406101623.MAA05463@postoffice3.mail.cornell.edu> X-Sender: swb1@132.236.56.11 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 10 Jun 1994 12:23:55 -0500 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Scott W Brim Subject: Re: Hurrah!! Cc: big-internet@munnari.OZ.AU There was an IAB paper on the concept of naming and the concept of connectivity a couple of years ago. Could anyone tell me what happened to it? ...Scott > I'm starting to see the value of EID's which are allocated in an > organizational hierarchy, something KRE and others have been saying for a long > time. The thing is that we already have such a hierarchy; DNS names. Now I > start to wonder if you need two separate hierarchies that do the same thing, and if there's some way to use one for both... Hmmm. > > Noel From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 03:36:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03988; Sat, 11 Jun 1994 02:43: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 CAA22057; Sat, 11 Jun 1994 02:42:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA22026; Sat, 11 Jun 1994 02:33:31 +1000 Precedence: list Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01682; Sat, 11 Jun 1994 01:41:17 +1000 (from lyman@BBN.COM) Message-Id: <9406101541.1682@munnari.oz.au> From: Lyman Chapin Subject: Re: What is "serverless autoconfiguration" ? To: deering@parc.xerox.com Cc: Big-Internet@munnari.OZ.AU, kre@munnari.OZ.AU In-Reply-To: <94Jun9.222701pdt.12171@skylark.parc.xerox.com> Date: Fri, 10 Jun 94 10:52:29 EDT Mail-System-Version: Hi Steve, You could always call it "ES-IS autoconfiguration", since this is exactly how ES-IS (ISO/IEC 9542) does dynamic address assignment...;-) - Lyman >To: Robert Elz >Cc: Big-Internet@munnari.OZ.AU, deering@parc.xerox.com >Subject: Re: What is "serverless autoconfiguration" ? >Date: Thu, 9 Jun 1994 22:26:58 PDT >From: Steve Deering > >> The term "serverless autoconfiguration" has been bandied around >> a lot recently, and I've just realised that I don't know what >> it means, or perhaps, if it means what I think it means, or >> maybe thought it means, I don't see how it can possibly work. > >Robert, > >Since I coined the phrase (actually, the complete phrase is "serverless >autoconfiguration of host addresses"), I'll tell you what I meant. Feel >free to invent a different term, if you find mine confusing. > >I meant the method whereby a host generates a unique internet address for >itself at start-up time by concatenating two parts: > > > >where: is the prefix that identifies the network/subnet/area > in which the host resides, which the host learns by listening to or > querying a neighboring router. > > is a value known to the host to be unique within the given > network/subnet/area. The most commonly used value is an Ethernet/ > IEEE-802 address, which being (in theory) globally unique, is thus > unique within any network/subnet/area. > >When no routers are present when a host starts up, the host may use a "null" >, e.g., all-zeros, for local communication; if and when a router >eventually shows up, the host then learns a non-null from which >it can fabricate a global address for itself. > >I exclude LocalTalk-style address autoconfiguration from my definition, >because it uses values that are small random numbers and, >therefore, not apriori known to be unique. (A host must query the >net, to learn if a chosen is already in use; as we all know, >this is much less robust than the approach based on known-unique values.) > >I used the qualifier "serverless" to contrast it with approaches that require >a host to obtain its address from a third-party (i.e., not the host and >not necessarily a router), e.g., a BOOTP or DHCP server. I had not meant >to distinguish between servers that hand-out manually assigned addresses >(e.g., BOOTP) and those that hand out automatically assigned addresses (e.g., >DHCP). > >Perhaps you would prefer the term "IPX-style autoconfiguration", since IPX >is the best-known example of an internet protocol that uses the "serverless" >approach to host address configuration. > >Now that you know what the term means, let the debate continue. From the >poll I took just before the IPng Directorate meeting in Chicago, it seems >that some people love it, some people hate it, but most people think it's >a reasonable capability to have as long as a network manager can disable >or ignore it on any given network. I consider this to be a crucial debate, >because the need to do IPX-style autoconfiguration is, in my mind, the >only technical motivation for having addresses bigger than 8 bytes. > >Steve > From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 03:37:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05468; Sat, 11 Jun 1994 03:23: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 DAA22121; Sat, 11 Jun 1994 03:23:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA22103; Sat, 11 Jun 1994 03:19:05 +1000 Precedence: list Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05165; Sat, 11 Jun 1994 03:18:47 +1000 (from dkatz@cisco.com) Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA27628; Fri, 10 Jun 1994 10:18:38 -0700 Date: Fri, 10 Jun 1994 10:18:38 -0700 From: Dave Katz Message-Id: <199406101718.KAA27628@feta.cisco.com> To: kre@munnari.OZ.AU Cc: Big-Internet@munnari.OZ.AU In-Reply-To: Robert Elz's message of Fri, 10 Jun 1994 13:10:34 +1000 <22304.771217834@munnari.OZ.AU> Subject: What is "serverless autoconfiguration" ? The model for network address assignment that I've been advocating is as follows. The hosts in general should ask for a network address, not assign one autonomously. This provides a point of administrative control for assignment policy--it could be quite stateless, or under tight control, or somewhere in between. Network address assignment should take place in the network layer fabric (namely, the routers, with the possible assistance of other forms of server for more complex administrative policy). I think it a requirement that it should be possible for the assignment to be stateless (in the sense that it is not a requirement that the assignment be written down in a non-volatile way). This has implications for address length (since you'll need to embed a cookie such as a MAC address). The assignment should be completely serverless only when there are no routers around, and that the addresses assigned in that manner should *not* be globally routable. This model supports a closed routerless, serverless LAN, a very lightweight setup (some hosts and a router, with no separate server to administer), and a very complex stateful disk-y server strategy where every new machine requires someone to type something first (I've heard this as a requirement from some of our customers). This does not provide any security against hosts just picking an address and talking, of course, but assuming well-behaved hosts provides a reasonable spectrum of administrative choices. Precedence: list Date: Fri, 10 Jun 1994 13:10:34 +1000 From: Robert Elz The term "serverless autoconfiguration" has been bandied around a lot recently, and I've just realised that I don't know what it means, or perhaps, if it means what I think it means, or maybe thought it means, I don't see how it can possibly work. To me, "serverless autoconfiguration" (in the sense we're using it, I don't care about things like finding default filesystems to mount and such) must mean obtaining the node's IPng (or whatever) address without help from any external entity, so that the system can be booted without the network connected, without a knowledgeable human around, the first time it comes out of the box from the manufacturer, and when its finished it will have its address ready to use as soon as the net is eventually plugged in. An alternative is that it requires a net, but it can be a "null net", as it sends some kind of "address reservation" packets ala appletalk. I don't see how that can possibly work at all. On the other hand, if some external system is assumed, to provide some assistance in generating the address - perhaps by sending periodic "the net number is X" packets or something, then I no longer see that as "serverless", whatever is sending the assistance packets - either unsolicited, or upon request, is an address server in my terminology - if you're willing to believe that such a thing exists, then is there some problem with making better use of that server than simply having it send out some dummy packet from time to time? Before I stop, I also understand that in some camps its OK for a node to work out of the box with an address that can only function "locally" (however that is defined) - and that some other address is required to communicate further. That's probably something I could live with (by inventing smart net terminators, that simply jammed the net for 5 minutes if they ever saw such a "local" address to discourage their use...) but doesn't get us a lot further, as realistically everything is going to need one of the more mature addresses to do any sane work in anything but the very smallest of organisations. (Is address configuration, even manually, really a problem in very small organisations? Assume some software help exists for the administrator, not that a local expert in other fields who just happens to be the site admin has to type 99 bytes of hex). I would like to clear this up, as I have a half impression that in some people's minds the opposite of "severless" autoconfiguration is a file that's edited by some human (like traditional bootp servers), or isn't autoconfiguration at all, neither of which I believe is true - ie: "serverless" is not the only kind of "automatic" autoconfiguration. kre From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 03:41:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06120; Sat, 11 Jun 1994 03:41: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 DAA22162; Sat, 11 Jun 1994 03:41:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA22148; Sat, 11 Jun 1994 03:35:24 +1000 Precedence: list Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05902; Sat, 11 Jun 1994 03:35:19 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA00419 (5.65c/IDA-1.4.4nsd for ); Fri, 10 Jun 1994 10:35:16 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA10302 (5.65c/IDA-1.4.4-910725 for ); Fri, 10 Jun 1994 10:35:09 -0700 Message-Id: <199406101735.AA10302@remmel.NSD.3Com.COM> To: Big-Internet@munnari.OZ.AU Subject: Re: What is "serverless autoconfiguration" ? In-Reply-To: Your message of "Fri, 10 Jun 94 08:54:42 +0200." <9406100654.AA15775@dxcoms.cern.ch> Date: Fri, 10 Jun 94 10:35:04 -0700 From: tracym@NSD.3Com.COM > ... Every network I know of today has at least > one server (in a generic sense, i.e. a distinguished machine > that is properly managed). ... Brian, My Appletalk net at home has no server. I plugged in the new printer and it simply worked. Tracy From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 04:42:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08262; Sat, 11 Jun 1994 04:42: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 EAA22274; Sat, 11 Jun 1994 04:41:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA22260; Sat, 11 Jun 1994 04:38:38 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08135; Sat, 11 Jun 1994 04:38:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00730; Fri, 10 Jun 94 14:38:26 -0400 Date: Fri, 10 Jun 94 14:38:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406101838.AA00730@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: What is "serverless autoconfiguration" ? Cc: jnc@ginger.lcs.mit.edu From: Steve Deering > The term "serverless autoconfiguration" has been bandied around a lot > recently, and I've just realised that I don't know what it means Since I coined the phrase ... I'll tell you what I meant. Feel free to invent a different term, if you find mine confusing. Agreed. It's really causing a lot of confusion and inability to communicate when everyone starts redefining terms in their heads, without making clear that they're using modified definitions. Let's keep to original meanings. I meant the method whereby a host generates a unique internet address for itself at start-up time by concatenating two parts: Just to be sure, would your definition also cover the case where you create a globally useful locator by concatenating , provided that the latter is unique on that network? This does seem to fall without your definition, I'm just unsure of exactly what would qualify as a . Noel From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 05:06:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06831; Sat, 11 Jun 1994 04:01: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 EAA22196; Sat, 11 Jun 1994 04:01:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA22180; Sat, 11 Jun 1994 03:45:57 +1000 Precedence: list Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05640; Sat, 11 Jun 1994 03:29:35 +1000 (from dkatz@cisco.com) Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA28603; Fri, 10 Jun 1994 10:29:30 -0700 Date: Fri, 10 Jun 1994 10:29:30 -0700 From: Dave Katz Message-Id: <199406101729.KAA28603@feta.cisco.com> To: dennis@ans.net Cc: Christian.Huitema@sophia.inria.fr, kre@munnari.OZ.AU, Big-Internet@munnari.OZ.AU In-Reply-To: Dennis Ferguson's message of Fri, 10 Jun 1994 11:56:35 -0400 <199406101556.AA129343@foo.ans.net> Subject: What is "serverless autoconfiguration" ? I think it's unavoidable that we sign up to do the rest of the work to make this useful. Hard-coded *anything* in the hosts (save, perhaps, the low-order part of the hostname, although even that could be done by a server) makes adminstration of large networks border on intractable. I do think it's important to separate out address assignment from other aspects of autoconfiguration, however, because of where the knowledge lies. Given that addresses (er, locators) need to have topological significance, it seems that the right place to pin the task is in the place with topological knowledge (the network infrastructure). Otherwise you have an information synchronization problem. Precedence: list Date: Fri, 10 Jun 1994 11:56:35 -0400 From: Dennis Ferguson Christian, > Serverless identification refers to the "dentist shop" problem. > If the dentist is not connected to the Internet and buys two PCs and > plugs both to an Ethernet, then the two PCs should be able > to talk IPng between themselves without any configuration. That > works with SIPP, so is probably possible. The part I am curious about is the "what next?" part. Now that the dentist has these two PCs up and running with their own self-determined addresses, what does he do with them? Not type `telnet' followed by 16 bytes worth of hex digits which he discovered by looking at his ARP cache, I hope. It seems to me that for serverless identification to be useful there needs to be an application infrastructure which supports machines which know nothing other than an address for themselves, so a machine which knows nothing but its address can do something useful. It also seems to me this may not be the Internet application infrastructure we have today. By bearing the cost of supporting serverless/configuration free identification at the network layer, are we signing up to do the rest of the work which appears to be needed to make this useful? Dennis Ferguson From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 06:05:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08469; Sat, 11 Jun 1994 04:46: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 EAA22289; Sat, 11 Jun 1994 04:46:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA22246; Sat, 11 Jun 1994 04:23:55 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07427; Sat, 11 Jun 1994 04:23:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00584; Fri, 10 Jun 94 14:23:47 -0400 Date: Fri, 10 Jun 94 14:23:47 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406101823.AA00584@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: lower 8 bits of 8+8 format Cc: jnc@ginger.lcs.mit.edu From: Masataka Ohta Actually, there are three hierarchies some of which can be merged. ... Some bits of a locator are used for local flat routing. Some bits of an EID are used for local assignment within an organization. These bits may overlap. I don't think we should try and save a few bits by having the two names in any way intermingled. Keep them totally separate. I'm very wary of having *anything* in EID's be used for routing at all (with one exception, which I'll get to). The reason is that the *whole point* of EID's is to have names *which do not depend on location at all*. I.e., you can pick the endpoint up, and move it *anywhere*, and it still uses only that exact same EID to identify that endpoint. (I know your suggestion doesn't do this, but once you start to use parts of the EID for routing, the door is open...) The one exception is that a locator might give, rather than an exact location (i.e. network interface) to deliver the packets to, an area inside which the endpoint is. If the routing inside that area tracks endpoints using "flat" routing, the packets could be delivered from there using an EID. Outside that, I think it's a really bad idea to use EID's in routing. In particular, embedding *any* topological information in EID's is an *absolute* no-no, since it breaks the portability. (Again, I know your suggestion doesn't do this, but it does put part of the locator function in the EID, which is a bad precedent.) Noel From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 06:08:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09581; Sat, 11 Jun 1994 05:22: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 FAA22340; Sat, 11 Jun 1994 05:21:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA22326; Sat, 11 Jun 1994 05:09:09 +1000 Precedence: list Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09187; Sat, 11 Jun 1994 05:09:03 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <14501(2)>; Fri, 10 Jun 1994 12:08:47 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <12171>; Fri, 10 Jun 1994 12:08:42 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, deering@parc.xerox.com Subject: Re: What is "serverless autoconfiguration" ? In-Reply-To: jnc's message of Fri, 10 Jun 94 11:38:26 -0800. <9406101838.AA00730@ginger.lcs.mit.edu> Date: Fri, 10 Jun 1994 12:08:30 PDT Sender: Steve Deering From: Steve Deering Message-Id: <94Jun10.120842pdt.12171@skylark.parc.xerox.com> > Just to be sure, would your definition also cover the case where you create a > globally useful locator by concatenating address>, provided that the latter is unique on that network? Yes. Steve From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 06:10:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09684; Sat, 11 Jun 1994 05:23: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 FAA22355; Sat, 11 Jun 1994 05:22:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA22323; Sat, 11 Jun 1994 05:06:10 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07088; Sat, 11 Jun 1994 04:11:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00496; Fri, 10 Jun 94 14:11:27 -0400 Date: Fri, 10 Jun 94 14:11:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406101811.AA00496@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: New TCP (was Re: 8+8 addressing..... Cc: jnc@ginger.lcs.mit.edu From: "Richard Carlson" I intended to define an address for the generic transport layer of a node, not caring what transport protocol was used ... So I think we are looking at 2 sides of the same coin and aren't too far apart. Yes, and exactly the same expression ("2 sides...") I'd have used. Fate-sharing entities, and the end-end principle, are two ways of looking at the same basic thing. > What's wrong with putting them below TCP, so that various different > transport protocols can all use the same mechanism? I feel that if it's in the network layer, someone will try and use it for routing purposes. Even though you didn't intend this, I think it will happen. Yes, there's no making things foolproof, is there! :-) I guess some people will always kludge things around horribly; perhaps we should just try and build something that allows people who are thinking straight to do it right. But the end stations don't need to know how the packet was routed so why include the dest IP address on the last hop? More work to take it out than leave it there... The idea of skipping the dest TA and just using it in the checksum is intriguing, I never thought of that. The problem is that without it, there's no way to allow for level 4 routing. You mean "level 4 demultiplexing", perhaps? Actually, if we take the viewpoint that in some cases (e.g. if a flow has been set up), the "selector" (whatever field the internetwork layer is looking at to forward the packet), such as the flow id, it would allow delivery to the endpoint (not just the interface). You could then drop both EID's from most packets. E.g. if you've done a flow setup, the flow should be able to deliver the packets to the right endpoint. You'd still have them included implicity (in the checksum) to catch mis-delivery errors, but you wouldn't need them otherwise. I don't expect multiple TA's, in fact that should never be allowed Yes, but it we have mobile processes which retain open connections while the move, you could have mutiple TA's on a single host. The EID is just a machine language version of the DNS name because we don't want to carry variable length DNS names around in data packets. Yes, I wish we didn't have to have the two separate but parallel naming spaces. Hmmm. (If we wanted variable length addresses then we could probably use the DNS name and skip one mapping issue altogether.) I'm not sure what you mean by "addresses" here, but DNS names aren't suitable for routign as they don't have topological significance. I still feel that getting to a node, fixed or mobile, and identifying that that node exists are 2 seperate issues and this is not true for IPv4 nodes. Yes, exactly. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 06:22:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11799; Sat, 11 Jun 1994 06:22: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 GAA22424; Sat, 11 Jun 1994 06:21:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA22421; Sat, 11 Jun 1994 06:10:45 +1000 Precedence: list Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09685; Sat, 11 Jun 1994 05:23:13 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA03619 (InterLock SMTP Gateway 1.1); Fri, 10 Jun 1994 15:22:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Fri, 10 Jun 1994 15:22:57 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 10 Jun 1994 15:22:57 -0400 Message-Id: <199406101919.AA71075@foo.ans.net> To: Dave Katz Cc: Christian.Huitema@sophia.inria.fr, kre@munnari.OZ.AU, Big-Internet@munnari.OZ.AU Subject: Re: What is "serverless autoconfiguration" ? In-Reply-To: Your message of "Fri, 10 Jun 1994 10:29:30 PDT." <199406101729.KAA28603@feta.cisco.com> Date: Fri, 10 Jun 1994 15:19:36 -0400 From: Dennis Ferguson > I think it's unavoidable that we sign up to do the rest of the work to > make this useful. Hard-coded *anything* in the hosts (save, perhaps, > the low-order part of the hostname, although even that could be done > by a server) makes adminstration of large networks border on intractable. This is indisputable, but one can't draw the conclusion that one must use an IEEE identifier to form a unique address just based on this. Is it not an alternative, for example, to have the same thing that tells you your name tell you the identifier portion of your address at the same time? I can think of arguments both ways, it just bothers me that I don't hear anyone making the arguments either way. > I do think it's important to separate out address assignment from other > aspects of autoconfiguration, however, because of where the knowledge > lies. Given that addresses (er, locators) need to have topological > significance, it seems that the right place to pin the task is in > the place with topological knowledge (the network infrastructure). > Otherwise you have an information synchronization problem. It goes without saying that the topological part of the address (is this still what you call it when the locator and identifier are squashed into the same quantity?) needs to be obtained from the thing that knows the topology, but I was talking about the other part, the part that identifies the host, either uniquely or within the context of the topology. What I'm really asking for is someone to make the argument of why it is better to obtain the identifier part from your hardware, and then tell it to the things you talk to to arrange for basic services like name resolution based on this, rather than just having the things you talk to tell you the identifer you should be using (or perhaps picking the identifer off the same spot on the disk where you store your private key, if you want the ID fixed and your computer is at a place which doesn't know your identifier). The advantage of doing it the latter way is either that you can have the same ID where ever you are in the topology and independent of what your hardware service man does you your computer so that services can use your computer's ID as part of the process of determining who you are, assuming you subscribe to the EID notion of ID's, or that your ID can be much, much smaller if you subscribe to the notion that ID's really only need to be sufficient to find your host in the context of a particular chunk of topology. Autoconfiguration of locators can be done whether you use IEEE hardware identifiers or something else. When people talk about using IEEE identifiers they just stop there, as if the solution to the rest of the problem were self-evident. It seems to me that the solution to the rest of the problem is not self-evident, and if you are going to need some outside help getting fully configured in any case (beyond the topology location which a router might know) then having that thing tell you your ID at the same time might not be a hardship. Dennis Ferguson From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 07:21:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13975; Sat, 11 Jun 1994 07:21: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 HAA22494; Sat, 11 Jun 1994 07:21:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA22480; Sat, 11 Jun 1994 07:05:20 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10676; Sat, 11 Jun 1994 05:48:39 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id MAA05061; Fri, 10 Jun 1994 12:48:14 -0700 Message-Id: <199406101948.MAA05061@Mordor.Stanford.EDU> To: Brian.Carpenter@cern.ch Cc: kre@munnari.OZ.AU (Robert Elz), Big-Internet@munnari.OZ.AU Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: What is "serverless autoconfiguration" ? Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 10 Jun 94 08:54:42 +0200. <9406100654.AA15775@dxcoms.cern.ch> Date: Fri, 10 Jun 94 12:48:13 -0700 From: Dave Crocker X-Mts: smtp ---- Included message: Every network I know of today has at least one server (in a generic sense, i.e. a distinguished machine I run an appletalk network at home and I can guarantee you that none of the machines is 'properly managed' or identifiable as a server. I believe this is quite common in a substantial class of small-group networks. small-scale, turnkey operation of TCP for entry-level environments is one of the major deficiencies in our technical repertoire. We need to let random user-pairs start networking, with the possibility of having formal servers and outside links come later. Dave From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 07:23:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14176; Sat, 11 Jun 1994 07:23: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 HAA22509; Sat, 11 Jun 1994 07:23:01 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA22477; Sat, 11 Jun 1994 07:02:45 +1000 Precedence: list From: jallard@microsoft.com Received: from netmail2.microsoft.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13303; Sat, 11 Jun 1994 07:02:27 +1000 (from jallard@microsoft.com) Received: by netmail2.microsoft.com (5.65/25-eef) id AA08217; Fri, 10 Jun 94 13:04:08 -0700 Message-Id: <9406102004.AA08217@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Fri, 10 Jun 94 13:04:08 PDT X-Msmail-Message-Id: A55A1CC4 X-Msmail-Conversation-Id: A55A1CC4 To: Big-Internet@munnari.OZ.AU, owner-Big-Internet@munnari.OZ.AU Date: Fri, 10 Jun 94 13:56:30 TZ Subject: Re: What is "serverless autoconfiguration" ? | First off, almost all networks have a server of some sort on it, | usually on the same subnet. | So lets not design for the very infrequent incounter. the dumb-client, smart-server general purpose computer network is only a small part of the ipng problem. today there are peer workgroup nets of systems on non-routed networks. these grow to be routed w/ no servers. even when a server is introduced it might not be available 24x7 to tell the "clients" (in this case peers) what they need to know to talk to each other. the more interesting devices of the future aren't even peers, but new networked "appliances" which are not general purpose computers. you can easily imagine a network of appliances which want to be controlled, polled or queried by a general purpose computer (take the diagnostic systems of your car as an example). when you go in for a checkup, some system will want to talk to a set of systems on a network. where's the server, where's the router? this is an extreme, probably unlikely example but i think you can easily see what i'm driving at and can probably project some of the advances which will be made in the next 5-10 years along these lines. you can take a handful of macs, tie them together with some phone cord and toss a printer on the wire and they can print. no server, no configuration, no complex manual addressing required. it just works. you can plug a second net card into a netware server, give it a "network identifier", and its an ipx router. you can plug 8 windows for workgroups computers together into a $300 hub w/ 10baset and they can share files with each other. these are all pretty popular networking products out in the market. these people don't want "ifconfig le0 102.14.124.32 netmask 0xffffff00 broadcast 102.14.124.255". we need simple, serverless, routerless addressing capabilities, we need simple serverless routed addressing capabilities, and we need serverful routed addressing and system configuration capabilities.. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 09:13:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15417; Sat, 11 Jun 1994 08:01: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 IAA22566; Sat, 11 Jun 1994 08:01:46 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA22552; Sat, 11 Jun 1994 07:42:39 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14753; Sat, 11 Jun 1994 07:42:32 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA13208; Fri, 10 Jun 94 14:37:43 -0700 Received: by xirtlu.zk3.dec.com; id AA11430; Fri, 10 Jun 1994 17:37:29 -0400 Message-Id: <9406102137.AA11430@xirtlu.zk3.dec.com> To: Dennis Ferguson Cc: Big-Internet@munnari.OZ.AU Subject: Re: What is "serverless autoconfiguration" ? In-Reply-To: Your message of "Fri, 10 Jun 94 15:19:36 EDT." <199406101919.AA71075@foo.ans.net> Date: Fri, 10 Jun 94 17:37:23 -0400 X-Mts: smtp As Steve B. stated if you want to put administration in an EID then IEEE addresses are out. I think they should only be used for local-use only, becaue they are not globally unqiue. Or go to IEEE 802 and fix the problem there so they are globally unique or wherever. I see no point in any EID that is not globally unique and if we want to use them without being globally unique then I withdraw all my support of the entire EID notion. It will be much harder to figure out how to use them not being globally unique, than figuring out a way to assign EIDs and design them to be globally unique IMHO. I can't figure out if the IEEE addr use is a political or technical discussion. If its political I will pass. If its technical I have heard no one refute Steve B's concerns of them being used as an EID. /jim From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 14:20:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18154; Sat, 11 Jun 1994 09:04: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 JAA22634; Sat, 11 Jun 1994 09:01:47 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA22619; Sat, 11 Jun 1994 08:43:41 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15393; Sat, 11 Jun 1994 08:00:36 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA14676; Fri, 10 Jun 94 14:58:57 -0700 Received: by xirtlu.zk3.dec.com; id AA11679; Fri, 10 Jun 1994 17:58:46 -0400 Message-Id: <9406102158.AA11679@xirtlu.zk3.dec.com> To: Big-Internet@munnari.OZ.AU Subject: Re: What is "serverless autoconfiguration" ? In-Reply-To: Your message of "Fri, 10 Jun 94 12:48:13 PDT." <199406101948.MAA05061@Mordor.Stanford.EDU> Date: Fri, 10 Jun 94 17:58:40 -0400 X-Mts: smtp One piece I would look for in this solution is that nothing in the technical strategy or architecture prevent me from building network address servers for IPng. I believe there is a market for these that do more than serve addresses too. /jim From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 15:44:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01724; Sat, 11 Jun 1994 15:44: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 PAA23037; Sat, 11 Jun 1994 15:41:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA23023; Sat, 11 Jun 1994 15:39:07 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26734; Sat, 11 Jun 1994 13:21:49 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Sat, 11 Jun 94 12:15:31 +0900 From: Masataka Ohta Message-Id: <9406110315.AA07120@necom830.cc.titech.ac.jp> Subject: Re: lower 8 bits of 8+8 format To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Sat, 11 Jun 94 12:15:29 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406101823.AA00584@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 10, 94 2:23 pm X-Mailer: ELM [version 2.3 PL11] > Actually, there are three hierarchies some of which can be merged. > ... Some bits of a locator are used for local flat routing. Some bits > of an EID are used for local assignment within an organization. These > bits may overlap. > > I don't think we should try and save a few bits by having the two names in any > way intermingled. Keep them totally separate. > I'm very wary of having > *anything* in EID's be used for routing at all (with one exception, which I'll > get to). > > The reason is that the *whole point* of EID's is to have names *which do not > depend on location at all*. Agreed. So, if some part of EID is used for locator, it is only for FLAT routing at the lowest routing level. > I.e., you can pick the endpoint up, and move it > *anywhere*, and it still uses only that exact same EID to identify that > endpoint. (I know your suggestion doesn't do this, Yes, if the endpoint is moved to different routing domain, upper level identifiers in locator, which share nothing with EID, will be used. > but once you start to use > parts of the EID for routing, the door is open...) The easiest way to shut the door is not to develop any routing protocol which divide the part of locator shared with EID into several layers. I believe IESG can enforce so. > The one exception is that a locator might give, rather than an exact location > (i.e. network interface) to deliver the packets to, an area inside which the > endpoint is. If the routing inside that area tracks endpoints using "flat" > routing, the packets could be delivered from there using an EID. If routing is layered into several levels, are there any reason not to use FLAT routing, but to do layered routing within a single level? > Outside that, I think it's a really bad idea to use EID's in routing. In > particular, embedding *any* topological information in EID's is an *absolute* > no-no, since it breaks the portability. (Again, I know your suggestion doesn't > do this, but it does put part of the locator function in the EID, which is > a bad precedent.) I know the real world that many people believes domain names (not those under in-addr.arpa.) should have some relationship to IP addresses or geographical locations. Thus, as long as EID has layers for unique assigment and delegation, the same misunderstanding will be common. For example, people (or even some EID assignment authority) tend to believe that all the equipment used in Japan should have EID issued by a Japanese authority, just because EID is layered. So, we can't stop some organization wrongly have internal assignment policy to relate EID and location. The expected misunderstanding has nothing to do with sharing information between EIDs and locators. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Sat Jun 11 18:44:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06884; Sat, 11 Jun 1994 18:42: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 SAA23200; Sat, 11 Jun 1994 18:41:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA23186; Sat, 11 Jun 1994 18:26:53 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06298; Sat, 11 Jun 1994 18:19:15 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA19522; Sat, 11 Jun 1994 01:19:11 -0700 Date: Sat, 11 Jun 1994 01:19:11 -0700 From: Tony Li Message-Id: <199406110819.BAA19522@lager.cisco.com> To: big-internet@munnari.OZ.AU Cc: SIPP Mailing list , tuba@Lanl.GOV, tli@cisco.com, yakov@watson.ibm.com Reply-To: big-internet@munnari.OZ.AU, tli@cisco.com, yakov@watson.ibm.com Subject: BigTen addressing drafts [Apologies if this is a duplicate. This is a retry.] Folks, As part of the IPng Directorate meeting May 19 & 20 in Chicago, the Directorate and its guests had a general discussion of alternative designs. Discussion focused around a hypothetical proposal which, for the lack of a better name, we call BigTen, after the conference center where the meeting was held. One of the more interesting features about BigTen is that it does use variable length addresses in a way unlike any of the current proposals. Subsequent to the meeting, Yakov and I were asked by the area directors to look into an addressing architecture and plan for such addresses. These documents are now available as Internet drafts: draft-rekhter-bigten-addr-arch-00.txt draft-li-bigten-addr-format-00.txt Please note that these are CRUDE first drafts subject to major revisions. For example, it's not clear if the length bits should have routing significance. Please direct any comments to Yakov and myself. Public discussion should occur on the big-internet mailing list. Thanks, Tony From owner-Big-Internet@munnari.OZ.AU Mon Jun 13 17:54:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24484; Mon, 13 Jun 1994 17:04: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 RAA25446; Mon, 13 Jun 1994 17:02:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA25432; Mon, 13 Jun 1994 16:46:09 +1000 Precedence: list Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22383; Mon, 13 Jun 1994 15:58:24 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA27877 (5.65c/IDA-1.4.4nsd for ); Sun, 12 Jun 1994 22:58:13 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA06181 (5.65c/IDA-1.4.4-910725 for ); Sun, 12 Jun 1994 22:58:09 -0700 Message-Id: <199406130558.AA06181@remmel.NSD.3Com.COM> To: big-internet@munnari.OZ.AU Subject: [tracym@NSD.3Com.COM: Re: Merging Routing Header ] Date: Sun, 12 Jun 94 22:58:08 -0700 From: tracym@NSD.3Com.COM Please forgive the cross-posting. I just sent this to SIPP, so some folks will get two copies, but others will get one who otherwise would not have seen the message. If the idea is not at all new, then please send a quick note to both lists to stifle unnecessary traffic. Thanks, Tracy ------- Forwarded Message Folks, The discussion of source routing has brought to the surface an idea that's been stewing for some time. It's always bothered me that routers at intermediate hops in source routes are burdened with two lookups: the first to recognize their own address, and a second to route based on the next hop after it's been extracted. This may be peculiar to IPv4 routing, and in the process of going away, but I'd like to suggest a different approach, at least for loose source routing, that would seem to improve things. The idea is that the source route should be advanced by a router when it chooses a directly connected next hop. This would eliminate the dual look-ups required by standard practise. The addressed next hop wouldn't see it's own address, but for loose source routing this should not be a problem. We could do this today. If the next hop is a full host address (as with IPv4 today) then it would be nice to actually know that the address is a neighbor router. On the other hand, if the next hop is simply a prefix that helps select a route (this could be done with IPv4, but I expect it will be done for IPng) then this definition makes perfect sense. Regards, Tracy [Usual disclaimer: I should be doing other work, so others will have to follow this up if it makes any sense.] ------- End of Forwarded Message From owner-Big-Internet@munnari.OZ.AU Mon Jun 13 19:27:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27179; Mon, 13 Jun 1994 18:43: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 SAA25550; Mon, 13 Jun 1994 18:42:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA25536; Mon, 13 Jun 1994 18:29:28 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26878; Mon, 13 Jun 1994 18:29:18 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA09621; Mon, 13 Jun 1994 10:29:35 +0200 Message-Id: <199406130829.AA09621@mitsou.inria.fr> To: Dennis Ferguson Cc: Big-Internet@munnari.OZ.AU Subject: Re: What is "serverless autoconfiguration" ? In-Reply-To: Your message of "Fri, 10 Jun 1994 15:19:36 EDT." <199406101919.AA71075@foo.ans.net> Date: Mon, 13 Jun 1994 10:29:34 +0200 From: Christian Huitema Dennis, I sure agree that serverless address configuration is only a part of the general problem, though a very important one. There are other parts which are important, notably resource discovery. The "need a name" problem which you mention should indeed be addressed though (1) it is hardly IPng related and (2) users are a lot more confortable baptizing their station than assigning it an address. Then, there is also the case that a number of resource discovery problems can be solved inside the application by use of multicast exchanges - in fact, name server is an alternative to multicasting. Multicasting queries and fetching records from a name server are two solutions to the same problem. One minimizes manager's time and is well tuned to the "local area" environment; the other minimizes use of long haul network resources. In fact, the whole point of resource discovery is to establish an intelligent mix of the two - see "archie" as an example of a solution. But then, maybe we don't need to rearchitecture the DNS the same day we switch to IPng, right? Christian Huitema From owner-Big-Internet@munnari.OZ.AU Mon Jun 13 19:43:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28819; Mon, 13 Jun 1994 19:43: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 TAA25636; Mon, 13 Jun 1994 19:42:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA25603; Mon, 13 Jun 1994 19:27:53 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27670; Mon, 13 Jun 1994 18:58:18 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA19215; Mon, 13 Jun 1994 10:58:13 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA01424; Mon, 13 Jun 1994 10:58:11 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406130858.AA01424@dxcoms.cern.ch> Subject: Re: What is "serverless autoconfiguration" ? To: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Date: Mon, 13 Jun 1994 10:58:11 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU (bigi) In-Reply-To: <199406101948.MAA05061@Mordor.Stanford.EDU> from "Dave Crocker" at Jun 10, 94 12:48:13 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1636 Dave (and Tracy who made the same point), Of course. But as anyone who has run a large AppleTalk environment will tell you, beyond a certain size plug-and-play turns into plug-and-pray, i.e. the algorithms don't scale. If I want to be picky I could argue that a two-node AppleTalk is not serverless, but that all the nodes behave as servers (they respond to multicast polls looking for services, of which the most basic is "is anyone using this address that I would like to use?"). I agree however that there is a role for very small self-configuring systems. The point is that the algorithms normally used for this are broken above a certain size of network, which is where my line of argument comes in. How do we ensure that allowing plug&play at the bottom end does not create horrendous scaling problems? How do we ensure that it does not create problems when plug&play networks later connect to the Internet? Brian >--------- Text sent by Dave Crocker follows: > > > ---- Included message: > > Every network I know of today has at least > one server (in a generic sense, i.e. a distinguished machine > > I run an appletalk network at home and I can guarantee you that none > of the machines is 'properly managed' or identifiable as a server. > I believe this is quite common in a substantial class of small-group > networks. > > small-scale, turnkey operation of TCP for entry-level environments is > one of the major deficiencies in our technical repertoire. We need to > let random user-pairs start networking, with the possibility of having > formal servers and outside links come later. > > Dave > From owner-Big-Internet@munnari.OZ.AU Tue Jun 14 02:03:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05301; Mon, 13 Jun 1994 23:44: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 XAA25848; Mon, 13 Jun 1994 23:42:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA25834; Mon, 13 Jun 1994 23:31:11 +1000 Precedence: list Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04241; Mon, 13 Jun 1994 23:14:50 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA17368 (5.65c/IDA-1.4.4nsd for ); Mon, 13 Jun 1994 06:14:45 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA06973 (5.65c/IDA-1.4.4-910725 for ); Mon, 13 Jun 1994 06:14:42 -0700 Message-Id: <199406131314.AA06973@remmel.NSD.3Com.COM> To: big-internet@munnari.OZ.AU (bigi) Subject: Re: What is "serverless autoconfiguration" ? In-Reply-To: Your message of "Mon, 13 Jun 94 10:58:11 +0200." <9406130858.AA01424@dxcoms.cern.ch> Date: Mon, 13 Jun 94 06:14:42 -0700 From: tracym@NSD.3Com.COM >I agree however that there is a role for very small self-configuring >systems. The point is that the algorithms normally used for this >are broken above a certain size of network, which is where my >line of argument comes in. How do we ensure that allowing plug&play >at the bottom end does not create horrendous scaling problems? >How do we ensure that it does not create problems when plug&play >networks later connect to the Internet? Brian, When you say it this way, there is no argument whatsoever, and we can write it into the charter for this effort. Perhaps our only difference of opinion is that you are worried that we can't have it both ways, and I am more of an optimist. Your concern is based in experience with existing implementations that don't scale. I would agree that the greater public good requires that non-conformers need to toe-the-line, which may require serverless nets to become serverfull when they join the rest of the world(or even just the rest of the building/campus;-). Tracy From owner-Big-Internet@munnari.OZ.AU Tue Jun 14 13:43:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07174; Tue, 14 Jun 1994 13:43: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 NAA26571; Tue, 14 Jun 1994 13:43:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA26557; Tue, 14 Jun 1994 13:34:39 +1000 Precedence: list Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06722; Tue, 14 Jun 1994 13:34:33 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa20426; 13 Jun 94 23:34 EDT To: "Robert G. Moskowitz" <0003858921@mcimail.com> Cc: big Internet Subject: Re: dotted notation considered awkward In-Reply-To: Your message of Wed, 08 Jun 1994 06:06:00 -0500. <03940608110630/0003858921NA3EM@mcimail.com> Date: Mon, 13 Jun 1994 23:34:14 -0400 From: John Curran Message-Id: <9406132334.aa20426@nic.near.net> -------- ] From: "Robert G. Moskowitz" <0003858921@mcimail.com> ] Subject: Re: dotted notation considered awkward ] Date: Wed, 8 Jun 94 06:06 EST ] ... ] For IPv4, a better human representation would have been the tuple format of ] (net, subnet, host) so that an address of 129.9.247.247 with a mask of ] 255.255.255.128 would have been (129.9, 496, 118) with a mask of (255.255, ] 512, 0). ] ] I can more easily explain tuples to people than the current notation! ] ] Also this format makes it clearer about the RFC 1122 limitation that subnet ] and host cannot have values of 0 or -1! We would have avoided that disaster ] last year! FYI, the RFC1122 tuples are now semantically null with the advancement of CIDR since the tuple definition requires the ability to distinguish a network/subnet boundary which no longer exists. /John From owner-Big-Internet@munnari.OZ.AU Tue Jun 14 15:18:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04930; Tue, 14 Jun 1994 12:44: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 MAA26502; Tue, 14 Jun 1994 12:43:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA26499; Tue, 14 Jun 1994 12:40:12 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27511; Tue, 14 Jun 1994 09:35:05 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA02061; Mon, 13 Jun 94 17:33:02 MDT Received: from [130.57.64.147] by WC.Novell.COM (4.1/SMI-4.1) id AA17919; Mon, 13 Jun 94 16:29:57 PDT Date: Mon, 13 Jun 94 16:29:56 PDT Message-Id: <9406132329.AA17919@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Greg Minshall Subject: Re: New TCP (was Re: 8+8 addressing..... Cc: big-internet@munnari.OZ.AU Noel, et al, You will take this with some salt grains, given my feeling that "EID" doesn't have a crisp enough definition in the community at large to make it a useful concept at present. However, >I realize that names aren't critical, but they may denote an important >difference in thinking. EID stands for "endpoint ID", where an endpoint is the >basic actor of reliable end-end communication; i.e. it's a name for a single >entity (such as a garden variety host). This would be a significant difference >from a transport level name which is local to that particular transport level. I think that a Steve Deering comment (or my interpretation thereof) applies here: the question is naming/addressing/whatever the space in which various "names" are to be interpreted. So, the "protocol type" field in an IPv4 packet identifies one of a number of instances of TCP (say) engines. The protocol type field, coupled with a specific IPv4 address, identifies *exactly one* TCP engine. Having identified a specific TCP engine you are, of course, then in a position to interpret the next layer of names: port numbers. >If the routers don't make decisions based on the TA's, then there's no need to >put the destination TA in every packet, unless you expect multiple TA's on the >same host. (I.e. you can't disambiguate packets based on the src/dest port and >src TA alone...) Sure, you include it in the checksum, to make sure the packet >was destined for this TA, but you don't need to actually ship the dest TA bits >over the wire. They are of no value in fault detection, and since I doubt >anyone's actually going to look at packets which fail the TCP checksum, there's >no other use for them. For network management purposes (not necessarily SNMP, just the grungy job of trying to track down network problems and fix them), being able to checksum "isolated" TCP packets is very valuable. I'd hate to see us break that. Greg From owner-Big-Internet@munnari.OZ.AU Tue Jun 14 16:01:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08609; Tue, 14 Jun 1994 14:26: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 OAA26615; Tue, 14 Jun 1994 14:23:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA26599; Tue, 14 Jun 1994 14:06:41 +1000 Precedence: list Received: from brolga.cc.uq.oz.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07909; Tue, 14 Jun 1994 14:06:38 +1000 (from G.Michaelson@cc.uq.oz.au) Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Tue, 14 Jun 1994 14:05:07 +1000 To: John Curran Cc: "Robert G. Moskowitz" <0003858921@mcimail.com>, big Internet Subject: Re: dotted notation considered awkward In-Reply-To: Your message of "Mon, 13 Jun 1994 23:34:14 -0400." <9406132334.aa20426@nic.near.net> X-Mailer: exmh version 1.4epsilon+ 6/7/94 Date: Tue, 14 Jun 1994 14:05:01 +1000 Message-Id: <22219.771566701@brolga.cc.uq.oz.au> From: George Michaelson From owner-Big-Internet@munnari.OZ.AU Tue Jun 14 16:03:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12784; Tue, 14 Jun 1994 16:03: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 QAA26738; Tue, 14 Jun 1994 16:03:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA26732; Tue, 14 Jun 1994 15:55:37 +1000 Precedence: list Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08219; Tue, 14 Jun 1994 14:14:08 +1000 (from dkatz@cisco.com) Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id VAA25542; Mon, 13 Jun 1994 21:13:46 -0700 Date: Mon, 13 Jun 1994 21:13:46 -0700 From: Dave Katz Message-Id: <199406140413.VAA25542@feta.cisco.com> To: jcurran@nic.near.net Cc: Big-Internet@munnari.OZ.AU In-Reply-To: John Curran's message of Mon, 13 Jun 1994 23:43:36 -0400 <9406132343.aa20983@nic.near.net> Subject: What is "serverless autoconfiguration" ? That was my (perhaps naive) assumption. Date: Mon, 13 Jun 1994 23:43:36 -0400 From: John Curran -------- ] From: Dave Katz ] Subject: What is "serverless autoconfiguration" ? ] Date: Fri, 10 Jun 1994 10:29:30 -0700 ] ... ] I do think it's important to separate out address assignment from other ] aspects of autoconfiguration, however, because of where the knowledge ] lies. Given that addresses (er, locators) need to have topological ] significance, it seems that the right place to pin the task is in ] the place with topological knowledge (the network infrastructure). ] Otherwise you have an information synchronization problem. By having the network infrastructure provide locator prefix assignment, you greatly improve the probability of meaningful aggregation. I'm all for such autoconfiguration, but don't actually believe you've avoided an information synchronization problem _unless_ you also require the hosts to perform autoregistration in the DNS infrastructure using whatever credentials they've been provided. /John From owner-Big-Internet@munnari.OZ.AU Tue Jun 14 16:56:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11979; Tue, 14 Jun 1994 15:44: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 PAA26705; Tue, 14 Jun 1994 15:43:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA26691; Tue, 14 Jun 1994 15:30:33 +1000 Precedence: list Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07180; Tue, 14 Jun 1994 13:43:54 +1000 (from jcurran@nic.near.net) Received: from nic.near.net by nic.near.net id aa20983; 13 Jun 94 23:43 EDT To: Dave Katz Cc: Big-Internet@munnari.OZ.AU Subject: Re: What is "serverless autoconfiguration" ? In-Reply-To: Your message of Fri, 10 Jun 1994 10:29:30 -0700. <199406101729.KAA28603@feta.cisco.com> Date: Mon, 13 Jun 1994 23:43:36 -0400 From: John Curran Message-Id: <9406132343.aa20983@nic.near.net> -------- ] From: Dave Katz ] Subject: What is "serverless autoconfiguration" ? ] Date: Fri, 10 Jun 1994 10:29:30 -0700 ] ... ] I do think it's important to separate out address assignment from other ] aspects of autoconfiguration, however, because of where the knowledge ] lies. Given that addresses (er, locators) need to have topological ] significance, it seems that the right place to pin the task is in ] the place with topological knowledge (the network infrastructure). ] Otherwise you have an information synchronization problem. By having the network infrastructure provide locator prefix assignment, you greatly improve the probability of meaningful aggregation. I'm all for such autoconfiguration, but don't actually believe you've avoided an information synchronization problem _unless_ you also require the hosts to perform autoregistration in the DNS infrastructure using whatever credentials they've been provided. /John From owner-Big-Internet@munnari.OZ.AU Tue Jun 14 16:56:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12918; Tue, 14 Jun 1994 16:06: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 QAA26755; Tue, 14 Jun 1994 16:06:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA26735; Tue, 14 Jun 1994 15:56:45 +1000 Precedence: list Received: from brolga.cc.uq.oz.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08200; Tue, 14 Jun 1994 14:13:20 +1000 (from G.Michaelson@cc.uq.oz.au) Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Tue, 14 Jun 1994 14:12:25 +1000 To: John Curran Cc: "Robert G. Moskowitz" <0003858921@mcimail.com>, big Internet Subject: Re: dotted notation considered awkward In-Reply-To: Your message of "Mon, 13 Jun 1994 23:34:14 -0400." <9406132334.aa20426@nic.near.net> X-Mailer: exmh version 1.4epsilon+ 6/7/94 Date: Tue, 14 Jun 1994 14:12:17 +1000 Message-Id: <22430.771567137@brolga.cc.uq.oz.au> From: George Michaelson [sorry about null message, in case kre doesn't remove it] Please don't get side-tracked into changing the address notation. You don't need this. Dotted quad is as workable as any other scheme, and has the advantage that the vast majority of the network-active userbase understand it. If ipng is going to leverage off existing deployed code, then this kind of shift just adds to the port work, to not much benefit. I dont think the benefits of making it non-standard (discovering how many places its hardwired into the code for instance) outweigh the problems. Having had one box on campus (unisys "mainframe-class") that assumed a non-standard notation for dotted quad (comma instead of fullstop) I can assure you, nobody wants to have more than one notation for addresses even if the address structure/content/size has changed. Its just not true to say users only have to see DNS form domain-names, the IP address itself is amazingly pervasive. Its already confusing enough having to deal with NSAPs, IPX, MAC-level and other addresses without a new notation for a motherhooded old value... If you dislike dotted quad so much, write a suite of translation routines to map it to and from your preferred tupleform, and port to every machine known to personkind. -George From owner-Big-Internet@munnari.OZ.AU Tue Jun 14 20:26:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22429; Tue, 14 Jun 1994 20:26: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 UAA26985; Tue, 14 Jun 1994 20:23:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA26982; Tue, 14 Jun 1994 20:17:47 +1000 Precedence: list Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22100; Tue, 14 Jun 1994 20:17:22 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA05037; Tue, 14 Jun 94 06:16:34 EDT Message-Id: <9406141016.AA05037@tipper.oit.unc.edu> To: George Michaelson Cc: John Curran , "Robert G. Moskowitz" <0003858921@mcimail.com>, big Internet Subject: Re: dotted notation considered awkward In-Reply-To: Your message of "Tue, 14 Jun 94 14:12:17 +1000." <22430.771567137@brolga.cc.uq.oz.au> Date: Tue, 14 Jun 94 06:16:33 -0400 From: Simon E Spero >>>>> "George" == George Michaelson writes: George> Dotted quad is as workable as any other scheme, and has George> the advantage that the vast majority of the network-active George> userbase understand it. Would't we have to use dotted octets instead? Simon From owner-Big-Internet@munnari.OZ.AU Tue Jun 14 22:35:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23040; Tue, 14 Jun 1994 20:43: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 UAA27021; Tue, 14 Jun 1994 20:43:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA27001; Tue, 14 Jun 1994 20:25:55 +1000 Precedence: list Received: from brolga.cc.uq.oz.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22419; Tue, 14 Jun 1994 20:25:50 +1000 (from G.Michaelson@cc.uq.oz.au) Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Tue, 14 Jun 1994 20:25:12 +1000 To: Simon E Spero Cc: John Curran , "Robert G. Moskowitz" <0003858921@mcimail.com>, big Internet Subject: Re: dotted notation considered awkward In-Reply-To: Your message of "Tue, 14 Jun 1994 06:16:33 -0400." <9406141016.AA05037@tipper.oit.unc.edu> Date: Tue, 14 Jun 1994 20:25:08 +1000 Message-Id: <1845.771589508@brolga.cc.uq.oz.au> From: George Michaelson >>>>> "George" == George Michaelson writes: George> Dotted quad is as workable as any other scheme, and has George> the advantage that the vast majority of the network-active George> userbase understand it. Would't we have to use dotted octets instead? Yes, dotted octets is more accurately what will be used, and all the myriad gethost...() calls and related usages will have to have drop-in replacements that can cope with forseeable variants of address. Likewise ifconfig which handles at least 2 notations for netmask and broadcast (0xfffff strings as well) But this means incremental change to existing expectations. I'm not saying a clean break doesn't have advantages, I just doubt its relevant at this stage. Consider the success so far in X.400 O/R name representation inside RFC-822 and how much simpler life would be if the mapping function supported @rhs legal encodings of /O=Sales & Marketing/.../ sequences... -George From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 05:54:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08640; Wed, 15 Jun 1994 04: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 EAA27490; Wed, 15 Jun 1994 04:43:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA27476; Wed, 15 Jun 1994 04:38:58 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05148; Wed, 15 Jun 1994 03:17:29 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Sun.COM by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA02342 Wed, 15 Jun 1994 03:17:24 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM ([129.144.1.38]) by Sun.COM (sun-barr.Sun.COM) id AA22890; Tue, 14 Jun 94 10:13:33 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AB04569; Tue, 14 Jun 94 10:12:52 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA02659; Tue, 14 Jun 1994 10:11:01 -0700 Date: Tue, 14 Jun 1994 10:11:01 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406141711.AA02659@jurassic.Eng.Sun.COM> To: big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM Subject: Updated SIPP Mosaic Pages The SIPP Mosaic pages have been updated. They can be found in the "New and Trendy Protocols" section of: http://town.hall.org/ The biggest change was made to the SIPP implementation section. New SIPP implementations are being done on HP-UX, NetBSD, and SunOS. I think there are now SIPP implementions being developed on most major host operating systems. Bob From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 05:55:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08851; Wed, 15 Jun 1994 04:47: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 EAA27505; Wed, 15 Jun 1994 04:47:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA27473; Wed, 15 Jun 1994 04:35:16 +1000 Precedence: list Received: from mailer.jhuapl.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08397; Wed, 15 Jun 1994 04:35:08 +1000 (from greenebr@aplcomm.jhuapl.edu) Received: from aplcomm.jhuapl.edu by mailer.jhuapl.edu (5.65/DEC-Ultrix/4.3) id AA14280; Tue, 14 Jun 1994 14:35:04 -0400 Received: from matrix.jhuapl.edu (bix-brg-mac.jhuapl.edu) by aplcomm.jhuapl.edu (5.0/SMI-SVR4) id AA13222; Tue, 14 Jun 1994 14:35:09 +0500 X-Mailer: InterCon TCP/Connect II 1.2 Message-Id: <9406141438.AA22834@matrix.jhuapl.edu> Date: Tue, 14 Jun 1994 14:38:22 -0500 From: Barry Raveendran Greene To: big-internet@munnari.OZ.AU Subject: Plase change E-mail address to big-internet Content-Length: 517 Hello, Please remove greenebr@aplcomm.jhuapl.edu from the big-internet list. Replace this address is this new address: barry@merlion.sing.net.sg Thanks, ===================================================================== Barry Raveendran Greene Internet: greenebr@aplcomm.jhuapl.edu Network Engineer (301) 953-6064 (301) 953-5727 FAX Johns Hopkins University / Applied Physics Lab ===================================================================== From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 13:02:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25408; Wed, 15 Jun 1994 12:23: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 MAA27904; Wed, 15 Jun 1994 12:23:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA27901; Wed, 15 Jun 1994 12:22:31 +1000 Precedence: list Received: from sundance.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22428; Wed, 15 Jun 1994 11:14:19 +1000 (from atkinson@sundance.itd.nrl.navy.mil) From: Ran Atkinson Message-Id: <9406142113.ZM2807@sundance.itd.nrl.navy.mil> Date: Tue, 14 Jun 1994 21:13:38 -0500 Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: big-Internet@munnari.OZ.AU Subject: variable length addresses Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil Whatever one might think about Bill's straw poll, the followup comments from several previously non-vocal router implementers are significant. The vast majority of those who spoke up on big-Internet clearly favoured fixed length addresses. Understanding that individuals speak for themselves and not their employers, the noteworthy fact is the amount of collective router implementation experience that prefers fixed length addresses. 2^^128 is A Whole Lot of address space. I was (and am) of the politically incorrect view that 2^^64 is enough if one doesn't immediately spend 48 bits for a flat system identifier portion of the address. If one does spend 48 bits that way but moves to a 16 byte fixed length address, then one still has 10 bytes/20 nibbles/80 bits of space for heirarchy. I suggest that IPng use hexadecimal notation in its human readable form so that nibble subnet boundaries are easier on us humans. I will then claim there are about 10-20 levels of heirarchy available to make routing easier and more efficient. This is not an unlimited number but I really think it is enough. I think there is some convergence of some parts of the community here. I just hope it isn't polarisation. Ran atkinson@itd.nrl.navy.mil as he reaches for his asbestos... :-) From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 13:23:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27738; Wed, 15 Jun 1994 13:23: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 NAA27973; Wed, 15 Jun 1994 13:23:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA27970; Wed, 15 Jun 1994 13:16:37 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27487; Wed, 15 Jun 1994 13:16:27 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25389; Tue, 14 Jun 94 23:14:22 -0400 Date: Tue, 14 Jun 94 23:14:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406150314.AA25389@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: Ran Atkinson the followup comments from several previously non-vocal router implementers are significant. The vast majority of those who spoke up on big-Internet clearly favoured fixed length addresses. ... the noteworthy fact is the amount of collective router implementation experience that prefers fixed length addresses. Stop trying to manufacture a non-existent consensus. My impression is that both sides have a large number of proponents. I see no rough consensus here. As an aside, most of the people I think of as doing well in the business of selling routers for money i) want variable length , and ii) say they can build boxes that will forward them as fast as fixed length. I just hope it isn't polarisation. Well, I dunno. I think there are people who have their feet sufficiently sunk in concrete that they just aren't goin to change their minds, no matter how good a rational engineering argument is placed in front of them. I don't think this counts. If a choice is forced, there would more likely be some very upset people. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 14:03:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29462; Wed, 15 Jun 1994 14:03: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 OAA28028; Wed, 15 Jun 1994 14:03:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA28025; Wed, 15 Jun 1994 14:00:38 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29199; Wed, 15 Jun 1994 14:00:32 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id VAA23114; Tue, 14 Jun 1994 21:00:17 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 14 Jun 1994 21:00:20 -0700 To: atkinson@itd.nrl.navy.mil From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: variable length addresses Cc: big-Internet@munnari.OZ.AU > I suggest that IPng use hexadecimal notation >in its human readable form so that nibble subnet boundaries are easier At last! A really DIFFICULT topic to debate! In fact, I haven't ever seen a proposal that had pleasant human factors. Ran's observation about predictability of boundaries is important, but we still are left with a bloody long string. Also, I think most people do hex badly. Mostly, we seem to need decimal. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 16:20:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02168; Wed, 15 Jun 1994 15:03: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 PAA28097; Wed, 15 Jun 1994 15:03:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA28083; Wed, 15 Jun 1994 14:51:06 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01657; Wed, 15 Jun 1994 14:51:01 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA16612; Tue, 14 Jun 94 21:46:28 -0700 Received: by xirtlu.zk3.dec.com; id AA16413; Wed, 15 Jun 1994 00:46:25 -0400 Message-Id: <9406150446.AA16413@xirtlu.zk3.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Tue, 14 Jun 94 23:14:22 EDT." <9406150314.AA25389@ginger.lcs.mit.edu> Date: Wed, 15 Jun 94 00:46:18 -0400 X-Mts: smtp => the followup comments from several previously non-vocal router => implementers are significant. The vast majority of those who spoke up on => big-Internet clearly favoured fixed length addresses. ... the noteworthy => fact is the amount of collective router implementation experience that => prefers fixed length addresses. >Stop trying to manufacture a non-existent consensus. My impression is that >both sides have a large number of proponents. I see no rough consensus here. Ran wasn't. I saw no words in Ran's memo that had the word or alluded to consensus. Ran stated what happened thats all. Thats all I read into his message as my input to Big-I and believe it was valid. Not consensus as a statement of fact. >As an aside, most of the people I think of as doing well in the business of >selling routers for money i) want variable length , and ii) say >they can build boxes that will forward them as fast as fixed length. Please sustantiate this with names of vendors and who stated what when and on what mail list. We just went through this on SIPP. Why not just talk about the technical issues and not just from an architecuture level but also from an engineering implemenmtation level too where costs and econmics are real factors in decision making. Big-I that has not seen it also needs to see Bob Hindens mail which provided another view to this entire subject. > I just hope it isn't polarisation. >Well, I dunno. I think there are people who have their feet sufficiently sunk >in concrete that they just aren't goin to change their minds, no matter how >good a rational engineering argument is placed in front of them. I don't think >this counts. If a choice is forced, there would more likely be some very upset >people. I hope this can be avoided sincerely. /jim From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 17:39:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05488; Wed, 15 Jun 1994 16:23: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 QAA28176; Wed, 15 Jun 1994 16:23:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA28173; Wed, 15 Jun 1994 16:20:28 +1000 Precedence: list Received: from netmail2.microsoft.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02437; Wed, 15 Jun 1994 15:09:20 +1000 (from jallard@microsoft.com) Received: by netmail2.microsoft.com (5.65/25-eef) id AA14478; Tue, 14 Jun 94 21:10:42 -0700 Message-Id: <9406150410.AA14478@netmail2.microsoft.com> Received: by netmail2 using fxenixd 1.0 Tue, 14 Jun 94 21:10:42 PDT X-Msmail-Message-Id: A363BA29 X-Msmail-Conversation-Id: A363BA29 From: "James 'J' Allard" To: atkinson@itd.nrl.navy.mil, owner-Big-Internet@munnari.OZ.AU Date: Tue, 14 Jun 94 22:04:28 TZ Subject: Re: variable length addresses Cc: big-Internet@munnari.OZ.AU | > I suggest that IPng use hexadecimal notation | >in its human readable form so that nibble subnet boundaries are easier | | At last! A really DIFFICULT topic to debate! | | In fact, I haven't ever seen a proposal that had pleasant human factors. | Ran's observation about predictability of boundaries is important, but we | still are left with a bloody long string. Also, I think most people do hex | badly. Mostly, we seem to need decimal. although the ops folks reading sniffer traces and configuring router filters will want some "standard notation", i don't see the big problem here. autoconfigure, autoconfigure, then do it some more. why more than .001% of ipng users will be exposed to addresses, i do not know. if this is an accurate assumption, then why waste the energy? hex is fine, dotted dec is fine, but we potentially lose granularity to convenience as we have w/ ipv4. ask 100 netware "experts" what an ipx address looks like, or how many bytes a network id is. 90+ will draw complete blanks. ask 100 users, 100 will draw blanks. let's straighten out the serverless/serverful autoconfiguration and dynamic dns registration problems and worry abt "dns name addresses" since this is the only thing that users and admins should be exposed to (generally speaking). the fact that thousands of users recognize dotted decimal or know something abt ipv4 address classes today is offensive. let's hide this convenient netlayer/routing address to the implementors and conveniently forget to document or display these warts on the end-systems. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 18:18:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08706; Wed, 15 Jun 1994 17:43: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 RAA28266; Wed, 15 Jun 1994 17:43:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA28263; Wed, 15 Jun 1994 17:42:39 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06566; Wed, 15 Jun 1994 16:45:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26457; Wed, 15 Jun 94 02:45:29 -0400 Date: Wed, 15 Jun 94 02:45:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406150645.AA26457@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: bound@zk3.dec.com >> The vast majority of those who spoke up on big-Internet clearly >> favoured fixed length addresses. > Stop trying to manufacture a non-existent consensus. ... I see no rough > consensus here. Ran wasn't. I saw no words in Ran's memo that had the word or alluded to consensus. Ran stated what happened thats all. ... Not consensus as a statement of fact. I dunno, maybe I'm way confused, but to me "vast majority" seems to be with a stone's throw of "rough consensus". The sentence I clipped is also couched in the form of a statement of fact. > As an aside, most of the people I think of as doing well in the business > of selling routers for money i) want variable length Please sustantiate this with names of vendors and who stated what when and on what mail list. Sigh. OK, I went back and looked at every instance of the word "fixed" in all mail to Big-Internet since mid-May. First, Bill Simpson's original message (Ran referred to "Whatever one might think about Bill's straw poll") asked if people thought we could live with fixed length *EID's* (and explicitly put off discussion of the issue of fixed length locators). Second, most of the discussion since then has been about EID's, not addresses (or locators). They are very different things (and I'm sure Ran knows the difference). His statement above, however, referred to "addresses". Since the discussion I found wasn't *about* addresses, I'm not really able to draw any conclusions about recently expressed feelings about fixed-length addresses. As for router vendors who probably think fixed-length addresses are wrong, you could try Tony Li (from Cisco) for a start. [I'd name Dave Katz (Cisco) and Ross Callon (Wellfleet) as well, but they'd undoubtly be dismissed as just Tuba backers.) Why not just talk about the technical issues Fine with me. Can we just drop this whole line? and not just from an architecuture level but also from an engineering implemenmtation level too where costs and econmics are real factors in decision making. Oh, you mean like the costs and economics of this whole IPng thing, which we are now stuck with since somebody picked a fixed size address for IPv4 that "was sure to be big enough" (or words to that effect)? What's doubly ironic is that this whole argument (about fixed versus variable) happened then too. "Those who forget history are doomed to repeat it." >> I just hope it isn't polarisation. > I think there are people who have their feet sufficiently sunk in > concrete that they just aren't goin to change their minds, no matter how > good a rational engineering argument is placed in front of them. ... If > a choice is forced, there would more likely be some very upset >people. I hope this can be avoided sincerely. Well, I dunno. I remember a question being asked about what people would do in a given procedural cirumstance (if none of the existing IPng candidates were picked), and at least one person send in a reply of the form "I'd probably quit". I'm actually quite sympathetic to his position (although I disagree with this person technically). I mean, if you really, truly, think something is that absolutely wrong thing to do, this reaction can be the appropriate one. Perhaps this (quitting on a matterof deep principle) is the attitude of a bygone age, though... Noel From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 18:20:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09562; Wed, 15 Jun 1994 18:09: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 SAA28300; Wed, 15 Jun 1994 18:03:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA28271; Wed, 15 Jun 1994 17:44:14 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05457; Wed, 15 Jun 1994 16:23:43 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA03831; Wed, 15 Jun 1994 08:23:29 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA20721; Wed, 15 Jun 1994 08:23:28 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406150623.AA20721@dxcoms.cern.ch> Subject: Address mapping (long) To: big-internet@munnari.OZ.AU (bigi) Date: Wed, 15 Jun 1994 08:23:28 +0200 (MET DST) Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 6535 Why is address mapping useful? ============================== 1. Convergence and multiprotocol networking ------------------------------------------- There has been quite some discussion of "convergence" of other Level 3 protocols onto IPng. Nobody has defined the goal of convergence. I will assume it is the provision of mechanisms for multiprotocol coexistence at Level 3 in the Internet, with later non-disruptive replacement of various older protocols by IPng. Another meaning of convergence is the insertion of a convergence sub-layer between two protocol layers. This is not discussed here. Here a number of mechanisms for convergence and/or multiprotocolism: CONVERGENCE BY REPLACEMENT: Here one simply avoids all intermediate steps. The next versions of several currently used protocols would all be identical, e.g. IPng should also be "IPXng", "AppleTalk Phase 3", "DECnet Phase VI", and "CLNP++". This is presumably the ultimate goal in any case. HEADER TRANSLATION: This is a CATNIP-like, or IPAE-translator-like, scheme where packet headers are translated on the fly. Then hosts running level 3 protocol X can communicate over a network running level 3 protocol Y. SHIPS IN THE DAY: One method is to move from the current ships-in-the-night (SIN) approach (routers support multiple Level 3 protocols, and multiple routing and addressing architectures), to a ships-in-the-day (SID) approach. In SID, routers support multiple Level 3 protocols but a unified routing and addressing architecture. (Note: "and addressing"!) SID is short of convergence but would considerably simplify network planning and management compared to SIN. ENCAPSULATION: (Or tunnels. If anyone sees a difference between encapsulation and tunnels please tell me. I never write "tunnelling" because I get upset when I see it spelt in American :-) Historically, the trouble with tunnels is the need for manual configuration, which does not scale. If the addressing architecture for encapsulated protocols could be made the same as that for the encapsulating protocol, mechanisms for automatic configuration of tunnels could be devised. (One can argue that in this case, tunnels and header translation are logically equivalent.) 2. The address mapping paradigm ------------------------------- I suggest that all of the above mechanisms are made possible if the address space of each existing protocol can be algorithmically mapped into the IPng address space, but not otherwise. If the IPng address format has the generic form (prefix,suffix) where the prefix locates the subscriber (site, campus or corporate network) and the suffix conveys the subscriber's internal host locator (and possibly EID), the most straightforward address mapping paradigm is to ensure that the suffix is big enough to cover all of the existing address spaces as well as new IPng hosts. onsidering address spaces in common use (but ignoring SNA/APPN because I know nothing about it), we find: 1. Eight bytes are precisely sufficient to map the useful bits of a DECnet/OSI NSAPA, i.e., 2 bytes for the area number and 6 bytes for the IEEE address. (The AFI is treated as a no-op in this analysis. It assumed that the IPng prefix fulfils the role of the AFI.) 2. Ten bytes are sufficient for an IPX address (4 bytes network number and 6 bytes IEEE address). 3. Three bytes suffice for Appletalk addresses (2 bytes network number and one byte host number). 4. Four bytes are enough for IPv4 addresses including RFC1597 addresses. One can conclude that the subscriber address space must be a minimum of 11 bytes (a code point byte plus the largest of the above), regardless of considerations affecting IPng itself. In this case algorithmic address mapping is trivial (attach or remove the prefix and the code point byte). This enables any of the mechanisms listed above. 3. Pitfalls ----------- The (prefix,suffix) model assumes that the mapped address is entirely contained in the suffix part. This is sufficient to ensure uniqueness of the total address (which is why RFC 1597 addresses can be migrated readily to IPng addresses). However it does not perfectly match the case where a non-IPng network is split into two or more parts interconnected only by the IPng Internet. To be concrete, let's consider a DECnet Phase V address space split between three sites called C, A and B (CERN, Argonne and Brookhaven if you want to be even more concrete.) They have three different DECnet area numbers NC, NA and NB and hosts within each area are identified by "IEEE" addresses which are actually their DECnet Phase IV addresses in disguise. They are (at some future date) connected to three different IPng service providers, so they have three different address prefixes PC, PA and PB. Then DECnet addresses at C will be in the form (NC,host) and when mapped into IPng address space will be (PC,DECnet,NC,host) where DECnet is the code point used for DECnet addresses within IPng address space. A DECnet router at C will need to know that to send a packet to (NA,host) it must actually be sent to (PA,DECnet,NA,host), but to send it to (NB,host) it must actually be sent to (PB,DECnet,NB,host). Thus instead of knowing how to route to NA and NB, it must know how to rewrite addresses by adding the appropriate prefix. This is error-prone, unless a complete set of routing protocols exist to support it. Now the main pitfall: in DECnet Phase V as defined today, the "prefix" is an OSI AFI which has simply been removed in the above discussion. Because AFIs are unique, and are an integral part of the address, any number of DECnets can coexist and interwork in OSI address space, each with its own AFI. In the paradigm discussed here, any number of DECnets can coexist in IPng address space, and each site has a unique prefix, but two subscribers using the same area number cannot interwork. Address mapping does not necessarily generate unambiguous addresses. No doubt a similar analysis could be made for IPX and AppleTalk: if network numbers (cf. area numbers in DECnet) are not globally unique then mapping them into IPng space may not be unambiguous. This does not matter as long as address mapping is used within a subscriber's network or between a small set of consenting subscribers. This is acceptable as an interim convergence or transition tool, but not as a long-term solution. (Thanks to Ran Atkinson for suggesting that I wrote this.) Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 20:30:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10386; Wed, 15 Jun 1994 18:23: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 SAA28332; Wed, 15 Jun 1994 18:23:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA28327; Wed, 15 Jun 1994 18:20:07 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09845; Wed, 15 Jun 1994 18:13:10 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406150813.9845@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 15 Jun 1994 09:11:49 +0100 To: "James 'J' Allard" Cc: atkinson@itd.nrl.navy.mil, owner-Big-Internet@munnari.OZ.AU, big-Internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Tue, 14 Jun 94 22:04:28 +0700." <9406150410.AA14478@netmail2.microsoft.com> Date: Wed, 15 Jun 94 09:11:44 +0100 From: Jon Crowcroft >ask 100 netware "experts" what an ipx address looks like, or how many >bytes a network id is. Checksum 2 packet length 2 Transport Control 1 Packet type 1 Destination Net 4 Destination Node 6 Destination Socket 2 Source Net 4 Source Node 6 Source Socket 2 or something like that > "On the Internet, nobody knows you're running Windows NT" i prefer the original: on the internet, no-one knows you're not really an expert... meanwhile, what are the pro's and cons of fixed and varialbe length adddresses? as far as i can see, if an address is 'big enough', there are no pro's to having it variable, (except the possible dubious one that we now have reached a _range_ of bandwidths and size of nets that we have to have a range of packet size from a minumum that cannot accomondate the full address(!), to the max that is better for low error, high throughput lines....i..e the variable address is not to scale _up_, but to comrpess down. the only other plus is one of consumer confidence (and here i refer to 'address space consumer', not user) - they just may not _believe_ a fixed address is big enough... what a shame:-) jon From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 21:23:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17228; Wed, 15 Jun 1994 21:23: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 VAA28495; Wed, 15 Jun 1994 21:23:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA28481; Wed, 15 Jun 1994 21:05:52 +1000 Precedence: list Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14867; Wed, 15 Jun 1994 20:23:19 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA23597; Wed, 15 Jun 94 05:27:26 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA06904; Wed, 15 Jun 94 05:23:06 CDT Date: Wed, 15 Jun 94 05:23:06 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9406151023.AA06904@anubis.network.com> To: big-Internet@munnari.OZ.AU Subject: Re: variable length addresses Let me stick up my hand here. I write code for routers, and I know how to make variable length things in packets go fast. Tony Li told me how! There are really two cases to be distinguished here, variable length with an 'expected' length that you can detect easily and treat as a fixed length for the fast path, and truly variable length. Even the truly variable length stuff can be handled with hardware assist, and hardware assist can pretty much be assumed in high performance boxes anyway. The win for the first kind of variable length thing is doubtful, it lets you grow your EID/locator/whatever space with less pain. Size of spaces seems to be less of an issue than 'how do you route efficiently in a billion node network', though. The win for the 2nd kind is that you can have arbitrarily long locally assigned chunks, which is joy and a wonder to behold. I vote for administrative simplicity, if that means TLV encoded variable length everythings in the header, with all the fields in random order, that's ok. The ASICs to shatter a header into its component atoms and look each atom up in a lookaside buffer will just need a few more gates. Big Deal. Hmm. Is this a host-side guys against a router guys thing? TLV encoded random order headers would truly suck if you were trying to get wire speed out of a Sun 3/50. Andrew From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 21:43:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17942; Wed, 15 Jun 1994 21:43: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 VAA28538; Wed, 15 Jun 1994 21:43:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA28535; Wed, 15 Jun 1994 21:41:47 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17835; Wed, 15 Jun 1994 21:41:40 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406151141.17835@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 15 Jun 1994 12:41:10 +0100 To: amolitor@anubis.network.com (Andrew Molitor) Cc: big-Internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 94 05:23:06 CDT." <9406151023.AA06904@anubis.network.com> Date: Wed, 15 Jun 94 12:41:06 +0100 From: Jon Crowcroft > Hmm. Is this a host-side guys against a router guys thing? >TLV encoded random order headers would truly suck if you were trying >to get wire speed out of a Sun 3/50. Andrew and there are more hosts than routers by at least 2 orders of magnitude, but the argument that the routers have to 'go faster' may not hold nowadays, when the hosts do mulitmeida, but when only 1% traffic is nonlocal... jon From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 22:03:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18543; Wed, 15 Jun 1994 22:03: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 WAA28570; Wed, 15 Jun 1994 22:03:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA28567; Wed, 15 Jun 1994 22:02:26 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18525; Wed, 15 Jun 1994 22:02:23 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA24504; Wed, 15 Jun 1994 14:02:19 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA02836; Wed, 15 Jun 1994 14:02:18 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406151202.AA02836@dxcoms.cern.ch> Subject: Re: variable length addresses To: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft) Date: Wed, 15 Jun 1994 14:02:18 +0200 (MET DST) Cc: amolitor@anubis.network.com, big-Internet@munnari.OZ.AU In-Reply-To: <9406151141.17835@munnari.oz.au> from "Jon Crowcroft" at Jun 15, 94 12:41:06 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 650 Jon, > and there are more hosts than routers by at least 2 orders of > magnitude, but the argument that the routers have to 'go faster' > may not hold nowadays, when the hosts do mulitmeida, but when only 1% > traffic is nonlocal... > Can't let that go. I should be so lucky as to have 99% locality. 75% would be high here and multimedia will REDUCE it. One of the main reasons we run a big Class B is router performance. We have to keep MBONE traffic off the Class B precisely because it has zero locality (not 1%, zero). Routers and hosts must both go at wire speed. It's worse for routers because they are connected to multiple wires. Brian From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 22:23:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19288; Wed, 15 Jun 1994 22:23: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 WAA28605; Wed, 15 Jun 1994 22:23:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA28586; Wed, 15 Jun 1994 22:05:01 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18579; Wed, 15 Jun 1994 22:04:57 +1000 (from yakov@watson.ibm.com) Message-Id: <9406151204.18579@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8721; Wed, 15 Jun 94 08:04:56 EDT Date: Wed, 15 Jun 94 08:00:33 EDT To: J.Crowcroft@cs.ucl.ac.uk, amolitor@anubis.network.com Cc: big-Internet@munnari.OZ.AU Subject: variable length addresses Ref: Your note of Wed, 15 Jun 94 12:41:06 +0100 Jon, >but when only 1% traffic is nonlocal I'd like to point out that the Internet is turning into the Information market (and it is doing this quite successfully). In such an environment the information is all over the net, and if the predominant use of the net is for the information retrieval, then I don't see how "only 1% traffic" is going to be nonlocal. So, the argument that the routers "have to go faster" may be more important in the future than it is today (as redistribution between local and non-local traffic shifts towards more non-local traffic). Yakov. From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 22:24:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19322; Wed, 15 Jun 1994 22:24: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 WAA28620; Wed, 15 Jun 1994 22:24:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA28600; Wed, 15 Jun 1994 22:13:06 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18881; Wed, 15 Jun 1994 22:12:56 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406151212.18881@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 15 Jun 1994 13:11:53 +0100 To: yakov@watson.ibm.com Cc: amolitor@anubis.network.com, big-Internet@munnari.OZ.AU, J.Crowcroft@cs.ucl.ac.uk Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 94 08:00:33 EDT." Date: Wed, 15 Jun 94 13:11:46 +0100 From: Jon Crowcroft >>but when only 1% traffic is nonlocal >I'd like to point out that the Internet is turning into the Information >market (and it is doing this quite successfully). In such an >environment the information is all over the net, and if the predominant >use of the net is for the information retrieval, then I don't see how >"only 1% traffic" is going to be nonlocal. >So, the argument that the routers "have to go faster" may be >more important in the future than it is today (as redistribution >between local and non-local traffic shifts towards more non-local >traffic). yakov - (and brian made the same point) i sorry, i disagree in the short term you are right, and mbone&www grwoth support you, but when domestic traffic takes off, and web cahcing is working right, and the net is engineered better (ore hierarchically), i think you will find that it reverts to the telephony pattern jon From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 23:03:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20874; Wed, 15 Jun 1994 23:03: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 XAA28697; Wed, 15 Jun 1994 23:03:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA28694; Wed, 15 Jun 1994 23:00:23 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20617; Wed, 15 Jun 1994 23:00:16 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA02615; Wed, 15 Jun 94 08:34:02 -0400 Message-Id: <9406151234.AA02615@rodan.UU.NET> To: big-internet@munnari.OZ.AU Cc: sipp@sunroof.eng.sun.com Subject: Grumble, grumble... Date: Wed, 15 Jun 1994 08:34:01 -0400 From: "Mike O'Dell" If we had wanted huge, variable length addresses, we could have settled on CLNP a long time ago. Some of us ain't gonna roll-over for variable length addresses the size of a small planet, just so people can encode the org chart of their entire civilization in the addresses. harumph! -Mike O'Dell Resident Crank, with attitude PS - no, I don't see Boeing as representative of an entire civilization - any group cool enough to do the 777 is too cool for that. From owner-Big-Internet@munnari.OZ.AU Wed Jun 15 23:50:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20007; Wed, 15 Jun 1994 22:43: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 WAA28665; Wed, 15 Jun 1994 22:43:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA28647; Wed, 15 Jun 1994 22:27:38 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19431; Wed, 15 Jun 1994 22:27:27 +1000 (from yakov@watson.ibm.com) Message-Id: <9406151227.19431@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8923; Wed, 15 Jun 94 08:27:26 EDT Date: Wed, 15 Jun 94 08:26:39 EDT To: J.Crowcroft@cs.ucl.ac.uk Cc: amolitor@anubis.network.com, big-Internet@munnari.OZ.AU Subject: variable length addresses Ref: Your note of Wed, 15 Jun 94 13:11:46 +0100 Jon, >in the short term you are right, and mbone&www growth support you. Thanks. >but when domestic traffic takes off, and web caching is working right, >and the net is engineered better, I think you will find that it reverts >to the telephony pattern. If the majority of the Internet users are going to be consumers (not such an unrealistic assumption), and if these consumers are going to access the Internet through some dial-up capabilities (also not such an unrealistic assumption), there will be AT LEAST one router between the place that wants to access some information, and the place where the information is stored. The factors you mentioned would improve the average number of hops, but I still think that most of the traffic is going to be nonlocal, especially if "local" means "local to my house". Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 00:03:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23754; Thu, 16 Jun 1994 00:03: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 AAA28773; Thu, 16 Jun 1994 00:03:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA28754; Wed, 15 Jun 1994 23:49:44 +1000 Precedence: list Received: from sundance.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20082; Wed, 15 Jun 1994 22:45:38 +1000 (from atkinson@sundance.itd.nrl.navy.mil) From: Ran Atkinson Message-Id: <9406150844.ZM3009@sundance.itd.nrl.navy.mil> Date: Wed, 15 Jun 1994 08:44:22 -0500 In-Reply-To: James 'J' Allard "Re: variable length addresses" (Jun 14, 22:04) References: <9406150410.AA14478@netmail2.microsoft.com> Reply-To: atkinson@itd.nrl.navy.mil X-Mailer: Z-Mail (3.0.1 04apr94) To: "James 'J' Allard" Subject: Re: variable length addresses Cc: big-Internet@munnari.OZ.AU Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Sender: atkinson@sundance.itd.nrl.navy.mil J., We are in violent agreement that ordinary users must not have to know about address formats and that we absolutely must have very solid auto-addressing and auto-configuration mechanisms so that plug and play works from day 1. My point is different, I think. The discussion in Chicago confirmed my own experience which is that the "network managers" for connected networks (i.e. not an isolated LAN) _must_ know about subnet masks and variable length subnetting to do their job reasonably well. I don't think that will change with IPng. Certainly the large interconnected IPX networks that I know about have NetWare Network Admins who grok and need to grok these things for IPX. I just want to make it _easier_ for such a network admin to use his/her address space more effectively -- by making nibble boundaries easier to deal with. Ran atkinson@itd.nrl.navy.mil From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 00:05:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23801; Thu, 16 Jun 1994 00:05: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 AAA28788; Thu, 16 Jun 1994 00:05:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA28757; Wed, 15 Jun 1994 23:50:22 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20253; Wed, 15 Jun 1994 22:51:15 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406151251.20253@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 15 Jun 1994 13:50:44 +0100 To: yakov@watson.ibm.com Cc: amolitor@anubis.network.com, big-Internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 94 08:26:39 EDT." Date: Wed, 15 Jun 94 13:50:39 +0100 From: Jon Crowcroft >If the majority of the Internet users are going to be consumers >(not such an unrealistic assumption), and if these consumers >are going to access the Internet through some dial-up capabilities >(also not such an unrealistic assumption), there will be AT LEAST >one router between the place that wants to access some information, >and the place where the information is stored. >The factors you mentioned would improve the average number of hops, >but I still think that most of the traffic is going to be nonlocal, >especially if "local" means "local to my house". architectural prediction: Cable net has head end + video on demand server at head of each street. which will also be multiprotocol router (and wil lalso be a CIX) then next level routers will be city-city, of which there will be quite a few, since there will be many providers... next ones will be country to country...again, there may be quite a few (after all, just what is a "country" nowadays...) many sites (homes) wil lbe producers - for instance, with good internet security, all my tax/health/bank/payroll/etc info will be _in my home_, not in the government server... locality of culture/language/physical travel for entertainment will determine locality of interest in information too.... large information servers (video/libraries etc) will be replicated etc etc so it'll all go local again in about 10-15 years... i assert! jon From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 02:23:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29096; Thu, 16 Jun 1994 02:23: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 CAA29055; Thu, 16 Jun 1994 02:23:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29049; Thu, 16 Jun 1994 02:21:38 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29060; Thu, 16 Jun 1994 02:21:28 +1000 (from valdis@black-ice.cc.vt.edu) Received: (valdis@localhost) by black-ice.cc.vt.edu (8.6.8.1/8.6.7) id MAA16962; Wed, 15 Jun 1994 12:17:48 -0400 Message-Id: <199406151617.MAA16962@black-ice.cc.vt.edu> To: Jon Crowcroft Cc: big-Internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 1994 12:41:06 EDT." <9406151141.17835@munnari.oz.au> From: Valdis.Kletnieks@vt.edu Date: Wed, 15 Jun 1994 12:17:48 +22306356 Sender: valdis@black-ice.cc.vt.edu On Wed, 15 Jun 1994 12:41:06 EDT, Jon Crowcroft said: > > (Andrew Molitor talking here) > > Hmm. Is this a host-side guys against a router guys thing? > >TLV encoded random order headers would truly suck if you were trying > >to get wire speed out of a Sun 3/50. Urp. I'm officially a host-side guy - I just talk to our router guys. ;) In any case, I tend towards the variable-length camp - on this campus we have 4,000 hosts (probably 60% of which are PC or Mac machines) and maybe a dozen routers. The economics of this end up being that on the host side, we're willing to pay extra for something that does auto-configuration etc, even if we have to pay a premium for routers with lots of hardware assists. ;) > and there are more hosts than routers by at least 2 orders of > magnitude, but the argument that the routers have to 'go faster' > may not hold nowadays, when the hosts do mulitmeida, but when only 1% > traffic is nonlocal... I wish it was 1% - the actual numbers here are more on the order of 5% - when you have one machine on campus that sends 122,846 pieces of mail off-campus, and another does 33,792 (actually, both machines are aliases of our 3090, and those are the numbers from yesterday), our T-1 links stay pretty busy (but then, nic.merit.edu /nsfnet/statistics/1994/nsf-9402.pnets says that we're the 43rd most active network out of 14,963) Valdis Kletnieks Computer Systems Engineer Virginia Tech From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 02:25:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29243; Thu, 16 Jun 1994 02:25: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 CAA29070; Thu, 16 Jun 1994 02:24:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29052; Thu, 16 Jun 1994 02:21:46 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29068; Thu, 16 Jun 1994 02:21:40 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA14323; Wed, 15 Jun 94 09:23:27 -0700 Date: Wed, 15 Jun 94 09:23:27 -0700 From: Eric Fleischman Message-Id: <9406151623.AA14323@atc.boeing.com> To: atkinson@itd.nrl.navy.mil, jallard@microsoft.com, owner-Big-Internet@munnari.OZ.AU Subject: Re: variable length addresses Cc: big-Internet@munnari.OZ.AU Dear J: Thank you for the following posting. I applaud your vision and fully agree with your statements. However, for the poor unfortunates who have to grope at this level (and both you and I have been there), I also wish to support Ran's point that more adequate human factors need to be built in as well. This is especially the case because I do not see the IETF moving us into a "user friendly" world anywhere near quickly enough: where is our autoregistration? End users want scalable and secure plug-and-play now. Sincerely yours, --Eric Fleischman >although the ops folks reading sniffer traces and configuring router filters >will want some "standard notation", i don't see the big problem here. >autoconfigure, autoconfigure, then do it some more. why more than .001% >of ipng users will be exposed to addresses, i do not know. if this is an >accurate assumption, then why waste the energy? hex is fine, dotted >dec is fine, but we potentially lose granularity to convenience as we >have w/ ipv4. >ask 100 netware "experts" what an ipx address looks like, or how many >bytes a network id is. 90+ will draw complete blanks. ask 100 users, 100 >will draw blanks. let's straighten out the serverless/serverful >autoconfiguration and dynamic dns registration problems and worry >abt "dns name addresses" since this is the only thing that users >and admins should be exposed to (generally speaking). >the fact that thousands of users recognize dotted decimal or >know something abt ipv4 address classes today is offensive. >let's hide this convenient netlayer/routing address to the >implementors and conveniently forget to document or display >these warts on the end-systems. _______________________________________________________________ J. Allard jallard@microsoft.com Program Manager of TCP/IP Technologies work: (206)882-8080 Microsoft Corporation home: (206)860-8862 "On the Internet, nobody knows you're running Windows NT" From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 02:38:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25522; Thu, 16 Jun 1994 00:45: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 AAA28845; Thu, 16 Jun 1994 00:43:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA28831; Thu, 16 Jun 1994 00:26:46 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24785; Thu, 16 Jun 1994 00:26:39 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA11202; Wed, 15 Jun 94 10:26:37 -0400 Date: Wed, 15 Jun 94 10:26:37 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: <9406151426.AA11202@rodan.UU.NET> To: big-internet@munnari.OZ.AU Subject: "most traffic is local" the definition of "local" shifts with time and instantaneous economics. diskless workstations are a good example of the curves forming an inverse cusp for a period, and people ran with it. now with 1 gig disks under $700, (the price of a good 10baseT hub), saving money on disks at the expense of network bandwidth is rather less attractive. so i believe "most traffic will be local", but as Ran pointed out, that may mean "cable neighborhood", city, or continent, depending on external economics. -mo From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 02:48:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26888; Thu, 16 Jun 1994 01:23: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 BAA28923; Thu, 16 Jun 1994 01:23:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA28910; Thu, 16 Jun 1994 01:12:25 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26391; Thu, 16 Jun 1994 01:12:17 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA14004; Wed, 15 Jun 94 09:11:40 MDT Received: from ns.Novell.COM by WC.Novell.COM (4.1/SMI-4.1) id AE22663; Wed, 15 Jun 94 07:42:30 PDT Date: Wed, 15 Jun 94 07:42:30 PDT Message-Id: <9406151442.AE22663@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Brian.Carpenter@cern.ch, dcrocker@Mordor.Stanford.EDU (Dave Crocker) From: Greg Minshall Subject: Re: What is "serverless autoconfiguration" ? Cc: big-internet@munnari.OZ.AU (bigi) Brian, >Of course. But as anyone who has run a large AppleTalk environment >will tell you, beyond a certain size plug-and-play turns into >plug-and-pray, i.e. the algorithms don't scale. AppleTalk runs afoul, in particular, of scaling problems in the acquisition of node numbers. >I agree however that there is a role for very small self-configuring >systems. The point is that the algorithms normally used for this >are broken above a certain size of network, which is where my >line of argument comes in. How do we ensure that allowing plug&play >at the bottom end does not create horrendous scaling problems? >How do we ensure that it does not create problems when plug&play >networks later connect to the Internet? My model is that there is an ICMP message which routers (can be configured to) generate which says "you can't use that address - get a serverfull address". (And, part of my model is that a node can simultaneously support more than one IPng address on an interface; i think you need this for switching providers and it is useful for the unlikely case of wanting to assert *some* control over the provider used for packets delivered *to* you.) Greg From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 02:51:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28473; Thu, 16 Jun 1994 02:03: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 CAA29020; Thu, 16 Jun 1994 02:03:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA29006; Thu, 16 Jun 1994 01:54:11 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28118; Thu, 16 Jun 1994 01:54:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29598; Wed, 15 Jun 94 11:53:54 -0400 Date: Wed, 15 Jun 94 11:53:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406151553.AA29598@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU, yakov@watson.ibm.com Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: Jon Crowcroft > I'd like to point out that the Internet is turning into the Information > market ... In such an environment the information is all over the net, in the short term you are right ... but when domestic traffic takes off, ... and the net is engineered better (more hierarchically), i think you will find that it reverts to the telephony pattern I don't believe this last statement. The usage patterns of the telephone network are in large part related to *what* you can do with it; call up another person and have a chat. The things you can do with the Internet are so different, I expect future usage patterns will also look different. E.g, how much traffic on the net is mailing lists and Netnews, all of which is (basically) widely multicast? Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 02:54:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00452; Thu, 16 Jun 1994 02:54: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 CAA29214; Thu, 16 Jun 1994 02:54:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29097; Thu, 16 Jun 1994 02:37:44 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29690; Thu, 16 Jun 1994 02:37:41 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA16228; Wed, 15 Jun 94 09:39:17 -0700 Date: Wed, 15 Jun 94 09:39:17 -0700 From: Eric Fleischman Message-Id: <9406151639.AA16228@atc.boeing.com> To: J.Crowcroft@cs.ucl.ac.uk, amolitor@anubis.network.com Subject: Re: variable length addresses Cc: big-Internet@munnari.OZ.AU Dear Jon, Excuse my ignorance. However in your reply to Andrew you said: >and there are more hosts than routers by at least 2 orders of >magnitude, but the argument that the routers have to 'go faster' >may not hold nowadays, when the hosts do mulitmeida, but when only 1% >traffic is nonlocal... I have no trouble understanding why routers need to quickly parse addresses to forward packets to the correct next hop -- and do it very quickly. However, even with real-time applications, I can not imagine why an end system needs to parse addresses in a similar manner. That is, to get an address I use a DNS name and obtain an address. The address is a unit. When I use the address the address remains a unit. When I reply to an address, the address still remains a unit. Sure, in real time applications my software needs to do things lickety-split, but I don't see the need for my host to parse these addresses as routers. Therefore, I don't understand why my end system cares whether the address is fixed length or variable, as long as it has the correct address and as long as it is able to handle that size of address. Now that I have displayed my ignorance, I would appreciate understanding what I have overlooked that requires an end system to have equivalent address parsing requirements and latencies as a router. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:03:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00934; Thu, 16 Jun 1994 03:03: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 DAA29264; Thu, 16 Jun 1994 03:03:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29150; Thu, 16 Jun 1994 02:48:45 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28592; Thu, 16 Jun 1994 02:09:01 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA23011; Wed, 15 Jun 94 12:08:49 -0400 Message-Id: <9406151608.AA23011@rodan.UU.NET> To: Brian.Carpenter@cern.ch Cc: big-internet@munnari.OZ.AU, mo@uunet.UU.NET Subject: Re: "most traffic is local" - even when it's petabytes... In-Reply-To: Your message of "Wed, 15 Jun 1994 18:02:09 +0200." <9406151602.AA11944@dxcoms.cern.ch> Date: Wed, 15 Jun 1994 12:08:49 -0400 From: "Mike O'Dell" Just so. Local for you is CERN and the huge data store. Makes complete sense to me, and I hope your folks get their 100MB/sec. -mo From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:06:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00986; Thu, 16 Jun 1994 03:06: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 DAA29283; Thu, 16 Jun 1994 03:05:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29166; Thu, 16 Jun 1994 02:49:56 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28434; Thu, 16 Jun 1994 02:02:55 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA29578; Wed, 15 Jun 1994 18:02:10 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA11944; Wed, 15 Jun 1994 18:02:09 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406151602.AA11944@dxcoms.cern.ch> Subject: Re: "most traffic is local" To: mo@uunet.UU.NET (Mike O'Dell) Date: Wed, 15 Jun 1994 18:02:09 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9406151426.AA11202@rodan.UU.NET> from "Mike O'Dell" at Jun 15, 94 10:26:37 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 881 Mike, For people with multi-terabyte data archives (such as particle physicists or home-entertainment suppliers) the local 1 GB disk is just a toy. My users want 100 Mbyte/s disk access over the campus network by year 2002. Actually they expect to have a petabyte data archive by then. Brian >--------- Text sent by Mike O'Dell follows: > > > the definition of "local" shifts with time and instantaneous economics. > diskless workstations are a good example of the curves forming an > inverse cusp for a period, and people ran with it. now with 1 gig > disks under $700, (the price of a good 10baseT hub), saving money > on disks at the expense of network bandwidth is rather less attractive. > > so i believe "most traffic will be local", but as Ran pointed out, > that may mean "cable neighborhood", city, or continent, depending > on external economics. > > -mo > From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:24:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01620; Thu, 16 Jun 1994 03: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 DAA29311; Thu, 16 Jun 1994 03:24:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29129; Thu, 16 Jun 1994 02:43:48 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26804; Thu, 16 Jun 1994 01:21:45 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA22534; Wed, 15 Jun 94 08:10:23 -0700 Received: by xirtlu.zk3.dec.com; id AA27531; Wed, 15 Jun 1994 11:10:19 -0400 Message-Id: <9406151510.AA27531@xirtlu.zk3.dec.com> To: Brian.Carpenter@cern.ch Cc: big-Internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 94 14:02:18 +0200." <9406151202.AA02836@dxcoms.cern.ch> Date: Wed, 15 Jun 94 11:10:13 -0400 X-Mts: smtp Brian, => and there are more hosts than routers by at least 2 orders of => magnitude, but the argument that the routers have to 'go faster' => may not hold nowadays, when the hosts do mulitmeida, but when only 1% => traffic is nonlocal... >Can't let that go. I should be so lucky as to have 99% locality. >75% would be high here and multimedia will REDUCE it. One of the >main reasons we run a big Class B is router performance. We have >to keep MBONE traffic off the Class B precisely because it has >zero locality (not 1%, zero). But your not going to debate that: 1) There are more hosts in the world than routers? 2) That the majority of network traffic at most end user sites that create the major revenue to warrant my job as a network software engineer is local LAN traffic? If so we then have to go back to some basic discussions and get consensus on variants of folks reality so we can move forward. >Routers and hosts must both go at wire speed. It's worse for routers >because they are connected to multiple wires. I have heard no router code writer tell me that theY cannot make fixed length addresses go at wire speeds. /jim From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:26:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01665; Thu, 16 Jun 1994 03:26: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 DAA29338; Thu, 16 Jun 1994 03:26:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29169; Thu, 16 Jun 1994 02:50:11 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28437; Thu, 16 Jun 1994 02:02:58 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406151602.28437@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 15 Jun 1994 17:00:34 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, yakov@watson.ibm.com Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 94 11:53:54 EDT." <9406151553.AA29598@ginger.lcs.mit.edu> Date: Wed, 15 Jun 94 17:00:32 +0100 From: Jon Crowcroft > in the short term you are right ... but when domestic traffic takes off, > ... and the net is engineered better (more hierarchically), i think you > will find that it reverts to the telephony pattern >I don't believe this last statement. The usage patterns of the telephone >network are in large part related to *what* you can do with it; call up >another person and have a chat. The things you can do with the Internet are so >different, I expect future usage patterns will also look different. E.g, how >much traffic on the net is mailing lists and Netnews, all of which is >(basically) widely multicast? Noel oh blimey, why do i always say the wrong thing i did _not_ mean that everything would be lots of 1-1 calls like telephones - i.e. the pattern of calls woould have a different texture, but would have the same _density_! i meant that the assumption of herarchical traffic wil statistically still be the case.... our _measurements_ show that netnbews and mail are totally irrelevant as a percentage...btw also www & mobone traffic are only the way they are as i said, coz the engineering of the www servers and the engfineering of the mbone are not cachized or pim-ized yet... jon From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:28:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01743; Thu, 16 Jun 1994 03:28: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 DAA29353; Thu, 16 Jun 1994 03:27:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29141; Thu, 16 Jun 1994 02:46:38 +1000 Precedence: list From: bound@zk3.dec.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27135; Thu, 16 Jun 1994 01:28:58 +1000 (from bound@zk3.dec.com) Received: from inet-gw-3.pa.dec.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29248 Thu, 16 Jun 1994 01:28:54 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA23134; Wed, 15 Jun 94 08:18:39 -0700 Received: by xirtlu.zk3.dec.com; id AA27680; Wed, 15 Jun 1994 11:18:37 -0400 Message-Id: <9406151518.AA27680@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: big-Internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 94 08:00:33 EDT." <9406151204.18579@munnari.oz.au> Date: Wed, 15 Jun 94 11:18:31 -0400 X-Mts: smtp Yakov, So are you saying that routers cannot keep up with wire speeds with fixed length addresses. Can you explain in detail the software code bottleneck in implementations that would prevent this using a generic routing code base or assists algorithms? I agree the Information Highway is important to consider as market and will alter the present market. In fact Bob Hinden has a complete section very well articulated in the SIPP IPng White Paper he did on this subject, which can be read whether you like SIPP or not. I sent it around to some of marketing folks and they pretty much agreed with Bob's projections of where the market will end up. But none of this takes away from the importance of the host networking paradigm that will support the applications used in this next generation Information Highway market. We don't want to rob Paul to pay Peter by giving to the hosts, routers, operators, providers, or any entity in the network space and take away from the other if we can do that in the IETF for IPng. But I think its critical for this discussion if we have a statement from someone that fixed length addresses can or cannot attain wire speeds? They do today with IPv4 and if they don't is it a limit of the address? /jim /jim From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:29:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29921; Thu, 16 Jun 1994 02:44: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 CAA29127; Thu, 16 Jun 1994 02:43:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29121; Thu, 16 Jun 1994 02:42:04 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29846; Thu, 16 Jun 1994 02:41:51 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA27583; Wed, 15 Jun 94 09:41:40 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA25677; Wed, 15 Jun 94 09:42:39 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA17896; Wed, 15 Jun 1994 09:41:35 -0700 Date: Wed, 15 Jun 1994 09:41:35 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406151641.AA17896@jurassic.Eng.Sun.COM> To: amolitor@anubis.network.com Cc: big-Internet@munnari.OZ.AU In-Reply-To: <9406151251.20253@munnari.oz.au> Subject: Re: variable length addresses I won't try to speak for all host vendors, but the one I am familiar with certainly thinks wire-speed host network performance is very important. It is important for desktops and is even more important for servers with multiple interfaces. All of those information servers everyone likes to talk about are not going to be routers :-) Bob From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:30:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01896; Thu, 16 Jun 1994 03:30: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 DAA29368; Thu, 16 Jun 1994 03:29:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA29261; Thu, 16 Jun 1994 03:01:36 +1000 Precedence: list Received: from netcom5.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00843; Thu, 16 Jun 1994 03:01:29 +1000 (from kck@netcom.com) Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id KAA29723; Wed, 15 Jun 1994 10:01:41 -0700 Date: Wed, 15 Jun 1994 10:01:41 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199406151701.KAA29723@netcom.com> To: big-Internet@munnari.OZ.AU Subject: Re: variable length addresses > I vote for administrative simplicity, if that means TLV encoded >variable length everythings in the header, with all the fields in >random order, that's ok. The ASICs to shatter a header into its component >atoms and look each atom up in a lookaside buffer will just need a few >more gates. Big Deal. > > Hmm. Is this a host-side guys against a router guys thing? >TLV encoded random order headers would truly suck if you were trying >to get wire speed out of a Sun 3/50. > > Andrew Not all NEW devices will have the advantage of hardware assit either! Also, it must be true hell trying to effectively compress variable length addresses unless they are really fixed size. This is case one, as you described above. I believe that addresses need to stay small. The scheme where addresses are 8 bytes or 16 bytes, with a bit indicating which they are might prove useful for things like source routes, wireless (or low bandwidth) links. The problem with this scheme will be administering it. Its bad enough now for people to deal with 4 byte IP addresses, what will happen if they are given 4, 8 and 16 byte addresses tod eal with? Esp. if we need new notations for each. And as bad as this will get, variable addresses will be a total nightmare to administer. -rich From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:31:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00242; Thu, 16 Jun 1994 02:49: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 CAA29156; Thu, 16 Jun 1994 02:49:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29100; Thu, 16 Jun 1994 02:38:11 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25795; Thu, 16 Jun 1994 00:54:54 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA20781; Wed, 15 Jun 94 07:46:34 -0700 Received: by xirtlu.zk3.dec.com; id AA26932; Wed, 15 Jun 1994 10:46:33 -0400 Message-Id: <9406151446.AA26932@xirtlu.zk3.dec.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 94 02:45:29 EDT." <9406150645.AA26457@ginger.lcs.mit.edu> Date: Wed, 15 Jun 94 10:46:27 -0400 X-Mts: smtp >Fine with me. Can we just drop this whole line? Fine. I will not state what Ross said but please if you have not read his response to Bill, please do. Also do you insist on bringing up the past such as what happened when they defined IPv4? I suggest we not get into that at this point until we want to use history maybe to support architectural assumptions. I could respond by saying there is a protocol in the market that supports variable addresses that has not been wildly successful. But thats not a good technical argument either. /jim From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:32:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00315; Thu, 16 Jun 1994 02:50: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 CAA29181; Thu, 16 Jun 1994 02:50:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29118; Thu, 16 Jun 1994 02:40:05 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29765; Thu, 16 Jun 1994 02:40:00 +1000 (from yakov@watson.ibm.com) Message-Id: <9406151640.29765@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 3395; Wed, 15 Jun 94 12:39:59 EDT Date: Wed, 15 Jun 94 12:36:07 EDT To: bound@zk3.dec.com Cc: big-Internet@munnari.OZ.AU Subject: variable length addresses Ref: Your note of Wed, 15 Jun 94 11:18:31 -0400 Jim, >So are you saying that routers cannot keep up with wire speeds with >fixed length addresses. Not at all. What I've been saying is that when designing IPng we need to worry as much about host performance implications as about router performance implications. To put it differently, we need a globally optimal solution that takes into account both routers and hosts. >I think its critical for this discussion if we have a statement >from someone that fixed length addresses can or cannot attain wire speed. I think we've already seen data from router vendors that wire speed can be attained with both fixed and variable length addresses. Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:34:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00371; Thu, 16 Jun 1994 02:52: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 CAA29199; Thu, 16 Jun 1994 02:52:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29124; Thu, 16 Jun 1994 02:42:10 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26371; Thu, 16 Jun 1994 01:09:46 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA22033; Wed, 15 Jun 94 08:03:59 -0700 Received: by xirtlu.zk3.dec.com; id AA27441; Wed, 15 Jun 1994 11:03:50 -0400 Message-Id: <9406151503.AA27441@xirtlu.zk3.dec.com> To: amolitor@anubis.network.com (Andrew Molitor) Cc: big-Internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 94 05:23:06 CDT." <9406151023.AA06904@anubis.network.com> Date: Wed, 15 Jun 94 11:03:44 -0400 X-Mts: smtp Could we keep the terms EID and Locators out of this discussion. I think it will confuse the technical tangents. The reason I say this is that its a separate discussion and some folks don't even think an EID has been defined and have no idea what it is technically or how they would be assigned. I am all for EIDs or mabye transport connection identifiers now, but this mail topic is not the place for that discussion IMHO. If we can figure out whether IPng can solve the problem with fixed length address or variable length address is the issue and discussion. The tangents we need to enter should be technical and analytical in nature I think? No its not a host guy vs router guy its a question of cost. If we can develop a fixed length address that lasts for 35 years why incur the cost in addition to all the other costs we face to build IPng products? I won't respond to the TLV encoding for the whole header as variables. This could take us on another tangent. I write code for Host kernels and variable addresses are not free and will not perform as fast as fixed length addresses, unless we can gain performance in other areas, which is possible and another cost. /jim /jim From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:45:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02569; Thu, 16 Jun 1994 03:45: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 DAA29426; Thu, 16 Jun 1994 03:45:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA29423; Thu, 16 Jun 1994 03:45:11 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02550; Thu, 16 Jun 1994 03:45:08 +1000 (from yakov@watson.ibm.com) Message-Id: <9406151745.2550@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 4837; Wed, 15 Jun 94 13:45:06 EDT Date: Wed, 15 Jun 94 13:38:18 EDT To: big-internet@munnari.OZ.AU Subject: variable length addresses Ref: Your note of Wed, 15 Jun 94 09:39:17 -0700 Folks, In the discussion on variable vs fixed length addresses, I would be interested to see the following estimate. Assume that a host vendor starts with a host that supports IPv4. Then assume two alternative scenarios: (a) need to change the host software to support IPng-A with fixed length addreses (e.g. 16 octets) (b) need to change the host software to support IPng-B with variable length addresses (max to 16 octets, in increment of 8 octets) Note that the *only* difference between IPng-A and IPng-B is that in IPng-B the length of an address is encoded as part of the address field. Given that software design, implementation and testing with scenario (a) takes X man-years, how many man-years (relative to X) it would take to do software design, implementation and testing with scenario (b) ? Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:48:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02688; Thu, 16 Jun 1994 03:48: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 DAA29446; Thu, 16 Jun 1994 03:47:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA29401; Thu, 16 Jun 1994 03:36:14 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02204; Thu, 16 Jun 1994 03:35:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00761; Wed, 15 Jun 94 13:35:34 -0400 Date: Wed, 15 Jun 94 13:35:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406151735.AA00761@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mo@uunet.uu.net Subject: Re: Grumble, grumble... Cc: jnc@ginger.lcs.mit.edu, sipp@sunroof.eng.sun.com From: "Mike O'Dell" If we had wanted huge, variable length addresses, we could have settled on CLNP a long time ago. Well, if we wanted to do what X.25 did, and take some existing technology and make minor tweaks, we could have done *that* a long time ago too. Look where it got X.25; an evolutionary dead end. (Also, I don't like CLNP, but not because the addresses are too long; I actually think they may be too short, myself.) Some of us ain't gonna roll-over for variable length addresses the size of a small planet, just so people can encode the org chart of their entire civilization in the addresses. Some of us ain't gonna roll-over for taking IPv4 and making some of the fields a little bigger (and SIPP even missed some of the fields that need to be extended), just so we can i) decide on something, anything, in a hurry, to get the spin-control that we are Fixing The Problem, ii) make the engineering microscopically easier for the less-inventive, iii) etc, etc, etc. Noel Resident Crank, with Major Attitude :-) From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 03:50:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02759; Thu, 16 Jun 1994 03: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 DAA29461; Thu, 16 Jun 1994 03:50:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29147; Thu, 16 Jun 1994 02:48:24 +1000 Precedence: list From: bound@zk3.dec.com Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27454; Thu, 16 Jun 1994 01:39:37 +1000 (from bound@zk3.dec.com) Received: from inet-gw-3.pa.dec.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29546 Thu, 16 Jun 1994 01:38:47 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA24232; Wed, 15 Jun 94 08:34:28 -0700 Received: by xirtlu.zk3.dec.com; id AA28062; Wed, 15 Jun 1994 11:34:24 -0400 Message-Id: <9406151534.AA28062@xirtlu.zk3.dec.com> To: yakov@watson.ibm.com Cc: big-Internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 94 08:26:39 EDT." <9406151227.19431@munnari.oz.au> Date: Wed, 15 Jun 94 11:34:18 -0400 X-Mts: smtp Yakov, >If the majority of the Internet users are going to be consumers >(not such an unrealistic assumption), and if these consumers >are going to access the Internet through some dial-up capabilities >(also not such an unrealistic assumption), there will be AT LEAST >one router between the place that wants to access some information, >and the place where the information is stored. For the Internet yes. But much of any vendors sales will consist of IPng in private companies in addition to the Internet business. Lets not forget about that market segment in our discussion. >The factors you mentioned would improve the average number of hops, >but I still think that most of the traffic is going to be nonlocal, >especially if "local" means "local to my house". If its cached it don't have to go to the network. There are no hops. This is not figured out yet but will be. So what your seeing now is only temporary and will improve. Yes set up will be major but unless a user is browsing through unrelated subjects with each mouse click eventually it will not require leaving the desktop and at the most accessing a local cache server on a local wire. So lets not penalize local traffic tomorrow for the incomplete solutions of today where network traffic is used. Plus I have not seen any multi-million dollar RFCs from any customers where I could win the networking part of the bid with just mosaic. Multicast on a local wire for IPv4 as a major piece is closer to the needs as far as emerging technology in RFCs. Yes mosaic is definitely a customer want but the technology behind it needs evolution, which is happening. /jim From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 04:10:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03392; Thu, 16 Jun 1994 04:10: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 EAA29491; Thu, 16 Jun 1994 04:10:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA29439; Thu, 16 Jun 1994 03:47:09 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02639; Thu, 16 Jun 1994 03:47:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00880; Wed, 15 Jun 94 13:46:54 -0400 Date: Wed, 15 Jun 94 13:46:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406151746.AA00880@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: kck@netcom.com (Richard Fox) Its bad enough now for people to deal with 4 byte IP addresses, what will happen if they are given 4, 8 and 16 byte addresses tod eal with? Esp. if we need new notations for each. And as bad as this will get, variable addresses will be a total nightmare to administer. Really? People seem to manage DNS names (variable lengths, variable numbers of levels) quite well. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 04:12:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03453; Thu, 16 Jun 1994 04:12: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 EAA29508; Thu, 16 Jun 1994 04:12:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA29482; Thu, 16 Jun 1994 04:02:30 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03182; Thu, 16 Jun 1994 04:03:33 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA22655; Wed, 15 Jun 94 10:56:44 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA16725; Wed, 15 Jun 1994 13:56:41 -0400 Date: Wed, 15 Jun 1994 13:45:50 -0400 Message-Id: <94061513455039@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: amolitor@anubis.network.com, big-Internet@munnari.OZ.AU Subject: Re: variable length addresses X-Vms-To: SMTP%"amolitor@anubis.network.com" X-Vms-Cc: SMTP%"big-Internet@munnari.oz.au",CONTA > Hmm. Is this a host-side guys against a router guys thing? Andrew, It looks like it is. On a router you're not concerned with what happens with a packet above the routing layer, and that is a totally different prospective than on a host, where you are very concerned about how protocol engines will handle the packets in the layers above routing - and big or variable addresses do not have a neglijible effect here at all - and how the users perceive the hosts behavior at applications level. Hosts also do routing, but much more on exceptional than regular basis, and yes, I am concerned about routing to be done fast too, but tricks that can be played for routing at hardware level are none. Furthermore, on hosts the networking is just a background activity, which has no importace whatsoever by itself, therefore has to take the least amount of time - ideally ZERO - such that enough CPU is left for the main things, that the host is meant to be used for. Going back to variable addresses, you say "I know how to make variable length things in packets go fast. Tony Li told me how!". I do not know what Tony may have told you - but I can speculate. I think it would be accurate to say that you can make the variable length address processing go at various degrees of slow, or fast, whatever word may be preffered, BUT NEVER AS FAST AS FIX address processing of same address size. That's why I am in for fixed size. To an extent, protocol headers are for protocol engines like machine instructions for a CPU. In that respect, network protocol designers and implementors can use or learn from the experience of computer architects, and implementors. Computer architecture technology of the last decade showed that faster machines can be built with a well crafted, reduced set of fix size machine instructions (RISC), where the size of instructions is optimally chosen. Alex p.s. I used to like VAX (CISC) quite a bit. From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 05:10:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05465; Thu, 16 Jun 1994 05:10: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 FAA29644; Thu, 16 Jun 1994 05:10:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA29615; Thu, 16 Jun 1994 04:52:40 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04866; Thu, 16 Jun 1994 04:52:38 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-05.dialip.mich.net (pm002-05.dialip.mich.net [35.1.48.86]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA21197 for ; Wed, 15 Jun 1994 14:52:34 -0400 Date: Wed, 15 Jun 94 15:48:45 GMT From: "William Allen Simpson" Message-Id: <2678.bill.simpson@um.cc.umich.edu> To: big-Internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: variable length everything > From: amolitor@anubis.network.com (Andrew Molitor) > I vote for administrative simplicity, if that means TLV encoded > variable length everythings in the header, with all the fields in > random order, that's ok. The ASICs to shatter a header into its component > atoms and look each atom up in a lookaside buffer will just need a few > more gates. Big Deal. > > Hmm. Is this a host-side guys against a router guys thing? > TLV encoded random order headers would truly suck if you were trying > to get wire speed out of a Sun 3/50. > It's an "expensive special purpose router" versus "everyone else" thing. Whether you know it or not, what people are building into those server, client, and phone ASICs today is an i186, not even an i386! TLV encoded _anything_ in the routing path is a disaster when trying to maintain current wire speed, and the wire speeds are going up. (The person you quoted is demonstrably clueless.) Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 05:26:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02097; Thu, 16 Jun 1994 03:32: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 DAA29383; Thu, 16 Jun 1994 03:31:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA29189; Thu, 16 Jun 1994 02:51:15 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28544; Thu, 16 Jun 1994 02:06:28 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA01666; Wed, 15 Jun 1994 18:05:49 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA12107; Wed, 15 Jun 1994 18:05:47 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406151605.AA12107@dxcoms.cern.ch> Subject: Re: variable length addresses To: bound@zk3.dec.com Date: Wed, 15 Jun 1994 18:05:47 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU (bigi) In-Reply-To: <9406151510.AA27531@xirtlu.zk3.dec.com> from "bound@zk3.dec.com" at Jun 15, 94 11:10:13 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1346 Jim, I am not going to debate your points, fortunately. Brian >--------- Text sent by bound@zk3.dec.com follows: > > Brian, > > => and there are more hosts than routers by at least 2 orders of > => magnitude, but the argument that the routers have to 'go faster' > => may not hold nowadays, when the hosts do mulitmeida, but when only 1% > => traffic is nonlocal... > > >Can't let that go. I should be so lucky as to have 99% locality. > >75% would be high here and multimedia will REDUCE it. One of the > >main reasons we run a big Class B is router performance. We have > >to keep MBONE traffic off the Class B precisely because it has > >zero locality (not 1%, zero). > > But your not going to debate that: > > 1) There are more hosts in the world than routers? > > 2) That the majority of network traffic at most end user > sites that create the major revenue to warrant my job > as a network software engineer is local LAN traffic? > > If so we then have to go back to some basic discussions and get > consensus on variants of folks reality so we can move forward. > > >Routers and hosts must both go at wire speed. It's worse for routers > >because they are connected to multiple wires. > > I have heard no router code writer tell me that theY cannot make fixed > length addresses go at wire speeds. > > /jim > From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 05:37:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04127; Thu, 16 Jun 1994 04: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 EAA29575; Thu, 16 Jun 1994 04:30:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA29540; Thu, 16 Jun 1994 04:16:15 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03661; Thu, 16 Jun 1994 04:16:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01162; Wed, 15 Jun 94 14:15:58 -0400 Date: Wed, 15 Jun 94 14:15:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406151815.AA01162@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: bound@zk3.dec.com Also do you insist on bringing up the past such as what happened when they defined IPv4? "A ship on the beach is a lighthouse to the sea" - Dutch proverb, cited on the title page of the first chapter of "Mythical Man-Month" I could respond by saying there is a protocol in the market that supports variable addresses that has not been wildly successful. But thats not a good technical argument either. A complete design/product/technology succeeds or fails for a complex mix of reasons. It's dangerous to draw inferences about one aspect from the overall success or failure (which is not what I did with my reference to IPv4 addresses). I could just as easily say that CLNP/TP never caught on because it wasn't a big enough step past TCP/IP. (Note: I actually don't think that's the whole answer either as to why CLNP/TP failed - there are many factors.) Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 05:50:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07164; Thu, 16 Jun 1994 05:50: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 FAA29703; Thu, 16 Jun 1994 05:50:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29675; Thu, 16 Jun 1994 05:37:07 +1000 Precedence: list Received: from quern.epilogue.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04735; Thu, 16 Jun 1994 04:48:37 +1000 (from dab@epilogue.com) From: Dave Bridgham Sender: dab@epilogue.com To: bound@zk3.dec.com Cc: big-Internet@munnari.OZ.AU In-Reply-To: bound@zk3.dec.com's message of Wed, 15 Jun 94 11:03:44 -0400 <9406151503.AA27441@xirtlu.zk3.dec.com> Subject: variable length addresses Date: Wed, 15 Jun 94 14:48:03 -0400 Message-Id: <9406151448.aa27427@quern.epilogue.com> Precedence: list From: bound@zk3.dec.com Date: Wed, 15 Jun 94 11:03:44 -0400 X-Mts: smtp Could we keep the terms EID and Locators out of this discussion. I think it will confuse the technical tangents. The problem is that when you say `address' I don't know if you're using address as a locator or an EID. I am very likely to give different answers to the fixed vs variable length question depending on which I think you meant. Maybe I can extract from context which concept you mean and maybe I'll get it wrong. Wouldn't it be easier if we used distinct terms? Dave From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 05:52:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07224; Thu, 16 Jun 1994 05:52: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 FAA29718; Thu, 16 Jun 1994 05:51:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29681; Thu, 16 Jun 1994 05:39:46 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05946; Thu, 16 Jun 1994 05:22:58 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA00334; Wed, 15 Jun 94 12:22:40 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA14667; Wed, 15 Jun 94 12:23:31 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA25068; Wed, 15 Jun 1994 12:22:26 -0700 Date: Wed, 15 Jun 1994 12:22:26 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406151922.AA25068@jurassic.Eng.Sun.COM> To: big-internet@munnari.OZ.AU In-Reply-To: <9406151745.2550@munnari.oz.au> Subject: re: variable length addresses > Note that the *only* difference between IPng-A and IPng-B is that > in IPng-B the length of an address is encoded as part of the address > field. If it should only be so simple. Unfortunately, it affects many things. These include transport connection identification, pseudo checksum calculations, routing, API's, naming systems, error handling, documentation, training, MIB's, etc. Variable length addresses make all of these more complex. > Given that software design, implementation and testing with scenario (a) > takes X man-years, how many man-years (relative to X) it would take > to do software design, implementation and testing with scenario (b) ? The issue is not whether it is possible to support variable length addresses, it is the cost for doing it (complexity, performance, etc.) worth the benefit gained. I believe fixed length addresses will last a very long time and I do not think that the added complexity of variable length addresses is worthwhile. Bob From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 05:53:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07280; Thu, 16 Jun 1994 05: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 FAA29739; Thu, 16 Jun 1994 05:53:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29672; Thu, 16 Jun 1994 05:37:05 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04099; Thu, 16 Jun 1994 04:29:20 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA24223; Wed, 15 Jun 94 11:21:54 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA16775; Wed, 15 Jun 1994 14:21:52 -0400 Date: Wed, 15 Jun 1994 13:57:43 -0400 Message-Id: <94061513574359@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: yakov@watson.ibm.com, big-Internet@munnari.OZ.AU Subject: Re: variable length addresses X-Vms-To: SMTP%"yakov@watson.ibm.com" X-Vms-Cc: SMTP%"big-Internet@munnari.oz.au",CONTA >>but when domestic traffic takes off, and web caching is working right, >>and the net is engineered better, I think you will find that it reverts >>to the telephony pattern. > >If the majority of the Internet users are going to be consumers >(not such an unrealistic assumption), unrealistic is fair, unprobable is in my view perhaps more accurate. Today businesses are the main networking users, and in the future more and more will be networked. They will be most likely connected 24 hours out of 24. Leisure or even appliance type of home netorked activity cannot measure up to that, because of the simple rule "you switch off the light when you leave a room in your house, but you may not when you leave your cubicle". >are going to access the Internet through some dial-up capabilities >(also not such an unrealistic assumption), there will be AT LEAST >one router between the place that wants to access some information, >and the place where the information is stored. > >The factors you mentioned would improve the average number of hops, >but I still think that most of the traffic is going to be nonlocal, >especially if "local" means "local to my house". > >Yakov. Dialing-up is expensive and has few if any alternatives today, when various service providers may be geographically far away, because this is just starting. As "information" is a lucrative business, those service providers will be cloned in every neighborhood, and one's home could likely end on the same fiber subnet with no need for routing. Alex From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 06:12:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08033; Thu, 16 Jun 1994 06: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 GAA29834; Thu, 16 Jun 1994 06:11:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29723; Thu, 16 Jun 1994 05:52:06 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07205; Thu, 16 Jun 1994 05:51:59 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA05957; Wed, 15 Jun 94 12:51:34 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA16466; Wed, 15 Jun 94 12:52:33 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA25904; Wed, 15 Jun 1994 12:50:56 -0700 Date: Wed, 15 Jun 1994 12:50:56 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406151950.AA25904@jurassic.Eng.Sun.COM> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9406151815.AA01162@ginger.lcs.mit.edu> Subject: Re: variable length addresses Noel, > A complete design/product/technology succeeds or fails for a complex mix of > reasons. It's dangerous to draw inferences about one aspect from the overall One of the big reasons for failure is not ever getting it done in the desire to reach perfection. Bob From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 06:14:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08061; Thu, 16 Jun 1994 06:14: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 GAA29849; Thu, 16 Jun 1994 06:14:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA29808; Thu, 16 Jun 1994 06:02:11 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07658; Thu, 16 Jun 1994 06:02:06 +1000 (from yakov@watson.ibm.com) Message-Id: <9406152002.7658@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 7309; Wed, 15 Jun 94 16:02:05 EDT Date: Wed, 15 Jun 94 16:01:14 EDT To: Bob.Hinden@Eng.Sun.COM, big-internet@munnari.OZ.AU Subject: variable length addresses Ref: Your note of Wed, 15 Jun 1994 12:22:26 -0700 Bob, >>Given that software design, implementation and testing with scenario (a) >>takes X man-years, how many man-years (relative to X) it would take to >>do software design, implementation and testing with scenario (b) ? > >The issue is not whether it is possible to support variable length >addresses, it is the cost for doing it worth the benefit gained. I believe >fixed length addresses will last a very long time and I do not think >that the added complexity of variable length addresses is worthwhile. You still didn't answer the question I asked -- how many man-years (relative to X) it would take to do software design implementation and testing with scenario (b) ? Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 06:15:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08126; Thu, 16 Jun 1994 06:15: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 GAA29864; Thu, 16 Jun 1994 06:15:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA29820; Thu, 16 Jun 1994 06:08:42 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07972; Thu, 16 Jun 1994 06:08:39 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA01744; Wed, 15 Jun 94 13:04:01 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA17030; Wed, 15 Jun 1994 16:03:59 -0400 Date: Wed, 15 Jun 1994 15:55:16 -0400 Message-Id: <94061515551587@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: variable length addresses X-Vms-To: SMTP%"jnc@ginger.lcs.mit.edu" X-Vms-Cc: SMTP%"big-internet@munnari.oz.au",CONTA From: SMTP%"jnc@ginger.lcs.mit.edu" 15-JUN-1994 15:19:00.19 > > From: kck@netcom.com (Richard Fox) > > Its bad enough now for people to deal with 4 byte IP addresses, what will > happen if they are given 4, 8 and 16 byte addresses tod eal with? Esp. if > we need new notations for each. And as bad as this will get, variable > addresses will be a total nightmare to administer. > >Really? People seem to manage DNS names (variable lengths, variable numbers >of levels) quite well. Today, managing DNS is a different level than specifying IP addresses, network masks, subnet masks, broadcast masks, etc... how many do DNS versus how many do the simple stuff - a poll would show probably a ratio of 1/30 if not 1/50, or better, so I guess I would concur with Richard and try to keep internet address handling at the current level, rather than bringing it to the level of DNS. Alex From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 06:52:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07508; Thu, 16 Jun 1994 05:55: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 FAA29765; Thu, 16 Jun 1994 05:55:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29695; Thu, 16 Jun 1994 05:40:04 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01376; Thu, 16 Jun 1994 03:18:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00503; Wed, 15 Jun 94 13:18:24 -0400 Date: Wed, 15 Jun 94 13:18:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406151718.AA00503@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: bound@zk3.dec.com Could we keep the terms EID and Locators out of this discussion. ... If we can figure out whether IPng can solve the problem with fixed length address or variable length address is the issue and discussion. Unfortunately, Jim, not everyone agrees that this is the question. I.e. not everyone thinks that IPng should look like IPv4, just with *either* larger, or variable length, addresses! (I personally find *either* option unappealing.) The chief difference between a locator and an address (and the reason we defined a whole new term) is *not* splitting the transport identification from the internetwork layer location function. Rather, it was because some people were visualizing designs in which that location function is not carried in every packet. Since many people had this strong mindset that an "address" is in every packet, and is the field that routers look at to forward packets, it led to very confusing discussions. Hence the explicit definition of "locator" to mean a location-sensitive name which *is not* carried in every packet. I write code for Host kernels and variable addresses are not free and will not perform as fast as fixed length addresses Depending on the design and constraints, this is not necessarily true. For instance, if you have a VanJ type "header prediction" algorithm going (as you proabbly would if you were trying to squeeze the last drop of performance), for the connection which is being "predicted", you can treat a variable length address as a fixed length field, which it is, *for that connection*. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 06:52:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08302; Thu, 16 Jun 1994 06:18: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 GAA29879; Thu, 16 Jun 1994 06:17:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29729; Thu, 16 Jun 1994 05:52:51 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07253; Thu, 16 Jun 1994 05:52:46 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA00445; Wed, 15 Jun 94 12:45:48 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA17000; Wed, 15 Jun 1994 15:45:46 -0400 Date: Wed, 15 Jun 1994 15:11:54 -0400 Message-Id: <94061515115390@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: variable length addresses X-Vms-To: SMTP%"jnc@ginger.lcs.mit.edu" X-Vms-Cc: SMTP%"big-internet@munnari.oz.au",CONTA >From: SMTP%"jnc@ginger.lcs.mit.edu" 15-JUN-1994 14:50:35.03 > >If you have a variable length internetwork header (be it from addresses or >whatever), the cost from that to upper layers, in the most general >implementation, seems to be i) an extra pointer register, and ii) two >instructions; one to extract the header length length, and one to add it to >the old pointer, and store the result in the new pointer. (On some >architectures, the latter may turn into two instructions, I guess.) This is only the additional work related to referencing the addresses in the header, which in fact is the least expensive. There are many other parts that are more expensive, such as the address match, and the machanisms related to passing, and storing the variable size address parameters - always have to pass two parameters rather than one, always store the length, besides the pointer or the address itself, etc... >Optimized code can use tricks like the header compression I mentioned to get >rid of even that. I reject header compression from the start - I would consider that only for exceptional cases and more like an act of desperation. In fact the added cost of compressing/decompressing may not amortize the savings. >Of course, if you're trying to lay the data down on a page >boundary, it can mess you up, but if you only have one of those applications >running at a time you can make it work. Remember I am talking about hosts, where practically most applications are networked, the file system is networked, the printing is networked, and so on.... >Obviously, packet setup in the internetwork layer can be more expensive, e.g. >if you can't use an unrolled loop to copy the addresses around. Address match is even more expensive than packet setup, since it multiplies at internet layer with number of routing table entries, and/or interface addresses, and at transport layer with the number of sockets. >are ways to deal with this; e.g. you can reuse packet buffers, eliminating the >address copy completely. Etc, etc, etc. I guess you refer to what one can do to optimize in general the protocol engines. But this has been long done, so I do not want any additional cost that does not have a sound and irrefutable justification. Alex From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 06:52:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07556; Thu, 16 Jun 1994 05: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 FAA29780; Thu, 16 Jun 1994 05:57:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29678; Thu, 16 Jun 1994 05:37:31 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04440; Thu, 16 Jun 1994 04:41:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01381; Wed, 15 Jun 94 14:41:15 -0400 Date: Wed, 15 Jun 94 14:41:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406151841.AA01381@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, conta@ucx.lkg.dec.com Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) that is a totally different prospective than on a host, where you are very concerned about how protocol engines will handle the packets in the layers above routing - and big or variable addresses do not have a neglijible effect here at all If you have a variable length internetwork header (be it from addresses or whatever), the cost from that to upper layers, in the most general implementation, seems to be i) an extra pointer register, and ii) two instructions; one to extract the header length length, and one to add it to the old pointer, and store the result in the new pointer. (On some architectures, the latter may turn into two instructions, I guess.) Optimized code can use tricks like the header compression I mentioned to get rid of even that. Of course, if you're trying to lay the data down on a page boundary, it can mess you up, but if you only have one of those applications running at a time you can make it work. Obviously, packet setup in the internetwork layer can be more expensive, e.g. if you can't use an unrolled loop to copy the addresses around. However, there are ways to deal with this; e.g. you can reuse packet buffers, eliminating the address copy completely. Etc, etc, etc. To an extent, protocol headers are for protocol engines like machine instructions for a CPU. In that respect, network protocol designers and implementors can use or learn from the experience of computer architects, and implementors. Computer architecture technology of the last decade showed that faster machines can be built with a well crafted, reduced set of fix size machine instructions (RISC), where the size of instructions is optimally chosen. There's one important difference that affects how useful this design aphorism is over here in networking. If I decided to change my CPU for one with a different architecture, you can keep using yours. The same is not true of a globally ubiquitous protocol (and I don't really believe that "design it to evolve" is really going to buy us as much as people might hope). Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 06:54:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08846; Thu, 16 Jun 1994 06:32: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 GAA29907; Thu, 16 Jun 1994 06:32:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29729; Thu, 16 Jun 1994 05:52:51 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07253; Thu, 16 Jun 1994 05:52:46 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA00445; Wed, 15 Jun 94 12:45:48 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA17000; Wed, 15 Jun 1994 15:45:46 -0400 Date: Wed, 15 Jun 1994 15:11:54 -0400 Message-Id: <94061515115390@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: variable length addresses X-Vms-To: SMTP%"jnc@ginger.lcs.mit.edu" X-Vms-Cc: SMTP%"big-internet@munnari.oz.au",CONTA >From: SMTP%"jnc@ginger.lcs.mit.edu" 15-JUN-1994 14:50:35.03 > >If you have a variable length internetwork header (be it from addresses or >whatever), the cost from that to upper layers, in the most general >implementation, seems to be i) an extra pointer register, and ii) two >instructions; one to extract the header length length, and one to add it to >the old pointer, and store the result in the new pointer. (On some >architectures, the latter may turn into two instructions, I guess.) This is only the additional work related to referencing the addresses in the header, which in fact is the least expensive. There are many other parts that are more expensive, such as the address match, and the machanisms related to passing, and storing the variable size address parameters - always have to pass two parameters rather than one, always store the length, besides the pointer or the address itself, etc... >Optimized code can use tricks like the header compression I mentioned to get >rid of even that. I reject header compression from the start - I would consider that only for exceptional cases and more like an act of desperation. In fact the added cost of compressing/decompressing may not amortize the savings. >Of course, if you're trying to lay the data down on a page >boundary, it can mess you up, but if you only have one of those applications >running at a time you can make it work. Remember I am talking about hosts, where practically most applications are networked, the file system is networked, the printing is networked, and so on.... >Obviously, packet setup in the internetwork layer can be more expensive, e.g. >if you can't use an unrolled loop to copy the addresses around. Address match is even more expensive than packet setup, since it multiplies at internet layer with number of routing table entries, and/or interface addresses, and at transport layer with the number of sockets. >are ways to deal with this; e.g. you can reuse packet buffers, eliminating the >address copy completely. Etc, etc, etc. I guess you refer to what one can do to optimize in general the protocol engines. But this has been long done, so I do not want any additional cost that does not have a sound and irrefutable justification. Alex From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 06:54:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09311; Thu, 16 Jun 1994 06:44: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 FAA29780; Thu, 16 Jun 1994 05:57:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29678; Thu, 16 Jun 1994 05:37:31 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04440; Thu, 16 Jun 1994 04:41:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01381; Wed, 15 Jun 94 14:41:15 -0400 Date: Wed, 15 Jun 94 14:41:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406151841.AA01381@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, conta@ucx.lkg.dec.com Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) that is a totally different prospective than on a host, where you are very concerned about how protocol engines will handle the packets in the layers above routing - and big or variable addresses do not have a neglijible effect here at all If you have a variable length internetwork header (be it from addresses or whatever), the cost from that to upper layers, in the most general implementation, seems to be i) an extra pointer register, and ii) two instructions; one to extract the header length length, and one to add it to the old pointer, and store the result in the new pointer. (On some architectures, the latter may turn into two instructions, I guess.) Optimized code can use tricks like the header compression I mentioned to get rid of even that. Of course, if you're trying to lay the data down on a page boundary, it can mess you up, but if you only have one of those applications running at a time you can make it work. Obviously, packet setup in the internetwork layer can be more expensive, e.g. if you can't use an unrolled loop to copy the addresses around. However, there are ways to deal with this; e.g. you can reuse packet buffers, eliminating the address copy completely. Etc, etc, etc. To an extent, protocol headers are for protocol engines like machine instructions for a CPU. In that respect, network protocol designers and implementors can use or learn from the experience of computer architects, and implementors. Computer architecture technology of the last decade showed that faster machines can be built with a well crafted, reduced set of fix size machine instructions (RISC), where the size of instructions is optimally chosen. There's one important difference that affects how useful this design aphorism is over here in networking. If I decided to change my CPU for one with a different architecture, you can keep using yours. The same is not true of a globally ubiquitous protocol (and I don't really believe that "design it to evolve" is really going to buy us as much as people might hope). Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 06:54:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07628; Thu, 16 Jun 1994 06:00: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 FAA29797; Thu, 16 Jun 1994 05:59:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA29698; Thu, 16 Jun 1994 05:40:54 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05767; Thu, 16 Jun 1994 05:19:03 +1000 (from rharris@espresso.rt.cs.boeing.com) Received: by atc.boeing.com (5.57) id AA11655; Wed, 15 Jun 94 12:21:02 -0700 Received: from spook.network-b by espresso.rt.cs.boeing.com (4.1/SMI-4.1) id AA12232; Wed, 15 Jun 94 12:18:41 PDT Date: Wed, 15 Jun 94 12:18:41 PDT From: "Richard L. Harris (206) 865-4922" Message-Id: <9406151918.AA12232@espresso.rt.cs.boeing.com> To: bound@zk3.dec.com Subject: identifiers and security [was: Re: Merging Routing Header] Cc: sipp@sunroof2.Eng.Sun.COM, saag@tis.com, big-Internet@munnari.OZ.AU, ericf@atc.boeing.com Jim, Some comments from a security viewpoint to your message and to the lists in general about addressing and identifiers. Purposely cross posted to big-internet and saag BUT if anyone replies please post to sipp only. Rich Harris (206) 865-4922 rharris@atc.boeing.com Boeing Computer Services > Whether its EIDs or IADs or just IPng addresses we need to define how > they are created and need an assignment plan. I have kept all messages > for the past 3 weeks on EIDs. I am going to try and read them all and > come with some idea. But I won't call them EIDs. > Please consider making the security issues involved with identifiers a high profile item in anything that you produce. > of a pain) my point is that cost is the issue and is the cost > necessary. > Please consider the costs of not doing good flexible identification. For security the costs can be very high. {Aside: ditto managment.} > >(a) filtering on address (which is used today quite widely) becomes > > problematic -- are you filtering on the identifying address, on > > extended address, or on both ? > I will presume that you are including filtering for security purposes, [firewalls especially,] but would like this explicitly acknowledged. Full identification may be done in every packet, once per flow setup, or never if it exists implicitly or can be deduced due to some basic properties of being an ipng header/address/identifier. I don't care how, it just needs to happen. I have been a lurker and will probably remain so but: Security ought to be a major criterion for the decision and discussion. I have seen very little consideration of securtiy ramifications expressed here over the last couple of months (sipp and big-internet). Identifiers are critical to Identification. Identification is critical to Authentication. Authenticatied identities are critical to Authorization (setup &) decision makeing. Authorization (& Identification and Authentication) are critical to `Access Control. Globaly significant identities are critical for distributed computing audit services and administration (management) services. A single identification scheme with identifiers that are both globaly unique and consistently mappable to the entity being identified seems to be, (at least in Boeings efforts to build a distributed systems security architecture,) a necessary prerequisite to being ABLE TO DO distributed security. (They are also needed in order for security to be reasonable, managable, cost effective, and user friendly enough.) Is the saag liaison listening? Eric Flieschmann represents Boeing both on this list and to the IETF as a whole. I am not taking an official Boeing position but I am raising a concern that the recent discussions don't seem to include ANY security considerations or concerns. Rich ------------------ Full copy of the triggering message follows. ------------------ > > From sipp-request@sunroof2.Eng.Sun.COM Tue Jun 14 20:40:37 1994 > To: yakov@watson.ibm.com > Cc: sipp@sunroof2.Eng.Sun.COM > Subject: Re: Merging Routing Header > Date: Tue, 14 Jun 94 23:21:25 -0400 > From: bound@zk3.dec.com > X-Mts: smtp > Sender: sipp-request@sunroof.Eng.Sun.COM > Content-Length: 4502 > > Yakov, > > Sorry for the late reply I was trying to set up our firewall to test our > SIPP code base with other implementors. My first experience and making > lots of errors. > > [THe node name at one of our SIPP Internet points will be sipper I was > going to go with deering but figured that might be a node name already, > hope to have on in Australia - hey lets figure this out so se can back > to writing code isn't the saying rough consensus and running code???] > > >>I think there are two distinct issues to be discussed: > >>(1) Whether unicast addresses carried in a packet should be of fixed > >> length > >>(2) Whether 16 octets as the fixed length or 16 octets as an upper > >> bound for a variable length is sufficient. > > > >It seems your setting up a political position and not a technical one in > >the discussion. > > >I beg your pardon. I failed to see "a political position", but I clearly > >see two technical issues: > > I took your mail to take me off the main point of my concern of doing > variable addresses and on to another point. It would have been more > clear to say that this is changing the point I want to discuss, could we > stick on that. Sorry. > > >(a) fixed vs variable length addresses > > OK I have no technical issue with variable addresses (but they are a bit > of a pain) my point is that cost is the issue and is the cost > necessary. > > >(b) max size of the address space (due to 16 bytes length) > > Yes. > > >Would you please elaborate on why do you think the above is political ? > > I answered the political question above. > > The subject is cost. Is variable addresses cost justified to implement > in products. > > Having read ahead and seen Bob Hinden's mail and if I accept that then > its not at all. 16bytes are plenty for at least 35 years. > > The cost is not justified in my mind. And though I do not speak for my > company at this time I do make recommendations to them and if we were to > have a position I would recommend that we not support the movement to > variable network layer addresses for TCP/IP --> IPng based on the > various discussions in the IETF and my own technical judgement. Its not > cost justified. > > =>Christian's example uses the SIPP ASEQ record from SIPP ROAD. > > >Please recall that in the SIPP ROAD document ASEQ is used for BOTH > >extended addresses AND for source routes with no way to distinguish > >between the two. That presents few problems, such as: > > >(a) filtering on address (which is used today quite widely) becomes > > problematic -- are you filtering on the identifying address, on > > extended address, or on both ? > > >(b) how do you support source routes that intermixes unicast > > addresses (which may be in extended format) and anycast > > addresses (aka "cluster addresses") ? > > >(c) how do you support both strict and loose source route ? > > >The above is by no means complete, but it shows some of the issues > >associated with the SIPP routing header in general and ASEQ in particular. > >So, before advocating going back to "what SIPP ASEQ record were defined" > >(as you suggested in your reply to Frank Kastenholz) I would suggest > >we look at the issues I listed above. > > I agree so lets see if we can make it work. > > =>we agreed that the transport would only depend on the low order > =>8 bytes as the identifying address. > > >If we use 16 octets fixed length addresses, your message implies > >that the lower order 8 octets of such an address have to be globally > >unique (or otherwise, you can't use it as an EID for your transport). > >What are the mechanisms to maintain global uniqueness of the > >lower order 8 octets of a SIPP address ? > > That was the discussion before the IPng retreat. I believe we had come > to the conclusion that IEEE addresses would not work by themselves. > Then it was suggested vendors assign them and I don't like that. But > then the IPng Retreat happened. > > Whether its EIDs or IADs or just IPng addresses we need to define how > they are created and need an assignment plan. I have kept all messages > for the past 3 weeks on EIDs. I am going to try and read them all and > come with some idea. But I won't call them EIDs. > > =>Please do not use IEEE addresses in these references. They are > =>not globally unique. If you 100% sure they are say that to this > =>list, or else do not use them for anything but a local address > > >I've been referring to the use of IEEE addresses as being just > >a part of a globally unique address. Using them as part of an address > >simplifies autoconfiguration. > > OK but that does use up 6bytes. Not sure that is good yet. > > /jim > From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 07:12:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10183; Thu, 16 Jun 1994 07:12: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 HAA29977; Thu, 16 Jun 1994 07:12:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA29961; Thu, 16 Jun 1994 07:01:34 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09994; Thu, 16 Jun 1994 07:01:31 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA05534; Wed, 15 Jun 94 13:56:56 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA17173; Wed, 15 Jun 1994 16:56:54 -0400 Date: Wed, 15 Jun 1994 16:41:49 -0400 Message-Id: <94061516414922@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: yakov@watson.ibm.com, big-Internet@munnari.OZ.AU Subject: Re: variable length addresses X-Vms-To: SMTP%"yakov@watson.ibm.com" X-Vms-Cc: SMTP%"big-Internet@munnari.oz.au",CONTA >From: SMTP%"yakov@watson.ibm.com" 15-JUN-1994 13:37:37.93 > >I think we've already seen data from router vendors that wire speed >can be attained with both fixed and variable length addresses. Yakov, This is a fair statement. Thanks. I feel at times that at an extent this debate is like the town hall meeting where the republican senator speaks about Clinton's health plan... Without taking away the known and aknowledged merits of variable addresses, is anyone debating the statement that processing a fixed address is simplier and faster than processing a variable address? Alex From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 07:14:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10205; Thu, 16 Jun 1994 07:14: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 HAA29992; Thu, 16 Jun 1994 07:13:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA29947; Thu, 16 Jun 1994 06:53:18 +1000 Precedence: list Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09087; Thu, 16 Jun 1994 06:38:35 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA02358; Wed, 15 Jun 94 16:37:04 EDT Message-Id: <9406152037.AA02358@tipper.oit.unc.edu> To: Jon Crowcroft Cc: "James 'J' Allard" , atkinson@itd.nrl.navy.mil, owner-Big-Internet@munnari.OZ.AU, big-Internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 94 09:11:44 BST." <9406150813.9845@munnari.oz.au> Date: Wed, 15 Jun 94 16:37:03 -0400 From: Simon E Spero >>>>> "Jon" == Jon Crowcroft writes: Jon> as far as i can see, if an address is 'big enough', there are Jon> no pro's to having it variable, Well, it all depends on whether 2^64 is a suitable definition of infinity.. it's kind of like lisp vs C for integers - in lisp, if a result won't fit in a fixnum, it rolls over into a bignum; with C, the number just rolls over and plays dead. To take the analogy a step further, lisp compilers optimise for the fixnum case and treat bignum overflow as an exceptional case; the same approach could be applied to variable length addresses, with the 64 bit case optimised for, and larger addresses stuck somewhere out of the way where they won't do any harm. I think this is what SIPP tries to do, but I'm not 100% convinced yet (I haven't coded the routing header stuff yet) Simon // Currently in Essex and enjoying the priviledge of my first Labour // member of anything.. From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 07:53:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11692; Thu, 16 Jun 1994 07:53: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 HAA00194; Thu, 16 Jun 1994 07:53:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA00172; Thu, 16 Jun 1994 07:44:58 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09587; Thu, 16 Jun 1994 06:51:29 +1000 (from jdemarco@ftp.com) Received: by ftp.com ; Wed, 15 Jun 1994 16:50:02 -0400 Received: by ftp.com ; Wed, 15 Jun 1994 16:50:02 -0400 Date: Wed, 15 Jun 1994 16:50:02 -0400 From: jdemarco@ftp.com (Jim DeMarco) Message-Id: <9406152050.AA28419@ftp.com> To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.OZ.AU, bound@zk3.dec.com, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Wed, 15 Jun 94 13:18:24 -0400 <9406151718.AA00503@ginger.lcs.mit.edu> Subject: variable length addresses Reply-To: jdemarco@ftp.com > I write code for Host kernels and variable addresses are not free and will > not perform as fast as fixed length addresses > >Depending on the design and constraints, this is not necessarily true. For >instance, if you have a VanJ type "header prediction" algorithm going (as you >proabbly would if you were trying to squeeze the last drop of performance), >for the connection which is being "predicted", you can treat a variable length >address as a fixed length field, which it is, *for that connection*. ^^^^^^^ (I assume you're referring to a locator here) Is this necessarily true? Would it not be possible for, say, a mobile host (whose variable-length-locator-address is changing) to screw up such header prediction? Or can we assume that the locator-address *length* will remain constant even if the locater-address changes? --Jim From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 08:32:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11659; Thu, 16 Jun 1994 07:52: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 HAA00178; Thu, 16 Jun 1994 07:52:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA00175; Thu, 16 Jun 1994 07:45:11 +1000 Precedence: list Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11429; Thu, 16 Jun 1994 07:45:06 +1000 (from barney@databus.databus.com) Date: Wed, 15 Jun 94 17:52 EDT Message-Id: <9406151752.AA02781@databus.databus.com> From: Barney Wolff To: big-Internet@munnari.OZ.AU Subject: Re: variable length addresses Content-Length: 313 Content-Type: text >From: SMTP%"yakov@watson.ibm.com" 15-JUN-1994 13:37:37.93 > >I think we've already seen data from router vendors that wire speed >can be attained with both fixed and variable length addresses. What is the official definition of "wire speed"? Ethernet? T1? T3? FDDI? OC12? Barney Wolff From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 08:33:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11905; Thu, 16 Jun 1994 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 HAA00220; Thu, 16 Jun 1994 07:55:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA00153; Thu, 16 Jun 1994 07:35:54 +1000 Precedence: list Received: from FRED.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08793; Thu, 16 Jun 1994 06:29:24 +1000 (from craig@BBN.COM) Message-Id: <9406152029.8793@munnari.oz.au> To: Noel Chiappa To: big-internet@munnari.OZ.AU, bound@zk3.dec.com Subject: Re: variable length addresses Date: Wed, 15 Jun 94 16:22:22 -0400 From: Craig Partridge > I write code for Host kernels and variable addresses are not free and will > not perform as fast as fixed length addresses > > Depending on the design and constraints, this is not necessarily true. For > instance, if you have a VanJ type "header prediction" algorithm going (as you > proabbly would if you were trying to squeeze the last drop of performance), > for the connection which is being "predicted", you can treat a variable length > address as a fixed length field, which it is, *for that connection*. Noel: Predictions work only if when writing the code you can predict that some 95+% of the time the address will be of a certain length. For header processing, there's a huge penalty in going back for the memory that contains the address info you missed, and there's a smaller but also severe penalty for loading too much memory with excess info. In routers, you can really optimize processor performance on the header if you always know how big the header is. In hosts, you can optimize both the header processing and (usually) the buffer management if you always know how big things are. Craig From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 08:33:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11946; Thu, 16 Jun 1994 07:57: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 HAA00235; Thu, 16 Jun 1994 07:57:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA00156; Thu, 16 Jun 1994 07:37:48 +1000 Precedence: list Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08931; Thu, 16 Jun 1994 06:35:22 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA28856; Wed, 15 Jun 94 15:39:34 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA16321; Wed, 15 Jun 94 15:35:13 CDT Date: Wed, 15 Jun 94 15:35:13 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9406152035.AA16321@anubis.network.com> To: big-internet@munnari.OZ.AU Subject: Re: variable length addresses An engineering estimate, eh? Let's say, to give us something to argue about, that we had an IPv4 header except that the source and destination addreses were encoded as variable length fields with, say, a 1 octet length followed by N octets of address. I think this would add something like an engineering week to the development cycle of a typical router, including testing. Add another month or so if you want to build good hardware assist for this header structure as opposed to IPv4, and add a few bucks per interface to the cost since you'll need to get some gates, and gates aren't free. It's probably quite a lot more effort to back-patch an existing IPv4 implementation to an address format like this, though perhaps less than the total effort required to reimplement from scratch. These estimates are guesses at how much longer it would take do an IPv4-funny-addresses than to do an IPv4 implementation, from scratch. As has been pointed out, at the host end it's more expensive, since there are APIs and whatnot to take in to consideration. Still, the overall effort inherent purely in making one particular kind of header field variable length is trivial. Andrew From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 08:34:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11985; Thu, 16 Jun 1994 07:59: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 HAA00250; Thu, 16 Jun 1994 07:59:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA00149; Thu, 16 Jun 1994 07:34:17 +1000 Precedence: list Received: from Princeton.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07719; Thu, 16 Jun 1994 06:03:48 +1000 (from jwagner@Princeton.EDU) Received: from ponyexpress.Princeton.EDU by Princeton.EDU (5.65b/2.111/princeton) id AA00694; Wed, 15 Jun 94 15:23:50 -0400 Received: from clytemnestra.Princeton.EDU by ponyexpress.princeton.edu (5.65c/1.113/newPE) id AA21823; Wed, 15 Jun 1994 15:23:48 -0400 Received: by clytemnestra.Princeton.EDU (4.1/Phoenix_Cluster_Client) id AA11651; Wed, 15 Jun 94 15:23:47 EDT Message-Id: <9406151923.AA11651@clytemnestra.Princeton.EDU> To: big-internet@munnari.OZ.AU Subject: Re: lower 8 bits of 8+8 format In-Reply-To: Your message of "Sat, 11 Jun 1994 12:15:29 +0200." <9406110315.AA07120@necom830.cc.titech.ac.jp> X-Mailer: exmh version 1.4zeta 6/10/94 Date: Wed, 15 Jun 1994 15:23:45 EDT From: John Wagner >> = Noel Chiappa > = Masataka Ohta > > The reason is that the *whole point* of EID's is to have names *which do not > > depend on location at all*. > > Agreed. So, if some part of EID is used for locator, it is only for > FLAT routing at the lowest routing level. > > > I.e., you can pick the endpoint up, and move it > > *anywhere*, and it still uses only that exact same EID to identify that > > endpoint. (I know your suggestion doesn't do this, > > Yes, if the endpoint is moved to different routing domain, upper level > identifiers in locator, which share nothing with EID, will be used. But this doesn't save you any bits, because you cannot use the bits out of the EID to act as the final part of the locator. Those bits will have to be duplicated into the locator. If you have two routing domains, A and B, both of which are using some part of the EID for the locator in the final flat routing, then a process cannot migrate from domain A to domain B because the EID must be changed to match the requirements of the new flat routing. If all you do is use the flat routing bits to create the initial EID but never look at it for routing then there will be no problem. But since you must be able to have multiple EIDs terminating in the same physical machine you must have bits beyond the flat routing info available to the generation process. And since the EID must be unique you still need some sort of registry. And since you have to contact the registry either way, why not simply have the registry assign the number by some algorithm and specify that no routing can be done? Any structure to the EID is likely to lead to software making assumptions that are inappropriate. John Wagner From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 09:07:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13469; Thu, 16 Jun 1994 08:34: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 IAA00306; Thu, 16 Jun 1994 08:34:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA00284; Thu, 16 Jun 1994 08:21:19 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12853; Thu, 16 Jun 1994 08:21:12 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 15 Jun 1994 18:21:09 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 15 Jun 1994 18:21:09 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA23704; Wed, 15 Jun 94 18:19:24 EDT Date: Wed, 15 Jun 94 18:19:24 EDT Message-Id: <9406152219.AA23704@mailserv-D.ftp.com> To: barney@databus.com Subject: Re: variable length addresses From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-Internet@munnari.OZ.AU Content-Length: 1369 > >I think we've already seen data from router vendors that wire speed > >can be attained with both fixed and variable length addresses. > > What is the official definition of "wire speed"? Ethernet? T1? T3? > FDDI? OC12? depends on who the official definer is. the criteria document (which is waiting for one of the ipng directors to review it) says something to the effect of: "a state of the art, commercial grade, router must be able to forward packets at speeds capable of fully utilizing common, commercial grade, high-speed media" 'commercial grade' typically would mean something that is available as a standard item, off the shelf, from one of the major router/media vendors. 'state of the art' would imply the latest release of the latest product... we couldn't give a specific media or speed. that would imply that we (craig partridge and i) know what the common media of the future will be... also, we have to remember that the future holds things that no one can predict. think of how this criterion would read if we were doing it for ipv4 in the late 70s -- what was 'high speed' commercial grade networking at the time? 9600 baud rs232 lines? :-) we could say 'fddi' or 'oc12' or '155mb atm' or whatever... but what will be common in 2004? -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 09:07:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14464; Thu, 16 Jun 1994 08:54: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 IAA00343; Thu, 16 Jun 1994 08:54:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA00337; Thu, 16 Jun 1994 08:48:44 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12026; Thu, 16 Jun 1994 08:00:53 +1000 (from valdis@black-ice.cc.vt.edu) Received: (valdis@localhost) by black-ice.cc.vt.edu (8.6.8.1/8.6.7) id RAA20611; Wed, 15 Jun 1994 17:59:33 -0400 Message-Id: <199406152159.RAA20611@black-ice.cc.vt.edu> To: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) Cc: yakov@watson.ibm.com, big-Internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 1994 16:41:49 EDT." <94061516414922@ucx.lkg.dec.com> From: Valdis.Kletnieks@vt.edu Date: Wed, 15 Jun 1994 17:59:33 +22306356 Sender: valdis@black-ice.cc.vt.edu On Wed, 15 Jun 1994 16:41:49 EDT, you said: > Without taking away the known and aknowledged merits of variable > addresses, is anyone debating the statement that processing a > fixed address is simplier and faster than processing a variable address? I don't think anybody is debating that fixed is theoretically faster. The debate is "is it sufficiently faster to disregard other benefits that variable gets us"? If fixed is 1% faster but variable gives up 15% more benefits, that's something to consider... /Valdis From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 09:07:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14567; Thu, 16 Jun 1994 08: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 IAA00369; Thu, 16 Jun 1994 08:55:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA00340; Thu, 16 Jun 1994 08:52:24 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12036; Thu, 16 Jun 1994 08:01:57 +1000 (from yakov@watson.ibm.com) Message-Id: <9406152201.12036@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9431; Wed, 15 Jun 94 18:01:55 EDT Date: Wed, 15 Jun 94 17:53:57 EDT To: conta@ucx.lkg.dec.com, big-Internet@munnari.OZ.AU Subject: variable length addresses Ref: Your note of Wed, 15 Jun 1994 16:41:49 -0400 Alex, >is anyone debating the statement that processing a fixed address >is simpler and faster than processing a variable address. Speaking for myself, I don't debate the above statement with respect to "simpler" aspect. With respect to "faster" I would like to point out that with fixed length addresses you *always* use the max length, even if you don't need it (Christian made this point today in his e-mail). On the other hand, with variable length addresses, I may use shorter address (e.g. 8 octets), rather than always use max length (e.g. 16 octets). That may have some impact on "faster" aspect. However, when comparing two choices, (a) -- fixed, and (b) -- variable, in my mind the most important point is NOT a qualitative statement that (a) is "simpler and faster" than (b), but some numbers that would provide an estimate of the difference. Would you agree with this ? Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 09:15:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15551; Thu, 16 Jun 1994 09: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 JAA00414; Thu, 16 Jun 1994 09:14:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA00389; Thu, 16 Jun 1994 09:07:39 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15147; Thu, 16 Jun 1994 09:07:33 +1000 (from yakov@watson.ibm.com) Message-Id: <9406152307.15147@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 0395; Wed, 15 Jun 94 19:07:32 EDT Date: Wed, 15 Jun 94 19:05:39 EDT To: dcrocker@Mordor.Stanford.EDU Cc: big-internet@munnari.OZ.AU Subject: variable length addresses Ref: Your note of Wed, 15 Jun 94 15:39:15 -0700 Dave, >...neither is allowed to be slow. We are in violent agreement. Let me repeat what I said before -- when optimizing performance we need to look at a global picture that includes both hosts AND routers. Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 09:18:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15801; Thu, 16 Jun 1994 09:18: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 JAA00444; Thu, 16 Jun 1994 09:18:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA00408; Thu, 16 Jun 1994 09:13:14 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13796; Thu, 16 Jun 1994 08:41:15 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id PAA24495; Wed, 15 Jun 1994 15:39:52 -0700 Date: Wed, 15 Jun 1994 15:39:52 -0700 From: Tony Li Message-Id: <199406152239.PAA24495@lager.cisco.com> To: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) Cc: yakov@watson.ibm.com, big-Internet@munnari.OZ.AU Subject: Re: variable length addresses Without taking away the known and aknowledged merits of variable addresses, is anyone debating the statement that processing a fixed address is simplier and faster than processing a variable address? Not at all. However, the additional cost in the high-performance path is something like 4 instructions. Seems like cheap insurance to me. Tony Li Demonstrably Clueless From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 09:21:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15923; Thu, 16 Jun 1994 09:21: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 JAA00459; Thu, 16 Jun 1994 09:20:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA00411; Thu, 16 Jun 1994 09:13:44 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13736; Thu, 16 Jun 1994 08:39:40 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id PAA29010; Wed, 15 Jun 1994 15:39:16 -0700 Message-Id: <199406152239.PAA29010@Mordor.Stanford.EDU> To: yakov@watson.ibm.com Cc: J.Crowcroft@cs.ucl.ac.uk, amolitor@anubis.network.com, big-Internet@munnari.OZ.AU Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: variable length addresses Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 15 Jun 94 08:00:33 -0400. <9406151204.18579@munnari.oz.au> Date: Wed, 15 Jun 94 15:39:15 -0700 From: Dave Crocker X-Mts: smtp ---- Included message: I'd like to point out that the Internet is turning into the Information market (and it is doing this quite successfully). In such an environment the information is all over the net, and if the predominant use of the net is for the information retrieval, then I don't see how "only 1% traffic" is going to be nonlocal. Your challenge is reasonable. On the other hand, there is a remarkably long and consistent history in both human and networking communication to see high locality of reference. So, at some level, the answer to your question is "because that's the way people use things". On the other hand, debating which needs to be faster, routers or hosts , probably isn't very productive, since the demands of real-time mean that neither is allowed to be slow. d/ From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 09:37:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15754; Thu, 16 Jun 1994 09:17: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 JAA00429; Thu, 16 Jun 1994 09:16:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA00405; Thu, 16 Jun 1994 09:12:09 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13145; Thu, 16 Jun 1994 08:27:32 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id PAA28922; Wed, 15 Jun 1994 15:27:20 -0700 Message-Id: <199406152227.PAA28922@Mordor.Stanford.EDU> To: Brian.Carpenter@cern.ch Cc: big-internet@munnari.OZ.AU (bigi) Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: Address mapping (long) Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 15 Jun 94 08:23:28 +0200. <9406150623.AA20721@dxcoms.cern.ch> Date: Wed, 15 Jun 94 15:27:20 -0700 From: Dave Crocker X-Mts: smtp Brian, I'm confused by your analysis. You charactertise the latter portion as having to do with address 'mapping' but the details seemed simply to do with "framing" the various kinds of addresses into some IPng addressing package, unchanged. I.e., keep using the various old forms, but precede them with an identifier switch. No? Dave From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 10:52:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16583; Thu, 16 Jun 1994 09:34: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 JAA00491; Thu, 16 Jun 1994 09:34:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA00488; Thu, 16 Jun 1994 09:33:41 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14045; Thu, 16 Jun 1994 08:47:36 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id PAA29096; Wed, 15 Jun 1994 15:47:25 -0700 Message-Id: <199406152247.PAA29096@Mordor.Stanford.EDU> To: Jon Crowcroft Cc: yakov@watson.ibm.com, amolitor@anubis.network.com, big-Internet@munnari.OZ.AU Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: variable length addresses Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 15 Jun 94 13:50:39 +0100. <9406151251.20253@munnari.oz.au> Date: Wed, 15 Jun 94 15:47:24 -0700 From: Dave Crocker X-Mts: smtp Jon, ---- Included message: Cable net has head end + video on demand server at head of each street. which will also be multiprotocol router (and wil lalso be a CIX) I believe the servers will be higher than at neighborhood and doubt there will even be any caching at street or neighborhood, given the storage requirements of video. (Yes, even for the one or two most popular movies it probably isn't worth having a cache at each stree or neighborhood. Head-End is probably the better bet. It's set up for the operations and maintenance that is needed. Hence, there's a server setup for some SET of neighborhoods. d/ From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 12:33:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20195; Thu, 16 Jun 1994 11:15: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 LAA00601; Thu, 16 Jun 1994 11:15:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA00581; Thu, 16 Jun 1994 11:06:10 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17526; Thu, 16 Jun 1994 10:04:20 +1000 (from kre@munnari.OZ.AU) To: yakov@watson.ibm.com Cc: big-Internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 1994 17:53:57 EDT." <9406152201.12036@munnari.oz.au> Date: Thu, 16 Jun 1994 10:04:16 +1000 Message-Id: <23124.771725056@munnari.OZ.AU> From: Robert Elz Date: Wed, 15 Jun 94 17:53:57 EDT From: yakov@watson.ibm.com Message-ID: <9406152201.12036@munnari.oz.au> On the other hand, with variable length addresses, I may use shorter address (e.g. 8 octets), But will you? rather than always use max length (e.g. 16 octets). That may have some impact on "faster" aspect. Yes, there's no question but that longer addresses will be slower than shorter ones, provided they don't get too short (shorter or longer than the natural word length will be slower). However, making any kind of decision tends to be much slower than straight line fixed code, unless there's special purpose hardware, which may exist in some routers, but won't in anything else. I can't see the difference between 8 and 16 bytes in processing speed possibly being slower than even a single decision on which of those is actually in use on any semi-modern general purpose architecture. However, when comparing two choices, (a) -- fixed, and (b) -- variable, in my mind the most important point is NOT a qualitative statement that (a) is "simpler and faster" than (b), but some numbers that would provide an estimate of the difference. Would you agree with this ? Yes, I would - so how about providing the numbers? Since fixed is clearly both simpler and faster, by some degree, I think the burden of demonstrating that the difference is in fact negligible enough not to matter should rest on those that claim that. Also remember when considering this that there are two decidely different arguments for variable length addresses - some people claim to want them to save bytes, so the shortest addresses possible can be transmitted, others want them so they can stick in the longest addresses they can imagine - sometimes just for the safety net (how do you produce a number for that benefit?) and other times because they want to use truly extravagent local routing (11 bytes of local addressing indeed!) Those two cases probably need to be considered separately, as one option may be to have a very short maximum, with shorter options which would at least appease those who don't like variable addresses because of their potential to become huge, but wouldn't satisfy those who say they want shorter addresses only because they want to get variable addressing in somehow so they can really have long ones, but don't want to be heard saying that. kre From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 12:35:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23989; Thu, 16 Jun 1994 12:35: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 MAA00722; Thu, 16 Jun 1994 12:35:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA00706; Thu, 16 Jun 1994 12:15:51 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20210; Thu, 16 Jun 1994 11:16:05 +1000 (from nordmark@jurassic-248.Eng.Sun.COM) Received: from relay2.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23416 Thu, 16 Jun 1994 11:15:50 +1000 (from nordmark@jurassic-248.Eng.Sun.COM) Received: from Sun.COM by relay2.UU.NET with SMTP (rama) id QQwuls18070; Wed, 15 Jun 1994 20:12:28 -0400 Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA25601; Wed, 15 Jun 94 17:05:55 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA12044; Wed, 15 Jun 94 17:06:54 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA07307; Wed, 15 Jun 1994 17:05:47 -0700 Received: by bobo.Eng.Sun.COM (5.x/SMI-SVR4) id AA19197; Wed, 15 Jun 1994 17:05:45 -0700 Date: Wed, 15 Jun 1994 17:05:45 -0700 From: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Message-Id: <9406160005.AA19197@bobo.Eng.Sun.COM> To: Brian.Carpenter@cern.ch Subject: Re: variable length addresses Cc: big-Internet@munnari.OZ.AU Mime-Version: 1.0 > Routers and hosts must both go at wire speed. It's worse for routers > because they are connected to multiple wires. I disagree. All routers have to do is switch packets at wire speed; albeit multiple wires. Hosts (in which I include desktops as well as servers with lots of networks connected to it), in addition to receiving and sending packets, have to run applications that source and sink the data. These applications do things like accessing disks, frame buffers, frame grabbers etc all of which consumes precious CPU cycles. Erik From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 12:43:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21022; Thu, 16 Jun 1994 11:35: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 LAA00631; Thu, 16 Jun 1994 11:35:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA00617; Thu, 16 Jun 1994 11:22:54 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20443; Thu, 16 Jun 1994 11:22:51 +1000 (from barney@databus.databus.com) Received: from relay2.UU.NET by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA23738 Thu, 16 Jun 1994 11:22:47 +1000 (from barney@databus.databus.com) Received: from databus.databus.com by relay2.UU.NET with SMTP (rama) id QQwuls15214; Wed, 15 Jun 1994 20:01:38 -0400 Date: Wed, 15 Jun 94 20:02 EDT Message-Id: <9406152009.AA03210@databus.databus.com> From: Barney Wolff To: kasten@ftp.com, barney@databus.com Cc: big-Internet@munnari.OZ.AU Subject: Re: variable length addresses Content-Length: 1601 Content-Type: text > Date: Wed, 15 Jun 94 18:19:24 EDT > From: kasten@ftp.com (Frank Kastenholz) > > > >I think we've already seen data from router vendors that wire speed > > >can be attained with both fixed and variable length addresses. > > > > What is the official definition of "wire speed"? Ethernet? T1? T3? > > FDDI? OC12? > > depends on who the official definer is. the criteria document (which > is waiting for one of the ipng directors to review it) says something > to the effect of: > "a state of the art, commercial grade, router must be able to > forward packets at speeds capable of fully utilizing common, > commercial grade, high-speed media" > > 'commercial grade' typically would mean something that is available > as a standard item, off the shelf, from one of the major router/media > vendors. 'state of the art' would imply the latest release of the > latest product... The point I was getting at is that the duration of a minimum-size packet is already 10 usec for T3 and heading to 1 usec for 600 Mbps real soon. I'm not at all sure that the claim of wire speed for both fixed and variable addresses holds even today, if minimum-size packets are not ruled out. It certainly does not hold for hosts. The tough case for a host comes not on a workstation supporting only a few active connections, but on a multi-homed server with hundreds or thousands, which must identify a connection on input and pick an interface on output. I hope we will not so specify IPng that such a server needs a hardware assist for IPng but not for anything else. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 12:46:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22060; Thu, 16 Jun 1994 11: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 LAA00676; Thu, 16 Jun 1994 11:55:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA00660; Thu, 16 Jun 1994 11:42:15 +1000 Precedence: list Received: from relay2.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21286; Thu, 16 Jun 1994 11:41:58 +1000 (from vjs@rhyolite.wpd.sgi.com) Received: from sgi.sgi.com by relay2.UU.NET with SMTP (rama) id QQwulw28564; Wed, 15 Jun 1994 21:01:04 -0400 Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for Big-Internet@munnari.OZ.AU id AA27251; Wed, 15 Jun 94 17:54:44 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA20721; Wed, 15 Jun 94 18:54:38 -0600 Date: Wed, 15 Jun 94 18:54:38 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406160054.AA20721@rhyolite.wpd.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: variable length addresses > From: ericf@atc.boeing.com (Eric Fleischman @ atc.boeing.com) > > ... > I have no trouble understanding why routers need to quickly parse > addresses to forward packets to the correct next hop -- and do it very > quickly. However, even with real-time applications, I can not imagine why > an end system needs to parse addresses in a similar manner. ... Parsing addresses in IPv4 matters if you want your host to go fast. For example, `ttcp` numbers in the hosts I know about are faster for TCP than for UDP because you don't have to worry about addresses for TCP as much per packet with 4.3BSD-style TCP/IP. Dealing with the sequence numbers and timers of the IPv4 TCP, IP, and UDP headers is less work per byte than grabbing the address and using it as a key to figure out what the packet is about. I write host code for a living. Silicon Graphics' host code is not the slowest in the world. Vernon Schryver, vjs@sgi.com. From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 12:55:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24826; Thu, 16 Jun 1994 12:55: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 MAA00765; Thu, 16 Jun 1994 12:55:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA00738; Thu, 16 Jun 1994 12:38:55 +1000 Precedence: list Received: from relay2.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22328; Thu, 16 Jun 1994 11:59:04 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from Mordor.Stanford.EDU by relay2.UU.NET with SMTP (rama) id QQwulr14114; Wed, 15 Jun 1994 19:56:28 -0400 Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id QAA29709; Wed, 15 Jun 1994 16:56:24 -0700 Message-Id: <199406152356.QAA29709@Mordor.Stanford.EDU> To: amolitor@anubis.network.com (Andrew Molitor) Cc: big-internet@munnari.OZ.AU Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: variable length addresses Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 15 Jun 94 15:35:13 -0500. <9406152035.AA16321@anubis.network.com> Date: Wed, 15 Jun 94 16:56:23 -0700 From: Dave Crocker X-Mts: smtp Having an estimate of the basic difference in initial coding effort is probably a reasonable data point in doing this realm of analysis, but it is only one data point. We have a long history with one addressing model and we have none with another. We do not really know much about living with variable length addressess, using them efficiently, etc. A continuing, major issue in the IPng debate is trying to be clear about the items that involve risk. Anything that entails doing something in a style that is significantly different from what we have done before entails some risk, and possibly quite alot. The issue is not fixed-vs-variable, but why the heck we should believe variable is such a win? The criticisms made by variable-advocates are all true. Every attempt at predicting the right length has been wrong. But at least we knew how to make fixed length work and work well. Hand-waving doesn't make variable safe. If anyting, it increases the risk. Dave From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 14:15:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28509; Thu, 16 Jun 1994 14:15: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 OAA00893; Thu, 16 Jun 1994 14:15:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA00879; Thu, 16 Jun 1994 14:06:53 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28126; Thu, 16 Jun 1994 14:06:47 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA02035; Wed, 15 Jun 94 21:02:47 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA18021; Thu, 16 Jun 1994 00:02:44 -0400 Date: Wed, 15 Jun 1994 23:50:41 -0400 Message-Id: <94061523504166@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: jallard@microsoft.com, atkinson@itd.nrl.navy.mil, big-internet@munnari.OZ.AU Subject: Re: variable length addresses X-Vms-To: SMTP%"jallard@microsoft.com" X-Vms-Cc: SMTP%"atkinson@itd.nrl.navy.mil", SMTP%"big-internet@munnari.OZ.AU",CONTA > >although the ops folks reading sniffer traces and configuring router filters >will want some "standard notation", i don't see the big problem here. >......... >......... > hex is fine, dotted >dec is fine, but we potentially lose granularity to convenience as we >have w/ ipv4. This is an opportunity to mention one important possible advantage of 16 byte long SIPP addresses that I think was ignored: specifying IPv4 addresses in the "standard Internet '.' text notation", i.e. aaa.bbb.ccc.ddd ! This could be used during the IPv4 to IPng transition, and would make applications significantly faster by eliminating the need to translate an IP address text to binary, and will make network sniffing a lot easier, since network addresses will be plain text !!! (-: Alex From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 14:56:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26592; Thu, 16 Jun 1994 13:35: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 NAA00814; Thu, 16 Jun 1994 13:35:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA00797; Thu, 16 Jun 1994 13:19:41 +1000 Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25858; Thu, 16 Jun 1994 13:19:31 +1000 (from news@sgi.com) Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA10041; Wed, 15 Jun 94 19:24:31 -0700 To: Big-Internet@munnari.OZ.AU Reply-To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: variable length addresses Message-Id: Precedence: list Date: Thu, 16 Jun 1994 02:04:57 GMT > From: ericf@atc.boeing.com (Eric Fleischman @ atc.boeing.com) > > ... > I have no trouble understanding why routers need to quickly parse > addresses to forward packets to the correct next hop -- and do it very > quickly. However, even with real-time applications, I can not imagine why > an end system needs to parse addresses in a similar manner. ... Parsing addresses in IPv4 matters if you want your host to go fast. For example, `ttcp` numbers in the hosts I know about are faster for TCP than for UDP because you don't have to worry about addresses for TCP as much per packet with 4.3BSD-style TCP/IP. Dealing with the sequence numbers and timers of the IPv4 TCP, IP, and UDP headers is less work per byte than grabbing the address and using it as a key to figure out what the packet is about. I write host code for a living. Silicon Graphics' host code is not the slowest in the world. Vernon Schryver, vjs@sgi.com. From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 15:32:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26724; Thu, 16 Jun 1994 13:37: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 NAA00829; Thu, 16 Jun 1994 13:36:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA00800; Thu, 16 Jun 1994 13:23:05 +1000 Precedence: list Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25971; Thu, 16 Jun 1994 13:22:36 +1000 (from conta@ucxaxp.ucx.lkg.dec.com) Received: from ucxaxp.ucx.lkg.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA11154; Wed, 15 Jun 94 20:18:17 -0700 Date: Wed, 15 Jun 1994 20:55:34 -0400 Message-Id: <94061520553461@ucxaxp.ucx.lkg.dec.com> From: conta@ucxaxp.ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: yakov@watson.ibm.com, big-Internet@munnari.OZ.AU Subject: Re: variable length addresses X-Vms-To: SMTP%"yakov@watson.ibm.com" X-Vms-Cc: SMTP%"big-Internet@munnari.oz.au",CONTA >From: SMTP%"yakov@watson.ibm.com" 15-JUN-1994 19:36:58.66 > >>is anyone debating the statement that processing a fixed address >>is simpler and faster than processing a variable address. > >Speaking for myself, I don't debate the above statement with respect >to "simpler" aspect. With respect to "faster" I would like to point >out that with fixed length addresses you *always* use the max length, >even if you don't need it (Christian made this point today in his >e-mail). Please remember the very important fact that optimal size does not mean maximum. Which is to say that fix size address forcefully will prevent many liberals to use as much as they otherwise would with variable size. >On the other hand, with variable length addresses, I may >use shorter address (e.g. 8 octets), rather than always use max length >(e.g. 16 octets). That may have some impact on "faster" aspect. I think it is a lot difficult to demonstrate the above with the current variable size addresses, notable CLNP. From my own recent curiosity and experience, which was stirred up by a majority of comments on this mailing list, the fact that variable size invariably invites people to use the maximum available size was verified. And this is statistically true not only in networking - just look around or watch C-SPAN. >However, when comparing two choices, (a) -- fixed, and (b) -- variable, >in my mind the most important point is NOT a qualitative statement >that (a) is "simpler and faster" than (b), I think it is the very important starting point for discussion or evaluation which seems to be openly avoided or bypassed by the variable address partizans. >but some numbers that would provide an estimate of the difference. >Would you agree with this ? I am not sure what you mean. Hm,... I mean what would be considered a satisfactory accurate number for an estimate. Do you mean, someone to go and collect data, take short message/response oriented applications, long message/response applications, unidirectional traffic applications, bidirectional traffic applications, datagram oriented applications, connection oriented applications,, create environments with one active communication and with multiple active communications, do PC (program counter) sampling, and profiling, internal cache sampling, instructions and instructions sequence timing calculations, look and compare machine code generated by C, C++, or other compilers, or assemblers, list and compare procedure calls, instruction sequences and procedures link constructions brought in by linkers, on CISC, and RISC, on 32, and 64 bit architectures, on routers, and hosts, on UNIX, (how many?) MS-DOS, Windows NT,....VM, OS-2,...OVMS,... ? Let me say just that if IPng does not give the system response and feel of IPv4 then there will be a lot of trouble. We talked about this at length. I know from years of squeezing out KB, and MB/sec, that good performance and feel does not come easily and in big chunks, but you can loose away easily and in big chunks. When I have a large multiprocessor VAX or Alpha host with 600 incoming and several tens or hundreds outgoing TELNET sessions on it, hundreds of SMTP mail coming into and going out, file copying, printing on several printers, several tens of workstations file systems mounted remotely, with several Ethernet, and FDDI adapters - does this get any empathy with you? - or a desktop Alpha, with several windows imported, in an intensive threads based network application environment, with file systems mounted all over the place, I care a lot to have every address match operation done as fast as possible, because the address match done for source and destination may get multiplied with the number of addresses the system has, with the number of routes it can route to, with the source and the destination address of each TCP, or UDP socket, just to name one mechanism that is affected by a change from fixed to variable address. Adding to that that the address match must be serialized - the list must be locked, providing access to only one processor, to prevent possible simultaneous destructive access of the list from a different processor. And adding to that the fact that all fix size address based caches that were built into IPv4 based TCP or UDP to speed up the searches will be broken, does this mean anything to you? Alex From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 15:55:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02757; Thu, 16 Jun 1994 15: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 PAA01017; Thu, 16 Jun 1994 15:55:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA01001; Thu, 16 Jun 1994 15:40:27 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01394; Thu, 16 Jun 1994 15:21:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04456; Thu, 16 Jun 94 01:21:29 -0400 Date: Thu, 16 Jun 94 01:21:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406160521.AA04456@ginger.lcs.mit.edu> To: Bob.Hinden@eng.sun.com, jnc@ginger.lcs.mit.edu Subject: Re: variable length addresses Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: Bob.Hinden@eng.sun.com (Bob Hinden) One of the big reasons for failure is not ever getting it done in the desire to reach perfection. Yup. However, that's not our problem here, I think. Our problem is far more a major disagreement over how bold to be, technically. Not being bold enough can also be a road to failure (and one I've seen from close up, sigh). I really seriously think this reluctance to go to variable length is as much an emotional reluctance to stray from what has been shown to work, as it is anything else. This is understandable; being bold is difficult. True, there are arguments about efficiency, etc, but what I think I am seeing here is a pattern I've seen repeated over and over again in the IETF over the years. Making radical changes is always uncomfortable, and efficiency (along with complexity) is often one of the counterarguments. However, you're right, we can't dither forever, fine-tuning. I can't speak for everyone, but I'm certainly ready to move fairly expeditiously toward putting together some "best guess" specs, and rolling it out. I just want to be pretty bold in so doing. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 16:15:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03617; Thu, 16 Jun 1994 16:15: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 QAA01047; Thu, 16 Jun 1994 16:15:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA01033; Thu, 16 Jun 1994 16:06:42 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03187; Thu, 16 Jun 1994 16:06:34 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA21917; Thu, 16 Jun 1994 08:06:22 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA03350; Thu, 16 Jun 1994 08:06:21 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406160606.AA03350@dxcoms.cern.ch> Subject: Re: Address mapping (long) To: dcrocker@Mordor.Stanford.EDU (Dave Crocker) Date: Thu, 16 Jun 1994 08:06:20 +0200 (MET DST) Cc: Brian.Carpenter@cern.ch, big-internet@munnari.OZ.AU, dcrocker@Mordor.Stanford.EDU In-Reply-To: <199406152227.PAA28922@Mordor.Stanford.EDU> from "Dave Crocker" at Jun 15, 94 03:27:20 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 595 Dave, Yes. That's what I mean by mapping. Do you have another definition? (If you're thinking about NAT, I believe that rfc1631 says more about NAT than we need to know.) Brian >--------- Text sent by Dave Crocker follows: > > Brian, > > I'm confused by your analysis. You charactertise the latter portion > as having to do with address 'mapping' but the details seemed simply to > do with "framing" the various kinds of addresses into some IPng addressing > package, unchanged. I.e., keep using the various old forms, but precede > them with an identifier switch. No? > > Dave > From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 17:33:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01163; Thu, 16 Jun 1994 15:15: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 PAA00960; Thu, 16 Jun 1994 15:15:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA00957; Thu, 16 Jun 1994 15:13:18 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00872; Thu, 16 Jun 1994 15:13:06 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA05810; Wed, 15 Jun 94 22:09:54 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA18095; Thu, 16 Jun 1994 01:09:52 -0400 Date: Thu, 16 Jun 1994 00:46:16 -0400 Message-Id: <94061600461603@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: yakov@watson.ibm.com, big-internet@munnari.OZ.AU Subject: Re: variable length addresses X-Vms-To: SMTP%"yakov@watson.ibm.com" X-Vms-Cc: SMTP%"big-internet@munnari.oz.au",CONTA >From: SMTP%"yakov@watson.ibm.com" 15-JUN-1994 16:25:32.94 >To: big-internet@munnari.oz.au > >Folks, >In the discussion on variable vs fixed length addresses, >I would be interested to see the following estimate. >Assume that a host vendor starts with a host >that supports IPv4. Then assume two alternative scenarios: >(a) need to change the host software to support IPng-A with > fixed length addreses (e.g. 16 octets) >(b) need to change the host software to support IPng-B with > variable length addresses (max to 16 octets, in increment of 8 octets) > >Note that the *only* difference between IPng-A and IPng-B is that >in IPng-B the length of an address is encoded as part of the address >field. > >Given that software design, implementation and testing with scenario (a) >takes X man-years, how many man-years (relative to X) it would take >to do software design, implementation and testing with scenario (b) ? > >Yakov. Yakov, Sorry if answers are out of the receiving order. As one may infer, from my focusing in an earlier message, unlike others that look at the development costs, I am looking at the production cost of having variable address versus fix addresses, in other words, how is a machine and its users going to be affected by a new address format, being used on the Internet. Obviously a fix address incures only one change relative to IPv4 - size. A variable address format incures the additional and much more costly change of processing variable addresses, in which the size is learned dinamically. The overall production cost can get higher than what may be considered acceptable. However, the level of acceptance is hard to define. Some customers scream if a new version of a software although with much more features than the previous one is 2% slower. Others scream at 5%, others at 10%, or more. The user feel, the perception are important. New headers, new fields, longer addresses and plus lack of experience in implementing and working with the new protocol will add most likely to per packet processing cost, and since that will be measured against IPv4 which has more than 10 or 15 years of continous performance improvments, I want to minimize the risc of having a defavorable customer perception. Alex From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 17:55:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07796; Thu, 16 Jun 1994 17:55: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 RAA01183; Thu, 16 Jun 1994 17:55:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA01136; Thu, 16 Jun 1994 17:35:51 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03582; Thu, 16 Jun 1994 16:14:08 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA29424; Thu, 16 Jun 1994 08:14:04 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA03682; Thu, 16 Jun 1994 08:14:03 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406160614.AA03682@dxcoms.cern.ch> Subject: Re: variable length addresses To: nordmark@jurassic-248.eng.sun.com (Erik Nordmark) Date: Thu, 16 Jun 1994 08:14:03 +0200 (MET DST) Cc: Brian.Carpenter@cern.ch, big-Internet@munnari.OZ.AU In-Reply-To: <9406160005.AA19197@bobo.Eng.Sun.COM> from "Erik Nordmark" at Jun 15, 94 05:05:45 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 934 Erik, Yes, I forgot to add that hosts must go at wire speed while only using a few percent of the CPU, I/O and memory bandwidth to do so. But if you allow a host to spend 10% of its resources on networking, you need a router of the same power to support ten wires, to a first approximation. Brian >--------- Text sent by Erik Nordmark follows: > > > > Routers and hosts must both go at wire speed. It's worse for routers > > because they are connected to multiple wires. > > I disagree. > All routers have to do is switch packets at wire speed; albeit multiple > wires. > > Hosts (in which I include desktops as well as servers with lots of > networks connected to it), in addition to receiving and sending packets, > have to run applications that source and sink the data. These applications > do things like accessing disks, frame buffers, frame grabbers etc all > of which consumes precious CPU cycles. > > Erik > From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 17:56:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07874; Thu, 16 Jun 1994 17: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 RAA01198; Thu, 16 Jun 1994 17:56:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA01139; Thu, 16 Jun 1994 17:36:33 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03580; Thu, 16 Jun 1994 16:14:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04842; Thu, 16 Jun 94 02:13:50 -0400 Date: Thu, 16 Jun 94 02:13:50 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406160613.AA04842@ginger.lcs.mit.edu> To: Bob.Hinden@eng.sun.com, big-internet@munnari.OZ.AU Subject: re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: Bob.Hinden@eng.sun.com (Bob Hinden) If it should only be so simple. Unfortunately, it affects many things. These include ... pseudo checksum calculations Do it once at connection setup (for the entire pseudo-header), and then store it as a seed to the checksum algorithm. Etc, etc. Variable length addresses make all of these more complex. Sure, but extra complexity is a fact of life as systems get bigger. It's going to happen whether you like it or not. The issue is not whether it is possible to support variable length addresses, it is the cost for doing it (complexity, performance, etc.) worth the benefit gained. Exactly. It's a difficult question, unfortunately with no closed-form answer. I believe fixed length addresses will last a very long time Well, if you look at the history of computer systems, it's amazing how many times fixed length things have turned out to be "not long enough". I doubt even a 16-byte locator will run a worldwide data network for 30+ years. Note: I am not saying it's too small to provide unique *identification*; my doubts have more to do with its ability to hold the names that would result from a hierarchically structured address system which made the routing in such a system have acceptable scaling overhead. I do not think that the added complexity of variable length addresses is worthwhile. Well, you and I sitting here saying "yes it is" and "no it isn't" isn't going to do much good. You have any ideas on how to make forward progress? Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 17:58:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07912; Thu, 16 Jun 1994 17:58: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 RAA01213; Thu, 16 Jun 1994 17:58:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA01161; Thu, 16 Jun 1994 17:46:25 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04511; Thu, 16 Jun 1994 16:38:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04999; Thu, 16 Jun 94 02:38:00 -0400 Date: Thu, 16 Jun 94 02:38:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406160638.AA04999@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, craig@bbn.com Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: Craig Partridge For header processing, there's a huge penalty in going back for the memory that contains the address info you missed, and there's a smaller but also severe penalty for loading too much memory with excess info. Craig, this is true of today's technology. What about 20 years down the road, though? In routers, you can really optimize processor performance on the header if you always know how big the header is. For a variety of reasons, including the fact that their memory-to-I/O bandwidth ratios are skewed from normal processing requirements, I think routers will always have significant hardware support for their job, so I don't worry about routers much. I don't hear the major router vendors jumping up and down and freaking out either... In hosts, you can optimize both the header processing and (usually) the buffer management if you always know how big things are. Sigh. I'm not sure how I got stuck defending something (variable length fields in every packet) that wouldn't be in any design I liked. As far as I can tell, high-performance applications are *not* going to be sending single packets. This means you've got a flow, and you can take the darn locators out of the packet completely, fixed *or* variable length, making the headers faster to set up (if you aren't recycling buffers). Even if you do have single packets, I know how to forward single packets which contain variable length locators fairly efficiently (using the New Datagram Mode, for instance). From the user's perspective, speed-of-light round trip delays for access to non-local data (16 msec from the US East Coast to the West Coast, for example) will completely swamp any extra time spent setting up the longer header. I can't believe we're wasting all this time arguing about a few stupid instructions. 20 years from now people will look back on this debate and wonder what we were all using for brains. Cycles are cheap, and getting cheaper. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 18:00:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08038; Thu, 16 Jun 1994 18:00: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 RAA01228; Thu, 16 Jun 1994 17:59:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA01167; Thu, 16 Jun 1994 17:49:25 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05036; Thu, 16 Jun 1994 16:47:20 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA11020; Wed, 15 Jun 94 23:44:48 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA18194; Thu, 16 Jun 1994 02:44:46 -0400 Date: Thu, 16 Jun 1994 01:10:52 -0400 Message-Id: <94061601105264@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: tli@cisco.com, big-Internet@munnari.OZ.AU, yakov@watson.ibm.com Subject: Re: variable length addresses X-Vms-To: SMTP%"tli@cisco.com" X-Vms-Cc: SMTP%"big-Internet@munnari.OZ.AU", SMTP%"yakov@watson.ibm.com",CONTA >From: SMTP%"tli@cisco.com" 15-JUN-1994 18:43:10.34 > Without taking away the known and aknowledged merits of variable > addresses, is anyone debating the statement that processing a > fixed address is simplier and faster than processing a variable address? > >Not at all. However, the additional cost in the high-performance path >is something like 4 instructions. > >Seems like cheap insurance to me. > >Tony Li Tony, Should I call this the "router guy" view? Those 'n' more instructions in an address match - which means we ignore all the other special operations required for processing variable addresses - may mean a lot. You do not mention that for each packet you may do: 1. case dependent, at internet layer you multiply the address match with the number of local host addresses, or/and with routing table entries. 2. At transport level, which 'router guys' ignore systematically, for each packet received, with data or no data, two address matches are performed for each socket that is in the list of sockets for that particular transport, and is not the socket looked for. ... Back to your number 4, did you mean 4 machine instructions or 4 instructions or lines of high level language? Let's see, assuming an imaginary simple architecture, and machine language, and using BigTen specs for this example of a two 16 byte addresses match: mova a, r1 ;;; pointer to address1 in r1/not counted mova b, r2 ;;; pointer to address2 in r2/not counted $$$start_counting: movb (r1), r3 ;1 load size of first address in register mask x, r3 ;2 mask unused bits shift r3, 1 ;3 eliminate bit 0 - strict vs loose, and align size mov (r2), r4 ;4 load size of second address in register mask x, r4 ;5 mask unused bits shift r4, 1 ;6 eliminate bit 0 - strict vs loose, and align size cmp r3, r4 ;7 compare the two - I suppose you don't ; want to go and compare two addresses ; that are not equal in size. bneq $$$not_equal ;8 branch if not equal Up to here this is 8 instructions to me, which I do not have for fixed addresses. Let's continue. $$$loop: cmp (r1), (r2) ;1 compare first 4 bytes bneq $$$not_equal ;2 branch if not equal cmp 4(r1), 4(r2) ;3 compare second group of 4 bytes bneq $$$not_equal ;4 branch if not equal decl r3 ;5 decrement size multiple of 8 bleq $$$equal ;6 continue if more to do addl #8, r1 ;7 point to next group addl #8, r2 ;8 point to next group brb $$$loop ;9 loop to do next 8 bytes $$$equal: ; ; Total 8 + 9 (first path) + 6(second path) = 23 ; $$$not_equal: Let's see, fixed addresses now. mova a, r1 ;;; pointer to address1 in r1 / not counted mova b, r2 ;;; pointer to address2 in r2 / not counted $$$start_counting: cmp (r1), (r2) ;1 compare first 4 bytes bneq $$$not_equal ;2 branch if not equal cmp 4(r1), 4(r2) ;3 compare second group of 4 bytes bneq $$$not_equal ;4 branch if not equal cmp 8(r1), 8(r2) ;5 compare third 4 bytes bneq $$$not_equal ;6 branch if not equal cmp 12(r1), 12(r2) ;7 compare firth group of 4 bytes bneq $$$not_equal ;8 branch if not equal ; ; total of 8 instructions ; The difference according to this is 15 instructions. Alex From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 18:02:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08205; Thu, 16 Jun 1994 18:02: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 SAA01243; Thu, 16 Jun 1994 18:01:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA01164; Thu, 16 Jun 1994 17:47:05 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02784; Thu, 16 Jun 1994 15:56:13 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04542; Thu, 16 Jun 94 01:56:01 -0400 Date: Thu, 16 Jun 94 01:56:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406160556.AA04542@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, conta@ucx.lkg.dec.com Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) > If you have a variable length internetwork header (be it from addresses > or whatever), the cost from that to upper layers ... seems to be i) an > extra pointer register, and ii) two instructions This is only the additional work related to referencing the addresses in the header, which in fact is the least expensive. No, it's the extra cost of getting to the upper layer header, which is otherwise unchanged. There are many other parts that are more expensive, such as the address match You mean checking to make sure the packet's for you? First, if you had EID's and locators, you wouldn't need to check the locator (variable length), just the EID (probably fixed length, and definitely shorter). Second, if you're using a protocol with end-end checksums which include the EID, you can skip checking the EID, and just assume the packet's for you; if it's a stray packet on a port you happen to have live, it'll fail the end-end checksum. and the machanisms related to passing, and storing the variable size address parameters - always have to pass two parameters rather than one, always store the length, besides the pointer or the address itself, etc... Why the devil are you doing that any time other than the initial open? You're better off passing a pointer to the relevant connection block anyway, rather than an "address" (fixed-length or otherwise). That's what you really need anyway, and if you pass that directly, rather than something you have to look up to turn into said pointer, you're ahead of the game there. (If you are doing a multi-user OS, you have to do something different, but let's not get into that rat-hole.) > Optimized code can use tricks like the header compression I mentioned to > get rid of even that. I reject header compression from the start Sorry, that was a mental typo; I mean to say "header prediction". > Of course, if you're trying to lay the data down on a page boundary, it > can mess you up, but if you only have one of those applications running > at a time you can make it work. Remember I am talking about hosts, where practically most applications are networked, the file system is networked, the printing is networked, and so on.... Just out of interest, do you try and put data down on page boundaries? Anyway, it turns out that for high-performance applications, my assumption (which could be wrong) is that most of these have a flow lying around, and if so, you can drop the locators from the packets, making the headers fixed length. > Obviously, packet setup in the internetwork layer can be more expensive, > e.g. if you can't use an unrolled loop to copy the addresses around. Address match is even more expensive than packet setup, since it multiplies at internet layer with number of routing table entries, and/or interface addresses A fast TCP should contain a pointer to the relevant internetwork level route cache entry anyway; that's faster than looking it up on every packet (and that entry should contain a pointer to the level 2 address, for the same reason). If you have EID's, most multi-interfaced hosts would have only one, getting rid of *that* cost. and at transport layer with the number of sockets. Hmm. First, EID's change the equation anyway. Second, even without EID's, there are tricks you can pull here. For instance, if the local/destination port pair is unique (which you can determine at connection setup, and you can mark as such at that time), and then you only have to check those on incoming packets (the end-end checksum will catch stray packets). If, on processing a packet, you find an entry not so marked, then you have to do the full compare, but that should be rare. > are ways to deal with this; e.g. you can reuse packet buffers, > eliminating the address copy completely. Etc, etc, etc. I guess you refer to what one can do to optimize in general the protocol engines. But this has been long done I would doubt this, actually. so I do not want any additional cost that does not have a sound and irrefutable justification. Sure, we just disagree about what classifies as "a sound and irrefutable justification". Look, I understand the people who like efficiency; I've been there. I know all about writing tense code. I've written more code than I can remember, knowing what machine language the compiler was going to emit, and counting the memory references as I wrote it, and trying to decide which variables to put in registers. I wrote (in the dim past :-) a router in a HLL that had what was, for that time, performance levels previously considered unapproachable without assembler. Etc, etc, etc. I'm trying to look at a bigger picture now, one that includes all costs, including engineering, deployment, operation, etc, over the entire lifecycle of the design, which is probably 30+ years! (If *anyone* thinks this is silly, realize that IPv4 is already over 15 years, and it will be over 20 before we are even starting to majorly transition off it.) Looked at from that perspective, the flexibility and adapability of separate mechanisms (for EID's and locators) and variable lengths (for locators) are worth the costs. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 18:16:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08739; Thu, 16 Jun 1994 18:16: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 SAA01283; Thu, 16 Jun 1994 18:15:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA01261; Thu, 16 Jun 1994 18:07:59 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08365; Thu, 16 Jun 1994 18:07:50 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406160807.8365@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Jun 1994 09:07:25 +0100 To: Eric Fleischman Cc: amolitor@anubis.network.com, big-Internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 94 09:39:17 PDT." <9406151639.AA16228@atc.boeing.com> Date: Thu, 16 Jun 94 09:07:22 +0100 From: Jon Crowcroft >I have no trouble understanding why routers need to quickly parse >addresses to forward packets to the correct next hop -- and do it very >quickly. However, even with real-time applications, I can not imagine why >an end system needs to parse addresses in a similar manner. That is, to get >an address I use a DNS name and obtain an address. ok, what about a ipng video on demand server or a transactions server supporting 100,000 customers it has to map addresses into TCP PCBs exactly as fast as the router forwarding packets to it it has to do a _full address match_ not just a prefix one.....unless you believe the EID stuff (actually, even if you do, such a server might well be multihomed on multiple provider nets, and therefore have to choose its network interfaces arefully, and check inbound and outbound match properly... ok? jon From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 18:30:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06912; Thu, 16 Jun 1994 17:35: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 RAA01128; Thu, 16 Jun 1994 17:35:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA01114; Thu, 16 Jun 1994 17:24:13 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06382; Thu, 16 Jun 1994 17:24:08 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA16646; Thu, 16 Jun 1994 00:22:43 -0700 Date: Thu, 16 Jun 1994 00:22:43 -0700 From: Tony Li Message-Id: <199406160722.AAA16646@lager.cisco.com> To: conta@ucx.lkg.dec.com Cc: big-Internet@munnari.OZ.AU, yakov@watson.ibm.com In-Reply-To: Alex Conta, Networks Engineering - TCP/IP's message of Thu, 16 Jun 1994 01:10:52 -0400 <94061601105264@ucx.lkg.dec.com> Subject: variable length addresses Alex, Should I call this the "router guy" view? Feel free to call it whatever you like. You do not mention that for each packet you may do: 1. case dependent, at internet layer you multiply the address match with the number of local host addresses, or/and with routing table entries. 2. At transport level, which 'router guys' ignore systematically, for each packet received, with data or no data, two address matches are performed for each socket that is in the list of sockets for that particular transport, and is not the socket looked for. Sorry, I'm lost here. Back to your number 4, did you mean 4 machine instructions or 4 instructions or lines of high level language? Machine instructions. Oh, and I was considering a longest match routing table lookup. Let's see, assuming an imaginary simple architecture, and machine language, and using BigTen specs for this example of a two 16 byte addresses match: mova a, r1 ;;; pointer to address1 in r1/not counted mova b, r2 ;;; pointer to address2 in r2/not counted $$$start_counting: movb (r1), r3 ;1 load size of first address in register You always have to load the first byte of the address, regardless of what you're doing. And actually, we should load a full word (for your favorite word size that's a multiple of 32 bits) here. mask x, r3 ;2 mask unused bits shift r3, 1 ;3 eliminate bit 0 - strict vs loose, and align size You can mask here and just remove the strict/loose bit. Leave the lengths alone. Aligning the length bits isn't important, as we aren't going to _count_ them, instead we'll branch on them with a case statement.... But to continue: movb (r2), r4 ;4 load size of second address in register mask x, r4 ;5 mask unused bits shift r4, 1 ;6 eliminate bit 0 - strict vs loose, and align size Again, loading is required anyhow, masking is due to strict/loose, and there's no need to shift yet. cmp r3, r4 ;7 compare the two - I suppose you don't ; want to go and compare two addresses ; that are not equal in size. bneq $$$not_equal ;8 branch if not equal Ok, if we got here, the lengths are equal. Doing the rest of the compare makes sense. Note that you have to compare these two words _anyhow_ so the above are not an additional instruction. Let's get the first byte off of the word: movl r3, r5 ;1 Copy shiftr 28, r5 ;2 Shift for convenient jumping jump table[r5] ;3 Branch Now, for each of the possible address lengths, you write an unrolled loop. Note that this unrolled loop is _EXACTLY_ the same as you would have to had to have done for the fixed address. Clever folks just arrange the labels to jump into the same instruction stream at the appropriate place... I believe that a more complex architecture can probably combine the copy and shift. And if your architecture is really simple, then the indexed branch takes one more instruction. That's 4. Tony Li Speed Freak From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 19:55:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12906; Thu, 16 Jun 1994 19:55: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 TAA01387; Thu, 16 Jun 1994 19:55:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA01362; Thu, 16 Jun 1994 19:39:03 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12462; Thu, 16 Jun 1994 19:38:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05922; Thu, 16 Jun 94 05:38:49 -0400 Date: Thu, 16 Jun 94 05:38:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406160938.AA05922@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, conta@ucx.lkg.dec.com Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) Tony's reply missed some optimizations. 1. case dependent, at internet layer you multiply the address match with the number of local host addresses Just assume the packet is for you. If you don't find a matching port (port pair for TCP), *then* check the destination to decide how to do the error handling (no such port, or the packet was misdirected). (Also, this is a tangent, but you can also fix this with an EID.) or/and with routing table entries. You should only being doing this lookup once, at connection setup time, and storing a pointer to the resulting entry in the connection block. 2. At transport level, which 'router guys' ignore systematically Look, if you get to gratuitously insult our professional competence, expect it back. And believe me, I can give as well as I get. How many TCP's have you written from scratch? (Hint: The answer for me is *not* "zero".) for each packet received, with data or no data, two address matches are performed for each socket that is in the list of sockets for that particular transport, and is not the socket looked for. First, check the ports first, not the addresses. You won't even get as far as the addresses for most sockets. Second, if you find a single matching port, don't even bother checking the addresses (on either end); the end-end checksum (which includes the pseudo-header, and thus the addresses of both ends) will catch stray packets which just happen to have the right ports in them. (There, I've saved enough cycles for you to more than pay for variable length addresses! :-) mov (r2), r4 ;4 load size of second address in register mask x, r4 ;5 mask unused bits shift r4, 1 ;6 eliminate bit 0 - strict vs loose, and align size Assuming the second address is the one that's already on hand, these second two instructions are totally gratuitous. The address should be stored with with these operations already performed. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 21:15:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15487; Thu, 16 Jun 1994 21:15: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 VAA01497; Thu, 16 Jun 1994 21:15:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA01475; Thu, 16 Jun 1994 20:58:22 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10152; Thu, 16 Jun 1994 18:50:28 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406160850.10152@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Jun 1994 09:50:11 +0100 To: Brian.Carpenter@cern.ch Cc: big-internet@munnari.OZ.AU Subject: Re: Address mapping (long) - convergence In-Reply-To: Your message of "Wed, 15 Jun 94 08:23:28 +0100." <9406150623.AA20721@dxcoms.cern.ch> Date: Thu, 16 Jun 94 09:50:08 +0100 From: Jon Crowcroft >1. Convergence and multiprotocol networking >------------------------------------------- > >There has been quite some discussion of "convergence" of other Level 3 >protocols onto IPng. Nobody has defined the goal of convergence. I will >assume it is the provision of mechanisms for multiprotocol coexistence at >Level 3 in the Internet, with later non-disruptive replacement of various >older protocols by IPng. goals of convergence for network managers and operatoes ease/convenience, and: 1. for cheaper network s/w (i.e. router s/w acquisution and recurrent) 2. use of network layer to carry 'foreign' protocol stacks (aka tunnels or encapsulation) i) with different operational routes (ships i nthe night) ii) with same route (and as per your excellent not, therefore an algorithmic adddress mapping) Any other covergence is at 2 possible layers: A. Transport Service for application writers. B. Application, and full stack convergence - for the USER!!!!! any other convergences are hacks, imho... cheers jon From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 21:17:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15533; Thu, 16 Jun 1994 21:17: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 VAA01512; Thu, 16 Jun 1994 21:17:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA01483; Thu, 16 Jun 1994 21:02:44 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11425; Thu, 16 Jun 1994 19:18:17 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA19338; Thu, 16 Jun 1994 02:16:43 -0700 Date: Thu, 16 Jun 1994 02:16:43 -0700 From: Tony Li Message-Id: <199406160916.CAA19338@lager.cisco.com> To: conta@ucx.lkg.dec.com Cc: big-Internet@munnari.OZ.AU In-Reply-To: Alex Conta, Networks Engineering - TCP/IP's message of Thu, 16 Jun 1994 03:37:53 -0400 <94061603375340@ucx.lkg.dec.com> Subject: variable length addresses Alex, In my current count the difference is 8 - there is no need to load in registers the first part of the address before the first compare - but still obviously handcrafting makes a difference. This was fun... Well, any way you slice it, you had to do the mask for the strict/loose bit. This bit is completely orthogonal to the issue of variable length addresses. Certainly if we get rid of that bit and we do memory to memory compares, then that saves four more instructions from your count. For RISC, the unrolled loops have to be in proximity to ensure instruction cache hits, while the existence of 'table' as data reference may incure data cache mises. Yup. Clever people might choose to arrange their jump table so that there is no I-cache miss for the common lengths. Further cleverness might avoid the data cache miss by doing math on the PC. It might burn an extra instruction in this case, but still be faster. Do you have a 'C" example that I could try with my compilers, and see the machine code generated and difference? Not offhand. Tony From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 21:19:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15573; Thu, 16 Jun 1994 21: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 VAA01527; Thu, 16 Jun 1994 21:19:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA01472; Thu, 16 Jun 1994 20:58:15 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09812; Thu, 16 Jun 1994 18:40:48 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA17364; Thu, 16 Jun 94 01:35:51 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA18421; Thu, 16 Jun 1994 04:35:49 -0400 Date: Thu, 16 Jun 1994 03:37:53 -0400 Message-Id: <94061603375340@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: tli@cisco.com, big-Internet@munnari.OZ.AU Subject: Re: variable length addresses X-Vms-To: SMTP%"tli@cisco.com" X-Vms-Cc: SMTP%"big-Internet@munnari.oz.au",CONTA >From: SMTP%"tli@cisco.com" 16-JUN-1994 03:31:44.98 >To: conta@ucx.lkg.dec.com Tony, What resulted is: mova a, r1 ;;; pointer to address1 in r1/not counted mova b, r2 ;;; pointer to address2 in r2/not counted $$$start_counting: movl (r1), r3 ;1 load first 4 bytes of address1 in register mask x, r3 ;2 mask unused bit 0 movl (r2), r4 ;3 load first 4 bytes of address2 in register mask x, r4 ;4 mask unused bit 0 cmpl r3, r4 ; compare the two bneq $$$not_equal ; branch if not equal movl r3, r5 ;5 Copy shiftr 28, r5 ;6 Shift for convenient jumping addl table, r5 ;7 jmp (r5) ;8 Branch The unrolled loop is clever indeed - used it for checksum routines. In my current count the difference is 8 - there is no need to load in registers the first part of the address before the first compare - but still obviously handcrafting makes a difference. This was fun... The imaginary architecture brakes down to very simple operations to avoid the hiding effect of more complex instructions, which execute in a cumulated simple instructions time. For RISC, the unrolled loops have to be in proximity to ensure instruction cache hits, while the existence of 'table' as data reference may incure data cache mises. Do you have a 'C" example that I could try with my compilers, and see the machine code generated and difference? Alex From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 21:21:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15652; Thu, 16 Jun 1994 21:21: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 VAA01542; Thu, 16 Jun 1994 21:20:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA01478; Thu, 16 Jun 1994 21:01:52 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10186; Thu, 16 Jun 1994 18:51:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05700; Thu, 16 Jun 94 04:51:24 -0400 Date: Thu, 16 Jun 94 04:51:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406160851.AA05700@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, conta@ucxaxp.ucx.lkg.dec.com Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: conta@ucxaxp.ucx.lkg.dec.com with the current variable size addresses, notable CLNP ... the fact that variable size invariably invites people to use the maximum available size was verified. And this is statistically true not only in networking What?! Look at your host's DNS name; know what the maximum length of any DNS field is? Does your US mail address completely fill the space in the address cards which have the character positions marked out? What about your UNIX file names? NSAP addressing plans take the whole 20 bytes because 20 bytes is seen as limited (particularly after you subtract the AFI, 6 bytes for the IEEE 802, etc), so that people feel they have to sit down and carefully allocate the space up front. If they had more space to play with *if they needed it*, and a format which made it much easier to add space to things in the middle, nobody would bother with pre-allocating all the space. > However, when comparing two choices, (a) -- fixed, and (b) -- variable, > in my mind the most important point is NOT a qualitative statement > that (a) is "simpler and faster" than (b) I think it is the very important starting point for discussion or evaluation which seems to be openly avoided or bypassed by the variable address partizans. I get really tired of people assuming that anyone who doesn't share their fixation on performance has no idea, or doesn't care, what the "real costs" of their pet schemes are. I find it damned insulting, thank you. I've *been there*, and I have tens of thousands of lines of code *still runnning* in production in the Internet in commercial products, OK? We're not bypassing anything, just looking at a little bigger picture than how many instructions its going to take this year. When I have a large multiprocessor VAX or Alpha host ... I care a lot to have every address match operation done as fast as possible, because the address match done for source and destination may get multiplied with the number of addresses the system has, with the number of routes it can route to, with the source and the destination address of each TCP, or UDP socket, just to name one mechanism that is affected by a change from fixed to variable address. You don't provide any details of how your databases are arranged. However, clever coding (e.g. checking the simple things first, like comparing ports for matches *before* checking the addresses; use of hashes or B-trees for databases which can get very big, instead of linear linked lists), use of some precomputed intermediate data (such as cached pointers) could probably improve the situation here a lot. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 21:32:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14472; Thu, 16 Jun 1994 20:35: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 UAA01431; Thu, 16 Jun 1994 20:35:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA01428; Thu, 16 Jun 1994 20:30:12 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09143; Thu, 16 Jun 1994 18:22:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05623; Thu, 16 Jun 94 04:22:52 -0400 Date: Thu, 16 Jun 94 04:22:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406160822.AA05623@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, dcrocker@mordor.stanford.edu Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: Dave Crocker Anything that entails doing something in a style that is significantly different from what we have done before entails some risk, and possibly quite alot. Sometimes doing only things that are not significantly different from what you have done before is a bigger risk. The number of major companies that have fallen on hard times through not changing to keep up with the fast-changing world around them is legion. Still, these are broad generalities, and won't help us decide here. The criticisms made by variable-advocates are all true. Every attempt at predicting the right length has been wrong. But at least we knew how to make fixed length work and work well. I'm sitting here with a pretty stunned look on my face; I can't believe you said this. Looking for keys underneath the street-light indeed... Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 22:29:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16965; Thu, 16 Jun 1994 21:55: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 VAA01603; Thu, 16 Jun 1994 21:55:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA01589; Thu, 16 Jun 1994 21:47:42 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15034; Thu, 16 Jun 1994 21:01:03 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406161101.15034@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Jun 1994 11:50:30 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, conta@ucx.lkg.dec.com Subject: Re: variable length addresses In-Reply-To: Your message of "Thu, 16 Jun 94 05:38:49 EDT." <9406160938.AA05922@ginger.lcs.mit.edu> Date: Thu, 16 Jun 94 11:50:18 +0100 From: Jon Crowcroft >(There, I've saved enough cycles for you to more than pay for variable length >addresses! :-) Noel information theorey, she say: if you have variable lenth address, you must vary it, otherwiase it conveys nothing TCP she say: me big end to end protocol, need to know end from end multihomed host, he say, need to look at varation in address, and check him don't vary from 1 packet to next in same connection i.e. variable length address necessarily costs more to end system than fixed address. what is gain to network that is worth loss to end system? also: personally, i think there are as many opportunities to assign variable length wrong as there are advantages in the flexibility ... this is based on talking to sites with 100k host networks in the UK, i often find they have a real problem with IPv4 address assignment. and note, if someone gets it wrong, the use memory in _all_ routers jon From owner-Big-Internet@munnari.OZ.AU Thu Jun 16 23:58:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20874; Thu, 16 Jun 1994 23:58: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 XAA01755; Thu, 16 Jun 1994 23:58:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA01726; Thu, 16 Jun 1994 23:54:49 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18384; Thu, 16 Jun 1994 22:42:36 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA14009; Thu, 16 Jun 94 08:42:22 -0400 Message-Id: <9406161242.AA14009@rodan.UU.NET> To: big-internet@munnari.OZ.AU Cc: sipp@sunroof.Eng.Sun.COM Subject: Maybe we have a definitional problem Date: Thu, 16 Jun 1994 08:42:19 -0400 From: "Mike O'Dell" Maybe some of the difficulty we are having is that the phrase "variable length" evokes strong gut reactions in some people for what may be good reasons (some of the current "discussion" is about whether they are "good enough"). There are at least two ways to do "variable length" and maybe it will help to try and think clearly about whether this distinction and the two choices which have been proposed make sense. Proposal 1: variable length via additional headers With Steve Deering's indulgence, the net effect of the original SIPP Routing Header is to provide additional address bits, albeit with a rather different spin than simply glomming them all together. So there is a real semantic difference. Further, since the routing headers are "stackable", maybe this can support the kind of "incremental headers" needed by Nimrod??? (Noel?) Proposal 2: variable length addresses by simple varying bit count Within this school of thought, there are several alternatives. One is the "8 or 16" school and the "really variable length but with some reasonable natural granularity" school. the first school argues that two choices is easier to do than an arbitrary choice, no matter how well aligned. the "really variable length" school argues that we can't really know 16 bytes is enough so simply be able to do whatever is needed eventually from Day 1. (excuse oversimplications) There may well be subschools and variants. Anyway..... Can we at least try to structure the discussion so we know which basic proposal is being addressed at any one time, and which distinctions and positions are being advocated??? This won't fix anything, but might help focus the discussion on some concrete distinctions before peoples' hands get wind-burn from the vigorous waving going on (grin). -Mike O'Dell From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 00:15:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21699; Fri, 17 Jun 1994 00: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 AAA01791; Fri, 17 Jun 1994 00:15:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA01786; Fri, 17 Jun 1994 00:12:48 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19066; Thu, 16 Jun 1994 23:03:02 +1000 (from jkrawczy@pobox.wellfleet.com) Received: from lobster.wellfleet.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05231 Thu, 16 Jun 1994 23:02:57 +1000 (from jkrawczy@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA22614; Thu, 16 Jun 94 08:58:49 EDT Received: from maggie.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA25149; Thu, 16 Jun 94 08:55:58 EDT Date: Thu, 16 Jun 94 08:55:58 EDT From: jkrawczy@pobox.wellfleet.com (John Krawczyk) Message-Id: <9406161255.AA25149@pobox.wellfleet> Received: by maggie.wellfleet (4.1/SMI-4.1) id AA14079; Thu, 16 Jun 94 08:59:18 EDT To: nordmark@jurassic-248.Eng.Sun.COM Cc: Brian.Carpenter@cern.ch, big-Internet@munnari.OZ.AU In-Reply-To: <9406160005.AA19197@bobo.Eng.Sun.COM> (nordmark@jurassic-248.Eng.Sun.COM) Subject: Re: variable length addresses Reply-To: jkrawczy@wellfleet.com Date: Wed, 15 Jun 1994 17:05:45 -0700 From: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) > Routers and hosts must both go at wire speed. It's worse for routers > because they are connected to multiple wires. I disagree. All routers have to do is switch packets at wire speed; albeit multiple wires. Hosts (in which I include desktops as well as servers with lots of networks connected to it), in addition to receiving and sending packets, have to run applications that source and sink the data. These applications do things like accessing disks, frame buffers, frame grabbers etc all of which consumes precious CPU cycles. Not to get too far off on this tangent, but routers also run "applications" that process and generate routing updates, handle telnet sessions and file transfers, and respond to SNMP requests (among other things, depending on the router). The application load isn't the same as a desktop host, but it's definitely not zero. Erik -jj From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 00:16:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20155; Thu, 16 Jun 1994 23:36: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 XAA01694; Thu, 16 Jun 1994 23:35:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA01691; Thu, 16 Jun 1994 23:25:13 +1000 Precedence: list Received: from FRED.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19669; Thu, 16 Jun 1994 23:24:51 +1000 (from craig@BBN.COM) Message-Id: <9406161324.19669@munnari.oz.au> To: Noel Chiappa Cc: big-internet@munnari.OZ.AU Subject: Re: variable length addresses Date: Thu, 16 Jun 94 09:14:21 -0400 From: Craig Partridge > I can't believe we're wasting all this time arguing about a few stupid > instructions. 20 years from now people will look back on this debate and > wonder what we were all using for brains. Cycles are cheap, and getting > cheaper. Noel: Here's why one argues about a few instructions: It requires 50-70 instruction cycles and 4 to 8 cache line loads to forward a current IP datagram using a processor. (Depends on your architecture). Current processor and memory performance trends say that these two metrics are roughly balanced (i.e, 4 to 8 cache line loads can be done in 50 to 70 instruction cycles). So, if you add, say 10 instructions to header processing, you've slowed the system down by 15% to 20%. One more cache line load (say due to bigger headers) has at least as severe an effect. Craig From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 00:30:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20814; Thu, 16 Jun 1994 23: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 XAA01740; Thu, 16 Jun 1994 23:55:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA01721; Thu, 16 Jun 1994 23:53:36 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18720; Thu, 16 Jun 1994 22:52:02 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406161252.18720@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 16 Jun 1994 13:51:33 +0100 To: "Mike O'Dell" Cc: big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM Subject: Re: Maybe we have a definitional problem In-Reply-To: Your message of "Thu, 16 Jun 94 08:42:19 EDT." <9406161242.AA14009@rodan.UU.NET> Date: Thu, 16 Jun 94 13:51:29 +0100 From: Jon Crowcroft >Proposal 1: variable length via additional headers >Proposal 2: variable length addresses by simple varying bit count there are also tw oother views 1. a variable length address made of fixed length componenents, and containing at start a hop by hop pointer to the current router's relevent part - this has same performance as fixed length, but is as flexible as... 2. a variable lentgh address with a rotuer specific mask/prefix for longest match lookups... jon From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 00:35:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22188; Fri, 17 Jun 1994 00:35: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 AAA01826; Fri, 17 Jun 1994 00:35:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA01807; Fri, 17 Jun 1994 00:19:24 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21771; Fri, 17 Jun 1994 00:19:20 +1000 (from vjs@rhyolite.wpd.sgi.com) Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for Big-Internet@munnari.OZ.AU id AA27820; Thu, 16 Jun 94 07:19:08 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA22750; Thu, 16 Jun 94 08:18:37 -0600 Date: Thu, 16 Jun 94 08:18:37 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406161418.AA22750@rhyolite.wpd.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: variable length addresses > From: J.Crowcroft@cs.ucl.ac.uk (Jon Crowcroft @ cs.ucl.ac.uk) > > >I have no trouble understanding why routers need to quickly parse > >addresses to forward packets to the correct next hop -- and do it very > >quickly. However, even with real-time applications, I can not imagine why > >an end system needs to parse addresses in a similar manner. That is, to get > >an address I use a DNS name and obtain an address. > > ok, what about a ipng video on demand server or a transactions server > supporting 100,000 customers > > it has to map addresses into TCP PCBs exactly as fast as the router > forwarding packets to it > > it has to do a _full address match_ not just a prefix one.....unless > you believe the EID stuff (actually, even if you do, such a server > might well be multihomed on multiple provider nets, and > therefore have to choose its network interfaces arefully, and check > inbound and outbound match properly... A host must also be prepared to do both specific and wild card matching on addresses. A given received UDP datagram might be the job of a process listening to datagrams only from a single remote host or it might be given to a process that wants all datagrams to a given port. Then there is multicast, which can involve delivering a single datagram to more than one process. That said, I must note that the incoming packet rates on the video-on-demand servers I've heard about are not the same as their outgoing packet rates. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 00:38:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22276; Fri, 17 Jun 1994 00:38: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 AAA01841; Fri, 17 Jun 1994 00:38:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA01823; Fri, 17 Jun 1994 00:33:22 +1000 Precedence: list Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20407; Thu, 16 Jun 1994 23:42:23 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA08650 (InterLock SMTP Gateway 1.1 for big-Internet@munnari.oz.au); Thu, 16 Jun 1994 09:41:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Thu, 16 Jun 1994 09:41:53 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 16 Jun 1994 09:41:53 -0400 Message-Id: <199406161338.AA123946@foo.ans.net> To: Tony Li Cc: conta@ucx.lkg.dec.com, big-Internet@munnari.OZ.AU, yakov@watson.ibm.com Subject: Re: variable length addresses In-Reply-To: Your message of "Thu, 16 Jun 1994 07:22:43 GMT." <199406160722.AAA16646@lager.cisco.com> Date: Thu, 16 Jun 1994 09:38:27 -0400 From: Dennis Ferguson Tony, > Should I call this the "router guy" view? > > Feel free to call it whatever you like. > > You do not mention that for each packet you may do: > > 1. case dependent, at internet layer you multiply the address match with the > number of local host addresses, or/and with routing table entries. > > 2. At transport level, which 'router guys' ignore systematically, for each > packet received, with data or no data, two address matches are > performed for each socket that is in the list of sockets for that > particular transport, and is not the socket looked for. > > Sorry, I'm lost here. This is worth understanding. I think it is demonstrable that hosts are more greatly affected by the cost of address processing since they generally need to process both the source and destination addresses. When a host receives a packet it must: - determine if the destination address is one of its local addresses. The current IPv4 implementation on Unix machines normally does this by scanning the list of interfaces looking for a match on the local address, which is what the first note is referring to. This becomes a less-than-sensible thing to do if the cost of comparing addresses becomes relatively more expensive than it is now (it is a somewhat dubious practice even now if the host has a lot of interfaces), so let's assume in any case a better implementation might do a binary tree lookup, doing a few bit tests to find the only local address which might match, and then does a single comparison against this address. The cost of variable-length addresses is probably an extra length check in the tree lookup loop (to avoid hosing yourself if the destination in the packet is shorter than host addresses you like) plus the difference in cost of doing a variable- rather than fixed-length comparison of the addresses (a couple of extra instructions plus object code bloat if you switch() to inline comparison code). - find the protocol control block for the transport session. For TCP and UDP this means demultiplexing based on source+destination addresses+ports. For TCP (which is easier) current Unix IPv4 implementations often do a quick comparison against the last protocol control block found, and if this doesn't match they scan the list of all active pcb's, comparing source+destination addresses+ports against each. This is 2. above, and again may be a silly thing to do if addresses are longer and comparisons more expensive, so let's again assume that they'll optimize the heck out of this by (a) using the destination address match done above to locate those pcb's using that local address (a layering violation, probably), and (b) doing a binary tree lookup against the source address and the port pair (with some complexity to deal with wildcarding?) to find the best possible match, then comparing the ports and the source address to find if it matches or not. The cost of variable length addresses is going to be the additional cost of locating the source address in the packet, since it won't be at a fixed offset, a length check in the tree lookup loop to avoid testing bits which aren't in the address, and again the cost of a variable- rather than fixed-length address comparison. Once you have the protocol control block you can checksum any data in the packet along with the transport header (many packets won't have data), process the TCP header (often quick if you can shortcut using header prediction), and move the data out to the application. I think it is clear that variable length address processing is going to cost hosts more than four instructions (it is also clear that bigger addresses of any flavour are going to require hosts to process addresses more cleverly than they might do now if they want to keep the performance up). What I can't estimate is whether the number of instructions it costs a good implementation to deal with variable length addresses is going to be significant compared to the remaining cost of processing the packet. TCP processing can be relatively fast, but there is the checksum on data-bearing packets and the cost of moving the data to the application to consider. I don't know how this might compare. Dennis Ferguson From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 00:56:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22825; Fri, 17 Jun 1994 00:56: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 AAA01896; Fri, 17 Jun 1994 00:55:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA01868; Fri, 17 Jun 1994 00:43:19 +1000 Precedence: list Received: from FRED.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22430; Fri, 17 Jun 1994 00:43:13 +1000 (from craig@BBN.COM) Message-Id: <9406161443.22430@munnari.oz.au> To: big-internet@munnari.OZ.AU Cc: sipp@sunroof.eng.sun.com Subject: address encodings / some code Date: Thu, 16 Jun 94 10:36:12 -0400 From: Craig Partridge Hi folks: I think Tony Li's note which gets us focussing on software is the right approach (we can count instructions and memory accesses and see what the real differences are). So what I've done here is grabbed a copy of the fast IPv4 input for BSD that Van distributed a few years back, modified it to focus on the fast path forwarding code (which we hit some 95% of the time), and hacked up a variant for SIPP (with 64 bit addresses -- 128 bit addresses are a straight extension though they may cause more stalls). Please note, Van bears no responsibility for the various stupid things I've probably done to his code. If someone is willing to hack up a variant for variant address lengths we could then run all the versions through compilers and estimate the timings from the assembly code. Feel free to send me bugfixes -- I'm on travel and did this without recourse to my usual programming environment to test stuff. Craig *********************************************** /* the IPv4 code */ #define HASH(d) ((d) % 101) /* not Van's hash function, which I don't have handy */ ip_input(m) struct mbuf *m; { register struct ip *ip = mtod(m,struct ip *); register u_int len = m->m_len; register u_int dst; register struct cache *cache; /* some sanity checking code not included (e.g., mbuf length checks) */ /* * check IP version number & header length. Min length header * with correct version is special-cased (we know we won't have * to deal with src route or other IP options). */ /* * MEMORY note, this is the first touch of the IP header * and will likely cause a stall until IP data is loaded into cache * * if IP header is multiple cache lines, accessing dst (which is * last 32 bits of header) should load the rest in the else clause */ if (*(char *)ip != ((IPVERSION << 4) | sizeof(struct ip)/4)) { /* handle source routes, etc */ } else dst = ip->ip_dst.s_addr; /* find (or create) cache entry for this destination */ /* MEMORY note, cache entry should be in cache, so no stall */ cache = &ipfwd_cache[HASH(dst)]; if (cache->dst != dst) { /* do full routing lookup */ } if (rt = cache->rt) { /* packet not for us -- forward it */ register int i; register struct ifnet *dest_ifp; /* update time-to-live and checksum */ i = ip->ip_ttl; if (--i <= 0) { discard(m); return; } ip->ip_ttl = i; i = (int) ip->ip_sum + 256; ip->ip_sum = i + (i>>16); dest_ifp = rt->rt_ifp; if (dest_ifp->if_mtu < len) ip_output(m,rt); else (dest_ifp->if_output)(m,rt); } /* packet for local host */ } *********************************************** /* SIPP version */ struct sipp { u_long vers_flow; u_long pay_hop; u_long src[2]; u_long dst[2]; } ; #define HASH(d) ((d[0]+d[1]) % 101) #define FHASH(f,s) (((s[0]+s[1])^f) % 101) /* for flows */ sipp_input(m) struct mbuf *m; { register struct sipp *sipp = mtod(m,struct sipp *); register u_int len = m->m_len; register struct fcache *fcache; register struct cache *cache; /* some sanity checking code not included (e.g., mbuf length checks) */ /* check SIPP version number */ /* * MEMORY note -- will cause at least part of SIPP header to be loaded * into d-cache */ if (*(char *)sipp != (SIPPVERSION << 4)) { discard(m); return; } /* * find (or create) cache entry for this destination * assume SIPP fields laid out as 32-bit quantities, so vers_flow * is the first 32-bits holding version and flow id */ if (sipp->vers_flow & SIPP_FLOWBITS) { /* MEMORY note: source likely loaded when we checked version */ fcache = &sipp_fcache[FHASH(sipp->vers_flow,sipp->src)]; /* * small trick, include sipp version # in fcache field so can * just mask with entire sipp version/flow field */ if ((fcache->src[0] ^ sipp->src[0])|(fcache->src[1] ^ sipp->src[1])| (fcache->flow^sipp->vers_flow)) { /* do full flow lookup */ } } else { /* not a flow */ /* * MEMORY note: dst may not have been loaded when we checked version * and may cause a stall */ cache = &ipfwd_cache[HASH(sipp->dst)]; if ((cache->dst[0] ^ sipp->dst[0])|(cache->dst[1] ^ sipp->dist[1])) { /* do full routing lookup */ } } if (rt = cache->rt) { /* packet not for us -- forward it */ register int i; register struct ifnet *dest_ifp; /* update time-to-live */ i = sipp->pay_hop & 0xff; if (--i <= 0) { discard(m); return; } sipp->pay_hop--; dest_ifp = rt->rt_ifp; if (dest_ifp->if_mtu < len) sipp_output(m,rt); else (dest_ifp->if_output)(m,rt); } /* packet for local host or needs embedded SIPP processing */ } From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 01:15:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23348; Fri, 17 Jun 1994 01:15: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 BAA01978; Fri, 17 Jun 1994 01:15:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA01961; Fri, 17 Jun 1994 01:08:46 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23197; Fri, 17 Jun 1994 01:08:39 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA03962; Thu, 16 Jun 1994 08:08:10 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Jun 1994 08:08:14 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: variable length addresses Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu At 1:22 AM 6/16/94, Noel Chiappa wrote: >Sometimes doing only things that are not significantly different from what you >have done before is a bigger risk. Noel, I'm sure you feel that your response to me was on the point, but it wasn't. My suggestion was to be aware of a category of risk and then to minimize. Minimize does not mean eliminate. Please do not attempt to turn my caution/suggestion into more than it was. to repeat: each step into the unknown entails risk. The more such steps, the more such risk. Worse, I tend to view the accumulation as having worse than a summative relationship. Hence, take only the ones that you are forced to take. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 01:18:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23364; Fri, 17 Jun 1994 01:18: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 BAA01993; Fri, 17 Jun 1994 01:16:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA01959; Fri, 17 Jun 1994 01:08:45 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23196; Fri, 17 Jun 1994 01:08:38 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA03959; Thu, 16 Jun 1994 08:08:02 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Jun 1994 08:08:06 -0700 To: Brian.Carpenter@cern.ch From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: Address mapping (long) Cc: Brian.Carpenter@cern.ch, big-internet@munnari.OZ.AU Brian, I'm afraid that I don't really view your suggestion as doing more than wrapping an envelope around pre-existing bits. I think of "mapping" as involving some sort of translation, so that old bits are transformed into some sort of new pattern. This would, presumably, make all of the different types of addresses really map into some sort of uniform address space. What you are proposing is merely a syntax for switching between different schemes, while preserving the independence of each of those schemes. It's tough to see how this results in any major win for anyone. At 11:06 PM 6/15/94, Brian Carpenter CERN-CN wrote: >Yes. That's what I mean by mapping. Do you have another definition? Dave +1 408 246 8253 (fax: +1 408 249 6205) choose its network interfaces arefully, and check > inbound and outbound match properly... A host must also be prepared to do both specific and wild card matching on addresses. A given received UDP datagram might be the job of a process listening to datagrams only from a single remote host or it might be given to a process that wants all datagrams to a given port. Then there is multicast, which can involve delivering a single datagram to more than one process. That said, I must note that the incoming packet rates on the video-on-demand servers I've heard about are not the same as their outgoing packet rates. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 01:35:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23738; Fri, 17 Jun 1994 01:35: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 BAA02044; Fri, 17 Jun 1994 01:35:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02041; Fri, 17 Jun 1994 01:30:45 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23646; Fri, 17 Jun 1994 01:30:41 +1000 (from vjs@rhyolite.wpd.sgi.com) Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for Big-Internet@munnari.OZ.AU id AA04698; Thu, 16 Jun 94 08:30:34 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA23169; Thu, 16 Jun 94 09:30:02 -0600 Date: Thu, 16 Jun 94 09:30:02 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406161530.AA23169@rhyolite.wpd.sgi.com> To: Big-Internet@munnari.OZ.AU > Subject: Re: variable length addresses > From: jnc@ginger.lcs.mit.edu (Noel Chiappa @ ginger.lcs.mit.edu) > > From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) > > Tony's reply missed some optimizations. > > 1. case dependent, at internet layer you multiply the address match with > the number of local host addresses > > Just assume the packet is for you. If you don't find a matching port ... Some of those optimizations (e.g. check least significant bits first) are classic, and apply more to fixed address sizes than variable. Where do you find the least significant bits in the presense of varying length fields? Or will network byte order in IPng be little endian? Both of you have missed a lot of optimizations. You're both spining out academic ideas at the keyboard, not looking hard to make a particular real implementation faster. It's a great sport that I enjoy, but not relevant. You can obviously make processing a particular address size nearly as fast processing the same but fixed size. You can handle any single address size fast enough so that cost of the bandwidth needed to carry the address size indication is about the same as the cost of checking that the variable length is unchanged. You are ignoring a consequence of your optimizations. What happens to the performance of your hosts and routers should that size change? Suddenly, on the day the Internet gets bigger, without any change on their part, they get a lot slower, and in the distant future when they are already at the limits of their performance. The consequences are not so very different from having to field IP:ng:ng. The "insurance" you are getting from variable length addresses is more like the $5/month stuff advertised on TV, enough for a modest funeral but not enough to put your heirs through Havard. Personally, I think that kind of insurance is a poor investment. On the other hand, if you build your routers and hosts to honestly deal with not just potentially variable length but varying length addresses, if you can run at speed with the rest of the header and the user data at arbitrary offsets, then you will pay in performance. The cost will be only a matter of a few cycles to figure out where everything is, and that cost will be lost in the noise in low performance implementations, but it will loom large in high performance implemenations, those which spend no more than Van Jacobson's handful of cycles/packet. By the way, which sizes of address are proposed? Any length from 8 to 32 bytes including odd values? Note that anything that does not put the user data at predictable boundaries will have catastrophic performance effects on the performance of more than one brand of UNIX workstation. Going from 8 to 9 byte addresses without adding a couple bytes of padding or changing the code and hardware to play the Ethernet trick differently would cost hosts substantially, up to a factor 100. Yes, one hundred times as slow. Those who do not know why I say that should be consider being more cautious in their assertions about how little variable sized fields might hurt. > 2. At transport level, which 'router guys' ignore systematically > > Look, if you get to gratuitously insult our professional competence, expect it > back. And believe me, I can give as well as I get. How many TCP's have you > written from scratch? (Hint: The answer for me is *not* "zero".) How recently did you write that code? How fast did it go, adjusting for the speed of the hardware at the time? Please do not argue on such grounds. None of us can win such arguments and none of us look good indulging in them. Each of us should argue only using facts we personally know to be true. For example, it was recently asserted that Van Jacobson header compression does not work on more than a single TCP stream at a time. That is nonsense to anyone who knows how VJ compression works, to anyone who has seen or written the code or read and remembered the RFC. Typical implementations are limited to 16 simultaneous streams, and the 8-bit "slot ID" in the protocol could obviously be extended to 32 bits to support 4,000,000,000 simultaneous streams and still yield giant compression ratios on 8-byte addresses. Whether you would want to compress headers on a given link or all links is a separate issue. Headers will be compressed on links were not considered slow a few years ago. Even 8-byte addresses guarantee that. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 01:55:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24165; Fri, 17 Jun 1994 01:55: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 BAA02090; Fri, 17 Jun 1994 01:55:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02055; Fri, 17 Jun 1994 01:36:52 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23765; Fri, 17 Jun 1994 01:36:48 +1000 (from yakov@watson.ibm.com) Message-Id: <9406161536.23765@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 8969; Thu, 16 Jun 94 11:36:46 EDT Date: Thu, 16 Jun 94 11:34:37 EDT To: dcrocker@mordor.stanford.edu Cc: big-internet@munnari.OZ.AU Subject: variable length addresses Dave, >The criticisms made by variable-advocates are all true. Every attempt >at predicting the right length has been wrong. Do you think we should do it (trying to predict the right length) one more time and then invest money in building products and transitioning to IPng, so that eventually we'll prove ONE MORE TIME that "every attempt at predicting the right length has been wrong" ? Yakov. From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 01:57:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24202; Fri, 17 Jun 1994 01:57: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 BAA02108; Fri, 17 Jun 1994 01:57:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02074; Fri, 17 Jun 1994 01:48:42 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24046; Fri, 17 Jun 1994 01:48:38 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA04258; Thu, 16 Jun 1994 08:48:25 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 16 Jun 1994 08:48:29 -0700 To: yakov@watson.ibm.com From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: variable length addresses Cc: big-internet@munnari.OZ.AU At 8:34 AM 6/16/94, yakov@watson.ibm.com wrote: >>The criticisms made by variable-advocates are all true. Every attempt >>at predicting the right length has been wrong. > >Do you think we should do it (trying to predict the right length) one >more time and then invest money in building products and transitioning Yes I do. We have no choice. I believe the claimed benefits for variable length addressing entail risks that we do not adequately appreciate and do not need to incur. Further, most such proposals really are fixed-length addressing in variable-length guise. That is, they, too, have an upper bound. There are many, many technical problems and features that most of us would like to tackle for IPng. All are worthy (IMO) but that does not mean that we can or should tackle them. We have a core set of requirements to satisfy and just attending to them is amibitious enough. Adding more increases the risk of the whole project. Increasing the risk of this project, beyond what is absolutely necessary, would be dumb (IMO). Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 02:15:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24478; Fri, 17 Jun 1994 02:15: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 CAA02148; Fri, 17 Jun 1994 02:15:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02127; Fri, 17 Jun 1994 02:07:20 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24347; Fri, 17 Jun 1994 02:07:16 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-12.dialip.mich.net (pm002-12.dialip.mich.net [35.1.48.93]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA10231 for ; Thu, 16 Jun 1994 12:07:11 -0400 Date: Thu, 16 Jun 94 14:48:51 GMT From: "William Allen Simpson" Message-Id: <2684.bill.simpson@um.cc.umich.edu> To: big-Internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: variable length addresses > From: yakov@watson.ibm.com > >I think its critical for this discussion if we have a statement > >from someone that fixed length addresses can or cannot attain wire speed. > > I think we've already seen data from router vendors that wire speed > can be attained with both fixed and variable length addresses. > We have a few such statements from large expensive router vendors. From small inexpensive router vendors, and host vendors, the consensus is clearly that fixed length is best, and variable is unworkable. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 02:17:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24507; Fri, 17 Jun 1994 02: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 CAA02163; Fri, 17 Jun 1994 02:17:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02130; Fri, 17 Jun 1994 02:07:26 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24349; Fri, 17 Jun 1994 02:07:19 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-12.dialip.mich.net (pm002-12.dialip.mich.net [35.1.48.93]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id MAA10237 for ; Thu, 16 Jun 1994 12:07:15 -0400 Date: Thu, 16 Jun 94 15:43:03 GMT From: "William Allen Simpson" Message-Id: <2685.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: variable length Identifiers Well, there has been one thing proved by the 97 messages totalling nearly 7,000 lines yesterday -- the fewer variable-length proponents write more words than the majority fixed-length proponents. Also clear is that the word "address" still is used inconsistently. Some are deliberately baiting the others by using address to mean Locator, when they know the others means Identifier. So, to be clear, let us talk about variable length Identifiers, meaning the part of the address that is included in the end-to-end checksum. If we have variable length Identifiers, why not just use the Fully Qualified Domain Name (FQDN)? This would eliminate DNS lookups, and be simpler for end users to understand. The answer, of course, is that it is too long. Which brings us to: how long is long enough? And, as an aside, do 256 byte Identifiers take only 4 (or 8) additional instructions for process, compared to 8 byte Identifiers? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 02:18:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24576; Fri, 17 Jun 1994 02:18: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 CAA02178; Fri, 17 Jun 1994 02:18:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA02098; Fri, 17 Jun 1994 01:55:49 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24163; Fri, 17 Jun 1994 01:55:40 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Thu, 16 Jun 1994 11:55:38 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 16 Jun 1994 11:55:38 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA02193; Thu, 16 Jun 94 11:53:49 EDT Date: Thu, 16 Jun 94 11:53:49 EDT Message-Id: <9406161553.AA02193@mailserv-D.ftp.com> To: J.Crowcroft@cs.ucl.ac.uk Subject: Re: variable length addresses From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-Internet@munnari.OZ.AU Content-Length: 1093 > >I have no trouble understanding why routers need to quickly parse > >addresses to forward packets to the correct next hop -- and do it very > >quickly. However, even with real-time applications, I can not imagine why > >an end system needs to parse addresses in a similar manner. That is, to get > >an address I use a DNS name and obtain an address. > ok, what about a ipng video on demand server or a transactions server > supporting 100,000 customers > > it has to map addresses into TCP PCBs exactly as fast as the router > forwarding packets to it > > it has to do a _full address match_ not just a prefix one.....unless > you believe the EID stuff (actually, even if you do, such a server > might well be multihomed on multiple provider nets, and > therefore have to choose its network interfaces arefully, and check > inbound and outbound match properly... only when the connection is setup. once the connection has been established, it should have the output interface cached. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 02:20:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24625; Fri, 17 Jun 1994 02:20: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 CAA02193; Fri, 17 Jun 1994 02:20:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02124; Fri, 17 Jun 1994 02:04:45 +1000 Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24288; Fri, 17 Jun 1994 02:04:42 +1000 (from news@sgi.com) Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA08583; Thu, 16 Jun 94 09:00:37 -0700 To: Big-Internet@munnari.OZ.AU Reply-To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: (missing) Message-Id: Precedence: list Date: Thu, 16 Jun 1994 15:46:09 GMT > Subject: Re: variable length addresses > From: jnc@ginger.lcs.mit.edu (Noel Chiappa @ ginger.lcs.mit.edu) > > From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) > > Tony's reply missed some optimizations. > > 1. case dependent, at internet layer you multiply the address match with > the number of local host addresses > > Just assume the packet is for you. If you don't find a matching port ... Some of those optimizations (e.g. check least significant bits first) are classic, and apply more to fixed address sizes than variable. Where do you find the least significant bits in the presense of varying length fields? Or will network byte order in IPng be little endian? Both of you have missed a lot of optimizations. You're both spining out academic ideas at the keyboard, not looking hard to make a particular real implementation faster. It's a great sport that I enjoy, but not relevant. You can obviously make processing a particular address size nearly as fast processing the same but fixed size. You can handle any single address size fast enough so that cost of the bandwidth needed to carry the address size indication is about the same as the cost of checking that the variable length is unchanged. You are ignoring a consequence of your optimizations. What happens to the performance of your hosts and routers should that size change? Suddenly, on the day the Internet gets bigger, without any change on their part, they get a lot slower, and in the distant future when they are already at the limits of their performance. The consequences are not so very different from having to field IP:ng:ng. The "insurance" you are getting from variable length addresses is more like the $5/month stuff advertised on TV, enough for a modest funeral but not enough to put your heirs through Havard. Personally, I think that kind of insurance is a poor investment. On the other hand, if you build your routers and hosts to honestly deal with not just potentially variable length but varying length addresses, if you can run at speed with the rest of the header and the user data at arbitrary offsets, then you will pay in performance. The cost will be only a matter of a few cycles to figure out where everything is, and that cost will be lost in the noise in low performance implementations, but it will loom large in high performance implemenations, those which spend no more than Van Jacobson's handful of cycles/packet. By the way, which sizes of address are proposed? Any length from 8 to 32 bytes including odd values? Note that anything that does not put the user data at predictable boundaries will have catastrophic performance effects on the performance of more than one brand of UNIX workstation. Going from 8 to 9 byte addresses without adding a couple bytes of padding or changing the code and hardware to play the Ethernet trick differently would cost hosts substantially, up to a factor 100. Yes, one hundred times as slow. Those who do not know why I say that should be consider being more cautious in their assertions about how little variable sized fields might hurt. > 2. At transport level, which 'router guys' ignore systematically > > Look, if you get to gratuitously insult our professional competence, expect it > back. And believe me, I can give as well as I get. How many TCP's have you > written from scratch? (Hint: The answer for me is *not* "zero".) How recently did you write that code? How fast did it go, adjusting for the speed of the hardware at the time? Please do not argue on such grounds. None of us can win such arguments and none of us look good indulging in them. Each of us should argue only using facts we personally know to be true. For example, it was recently asserted that Van Jacobson header compression does not work on more than a single TCP stream at a time. That is nonsense to anyone who knows how VJ compression works, to anyone who has seen or written the code or read and remembered the RFC. Typical implementations are limited to 16 simultaneous streams, and the 8-bit "slot ID" in the protocol could obviously be extended to 32 bits to support 4,000,000,000 simultaneous streams and still yield giant compression ratios on 8-byte addresses. Whether you would want to compress headers on a given link or all links is a separate issue. Headers will be compressed on links were not considered slow a few years ago. Even 8-byte addresses guarantee that. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 02:35:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24868; Fri, 17 Jun 1994 02: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 CAA02229; Fri, 17 Jun 1994 02:35:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02220; Fri, 17 Jun 1994 02:30:12 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24776; Fri, 17 Jun 1994 02:30:07 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Thu, 16 Jun 1994 12:30:04 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 16 Jun 1994 12:30:04 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA02894; Thu, 16 Jun 94 12:28:18 EDT Date: Thu, 16 Jun 94 12:28:18 EDT Message-Id: <9406161628.AA02894@mailserv-D.ftp.com> To: craig@BBN.COM Subject: Re: variable length addresses From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Content-Length: 2158 Craig, Is it logical to deduce from your statement that you believe that IPng should be forwardable with the same cache line load and instruction cycle count as IPv4? Is it logical to deduce from your statement that you believe that future silicon (4 years from now, never mind 20) will have the same performance characteristics, in terms of caches, etc, as today? If the answer to either of these questions is no then I would contend that this whole argument is silly and nothing more than the product of coders who worry about doing something that they have not done before. We should first figure out what the architecture for the new IP should be, what problems need to be solved and which ones we intend to solve. Once we do that, we can develop a protocol. Only when we have a protocol should we worry about optimizing it. To worry about optimizations and then make the architecture and specifications fit the optimizations is quite simply backwards. Let's get the architecture and the protocols done. There are plenty of over-bright, over-eager grad students and undergrad students who can figure out how to optimize the architecture and protocol ONCE WE DEFINE THEM. > > I can't believe we're wasting all this time arguing about a few stupid > > instructions. 20 years from now people will look back on this debate and > > wonder what we were all using for brains. Cycles are cheap, and getting > > cheaper. > > Noel: > > Here's why one argues about a few instructions: > > It requires 50-70 instruction cycles and 4 to 8 cache line loads > to forward a current IP datagram using a processor. (Depends on your > architecture). Current processor and memory performance trends say > that these two metrics are roughly balanced (i.e, 4 to 8 cache > line loads can be done in 50 to 70 instruction cycles). > > So, if you add, say 10 instructions to header processing, you've slowed > the system down by 15% to 20%. One more cache line load (say due to bigger > headers) has at least as severe an effect. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 02:55:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25192; Fri, 17 Jun 1994 02: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 CAA02277; Fri, 17 Jun 1994 02:55:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02263; Fri, 17 Jun 1994 02:54:08 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25158; Fri, 17 Jun 1994 02:54:05 +1000 (from valdis@black-ice.cc.vt.edu) Received: (valdis@localhost) by black-ice.cc.vt.edu (8.6.8.1/8.6.7) id MAA05740; Thu, 16 Jun 1994 12:53:56 -0400 Message-Id: <199406161653.MAA05740@black-ice.cc.vt.edu> To: Dave Crocker Cc: big-internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Wed, 15 Jun 1994 16:56:23 EDT." <199406152356.QAA29709@Mordor.Stanford.EDU> From: Valdis.Kletnieks@vt.edu Date: Thu, 16 Jun 1994 12:53:56 +22306356 Sender: valdis@black-ice.cc.vt.edu On Wed, 15 Jun 1994 16:56:23 EDT, Dave Crocker said: > The issue is not fixed-vs-variable, but why the heck we should believe > variable is such a win? The criticisms made by variable-advocates > are all true. Every attempt at predicting the right length has been > wrong. But at least we knew how to make fixed length work and work > well. Hand-waving doesn't make variable safe. If anyting, it increases > the risk. Dave: Yes, we have less experience with variable length. However, which would you rather choose for next time: Yet Another Fixed Length header that falls flat on its face in 2007 and requires a complete replacement of the IP stack, or Some Well-Designed New Variable Length header that suddenly gets REAL SLOW but keeps working when we start expanding from 8 byte addresses to 12? At least this way things keep working until we can re-optimize the stack, an that can be done a host at a time... As somebody (Noel?) pointed out a long time ago, at current growth rates the "current" installed base will be only 5% or so of the total running in 5 years. If you think it's painful to contemplate moving to a non-extensible format *now*, imagine the pain in 15 or 20 years..... Yes. Converting to variable length scares me silly, there's a lot we dont understand. On the other hand, unlike probably a good portion of this list, I'm still going to be in the work force 30 years from now - and that's even scarier... ;) /Valdis (who wonders if anybody else on this list has software that will break in 5 years, 6 months, and 15 days when that yymmdd rolls over) From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 02:58:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25224; Fri, 17 Jun 1994 02:58: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 CAA02293; Fri, 17 Jun 1994 02:57:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA02258; Fri, 17 Jun 1994 02:41:50 +1000 Precedence: list Received: from nsco.network.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24969; Fri, 17 Jun 1994 02:41:41 +1000 (from amolitor@anubis.network.com) Received: from anubis.network.com by nsco.network.com (4.1/1.34) id AA04242; Thu, 16 Jun 94 11:45:57 CDT Received: from blefscu.network.com by anubis.network.com (4.1/SMI-4.1) id AA26580; Thu, 16 Jun 94 11:41:34 CDT Date: Thu, 16 Jun 94 11:41:34 CDT From: amolitor@anubis.network.com (Andrew Molitor) Message-Id: <9406161641.AA26580@anubis.network.com> To: big-Internet@munnari.OZ.AU Subject: Re: variable length addresses Umm, Bill Simpson says that vendors of large expensive routers think variable length addresses are fine, while vendors of cheap, small routers disagree? Is $5K an expensive router? I submit that people who sell slow routers might think that variable length addresses are bad. Not everyone just slaps a net-2 port onto a 68000 and calls it a router, though. I think we've arrived at the following position: - variable length addresses will cost, and the cost will vary according to just how variable the address is (see notes below). - the cost is relatively small, in terms of performance, if one is careful. 10-50 percent seems like a reasonable wild guess for sensible sorts of variable length addresses. - the cost is greater for hosts, therefore an architecture which hid the variable length parts from the hosts might be real slick (Nimrod with routers handling the flow setup and so on and so forth, hosts just see a flat network of things with EIDs) - the development risks might be high. Some feel that we don't know enough about how to route on variable length things to be sure we can do it right. - the benefits of variable length addresses are under scrutiny. The main benefit that people can come up with is ease of administration. It's looking a lot like a smallish win for a smallish cost, when bits hit metal. I don't think anyone thinks we can get away with small, or even medium sized, locators. With something like Nimrod, it doesn't really matter if they're a huge fixed size, or truly variable, since you don't use them all that much. Notes on variability of 'address' length ---------------------------------------- It'd be sort of nice if people could try to be a little more clear on what they mean by 'variable length address.' - Nobody seems to think that Endpoint Identifiers (EIDs) should be variable length at all. There's some disagreement about how big they should be. - 'address' could be one of lots of things, I think that most people seem to mean 'locator', a thing that describes where something with an EID is. This is heirarchical, so making it fixed length, or mandating a maximum length, implies a maximum depth to the routing hierarchy. - 'address' could also mean 'forwarding information', such as a source route. I don't see how it's possible to make this be fixed length, though it probably does come as a variable number of things, each of a fixed size. - A variable length field could be: - any number of bytes in length, with no expected length - any number of words in length, with no expected length - any number of longs in length, with no expected length - any number of bytes in length, with an expected length that we can optimise for - any number of words in length, with ... - any number of longs in length, with ... or any of the above with a maximum allowable size. Other variations are possible, but these seem to be the sane ones. As vjs has pointed out, it'd be a Bad Thing for fields to be anything other than 32-bit aligned and in 32-bit hunks (well, 64 or 128 would be ok, but not less than 32). From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 03:35:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25874; Fri, 17 Jun 1994 03: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 DAA02356; Fri, 17 Jun 1994 03:35:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02342; Fri, 17 Jun 1994 03:21:30 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25519; Fri, 17 Jun 1994 03:21:24 +1000 (from ericf@atc.boeing.com) Received: from atc.boeing.com by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA16446 Fri, 17 Jun 1994 03:20:52 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA08240; Thu, 16 Jun 94 10:20:10 -0700 Date: Thu, 16 Jun 94 10:20:10 -0700 From: Eric Fleischman Message-Id: <9406161720.AA08240@atc.boeing.com> To: J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: variable length addresses Cc: big-internet@munnari.OZ.AU, conta@ucx.lkg.dec.com Dear Jon, >personally, i think there are as many opportunities to assign >variable length wrong as there are advantages in the flexibility ... >this is based on talking to sites with 100k host networks in the UK, i >and note, if someone gets it wrong, the use memory in _all_ routers I doubt if anyone disagrees with you. I would be very surprised if any variable length proponent would advise any entity to deploy the variable length addresses in a single site variably. Rather the sites would select a preferred fixed length and use that. Thus, we might use a 16 byte address because of our hierarchy needs but somebody else may use a 8 byte address because of their more limited hierachy needs. Neither they nor we are liable to mix sizes because that would imply that we would be smart enough to keep them straight. However, should our companies merge together (via an acquisition or some other unforseen event) then we would have to keep a more complicated algorithm in mind: our old company uses 16 bytes and their old company uses 8 bytes. In any case, not too many of us would think that we were smart enough to use multiple sizes in the same site. My point: variable length addresses do not mean that sites necessarily deploy variable sized addresses. It means that different sites may select an address size which they think bests meets their needs. And there must be a fixed upper and lower bound to what "variable" means. Therefore, there is one more component to add to this discussion: One size addresses means that everyone must use the same size addresses: one size must fit all. Variable length addresses gives sites the flexibility to use appropriate sized addresses to best meet their needs. [Of course, "appropriate" is in the eye of the beholder, and I would not want to defend what other people may think "appropriate" to be.] It also leaves open the possibility of escaping from a "wrong length choice" -- but that escape may likely carry with it the requirement to readdress. However, I would prefer to readdress rather than have to redeploy new protocols to compensate for our lack of omnicience as we are for IPv4 ==> IPng. Bottom line: I am always in favor of flexibility unless it carries with it a prohibitive performance penalty. Thus, I am very grateful for those of you who are discussing the performance impacts of these two approaches. Is a consensus beginning to form on that critical issue? How great is the performance hit on hosts for variable length addresses? Sincerely yours, --Eric Fleischman BTW: Dave's mentioning of risk also resonated with me. However, somehow I think that our experience with DECnet/OSI and OSI has meant that we are not totally unexposed to variable length addressing and thus the risks may not be as great as he suggested. Any comments? From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 03:55:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26219; Fri, 17 Jun 1994 03:55: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 DAA02399; Fri, 17 Jun 1994 03:55:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA02385; Fri, 17 Jun 1994 03:51:24 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26151; Fri, 17 Jun 1994 03:51:22 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id KAA05125; Thu, 16 Jun 1994 10:50:37 -0700 Message-Id: <199406161750.KAA05125@Mordor.Stanford.EDU> To: Valdis.Kletnieks@vt.edu Cc: big-internet@munnari.OZ.AU Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: variable length addresses Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 16 Jun 94 12:53:56. <199406161653.MAA05740@black-ice.cc.vt.edu> Date: Thu, 16 Jun 94 10:50:36 -0700 From: Dave Crocker X-Mts: smtp Valdis, ---- Included message: or Some Well-Designed New Variable Length header that suddenly gets REAL SLOW but keeps working when we start expanding from 8 byte addresses to 12? You are making a number of assumptions about the particular risks involved. I believe we don't know enough for such assurances. For example, since we have little design or use experience, any claims that the var-length scheme will be well design is (IMO) inappropriate. Ditto for the sorts of deficient behavior we will experience. As somebody (Noel?) pointed out a long time ago, at current growth rates the "current" installed base will be only 5% or so of the total running in 5 years. If you think it's painful to contemplate moving Your heart is a small percentage of your body mass, but somehow, the medical folks think that it's worth paying very close attention to its well-being. Yes. Converting to variable length scares me silly, there's a lot we dont understand. On the other hand, unlike probably a good portion of this list thank your for this. End of discussion. D/ From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 04:55:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27108; Fri, 17 Jun 1994 04:55: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 EAA02474; Fri, 17 Jun 1994 04:55:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA02460; Fri, 17 Jun 1994 04:54:27 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27087; Fri, 17 Jun 1994 04:54:23 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id LAA05712; Thu, 16 Jun 1994 11:54:16 -0700 Message-Id: <199406161854.LAA05712@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Valdis.Kletnieks@vt.edu, big-internet@munnari.OZ.AU Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: variable length addresses Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 16 Jun 94 14:46:49 -0400. <9406161846.AA10402@ginger.lcs.mit.edu> Date: Thu, 16 Jun 94 11:54:15 -0700 From: Dave Crocker X-Mts: smtp ---- Included message: Hmm. Couldn't you equally say that we don't have enough design or use experience to say that any claims that var-length schemes will be *poorly* designed are not approriate? Clever question, Noel. My own answer is 'no'. Goodness seems to require effort and skill. Badness seems to come for free. (I suppose one could assert rules of entropy and chaos to explain this, but I wouldn't dream of proposing such an explanation myself...) Umm. How much did we understand about the difficulties of moving retransmis sion into the hosts when TCP was done? By 1983, when TCP was put into production use, we had about 10 years of experience with Ethernet (and TCP) exponential backoff concepts. Dave From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 04:57:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27136; Fri, 17 Jun 1994 04:57: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 EAA02489; Fri, 17 Jun 1994 04:57:05 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA02457; Fri, 17 Jun 1994 04:46:59 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26968; Fri, 17 Jun 1994 04:46:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10402; Thu, 16 Jun 94 14:46:49 -0400 Date: Thu, 16 Jun 94 14:46:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406161846.AA10402@ginger.lcs.mit.edu> To: Valdis.Kletnieks@vt.edu, dcrocker@Mordor.Stanford.EDU Subject: Re: variable length addresses Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu From: Dave Crocker You are making a number of assumptions about the particular risks involved. I believe we don't know enough for such assurances. For example, since we have little design or use experience, any claims that the var-length scheme will be well design is (IMO) inappropriate. Hmm. Couldn't you equally say that we don't have enough design or use experience to say that any claims that var-length schemes will be *poorly* designed are not approriate? > Yes. Converting to variable length scares me silly, there's a lot we dont > understand. thank your for this. End of discussion. Umm. How much did we understand about the difficulties of moving retransmission into the hosts when TCP was done? Noel From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 05:15:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27549; Fri, 17 Jun 1994 05:15: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 FAA02528; Fri, 17 Jun 1994 05:15:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA02497; Fri, 17 Jun 1994 04:57:27 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27143; Fri, 17 Jun 1994 04:57:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10490; Thu, 16 Jun 94 14:56:49 -0400 Date: Thu, 16 Jun 94 14:56:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406161856.AA10490@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: Jon Crowcroft I'm not sure I'm fully able to grok the Crowcroftian here, but here goes... :-) TCP she say: me big end to end protocol, need to know end from end Sure, which is why I like EID's (for those who aren't crazy enough to depend on the end-end-identification being included in the end-end-checksum of the pseudo-header of the end-end data :-). I'm perfectly happy to make *them* a reasonable (e.g. 64 bits) fixed length. multihomed host, he say, need to look at varation in address, and check him don't vary from 1 packet to next in same connection Why? If someone moves, they should send you an ICMP message saying "this EID is now at locator , please update yourself". Looking at *every* packet on the offchance that someone has moved seems rather silly. i.e. variable length address necessarily costs more to end system than fixed address. Well, I'm not in favor of variable length addresses. I'm in favor of variable length locators, a big difference. Yes, variable length things take more time to process in software, but intelligent coding can reduce the impact. what is gain to network that is worth loss to end system? Flexibility and adaptability over the entire life-cycle of the system. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 05:17:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27560; Fri, 17 Jun 1994 05:17: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 FAA02543; Fri, 17 Jun 1994 05:16:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA02525; Fri, 17 Jun 1994 05:12:57 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27502; Fri, 17 Jun 1994 05:12:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10636; Thu, 16 Jun 94 15:12:52 -0400 Date: Thu, 16 Jun 94 15:12:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406161912.AA10636@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, craig@bbn.com Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: Craig Partridge It requires 50-70 instruction cycles and 4 to 8 cache line loads to forward a current IP datagram using a processor. ... So, if you add, say 10 instructions to header processing, you've slowed the system down by 15% to 20%. There is a substantially different balance between I/O-memory bandwidth and CPU-memory bandwidth in the routing application, from normal applications. I.e. if your router is handling a bulk data transfer, with lots of large data packets, the number of CPU memory references is a lot smaller, in ratio to the I/O memory references, than it is for most "normal" applications. Then, you have the issue of double transfers of all packet data over the bus, if you have a large single shared memory, which leads you to put large buffers, and some crunchy computing power, out on the interfaces. (This gives you a design that scales better in terms of numbers of interfaces anyway, this being the current trend, for reasons that escape me, since it's bigger single points of failure). So, for high performance routers, you wind up with a specialized hardware base (in terms of the memory, and busses, etc) anyway. I think that you will find that due to this specialized hardware base (and people like Tony can speak to this more than me, since I don't build these things for a living and more, like I used to :-), looking at this particular application from an analysis based on convential workstations CPU's, etc, may not be too fruitful. Perhaps Tony has some additional comments on this particular line? Noel From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 05:35:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27767; Fri, 17 Jun 1994 05:35: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 FAA02580; Fri, 17 Jun 1994 05:35:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA02577; Fri, 17 Jun 1994 05:32:43 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27728; Fri, 17 Jun 1994 05:32:40 +1000 (from valdis@black-ice.cc.vt.edu) Received: (valdis@localhost) by black-ice.cc.vt.edu (8.6.8.1/8.6.7) id PAA09216; Thu, 16 Jun 1994 15:32:36 -0400 Message-Id: <199406161932.PAA09216@black-ice.cc.vt.edu> To: Dave Crocker Cc: big-internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Thu, 16 Jun 1994 11:54:15 EDT." <199406161854.LAA05712@Mordor.Stanford.EDU> From: Valdis.Kletnieks@vt.edu Date: Thu, 16 Jun 1994 15:32:36 +22306356 Sender: valdis@black-ice.cc.vt.edu On Thu, 16 Jun 1994 11:54:15 EDT, Dave Crocker said: > By 1983, when TCP was put into production use, we had about 10 years > of experience with Ethernet (and TCP) exponential backoff concepts. If I remember correctly, the Jan 1 1983 cutover was a "everybody is supposed to be doing TCP rather than NCP. Surely you aren't suggesting that "everybody will be running IPng rather than IPV4 by MM/DD/YY" has a snowball's chance of happening without several years of testing and tuning? Or did I miss the reason why we're running around trying to make a decision this summer so we can have something deployed several years from now? /Valdis From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 05:36:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27810; Fri, 17 Jun 1994 05:36: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 FAA02595; Fri, 17 Jun 1994 05:36:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA02572; Fri, 17 Jun 1994 05:29:16 +1000 Precedence: list Received: from newsun.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27703; Fri, 17 Jun 1994 05:29:11 +1000 (from Don_Provan@Novell.COM) Received: from na.SJF.Novell.COM by newsun.novell.com (4.1/SMI-4.1) id AA20104; Thu, 16 Jun 94 12:29:07 PDT Received: by na.SJF.Novell.COM (4.1/SMI-4.1) id AA22282; Thu, 16 Jun 94 12:29:07 PDT Date: Thu, 16 Jun 94 12:29:07 PDT From: Don_Provan@Novell.COM (don provan) Message-Id: <9406161929.AA22282@na.SJF.Novell.COM> To: Big-Internet@munnari.OZ.AU Subject: proposal for address length solution Allow me to suggest a solution: Have a variable length locator, with the length conveyed within the locator as a count of 32 bit words. Agree to a required maximum that's in line with the size people think the fixed length locator should be. Say 128 bits. Now set the required minimum TO *EXACTLY* THE SAME VALUE. In other words, design the locators to have a length that's variable, but only require implementations to support the single length we agree on at this time. This gives fixed length people their fixed length locators. It gives variable length people their future expansion, although it does not *deploy* that expandability. It doesn't allow shorter locators to save space, either, but perhaps that feature isn't as important as reaching an agreement. Does that idea help any? Frankly I'm a little embarrassed to bring it up, since I've always assumed that the fixed length locators would have some kind of address version number -- reserving the top bit, perhaps -- to allow for expansion at a later time. Even the old IPv4 addresses had room to invent multicast addresses via class D. Personally I think by the time we run out of room in 128 bits, other things will be broken with IPng just as other things are now considered broken in IPv4. If size were IPv4's only problem we could have just defined class E addresses to be 128 bits long and had the implementations all done and deployed two years ago. But I'm always in favor of a little forward compatibility, so I say give the variable length people a variable length, just with a very small range, and get on to *doing* something instead of just bickering. don provan donp@novell.com From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 05:55:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28128; Fri, 17 Jun 1994 05: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 FAA02646; Fri, 17 Jun 1994 05:55:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA02625; Fri, 17 Jun 1994 05:47:30 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28010; Fri, 17 Jun 1994 05:47:25 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA25869; Thu, 16 Jun 94 13:46:53 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB26763; Thu, 16 Jun 94 12:43:52 PDT Date: Thu, 16 Jun 94 12:43:52 PDT Message-Id: <9406161943.AB26763@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: yakov@watson.ibm.com From: Greg Minshall Subject: Re: variable length addresses Cc: big-Internet@munnari.OZ.AU Yakov, >I'd like to point out that the Internet is turning into the Information >market (and it is doing this quite successfully). In such an >environment the information is all over the net, and if the predominant >use of the net is for the information retrieval, then I don't see how >"only 1% traffic" is going to be nonlocal. Foo. If the measured traffic today is "only 1% nonlocal" (not that Jon made quite so strong of an assertion about the validity of his numbers), that is just a fact. What you are doing is waving your hands. I can wave mine, too: one major break in the network today is WWW/Mosaic traffic (hitting the NCSA home page and other popular sites). To fix that, we are going to have to move data closer to the users (caching/replication). This will increase "locality of reference". I suspect (waving of hands) that for most usages, similar things will happen. And, in general, you are ignoring that the predominant use of a LAN is to retrieve information from that LAN; the predominant use of a campus net is to retrieve information from that campus network; etc. Greg From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 05:57:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28159; Fri, 17 Jun 1994 05: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 FAA02661; Fri, 17 Jun 1994 05:57:23 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA02628; Fri, 17 Jun 1994 05:47:50 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28018; Fri, 17 Jun 1994 05:47:47 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA25885; Thu, 16 Jun 94 13:47:22 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB26763; Thu, 16 Jun 94 12:44:21 PDT Date: Thu, 16 Jun 94 12:44:21 PDT Message-Id: <9406161944.AB26763@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: atkinson@itd.nrl.navy.mil From: Greg Minshall Subject: Re: variable length addresses Cc: big-Internet@munnari.OZ.AU Ran, > My point is different, I think. The discussion in Chicago confirmed >my own experience which is that the "network managers" for connected >networks (i.e. not an isolated LAN) _must_ know about subnet masks and >variable length subnetting to do their job reasonably well. I don't >think that will change with IPng. Certainly the large interconnected >IPX networks that I know about have NetWare Network Admins who grok and >need to grok these things for IPX. I just want to make it _easier_ for >such a network admin to use his/her address space more effectively -- >by making nibble boundaries easier to deal with. I have three general key points for IPng: 1. Stateless autoconfiguration (thank you Ross for the term) of end nodes for network connectivity. 2. Easier configuration of routers at customer sites. 3. Service location which is easy and scales (which isn't part of IPng per se, but motivate #1). For #2, IPX, and AppleTalk "classic", routers are reasonably simple for local administrators (at least for network configuration parameters) to configure: an administrator has a bag of unused network numbers and picks one of those numbers at random from the bag and assigns it to the wire (the router's interface to the wire). IPv4 is a nightmare to administer. Subnet masks are a key reason why. Hopefully, IPng will shield all but the "backbone" administrators from any such notions. Hopefully, IPng will give a "bag" of network numbers to local administrators to choose from. (The trick, of course, is doing this and scaling from a routing point of view at the same time!) Greg ps - Which is not to say we shouldn't have ipng_ntoa()... From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 05:58:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28216; Fri, 17 Jun 1994 05:58: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 FAA02676; Fri, 17 Jun 1994 05:58:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA02622; Fri, 17 Jun 1994 05:42:15 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27902; Fri, 17 Jun 1994 05:42:13 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id MAA06306; Thu, 16 Jun 1994 12:42:08 -0700 Message-Id: <199406161942.MAA06306@Mordor.Stanford.EDU> To: Valdis.Kletnieks@vt.edu Cc: big-internet@munnari.OZ.AU Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: variable length addresses Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Thu, 16 Jun 94 15:32:36. <199406161932.PAA09216@black-ice.cc.vt.edu> Date: Thu, 16 Jun 94 12:42:07 -0700 From: Dave Crocker X-Mts: smtp (sigh. sorry. I thought of this issue only after hitting send...) ---- Included message: On Thu, 16 Jun 1994 11:54:15 EDT, Dave Crocker said: If I remember correctly, the Jan 1 1983 cutover was a "everybody is supposed to be doing TCP rather than NCP. Surely you aren't suggesting that "everybody will be running IPng rather than IPV4 by MM/DD/YY" has a No, indeed I'm not. So, either I can argue that the level of commitment we are about to make is comparable to that moment in time, or else I can backup the adoption date reference. I will, of course pursue both... The decision in 1982 (or thereabouts) affected a few hundred machines in 1983, with pretty much none of them being mission critical. The decision today will very, very quickly affect many, many more machines. So, I'm inclined to keep the 1983 reference as a measure of impact. However, if we want to require 'structural' comparability to the reference, then I'd say somewhere around 1980 a "community decision" was made to adopt TCP and its retransmission scheme. (I wasn't part of this activity and might have the date off, slightly, so unless someone wants to assert 1976 or 1983 please don't refine my estimate. Since the first implementation of TCP was in 1976, I doubt we'll have to push the estimate back that far.) In any event, this means that we had a minimum of five years of experience with exponential backoff, and probably more like 7 or 8. That's quite a lot. Also, the progression of work that led to the scheme did constitute a foundation to a useful degree. I'm not sure we can claim the same for a variable length scheme. Yes, we have much improvement over recent years. But I think there is a difference between initial adoption of a reasonably well understood construct, followed by periodic improvement, versus a kind of hand-over-eyes toss of the dart hoping for an improvement, without any meaningful experience to understand the impact. (When pinning the tail on the donkey, be careful it doesn't bite you.) Dave From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 07:40:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00502; Fri, 17 Jun 1994 07:35: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 HAA02800; Fri, 17 Jun 1994 07:35:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA02786; Fri, 17 Jun 1994 07:18:52 +1000 Precedence: list Received: from FRED.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29954; Fri, 17 Jun 1994 07:18:48 +1000 (from craig@BBN.COM) Message-Id: <9406162118.29954@munnari.oz.au> Subject: Re: variable length addresses To: Frank Kastenholz Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Date: Thu, 16 Jun 94 17:11:47 -0400 From: Craig Partridge Hi Frank: > Is it logical to deduce from your statement that you believe that > IPng should be forwardable with the same cache line load and > instruction cycle count as IPv4? If it were feasible yes. I believe no IPng candidate can achieve this goal but I think it is the right kind of goal. Put another way, yes I believe a goal of IPng should be to minimize the number of instructions and cache load/stores required to handle the header. > Is it logical to deduce from your statement that you believe that > future silicon (4 years from now, never mind 20) will have the same > performance characteristics, in terms of caches, etc, as today? Extrapolating from today's trends, the answer is that the performance tradeoffs will generally be worse than today -- i.e., non-cache accesses will be more expensive. > We should first figure out what the architecture for the new IP > should be, what problems need to be solved and which ones we intend > to solve. Once we do that, we can develop a protocol. Only when we > have a protocol should we worry about optimizing it. I believe that this discussion all started on the SIPP list with the question being what the final proposal for SIPP should be, and what were the costs vs. benefits of variable vs. fixed sized addresses for SIPP. In that discussion, performance is very much part of the equation. Craig From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 08:35:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02872; Fri, 17 Jun 1994 08:35: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 IAA02883; Fri, 17 Jun 1994 08:35:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA02866; Fri, 17 Jun 1994 08:23:04 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02400; Fri, 17 Jun 1994 08:22:59 +1000 (from nordmark@jurassic-248.Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA06137; Thu, 16 Jun 94 15:22:26 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA09238; Thu, 16 Jun 94 13:43:05 PDT Received: from bobo.Eng.Sun.COM by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA01261; Thu, 16 Jun 1994 13:41:48 -0700 Received: by bobo.Eng.Sun.COM (5.x/SMI-SVR4) id AA01297; Thu, 16 Jun 1994 13:41:47 -0700 Date: Thu, 16 Jun 1994 13:41:47 -0700 From: nordmark@jurassic-248.Eng.Sun.COM (Erik Nordmark) Message-Id: <9406162041.AA01297@bobo.Eng.Sun.COM> To: Brian.Carpenter@cern.ch Subject: Re: variable length addresses Cc: big-Internet@munnari.OZ.AU Mime-Version: 1.0 > From brian@dxcoms.cern.ch Wed Jun 15 23:14 PDT 1994 > Yes, I forgot to add that hosts must go at wire speed while > only using a few percent of the CPU, I/O and memory bandwidth > to do so. But if you allow a host to spend 10% of its resources > on networking, you need a router of the same power to support > ten wires, to a first approximation. If the host is a server (NFS, database, video server etc) that has 10 wires you still only want to spend a small fraction of CPU and memory bandwith while running all wires at wire speed. My gut feel is that servers have about the same number of wires as routers i.e. the host software running on the servers have to be faster than the router switching hardware+software in order for the servers to be useful as information depositories. Erik From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 08:36:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02896; Fri, 17 Jun 1994 08: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 IAA02898; Fri, 17 Jun 1994 08:36:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA02880; Fri, 17 Jun 1994 08:33:47 +1000 Precedence: list Received: from fnal.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00384; Fri, 17 Jun 1994 07:31:26 +1000 (from crawdad@munin.fnal.gov) Received: from munin.fnal.gov by FNAL.FNAL.GOV (PMDF V4.2-12 #3998) id <01HDM7DGWUI80067MI@FNAL.FNAL.GOV>; Thu, 16 Jun 1994 16:31:06 CDT Received: from LOCALHOST.fnal.gov by munin.fnal.gov (4.1/SMI-4.1) id AA20656; Thu, 16 Jun 94 16:30:52 CDT Date: Thu, 16 Jun 1994 16:30:52 -0500 From: Matt Crawford Subject: Re: variable length addresses In-Reply-To: Your message of Thu, 16 Jun 94 12:53:56. <199406161653.MAA05740@black-ice.cc.vt.edu> To: Valdis.Kletnieks@vt.edu Cc: big-internet@munnari.OZ.AU Message-Id: <9406162130.AA20656@munin.fnal.gov> Content-Transfer-Encoding: 7BIT > However, which would you rather choose for next time: > > Yet Another Fixed Length header that falls flat on its face in 2007 > and requires a complete replacement of the IP stack, or Some > Well-Designed New Variable Length header that suddenly gets REAL SLOW This is a false dichotomy. It ignores many other logically possible choices, such as a fixed length header that works fine until other aspects of the protocol become obsolete. > As somebody (Noel?) pointed out a long time ago, at current growth > rates the "current" installed base will be only 5% or so of the total > running in 5 years. If you think it's painful to contemplate moving > to a non-extensible format *now*, imagine the pain in 15 or 20 years..... Do you not think that the installed base of 15 years hence will be obly 5% of the total running to years from now? Why not? _________________________________________________________ Matt Crawford crawdad@fnal.gov Fermilab From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 10:28:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03626; Fri, 17 Jun 1994 08: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 IAA02946; Fri, 17 Jun 1994 08:55:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA02928; Fri, 17 Jun 1994 08:44:51 +1000 Precedence: list Received: from primus.cstp.umkc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03258; Fri, 17 Jun 1994 08:44:45 +1000 (from lee@PRIMUS.CSTP.UMKC.EDU) Received: by PRIMUS.CSTP.UMKC.EDU (MX V4.0-1 AXP) id 1; Thu, 16 Jun 1994 17:43:49 CST Date: Thu, 16 Jun 1994 17:43:48 CST From: Sung Jong Lee (David) Reply-To: LEE@vax2.cstp.umkc.edu To: big-internet@munnari.OZ.AU Cc: lee@PRIMUS.CSTP.UMKC.EDU Message-Id: <009800C7.BA7522CA.1@PRIMUS.CSTP.UMKC.EDU> Subject: Unsubscribe Please unsubscribe me. From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 10:39:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03647; Fri, 17 Jun 1994 08: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 IAA02961; Fri, 17 Jun 1994 08:56:24 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA02914; Fri, 17 Jun 1994 08:37:58 +1000 Precedence: list Received: from FRED.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00369; Fri, 17 Jun 1994 07:30:02 +1000 (from craig@BBN.COM) Message-Id: <9406162130.369@munnari.oz.au> To: Noel Chiappa Cc: big-internet@munnari.OZ.AU Subject: Re: variable length addresses Date: Thu, 16 Jun 94 17:20:16 -0400 From: Craig Partridge > It requires 50-70 instruction cycles and 4 to 8 cache line loads > to forward a current IP datagram using a processor. ... So, if you add, > say 10 instructions to header processing, you've slowed the system down by > 15% to 20%. > > There is a substantially different balance between I/O-memory bandwidth and > CPU-memory bandwidth in the routing application, from normal applications. > I.e. if your router is handling a bulk data transfer, with lots of large data > packets, the number of CPU memory references is a lot smaller, in ratio to the > I/O memory references, than it is for most "normal" applications. Then, you > have the issue of double transfers of all packet data over the bus, if you > have a large single shared memory, which leads you to put large buffers, and > some crunchy computing power, out on the interfaces. (This gives you a design > that scales better in terms of numbers of interfaces anyway, this being the > current trend, for reasons that escape me, since it's bigger single points of > failure). > > So, for high performance routers, you wind up with a specialized hardware base > (in terms of the memory, and busses, etc) anyway. I think that you will find > that due to this specialized hardware base (and people like Tony can speak to > this more than me, since I don't build these things for a living and more, > like I used to :-), looking at this particular application from an analysis > based on convential workstations CPU's, etc, may not be too fruitful. Noel: I vigorously disagree. If you put the general purpose CPU out on the interfaces (and some folks have done this in the past, and will in the future), the same rules apply. The speed at which the CPU can handle the packets is bounded by the instruction/memory access time. And right now the decision making process is the bottleneck -- otherwise explain to me why it is that we have gigabit busses (implying, with average packet size of 1 Kb, a packet rate of 1 MPS), yet packet rates are only in the few hundreds of thousands of packets per second -- and why we have slow and fast paths in routers... Or, if you prefer, look at the AT&T route approach -- all their CPUs do is decide where to send packets based on the headers (data is transferred over a special bus). Craig From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 10:50:08 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05126; Fri, 17 Jun 1994 09:35: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 JAA03013; Fri, 17 Jun 1994 09:35:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA02997; Fri, 17 Jun 1994 09:24:40 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04658; Fri, 17 Jun 1994 09:24:36 +1000 (from hinden@chestnut.Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA17064; Thu, 16 Jun 94 16:24:15 PDT Received: from chestnut.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA28346; Thu, 16 Jun 94 16:25:28 PDT Received: by chestnut.Eng.Sun.COM (5.0/SMI-SVR4) id AA00674; Thu, 16 Jun 1994 16:25:02 +0800 Date: Thu, 16 Jun 1994 16:25:02 +0800 From: hinden@chestnut.Eng.Sun.COM (Bob Hinden) Message-Id: <9406162325.AA00674@chestnut.Eng.Sun.COM> To: Craig Partridge Cc: big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM In-Reply-To: <9406162118.29954@munnari.oz.au> Subject: Re: variable length addresses Content-Length: 1147 Craig, > I believe that this discussion all started on the SIPP list with the question > being what the final proposal for SIPP should be, and what were the costs vs. > benefits of variable vs. fixed sized addresses for SIPP. In that discussion, > performance is very much part of the equation. You are correct. This started out as a discussion about what to do with SIPP (which is why I copied the SIPP list). I think the outcome of the SIPP discussion is relatively clear (as clear as any email discussion ever is) and is that for SIPP 16byte fixed length addresses are a reasonable middle ground. They resolve the issues that some people have with the size of 8 byte SIPP addresses and make it easier to do auto-configuration. Not everyone agrees with this (one voice who prefers to keep the addresses 8 bytes, and a few who prefer variable length addresses), but I think most of the people working on SIPP seem to support 16byte fixed length addresses. I think the discussion on SIPP should move back to the SIPP list. If folks want to continue the general discussion about fixed vs. variable on the BI, they are free to do so. Bob From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 12:30:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12071; Fri, 17 Jun 1994 12:26: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 MAA03176; Fri, 17 Jun 1994 12:24:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA03172; Fri, 17 Jun 1994 12:13:04 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09869; Fri, 17 Jun 1994 11:32:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12908; Thu, 16 Jun 94 21:32:24 -0400 Date: Thu, 16 Jun 94 21:32:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406170132.AA12908@ginger.lcs.mit.edu> To: craig@bbn.com, hinden@chestnut.eng.sun.com Subject: Re: variable length addresses Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu, sipp@sunroof.eng.sun.com From: hinden@chestnut.eng.sun.com (Bob Hinden) for SIPP 16byte fixed length addresses are a reasonable middle ground. Just to clarify, is this going to be treated as a monolithic entity, or more along the lines of what Bill Simpson suggested (with 8+8, and only the lower 8 bytes being used in the transport pseudo-header)? If folks want to continue the general discussion about fixed vs. variable on the BI, they are free to do so. This debate seems to make remarkably little progress in terms of coming to any conclusion. People may be more educated about the issues, but it's hard to point to any agreement beyond that. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 12:56:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12532; Fri, 17 Jun 1994 12:37: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 MAA03219; Fri, 17 Jun 1994 12:37:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA03167; Fri, 17 Jun 1994 12:10:54 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10506; Fri, 17 Jun 1994 11:49:29 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA29248; Thu, 16 Jun 94 18:41:09 -0700 Received: by xirtlu.zk3.dec.com; id AA03736; Thu, 16 Jun 1994 21:41:06 -0400 Message-Id: <9406170141.AA03736@xirtlu.zk3.dec.com> To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Thu, 16 Jun 94 12:28:18 EDT." <9406161628.AA02894@mailserv-D.ftp.com> Date: Thu, 16 Jun 94 21:41:00 -0400 X-Mts: smtp >If the answer to either of these questions is no then I would contend >that this whole argument is silly and nothing more than the product >of coders who worry about doing something that they have not done >before. First its not silly. Second I could take the coders view and say we are sick of architecture folks trying to build protocols in the IETF for IPng. Now we have real coders (not used to be coders) but folks developing code from all proposals. I take your statement as an attack to those folks whose companies are paying them to see if any of these ideas will ever work and perform. I don't think you would want the coders to go away from this forum then all you would have is rough consensus and no running code. >Let's get the architecture and the protocols done. There are plenty >of over-bright, over-eager grad students and undergrad students who >can figure out how to optimize the architecture and protocol ONCE WE >DEFINE THEM. Well I think all the coders should quit coming to the IETF if this is the respect they have and let the IETF go into pure research mode. And then no one in the market would take it seriously other than a think tank. I think you went overboard here about the coders is my point. /jim From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 13:04:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13645; Fri, 17 Jun 1994 13:04: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 NAA03269; Fri, 17 Jun 1994 13:04:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA03266; Fri, 17 Jun 1994 13:04:07 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13625; Fri, 17 Jun 1994 13:03:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13613; Thu, 16 Jun 94 23:03:26 -0400 Date: Thu, 16 Jun 94 23:03:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406170303.AA13613@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, vjs@rhyolite.wpd.sgi.com Subject: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) > Tony's reply missed some optimizations. Some of those optimizations (e.g. check least significant bits first) are classic, and apply more to fixed address sizes than variable. Where do you find the least significant bits in the presense of varying length fields? The only optimization I suggested along these lines was to check the ports first. They should be easy to find, and if you have an "internetwork header length" field in IPng, it will takes *exactly* the same number of instructions to find them as with IPv4, since IPv4 already has variable length internetwork headers, and I doubt there's much code that optimizes for the "no options" case (Van's header prediction might, I don't remember). In any case, the cost of getting the pointer to the TCP header is swamped by the costs of checking more than a few control blocks. Both of you have missed a lot of optimizations. Good, can you point them out? You're both spining out academic ideas at the keyboard, not looking hard to make a particular real implementation faster. I understand the point you are trying to make, that we are looking at hypothetical implementations, not real ones, and it's a good and valid one. However, you could have said that without the "academic" label, which was gratuitous, since this is one of the common ways used to put down things as "too impractical". Can we all please continue this without ad hominem comments? It's a great sport that I enjoy, but not relevant. What else can we do? Try and look at all possible implementations and average over them? Looking at a particular instance (even if hypothetical) has given us, I think, a clearer idea of what the minimal costs really are... You can obviously make processing a particular address size nearly as fast processing the same but fixed size. ... What happens to the performance of your hosts and routers should that size change? The kind of thing Tony outlined, with the jump table, does not suffer any massive loss of performance when you change the size; the cost does increase, but in line with the increase in size of the address. The flexibility and adaptability seems well worth it to me, especially when taken with your comment that the processing can be made almost as efficient as for the same, but fixed, size. We'll only pay the cost of larger items if and when we start using them, not now. Suddenly, on the day the Internet gets bigger, without any change on their part, they get a lot slower, and in the distant future when they are already at the limits of their performance. I don't think so. Processors are still getting faster all the time, so by the time addresses get larger, there'd be more processing power aroud nto handle them. Of course, we're probably also sending more packets by then, etc, etc, but it's not quite as bleak as you indicate here. if you can run at speed with the rest of the header and the user data at arbitrary offsets, then you will pay in performance. If by "arbitrary", you mean "unaligned", then this is a bit unfair. Nobody is talking about doing *either* of these. It's easy to i) put all the variable length fields at the end of any header, and ii) either pad each one so the next thing is aligned, or pad that whole header when done, so the *next* header is aligned, etc. Variable length *headers* do not have to impose a significant cost to the processing of the following headers. Also, trying to make it look like you don't have variable length headers, by use of repetitive encapsulation, is a bit of a shell-game; it's still going to take processing power to handle those encapsulated headers. Depending on what the variable length *data items* are in such header, there may or may not be a significant cost in handling those data items, but that depends on the details of the use of those fields. If you have a fixed length EID, a variable length address or locator is obviously a lot less expensive overall, since many of the expensive operations at the transport level (such as control block location, etc) would be performed on the EID. Etc, etc. that cost will be lost in the noise in low performance implementations, but it will loom large in high performance implemenations, those which spend no more than Van Jacobson's handful of cycles/packet. Just out of interest, how does VJ prediction find the control block quickly? Does it use much the same code as the vanilla BSD, or does he have some tricks there too? E.g., keeping the control blocks linked in MRU order? (Details all omitted to keep this short! :-) By the way, which sizes of address are proposed? Any length from 8 to 32 bytes including odd values? Well, for locators (i.e. not in every packet), my preference would consist of a sequence of variable number of variable length elements. These elements would usually only be a byte or two, but the last one would typically be longer; e.g. 48 bits. Note that anything that does not put the user data at predictable boundaries will have catastrophic performance effects on the performance ...Going from 8 to 9 byte addresses without adding a couple bytes of padding Yes, clearly any variable length fields should be padded to keep things aligned. However, note that IPv4 does this already (the internetworking header is padded to a multiple of 32 bits). How recently did you write that code? How fast did it go, adjusting for the speed of the hardware at the time? It was some years ago, but I was getting a good fraction of a megabit/sec from a 68000 (or 68010, I don't remember which, and I don't recall the clock speed) running from a data source to a data sink on another machine over an Ethernet. I had to go through an IPC to send the packets, which was something of a bottleneck as I recall, but the details are faded. Please do not argue on such grounds. None of us can win such arguments and none of us look good indulging in them. I'd be more than happy to refrain, especially if it's agreed that you don't have to be writing or maintaining code *this week* to have anything of value to say. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 13:55:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15067; Fri, 17 Jun 1994 13:45: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 NAA03325; Fri, 17 Jun 1994 13:44:25 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA03310; Fri, 17 Jun 1994 13:26:53 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11389; Fri, 17 Jun 1994 12:10:19 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA16070; Thu, 16 Jun 94 19:02:55 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA20384; Thu, 16 Jun 1994 22:02:54 -0400 Date: Thu, 16 Jun 1994 21:56:27 -0400 Message-Id: <94061621562772@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu Subject: Re: variable length addresses X-Vms-To: SMTP%"J.Crowcroft@cs.ucl.ac.uk" X-Vms-Cc: SMTP%"big-internet@munnari.oz.au", SMTP%"jnc@ginger.lcs.mit.edu",CONTA >From: SMTP%"J.Crowcroft@cs.ucl.ac.uk" 16-JUN-1994 06:54:55.03 >To: jnc@ginger.lcs.mit.edu (Noel Chiappa) > >(There, I've saved enough cycles for you to more than pay for variable length > >addresses! :-) > > Noel > >information theorey, she say: > >if you have variable lenth address, you must vary it, otherwiase it >conveys nothing > >TCP she say: me big end to end protocol, need to know end from end > >multihomed host, he say, need to look at varation in address, and >check him don't vary from 1 packet to next in same connection > > (-: (-: (-: You're a funny Englishman ! Alex From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 14:24:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16661; Fri, 17 Jun 1994 14:24: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 OAA03369; Fri, 17 Jun 1994 14:24:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA03355; Fri, 17 Jun 1994 14:04:49 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15981; Fri, 17 Jun 1994 14:04:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13973; Fri, 17 Jun 94 00:04:37 -0400 Date: Fri, 17 Jun 94 00:04:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406170404.AA13973@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, conta@ucx.lkg.dec.com Subject: re: variable length (and hopefully with an end) Cc: jnc@ginger.lcs.mit.edu From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) I didn't mean to give any pejorative sense to what I've said, but I take responsability for it, and if it sounded that way to you or others, here is my sorry. Sorry I got upset, but I'm getting tired of being told I (and the arguments I'm using) are too abstract, too academic, too unrealistic, too out of touch, etc, etc, etc. So, perhaps I sometimes hear it being said when it's not. so I hope what you said is not an attempt of intimidation, or switch of the character of the debate. No, let's just stick to the purely technical debate, and I'll be as happy as everyone else. On this list there is an exhibition of good and civilized debate, good ideas, good expertize, good profesional pride, good and fruitful colaboration, but at times, fortunately rare, also of extreme egocentrism, of ideas with no start or no end, of political crap, of bad manners, and so on... It would be difficult if not impossible to have one side without the other, it's just real life. Yup. There's also a great deal riding on what we decide, and thus a great deal of stress here, and nerves get stretched a bit thin; what's sometimes amazing to me is not that we have the blowups we do, but that we don't have more. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 16:02:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17497; Fri, 17 Jun 1994 14:44: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 OAA03415; Fri, 17 Jun 1994 14:44:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA03409; Fri, 17 Jun 1994 14:42:18 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15424; Fri, 17 Jun 1994 13:53:20 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA20324; Thu, 16 Jun 94 20:47:38 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA20521; Thu, 16 Jun 1994 23:47:14 -0400 Date: Thu, 16 Jun 1994 23:42:49 -0400 Message-Id: <94061623424900@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: re: variable length (and hopefully with an end) X-Vms-To: SMTP%"jnc@ginger.lcs.mit.edu" X-Vms-Cc: SMTP%"big-internet@munnari.oz.au",CONTA >From: SMTP%"jnc@ginger.lcs.mit.edu" 16-JUN-1994 02:02:14.79 >To: conta@ucx.lkg.dec.com, big-internet@munnari.oz.au > > etc. etc. etc. etc... > >... I find it damned insulting, thank you. > >> 2. At transport level, which 'router guys' ignore systematically > >Look, if you get to gratuitously insult our professional competence, expect it >back. Wait a minute, I didn't mean to give any pejorative sense to what I've said, but I take responsability for it, and if it sounded that way to you or others, here is my sorry. Nothing I've said is worse or more than what you or others did... and so I hope what you said is not an attempt of intimidation, or switch of the character of the debate. >How many TCP's have you written from scratch? >(Hint: The answer for me is *not* "zero".) Well if you want me to tell you what I did, and to listen at what you did then we will have to take that somewhere else. Toronto may have a good beer, or a nice view, or whatever... ... By the way this is not meant as offense to anyone. On this list there is an exhibition of good and civilized debate, good ideas, good expertize, good profesional pride, good and fruitful colaboration, but at times, fortunately rare, also of extreme egocentrism, of ideas with no start or no end, of political crap, of bad manners, and so on... It would be difficult if not impossible to have one side without the other, it's just real life. Alex From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 16:02:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17565; Fri, 17 Jun 1994 14:46: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 OAA03430; Fri, 17 Jun 1994 14:45:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA03412; Fri, 17 Jun 1994 14:42:21 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14712; Fri, 17 Jun 1994 13:34:52 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13794; Thu, 16 Jun 94 23:34:46 -0400 Date: Thu, 16 Jun 94 23:34:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406170334.AA13794@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: variable length Identifiers Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" the fewer variable-length proponents write more words than the majority fixed-length proponents. Perhaps the reason not more have spoken up is they don't have anything to add. Still, it's a good point; can we hear from some other people, especially (as far as I'm concerned) from people who want variable length addresses/ locators? (However, read through to the section about the "three camps" before identifying what you prefer.) Also clear is that the word "address" still is used inconsistently. True. I try to always mean it to use "a topogically sensitive name which occurs in all packets", but that still doesn't answer the question of "is this the name of the end-end entity as well". That's why I don't like the term "address", but it continues to be used. Some are deliberately baiting the others by using address to mean Locator, when they know the others means Identifier. Are you sure? I thought all this recent discussion was about topologially sensitive things, not end-end identifiers. If so, I've been labouring under a grave misapprehension, as I favor (although not irrevocably) fixed-length identifiers. Since I know not everyone agrees with the idea of splitting the end-end identification from the topological location function, and others don't like leaving the latter out of some packets, I try and respond in whatever framework they are using. If someone uses the term "address" in a message, what should I do in responding? So, to be clear, let us talk about variable length Identifiers, meaning the part of the address that is included in the end-to-end checksum. You just used "address" in what some might see as an inconsistent fashion. I can see 3 major camps into which people might fall, divided into a variety of sub-camps. - A single field, used both to indentify end-end entities, and topologically sensitive. (We call this an address, right?) - Separate fields for thse two functions, and the latter is always present. (We often call the former an EID, but we also call the latter an address, I guess?) - Separate fields, and the latter is sometime not present when a packet belongs to a flow. (The latter is called a locator in this case.) Then, for each case, you get to ask the fixed/variable length question, in the latter two cases twice. So it can all get very confusing. I expect we have many different factions. You seem to favor the second case, with fixed in each instance. Others prefer the first; some with fixed length, others with variable. I prefer the third, with fixed length EID's, and variable length locators. These disagreements is not going to be settled by debate here. In light of this, perhaps the IETF as a whole was naive when it decided to try and push for a single IPng. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 16:24:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21343; Fri, 17 Jun 1994 16:24: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 QAA03525; Fri, 17 Jun 1994 16:24:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA03522; Fri, 17 Jun 1994 16:13:54 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20885; Fri, 17 Jun 1994 16:13:39 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA25950; Thu, 16 Jun 94 23:09:41 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA20707; Fri, 17 Jun 1994 02:09:19 -0400 Date: Fri, 17 Jun 1994 01:55:55 -0400 Message-Id: <94061701555573@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: mo@uunet.uu.net, big-internet@munnari.OZ.AU, J.Crowcroft@cs.ucl.ac.uk Subject: Re: Maybe we have a definitional problem X-Vms-To: SMTP%"mo@uunet.uu.net" X-Vms-Cc: SMTP%"big-internet@munnari.oz.au", SMTP%"J.Crowcroft@cs.ucl.ac.uk",CONTA >From: SMTP%"mo@uunet.uu.net" 16-JUN-1994 08:58:16.54 >To: big-internet@munnari.oz.au Mike may have perceived quite well the gut reaction (-:. As I see it, and perhaps are many to share this view, the very valuable merit of a "variable address" (variable Network ID, fixed Host ID) is more the capability of unlimited growth, then having at a given time the liberty of specifying any address size. That is quite a bit related to the fact that I think it is dangerous to have at a given time a mixture of address lengths in the global network. I am a bit horified to the prospect that someone may need configure a host with one interface to a network with an address of N bytes, and the other interface to a network of N+M bytes, with different masks, and masks sizes, etc... - this could turn into a management nightmare. Not to mention the incresed level of difficulty in implementing the mechanisms to handle combinations of different lengths. Therefore I believe that the variable address size should be part of a rather "managed growth of the address space". In the boundaries of this concept, the address assignment would be carefully controlled, through the process of assignment itself, and have the address space uniformly distributed, such that the address size would be the same globally, and it would grow when strictly necessary, with the same number of multiple of 64bits globally. In other words, if after year 2000 + x, 64bits of address are nolonger sufficient, in year 2000 + x, the Internet is switched to 128 bits, with new prefixes, being added to existent addresses. Similarly, to 192 bits, and so on. This will make the header essentially look like a fix address header - both addresses are the same size. A field in the main header - the version number or a header size concatenated with the version number - would indicate the type or size of the header and thus addresses. By the way this possible solution is so simple that many may have thought of and mentioned it in one shape or another - there are days I simply skip messages, I don't know how one could read all of them and do some other work as well - but recently it became more and more a topic of reflection for myself, and discussion with various people, and collegues. The planning of what to do at switching the addressing to a larger address space can be done from the very beginning, in the sense that APIs, DNS, configuration, etc. would provide adequate space for growths, such that applications would have to go through NO MODIFICATIONS when the size of the address space is changed. This can be done by an adequate design of address related structures and required buffers. Kernels - lower layers - would have to be rebuilt to take in consideration an address growth. THis may be a major negative point, but with an ahead of time planning, it can be done with more ease. Alex From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 18:44:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26757; Fri, 17 Jun 1994 18:44: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 SAA03664; Fri, 17 Jun 1994 18:44:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA03661; Fri, 17 Jun 1994 18:43:25 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25277; Fri, 17 Jun 1994 18:09:28 +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 AA15993 Fri, 17 Jun 1994 18:09:19 +1000 (from barney@databus.databus.com) Date: Fri, 17 Jun 94 04:05 EDT Message-Id: <9406170408.AA00895@databus.databus.com> From: Barney Wolff To: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU, bsimpson@MorningStar.Com Subject: Re: variable length Identifiers Content-Length: 523 Content-Type: text Noel, if fixed EIDs and variable locators are both right, does this imply that the uncertainties of network topology are greater than the uncertainties of administrative assignment of EIDs? I don't have a sense of the reasoning behind this. A more general question: Since frame relay and ATM mean that a host with a single physical interface may have dozens, hundreds or thousands of logical interfaces, do the routing-over-large-clouds folks have any insights for us in this debate? Barney Wolff From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 20:42:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27566; Fri, 17 Jun 1994 19:04: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 TAA03694; Fri, 17 Jun 1994 19:04:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA03669; Fri, 17 Jun 1994 18:45:11 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24933; Fri, 17 Jun 1994 18:00:21 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA13192; Fri, 17 Jun 1994 00:59:39 -0700 Date: Fri, 17 Jun 1994 00:59:39 -0700 From: Tony Li Message-Id: <199406170759.AAA13192@lager.cisco.com> To: big-internet@munnari.OZ.AU Subject: Why variable length? Folks, Here are some numbers which help explain why I'm very concerned about 16 byte addresses. The reasoning here is a bit long and tortuous. Please bear with me. Currently, for IPv4 we've allocated about 1.6e9 host addresses. We have, approximately, 2e6 hosts actually connected. That means that we have an efficiency of 1.25e-3. [Yes, that's right, about 800 allocated addresses per actual used address. ;-( ] Why are these numbers so bad? Because there's a lot of waste when we assign an address to an organization. Typically, a site has two levels of hierarchy, with a network number and then subnets and hosts on each subnet. Some subnets go unused because the organization just doesn't need them yet. They can't be easily given away because the organization will need to grow, and if their address allocation is TOO tight, they'll need another network number. That would be bad for routing, for reasons that I won't go into here. So there's some unavoidable waste. Further, there's waste because each subnet can't be completely filled. Usually this is simply because the subnet mask is fixed across the organization and was chosen to simplify human factors. The subnets are just plain bigger than they need to be. There's also some unavoidable wasteage here because the subnet is sized to be a power of two. Axiom 1: Hierarchical addressing on bit boundaries has a considerable amount of unavoidable waste. If we restrict where we're willing to put hierarchical boundaries on more granular boundaries (byte, nibble) so that network managers are able to work with them more easily, we lose more addresses because there's more waste at both within each subnet, and probably we need more subnets within each network. This leads to Corollary 1: Hierarchical addressing on byte or nibble boundaries is even more wasteful. While we do know that CIDR will help these numbers, we're just beginning to see how that will really work in the real world. Certainly only the early adopters have deplyed CIDR within their networks and are making effective use of variable length subnet masks. Nonetheless, we can use our existing numbers as a worst case measurement for IPng addressing efficiency. To this end, we'd like to characterize the efficiency of IPng multi-level addresses. We can easily see that Axiom 2: The cummulative efficiency of an addressing plan is the product of the efficiencies at each level. For example, if we have 100 subnets and we are 10% efficient, and each subnet could have 100 hosts and we're again 10% efficient, then we've only used 10*10 = 100 addresses out of 100 * 100 = 10000 possible addresses, giving 1% efficiency. Approximation 1: Thus, with the IPv4 two level addressing hierarchy, we can get a first approximation of the efficiency at each level as sqrt(1.25e-3) ~= .03. Now, let's take a look at 16 byte addresses. If we take an addressing plan such as has been proposed for BigTen, we see that we have some administrative wasteage up front, and 6 bytes for an IEEE 802 address. Dividing up the remaining space, we see that it's convenient to have approximately 7 or 8 levels of hierarchy. Approximation 2: A 7 level hiearchical system has a worst-case efficiency of .03^7 = 2e-11. How many addresses are there _really_ in a 16 byte address? Well, the IEEE 802 address consumes 6 bytes, and we also have approximately one byte of administrative overhead at the front of the address. The result is that we have 16 - 6 - 1 = 9 bytes of effective address space. Approximation 3: There are roughly 2^(9 * 8) = 2^72 = 4e21 addresses useable. Given approximation 2 and 3, we see that Approximation 4: 16 byte addresses with a 7 level hierarchical addressing system can support an Internet of 4e21 * 2e-11 = 8e10 hosts, in the worst case. And that's why I'm scared that 16 bytes is not enough. Tony From owner-Big-Internet@munnari.OZ.AU Fri Jun 17 22:27:57 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01396; Fri, 17 Jun 1994 21:06:03 +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 AA21345 Fri, 17 Jun 1994 20:49:39 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id UAA03796; Fri, 17 Jun 1994 20:44:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA03782; Fri, 17 Jun 1994 20:37:14 +1000 Precedence: list Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27832; Fri, 17 Jun 1994 19:16:18 +1000 (from ses@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA04915; Fri, 17 Jun 94 05:15:54 EDT Message-Id: <9406170915.AA04915@tipper.oit.unc.edu> To: Craig Partridge Cc: Frank Kastenholz , jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Thu, 16 Jun 94 17:11:47 EDT." <9406162118.29954@munnari.oz.au> Date: Fri, 17 Jun 94 05:15:53 -0400 From: Simon E Spero >>>>> "Craig" == Craig Partridge writes: Craig> I believe that this discussion all started on the SIPP list Craig> with the question being what the final proposal for SIPP Craig> should be, and what were the costs vs. benefits of Craig> variable vs. fixed sized addresses for SIPP. In that Craig> discussion, performance is very much part of the equation. This discussion is interesting, but it's kind of hard to discuss performance and cache-line misses without really knowing what the characteristics of hardware in the future. Craig- since you're one of the resident gigabitologists, could you try outlining a few possibly configurations to work with- e.g. register width, line width, number of cycles to load cache, number of cache lines etc. That way, we can try some cycle counts for different situations, and see if any obvious problems manifest themselves. From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 00:27:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07660; Sat, 18 Jun 1994 00:07: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 AAA03976; Sat, 18 Jun 1994 00:04:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA03957; Fri, 17 Jun 1994 23:48:12 +1000 Precedence: list Received: from nbkanata.Newbridge.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05002; Fri, 17 Jun 1994 23:00:17 +1000 (from jhalpern@mako.Newbridge.COM) Received: from Newbridge.COM (thor.Newbridge.COM) by nbkanata.newbridge.com (4.1/SMI-4.1) id AA28014; Fri, 17 Jun 94 08:55:36 EDT Received: from mako.newbridge by Newbridge.COM (4.1/SMI-4.0) id AA27169; Fri, 17 Jun 94 08:55:34 EDT Received: from urchin.newbridge by mako.newbridge (4.1/SMI-4.1) id AA20004; Fri, 17 Jun 94 08:55:31 EDT Received: by urchin.newbridge (5.0/SMI-SVR4) id AA02573; Fri, 17 Jun 1994 08:57:54 +0500 Date: Fri, 17 Jun 1994 08:57:54 +0500 From: jhalpern@mako.Newbridge.COM (Joel Halpern) Message-Id: <9406171257.AA02573@urchin.newbridge> To: big-internet@munnari.OZ.AU Subject: Re: variable length Identifiers X-Sun-Charset: US-ASCII Content-Length: 1585 Since people are drawing conclusions from the number of participants in this length debate, I will put in my opinion as to what I would like to see. I have not even tried to determine if there is a reasonable way for SIPP or any other proposal to meet the goal. This is an isolated observation. 1) I think that the logical separation between Locator and EID is valuable, and I would like to see it used. 2) I think that 64 bit EIDs (fixed sized) are quite practical. While they may or may not have internal structure for inverse lookup or administration, all other processing shall treat them as single, uninterpretable sequence of uniquely identifying bits. 3) EIDs are used by transport to identify connection endpoints. They may also be used by last hop routing using an ES-IS or ARP like mechanism. 4) Locators are variable length. They have extra internal structure so as to make the router processing easy and effective if necessary. I am not yet convinced we will be able to omit locators from the majority of packets. Variable length locators, carefully defined, give us the power and flexibility to move forward in architecture and deployment. 5) Without some idea of how the topology is going to be managed, communicated, and controlled, it is not a good idea to specify too much about how locators are built. We need some notion of what our routing/topology architecture looks like, so we know what will need to be named. Thank you, Joel M. Halpern jhalpern@newbridge.com Newbridge Networks Inc. From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 00:27:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07678; Sat, 18 Jun 1994 00:09: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 AAA03991; Sat, 18 Jun 1994 00:09:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA03971; Fri, 17 Jun 1994 23:55:12 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06177; Fri, 17 Jun 1994 23:32:35 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Fri, 17 Jun 1994 09:32:30 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 17 Jun 1994 09:32:30 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA14103; Fri, 17 Jun 94 09:30:42 EDT Date: Fri, 17 Jun 94 09:30:42 EDT Message-Id: <9406171330.AA14103@mailserv-D.ftp.com> To: bound@zk3.dec.com Subject: Re: variable length addresses From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 1817 > Return-Path: > To: kasten@ftp.com > Cc: big-internet@munnari.oz.au > Subject: Re: variable length addresses > In-Reply-To: Your message of "Thu, 16 Jun 94 12:28:18 EDT." > <9406161628.AA02894@mailserv-D.ftp.com> > Date: Thu, 16 Jun 94 21:41:00 -0400 > From: bound@zk3.dec.com > X-Mts: smtp > Content-Type: text > Content-Length: 1246 > > > >If the answer to either of these questions is no then I would contend > >that this whole argument is silly and nothing more than the product > >of coders who worry about doing something that they have not done > >before. > > First its not silly. Second I could take the coders view and say we are > sick of architecture folks trying to build protocols in the IETF > for IPng. Now we have real coders (not used to be coders) but folks > developing code from all proposals. I take your statement as an attack > to those folks whose companies are paying them to see if any of these > ideas will ever work and perform. I don't think you would want the > coders to go away from this forum then all you would have is rough > consensus and no running code. > > >Let's get the architecture and the protocols done. There are plenty > >of over-bright, over-eager grad students and undergrad students who > >can figure out how to optimize the architecture and protocol ONCE WE > >DEFINE THEM. > > Well I think all the coders should quit coming to the IETF if this is > the respect they have and let the IETF go into pure research mode. And > then no one in the market would take it seriously other than a think > tank. > > I think you went overboard here about the coders is my point. > > /jim > -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 02:28:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11155; Sat, 18 Jun 1994 01: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 BAA04155; Sat, 18 Jun 1994 01:44:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA04115; Sat, 18 Jun 1994 01:36:50 +1000 Precedence: list Received: from gasco.gasco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09555; Sat, 18 Jun 1994 01:02:42 +1000 (from dmk@gasco.com) Received: by gasco.com (/\==/\ Smail3.1.28.1 #28.4) id ; Fri, 17 Jun 94 07:58 PDT Received: by anise.gasco.com (Smail3.1.28.1 #5) id m0qEfM1-0002uRC; Fri, 17 Jun 94 07:57 PDT From: dmk@anise.gasco.com (David M. Koon) Message-Id: <9406170757.ZM4463@anise.gasco.com> Date: Fri, 17 Jun 1994 07:57:12 -0700 Reply-To: dmk@gasco.com X-Mailer: Z-Mail (3.1.0 22feb94 MediaMail) To: big-internet@munnari.OZ.AU Subject: Please unsubscribe me from this list Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 Please unsubscribe davek@ims.com from this list. Thanks, -- David M. Koon IBM/NNG Network Administrator 226-4211 ext 5747 From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 02:29:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11241; Sat, 18 Jun 1994 01:49: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 BAA04171; Sat, 18 Jun 1994 01:49:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA04126; Sat, 18 Jun 1994 01:37:45 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09554; Sat, 18 Jun 1994 01:02:38 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-06.dialip.mich.net (pm002-06.dialip.mich.net [35.1.48.87]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA08115 for ; Fri, 17 Jun 1994 11:01:03 -0400 Date: Fri, 17 Jun 94 14:37:22 GMT From: "William Allen Simpson" Message-Id: <2696.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: variable length Identifiers > Noel, if fixed EIDs and variable locators are both right, does this imply > that the uncertainties of network topology are greater than the uncertainties > of administrative assignment of EIDs? I don't have a sense of the > reasoning behind this. > Yes. Human administration changes slowly. Network topology changes much more quickly. > A more general question: Since frame relay and ATM mean that a host with > a single physical interface may have dozens, hundreds or thousands of > logical interfaces, do the routing-over-large-clouds folks have any > insights for us in this debate? > The "logical interfaces" would all have the same Locator. Each "logical interface" could have a separate Identifying-Address. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 02:29:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11254; Sat, 18 Jun 1994 01:50: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 BAA04186; Sat, 18 Jun 1994 01:50:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA04129; Sat, 18 Jun 1994 01:38:12 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09538; Sat, 18 Jun 1994 01:02:34 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-06.dialip.mich.net (pm002-06.dialip.mich.net [35.1.48.87]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA08112 for ; Fri, 17 Jun 1994 11:01:00 -0400 Date: Fri, 17 Jun 94 14:27:20 GMT From: "William Allen Simpson" Message-Id: <2695.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: variable length Identifiers > True. I try to always mean it to use "a topogically sensitive name which > occurs in all packets", but that still doesn't answer the question of "is this > the name of the end-end entity as well". That's why I don't like the term > "address", but it continues to be used. > There is no topological requirement in an "address". For example, IEEE addresses have no topological significance. Postal addresses have no topological relation to the SCF in which mail is distributed. > - A single field, used both to indentify end-end entities, and topologically > sensitive. (We call this an address, right?) > - Separate fields for thse two functions, and the latter is always present. > (We often call the former an EID, but we also call the latter an address, I > guess?) > - Separate fields, and the latter is sometime not present when a packet belongs > to a flow. (The latter is called a locator in this case.) > I favor the third case, with fixed size end-end Identifier, and a variable length Locator (each element of which is also fixed size). This is the current SIPP design, where the SIP Routing Header was merged with the PIP FTIF, creating SIPP. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 02:44:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12973; Sat, 18 Jun 1994 02:44: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 CAA04257; Sat, 18 Jun 1994 02:44:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA04254; Sat, 18 Jun 1994 02:43:57 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12969; Sat, 18 Jun 1994 02:43:50 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA21214; Fri, 17 Jun 94 09:43:26 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA09972; Fri, 17 Jun 94 09:44:46 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA20184; Fri, 17 Jun 1994 09:43:20 -0700 Date: Fri, 17 Jun 1994 09:43:20 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406171643.AA20184@jurassic.Eng.Sun.COM> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM In-Reply-To: <9406170132.AA12908@ginger.lcs.mit.edu> Subject: Re: variable length addresses Noel, >Just to clarify, is this going to be treated as a monolithic entity, or >more along the lines of what Bill Simpson suggested (with 8+8, and only the >lower 8 bytes being used in the transport pseudo-header)? I will respond to this on the SIPP list in another message. >This debate seems to make remarkably little progress in terms of coming to any >conclusion. That is something I can agree with :-) Bob From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 04:04:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15739; Sat, 18 Jun 1994 04:04: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 EAA04336; Sat, 18 Jun 1994 04:04:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA04333; Sat, 18 Jun 1994 03:59:08 +1000 Precedence: list Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15491; Sat, 18 Jun 1994 03:59:03 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA09160; Fri, 17 Jun 94 13:57:35 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA22776; Fri, 17 Jun 94 13:54:45 EDT Date: Fri, 17 Jun 94 13:54:45 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9406171754.AA22776@pobox.wellfleet> To: Bob.Hinden@Eng.Sun.COM, ericf@atc.boeing.com Subject: Re: variable length addresses Cc: big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM > This debate seems to make remarkably little progress in terms of > coming to any conclusion. That is something I can agree with :-) Why don't I take a shot at my current mode of thinking: My understanding of what Steve proposed last week was that the SIPP address would be sixteen bytes fixed length, with the option of using the low order 8 bytes (or 6 bytes?) as "something that the host already knows" so that we can use "serverless" (IPX-style) address autoconfiguration, with a provision for efficient source routing (which really is source routing, and not extended addressing). My contention is that we are not actually discussing whether this will work, but rather that folks from the variable length and/or 8 byte camp are discussing features that are sub-optimal about this approach, but that ought to be possible to make work. Looking at Eric's list I see: - Five levels of internal hierarchy If 8 bytes are used to identify the host within the area or subnet (aiding autoconfiguration), and if it takes something like 2 bytes to identify the provider(s) from which Boeing takes it's address assignments, plus another two bytes to identify Boeing, then this leaves at most 4 bytes, plus the 8 byte host-known part, for Boeing's use. Thus we seem to have barely enough here (presumeably the fifth and lowest level is indeed host on the subnet or host within an area, which uses the low order 8 bytes). If I am off by a byte, or Eric is off by a level, then at some point Boeing would need to use bit boundaries rather than byte boundaries for address assignment. This is clearly a bit harder for humans to handle, and probably makes hexadecimal better than dotted decimal notation for human-writing of the address. However, I think that we are talking about something that is possible. Most likely, this also means that providers will have to give a shorter prefix to Boeing (leaving a larger amount of the space for Boeing's use), relative to the size of prefix that they give to a much smaller company. This makes address administration more complex for the provider, but not horrendously so (telephone co's already give individual phone numbers to houses, and larger prefixes to companies). I tend to agree with Eric that this makes fixed 8 byte addresses untenable. - More than 1,000,000 IPng devices. I think that this is very realistic requirement. However, if Boeing gets the low order 12 bytes to play with, then I would think that this would be possible. I think that this absolutely requires address autoconfiguration of one kind of another. - "serverless" autoaddressing. I actually think that we should use the low order 8 bytes for this (not just 6), as I wouldn't want to count on IEEE IDs lasting forever. Yes, this again requires 16 byte addresses, not 8. - serverless addresses must be real global addresses. Again, this pushes us to 16 bytes (not 8). It would also work with variable addresses of course. - addressing must be simple (so normal folks can avoid screwing it up). Hmmm. This would seem to imply using a single addressing format within Boeing, which pushes somewhat against the desire to make efficient use of addresses. Thus, does a small site, tied into the corporate backbone via wide area links, get the same address space as a large site (also tied into the corporate backbone via wide area links)? I am not sure. I suspect that folks can understand two or three formats (big site format, small site format). The next couple of points are also tied into making things simpler for humans. I agree with Eric's point that humans are more expensive than bits on the wire (computer companies keep making bits cheaper, congress keeps making people more expensive -- we can expect this trend to continue, at least for bits). Fifteen years ago we somehow managed to afford to send 4 byte addresses with every packet. I find it hard to believe that the networks aren't more than four times faster now. Generally, it seems to me from Eric's message that fixed 8 byte addresses are just not a sensible tradeoff for networks of a size which is currently anticipated (such as a Boeing network attached to a global Internet). Some of us are also seeing possibilities of networks in the future which are considerably larger than what Eric is talking about. However, I think that 16 bytes may be fit to Eric's need. It would be a good exercise to work out precisely in painful detail how this will work and make sure before we come to any final conclusion. Ross PS: Has there been any serious thought to fixed length 24 byte addresses? This may seem like frivolous waste of bandwidth, but Eric does have a very good point that we really need to optimize for the humans (network administrators, for example). From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 06:04:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19900; Sat, 18 Jun 1994 06:04: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 GAA04470; Sat, 18 Jun 1994 06:04:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA04456; Sat, 18 Jun 1994 05:53:01 +1000 Precedence: list From: daniel@ISI.EDU Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17511; Sat, 18 Jun 1994 04:54:18 +1000 (from daniel@ISI.EDU) Received: from dza.isi.edu by venera.isi.edu (5.65c/5.61+local-14) id ; Fri, 17 Jun 1994 11:54:14 -0700 Date: Fri, 17 Jun 94 11:54:09 PDT Posted-Date: Fri, 17 Jun 94 11:54:09 PDT Message-Id: <9406171854.AA01452@dza.isi.edu> Received: by dza.isi.edu (4.1/4.0.3-4) id ; Fri, 17 Jun 94 11:54:09 PDT To: big-internet@munnari.OZ.AU Subject: Variable length locators Reply-To: daniel@ISI.EDU Having gone through the trouble of reading all the arguments about variable length locators, I figured I might as well make a list of pros and cons for the various methods discussed. Perhaps if we have a good list of the issues involved, it will be easier to reach a decision/compromise. Here are my notes. Feel free to suggest additions. And note that not once did I use the word "address." :-) Daniel Zappala ---------------------------------------------------------------------- * Fixed length locators Description: Locators are size X and no other size is possible. Pros: 1. Allows routers/hosts to optimize for the fixed length. 2. Size X will be good enough for all time or for Y years, so optimizing now is the best thing we can do. Cons: 1. We will eventually run out of locator space because we are inherently wasteful or because we can't predict the future well enough. It is better to allow for future expansion now, so that we don't have to go through this effort again. 2. Fixed size locators waste space because not all sites need the same size of locator. ---------------------------------------------------------------------- * Variable length locators, with a default size Description: Use only one particular size of locator at a time, but allow that size to change over time. That is, locators are only variable in the long term and the default size changes infrequently. Pros: 1. Allows future locator expansion without having to create a new protocol and/or packet format. Because only the default size is legal, then we can start with fixed size X and expand in Y years when/if we discover we need more space. 2. Routers/hosts can optimize for the default size, gaining the advantage of fixed length locators. 3. Locator size can be managed, preventing the problem where variable size fields quickly grow to their maximum size and thus waste space. Cons: 1. When the default size changes, routers/hosts may need to change their optimizations to fit the new size. 2. If maximum fixed size X is large enough for all time or for Y years, after which a new protocol will be needed anyway, then we've wasted our time creating a structure for future growth. 3. We will waste some space because not all sites need the same size locator. ---------------------------------------------------------------------- * "Truly" variable locators, where a number of sizes may be legal at one time. Description: The size of the locator is defined by a size field and that field has a number of legal values, all of which may be used at any time. Pros: 1. Different sites can choose a size appropriate for their site, eliminating the waste caused by having to choose one size for everyone. 2. If we really try, we can make routers/hosts run quickly with variable length locators. Cons: 1. Routers will be slower when dealing with the variable size compared to having a fixed size. 2. Variable length fields tend to quickly grow to their maximum size, so we will just end up wasting space. 3. Maximum size X is large enough for all time or for Y years, so we should just optimize for size X. From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 06:24:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20510; Sat, 18 Jun 1994 06:24: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 GAA04502; Sat, 18 Jun 1994 06:24:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA04497; Sat, 18 Jun 1994 06:14:30 +1000 Precedence: list Received: from OSI.NCSL.NIST.GOV by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20147; Sat, 18 Jun 1994 06:14:26 +1000 (from colella@osi.ncsl.nist.gov) Received: from emu.ncsl.nist.gov.noname by osi.ncsl.nist.gov (4.1/SMI-4.0-MHS-7.0) id AA24656; Fri, 17 Jun 94 16:14:22 EDT Date: Fri, 17 Jun 94 16:14:22 EDT Message-Id: <9406172014.AA24656@osi.ncsl.nist.gov> To: rcallon@pobox.wellfleet.com Subject: Re: variable length addresses Cc: big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM, colella@nist.gov From: colella@nist.gov Reply-To: colella@nist.gov Ross, > If 8 bytes are used to identify the host within the area > or subnet (aiding autoconfiguration), and if it takes > something like 2 bytes to identify the provider(s) from > which Boeing takes it's address assignments, plus another > two bytes to identify Boeing, then this leaves at most 4 > bytes, plus the 8 byte host-known part, for Boeing's use. Do you forsee carving up the two-byte provider space for continental or regional level aggregation? In the I-D "Administrative Allocation of the 64-bit Number Space" the provider space is two bytes, but there's also a Format/Continent/Region field above it that is also two bytes, allowing aggregation above the provider space. --Richard From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 07:44:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22746; Sat, 18 Jun 1994 07: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 HAA04592; Sat, 18 Jun 1994 07:44:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA04578; Sat, 18 Jun 1994 07:36:35 +1000 Precedence: list Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22510; Sat, 18 Jun 1994 07:36:31 +1000 (from rcallon@pobox.wellfleet.com) Received: from pobox.wellfleet (pobox.wellfleet.com) by lobster.wellfleet.com (4.1/SMI-4.1) id AA12354; Fri, 17 Jun 94 17:35:12 EDT Received: from cabernet.wellfleet by pobox.wellfleet (4.1/SMI-4.1) id AA27841; Fri, 17 Jun 94 17:32:22 EDT Date: Fri, 17 Jun 94 17:32:22 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-Id: <9406172132.AA27841@pobox.wellfleet> To: colella@nist.gov Subject: Re: variable length addresses Cc: big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM > If 8 bytes are used to identify the host within the area > or subnet (aiding autoconfiguration), and if it takes > something like 2 bytes to identify the provider(s) from > which Boeing takes it's address assignments, plus another > two bytes to identify Boeing, then this leaves at most 4 > bytes, plus the 8 byte host-known part, for Boeing's use. Do you forsee carving up the two-byte provider space for continental or regional level aggregation? In the I-D "Administrative Allocation of the 64-bit Number Space" the provider space is two bytes, but there's also a Format/Continent/Region field above it that is also two bytes, allowing aggregation above the provider space. Richard; Good point. This would seem to question whether 2 bytes is enough to identify the provider. I was expecting that the 2 byte provider space would be "CIDR-ized", with some continents getting small blocks (antartica?), and some getting larger blocks (North america and Europe). Also, if there are eventually more than 65,000 small providers, then we probably would also need different length prefixes to different providers. Now, if some very small provider only got a three byte prefix (rather than the more efficient and prestigious two byte prefix), then they might have to give up a lot of their space for a single customer if they wanted to give service to a very big company which needed a short prefix. However, there is some danger that some continent might get a small block, but later end up with booming economies and large numbers of providers (and heavily networked companies and homes). This could conceivably force either renumbering of providers, or keep us from aggregating reachability to blocks of providers. If all of this forces us to use three or four bytes to indicate the provider, then my "if I am off by a byte" contingency seems to be exercised. Now, obviously 2 bytes to identify Boeing in the provider space is also obviously not going to be enough bytes to identify every conceivable customer of a provider. Thus my example assumes that the provider will offer a shorter prefix to large companies, and a smaller prefix to smaller companies. Again, if a company size changes (something we are seeing a lot of in this industry, in both directions here in MA), then this might lead to the need to renumber. This all makes me believe that there is a tradeoff between longer addresses, and the difficulty in administering the address space in at least three dimensions: variable length prefixes for different sized providers and companies and sites, the frequency of address changes (although other causes may effect this more), and the need to put boundaries on non-byte boundaries. Again, this all seems to imply that we are not actually discussing whether 16 byte addresses will work, but rather are discussing how much pain will be inflicted on humans trying to administer it, and what methods can be used to make this less difficult. Ross PS: Can we pick one mailing list? Should I be responding to SIPP or to Big-Internet (I really don't care which, I am on both lists). From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 10:04:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27059; Sat, 18 Jun 1994 10:04: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 KAA04723; Sat, 18 Jun 1994 10:04:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA04717; Sat, 18 Jun 1994 09:56:18 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26774; Sat, 18 Jun 1994 09:56:09 +1000 (from kre@munnari.OZ.AU) To: rcallon@pobox.wellfleet.com (Ross Callon) Cc: Bob.Hinden@Eng.Sun.COM, ericf@atc.boeing.com, big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM Subject: Re: variable length addresses In-Reply-To: Your message of "Fri, 17 Jun 1994 13:54:45 EDT." <9406171754.AA22776@pobox.wellfleet> Date: Sat, 18 Jun 1994 09:56:05 +1000 Message-Id: <23397.771897365@munnari.OZ.AU> From: Robert Elz Date: Fri, 17 Jun 94 13:54:45 EDT From: rcallon@pobox.wellfleet.com (Ross Callon) Message-ID: <9406171754.AA22776@pobox.wellfleet> Most likely, this also means that providers will have to give a shorter prefix to Boeing (leaving a larger amount of the space for Boeing's use), relative to the size of prefix that they give to a much smaller company. I had never imagined that anyone could think otherwise, has anyone been assuming that Boeing and Joe's fish shop would fit into the allocation hierarchy at the same level? That would make no sense at all. This makes address administration more complex for the provider, Not really - Boeing is to all intents and purposes a provider, except that they sell services only within their own company. We simply treat them, and other similar companies, as providers. Not only does this make address allocations more rational, it also probably helps routing long term (as they connect to the net in many places, rather than just one). I tend to agree with Eric that this makes fixed 8 byte addresses untenable. I'm not sure of that, I suspect that 8 byte addresses might still work, but I'm not certain they will - it seems prudent to opt for 16 bytes. - More than 1,000,000 IPng devices. I think that this is very realistic requirement. However, if Boeing gets the low order 12 bytes to play with, then I would think that this would be possible. 12 bytes! Surely not, there are more than 1,000,000 devices on the internet as it is now, with a total of 4 bytes of address space, and much of it wasted. It can't possibly take 12 bytes to manage many orders of magnitude more than a million hosts. 5 bytes perhaps... - addressing must be simple (so normal folks can avoid screwing it up). Hmmm. This would seem to imply using a single addressing format within Boeing, No, it implies keeping "normal folks" away from number allocations, and doing that with software written by experts. I am not sure. I suspect that folks can understand two or three formats (big site format, small site format). Why do folks need to understand any formats at all? Folks means net managers, etc - obviously end user folks don't. PS: Has there been any serious thought to fixed length 24 byte addresses? This may seem like frivolous waste of bandwidth, but Eric does have a very good point that we really need to optimize for the humans (network administrators, for example). There is more than one way to tackle that problem, allocating address bits to it only works if we assume address bits are free. They aren't. kre From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 10:06:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27092; Sat, 18 Jun 1994 10:06: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 KAA04738; Sat, 18 Jun 1994 10:06:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA04720; Sat, 18 Jun 1994 10:00:30 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26935; Sat, 18 Jun 1994 10:00:19 +1000 (from vjs@rhyolite.wpd.sgi.com) Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for Big-Internet@munnari.OZ.AU id AA21120; Fri, 17 Jun 94 17:00:07 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA29679; Fri, 17 Jun 94 17:59:33 -0600 Date: Fri, 17 Jun 94 17:59:33 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406172359.AA29679@rhyolite.wpd.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: re: not in the same reality..... > From: ericf@atc.boeing.com (Eric Fleischman) > ... > As I see it, the IPng proposals suffer from the 80/20 rule. While 80% > of the community may benefit, the 20% is upset that their community is > potentially left out of much of the benefit. What we want, of course, > is for everyone to equally benefit. We want a solution which is uniformedly > good for the entire community. Some of us are perfectly willing to say that one size cannot not fit all, that no single design, with or without variable anything will cover everything, and that trying to cover everything will make everyone unhappy and no one happy. Some think "uniformedly good for the entire community" inevitably means "uniformly unsatisfactory." For examples of why one might think that way, please look at the OSI protocols, the OSF kernel and DCE, and System V release 4. Note the OSI protocols, where not only addresses are variable, but so are the protocols (TP0-TP4, CLNS-CONS). They are supposed to be variable for exactly the same reasons advanced to make the IPng address variable. Of course, the real reason for the OSI variability is the familiar lack of courage in any committee to say "this is the 80% we're going to support and that 20% will not work." By the way, I'm surprised at your statements that Boeing is interested in having 1,000,000 IP hosts. Last I knew, long ago as well as not so long ago, based on public statements as well as private conversations, I thought Boeing was still very much in the "OSI will eventually triumph" camp. What happened? Is this indicative of a change in official corporate strategy? Judging from your suggestions aimed at covering all bases, an underlying affection for the cover-all-bases style of the OSI protocols remains. (Please do not be too insulted by that observation. It's only a statement of apparent fact. Only among the worst of politicians can someone's past positions or the positions of one's predecessors be insults.) > ... > I would like to ask this working group the following question to see if > the following addressing approach is technically viable and "fair" to all: > Can we define an addressing structure which permits variable > length addresses but requires that only one or two options (say > fixed length 8 and 16 byte addresses) be deployed for the foreseeable > future? Furthermore, can we ensure that the granularity requirements > of the theoretical address space be defined so that the total > theoretical size possibilities are constrained to single digits (e.g., > length options of 8, 12, 16, 20, or 24 bytes only)? > I recognize that I did not think up this idea. However, I am very interested > in knowing technical reasons why this could not be the solution to our > dilemma. Failing this, how about a schema with a fixed size EID and a > variable sized locator such as SIPP with extended addressing was (debatably) > tending towards previously (i.e., after the union with PIP)? 0. most of my salary currently comes from people buying machines for those small, isolated networks. 1. there is plenty of bandwidth on those small networks for a bloated address. It is irritating to ship those 0's around, but even on Ethernets, there is plenty of bandwidth. The effects of an extra 100 bytes of header on the available bandwidth of FDDI or HIPPI LANs are insignificant. 2. the networks that will be hurt by doubling the size of a TCP ACK will be those were bandwidth is precious instead of free, big networks, the Internet as well as the interconnects of your network. 3. my code is simpler if the address is fixed size. It will be only a little faster, but it will be significantly simpler. That simplicity will only ("only") reduce the number of dumb mistakes I make, special cases I forget (e.g. getting all of the address in one mbuf when the address is not the common size), and so on. 4. if you force me to support variable addresses with a maximum size of X, I'll have to design and code to support a size of X, and hope eventually to optimize a case for X-x. 5. If you force me to support X some of the time, then I'd rather just do it all of the time, unless X is ridiculous large, and in that case, I'd rather join some other party. By the way, have you read the "bigten" draft? And noticed the limit is 56 bytes of address? Don't some UNIX systems still limit the hostname, including full DNS expansion to 64 bytes? Wouldn't it be more forthright to say the variable address positions "use a form of DNS for the address"? Wouldn't it be better to support a larger, variable sized locater that looks like a FQDN and is rarely used, and a much smaller, fixed sized EID? Or just accept TUBA and SAPs? Why turn SIPP into TUBA? "Uniformedly good for the entire community" I guess you can't know how that rattles people like me who enjoyed an indoctrination in uniformed goodness thanks to the Selective Service Act. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 11:27:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28184; Sat, 18 Jun 1994 10:45: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 KAA04820; Sat, 18 Jun 1994 10:44:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA04781; Sat, 18 Jun 1994 10:26:28 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27594; Sat, 18 Jun 1994 10:26:21 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA28001; Fri, 17 Jun 94 17:26:14 PDT Received: from jurassic.Eng.Sun.COM (camilla) by Eng.Sun.COM (4.1/SMI-4.1) id AA18500; Fri, 17 Jun 94 17:27:38 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA09280; Fri, 17 Jun 1994 17:26:09 -0700 Date: Fri, 17 Jun 1994 17:26:09 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406180026.AA09280@jurassic.Eng.Sun.COM> To: rcallon@pobox.wellfleet.com (Ross Callon) Cc: colella@nist.gov, big-internet@munnari.OZ.AU, sipp@sunroof.Eng.Sun.COM In-Reply-To: <9406172132.AA27841@pobox.wellfleet> Subject: Re: variable length addresses Ross, > PS: Can we pick one mailing list? Should I be responding to > SIPP or to Big-Internet (I really don't care which, I am on > both lists). Suggest that if we are talking about SIPP (for example your message about 16byte address allocation) it should go on the SIPP list. Bob From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 11:29:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28199; Sat, 18 Jun 1994 10:45: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 KAA04835; Sat, 18 Jun 1994 10:45:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA04786; Sat, 18 Jun 1994 10:34:33 +1000 Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27924; Sat, 18 Jun 1994 10:34:29 +1000 (from news@sgi.com) Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA24980; Fri, 17 Jun 94 17:29:44 -0700 To: Big-Internet@munnari.OZ.AU Reply-To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: re: not in the same reality..... Message-Id: Precedence: list Date: Sat, 18 Jun 1994 00:13:53 GMT > From: ericf@atc.boeing.com (Eric Fleischman) > ... > As I see it, the IPng proposals suffer from the 80/20 rule. While 80% > of the community may benefit, the 20% is upset that their community is > potentially left out of much of the benefit. What we want, of course, > is for everyone to equally benefit. We want a solution which is uniformedly > good for the entire community. Some of us are perfectly willing to say that one size cannot not fit all, that no single design, with or without variable anything will cover everything, and that trying to cover everything will make everyone unhappy and no one happy. Some think "uniformedly good for the entire community" inevitably means "uniformly unsatisfactory." For examples of why one might think that way, please look at the OSI protocols, the OSF kernel and DCE, and System V release 4. Note the OSI protocols, where not only addresses are variable, but so are the protocols (TP0-TP4, CLNS-CONS). They are supposed to be variable for exactly the same reasons advanced to make the IPng address variable. Of course, the real reason for the OSI variability is the familiar lack of courage in any committee to say "this is the 80% we're going to support and that 20% will not work." By the way, I'm surprised at your statements that Boeing is interested in having 1,000,000 IP hosts. Last I knew, long ago as well as not so long ago, based on public statements as well as private conversations, I thought Boeing was still very much in the "OSI will eventually triumph" camp. What happened? Is this indicative of a change in official corporate strategy? Judging from your suggestions aimed at covering all bases, an underlying affection for the cover-all-bases style of the OSI protocols remains. (Please do not be too insulted by that observation. It's only a statement of apparent fact. Only among the worst of politicians can someone's past positions or the positions of one's predecessors be insults.) > ... > I would like to ask this working group the following question to see if > the following addressing approach is technically viable and "fair" to all: > Can we define an addressing structure which permits variable > length addresses but requires that only one or two options (say > fixed length 8 and 16 byte addresses) be deployed for the foreseeable > future? Furthermore, can we ensure that the granularity requirements > of the theoretical address space be defined so that the total > theoretical size possibilities are constrained to single digits (e.g., > length options of 8, 12, 16, 20, or 24 bytes only)? > I recognize that I did not think up this idea. However, I am very interested > in knowing technical reasons why this could not be the solution to our > dilemma. Failing this, how about a schema with a fixed size EID and a > variable sized locator such as SIPP with extended addressing was (debatably) > tending towards previously (i.e., after the union with PIP)? 0. most of my salary currently comes from people buying machines for those small, isolated networks. 1. there is plenty of bandwidth on those small networks for a bloated address. It is irritating to ship those 0's around, but even on Ethernets, there is plenty of bandwidth. The effects of an extra 100 bytes of header on the available bandwidth of FDDI or HIPPI LANs are insignificant. 2. the networks that will be hurt by doubling the size of a TCP ACK will be those were bandwidth is precious instead of free, big networks, the Internet as well as the interconnects of your network. 3. my code is simpler if the address is fixed size. It will be only a little faster, but it will be significantly simpler. That simplicity will only ("only") reduce the number of dumb mistakes I make, special cases I forget (e.g. getting all of the address in one mbuf when the address is not the common size), and so on. 4. if you force me to support variable addresses with a maximum size of X, I'll have to design and code to support a size of X, and hope eventually to optimize a case for X-x. 5. If you force me to support X some of the time, then I'd rather just do it all of the time, unless X is ridiculous large, and in that case, I'd rather join some other party. By the way, have you read the "bigten" draft? And noticed the limit is 56 bytes of address? Don't some UNIX systems still limit the hostname, including full DNS expansion to 64 bytes? Wouldn't it be more forthright to say the variable address positions "use a form of DNS for the address"? Wouldn't it be better to support a larger, variable sized locater that looks like a FQDN and is rarely used, and a much smaller, fixed sized EID? Or just accept TUBA and SAPs? Why turn SIPP into TUBA? "Uniformedly good for the entire community" I guess you can't know how that rattles people like me who enjoyed an indoctrination in uniformed goodness thanks to the Selective Service Act. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 11:31:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28211; Sat, 18 Jun 1994 10: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 KAA04850; Sat, 18 Jun 1994 10:46:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA04789; Sat, 18 Jun 1994 10:36:35 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25870; Sat, 18 Jun 1994 09:27:19 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Why variable length? In-Reply-To: Your message of "Fri, 17 Jun 1994 00:59:39 MST." <199406170759.AAA13192@lager.cisco.com> Date: Sat, 18 Jun 1994 09:27:13 +1000 Message-Id: <23385.771895633@munnari.OZ.AU> From: Robert Elz Date: Fri, 17 Jun 1994 00:59:39 -0700 From: Tony Li Message-ID: <199406170759.AAA13192@lager.cisco.com> Currently, for IPv4 we've allocated about 1.6e9 host addresses. We have, approximately, 2e6 hosts actually connected. That means that we have an efficiency of 1.25e-3. Really, are you really claiming to associated "connected" with "allocated" and achieve that result? Do you not ignore by this all the systems that could be connected, but aren't for reasons that have nothing whatever to do with address space effeciency (which could be any of security, costs, policy, ...) ? While there's no doubt that allocations haven't been used very effeciently, its not nearly that bad (typical numbers around 1% effeciency are more often claimed - that's an average of just 2.5 hosts per class C, or 655 per class B). Why are these numbers so bad? Some of the reasons you quote are quite valid, but there are also others. One current reason is the incredible waste from the assigned class A addresses - that is, allocating far too much address space to sites that have no real reason to need nearly that much (I do not say that applies to every allocated class A, but it certainly applies to most - there are some allocated that probably have no addresses actually in use on them at all any more - this consumes huge amounts of the currently wasted space). Defeciencies in the protocols we have had to work with is another reason. IGP's have not permitted variable sized subnets until quite recently, meaning that sites have had to consume the product of the number of subnets they need and the number of hosts on the biggest of those subnets. Axiom 1: Hierarchical addressing on bit boundaries has a considerable amount of unavoidable waste. This is undoubtably true, I disagree on the amount of the waste however. Corollary 1: Hierarchical addressing on byte or nibble boundaries is even more wasteful. Absolutely true. Conclusion, don't do that. The nice boundary breakdowns have largely been argued based on human factors issues - which are certainly very important. However, this is not the only possible way to make things nicer for humans, and in fact, almost certainly not even the best, or close to it, method. It implies that humans will be looking at addresses as bit sequences, which is really pretty silly. What is needed is better interface software that allows humans (network managers, etc, I refer to here, "regular users" should never see numbers at this level at all) to interact with the network in more rational methods. There's no particular reason that most network managers should ever need to even know which particular binary values have been assigned, any more than software engineers these days need ever look at the binary format of the programs they execute. In fact, software engineers don't even look at the assembly level of programs they write these days (people around here typically have never seen adb used, and have no idea what to do with it if they're shown, as the very concept of machine code, and assembler, is generally completely hidden from them). So far in the network field we have been very lax in moving in the same direction - we still expect people to look at the bits, and manipulate those things, there must be a better way. Good compilers can produce better machine code than humans can for any reasonably large system (not necessarily for trivia) because they can make use of tricks/details that humans wouldn't be able to keep track of (ie: if a human wrote it that way it would be an unmaintainable mess). In exactly the same way, if humans assign network numbers they're naturally going to do it in a somewhat wasteful way in order to keep the thing under control - an automated assignment system need not worry about details like that, it can produce effecient strategies at the low level while still presenting an intelligible interface to the user - humans more typically want to name their networks, not number the things. Nonetheless, we can use our existing numbers as a worst case measurement for IPng addressing efficiency. We can, but to be fair, its much worse than we should be able to do in the future. Still, lets continue. Axiom 2: The cummulative efficiency of an addressing plan is the product of the efficiencies at each level. Yes. However we should not assume that the number of levels is fixed within the overall addressing plan, nor that the effeciency of allocation at each level is the same. Typically at higher levels effeciency can be better than at lower levels as less padding is needed to allow for uncertain growth (eg: the number of buildings in your organisation doesn't often change by many orders of magnitude, but the number of hosts inside a building easily might). Approximation 1: Thus, with the IPv4 two level addressing hierarchy, we can get a first approximation of the efficiency at each level as sqrt(1.25e-3) ~= .03. But IPv4 is really 3 levels. Even assuming 1.25e-3, which I believe is much lower than the real current effeciency level, the correct number should be cube root (1.25e-3), or 0.11 shouldn't it? (That is, unless you're measuring net numbers, rather than host numbers, in which case your final answer is within the design parameters). Now, let's take a look at 16 byte addresses. If we take an addressing plan such as has been proposed for BigTen, we see that we have some administrative wasteage up front, and 6 bytes for an IEEE 802 address. Dividing up the remaining space, we see that it's convenient to have approximately 7 or 8 levels of hierarchy. First, I don't think we need a byte of admistrative wastage, or not one that's distinct from a level of hierarchy anyway. Second, I don't believe that we should be sticking with 6 bytes of utter wastage at the end of addresses, but lets keep going with those assumptions... Approximation 2: A 7 level hiearchical system has a worst-case efficiency of .03^7 = 2e-11. Or perhaps 0.11^7 = 2e-8. Approximation 3: There are roughly 2^(9 * 8) = 2^72 = 4e21 addresses useable. Here you've totally ignored all the addresses you can make use of out of the 6 bytes of wasted IEEE space - that stuff is almost all gratuituous noise (flatuence?) - but not completely. I'd estimate at least 1 byte, and possibly 2 (maybe 1.5) of actual useable space in those 6 bytes, which would give at least 2^80 addresses useable (1e24). Given approximation 2 and 3, we see that Approximation 4: 16 byte addresses with a 7 level hierarchical addressing system can support an Internet of 4e21 * 2e-11 = 8e10 hosts, in the worst case. Absolute worst case I'd say is 1e24 * 2e-8, or 2e16 - which is nicely above the agreed design parameters for IPng, and still assumes absurdly wasteful allocation policies. Now do you see why I, and others, are not in the least worried about 16 byte address spaces. If we can improve, just a little, on allocation effeciencies, say by not using those 6 bytes of nonsense, or by being just a little more effecient in assigning space at some of the levels, these numbers quickly rise dramatically. As an example, if we could manage just 15% effeciency per level, rather than 11% (I suspect we already do better than 15% if we really counted - with three levels of hierarchy that's still only 1/3 of one percent overall effeciency), and if we could manage just 90 bits of allocatable space out of the 128 available (losing the rest to non-meaningful noise - nb: not additional levels of hierarchy, administrative or not), and still assuming 7 levels of hierarchy, then the number turns out at more than 2e21 addresses to allocate to hosts. That should be achievable, and is lots more than we have agreed we need (LOTS LOTS more). If our overall effeciency is currently more like the more common 1% estimate (22% per level), which I believe it probably is if you exclude all the totally wasted class A numbers, then even with only 72 allocatable bits, and 7 levels we get 3e19 host numbers. Keeping 22% effeciency per level, and managing to use 100 bits would give 3e25 hosts... I have a proposal that I think is not unreasonable, and could help avoid unnecessary address wastage. Lets impose a charge for addresses. I know this is not new. The charge can go to help support the NICs that will be burdened with assigning all these addresses. I suspect that many people see this coming in any case. Now to keep things in perspective, lets make the charge pretty negligible - we don't want anyone to be unduly burdened with this. Lets say 0.00001 SFr per allocated address per annum. (That is 1e-5 of a Swiss Franc). I use SFr because its a nice stable currency of a financially oriented nation, and because it happens (at the minute) to be roughly comparable with Australian dollars, so its easy for me to think in those numbers... For those in the US, SFr are probably around USD 0.75 - that is, a Swiss Franc is less than a US dollar, and I'm suggesting less than 1/1000 of a US cent for each allocated address. Now, using current allocation sizes, a class C net number would cost approx 1/4 US cent per annum... that's not going to hurt anyone I don't think, a class B number will cost maybe US0.50 per annum, also pretty trivial. That is, these numbers aren't going to impose any kind of financial burden on anyone, even allowing that average houses are probably going to want at least class B sized spaces in the future. Even if you need a class A sized space, that's going to be about 170 SFr a year, which your average small company, or school, should have no particular problem with (less than USD 150). On the other hand, if you're a big company, and need 32 bits of address space, you will pay almost 43000 SFr per annum, which for companies that large is still a pretty small number overall. I doubt Boeing (to take a popular example) would have many problems with this (approx USD 30,000 - or for their million hosts, an overhead of about three cents per host). Where we really win from this scheme however is with those sites that really believe they need 48 bit spaces. Each of those we allocate will bring in almost 3 billion (US billions, ie: 3 thousand million) SFr per annum, selling one of those would allow any NIC I can think of to survive quite nicely, even with doing all the paperwork necessary to collect all those $150 and $0.50 fees for the smaller allocations, though people wanting a class B (or smaller) space would probably buy a 100 year lease for $50 (or less)). I will leave it for you readers to calculate the cost of a 64 bit space, its a number bigger than I know the words to describe (I think its bigger than the US national debt). But it would be available for anyone who could justify it. Similarly, the 88 bit space (11 bytes) that Brian Carpenter claimed he might need would be available to CERN to buy if they wanted it. I don't know where they'd find that many SFr though... In a message on the SIPP list, Eric Fleischman pointed out that (I quote) "Everything is a cost/benefit tradeoff", and he's quite right, it is. The problem with addressing allocations (which was the topic in point), has been that there has been no quantifiable cost of allocating addresses to set off against the cost of administering the space assigned. Obviously the result of an analysis leans heavily toward using address space so as to minimise administrative costs. Imposing a real cost (even one so trivial as 1/100000 SFr per allocated address) will provide something to balance the administrative costs of strategies with various allocation effeciencies against. Then the analysis starts to produce different answers. kre From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 11:44:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29859; Sat, 18 Jun 1994 11:44: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 LAA04921; Sat, 18 Jun 1994 11:44:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA04907; Sat, 18 Jun 1994 11:28:38 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28667; Sat, 18 Jun 1994 11:03:38 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id SAA29192; Fri, 17 Jun 1994 18:03:10 -0700 Date: Fri, 17 Jun 1994 18:03:10 -0700 From: Tony Li Message-Id: <199406180103.SAA29192@lager.cisco.com> To: kre@munnari.OZ.AU (Robert Elz) Cc: big-internet@munnari.OZ.AU Subject: Re: Why variable length? Absolute worst case I'd say is 1e24 * 2e-8, or 2e16 - which is nicely above the agreed design parameters for IPng, and still assumes absurdly wasteful allocation policies. Now do you see why I, and others, are not in the least worried about 16 byte address spaces. Nope. But then again, I guess I disagree with the entire philosophy of designing to just meet the design parameters and no farther. The design parameters are just a guess. I consider them to be a minimal lower bound. Tony p.s. Number haggling omitted. Please don't construe this as agreement with your numbers. I think you're way high. From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 15:25:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07571; Sat, 18 Jun 1994 15:25: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 PAA05108; Sat, 18 Jun 1994 15:24:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA05105; Sat, 18 Jun 1994 15:18:37 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04638; Sat, 18 Jun 1994 14:05:47 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id AAA01224; Sat, 18 Jun 1994 00:05:43 -0400 Date: Sat, 18 Jun 1994 00:05:43 -0400 From: Vadim Antonov Message-Id: <199406180405.AAA01224@titan.sprintlink.net> To: kre@munnari.OZ.AU, tli@cisco.com Subject: Re: Why variable length? Cc: big-internet@munnari.OZ.AU The "variable vs fixed length addresses" thread is a bit silly. The real question is "do we really need static name-address and interface-address bindings?". If IPng will include the *mandatory* address auto-configuration which does not impose bit boundaries between host and network addresses but rather generates addresses as sums of "host number" in the LAN and the LAN addresses then a simple mechanism for increasing network size with addition of new hosts (and, of course, reduction of size when hosts get removed) we can easily achieve 40-60% address space utilization which makes 8 bytes addresses sufficient for all foreseeable future. The additive addressing scheme can be expanded further to work on several levels of address space delegation -- i.e. there can be one central "address server" in the Internet which allocates continuous blocks to national service providers, they, in turn, allocate smaller blocks to small service providers etc down to LANs. It incidentally ensures maximal possible aggregation and minimal size of global routing tables (and for all practical purposes eliminates the routing flops). With architecture like that we only need to have one route to a routing domain; and every routing domain should have one primary address allocation server. Isolated network will no longer need to borrow address space from the global Internet just because they many be connected in some future -- the network will be "renumbered" at the time when it will be physically connected. Note that relative host numbers inside the network won't be changed at the time. With blocks sized as powers of 2 and buddy allocation algorithms we can use the "standard" address+netmask routes and radix tree routing algorithms. DNS should map names not into addresses but rather into sequences of assigned numbers of address servers *relative to higher-level address servers*. The name->address translation in this case includes not only a series of queries to name servers but also a series of queries to address allocation servers. The mapping algorithm is trivial and is left as an excercise to the reader. The only remaining question is how to handle transition states; however allowing transient secondary addresses and careful handling of expiration of name-address caches is no rocket science. The only side note -- addresses should not appear at application level; i.e. "bind" system call should take domain name as an argument. This will allow kernel to handle address changes (based on expiration of name-address cache) invisibly to users. With dynamic addressing IP can really become "plug-and-play" network technology; not the administrative nightmare we have now. Also, my company won't have to purchase routers with 1Gb of RAM to keep zillions of BIIIIG routes. Of course, the dynamic addressing scheme can cause accidential "big renumberings" when large NSPs outgrow their allocated blocks; however, although the total amount of computaions involved in "big renumberings" can be huge, it is very small for every particular participating device. For every connected host the number of address allocation servers which can cause renumbering is limited -- the reasonable assumption is "no more than a dozen". Customer migration between service providers becomes trivial. (Also, the address allocation servers can double as reverse-mapping DNS servers and InterNIC ceases processing the avalanche of network number applications). I hope this proposal is crazy enough to be worthwhile. Regards, --vadim From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 16:44:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09994; Sat, 18 Jun 1994 16:44: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 QAA05218; Sat, 18 Jun 1994 16:44:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA05202; Sat, 18 Jun 1994 16:29:50 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09575; Sat, 18 Jun 1994 16:29:44 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id XAA07183; Fri, 17 Jun 1994 23:29:13 -0700 Date: Fri, 17 Jun 1994 23:29:13 -0700 From: Tony Li Message-Id: <199406180629.XAA07183@lager.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: Robert Elz's message of Sat, 18 Jun 1994 16:09:38 +1000 <23507.771919778@munnari.OZ.AU> Subject: Why variable length? p.s. Number haggling omitted. Please don't construe this as agreement with your numbers. I think you're way high. In that case please explain where and why my estimates are incorrect (as I did with yours). You went to a cube root when calculating current efficiencies, which I think is compltely unjustified. Certainly the allocation waste at the network level has been really quite minimal. Further, the figures for allocation ignore unallocated network numbers, thereby eliminating this as a significant contributor to lossage. You disagree about a byte of wasteage. Even with SIPP there is some significant amount of administrative overhead at the front. You (correctly) point out that there is SOME usage within the subnet. You've added another 8 bits of addressing, but you fail to take into account the additional level of hierarchy and the additional inefficiency. In short, yes, the numbers are highly sensitive based on how you forsee reality. There might be more levels of hierarchy. There might be fewer. I don't want to quibble about the numbers with you because neither of us has a perfect crystal ball. The point that I'm trying to make is that there is, in my mind, some significant chance that we could deliver a protocol which blows up in our (grandchildren's) faces. The risk is non-negligible. The catastrophe is incredibly expensive. The insurance against this is cheap. What can I say? I live in California, about 10 miles from the San Andreas. I pay for earthquake insurance. Compared to that decision, this is a no-brainer. ;-) Tony From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 18:24:26 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09293; Sat, 18 Jun 1994 16:24: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 QAA05175; Sat, 18 Jun 1994 16:24:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA05161; Sat, 18 Jun 1994 16:09:44 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08946; Sat, 18 Jun 1994 16:09:41 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Why variable length? In-Reply-To: Your message of "Fri, 17 Jun 1994 18:03:10 MST." <199406180103.SAA29192@lager.cisco.com> Date: Sat, 18 Jun 1994 16:09:38 +1000 Message-Id: <23507.771919778@munnari.OZ.AU> From: Robert Elz Date: Fri, 17 Jun 1994 18:03:10 -0700 From: Tony Li Message-ID: <199406180103.SAA29192@lager.cisco.com> I guess I disagree with the entire philosophy of designing to just meet the design parameters and no farther. This very much depends on how the design params are set. If I ask for a net to handle my 100 hosts, and I'm delivered a net to handle my 100 hosts, and no more, then I'm likely to be unhappy when I can't expand. On the other hand, if I have 100 hosts, and so ask for a net to handle 1000, because that's way more than what I expect to have, then if I'm delivered what I ask for, that's just fine. It all depends how the parameter was set. I believe the "must handle 1e15 hosts" requirement is set at a "we don't really ever expect it to get this high, but just in case" value, rather than a "this is how many hosts we really think we'll have". The design parameters are just a guess. Yes. I consider them to be a minimal lower bound. Yes, the question is how much higher should we go. Is handling 1e16 hosts enough, 1e20, 1e40, 1e100 ??? My calculations suggested 2e16 as an absolute worst case, and more likely something like 1e21, and perhaps 1e25, with not unreasonable assumptions. I believe any of those is easily big enough - by the time we reach those numbers of actual hosts in existance (even if not connected) everything we think we know now about networking is likely to have been turned upside down (its a long way away). p.s. Number haggling omitted. Please don't construe this as agreement with your numbers. I think you're way high. In that case please explain where and why my estimates are incorrect (as I did with yours). kre From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 20:42:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13510; Sat, 18 Jun 1994 18:44: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 SAA05334; Sat, 18 Jun 1994 18:44:39 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA05320; Sat, 18 Jun 1994 18:28:11 +1000 Precedence: list Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12939; Sat, 18 Jun 1994 18:28:05 +1000 (from vjs@rhyolite.wpd.sgi.com) Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for Big-Internet@munnari.OZ.AU id AA00388; Sat, 18 Jun 94 01:27:59 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:Big-Internet@munnari.OZ.AU id AA01558; Sat, 18 Jun 94 02:27:54 -0600 Date: Sat, 18 Jun 94 02:27:54 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9406180827.AA01558@rhyolite.wpd.sgi.com> To: Big-Internet@munnari.OZ.AU Subject: Re: Why variable length? > From: avg@sprint.net (Vadim Antonov) > [automatic renumbering] > [automagic number assignment] > ... > I hope this proposal is crazy enough to be worthwhile. There must be something in the ether. I wrote and discarded without sending a few hundred words about those same ideas a few hours before receive that message. It seemed too hard to show the ideas are implementable, scalable, and sane. Other thoughts I had were - use something distributed like IEEE spanning tree in the routers with a mechanism to count hosts on the local wire and a hint about the edges of the network to automatically build the hierarchy in networks ranging from houses to Boeing's. - use a distributed instead of centralized registration facility, using the IEEE 48-bit address as the key for the registration but not putting it in any addresses. - use some of the automagic mechanisms that are necessary for route aggregation. It's too bad that the Internet is too mature for such silly ideas, as well as more radical and rational things to be seriously considered. It's too bad that without such things, light switches will not have IP addresses, because your average electrician won't be bothered with setting netmasks, installing static default routes, and partitioning address blocks into hierarchies. Oh, well. Someday light switches will have network addresses, even if not IP address, which is all that matters. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Sat Jun 18 20:44:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17161; Sat, 18 Jun 1994 20:44: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 UAA05449; Sat, 18 Jun 1994 20:44:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA05446; Sat, 18 Jun 1994 20:42:52 +1000 Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14194; Sat, 18 Jun 1994 19:04:30 +1000 (from news@sgi.com) Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA01934; Sat, 18 Jun 94 01:56:10 -0700 To: Big-Internet@munnari.OZ.AU Reply-To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: Why variable length? Message-Id: Precedence: list Date: Sat, 18 Jun 1994 08:54:12 GMT > From: avg@sprint.net (Vadim Antonov) > [automatic renumbering] > [automagic number assignment] > ... > I hope this proposal is crazy enough to be worthwhile. There must be something in the ether. I wrote and discarded without sending a few hundred words about those same ideas a few hours before receive that message. It seemed too hard to show the ideas are implementable, scalable, and sane. Other thoughts I had were - use something distributed like IEEE spanning tree in the routers with a mechanism to count hosts on the local wire and a hint about the edges of the network to automatically build the hierarchy in networks ranging from houses to Boeing's. - use a distributed instead of centralized registration facility, using the IEEE 48-bit address as the key for the registration but not putting it in any addresses. - use some of the automagic mechanisms that are necessary for route aggregation. It's too bad that the Internet is too mature for such silly ideas, as well as more radical and rational things to be seriously considered. It's too bad that without such things, light switches will not have IP addresses, because your average electrician won't be bothered with setting netmasks, installing static default routes, and partitioning address blocks into hierarchies. Oh, well. Someday light switches will have network addresses, even if not IP address, which is all that matters. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.OZ.AU Sun Jun 19 09:11:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06645; Sun, 19 Jun 1994 08:05: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 IAA06013; Sun, 19 Jun 1994 08:04:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA06010; Sun, 19 Jun 1994 07:55:15 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06341; Sun, 19 Jun 1994 07:55:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26175; Sat, 18 Jun 94 17:55:08 -0400 Date: Sat, 18 Jun 94 17:55:08 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406182155.AA26175@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, daniel@isi.edu Subject: Re: Variable length locators Cc: jnc@ginger.lcs.mit.edu From: daniel@isi.edu Having gone through the trouble of reading all the arguments about variable length locators ... note that not once did I use the word "address." :-) Unfortunately, I'm not sure we were talking about locators, fixed or variable length. For instance, since the locator would never be used as a transport level name, by definition all the discussion about the cost to TCP of variable length whatevers was by definition not about locators. I've basically given up hope of getting the terminology unscrewed. Tongue in cheek to a degree which I leave as an exercise to the reader, I have a modest proposal. In an earlier message, I indentifed three broad classes of how to go about it: - 1) those who think we should have a single label (i.e. the address) for both transport and internetwork level - 2) those who think we should have two (the EID and the ??), where the ?? is in all packets - 3) those who think we should have two (the EID and the locator), where the locator is in all packets. Then you get to decide about fixed and variable for all these. In short, a total of 12 different models. I suggest we identify, in each message we send, the particular model we're assuming in our statements by starting the message with a line of the form: "Model being used", where T is (1, 2 or 3, from the above), and each L is one of (F, V, for fixed and variable; second L optional). So, for example, the current SIPP spec is a 1F model (ignoring the source route stuff), and Nimrod is currently working with a 3FV model. Use "grep" type syntax if your comments apply across more than one model; e.g. the statement "variable length isn't a problem if the transport level name is fixed length" would apply to models [23]FV, and "I think we should separate out the transport name from the internetwork name" would apply in models [23].., and so on. Yes, this is completely ridiculous and stupid. However, short of adopting consistent terminology and carefully applying it, we're going to waste time discovering we've just had a flaming argument, and been arguing about completely separate things. I have absolutely no suggestions on how to fix this. Noel From owner-Big-Internet@munnari.OZ.AU Sun Jun 19 13:05:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14698; Sun, 19 Jun 1994 13:05: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 NAA06272; Sun, 19 Jun 1994 13:04:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA06267; Sun, 19 Jun 1994 13:01:52 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14671; Sun, 19 Jun 1994 13:01:48 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26596; Sat, 18 Jun 94 23:01:40 -0400 Date: Sat, 18 Jun 94 23:01:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406190301.AA26596@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: Variable length locators Cc: jnc@ginger.lcs.mit.edu It has been pointed out that I can't type and can't count. To wit: - 3) those who think we should have two (the EID and the locator), where the locator is in all packets. This should be "not necessarily in all packets". Then you get to decide about fixed and variable for all these. In short, a total of 12 different models. Again, since option 1 has only two choices, the total is 10. Noel PS: I guess I left out the cases having to do with not having an EID in all packets, but let's skip that. From owner-Big-Internet@munnari.OZ.AU Sun Jun 19 16:56:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21159; Sun, 19 Jun 1994 16: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 QAA06468; Sun, 19 Jun 1994 16:44:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA06454; Sun, 19 Jun 1994 16:35:42 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19804; Sun, 19 Jun 1994 16:01:50 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Why variable length? In-Reply-To: Your message of "Fri, 17 Jun 1994 23:29:13 MST." <199406180629.XAA07183@lager.cisco.com> Date: Sun, 19 Jun 1994 16:01:47 +1000 Message-Id: <23585.772005707@munnari.OZ.AU> From: Robert Elz Date: Fri, 17 Jun 1994 23:29:13 -0700 From: Tony Li Message-ID: <199406180629.XAA07183@lager.cisco.com> You went to a cube root when calculating current efficiencies, which I think is compltely unjustified. Certainly the allocation waste at the network level has been really quite minimal. True - this is an example of the higher levels of the hierarchy being able to be more effeciently managed than lower levels. Assuming that the effeciency that's obtained inside sites, will be the same that applies everywhere I don't believe is correct. Further, the figures for allocation ignore unallocated network numbers, thereby eliminating this as a significant contributor to lossage. Unallocated numbers aren't lost or wasted, unless the potential (or liklihood) for further allocations there no longer exists. Its true that the numbers didn't take into account any potential wastage at that level, but at the top level there should be none. It (under any scheme) is never going to waste bits - unless you do something silly like allocate the top bits only to countries or something, in which case you may have to wait for new countries to be created to use the bits, which would be lossage - this kind of thing is why we need careful allocation policies. You disagree about a byte of wasteage. Yes, though the calculations continued to assume that wastage. Even with SIPP there is some significant amount of administrative overhead at the front. I am not one of the SIPP workers, I was discussing purely the capacity of 16 byte addresses - anyone can take any number of bytes and waste them (look at NSAPs), nothing we can do can prevent people from proposing poor allocation strategies. I'm not sure which of the SIPP addressing proposals is supposed to be the current one - I'm not even sure if they've done one since the (proposed) switch to 16 bytes, so I make no comment about that. You (correctly) point out that there is SOME usage within the subnet. You've added another 8 bits of addressing, but you fail to take into account the additional level of hierarchy and the additional inefficiency. No, taking only 8 of the 48 bits (which I don't think should be used anyway, but never mind) accounts for that - those extra bits are the wastage (extreme ineffeciency). The point that I'm trying to make is that there is, in my mind, some significant chance that we could deliver a protocol which blows up in our (grandchildren's) faces. I agree, but with 16 bytes of addressing I simply can't see that it wil be addressing that will do it. It will be one of the things we're currently taking for granted, and not really debating at all that will do this. Unfortunately there is no way to guard against what we can't forsee. 16 bytes of addressing is simply plenty - provided we can stay rational with addressing schemes. Note that 4 byte addresses would certainly be just fine now, and we wouldn't be very worried at all about running out if all we had ever done was allocate blocks of class C addresses. We would still have lots of those left around - even using CIDR type addressing, with blocks split, and internal wastage because of it. The addressing plan is much more important than the number of bytes in the address. As I believe I've said before, 8 bytes would probably be enough till IPng dies from other causes. The difference between 8 bytes and 16 is so immense its almost beyond comprehension. kre From owner-Big-Internet@munnari.OZ.AU Sun Jun 19 19:28:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25651; Sun, 19 Jun 1994 18:45: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 SAA06585; Sun, 19 Jun 1994 18:44:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA06571; Sun, 19 Jun 1994 18:38:01 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23559; Sun, 19 Jun 1994 17:53:22 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id AAA04749; Sun, 19 Jun 1994 00:52:33 -0700 Date: Sun, 19 Jun 1994 00:52:33 -0700 From: Tony Li Message-Id: <199406190752.AAA04749@lager.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: Robert Elz's message of Sun, 19 Jun 1994 16:01:47 +1000 <23585.772005707@munnari.OZ.AU> Subject: Why variable length? Robert, The point that I'm trying to make is that there is, in my mind, some significant chance that we could deliver a protocol which blows up in our (grandchildren's) faces. I agree, but with 16 bytes of addressing I simply can't see that it wil be addressing that will do it. It will be one of the things we're currently taking for granted, and not really debating at all that will do this. Unfortunately there is no way to guard against what we can't forsee. 16 bytes of addressing is simply plenty - provided we can stay rational with addressing schemes. What you really mean by "rational" is "pretty close to optimal". If we could, that would be fine with me. But the fact of the matter is that there's an eduction problem associated with this that will not be overcome. Site administrators today only learn about subnetting because they absolutely have to so that they can get their networks up and running. Asking them to learn enough about addressing to "do the right thing" for the sake of addressing is akin to asking them to take up chemistry so that they can figure out when their car is polluting too much. It's a nice idea, but it has no hope of scaling. In a sense, you're absolutely correct. One of the things that we're taking for granted is expertise. The 800 people that we see three times a year certainly are indicative of the cream of the crop. But no matter how fast we educate and how well we coordinate, the operational folks in the IETF are not going to have intimate control over the Internet-yet-to-come. We simply set it in motion and hope that we put the right spin on it. And use body english when things look bad. To that end, we have to make the IPng design simple and forgiving. Simple in that things like renumbering and auto-configuration have to work to make a system of this size have a hope of working at all, and for the things that we don't know how to automate, such as address space design, we have to make it sufficiently forgiving so that real humans can do it, make mistakes, and walk away to tell about it. Tony From owner-Big-Internet@munnari.OZ.AU Sun Jun 19 19:45:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27282; Sun, 19 Jun 1994 19:45: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 TAA06652; Sun, 19 Jun 1994 19:44:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA06638; Sun, 19 Jun 1994 19:25:24 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26754; Sun, 19 Jun 1994 19:25:20 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Why variable length? In-Reply-To: Your message of "Sun, 19 Jun 1994 00:52:33 MST." <199406190752.AAA04749@lager.cisco.com> Date: Sun, 19 Jun 1994 19:25:16 +1000 Message-Id: <23610.772017916@munnari.OZ.AU> From: Robert Elz Date: Sun, 19 Jun 1994 00:52:33 -0700 From: Tony Li Message-ID: <199406190752.AAA04749@lager.cisco.com> What you really mean by "rational" is "pretty close to optimal". No, not at all, I agree with essentially everything in this message from you other than this one line. Optimal is clearly not going to happen, or rather, doesn't look likely to happen (some kind of automatic assignment with agressive renumbering, as was suggested here just recently may get close, but that doesn't look realistic any time soon). If we could get to about 25% per level of the hierarchy we'd have absolutely no problems, even 15% or 20% would suffice if we don't let the hierarchy get too deep. Also remember that some of the ineffeciencies we see with IPv4 are ones we have essentially forced on people - until recently anyone who was likely to hav more than a hundred or so hosts was usually given a class B address. This time we start with the knowledge that we need to conserve addresses - knowledge is powerful, with it we can do the right thing. Asking them to learn enough about addressing to "do the right thing" for the sake of addressing is akin to asking them to take up chemistry so that they can figure out when their car is polluting too much. Absolutely - partly this is a non issue, as by the time we get down to the space allocated to sites wastage there won't matter too much - we want to overallocate to them a little so as they grow that won't pollute the routing hierarchies. But more importantly, when we start deploying IPng we don't want humans allocating addresses the way we do now at all. Its unnecessary, error prone, and tedious. To that end, we have to make the IPng design simple and forgiving. Absolutely. Simple in that things like renumbering and auto-configuration have to work to make a system of this size have a hope of working at all, Absolutely - and fortunately, the combination of what is needed to make autoconfig & renumbering work almost by definition must take the manual work out of address assignment. Renumbering simply can't be done by sending mail to the net admin saying "Please renumber your net by Thursday" - it simply won't work. It has to be automated. If renumbering is automated, then consider initial numbering as simply renumbering from nothing. and for the things that we don't know how to automate, such as address space design, We don't know how to automate address space design, but that we don't need to do often - implementation of the design, once done, can be automated however. Almost no net admins want to design their own address space, they simply want something that works. Code to collect simple input that the admin does have like how many cables there are, and where they connect, and then to produce a numbering plan that works in accordance with the predesigned address plan can't be hard to produce. It doesn't need to be optimal, in terms of either addressing or routing, just adequate. kre From owner-Big-Internet@munnari.OZ.AU Sun Jun 19 21:05:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29421; Sun, 19 Jun 1994 21:05: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 VAA06733; Sun, 19 Jun 1994 21:04:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id UAA06717; Sun, 19 Jun 1994 20:49:45 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27816; Sun, 19 Jun 1994 20:02:02 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id DAA09960; Sun, 19 Jun 1994 03:01:17 -0700 Date: Sun, 19 Jun 1994 03:01:17 -0700 From: Tony Li Message-Id: <199406191001.DAA09960@lager.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: Robert Elz's message of Sun, 19 Jun 1994 19:25:16 +1000 <23610.772017916@munnari.OZ.AU> Subject: Why variable length? We don't know how to automate address space design, but that we don't need to do often - implementation of the design, once done, can be automated however. Are you seriously intending on imposing a single addressing design on the entire Internet? Would you today let me tell you what subnet mask you have to use? Almost no net admins want to design their own address space, they simply want something that works. Code to collect simple input that the admin does have like how many cables there are, and where they connect, and then to produce a numbering plan that works in accordance with the predesigned address plan can't be hard to produce. It doesn't need to be optimal, in terms of either addressing or routing, just adequate. You are correct in that net admins do not want to design their addressing. They frequently call on their vendors to do that for them, so I see more than my share. However, I find that every single addressing plan that I do is slightly different. You have quite a bit of non-tangible data which go into the design, such as how fast a particular subnet will need to grow. Not how fast the net admin _claims_ it will grow, when asked, but how it will really grow, given their business situation. Frequently the net admin is off by an order of magnitude or more. Then there's redundancy. And aggregation. And administrative boundaries within the organization. I agree that this is a really nice goal, and I, for one, would really like to see it. But it is, today, nothing more than a research idea. As you pointed out, it really does have to be more than "just adequate". It has to be something like 10-15% efficient. Frankly, I just don't like betting the Internet on the fate of a research project. Tony From owner-Big-Internet@munnari.OZ.AU Mon Jun 20 01:34:46 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06107; Mon, 20 Jun 1994 00:45: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 AAA06931; Mon, 20 Jun 1994 00:44:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA06928; Mon, 20 Jun 1994 00:40:12 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04358; Mon, 20 Jun 1994 00:00:14 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA29759; Sun, 19 Jun 94 10:00:03 -0400 Date: Sun, 19 Jun 94 10:00:03 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: <9406191400.AA29759@rodan.UU.NET> To: big-internet@munnari.OZ.AU Subject: "provider" indicator in addresses Implicit in most of the discussions about address format has been some notion of encoding "provider" pretty near the top (or at the top). While this notion exhibits pretty good consensus vibes, let me throw another log on that fire. One recurring problem within the current net is some notion of "locality." As resources get replicated and distributed to reduce long transits, identifying which resource servers might be closer to you than others is a real concern. The first jerk is to argue "Resource location protocol's job - not addressing." Well, right, but we ain't got one now for real. So simply being able to look at a list of possible servers and identify "good choices" is extremely useful, and a equality match on "provider" in the address is a reasonable first-guess at "good choice". (EG, A name server might even decide which address to return based on the provider in the request.) I realize I'm preaching to the choir here to some degree, but it's yet another reason to not lose that identification. I know it won't *always* work - damn few things ever do - but there are common scenarios where it can help dramatically until new, more knowledgeable resource location machinery spins up to speed. We now return you to your reguarly scheduled rant. -mo From owner-Big-Internet@munnari.OZ.AU Mon Jun 20 02:06:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08261; Mon, 20 Jun 1994 02:06: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 CAA07012; Mon, 20 Jun 1994 02:04:56 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA06998; Mon, 20 Jun 1994 01:46:11 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07710; Mon, 20 Jun 1994 01:46:06 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-25.dialip.mich.net (pm002-25.dialip.mich.net [35.1.48.106]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA01865 for ; Sun, 19 Jun 1994 11:46:01 -0400 Date: Sun, 19 Jun 94 14:34:05 GMT From: "William Allen Simpson" Message-Id: <2708.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: naming of designs > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > - 1) those who think we should have a single label (i.e. the address) for both > transport and internetwork level > - 2) those who think we should have two (the EID and the ??), where the ?? is > in all packets > - 3) those who think we should have two (the EID and the locator), where the > locator is in all packets. > the current SIPP spec is a 1F model (ignoring the source route stuff), and > Nimrod is currently working with a 3FV model. > Sorry, Noel, but you are incorrect about SIPP. The current SIPP model is 4F(V). 4) A single label for transport (the identifying-address) which includes routing domain information (for administration and slow single packet routing), a source route (for fast policy routing), and a Flow label (for faster multi-packet routing). The I-A and Flow are in all packets, the source route is optional (ideally only used to setup the Flow). Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Jun 20 04:06:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11673; Mon, 20 Jun 1994 04:06: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 EAA07128; Mon, 20 Jun 1994 04:04:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA07114; Mon, 20 Jun 1994 03:49:30 +1000 Precedence: list Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB11336; Mon, 20 Jun 1994 03:49:26 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA24866 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Sun, 19 Jun 1994 13:49:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 19 Jun 1994 13:49:15 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 19 Jun 1994 13:49:15 -0400 Message-Id: <199406191745.AA78185@foo.ans.net> To: bsimpson@morningstar.com Cc: big-internet@munnari.OZ.AU Subject: Re: naming of designs In-Reply-To: Bill Simpson's message of "Sun, 19 Jun 1994 14:34:05 GMT." <2708.bill.simpson@um.cc.umich.edu> Date: Sun, 19 Jun 1994 13:45:52 -0400 From: Dennis Ferguson >> From: jnc@ginger.lcs.mit.edu (Noel Chiappa) >> - 1) those who think we should have a single label (i.e. the address) for both >> transport and internetwork level >> the current SIPP spec is a 1F model (ignoring the source route stuff), and >> Nimrod is currently working with a 3FV model. > > Sorry, Noel, but you are incorrect about SIPP. > > The current SIPP model is 4F(V). > > 4) A single label for transport (the identifying-address) which > includes routing domain information (for administration and slow > single packet routing), a source route (for fast policy routing), So what is it which distinguishes "the identifying-address" from "the address" described in 1) above? Dennis Ferguson From owner-Big-Internet@munnari.OZ.AU Mon Jun 20 15:02:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13501; Mon, 20 Jun 1994 05: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 FAA07202; Mon, 20 Jun 1994 05:04:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA07197; Mon, 20 Jun 1994 04:55:45 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13133; Mon, 20 Jun 1994 04:55:41 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-22.dialip.mich.net (pm002-22.dialip.mich.net [35.1.48.103]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA10266 for ; Sun, 19 Jun 1994 14:55:37 -0400 Date: Sun, 19 Jun 94 18:38:46 GMT From: "William Allen Simpson" Message-Id: <2718.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Assignment Efficiency One of the topics of discussion on the SIPP list has related to assignment. One company which currently has order 10**5 (2**17) nodes, and expects to reach order 10**6 (2**20) nodes in the next 30 years, has asked for 2**48 addresses to be assigned, in order that it may have 5 layers of administration. Another person has asked me privately to expand the assignment guidelines in my recent draft. To that end, are we in agreement that nowhere would we allow 2**28 inefficiency in subscriber assignment? Would 2**4 be an acceptable maximum, or should we stick to the current 2**2? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Mon Jun 20 16:45:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02910; Mon, 20 Jun 1994 15:46: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 PAA07733; Mon, 20 Jun 1994 15:45:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA07719; Mon, 20 Jun 1994 15:38:26 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00296; Mon, 20 Jun 1994 14:33:57 +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 AA09912 Mon, 20 Jun 1994 14:32:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28360; Mon, 20 Jun 94 00:29:31 -0400 Date: Mon, 20 Jun 94 00:29:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406200429.AA28360@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, kre@munnari.OZ.AU Subject: Re: Why variable length? Cc: jnc@ginger.lcs.mit.edu From: Robert Elz > the allocation waste at the network level has been really quite minimal. this is an example of the higher levels of the hierarchy being able to be more effeciently managed than lower levels. Well, until recently these numbers were assigned in a "flat" way, so you could assign them sequentially, i.e. very efficiently. We'll have to see if the same inefficiency trends we now see *inside* network numbers propogate upward as CIDR is deployed, and we start allocating things at the higher levels in a way which follows a topologically related hierarchy. My guess they will.. Assuming that the effeciency that's obtained inside sites, will be the same that applies everywhere I don't believe is correct. Why not? The forces that drive inefficiency inside sites (allocate more space than you need for a given layer of naming, to prevent renumbering as you grow, etc, etc) are the same at higher levels as they are at lower levels, and in fact they are even *more* forceful at higher levels, since the amount of renumbering you have to do to change is larger... unless you do something silly like allocate the top bits only to countries or something Any scheme which allocates topological indentifiers from the top down in a static fashion, based on administrative agreements, and not bottom up, based on real topology, is almost inevitably going to have this kind of silliness. You wind up with allocations based on political and administrative considerations, not topology. Needless to say the routing doesn't like this too well, although you can apply more thrust (up to a certain point, of course, as we've found). (We've gotten away with this kind of things in the real world since physical topology and organizational boundaries tend to be related. However, the topology of cyberspace is pretty arbitrary...) I was discussing purely the capacity of 16 byte addresses I'm assuming you're using the term "address" here to mean "indentifier used at both the internetwork and transport layers", right? 16 bytes of addressing is simply plenty - provided we can stay rational with addressing schemes. Well, the bug in the calculations you guys have both been doing is that you're using experience with the current routing system, which can't do much fancy with QOS and policy. Thus, there's not much reason to name areas of the network topology about which you can make policy or QOS statements. (E.g. "the Mass Pike is a toll road".) Right now, the choice of objects to draw abstraction boundaries around is driven primarily by administrative concerns (i.e. "our company got this block of addresses from the IANA"), and secondarily by issues of routing overhead. (I.e. we put CIDR up because the top level got too large to route effectively, requiring us to put more layers of boundaries in what used to be a single layer.) It's extremely likely that the addition of more factors in the routing will cause us to adopt a more complex abstraction hierarchy. (In English, that way, we can do things like name the Mass Pike.) In other words, more levels of hierarchy. Since the number of levels appears as a *exponent* in those efficiency calculations, this is bad news on that front. Unfortunately, I have no way to quantify this affect, although I know it will happen. (Oh, BTW, I'm assuming you're using the term "address" to mean a 'name' with topological sensitivity here.) Note that 4 byte addresses would certainly be just fine now, and we wouldn't be very worried at all about running out if all we had ever done was allocate blocks of class C addresses. We would still have lots of those left around Nope. Assuming all the class A space was pissed away (and in fact, it's less than 50% used, and I expect a large chunk of it wil get CIDR'ized one day), that's still only 4 times as much space as the entire C space. The Internet is doubling in size about every year (and I don't know of anyone who thinks this rate is going to slow down substantially anytime soon, although some think it will speed up). So in a hypothetical future in which we productively use all of class A space, we get 2 years more than we get in the h.f. in which we pissed away all of A space. Of course, if the growth starts to happen in ways which tends to fill in already allocated adddress space, this doubling time might change, but we do have this kind of growth ocurring already, without having affected the growth rate much. The addressing plan is much more important than the number of bytes in the address. Sure, but any such plan which is imposed from the top down isn't going to do too well. The topology of the real world is remarkably resistant to change (modulo the odd war), but the topology of cyberspace is distressingly fluid. As I believe I've said before, 8 bytes would probably be enough till IPng dies from other causes. Really? You think the basic ideas have that short a shelf-life? Would we be discarding IPv4 if the addresses were 8 bytes long? I think not (SIPP looks pretty much like IPv4 with 8 byte addresses, as Steve used to keep pointing out.) Heck, if IPv4 had 8 byte addresses, I'd be figuring out how to make it work with flows, without a new packet format! The reason I'm suggesting doing something radical is we *are* talking about doing a new packet format (and hitting all the hosts). I guess I'm still dubious we can pull this off, actually. There are a *lot* of IPv4 hosts out there, and the economic incentive to keep IPv4 patched into life is going to be pretty big... but let's not get into that. Noel From owner-Big-Internet@munnari.OZ.AU Mon Jun 20 18:57:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05672; Mon, 20 Jun 1994 17:05: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 RAA07812; Mon, 20 Jun 1994 17:05:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA07798; Mon, 20 Jun 1994 16:50:20 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28403; Mon, 20 Jun 1994 13:36:51 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA05073; Sun, 19 Jun 94 22:38:21 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ba07665; 20 Jun 94 3:34 GMT Date: Sun, 19 Jun 94 22:29 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: REALITY CHECK TIME! Message-Id: <45940620032954/0003858921NA5EM@mcimail.com> I am composing this note on my flight back from INET'94. I am caught up with BIG-I as of last sunday noon (6-12), and although I spoke to a few of you in Prague, things just MIGHT have occured to obsolete this message. But since as soon as I get back, I will be over a week behind in all mail (unless MCI started throwing out messages after some limit) I will not get another chance to compose such a note......... NOTES about EIDs I like them. They must be globally unique and must not be based on MAC addresses. first on not MAC addresses: I have enough hosts with multiple interfaces to make it an interesting excercise to choose just one. But to stave off any comments, consider dialup, the interface is the serial port, and soon we may have more of those than ethernet cards. Think if all those BBS and commercial online providers start using EIDs. I have a MAJOR need for dialup. Over 1,000 field people, just under 6,000 dealers with dialup as backup to the X.25 network (but then I would use the X.121 address as the EID, right?), and between 6,000 and 10,000 suppliers that will be accessing my automotive supplier firewall (some over dedicated lines, some over the INTERNET, most dialing up for some time). There will be other technologies as well, radio perhaps. So I think we should not encourage MAC addresses, but find another method. I kind of like the idea of an IANA that would assign part of the EID, much like IEEE does for MAC addresses and leave the rest for us. 2^32 registered entities MIGHT be enough, AIAG will only register some 60,000 and NADA well, I really do not know how many dealers there are in North America :( 32 bits should be enough for us big guys to administer our own numbers, particularly for address bit twiddlers like Chrysler :) Next on to locators: Large private networks like Chrysler's and as Brian Carpenter pointed out, CERN and Boeing will want complete control of the address. So the Locator will be a completely internal matter with internal routing policies determining how packets get to the corporate boarders and out. By the end of this year, I hope to have a few connections to the INTERNET... 64 bits SHOULD be enough for the routing we need to do inside our Corporate network, again with bit twiddling. And see below about this bit twiddling... Now an interesting problem with locators.... Let us consider Mom&Pops Nylon Fasteners in Livonia MI. They supply them to Chrysler, FORD and GM. Being a smallish supplier, they communicate to each of the OEMs via the OEM's private dialup services; a couple times a day to each costing a couple of dollars a day for the communications. First question is the EID; Mom&Pops CIO, son Billy, applied to the IANA and got 252685 (he is one of the early implementors of IPng). Their Novell server's EID is 252685.1, the AutoCad workstation is 252685.2, and the business workstation (complete with EDI software) is 252685.3 or some such. The Locator for this little network SHOULD be 'unimportant' and SHOULD auto-configure from the Novell Server. Now what is the Locator for the business workstation's serial port? I would hope that the new PPP spec that supports IPng will allow for only the negotiation of the Locator when desired (other times we might want to dictate the EID, but I bet not). In fact, I wonder what the IP providers think about the current IPng addressing. Are any of them here? Address Presentation: This time around, we have to encourage, no, rather insist on address bit twiddling. Byte bounderies MUST go by the wayside. A new representation that is truely user frendly. The might be it. I don't know for sure. There are only a handful of us here at Chrysler that REALLY understand what we have done with variable subnetting; we are trying to rectify that. You mathematicians ot there think up something that a CNE can deal with.... This is all for now, one more hour to Detroit and I have a trip report to write! Bob From owner-Big-Internet@munnari.OZ.AU Mon Jun 20 21:16:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09864; Mon, 20 Jun 1994 19:05: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 TAA07928; Mon, 20 Jun 1994 19:05:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA07925; Mon, 20 Jun 1994 18:57:27 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06301; Mon, 20 Jun 1994 17:29:30 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Why variable length? In-Reply-To: Your message of "Sun, 19 Jun 1994 03:01:17 MST." <199406191001.DAA09960@lager.cisco.com> Date: Mon, 20 Jun 1994 17:29:26 +1000 Message-Id: <23677.772097366@munnari.OZ.AU> From: Robert Elz Date: Sun, 19 Jun 1994 03:01:17 -0700 From: Tony Li Message-ID: <199406191001.DAA09960@lager.cisco.com> Are you seriously intending on imposing a single addressing design on the entire Internet? No - if you read what I said (which I admit was a little confused - the latter part of the sentence you quoted could have been read that way I guess) you'd see I indicated that there wouldn't be many addressing designs (which does not mean only one), software could cope with that OK - either by using different software, or one process that can select among several algorithms. Would you today let me tell you what subnet mask you have to use? No, of course not - but subnet masks are an output of the process, not an input - to use a subnet mask at all is an addressing design, the value of the subnet mask to use is something the software should select for you (and probably implement without you ever seeing it if you don't want to). The "several addressing designs" would refer to choices like flat routing througout the organisation, or fully topological routing with varying subnet masks, or ... There aren't a lot of different choices at that level - that we know of now anyway. As more are invented, they can be implemented and made available. However, I find that every single addressing plan that I do is slightly different. I assume in detail, not in overall philosophy. You have quite a bit of non-tangible data which go into the design, such as how fast a particular subnet will need to grow. That's certainly true today, but it had better not be true in the future. We know that we're going to have to implement automatic renumbering so that routing can scale as people (orgs) move around the topology - the same automatic renumbering can cope with unexpected increases in subnet sizes. Frequently the net admin is off by an order of magnitude or more. That's OK, that much slop we can allow (3 bits) - the software can simply assume that at the subnet level. At higher levels things rarely grow that fast, so perhaps 2 bits wasted would be reaosnable. For a 5 level hierarchy that would be 11 wasted bits. That means a 32 bit space could handle 2^21 nodes, with plenty of room left for growth everywhere with 5 levels of hierarchy (ie: a lot). That's one huge network. Organisations even vaguelly likely to need a net anything like that big will impose no strain on 128 bits of address space at all if they're given 32 bits each. Smaller organisations (individial houses, 3 man companies, etc) are never going to need nearly that many, and smaller spaces will suffice for them - that's the majority of sites, or will be. Then there's redundancy. And aggregation. Yes, software can allow for that (though reduncancy and room for growth are the same thing, aren't they?) Software can probably do aggregation better than most humans. And administrative boundaries within the organization. In organisations where that's important, that can be handled too - in other organisations it doesn't matter - this is really no different from delegation by higher level, and simply gives each admin unit a smaller spac in which to manage its own needs. But it is, today, nothing more than a research idea. Renumbering may be, but it is something that we have to make work - it also doesn't look difficult - even less so if we spearate transport level identification from the network level. As you pointed out, it really does have to be more than "just adequate". It has to be something like 10-15% efficient. Yes, but that is not a lot to ask (15% per level, not 15% overall). kre From owner-Big-Internet@munnari.OZ.AU Mon Jun 20 23:47:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13101; Mon, 20 Jun 1994 21:05: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 VAA08044; Mon, 20 Jun 1994 21:05:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA08039; Mon, 20 Jun 1994 21:01:34 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09905; Mon, 20 Jun 1994 19:07:28 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id CAA01409; Mon, 20 Jun 1994 02:06:25 -0700 Date: Mon, 20 Jun 1994 02:06:25 -0700 From: Tony Li Message-Id: <199406200906.CAA01409@lager.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: Robert Elz's message of Mon, 20 Jun 1994 17:29:26 +1000 <23677.772097366@munnari.OZ.AU> Subject: Why variable length? Robert, Then there's redundancy. And aggregation. Yes, software can allow for that (though reduncancy and room for growth are the same thing, aren't they?) Software can probably do aggregation better than most humans. Partitioning the topology to allow for aggregation in the face of redundancy is a non-trivial problem. You have to understand which parts of the organization are not affected by being in a partitioned area, for example. And administrative boundaries within the organization. In organisations where that's important, that can be handled too - in other organisations it doesn't matter - this is really no different from delegation by higher level, and simply gives each admin unit a smaller spac in which to manage its own needs. Handled HOW? Short of an AI project, I certainly don't see that happening. Renumbering may be, but it is something that we have to make work - it also doesn't look difficult - even less so if we spearate transport level identification from the network level. No, I'm talking about the software for doing addressing design, NOT renumbering. I understand the renumbering problem, the only question there is the mechanics. Addressing today is nothing short of an art, and I don't see that you'll be successfull doing that with anything less than an expert system. And maybe not even then, as much of it is value judgement. Tony From owner-Big-Internet@munnari.OZ.AU Mon Jun 20 23:52:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13646; Mon, 20 Jun 1994 21:25: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 VAA08087; Mon, 20 Jun 1994 21:25:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA08071; Mon, 20 Jun 1994 21:17:02 +1000 Precedence: list Received: from dxmint.cern.ch by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11787; Mon, 20 Jun 1994 20:09:39 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA23982; Mon, 20 Jun 1994 12:09:33 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA09303; Mon, 20 Jun 1994 12:09:33 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406201009.AA09303@dxcoms.cern.ch> Subject: Re: Assignment Efficiency To: bsimpson@morningstar.com Date: Mon, 20 Jun 1994 12:09:33 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <2718.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Jun 19, 94 06:38:46 pm Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1421 Bill, I am getting fed up with the way you refuse to acknowledge the actual request made by the few corporate network managers who happen to be active on these lists. The actual request is not for "2**48 addresses to be assigned". It is for "enough address bits to allow a sparse numbering plan". You are arguing that address bytes are expensive and should be minimised. We are arguing (for a variety of reasons that have been beaten to death by now) that WE, the paying customers for large quantities of distributed computing product, WANT sparse address spaces. A compromise at 16 bytes has been proposed. Well, as I said, I'm fed up with this argument. If you want to ignore a market message, fine. Brian >--------- Text sent by William Allen Simpson follows: > > One of the topics of discussion on the SIPP list has related to > assignment. One company which currently has order 10**5 (2**17) nodes, > and expects to reach order 10**6 (2**20) nodes in the next 30 years, has > asked for 2**48 addresses to be assigned, in order that it may have 5 > layers of administration. > > Another person has asked me privately to expand the assignment > guidelines in my recent draft. > > To that end, are we in agreement that nowhere would we allow 2**28 > inefficiency in subscriber assignment? Would 2**4 be an acceptable > maximum, or should we stick to the current 2**2? > > Bill.Simpson@um.cc.umich.edu > From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 00:12:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16435; Mon, 20 Jun 1994 23:05: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 XAA08178; Mon, 20 Jun 1994 23:05:08 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA08164; Mon, 20 Jun 1994 22:54:12 +1000 Precedence: list Received: from mailhub.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16017; Mon, 20 Jun 1994 22:54:05 +1000 (from john@iastate.edu) Received: from pooh.cc.iastate.edu by mailhub.iastate.edu id AA25794; Mon, 20 Jun 1994 07:54:08 -0500 Received: by pooh.cc.iastate.edu; id AA08531; Mon, 20 Jun 1994 07:53:57 -0500 Message-Id: <9406201253.AA08531@pooh.cc.iastate.edu> To: big-internet@munnari.OZ.AU Subject: Re: Assignment Efficiency In-Reply-To: Your message of Mon, 20 Jun 1994 12:09:33 +0200. <9406201009.AA09303@dxcoms.cern.ch> Date: Mon, 20 Jun 1994 07:53:57 CDT From: John Hascall Brian.Carpenter@cern.ch writes: > We are arguing (for a variety of reasons > that have been beaten to death by now) that WE, the paying customers > for large quantities of distributed computing product, WANT sparse > address spaces. A compromise at 16 bytes has been proposed. > Well, as I said, I'm fed up with this argument. If you want to ignore > a market message, fine. Remember that 99+% of us paying customers would fit in 2 bytes and our customer message is: fast, small, simple. I'll suggest that the "customer area" be fairly small and that address blocks be sold (at say US$65/64KiloAddrs) - then if the gentleman would like a big huge sparse address space, he could put his money where his mouth is. With reasonable efficiency that would be < $10K for 2^20 nodes, with `governmental' efficiency (using 2^48 addresses :) that would be $279,172,874,240. (That should cover the IPds9 research bill, eh? :) > >--------- Text sent by William Allen Simpson follows: > > One of the topics of discussion on the SIPP list has related to > > assignment. One company which currently has order 10**5 (2**17) nodes, > > and expects to reach order 10**6 (2**20) nodes in the next 30 years, has > > asked for 2**48 addresses to be assigned, in order that it may have 5 > > layers of administration. John From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 01:33:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18829; Tue, 21 Jun 1994 00:05: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 AAA08247; Tue, 21 Jun 1994 00:05:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA08242; Mon, 20 Jun 1994 23:56:54 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14411; Mon, 20 Jun 1994 22:00:02 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA28743; Mon, 20 Jun 1994 14:00:34 +0200 Message-Id: <199406201200.AA28743@mitsou.inria.fr> To: Brian.Carpenter@cern.ch Cc: big-internet@munnari.OZ.AU Subject: Re: Assignment Efficiency In-Reply-To: Your message of "Mon, 20 Jun 1994 12:09:33 +0200." <9406201009.AA09303@dxcoms.cern.ch> Date: Mon, 20 Jun 1994 14:00:32 +0200 From: Christian Huitema Brian, Minimizing the size of the header is a valid concern. In short, the header is a "common good"; its size has a direct impact on everybody's performances - see the figures provided by Craig Partridge on cache lines, etc. You can reasonably expect a large body of users to protest loudly against an attempt to jeopardize this common good. Indeed, we are not in the business of skinning down the header at all cost - it must carry sufficient information to do the job. We seem to be very near from an agreement on "SIPP with 16 octets address", which appears to be a very reasonable middle ground. My own proposal of "8 or 16" was a secondary optimization - I would be happy with a fixed 16 octets address. The requirement put forward by Boeing puzzles me. That they need five level of addressing hierarchy for their internal network seems bizarre when the whole telephone network of France only uses 3 (nation, slice of 10000 numbers, number). I have not looked at their particular problem though, and have no way to assess the cost of alternate solutions. But I would be extremely surprised to learn that no other plan would be conceivable, either by using a different hierarchy, or by assigning variable bit lengths to different branches of the hierarchical tree, or by combining a relatively flat addressing with the use of source routes. By the way, the SIPP loose "source route" are precisely there to provide an escape and a path of evolution. We may not know the details yet, but all works on flexible routing (nimrod, sdrp, idpr, route segments) point towards this type of solution. The "address" may be fixed size, but we will have many of them... Christian Huitema From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 01:45:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22634; Tue, 21 Jun 1994 01:45: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 BAA08357; Tue, 21 Jun 1994 01:45:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08343; Tue, 21 Jun 1994 01:39:23 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20926; Tue, 21 Jun 1994 00:54:46 +1000 (from kre@munnari.OZ.AU) To: Tony Li Cc: big-internet@munnari.OZ.AU Subject: Re: Why variable length? In-Reply-To: Your message of "Mon, 20 Jun 1994 02:06:25 MST." <199406200906.CAA01409@lager.cisco.com> Date: Tue, 21 Jun 1994 00:54:42 +1000 Message-Id: <23722.772124082@munnari.OZ.AU> From: Robert Elz Tony, I think you're reading more into my suggestions than that which I am making. I'm not claiming that network design is easy, or can be solved simply by some magic software, that still needs to be done the hard way. Just that once the network is designed it can be numbered fairly easily. Handling aggregation and allowing for redundant nets to be (partly) partitioned (full partitioning is no problem) is difficult, I agree, so simply err on the conservative side, and don't aggregate anywhere that's possible. Detecting that is not difficult (its basically a loop in the net) - for 99% of sites this will be just fine, almost no-one needs full aggregation of their internal net, in fact the vast majority of sites can easily survive with simple flat routing. Sites that need more can hire an expert (from their friendly router vendor probably) and have it done properly. Similarly, administrative breakdowns need to be done by the organisation concerned, if it was anything else it wouldn't be administrative - once that breakup is done, the numbering is simply applied to each part separately, the results of that are input to the same algorithm which will then number the higher level. Its true that addressing today is an art - that's partly because it needs to be made right first time, and that involves much crystal ball gazing (ie: expert analysis). But once we have auto renumbering this is less important - if an initial attempt proves to be less than ideal, simply do it all again and renumber. Sometimes brute force can be effective. kre From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 02:37:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22656; Tue, 21 Jun 1994 01: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 BAA08372; Tue, 21 Jun 1994 01:47:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08340; Tue, 21 Jun 1994 01:35:42 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19487; Tue, 21 Jun 1994 00:18:31 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Mon, 20 Jun 1994 10:17:45 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 20 Jun 1994 10:17:45 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA03015; Mon, 20 Jun 94 10:15:55 EDT Date: Mon, 20 Jun 94 10:15:55 EDT Message-Id: <9406201415.AA03015@mailserv-D.ftp.com> To: kre@munnari.OZ.AU Subject: Re: Why variable length? From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: tli@cisco.com, big-internet@munnari.OZ.AU Content-Length: 2026 > From: Robert Elz > Date: Fri, 17 Jun 1994 18:03:10 -0700 > From: Tony Li > > I guess I disagree with the entire philosophy of designing > to just meet the design parameters and no farther. ... > It all depends how the parameter was set. I believe the > "must handle 1e15 hosts" requirement is set at a "we don't > really ever expect it to get this high, but just in case" > value, rather than a "this is how many hosts we really think > we'll have". Not quite. There is a white paper from the cable television industry in the internet drafts directory. draft-vecchi-ipng-tvcable-viewpt-00.txt It provides the basis for the E12 network numbers statement. In terms of planning for worldwide cable TV, they estimated that there would be on the order of E10 homes in the world. They added 2 orders of magnitude of safety and then said that IPng needed to support E12 end nodes. Now, the cable TV people see a home as an end-node. The authors of the IPng criteria document see a home as a 'leaf network' on which one possible node might be a cable-tv box. So, the cable tv estimate of E10 homes, with 2 orders of magnitude to get us E12 seems reasonable as the total number of 'leaf-networks' in the world. This number includes not only homes but offices, factories, cars, boats, planes, trains, etc etc etc. Where did E15 "end nodes" come from? Well, how many, on average, end nodes will there be per leaf network? 10? 100? 1000? Well, 10 seems too small, (for the world-wide average), 1000 seems too big. 100 is probably about right -- and when you consider that there are 2-3 million estimated end nodes on the Internet, with something like 30,000 networks, 100 end-nodes/network seems even more better. Add an order of magnitude for safety and you get 1000 nodes/network or E15 nodes... E15 was not the product of a random number generator... -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 02:37:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22670; Tue, 21 Jun 1994 01:48: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 BAA08387; Tue, 21 Jun 1994 01:48:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA08337; Tue, 21 Jun 1994 01:30:40 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18805; Tue, 21 Jun 1994 00:03:59 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-08.dialip.mich.net (pm002-08.dialip.mich.net [35.1.48.89]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id KAA16408 for ; Mon, 20 Jun 1994 10:03:52 -0400 Date: Mon, 20 Jun 94 13:29:16 GMT From: "William Allen Simpson" Message-Id: <2724.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: Assignment Efficiency > From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) > I am getting fed up with the way you refuse to acknowledge the actual > request made by the few corporate network managers who happen to be > active on these lists. The actual request is not for "2**48 addresses > to be assigned". It is for "enough address bits to allow a sparse > numbering plan". The _actual_ request was for 2**48 addresses for 2**20 nodes. > You are arguing that address bytes are expensive and > should be minimised. We are arguing (for a variety of reasons > that have been beaten to death by now) that WE, the paying customers > for large quantities of distributed computing product, WANT sparse > address spaces. You, the NON-paying customers, are requesting the rest of us to pay to support your fantasy. I have not yet seen your offer to pay even at a annual rate of $0.001 for each allocated address, since that would be _vast_ quantities of money for a sparse space. In another message to the SIPP list, you have asked that addresses be even bigger than DECnet V, to provide a 1:1 mapping. The other big site has proposed as much as 24 bytes. # From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) # Message-Id: <9406200656.AA00388@dxcoms.cern.ch> # Subject: Re: How many things we identify # Date: Mon, 20 Jun 1994 08:56:33 +0200 (MET DST) # # No, NO, *NO*! You just add a prefix. The numbering plan survives but the # address space gets bigger. There is a second stage in Phase V transition # when you can renumber but only when all Phase IV hosts have gone away. # # > (If not, what was the benefit?) You'll have to # > renumber eventually when you switch fully from IPv4 to IPng, # > again that's the whole point. # # Exactly. The SIPP space is big enough to contain the IPv4 space. # I would like it big enough to contain other address spaces too. # That is exactly, precisely my point. > Well, as I said, I'm fed up with this argument. If you want to ignore > a market message, fine. > I'm not ignoring your message, I'm saying you are Wrong *WRONG* W-R-O-N-G! To paraphrase another, if we had wanted huge sparse addresses, we would have chosen CLNP two years ago. The bits are not free. 16 bytes is too big for my needs. 24 is TOTALLY UNACCEPTABLE. To paraphrase yet another, "You can't have it!" To return to the topic in this thread, for allocation guidelines, do we stick to the current 2**2 slop target, or expand to 2**3 or 2**4? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 04:25:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28361; Tue, 21 Jun 1994 04:25: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 EAA08732; Tue, 21 Jun 1994 04:25:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA08696; Tue, 21 Jun 1994 04:08:19 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27848; Tue, 21 Jun 1994 04:08:16 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA25524; Mon, 20 Jun 94 12:07:54 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06502; Mon, 20 Jun 94 11:04:42 PDT Date: Mon, 20 Jun 94 11:04:42 PDT Message-Id: <9406201804.AB06502@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Jon Crowcroft From: Greg Minshall Subject: Re: variable length addresses Cc: big-Internet@munnari.OZ.AU Jon, >ok, what about a ipng video on demand server or a transactions server >supporting 100,000 customers >it has to map addresses into TCP PCBs exactly as fast as the router >forwarding packets to it (Note that it needs to use both the *source* and *destination* addresses...) >it has to do a _full address match_ not just a prefix one... Rob Ullman shared a cute trick, which is compute the pheader checksum first on the incoming packet, then use *THAT* as the key to look up the PCB. (Once it has found the PCB, of course, it needs to compare all the address bits.) Does this help? Greg From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 04:26:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28388; Tue, 21 Jun 1994 04:26: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 EAA08747; Tue, 21 Jun 1994 04:26:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA08699; Tue, 21 Jun 1994 04:08:34 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27857; Tue, 21 Jun 1994 04:08:31 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA25550; Mon, 20 Jun 94 12:08:10 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB06502; Mon, 20 Jun 94 11:04:59 PDT Date: Mon, 20 Jun 94 11:04:59 PDT Message-Id: <9406201804.AB06502@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: J.Crowcroft@cs.ucl.ac.uk From: Greg Minshall Subject: Re: variable length addresses Cc: big-internet@munnari.OZ.AU Jon, >personally, i think there are as many opportunities to assign >variable length wrong as there are advantages in the flexibility ... >this is based on talking to sites with 100k host networks in the UK, i >often find they have a real problem with IPv4 address assignment. >and note, if someone gets it wrong, the use memory in _all_ routers I think the *best* argument for variable length addresses is that it allows for sloppy address assignment (by your 100k host networks, say) and still *runs*. It may not run optimally, but as long as the "damage" is contained within a given site, then this is not a problem globally. And, if runs poorly enough, people will eventually be motivated to apply sufficient brainpower to fix it. As you mention, even IPv4 addresses are subject to this problem. I assume you don't want to *constrain* the address assignment any more than is done in IPv4? Thoughts? Greg From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 04:30:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24475; Tue, 21 Jun 1994 02:45: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 CAA08578; Tue, 21 Jun 1994 02:45:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08511; Tue, 21 Jun 1994 02:32:53 +1000 Precedence: list Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23883; Tue, 21 Jun 1994 02:32:50 +1000 (from kre) Date: Tue, 21 Jun 1994 02:32:50 +1000 From: Robert Elz Message-Id: <9406201632.23883@munnari.oz.au> To: kasten@ftp.com Subject: Re: Why variable length? Cc: big-internet@munnari.OZ.AU, tli@cisco.com Date: Mon, 20 Jun 94 10:15:55 EDT Message-Id: <9406201415.AA03015@mailserv-D.ftp.com> From: kasten@ftp.com (Frank Kastenholz) E15 was not the product of a random number generator... I didn't think I said it was, rather that it was designed to be more that we ever thought we'd reach, which I believe your message just confirmed. Take rational estimates, add three more orders of magnitude, and you have more than we expect to ever reach, right? kre From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 04:35:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24601; Tue, 21 Jun 1994 02:48: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 CAA08595; Tue, 21 Jun 1994 02:47:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA08544; Tue, 21 Jun 1994 02:37:08 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22672; Tue, 21 Jun 1994 01:48:42 +1000 (from valdis@black-ice.cc.vt.edu) Received: (valdis@localhost) by black-ice.cc.vt.edu (8.6.8.1/8.6.7) id LAA22565; Mon, 20 Jun 1994 11:48:39 -0400 Message-Id: <199406201548.LAA22565@black-ice.cc.vt.edu> To: Robert Elz Cc: big-internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Sat, 18 Jun 1994 09:56:05 EDT." <23397.771897365@munnari.OZ.AU> From: Valdis.Kletnieks@vt.edu Date: Mon, 20 Jun 1994 11:48:38 +22306356 Sender: valdis@black-ice.cc.vt.edu On Sat, 18 Jun 1994 09:56:05 EDT, Robert Elz said: > I had never imagined that anyone could think otherwise, has > anyone been assuming that Boeing and Joe's fish shop would > fit into the allocation hierarchy at the same level? Well.. it depends on *which* 'same level'... > Not really - Boeing is to all intents and purposes a provider, > except that they sell services only within their own company. > We simply treat them, and other similar companies, as providers. > Not only does this make address allocations more rational, it > also probably helps routing long term (as they connect to the > net in many places, rather than just one). OK.. I have to ask here - exactly *how* are you defining 'provider' here? Is ANS a provider, selling services to all comers? Is Boeing, selling only internally? Is 'Virginia Tech Communications and Network Services', because we chargeback for network connections to the campus backbone? If I have a medium-sized business that has a crew of 3 guys that do PC networking, is that a provider? If I manage my home network, am I a provider? (Remember, I could be connecting to many places - I already know people who subscribe to AOL, Compu$erve, Prodigy, *and* buy SLIP access from more than 1 vendor. Damn slippery slope here, especially if you're planning to base your allocation heirarchy on it. Valdis Kletnieks Computer Systems Engineer Virginia Tech From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 04:48:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26173; Tue, 21 Jun 1994 03: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 DAA08654; Tue, 21 Jun 1994 03:25:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA08627; Tue, 21 Jun 1994 03:06:05 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25245; Tue, 21 Jun 1994 03:05:51 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA22941; Mon, 20 Jun 94 10:07:55 -0700 Date: Mon, 20 Jun 94 10:07:55 -0700 From: Eric Fleischman Message-Id: <9406201707.AA22941@atc.boeing.com> To: Big-Internet@munnari.OZ.AU, vjs@rhyolite.wpd.sgi.com Subject: re: not in the same reality..... Dear Vernon, Yes, I have read the BIGTEN draft. As I understand it, BIGTEN is an attempt to form a global compromise between all IPng factions. It encorporates elements from each of the approaches and seemed to satisfy the leaders of all the IPng working groups (with one notable exception). I had hopes that it might prove to be universally appealing, though there were elements of that compromise that I didn't like. However, a good compromise has much much more good than bad and it evenly distributes the pain and benefit -- and is workable. Thus, I had great hopes for that position. Be that as it may, I have only a few personal "hot buttons" concerning IPng: 1) IPng must work -- and work very well. 2) IPng must be simple, easy-to-use, scalable, expandable and endure several decades. 3) IPng must have a large address space. I can not believe 8 bytes are adequate for the world-wide Internet in 2010. I prefer 16 bytes if we must have a "one size fits all" approach. 4) IPng must have enhanced functionality over IPv4 so that users will want to deploy it instead of IPv4 -- either that or it must have workable (non-broken) IPAE-like element so that users won't know that they have deployed it. 5) IPng must be able to serve as a convergence protocol upon which all datagram technologies may eventually converge. It should be "one protocol to bind them all." Bottom line: IPng represents substantial (i.e., unbelievably high) potentially non-value added expense for large end users. There had better be an awefully good reason for us to deploy such a thing -- and it had better endure for several decades if there is any hope for us to justify such a deployment via cost/benefit analysis. IPng is a hard sell and our vendors had better plan on supporting IPv4 for some time to come -- unless IPng is bundled with "killer applications" or something very surprising happens to the market. >By the way, I'm surprised at your statements that Boeing is interested >in having 1,000,000 IP hosts. Last I knew, long ago as well as not so >long ago, based on public statements as well as private conversations, >I thought Boeing was still very much in the "OSI will eventually >triumph" camp. What happened? Is this indicative of a change in >official corporate strategy? Judging from your suggestions aimed at >covering all bases, an underlying affection for the cover-all-bases >style of the OSI protocols remains. (Please do not be too insulted by >that observation. It's only a statement of apparent fact. Only among >the worst of politicians can someone's past positions or the positions >of one's predecessors be insults.) Boeing is a team player. It builds airplanes, not data comm equipment. If our customers and partners want a certain type of data comm, we try very hard to comply. If governments or our industry require conformance to a certain type of data comm, then we must comply, of course. Only a few years ago the situation was that substantial parts of the world REQUIRED OSI for commerce. TCP/IP was illegal for commerce in many of the countries we trade in. What would you do it 60% (or more) of your revenue came from outside of North America? There is no rocket science here: you follow the market and the governmental decrees. Of course, what you do in your own internal networks is again a function of the market. Why are you surprised, therefore, that we have among the larger TCP/IP deployments in the world? Is there a better game in town that we should have invested in? TCP/IP is currently both our tactical and strategic data communications direction. We are currently trying to converge many of our deployed protocol families upon TCP/IP transports -- and eliminate from usage those which don't/can't converge. Exceptions, of course, exist: it appears that the aeronautical industry is about to require OSI usage for communications world-wide and some of our business partners still have similar requirements. But that isn't what you asked. You asked about our reputation for OSI support stemming from the Technical and Office Protocol (TOP) and a certain world-famous individual. Well, we felt that TOP was a good idea and we honestly tried to deploy it. However, at least one important vendor did not have deployable products and wasn't very cooperative, so we had to try some other open systems-based corporate solution. As for world-famous individuals, what do you do with a visionary when you no longer think that the vision of that visionary is correct -- especially if the visionary does not alter the vision with the receipt of new and enhanced data? Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 05:57:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28429; Tue, 21 Jun 1994 04:27: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 EAA08762; Tue, 21 Jun 1994 04:27:41 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA08718; Tue, 21 Jun 1994 04:16:18 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28024; Tue, 21 Jun 1994 04:16:15 +1000 (from bill.simpson@um.cc.umich.edu) Received: from [35.1.1.42] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15306 Tue, 21 Jun 1994 04:16:09 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-07.dialip.mich.net (pm002-07.dialip.mich.net [35.1.48.88]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id OAA08343 for ; Mon, 20 Jun 1994 14:13:25 -0400 Date: Mon, 20 Jun 94 16:26:57 GMT From: "William Allen Simpson" Message-Id: <2727.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Margins Thank you, Frank. > From: kasten@ftp.com (Frank Kastenholz) > Date: Mon, 20 Jun 94 10:15:55 EDT > > From: Robert Elz > > Date: Fri, 17 Jun 1994 18:03:10 -0700 > > From: Tony Li > > > > I guess I disagree with the entire philosophy of designing > > to just meet the design parameters and no farther. > ... > > > It all depends how the parameter was set. I believe the > > "must handle 1e15 hosts" requirement is set at a "we don't > > really ever expect it to get this high, but just in case" > > value, rather than a "this is how many hosts we really think > > we'll have". > > ... the cable tv estimate of E10 homes, with 2 orders of magnitude to > get us E12 seems reasonable as the total number of 'leaf-networks' in > the world. This number includes not only homes but offices, factories, > cars, boats, planes, trains, etc etc etc. > > Where did E15 "end nodes" come from? Well, how many, on average, end > nodes will there be per leaf network? 10? 100? 1000? Well, 10 seems > too small, (for the world-wide average), 1000 seems too big. 100 is > probably about right -- and when you consider that there are 2-3 > million estimated end nodes on the Internet, with something like > 30,000 networks, 100 end-nodes/network seems even more better. Add an > order of magnitude for safety and you get 1000 nodes/network or E15 > nodes... > So, the number E15 already has several good conservative engineering margins of error built in, first at the networks, and then at the nodes. If we already have these margins of error in our estimate, why do we need ever larger margins to hedge the margins? Where does it stop? E15 fits very easily within 2**64, with yet another margin of 16,000, just for power of 2 boundaries. Totalling the margins gives us a 1,600,000 margin of error. Any other area of engineering would scoff at designing at these margins. It would not be cost effective, even when designing a 100 year bridge. Are we collectively that incompetent? This is a 30 year design. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 06:05:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02680; Tue, 21 Jun 1994 06:05: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 GAA08879; Tue, 21 Jun 1994 06:05:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA08865; Tue, 21 Jun 1994 05:49:27 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29153; Tue, 21 Jun 1994 04:42:21 +1000 (from valdis@black-ice.cc.vt.edu) Received: (valdis@localhost) by black-ice.cc.vt.edu (8.6.8.1/8.6.7) id OAA21949; Mon, 20 Jun 1994 14:42:15 -0400 Message-Id: <199406201842.OAA21949@black-ice.cc.vt.edu> To: bsimpson@MorningStar.Com Cc: big-internet@munnari.OZ.AU Subject: Re: Margins In-Reply-To: Your message of "Mon, 20 Jun 1994 16:26:57 EST." <2727.bill.simpson@um.cc.umich.edu> From: Valdis.Kletnieks@vt.edu Date: Mon, 20 Jun 1994 14:42:14 +22306356 Sender: valdis@black-ice.cc.vt.edu On Mon, 20 Jun 1994 16:26:57 EST, you said: > If we already have these margins of error in our estimate, why do we > need ever larger margins to hedge the margins? Where does it stop? > > Totalling the margins gives us a 1,600,000 margin of error. Any other > area of engineering would scoff at designing at these margins. It > would not be cost effective, even when designing a 100 year bridge. > > Are we collectively that incompetent? This is a 30 year design. No, it's just that a civil engineer who builds a bridge that is rated for carrying up to 10,000 40-ton trucks going at 65 miles an hour a day *knows* that he doesn't have to worry about 10,000,000 trucks a day, or 40,000 ton trucks, or trucks that travel at 65,000 miles an hour.. I expanded by a factor of 1000. What is the average top-end bandwidth now? FDDI at 100Mbits? What was the average top-end bandwidth 30 years ago? Was 9600 baud available off-the-shelf in 1964? Figure the ratios yourself.... /Valdis From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 06:12:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01177; Tue, 21 Jun 1994 05:25: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 FAA08835; Tue, 21 Jun 1994 05:25:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA08821; Tue, 21 Jun 1994 05:23:58 +1000 Precedence: list Received: from pern.cc.purdue.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01024; Tue, 21 Jun 1994 05:23:53 +1000 (from smb@pern.cc.purdue.edu) Received: from localhost by pern.cc.purdue.edu (4.1/Purdue_CC) id AA03324; Mon, 20 Jun 94 14:23:49 EST Message-Id: <9406201923.AA03324@pern.cc.purdue.edu> To: big-Internet@munnari.OZ.AU Cc: "Scott M. Ballew" Subject: Locality of reference (was re: variable length addresses) Date: Mon, 20 Jun 1994 14:23:48 -0500 From: smb@pern.cc.purdue.edu ("Scott M. Ballew") Greg Minshall wrote: > And, in general, you are ignoring that the predominant use of a LAN is to > retrieve information from that LAN; the predominant use of a campus net is > to retrieve information from that campus network; etc. I have seen several claims regarding current locality of reference of network traffic used to predict that future network usage will all be equally local (for any given definition of local). After reading this for the umpteenth time, I began to wonder whether locality of network usage is reality because of the way people use things, or because of current limitations in our network technology (or costs). Consider if a nonlocal access were as "inexpensive" as a local access. Why would anyone pay the cost to localize some information (through caching or replication)? If it is really as cheap for me to retrieve a piece of information from Europe as it is from down the hall, why should I expend the local resources to store it down the hall? I claim that if we somehow stumble into a future where remote access to information is as cheap as local access, then locality of reference will disappear from the network. It seems somewhat short-sighted to continue to argue for or against some design aspect based on a presumed future locality of reference. Scott M. Ballew Purdue Data Network From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 08:49:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04315; Tue, 21 Jun 1994 06:45: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 GAA08954; Tue, 21 Jun 1994 06:45:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA08951; Tue, 21 Jun 1994 06:40:17 +1000 Precedence: list Received: from mailhub.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02076; Tue, 21 Jun 1994 05:54:13 +1000 (from john@iastate.edu) Received: from pooh.cc.iastate.edu by mailhub.iastate.edu id AA16325; Mon, 20 Jun 1994 14:54:14 -0500 Received: by pooh.cc.iastate.edu; id AA10482; Mon, 20 Jun 1994 14:54:02 -0500 Message-Id: <9406201954.AA10482@pooh.cc.iastate.edu> Cc: big-Internet@munnari.OZ.AU Subject: Re: Locality of reference (was re: variable length addresses) In-Reply-To: Your message of Mon, 20 Jun 1994 14:23:48 -0500. <9406201923.AA03324@pern.cc.purdue.edu> Date: Mon, 20 Jun 1994 14:54:00 CDT From: John Hascall smb@pern.cc.purdue.edu ("Scott M. Ballew") wrote: > Greg Minshall wrote: > > And, in general, you are ignoring that the predominant use of a LAN is to > > retrieve information from that LAN; the predominant use of a campus net is > > to retrieve information from that campus network; etc. > I have seen several claims regarding current locality of reference of > network traffic used to predict that future network usage will all be > equally local (for any given definition of local). After reading this > for the umpteenth time, I began to wonder whether locality of network > usage is reality because of the way people use things, or because of > current limitations in our network technology (or costs). > Consider if a nonlocal access were as "inexpensive" as a local access. > Why would anyone pay the cost to localize some information (through > caching or replication)? If it is really as cheap for me to retrieve > a piece of information from Europe as it is from down the hall, why > should I expend the local resources to store it down the hall? Unless IPng is somehow going to use sub-space routing :) .. presumably because you want to get it faster. John From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 09:06:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09215; Tue, 21 Jun 1994 09:06: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 JAA09089; Tue, 21 Jun 1994 09:05:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09070; Tue, 21 Jun 1994 08:53:44 +1000 Precedence: list Received: from tigger.cc.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06048; Tue, 21 Jun 1994 07:43:50 +1000 (from john@iastate.edu) Received: by tigger.cc.iastate.edu with sendmail-5.65 id ; Mon, 20 Jun 1994 16:43:45 -0500 Message-Id: <9406202143.AA27015@tigger.cc.iastate.edu> To: smb@pern.cc.purdue.edu ("Scott M. Ballew") Cc: big-Internet@munnari.OZ.AU Subject: Re: Locality of reference (was re: variable length addresses) In-Reply-To: Your message of Mon, 20 Jun 1994 16:24:14 -0500. <9406202124.AA03816@pern.cc.purdue.edu> Date: Mon, 20 Jun 1994 16:43:44 CDT From: John Hascall > > smb@pern.cc.purdue.edu ("Scott M. Ballew") wrote: > > > Consider if a nonlocal access were as "inexpensive" as a local access. > > > Why would anyone pay the cost to localize some information (through > > > caching or replication)? If it is really as cheap for me to retrieve > > > a piece of information from Europe as it is from down the hall, why > > > should I expend the local resources to store it down the hall? > > > > Unless IPng is somehow going to use sub-space routing :) .. > > presumably because you want to get it faster. > > You are assuming that local bandwidth will always be significantly > greater than remote bandwidth, or that the average person will care. Bandwidth may (will) increase, the speed of light is unlikely to. Imagine that glorious day in the future when I have 1GB/s all the way to Europe. Imagine further that a 1MB file over there strikes my fancy. It could very well be that retrieving that file will take 201 mSec. 100 mS for my request to get there, 1 mSec for the transfer which takes another 100 mS to get back here. On the otherhand if the file is just down the road 100 miles or so, it might take 3 mSec. Imagine further that this is some gee-whiz son-of-WWW app with 50 of these things on a page. 10 seconds vs. 150 mS. John From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 09:45:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10678; Tue, 21 Jun 1994 09: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 JAA09186; Tue, 21 Jun 1994 09:45:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA09172; Tue, 21 Jun 1994 09:31:59 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06638; Tue, 21 Jun 1994 07:59:13 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA01498; Mon, 20 Jun 94 15:01:19 -0700 Date: Mon, 20 Jun 94 15:01:19 -0700 From: Eric Fleischman Message-Id: <9406202201.AA01498@atc.boeing.com> To: Christian.Huitema@sophia.infria.fr, big-internet@munnari.OZ.AU Subject: Re: assignment efficiency Dear Christian Huitema (and the SIPP Working Group), This note is in response to your statement below to Brian Carpenter. >The requirement put forward by Boeing puzzles me. That they need five level of >addressing hierarchy for their internal network seems bizarre when the whole >telephone network of France only uses 3 (nation, slice of 10000 numbers, >number). I have not looked at their particular problem though, and have no way >to assess the cost of alternate solutions. But I would be extremely surprised >to learn that no other plan would be conceivable, either by using a different >hierarchy, or by assigning variable bit lengths to different branches of the >hierarchical tree, or by combining a relatively flat addressing with the use >of source routes. Comparing addressing of telephones to data communications is not valid. Telephony addressing is much denser than data communications addressing. It uses very different technologies. The administration and forwarding technologies are very different from each other. The requirements of the two are very different from each other. It is apples and oranges. Thus, if you want to understand the network addressing needs of large multinationals by looking at the French telephone system, you will come out with some rather "peculiar" results. In any case, the issues affecting the need for addressing [and routing] hierarchy are complex for large multi-national corporations with extensive world-wide business dealings. The directions of an addressing architecture are in many ways a reflection of ones underlying assumptions. One assumption of the following is that the corporation will have a single address space. This, of course, is not the only alternative. Indeed, alternatives exist at many levels but each have architectural implications. In any case, I believe that the following assumptions with the following characteristics must be permissible within IPng addressing architecture. For this reason I stated that it is my assumption that an IPng addressing requirement is that the following structure can be supported. The following POTENTIAL layers of addressing hierarchy may be discerned. It is my belief/hope that in some cases some of these layers can be integrated into a single layer in an effort to try to reduce the layers of hierarchy and the resulting addressing sparseness as much as possible. Thus, I suggested 5 layers of hierarchy when the actual number of potential layers is greater. Of course, things may be combined in different ways, but 5 layers seemed to me to be a reasonable number as a starting point for discussion. In any case, the potential layers of hierarchy are as follows: 1) Continent: we currently have private links to every continent (well, probably not Antartica). I am not aware of the actual number of private links from Puget Sound to remote sites overseas but it is a VERY large number. For example, we must be able to address virtually every airport at which any of our planes can land -- with the possible exception of some of the dirt strips in the jungles which may be infrequently serviced by us via portable satellite communications. We also communicate with virtually every airline in the world and (potentially, I believe) the governments as well. We also have literally hundreds of corporations which are our suppliers and business partners -- again widely distributed throughout the world. I am sure that I am overlooking things, but our private world-wide communications are mind-bogglingly extensive. It is not likely that we would use the Internet for much of these communications due to security limitations of the Internet -- though increasingly many of these sites are beginning to have Internet connectivity so perhaps this may change somewhat. 2) Major Region within a continent. See above paragraph for size and scope. In my mind I joined together 1 & 2 into a single layer in which a few thousand regions potentially need to be addressed. However, I doubt my own "educated guess" number fearing that it is far too low. 3) Cities within a region. For example, in the Puget Sound region in which I work we have maybe like 40 cities in this small region which have substantial Boeing sites and who knows how many cities with other sites of lesser stature. If you want to make "regions" non-geographically based (e.g., call our Portland, Oregon or Spokane, Washington or Moses Lake, Washington sites as part of Puget Sound) then the number is much, much greater. 4) Campuses within a city. We can potentially have several sprawling campuses within a city and an indeterinate number of lesser sites and stand-alone buildings as well. 5) Buildings within a Campus. Some of our campuses are immense containing literally hundreds of buildings. No exaggeration. 6) Networks and subnetworks within a building. Boeing has some immense buildings. In fact, the largest building in the world by volume is a Boeing building in Everett. Some of these buildings are mind-boggling big. One which comes to mind appears to me to stretch a few kilometers in length. It is simply unbelievable. Even if you see it, it is doubtful if you can believe it. I know that MY mind still can't believe it and I've seen it several times. Note that I assume that the distinction between networks and subnetworks will go away. If not, then make this two potential layers. In any case, some of these buildings can consume a Class B and then go back for seconds. 7) Individual Hosts and devices within a subnetwork. Having said the above, I doubt if you can usefully use this info. That is because the chore/cost of administering, maintaining, and supporting such a space are not being addressed. As Brian Carpenter said, "human factors" are key to understand these issues. I have little hope that I can adequately explain this subject to the uninitiated in a compelling fashion. Certainly, any attempt by outsiders to coalesce these potential layers into as few as possible will be meaningless and adsurd. Any such coalescence simply must account for the routing topography, tarrif and legal issues, and other related info not available to outsiders. The bottom line is that 5 layers of hierarchy are not unreasonable. It is my opinion that any addressing schema which can't support at least that many levels is inadequately constrained from meeting the evolving needs of the Internet community as a whole. Are not networks expanding, becoming universally larger and more complex? Even if you could demonstrate that we don't need so many levels of hierarchy today, can you really claim that we won't need them ten years from now? [Why can't we end users just be believed when we try to explain the view we see from our knot-hole? Isn't the Internet being designed to meet our needs too? Tut tut.] Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 12:28:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03591; Tue, 21 Jun 1994 06:25: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 GAA08922; Tue, 21 Jun 1994 06:25:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA08906; Tue, 21 Jun 1994 06:15:42 +1000 Precedence: list Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03136; Tue, 21 Jun 1994 06:15:35 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id NAA26214; Mon, 20 Jun 1994 13:12:35 -0700 Date: Mon, 20 Jun 1994 13:12:35 -0700 From: Tony Li Message-Id: <199406202012.NAA26214@lager.cisco.com> To: kre@munnari.OZ.AU Cc: big-internet@munnari.OZ.AU In-Reply-To: Robert Elz's message of Tue, 21 Jun 1994 00:54:42 +1000 <23722.772124082@munnari.OZ.AU> Subject: Why variable length? Robert, Tony, I think you're reading more into my suggestions than that which I am making. I'm not claiming that network design is easy, or can be solved simply by some magic software, that still needs to be done the hard way. Just that once the network is designed it can be numbered fairly easily. Ok, that I'll agree with. How do you propose that we do the design so that even Joe Site Network Manager gives us 15% utilization. Handling aggregation and allowing for redundant nets to be (partly) partitioned (full partitioning is no problem) is difficult, I agree, so simply err on the conservative side, and don't aggregate anywhere that's possible. This clearly not a tractable philosophy. Now routing within the site no longer scales. Sites that need more can hire an expert (from their friendly router vendor probably) and have it done properly. I think you should take it as axiomatic that they won't realize that they need it until after they've discovered that their routers are falling over. Similarly, administrative breakdowns need to be done by the organisation concerned, if it was anything else it wouldn't be administrative - once that breakup is done, the numbering is simply applied to each part separately, the results of that are input to the same algorithm which will then number the higher level. Its true that addressing today is an art - that's partly because it needs to be made right first time, and that involves much crystal ball gazing (ie: expert analysis). But once we have auto renumbering this is less important - if an initial attempt proves to be less than ideal, simply do it all again and renumber. Sometimes brute force can be effective. Detecting that your addressing efficiency is too low for the remainder of the network is non-trivial. External requests to repair this will likely be met with extremely rude responses. Tony From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 12:33:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12184; Tue, 21 Jun 1994 10:25: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 KAA09241; Tue, 21 Jun 1994 10:25:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA09227; Tue, 21 Jun 1994 10:19:21 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11889; Tue, 21 Jun 1994 10:18:59 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA16020; Mon, 20 Jun 94 17:21:01 -0700 Date: Mon, 20 Jun 94 17:21:01 -0700 From: Eric Fleischman Message-Id: <9406210021.AA16020@atc.boeing.com> To: big-internet@munnari.OZ.AU Subject: Don't correct a fool Dear Brian, I fear that a certain percentage of our IETF community has a different view of what a "market" is than either you or I do. I am also given the distinct impression that end users and our viewpoint are not valued or understood by these individuals and that they would vastly prefer it if we would just simply "go away" so that they could play their little games without the distraction of our viewpoint. I don't think these people understand -- or CAN understand -- the fact that unless us corporate users can buy into IPng, IPng is dead. Ditto if any other major community also can not buy into IPng: IPng simply has to be a consensus based process which ALL communities can buy into. Unfortunately, these individuals have also not displayed an inclination to listen to others nor to learn from their experience and wisdom. I am reminded of the proverb which warns one not to correct a fool. One should not correct a fool because the fool will spurn the correction. Rather, we are instructed to correct a wise person because the wise person will value the correction and thank us for it. I hope that we ouselves are wise men and that that we are correctly valuing the insight and the experience we are fortunately receiving from others on this list. However, I think that it is unreasonable to expect all of our community to have a similar mindset -- unfortunately. Let us hope that the community as a whole has more sense than this subset of our number. If not, we are simply wasting our time and would be wiser if we spend our time in other more profitable pursuits. Sincerely yours, --Eric Fleischman >From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) >Message-Id: <9406201009.AA09303@dxcoms.cern.ch> >Subject: Re: Assignment Efficiency >To: bsimpson@morningstar.com >Date: Mon, 20 Jun 1994 12:09:33 +0200 (MET DST) >Cc: big-internet@munnari.oz.au > >Bill, > >I am getting fed up with the way you refuse to acknowledge the actual >request made by the few corporate network managers who happen to be >active on these lists. The actual request is not for "2**48 addresses >to be assigned". It is for "enough address bits to allow a sparse >numbering plan". You are arguing that address bytes are expensive and >should be minimised. We are arguing (for a variety of reasons >that have been beaten to death by now) that WE, the paying customers >for large quantities of distributed computing product, WANT sparse >address spaces. A compromise at 16 bytes has been proposed. > >Well, as I said, I'm fed up with this argument. If you want to ignore >a market message, fine. > > Brian From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 12:43:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09514; Tue, 21 Jun 1994 09:14: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 JAA09119; Tue, 21 Jun 1994 09:14:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA09067; Tue, 21 Jun 1994 08:51:26 +1000 Precedence: list Received: from pern.cc.purdue.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05465; Tue, 21 Jun 1994 07:24:28 +1000 (from smb@pern.cc.purdue.edu) Received: from localhost by pern.cc.purdue.edu (4.1/Purdue_CC) id AA03816; Mon, 20 Jun 94 16:24:15 EST Message-Id: <9406202124.AA03816@pern.cc.purdue.edu> To: John Hascall Cc: big-Internet@munnari.OZ.AU, "Scott M. Ballew" Subject: Re: Locality of reference (was re: variable length addresses) In-Reply-To: Your message of "Mon, 20 Jun 1994 14:54:00 CDT." <9406201954.AA10482@pooh.cc.iastate.edu> Date: Mon, 20 Jun 1994 16:24:14 -0500 From: smb@pern.cc.purdue.edu ("Scott M. Ballew") > smb@pern.cc.purdue.edu ("Scott M. Ballew") wrote: > > Consider if a nonlocal access were as "inexpensive" as a local access. > > Why would anyone pay the cost to localize some information (through > > caching or replication)? If it is really as cheap for me to retrieve > > a piece of information from Europe as it is from down the hall, why > > should I expend the local resources to store it down the hall? > > Unless IPng is somehow going to use sub-space routing :) .. > presumably because you want to get it faster. You are assuming that local bandwidth will always be significantly greater than remote bandwidth, or that the average person will care. We regularly see our (undisciplined) users retrieving large binary files via FTP (or HTTP) from Europe when a copy exists any number of places in the US. In these cases, there is a clear performance advantage to the user to access the local (US) copy, but they still insist on retrieving the remote (European) copy. Why? Primarily, I believe, it is ingorance, but often it is that the time it takes to get the file from Europe to the local machine is still dwarfed by the time it takes them to tranfer it via, for example, kermit at 2400 bps (or even 14.4kbps) to their personal machine at home. All I was attempting to point out (and perhaps badly, at that) was that locality of reference in our current networks is an effect of current constraints, not an immutable fact. As bandwidth continues to get cheaper, the definition of "local" will tend to get larger. Scott From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 12:47:36 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13769; Tue, 21 Jun 1994 11:05: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 LAA09285; Tue, 21 Jun 1994 11:05:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA09271; Tue, 21 Jun 1994 10:54:23 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13397; Tue, 21 Jun 1994 10:54:15 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA23928; Mon, 20 Jun 94 18:53:11 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB08698; Mon, 20 Jun 94 17:49:59 PDT Date: Mon, 20 Jun 94 17:49:59 PDT Message-Id: <9406210049.AB08698@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Christian Huitema From: Greg Minshall Subject: Re: Assignment Efficiency Cc: big-internet@munnari.OZ.AU Christian, >The requirement put forward by Boeing puzzles me. That they need five level of >addressing hierarchy for their internal network seems bizarre when the whole >telephone network of France only uses 3 (nation, slice of 10000 numbers, >number). Actually, i think the best argument for *fixed* length addresses is that there is (going to be) a "phone company" to which everyone will hook up and will provide address management and routing for all (but the biggest) customers. If we had such a phone company (which we don't), then the case for fixed length is stronger (though, even the phone company seems to need to add bits here and there). Greg From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 12:49:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09638; Tue, 21 Jun 1994 09:16: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 JAA09134; Tue, 21 Jun 1994 09:15:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA09086; Tue, 21 Jun 1994 09:03:57 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01871; Tue, 21 Jun 1994 05:46:48 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Mon, 20 Jun 1994 15:45:58 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Mon, 20 Jun 1994 15:45:58 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA08503; Mon, 20 Jun 94 15:44:08 EDT Date: Mon, 20 Jun 94 15:44:08 EDT Message-Id: <9406201944.AA08503@mailserv-D.ftp.com> To: bsimpson@MorningStar.Com Subject: Re: Margins From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 9984 Bill, First of all, you keep talking about enumeration of 10E15 elements. You are right, 10E15 elements can be enumerated in 64 bits. However, enumeration assumes 'dense' use of the space. How dense the space is used is going to depend on what we actually are talking about. If we are talking about topologically sensitive information (sometimes known as a locator) then the a certain pattern of use will prevail. If we are talking about uniquely naming the elements of the network (sometimes known as EIDs) then another pattern of use will prevail. If we are talking about something that combines both the unique name and the topological information (sometimes known as an IPv4 address), then a third pattern of use will prevail. Unique Names ============ These will be administratively assigned. It might be by the manufacturer of a device. More likely it will be by the owner of the device. I imagine that these will be dealt with in an administrative hierarchy. This might be geographic, it might not. I would recommend that it closely follow the hierarchy used for domain names. Why? Simple. I forsee that there may well be many attempts to map between domain names and unique names (in both directions) and this mapping would be facilitated by having the two follow a similar hierarchy. Also, the domain hierarchy is an existing hierarchy that seems to work relatively well and since the issues surrounding unique names are similar to domain names -- well, if the problems are similar, then it should not be surprising that the solutions are also similar... I have not given the issue of assigning Unique Names much thought. Using IEEE 802 numbers might not be very good. 802 numbers are 6 bytes long, leaving 2 bytes for 'additional' administrative structure. I am not sure that this is enough, even if we simply 'enumerate' the assigning entities (i.e. there might be more than 65536 entities that wish to assign numbers....). If structure is added to ease the inverse DNS lookups then things are even worse. I'd imagine that there would be 1 or 2 levels of 'goop' at the top of the hierarchy: sort of similar to the .com or .edu. stuff at the top of DNS. Then there would be the true assigning entity (sort of "ftp" of "ftp.com") followed by a 0-2 of internal levels and then of course, the final node. So we get anywhere from 3 to 6 levels of assignment hierarchy in the number. How many bytes per level? I don't know. I'd guess 1 or 2 would be just fine (giving a range of 3-12 bytes of uniqe name). So, 8-bytes would probably be ok. 16 bytes certainly should be. 16 bytes would also allow additional administrative structure to be placed into these names -- perhaps allowing one to embed ieee 802 numbers in there, or ipx addresses and so on. I do not think that these will be allocated as simple blocks (e.g. ftp Software gets numbers 28,863,218 -> 28,863,861 or whatever). This would make it effectively impossible to use the unique name in a dns query. Topological Information ======================= These are not administratively assigned. These things are what the routing subsystem uses in determining the topology. The closer that the internal structure of these things is an analog of the network's topological structure, the less resources the routing subsystem will require. As an aside, consider the reverse case. If there is absolutely 0 correlation between this number and the topological structure of the network then what you have is, in effect, a bridged network where the topology management subsystem must globally keep track of the location of every individual node of the network. I don't think that anyone is suggesting that we make the Internet of 2010 be nothing more than a huge bridged Ethernet... As a network grows bigger and more complex, in order to efficiently manage the network topology and to select paths through that topology, you need to use information that more closely represents that topology. You need things that, less and less, simply identify a node, and more and more tell you where that node is. So, the question is what amount of topology needs to be carried around in these things to efficiently deduce the network structure, and then locate paths through that structure for a given packet. This sometimes is known as aggregation -- where you aggregate, or combine, information about many end nodes into a single datum that the routing system uses.In IPv4 we currently do this to one or two levels (end nodes into subnets, subnets into networks). I've given this one a bit of numerical thought. I would guess that each element of The Internet will combine, or aggregate about 100 'contained' elements, on average. If we assume that there are E12 leaf networks, this implies 6 levels of hierarchy. The question, now, is how many bits will be required for this. Obviously it would be at least 7. However, I do not see network operators gleefully accepting element boundaries on bit-boundaries. I think that, as a matter of psychology or user-friendliness, these have to be on byte boundaries. So one byte it would be. But 1 byte gives only a margin of 2.5. I expect that there will be some areas that want to aggregate more than 255 elements together (eg one of our customers has a single bridged ethernet of ~50,000 nodes running ip...). I'd imagine that if I told a network operator that things will pretty much just fit into 1 byte, they'd be very unhappy. If I gave them 2 bytes per level, things would go much better. (I'd like to suggest 12 bits, but I've made the quantum a single byte). So, 6 levels at 2 bytes per level is 12 bytes for topologically sensitive location that gets you down to the 'leaf' network (one of those E12 things). Now, you have to add information that identifies the actual destination host. This could be the Unique Name, in which case it adds 0 to the topological information (which is good!). This is my preference. However, if this is not possible (for any reason) then there is a question of how many end-nodes there will be per leaf-network. The derivation of the E15 number, below, suggests that 1000 is a good guess; more than one byte, less than 2. If we have 1-byte quanta, this means 2 bytes. So, we are talking 12-14 bytes of topological information. Now, the question is how much one trusts the estimates of aggregations that were made in this derivation, as well as the 'safety margins' built into it. I do not think that we can make things smaller than this and still maintain the safety for getting, adequately, to E12 leaf networks. Note well, I am not talking about the safety of the derivation of E12, I am talking about the margin in calculating how many bytes are needed to represent E12 leaves. I do not imagine making it smaller than 12 bytes -- which implies that 8 is simply not useful in this scenario. 16 is probably a reasonable number (keeping multiples of 4 bytes and all that). Note that this does not increase things by 2**32 -- going from 12 to 16 adds four bytes, at two bytes per level of hierarchy we get 2 levels of hierarchy, and at 100:1 aggregation per level we get a factor of 10,000, not 4 billion... (no argument that this is horrible efficiency -- but simply stating that it is horrible efficiency and therefore won't happen is, well, naive to put it politely). 16 bytes is probably ok. But I assume that we will make mistakes or that an assumption I've made is wrong. I'd like the option for IPng to be simply and easily migrated to >16 bytes. From an ultra- conservative point of view, 24 is probably ok, 32 should be more than enough. > From: "William Allen Simpson" > > Thank you, Frank. > > > From: kasten@ftp.com (Frank Kastenholz) > > Date: Mon, 20 Jun 94 10:15:55 EDT > > > From: Robert Elz > > > Date: Fri, 17 Jun 1994 18:03:10 -0700 > > > From: Tony Li > > > > > > I guess I disagree with the entire philosophy of designing > > > to just meet the design parameters and no farther. > > ... > > > > > It all depends how the parameter was set. I believe the > > > "must handle 1e15 hosts" requirement is set at a "we don't > > > really ever expect it to get this high, but just in case" > > > value, rather than a "this is how many hosts we really think > > > we'll have". > > > > ... the cable tv estimate of E10 homes, with 2 orders of magnitude to > > get us E12 seems reasonable as the total number of 'leaf-networks' in > > the world. This number includes not only homes but offices, factories, > > cars, boats, planes, trains, etc etc etc. > > > > Where did E15 "end nodes" come from? Well, how many, on average, end > > nodes will there be per leaf network? 10? 100? 1000? Well, 10 seems > > too small, (for the world-wide average), 1000 seems too big. 100 is > > probably about right -- and when you consider that there are 2-3 > > million estimated end nodes on the Internet, with something like > > 30,000 networks, 100 end-nodes/network seems even more better. Add an > > order of magnitude for safety and you get 1000 nodes/network or E15 > > nodes... > > > So, the number E15 already has several good conservative engineering > margins of error built in, first at the networks, and then at the nodes. > > If we already have these margins of error in our estimate, why do we > need ever larger margins to hedge the margins? Where does it stop? > > E15 fits very easily within 2**64, with yet another margin of 16,000, > just for power of 2 boundaries. > > Totalling the margins gives us a 1,600,000 margin of error. Any other > area of engineering would scoff at designing at these margins. It > would not be cost effective, even when designing a 100 year bridge. > > Are we collectively that incompetent? This is a 30 year design. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 16:57:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20331; Tue, 21 Jun 1994 14:05: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 OAA09448; Tue, 21 Jun 1994 14:05:14 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA09434; Tue, 21 Jun 1994 13:45:39 +1000 Precedence: list Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14044; Tue, 21 Jun 1994 11:16:46 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA10710 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Mon, 20 Jun 1994 21:16:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Mon, 20 Jun 1994 21:16:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 20 Jun 1994 21:16:31 -0400 Message-Id: <199406210116.AA19535@foo.ans.net> To: Eric Fleischman Cc: Christian.Huitema@sophia.infria.fr, big-internet@munnari.OZ.AU Subject: Re: assignment efficiency In-Reply-To: Your message of "Mon, 20 Jun 1994 22:01:19 GMT." <9406202201.AA01498@atc.boeing.com> Date: Mon, 20 Jun 1994 21:16:29 -0400 From: Dennis Ferguson Eric, > Comparing addressing of telephones to data communications is not valid. > Telephony addressing is much denser than data communications addressing. > It uses very different technologies. The administration and forwarding > technologies are very different from each other. The requirements of the > two are very different from each other. It is apples and oranges. Thus, [...] > Having said the above, I doubt if you can usefully use this info. That > is because the chore/cost of administering, maintaining, and supporting such > a space are not being addressed. As Brian Carpenter said, "human factors" > are key to understand these issues. I have little hope that I can > adequately explain this subject to the uninitiated in a compelling > fashion. Certainly, any attempt by outsiders to coalesce these potential > layers into as few as possible will be meaningless and adsurd. Any such > coalescence simply must account for the routing topography, tarrif and legal > issues, and other related info not available to outsiders. Let's pick another point of comparison, then, so perhaps you can articulate the incomprehensible (certainly to me) a bit better. In another note you indicated the scale of this thing you are envisioning: > 2) An ability to potentially address more than 1,000,000 internal IPng > devices in the medium term. [Note, only a subset of these devices will It seems to me there is an operating, already deployed data communications network on which can be addressed (by the best guess I have seen) several times this number of devices. This, of course, is the public Internet. This network also spans all continents (which of course have regions, and cities, and campuses, and so on). It of course has a routing topography, and was built in the face of tariff and legal issues which I have no hope of understanding. Until recently it was built by people who cared very little about profligate consumption of the address space, who for the most part ignored issues of routing hierarchy, had no ability to do anything like automated renumbering or server discovery and had relatively primative routing protocols and technology. And it was built with almost no overall administration and support, most recently by people who were often competitors with little in common other than maybe (just maybe) that a bigger, well-operating global network might be in their common interest. There were no real precedents when this network was built, so there was a lot of learning by trail-and-error, using technology which made recovering from errors a lot more expensive than one might expect it to be in the future. And it was built using about 30 bits of address space and (until a very few months ago) essentially a two tier addressing/routing hierarchy. The fact that you can identify many (7?) layers of potential hierarchy doesn't mean you need to use them, what you need to use is enough abstraction to keep your routers up and happy. > [Why can't we end users just be believed when > we try to explain the view we see from our knot-hole? Isn't the > Internet being designed to meet our needs too? Tut tut.] The problem I have is that you haven't really presented much more than a statement of your beliefs, with not much in the way of technical justification to back them up. I'd be inclined to believe you anyway (and I apologize in advance for not doing so), except that when faced with an apparent choice between your statement of your beliefs about what might be sufficient, and an existance proof for what was already sufficient for a network of this size, I find it difficult to make the leap of faith. You need to articulate why what you are planning is so different from what's been built already, so we can get a technical handle on why you came to this conclusion. Dennis Ferguson From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 17:52:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23622; Tue, 21 Jun 1994 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 PAA09540; Tue, 21 Jun 1994 15:25:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA09526; Tue, 21 Jun 1994 15:15:43 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19853; Tue, 21 Jun 1994 13:51:09 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm012-13.dialip.mich.net (pm012-13.dialip.mich.net [35.1.48.214]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id XAA21521 for ; Mon, 20 Jun 1994 23:50:56 -0400 Date: Tue, 21 Jun 94 03:00:22 GMT From: "William Allen Simpson" Message-Id: <2736.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: addressing elements > From: kasten@ftp.com (Frank Kastenholz) > First of all, you keep talking about enumeration of 10E15 elements. > You are right, 10E15 elements can be enumerated in 64 bits. However, > enumeration assumes 'dense' use of the space. > Not very dense. About 1E10-5. > How dense the space is used is going to depend on what we actually > are talking about. If we are talking about topologically sensitive > information (sometimes known as a locator) then the a certain pattern > of use will prevail. If we are talking about uniquely naming the > elements of the network (sometimes known as EIDs) then another > pattern of use will prevail. If we are talking about something that > combines both the unique name and the topological information > (sometimes known as an IPv4 address), then a third pattern of use > will prevail. > Which is why whenever I am talking about the size of numbers, I am only talking about uniquely naming/numbering entities in the net. This is both heirarchical and dense. You have given us good numbers for estimating the size of these elements. Topologically sensitive information (locator) never was, is not, and is never likely to be heirarchical, and therefore not subject to more than accidental aggregation. Therefore, we need only decide the size of elements which name routing points in the topology. Since we need to number nodes in the network, it makes sense to use the same naming elements for identifying nodes in the topology. As to the rest of your argument (structure and number of levels), this assumes heirarchy in the network topology. There demonstrably is no heirarchy, therefore your level estimates serve only to show us that the SIPP routing header has a likely maximum future size of 6 elements (notwithstanding that Boeing thinks it needs another 5 all for itself). Attempting to create heirarchical numbers for all possible organizations of a mesh network, your level estimates limit us to 6! = 720 address sequence combinations per node, which is a bit beyond the realm of possible human management, particularly since this will change dynamically. Of course, Boeing will need 11!, which is more than I can do in my head. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 19:32:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01675; Tue, 21 Jun 1994 18:45: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 SAA09735; Tue, 21 Jun 1994 18:45:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA09721; Tue, 21 Jun 1994 18:35:46 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29233; Tue, 21 Jun 1994 17:44:45 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA02732; Tue, 21 Jun 1994 09:45:20 +0200 Message-Id: <199406210745.AA02732@mitsou.inria.fr> To: Eric Fleischman Cc: big-internet@munnari.OZ.AU Subject: Re: assignment efficiency In-Reply-To: Your message of "Mon, 20 Jun 1994 15:01:19 PDT." <9406202201.AA01498@atc.boeing.com> Date: Tue, 21 Jun 1994 09:45:18 +0200 From: Christian Huitema Eric, The addressing plans of Boeing should be that of Boeing; you have no more reason to assign addresses to each of your customers or suppliers than you have reasons to assign their telephone numbers. As for airports, isn't SITA addressing every airport worldwide, and in fact every airline booth in every airport, with something like 7 upper case characters addresses? Christian PS. I am in no case speaking for "The SIPP working group". From owner-Big-Internet@munnari.OZ.AU Tue Jun 21 23:45:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12051; Tue, 21 Jun 1994 23:45: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 XAA09998; Tue, 21 Jun 1994 23:45:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA09995; Tue, 21 Jun 1994 23:40:23 +1000 Precedence: list Received: from pern.cc.purdue.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11906; Tue, 21 Jun 1994 23:40:19 +1000 (from smb@pern.cc.purdue.edu) Received: from localhost by pern.cc.purdue.edu (4.1/Purdue_CC) id AA05472; Tue, 21 Jun 94 08:40:14 EST Message-Id: <9406211340.AA05472@pern.cc.purdue.edu> To: John Hascall Cc: big-Internet@munnari.OZ.AU Subject: Re: Locality of reference (was re: variable length addresses) In-Reply-To: Your message of "Mon, 20 Jun 1994 16:43:44 CDT." <9406202143.AA27015@tigger.cc.iastate.edu> Date: Tue, 21 Jun 1994 08:40:13 -0500 From: smb@pern.cc.purdue.edu ("Scott M. Ballew") > > You are assuming that local bandwidth will always be significantly > > greater than remote bandwidth, or that the average person will care. > > Bandwidth may (will) increase, the speed of light is unlikely to. > > Imagine that glorious day in the future when I have 1GB/s all the > way to Europe. Imagine further that a 1MB file over there strikes > my fancy. It could very well be that retrieving that file will > take 201 mSec. 100 mS for my request to get there, 1 mSec for > the transfer which takes another 100 mS to get back here. > > On the otherhand if the file is just down the road 100 miles > or so, it might take 3 mSec. > > Imagine further that this is some gee-whiz son-of-WWW app with > 50 of these things on a page. 10 seconds vs. 150 mS. While I admit that I neglected the affects of latency, I think your other numbers don't pan out. Why in the world would I do these 50 retrievals one at a time rather than send off my 50 requests and then wait for my 50 replies. This would cut the cumulative time down to something more on the order of 250ms vs 52ms. When talking about times this short, I really doubt anyone is going to really notice. I guess where I was headed with this whole thought is that we should not blindly assume that locality of reference will continue (or at least continue to the same degree as current). If we are serious about the Internet being the foundation for the Information Superhighway, then we need to make sure that all parts of it are as efficient as possible on the grounds that we are unlikely to accurately predict future usage patterns based on current and past usage patterns that may very well be the result of constraints that themselves may change. Scott From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 00:14:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12277; Tue, 21 Jun 1994 23:48: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 XAA10013; Tue, 21 Jun 1994 23:48:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA09981; Tue, 21 Jun 1994 23:30:15 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11459; Tue, 21 Jun 1994 23:30:09 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-13.dialip.mich.net (pm002-13.dialip.mich.net [35.1.48.94]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id JAA26605 for ; Tue, 21 Jun 1994 09:30:03 -0400 Date: Tue, 21 Jun 94 12:53:49 GMT From: "William Allen Simpson" Message-Id: <2740.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: assignment efficiency > From: Eric Fleischman > [Why can't we end users just be believed when > we try to explain the view we see from our knot-hole? Isn't the > Internet being designed to meet our needs too? Tut tut.] 1) Because you keep stating "beliefs" without technical justification. 2) Because some of the "requirements" you have recently stated are contrary to the real world. As an example, you stated a "requirement" that IEEE numbers be globally unique. They aren't. Reality check. 3) Because your own numbers conflict between your own messages. You have on one hand a stated "requirement" (June 16) for "more than 1,000,000 internal IPng devices in the medium term". Yet, in this message (Jun 20), you state you only need a couple of class B's for your largest building. You only have one of these buildings, not thousands of these buildings. Reality check. 4) Because you state you "require" (Jun 16): "An ability to have five levels of internal routing hierarchy within our vast international private network IN ADDITION TO whatever levels of routing hierarchy are needed by the world-wide Internet infrastructure. This is among the most patently ludicrous statements I have seen in the IPng debate to date. The current Internet has more than 1,000,000 nodes, and doesn't have 5 levels of routing heirarchy. That they would be "in addition to" the world-wide network only shows the hubris of your statements. Use of "private links" paralleling the Internet does not improve the efficiency of the limited intercontinental bandwidth. I seriously doubt that Boeing laid those seabed links. They are a common resource. Had you shared your links today, as CERN does, you would not be having this problem, and the Internet would already have better connectivity. You should not be surprised that the rest of the Internet is not willing to waste vast amounts of their future bandwidth to accomodate you. 5) Because another end user company, bigger, more sites, more nodes, has already issued a "reality check" on your statements. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 00:14:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13208; Wed, 22 Jun 1994 00:05: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 AAA10049; Wed, 22 Jun 1994 00:05:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA10029; Tue, 21 Jun 1994 23:49:59 +1000 Precedence: list From: bound@zk3.dec.com Received: from inet-gw-3.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09912; Tue, 21 Jun 1994 22:43:41 +1000 (from bound@zk3.dec.com) Received: from xirtlu.zk3.dec.com by inet-gw-3.pa.dec.com (5.65/27May94) id AA20253; Tue, 21 Jun 94 05:31:56 -0700 Received: by xirtlu.zk3.dec.com; id AA22800; Tue, 21 Jun 1994 08:31:48 -0400 Message-Id: <9406211231.AA22800@xirtlu.zk3.dec.com> To: Eric Fleischman Cc: big-internet@munnari.OZ.AU Subject: Re: Don't correct a fool In-Reply-To: Your message of "Mon, 20 Jun 94 17:21:01 PDT." <9406210021.AA16020@atc.boeing.com> Date: Tue, 21 Jun 94 08:31:42 -0400 X-Mts: smtp Eric, >I fear that a certain percentage of our IETF community has a different >view of what a "market" is than either you or I do. I am also given the >distinct impression that end users and our viewpoint are not valued or >understood by these individuals and that they would vastly prefer it if >we would just simply "go away" so that they could play their little games >without the distraction of our viewpoint. I don't think these people >understand -- or CAN understand -- the fact that unless us corporate users >can buy into IPng, IPng is dead. Ditto if any other major community also >can not buy into IPng: IPng simply has to be a consensus based process which >ALL communities can buy into. Unfortunately, these individuals have also >not displayed an inclination to listen to others nor to learn from their >experience and wisdom. Please don't think that because of a few individual responses on this mailing list its the majority view of the community or that your input is not very important. I do this too but have decided that all discussion is good even if I don't like it or 'think' some of the replies are coming from a very focused black hole. For example you have convinced me to change my thinking on how hiearchial addressing must be approached. Most of all this latest round of discussions at times has been heated by the passion to get this done and figured out. This is good as it produces hard work and serious analysis (EMOTION + LOGIC + TALENT). One suggestion I made to someone who asked me was how to approach this group discussion. What I told this person is I believe you cannot say here is the answer and expect folks to say OK lets go for it. It has to have discussion and its that discussion that causes momentum and consensus. Then someone goes and writes a draft and hopefully some code too. For example I think Tony and Kre's recent discussions are going somewhere very positive and forward. This will turn into some kind of architecture support structure is my guess (at least for me). So its the discussion not the result for awhile anyway. And there has been NO RESULT for any of this topic. We are still working on it. But I think you have been heard loud an clear (and Brian and Bob M. too). Its true no ones knows your using the fastest 64bit microprocessor in the world while on the Internet but there is a good chance your a human being who will make mistakes, display emotion, question anothers idea, let your ego get the better of you, etc.. etc.. PEACE, /jim From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 01:09:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15609; Wed, 22 Jun 1994 01:05: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 BAA10156; Wed, 22 Jun 1994 01:05:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA10151; Wed, 22 Jun 1994 00:59:21 +1000 Precedence: list Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15352; Wed, 22 Jun 1994 00:59:07 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA13778 (5.65c/UK-2.1-940401); Tue, 21 Jun 1994 11:03:32 -0400 From: Gary Scott Malkin Date: Tue, 21 Jun 1994 11:03:32 -0400 Message-Id: <13778.199406211503@atlas.xylogics.com> To: Greg_Minshall@novell.com Cc: big-internet@munnari.OZ.AU In-Reply-To: Greg Minshall's message of Mon, 20 Jun 94 17:49:59 PDT <9406210049.AB08698@WC.Novell.COM> Subject: Assignment Efficiency > If we had such a phone company (which we don't), then the case for fixed > length is stronger (though, even the phone company seems to need to add > bits here and there). Actually, the phone company is suffering from the fact that they've traditionally used a fixed length address as a variable one. The little tricks they used to identify area codes is starting to fail because they have run out of them and now require long distance calls to carry the country code. I think this is a good argument against 8-16 variable length addressing. And if the phone company can get by with 10**11 numbers, we should be able to get by with 256**16! ---------------------------------------------------------------------- Gary Malkin Cheap, Fast, Good (617) 272-8140 Pick two! From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 03:05:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19380; Wed, 22 Jun 1994 03:05: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 DAA10290; Wed, 22 Jun 1994 03:05:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA10260; Wed, 22 Jun 1994 02:45:17 +1000 Precedence: list Received: from weizmann.weizmann.ac.il by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18850; Wed, 22 Jun 1994 02:45:06 +1000 (from VSARIEL@WEIZMANN.WEIZMANN.AC.IL) Message-Id: <9406211645.18850@munnari.oz.au> Received: from WEIZMANN.WEIZMANN.AC.IL by WEIZMANN.weizmann.ac.il (IBM VM SMTP V2R2) with BSMTP id 5208; Tue, 21 Jun 94 19:44:47 +0300 Received: from WEIZMANN.WEIZMANN.AC.IL (NJE origin VSARIEL@WEIZMANN) by WEIZMANN.WEIZMANN.AC.IL (LMail V1.2a/1.8a) with BSMTP id 3502; Tue, 21 Jun 1994 19:44:47 +0300 Date: Tue, 21 Jun 94 19:44:28 +0300 From: "Ariel T. Sobelman" To: big-internet@munnari.OZ.AU Please subscribe me to this list. Thanks, Ariel T. Sobelman --------------------------------------------------------------------- | Ariel T. Sobelman vsariel@weizmann.BITNET | | Weizmann Institute of Science vsariel@weizmann.weizmann.ac.il | | Rehovot, 76100 Tel: +972-8-343044 | | Israel Fax: +972-8-344102 | --------------------------------------------------------------------- From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 04:25:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22457; Wed, 22 Jun 1994 04:25: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 EAA10407; Wed, 22 Jun 1994 04:25:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA10393; Wed, 22 Jun 1994 04:16:32 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22127; Wed, 22 Jun 1994 04:16:28 +1000 (from solensky@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 21 Jun 1994 14:16:22 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 21 Jun 1994 14:16:22 -0400 Received: from solensky.fenway.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA19156; Tue, 21 Jun 94 14:14:32 EDT Date: Tue, 21 Jun 94 14:14:32 EDT Message-Id: <9406211814.AA19156@mailserv-D.ftp.com> To: ietf@cnri.reston.va.us, big-internet@munnari.OZ.AU Subject: ALE looking for estimates From: solensky@ftp.com (Frank T Solensky) Cc: ipv4-ale@ftp.com Reply-To: ipv4-ale@ftp.com Sender: solensky@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Tue Jun 21 14:14:22 1994] Originating-Client: fenway.ftp.com Content-Length: 6027 The IPv4-ALE working group is chartered to provide an estimate for the amount of time that we've got before the IPv4 address space becomes depleted. Estimates that we've made up to this point have all been based on looking at the historic trends and projecting them out into the future. The problem with this approach, as we've acknowledged many times, is that the trend lines are driven by existing technologies. We haven't been able to factor the impact that other technologies would introduce. After the attached note was forwarded to the IPv4-ALE list, I felt it was time to cast a wider net than we've been using up to this point. If you don't have any estimates yourself but do know of someone who might, please forward this message to them. We'd greatly appreciate receiving any input from those who might have some thoughts on what the needs will be for the following entities who may be getting 'connected' within the next couple of years: - utility companies - airlines (air traffic control systems, in-flight services, etc.) - health care - mobile systems - most especially: "other" Please reply either to the IPv4-ALE list (ipv4-ale@research.ftp.com) or to myself. Thanks in advance.. -- Frank Solensky ~~~~~ most original header lines removed ~~~~~~~~~~~~~~~~~~~~~~~ >From LMB9987@kbct.bems.boeing.com Mon Jun 20 22:44:54 1994 Date: Mon, 20 Jun 1994 19:37:24 -0700 (PDT) From: LMB9987 Resent-To: sob@Harvard.edu Status: R Dear Mr. Bradner, I am behind in my extracurricular (not work related) reading, and when scanning for a particular article, I came across your Internetworking Monitor article regarding the IETF meeting. What caught my eye was the Address Lifetime wg report that 2008 +/- 3 years was their latest estimate to exhaust the TCP/IP address space plus your comment about the electric utilities. It made me start thinking about where this working group is getting their input and what industries are represented. The electric utilities are in fact intending to not only control and manage the utility power grid using router-based, non-proprietary communications, they also expect to read meters and electronically debit bank accounts. I don't think they intend to wait until 2008 since pilots are underway right now. That's one example - The current air traffic control system is based on analog voice radio transmission and because of the saturation in areas of dense population is very bandwidth restricted. The FAA, the national Air Transport Association and the International Air Transport Association are working together to deploy a router-based air-to-ground + ground based network infrastructure called the ATN. The airline's vision includes using router-based, non-proprietary communications for air-traffic control, transmission of maintenance information to their ground facilities prior to landing, two-way digital communications via satellite for overseas flight to get up-to-date weather and traffic information (which will save individual airlines with long overseas flights millions of dollars per year in fuel alone), not to mention in-flight links to reservations (plane, hotel, car rental, etc.), in-flight catalog purchases, entertainment, cabin services, and even inflight office services including email. To remain globally competitive, manufacturing partnerships and supplier connections need to be flexible with sharing of detailed design information, contractual negotiations, and other key business related information exchanged electronically, anywhere in the world. Of course this all requires a highly reliable, scaleable, well-managed and secure global communications infrastructure. The medical community has visions of using LANS to interconnect monitoring equipment at each patient's bed, and doctor's have visions of being able to view this information anywhere (including catscans) , but especially at home in emergency situations. These aren't just visions - various industry trade associations are collaborating and investing in planning and piloting all of the above. While there are many barriers to overcome to achieve these objectives, the primary barrier is any progress in deploying a communications infrastructure that supports these visions, because they all have one thing in common. They don't intend to build individual industry specific infrastructures. They would like to use a combination of public, and private communications facilities, seamlessly integrated with a common global addressing scheme. It's difficult to gage when (or if) any of this will take off. It could be tomorrow. You mention the positive EDI session with new faces. If you attend any trade association meeting, you will discover groups developing plans for email, EDI, standards - both national and international and it sounds to me like only a fraction of them attend IETF meetings. Unfortunately, these industry groups get infrequent coverage by the press since their companies and likewise their associations are conservative by nature and tend to frown on the kind of behavior that seems to grab the interest of the press and make headlines. I'm very curious about the processes and mechanisms used to make projections regarding the growth of a global network infrastructure (which I believe is how the Internet community is portraying the Internet). If you could provide any insight on the basis used for those projections, I would really like to know. In return, I can certainly provide contact information on some of the activities I have mentioned if the information is not well know in the IETF. I receive newsletters from a number of these groups, but have limited time to read them all, so much of it eventually gets roundfiled. Laurie Bride, (206)477-1018, G-2681, 6C-38 Developer Workbench Deployment, LMB9987@KBCT.BEMS.BOEING.COM "In a time of drastic change it is the learners that inherit the future." E. Hoffer From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 04:33:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18877; Wed, 22 Jun 1994 02:45: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 CAA10258; Wed, 22 Jun 1994 02:45:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA10244; Wed, 22 Jun 1994 02:37:57 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16857; Wed, 22 Jun 1994 01:45:12 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA15740; Tue, 21 Jun 94 08:47:13 -0700 Date: Tue, 21 Jun 94 08:47:13 -0700 From: Eric Fleischman Message-Id: <9406211547.AA15740@atc.boeing.com> To: big-internet@munnari.OZ.AU, dennis@ans.net Subject: Re: assignment efficiency Cc: ericf@munnari.OZ.AU Dear Dennis, Thank you for your note clarifying that you did not follow our purported need for substantially larger address space because the 32 bits of IPv4 addresses currently supports more devices than the total amount we hope to eventually support within our private network. The difference, of course, is that IPv4 addressing is broken. It is does not aggregate WITHIN vast private corporate networks. It takes more administrative "care and feeding" than any of the other 22 protocol families we have deployed (well, almost: pre-APPN SNA takes more care and feeding). The granularity of IPv4 networks are either unwieldingly large or far too tiny. The whole IPv4 addressing scheme is NOT designed to work with modern networking -- and does not do so well today. There is no correspondence between the address space and what we are seeking to address either administratively or geographically or via any other system known to mankind. IPv4 addressing is a kludge built upon a kludge. It is simply a bear to work with. More could be said but the conclusion is that IPv4 addressing is broken. Therefore, one of my basic assumptions for IPng addressing was that the numerous factors which make IPv4 so difficult to use within large private networks would be removed. I did not imagine that a class of our community wanted to preserve major broken elements of IPv4 within IPng. If so, why migrate to IPng at all? Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 05:40:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20041; Wed, 22 Jun 1994 03:25: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 DAA10333; Wed, 22 Jun 1994 03:25:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA10317; Wed, 22 Jun 1994 03:11:01 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19631; Wed, 22 Jun 1994 03:10:55 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 21 Jun 1994 13:10:47 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 21 Jun 1994 13:10:47 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA18053; Tue, 21 Jun 94 13:08:57 EDT Date: Tue, 21 Jun 94 13:08:57 EDT Message-Id: <9406211708.AA18053@mailserv-D.ftp.com> To: big-internet@munnari.OZ.AU Subject: Forwarded: I-D ACTION:draft-kastenholz-ipng-criteria-02.txt From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Content-Length: 3372 Sorry to intrude on the normal rants of the list, but this may be of some passing interest.... Return-Path: Mime-Version: 1.0 To: IETF-Announce:;@IETF.CNRI.Reston.VA.US; From: Internet-Drafts@CNRI.Reston.VA.US Reply-To: Internet-Drafts@CNRI.Reston.VA.US Subject: I-D ACTION:draft-kastenholz-ipng-criteria-02.txt Date: Tue, 21 Jun 94 11:28:39 -0400 X-Orig-Sender: cclark@CNRI.Reston.VA.US Content-Type: Multipart/Mixed; Boundary="NextPart" Content-Length: 2702 --NextPart A Revised Internet-Draft is available from the on-line Internet-Drafts directories. Title : Technical Criteria for Choosing IP: The Next Generation (IPng) Author(s) : F. Kastenholz, C. Partridge Filename : draft-kastenholz-ipng-criteria-02.txt Pages : 48 Date : 06/20/1994 This memo presents a set of criteria that the authors' believe should be used to help evaluate protocols being proposed for adoption as the next generation of IP. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-kastenholz-ipng-criteria-02.txt". Internet-Drafts directories are located at: o US East Coast Address: ds.internic.net (198.49.45.10) o US West Coast Address: ftp.isi.edu (128.9.0.32) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mailserv@ds.internic.net. In the body type: "FILE /internet-drafts/draft-kastenholz-ipng-criteria-02.txt". For questions, please mail to Internet-Drafts@cnri.reston.va.us. Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ds.internic.net" Content-Type: text/plain Content-ID: <19940620150658.I-D@CNRI.Reston.VA.US> FILE /internet-drafts/draft-kastenholz-ipng-criteria-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-kastenholz-ipng-criteria-02.txt"; site="ds.internic.net"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <19940620150658.I-D@CNRI.Reston.VA.US> --OtherAccess-- --NextPart-- From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 06:08:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23213; Wed, 22 Jun 1994 04:45: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 EAA10437; Wed, 22 Jun 1994 04:45:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA10423; Wed, 22 Jun 1994 04:35:48 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20356; Wed, 22 Jun 1994 03:33:03 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA29972; Tue, 21 Jun 94 10:35:09 -0700 Date: Tue, 21 Jun 94 10:35:09 -0700 From: Eric Fleischman Message-Id: <9406211735.AA29972@atc.boeing.com> To: big-internet@munnari.OZ.AU, sipp@sunroof.eng.sun.com Subject: Shame Cc: ericf@munnari.OZ.AU Dear Bill Simpson: (cc: Big Internet, SIPP) For some time now you have been allegedly quoting me on the B-I and the SIPP lists. Unfortunately, I have NEVER said ANY of the outrageous things which you have repeatedly stated that I have said -- nor had I even imagined them. I realize that you are known for your "dramatic" postings. However, your outrageous misrepresentations and your regular use of "Agumentum ad hominem" and "Argumentum ad adsurdum" arguments within your postings have been a shameful abuse of these lists. That is, the purpose of these lists is for the Internet community to jointly work together to form informed common positions. The Internet is composed of various communities each possessing useful but differing perspectives. These lists serve as a forum by which the whole community can exchange information and perspectives to evolve common consensus- based positions. Abusive mud slinging has no place within these lists. It is counter-productive and contrary to the very purposes of these lists. Thus far I have endured your abuses in silence hoping that by being silent I would not encourage you to persist in your foolishness. Yet silence did not still your acid-laced, dishonest, and abusive postings. Therefore, I want to publicly state the following: The alleged quotations of my postings by Bill Simpson are lies. Bill has knowingly and purposefully misrepresented my statements and beliefs. He has cast dispersions upon my character and integrity as well as the intelligence of my employer by distorting our positions into adsurd charactatures. He has then has regularly reiterated these charactatures of his own invention as statements of fact. I also wish to publicly urge you to please dissist from your dishonest and shameful practices. You are displaying a character which lacks both honor and moral integrity. Sincerely yours, --Eric Fleischman From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 08:33:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25836; Wed, 22 Jun 1994 06:05: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 GAA10520; Wed, 22 Jun 1994 06:05:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA10517; Wed, 22 Jun 1994 06:04:35 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23865; Wed, 22 Jun 1994 05:10:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10591; Tue, 21 Jun 94 15:10:50 -0400 Date: Tue, 21 Jun 94 15:10:50 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406211910.AA10591@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, big-internet@munnari.OZ.AU Subject: Re: Assignment Efficiency Cc: jnc@ginger.lcs.mit.edu From: Christian Huitema By the way, the SIPP loose "source route" are precisely there to provide an escape and a path of evolution. We may not know the details yet, but all works on flexible routing (nimrod, sdrp, idpr, route segments) point towards this type of solution. The "address" may be fixed size, but we will have many of them... I can't speak for the other designs, but the SIPP "source route" probably won't be very useful to Nimrod, where paths are specified more like PIP source routes; i.e. a sequence of "address" elements (which are typically only a byte or two). Noel From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 08:41:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27597; Wed, 22 Jun 1994 07:05: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 HAA10591; Wed, 22 Jun 1994 07:05:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA10577; Wed, 22 Jun 1994 06:46:31 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27208; Wed, 22 Jun 1994 06:46:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11986; Tue, 21 Jun 94 16:46:22 -0400 Date: Tue, 21 Jun 94 16:46:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406212046.AA11986@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: assignment efficiency Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" The current Internet has more than 1,000,000 nodes, and doesn't have 5 levels of routing heirarchy. Really? CIDR was introduced *precisely* because the 3+ (net, subnet(s), host) we had weren't enough. I'm not sure how many layers various parts of the network are using now that CIDR has been deployed (you can't tell just from looking at an address), but I wouldn't be surprised if parts are now using 5. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 09:36:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00836; Wed, 22 Jun 1994 08:45: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 IAA10693; Wed, 22 Jun 1994 08:45:20 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA10679; Wed, 22 Jun 1994 08:34:36 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26281; Wed, 22 Jun 1994 06:19:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11355; Tue, 21 Jun 94 16:18:59 -0400 Date: Tue, 21 Jun 94 16:18:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406212018.AA11355@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bill.simpson@um.cc.umich.edu Subject: Re: addressing elements Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" Topologically sensitive information (locator) never was, is not, and is never likely to be heirarchical, and therefore not subject to more than accidental aggregation. Perhaps I'm misunderstanding what you're trying to say here, but this doesn't make snese to me. The only way to make the overhead costs of routing scale is to not do "flat" routing; i.e. routing in which each destination in the entire network is tracked individually. Large scale routing is *necessarily* hierarchical. Since we need to number nodes in the network, it makes sense to use the same naming elements for identifying nodes in the topology. Again, perhaps I'm reading this wrong, but a variety of applications (mobility, etc) make is useful to have a name which stays the same no matter where you are. At the same time, the routing needs names which say where you are; i.e. they change depending on where you are. You can't do both with one name! As to the rest of your argument (structure and number of levels), this assumes heirarchy in the network topology. There demonstrably is no heirarchy I can take a completely arbitrary random graph, and create a hierarchical address structure for it, and you can create that hierarchy pretty much randomly, and it will work pretty well. If you do actually have a connectivity graph which has some structure, then you will find the routing overhead is lower if you use an addressing hieirarchy which takes that structure into account. Noel From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 12:34:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07388; Wed, 22 Jun 1994 11:45: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 LAA10856; Wed, 22 Jun 1994 11:45:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA10853; Wed, 22 Jun 1994 11:41:31 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05961; Wed, 22 Jun 1994 11:03:58 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA25507; Tue, 21 Jun 94 20:05:28 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ca26754; 22 Jun 94 1:01 GMT Date: Tue, 21 Jun 94 10:57 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: bsimpson To: big internet Subject: Re: assignment efficiency Message-Id: <05940621155750/0003858921NA1EM@mcimail.com> Bill Simpson said: > That they would be "in addition to" the world-wide network only > shows the hubris of your statements. Use of "private links" > paralleling the Internet does not improve the efficiency of the > limited intercontinental bandwidth. I seriously doubt that Boeing > laid those seabed links. They are a common resource. > Had you shared your links today, as CERN does, you would not be > having this problem, and the Internet would already have better > connectivity. You should not be surprised that the rest of the > Internet is not willing to waste vast amounts of their future > bandwidth to accomodate you. Bill, until such time that we can do encrypted sessions world-wide over public links, us corporate types will use private links. We have them to our Minivan plant is Austria and our facilities in Mexico. GM and FORD have them to a lot more places. For some of these, the simple trust model with VANs is used, others have DES end-to-end encryption. Then there is the performance issue. In some cases, we cannot use the TCP it will get done model. We have response-level requirements with the end-user. But I am monitoring this whole arena and will use public links wherever I can. > 5) Because another end user company, bigger, more sites, more nodes, > has already issued a "reality check" on your statements. If you mean me, Boeing is bigger than Chrysler. We are more modern in our architecture than some parts of Boeing simply because we started later... Bob From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 17:25:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19949; Wed, 22 Jun 1994 17: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 RAA11170; Wed, 22 Jun 1994 17:25:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA11156; Wed, 22 Jun 1994 17:19:29 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19822; Wed, 22 Jun 1994 17:19:26 +1000 (from huitema@mitsou.inria.fr) Received: from mitsou.inria.fr by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA19362 Wed, 22 Jun 1994 17:18:34 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA07470; Wed, 22 Jun 1994 09:16:33 +0200 Message-Id: <199406220716.AA07470@mitsou.inria.fr> To: "Robert G. Moskowitz" <0003858921@mcimail.com> Cc: big internet Subject: Re: use of crypto (was: assignment efficiency) In-Reply-To: Your message of "Tue, 21 Jun 1994 10:57:00 EST." <05940621155750/0003858921NA1EM@mcimail.com> Date: Wed, 22 Jun 1994 09:16:31 +0200 From: Christian Huitema => => Bill, until such time that we can do encrypted sessions world-wide over => public links, us corporate types will use private links. We have them to => our Minivan plant is Austria and our facilities in Mexico. GM and FORD have => them to a lot more places. For some of these, the simple trust model with => VANs is used, others have DES end-to-end encryption. Then there is the => performance issue. In some cases, we cannot use the TCP it will get done => model. We have response-level requirements with the end-user. => Bob, Many of us have long tried to make the point that the regulations on cryptography, and specifically those on export of cryptography, were hurting the Internet. The "agencies that count" and other "powers that be" generally brush our concerns aside; idealistic libertarians is the generic tag... Now, the effect you are quoting is quite different: absence of easily available crypto tools obliges companies to invest in super expensive international leased lines, i.e. are hurting business competitivity big time. Could you quantify that effect? Christian Huitema PS. By the way, what makes you think that hostile secret services cannot monitor your leased lines? From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 17:48:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15605; Wed, 22 Jun 1994 15:25: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 PAA11054; Wed, 22 Jun 1994 15:25:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA11029; Wed, 22 Jun 1994 15:08:57 +1000 Precedence: list Received: from vinegar.sesqui.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12458; Wed, 22 Jun 1994 13:58:19 +1000 (from bmanning@sesqui.net) Received: by vinegar.sesqui.net (4.1/SMI-4.1 Jun93 - wcm) id AA05273; Tue, 21 Jun 94 22:58:50 CDT From: bmanning@sesqui.net (William Manning) Message-Id: <9406220358.AA05273@vinegar.sesqui.net> Subject: Re: assignment efficiency To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 21 Jun 1994 22:58:49 -0500 (CDT) Cc: big-internet@munnari.OZ.AU, bsimpson@morningstar.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9406212046.AA11986@ginger.lcs.mit.edu> from "Noel Chiappa" at Jun 21, 94 04:46:22 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: 687 > > From: "William Allen Simpson" > > The current Internet has more than 1,000,000 nodes, and doesn't have 5 > levels of routing heirarchy. > > Really? CIDR was introduced *precisely* because the 3+ (net, subnet(s), host) > we had weren't enough. I'm not sure how many layers various parts of the > network are using now that CIDR has been deployed (you can't tell just from > looking at an address), but I wouldn't be surprised if parts are now using 5. > > Noel > You are correct! I can measure 6 levels from here. Mr. Simpson, please return to your homework. (Or perhaps I do not run part of the current Internet :) -Bill Manning From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 19:08:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23174; Wed, 22 Jun 1994 18:46: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 SAA11251; Wed, 22 Jun 1994 18:45:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA11237; Wed, 22 Jun 1994 18:34:49 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21821; Wed, 22 Jun 1994 18:13:34 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406220813.21821@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 22 Jun 1994 09:11:15 +0100 To: Greg Minshall Cc: big-internet@munnari.OZ.AU Subject: Re: variable length addresses In-Reply-To: Your message of "Mon, 20 Jun 94 11:04:59 PDT." <9406201804.AB06502@WC.Novell.COM> Date: Wed, 22 Jun 94 09:11:12 +0100 From: Jon Crowcroft >>personally, i think there are as many opportunities to assign >>variable length wrong as there are advantages in the flexibility ... >>this is based on talking to sites with 100k host networks in the UK, i >>often find they have a real problem with IPv4 address assignment. >>and note, if someone gets it wrong, the use memory in _all_ routers >I think the *best* argument for variable length addresses is that it allows >for sloppy address assignment (by your 100k host networks, say) and still >*runs*. It may not run optimally, but as long as the "damage" is contained >within a given site, then this is not a problem globally. And, if runs >poorly enough, people will eventually be motivated to apply sufficient >brainpower to fix it. >As you mention, even IPv4 addresses are subject to this problem. I assume >you don't want to *constrain* the address assignment any more than is done >in IPv4? >Thoughts? tradeoffs, tradeoffs, tradeoffs, the mind boggles... and spins jon From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 21:25:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28219; Wed, 22 Jun 1994 21:25: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 VAA11420; Wed, 22 Jun 1994 21:25:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA11406; Wed, 22 Jun 1994 21:11:08 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27675; Wed, 22 Jun 1994 21:11:01 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA23223; Wed, 22 Jun 94 06:12:33 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ag00461; 22 Jun 94 11:08 GMT Date: Wed, 22 Jun 94 06:06 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Christian Huitema Cc: big internet Subject: Re: use of crypto (was: assignment efficiency) Message-Id: <80940622110608/0003858921NA2EM@mcimail.com> Christian said: >Many of us have long tried to make the point that the regulations on >cryptography, and specifically those on export of cryptography, were >hurting the Internet. The "agencies that count" and other "powers that >be" generally brush our concerns aside; idealistic libertarians is >the generic tag... Now, the effect you are quoting is quite different: >absence of easily available crypto tools obliges companies to invest >in super expensive international leased lines, i.e. are hurting business >competitivity big time. Could you quantify that effect? I really don't believe in the VAN trust model. We have seen the taps off to the gov in the TELCO NOCS. Whoops shouldn't have said that in public :) We have a T1 to Austria caring SNA and TCP/IP traffic. The TCP stuff could have gone over an encrypted connection. The SNA is tougher, DLS might work but needs to be proved over the congested international network. So perhaps we could save ourselves a LOT of money, or rather help pay for more international bandwidth if there was public encryption world-wide. If you go through the FORTUNE 100 for international corps (probably all), you will find a lot of private lines. Some of the banking lines are encrypted with triple DES (we have a local line like that to our bank), but most are open becuase there is no encryption available. Almost seems that this is a plot by the TELCOs for more business ;) Perhaps we can get some info from the friendly TELCOs as to how many private, international lines there are. Then the problem is home much real bandwidth is needed by them to determine what the savings of a common carrier would be. Wed morning ramblings.... Bob From owner-Big-Internet@munnari.OZ.AU Wed Jun 22 21:45:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28892; Wed, 22 Jun 1994 21:45: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 VAA11452; Wed, 22 Jun 1994 21:45:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA11449; Wed, 22 Jun 1994 21:43:13 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28747; Wed, 22 Jun 1994 21:43:04 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA23991; Wed, 22 Jun 94 06:44:37 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ad02352; 22 Jun 94 11:40 GMT Date: Wed, 22 Jun 94 06:41 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: A Serious Proposal Message-Id: <80940622114108/0003858921NA3EM@mcimail.com> Preamble: Colleagues, I am behind on my review of this list, but a few kind souls have summarized the discussions of the last week for me. Based on that, some conversations I participated in INET, and my corporate, pragmatic view, I propose the following as a model for SIPP address utilization. In it you will find NIC funding, corporate addressing safety blankets, and topologies. I have a think skin and can take name-calling if some of you do not like my proposal. But give it serious consideration. I firmly believe it addresses both the public and private needs. THE SIPP ADDRESS as a Confounding of measures. I cannot compare myself to Chiappa or Osta. But I did have a fair amount of math and statistics in my college days. In one major project for the ecologists we developed a simple indice that confounded a number of separate measures. This indice (the 'diversity index' that was based on information theory) was then used in a number of papers to assist others in understanding both population dynamics and successonal forces. I see SIPP addresses as doing a similar thing. In fact, IPv4 are confounding indices. The basic dual measure of the SIPP address is Location and Entity. This follows our basic 8+8 discussion. Another measure we have been using is a Provider measure that some have been working on casting in a hierarchy (today it is the AS number). Actually, the AS number, I think, is a confounded index of to key measures, Provider, and Network Entity. I propose to measures consisting of two measures. At the higher level is the LOCATOR/EID. The EID as you will see is globally unique. The Locator is a globally unique network segment. Each measure gets allocated 8 bytes of the SIPP address. EID STRUCTURE and Funding The EID is composed of two components. An Agency identifier, and an entity address. This will break the EID into two 4 byte pieces. The Agency identifier is assigned by an addressing agency. Anyone can submit paperwork and a processing fee to get one (after all there are 2^32 of them). There is an annual maintence fee to maintain the registry of these numbers, perhaps the 'standard' 15% of initial fee. Thus the addressing agencies have an income flow to run a quality service. The fees also assure compliance of uniqueness for the requesting Agency. An Agency might be a public network provider like ANS, SPRINT, SURFNet, or NEARNet. I could also be a private network provider like CERN, Boeing, Chrysler, or EDS. I could see an organization like EDS getting two numbers, one for GM and one for there commercial, non GM, network. An Agency is then free to assign addresses in the second 4 bytes. 2^32 is a lot of addresses and there is no topology in them, so they all can be assigned to devices. LOCATOR STRUCTURE and Funding The Locator is composed of two components. A Provider number and a Provider unique topology structure. The Locator would be broken down into 2 bytes for Provider and 6 bytes for topology. The 65K Provider numbers will be allocated by a registry organization. These will be much more expensive than an EID Agency number, but with the same 15% annual maintence fee. Provider numbers will be doled out to network providers like ANS, SPRINT, SURFNET, MSEN, etc, and to corporate entities wanting complete control over their destiny, perhaps only the Fortune 1000. Thus 65K SHOULD be more than adequate. Each Provider and then use the remaining 48 bits to compose a topological tree of their network. Those that insist on working on byte bounderies can have 6 levels internally with 256 branches off of each node. Us bit twiddlers can do as we wish. The end node in this tree represents a physical network (or virtual for ATM, X.25, etc). It can have as many devices in it as is desired as there is no required tie between Locator and EID. Thus the full 48 bits is topology. The global routing is a bit of a challenge for me. I could see how the Provider number might be mapped to an ATM address of the Provider's border ATM switch. For those providers with multiple contact points, part of the topology would have to be used in this mapping and other, more experience routing people need to lend a hand. SUMMARY A Provider/Topology//Agency/Entity (2/6//4/4) addressing scheme would go a long way to meet the need of all users of IPng: Public and Private. It can supply a funding model for the administrative functions of IPng. It allows for considerable flexability in address usage to fit models unique to different players in the global network. Bob Moskowitz Chrysler Corporation IS Technical Services (810) 758-8212 From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 00:06:12 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03789; Thu, 23 Jun 1994 00:06: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 AAA11580; Thu, 23 Jun 1994 00:05:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA11564; Wed, 22 Jun 1994 23:54:57 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02913; Wed, 22 Jun 1994 23:54:45 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA28584; Wed, 22 Jun 94 08:55:53 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ac10916; 22 Jun 94 13:51 GMT Date: Wed, 22 Jun 94 08:44 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: big internet Subject: Re: A Serious Proposal Message-Id: <53940622134435/0003858921NA1EM@mcimail.com> I typoed: >I have a think skin and can take name-calling if some of you do not like my >proposal. That is thick skin. Lots of typos in this, shows my 3 hours of sleep every night to make up for leaving the family for a week :( Appologize for them and hope you all can figure out when I use to instead of two and the like ;-) Bob From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 01:47:42 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05015; Thu, 23 Jun 1994 00:45: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 AAA11638; Thu, 23 Jun 1994 00:45:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA11624; Thu, 23 Jun 1994 00:33:28 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03823; Thu, 23 Jun 1994 00:07:50 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 22 Jun 94 23:01:22 +0900 From: Masataka Ohta Message-Id: <9406221401.AA14731@necom830.cc.titech.ac.jp> Subject: Re: Why variable length? To: kasten@ftp.com Date: Wed, 22 Jun 94 23:01:20 JST Cc: kre@munnari.OZ.AU, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: <9406201415.AA03015@mailserv-D.ftp.com>; from "Frank Kastenholz" at Jun 20, 94 10:15 am X-Mailer: ELM [version 2.3 PL11] > Not quite. > > There is a white paper from the cable television industry in the > internet drafts directory. draft-vecchi-ipng-tvcable-viewpt-00.txt It > provides the basis for the E12 network numbers statement. > > In terms of planning for worldwide cable TV, they estimated that > there would be on the order of E10 homes in the world. They added 2 > orders of magnitude of safety and then said that IPng needed to > support E12 end nodes. OK. Let's assume that we need E12 (2^40) home networks. > Now, the cable TV people see a home as an > end-node. The authors of the IPng criteria document see a home as a > 'leaf network' on which one possible node might be a cable-tv box. Considering that an average home network would need about 256 addresses and with another safety factor of 256, we need 16 bits more, 56 bits. Thus, a 64 bit EID space is enough for us with yet another safety factor of 256. Isn't it safe enough? Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 01:51:21 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05182; Thu, 23 Jun 1994 00:48: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 AAA11653; Thu, 23 Jun 1994 00:48:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA11621; Thu, 23 Jun 1994 00:32:45 +1000 Precedence: list Received: from mailhub.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03859; Thu, 23 Jun 1994 00:10:06 +1000 (from john@iastate.edu) Received: from pooh.cc.iastate.edu by mailhub.iastate.edu id AA12365; Wed, 22 Jun 1994 09:10:12 -0500 Received: by pooh.cc.iastate.edu; id AA13395; Wed, 22 Jun 1994 09:10:00 -0500 Message-Id: <9406221410.AA13395@pooh.cc.iastate.edu> To: big internet Subject: non-geographical routing considered harmful Date: Wed, 22 Jun 1994 09:09:59 CDT From: John Hascall I would be most pleased if someone more to the front of this future bus would discuss how IPng might improve this situation, (2 sites, ~30 miles apart connected to 2 different providers): 1 router169 (129.186.169.254) 4 ms 4 ms 4 ms 2 isu-1 (192.245.179.1) 4 ms 4 ms 4 ms 3 [MIDnet, Lincoln] 128.242.21.1 (128.242.21.1) 12 ms 12 ms 12 ms 4 [MIDnet, Lincoln] 192.35.171.10 (192.35.171.10) 23 ms 16 ms 12 ms 5 t3-1.cnss81.St-Louis.t3.ans.net (140.222.81.2) 23 ms 31 ms 23 ms 6 mf-0.cnss80.St-Louis.t3.ans.net (140.222.80.222) 27 ms 27 ms 35 ms 7 t3-1.cnss24.Chicago.t3.ans.net (140.222.24.2) 31 ms 31 ms 31 ms 8 t3-0.cnss40.Cleveland.t3.ans.net (140.222.40.1) 43 ms 35 ms 39 ms 9 t3-1.cnss48.Hartford.t3.ans.net (140.222.48.2) 55 ms 55 ms 59 ms 10 t3-2.cnss32.New-York.t3.ans.net (140.222.32.3) 55 ms 59 ms 59 ms 11 t3-1.cnss56.Washington-DC.t3.ans.net (140.222.56.2) 62 ms 70 ms 62 ms 12 mf-0.cnss58.Washington-DC.t3.ans.net (140.222.56.194) 62 ms 62 ms 66 ms 13 t3-0.enss145.t3.ans.net (140.222.145.1) 62 ms 62 ms 70 ms 14 icm-fix-e-F0.icp.net (192.203.229.245) 129 ms 66 ms 62 ms 15 icm-dc-1-H1/0.icp.net (192.157.65.121) 70 ms 70 ms 62 ms 16 144.228.20.4 (144.228.20.4) 70 ms 74 ms 74 ms 17 144.228.20.1 (144.228.20.1) 102 ms 184 ms 148 ms 18 sl-chi-3-S1/0-T1.sprintlink.net (144.228.0.161) 121 ms 98 ms 90 ms 19 sl-chi-2-F0.sprintlink.net (144.228.129.2) 94 ms 90 ms 117 ms 20 sl-infotex-1-S0-56k.sprintlink.net (144.228.128.194) 117 ms 266 ms 164 ms 21 dsm6.dsmnet.com (198.202.223.38) 254 ms 133 ms 133 ms From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 01:53:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06656; Thu, 23 Jun 1994 01:26: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 BAA11764; Thu, 23 Jun 1994 01:25:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA11699; Thu, 23 Jun 1994 01:08:56 +1000 Precedence: list Received: from mail.physics.ox.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06018; Thu, 23 Jun 1994 01:08:25 +1000 (from j.macallister1@physics.oxford.ac.uk) Received: from av1.physics.ox.ac.uk by mail with SMTP (5.65c+/IDA-1.4.4-UK-t for ) id AA08353; Wed, 22 Jun 1994 16:07:04 +0100 Date: Wed, 22 Jun 1994 16:09:15 +0100 (BST) From: John Macallister To: BIG-INTERNET@munnari.OZ.AU Cc: MACALLSTR@v1.ph.ox.ac.uk Message-Id: <940622160915.27400a48@v1.ph.ox.ac.uk> Subject: RE: Addressing range One great mistake that has been made with every new network address scheme so far is that the designers have failed to appreciate that what is required is not a large address space but an (infinitely) expandable one. One of the reasons for the wrong choice of address space in the past, of course, is that the original choices were reasonable for the original implementation but the use of many protocols has moved into areas for which they were never intended: mainly moving from local/private use to public/World-wide networks. Setting a limit on the address space, even it's very large, is unwise as it's just not possible to accurately predict how computer technology will have evolved several years from now. At the moment it's clear that every individual on Earth will eventually have some form of network address and most likely several. With bio-computers it's possible that one might want to address groups of molecules! Any addressing scheme which could cater for all possibilities in such a situation would have to be very large indeed. It would appear that an addressing scheme in which an address could be an arbitrarily large number will have to be the eventual choice and might be stored as:
Only such an addressing scheme, which is (infinitely) expandable makes any sense in the long term. John From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 02:06:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08120; Thu, 23 Jun 1994 02:06: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 CAA11817; Thu, 23 Jun 1994 02:05:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA11792; Thu, 23 Jun 1994 01:48:11 +1000 Precedence: list Received: from vinegar.sesqui.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06523; Thu, 23 Jun 1994 01:20:44 +1000 (from bmanning@sesqui.net) Received: by vinegar.sesqui.net (4.1/SMI-4.1 Jun93 - wcm) id AA11866; Wed, 22 Jun 94 10:21:00 CDT From: bmanning@sesqui.net (William Manning) Message-Id: <9406221521.AA11866@vinegar.sesqui.net> Subject: Re: non-geographical routing considered harmful To: john@iastate.edu (John Hascall) Date: Wed, 22 Jun 1994 10:21:00 -0500 (CDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9406221410.AA13395@pooh.cc.iastate.edu> from "John Hascall" at Jun 22, 94 09:09:59 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: 553 First off, why is this a bad thing? An existing analogy is the neighbors, one with MCI and one with Sprint as the prefered carrier of both local and long distance calls. It is in both MCI & Sprints interests to keep the number of interconnects small (less $) If the service is acceptable (delay, latency etc) then why should it matter that they only exchange traffic in 6-10 locations around the world? This also seems to be the wave of the future wrt competition. Geographic orientation requires a monoploy on managment of the local space. -Bill From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 02:25:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08586; Thu, 23 Jun 1994 02: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 CAA11912; Thu, 23 Jun 1994 02:25:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA11884; Thu, 23 Jun 1994 02:14:06 +1000 Precedence: list Received: from mail.physics.ox.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08241; Thu, 23 Jun 1994 02:13:57 +1000 (from j.macallister1@physics.oxford.ac.uk) Received: from av1.physics.ox.ac.uk by mail with SMTP (5.65c+/IDA-1.4.4-UK-t for ) id AA08777; Wed, 22 Jun 1994 17:12:49 +0100 Date: Wed, 22 Jun 1994 17:15:00 +0100 (BST) From: John Macallister To: big-internet@munnari.OZ.AU Cc: MACALLSTR@v1.ph.ox.ac.uk Message-Id: <940622171500.27400a48@v1.ph.ox.ac.uk> Subject: Re: addressing. P.S. While a few multiples of 226 bits may be the absolute upper limit on addressing requirements, the addition of a field allows sensibly size packets to be transmitted when the upper addresses are not being used. John From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 02:27:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08742; Thu, 23 Jun 1994 02:27: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 CAA11927; Thu, 23 Jun 1994 02:27:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA11831; Thu, 23 Jun 1994 02:09:42 +1000 Precedence: list Received: from mail.physics.ox.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08174; Thu, 23 Jun 1994 02:09:17 +1000 (from j.macallister1@physics.oxford.ac.uk) Received: from av1.physics.ox.ac.uk by mail with SMTP (5.65c+/IDA-1.4.4-UK-t for ) id AA08744; Wed, 22 Jun 1994 17:08:04 +0100 Date: Wed, 22 Jun 1994 17:10:16 +0100 (BST) From: John Macallister To: big-internet@munnari.OZ.AU Cc: J.Crowcroft@cs.ucl.ac.uk, MACALLSTR@v1.ph.ox.ac.uk Message-Id: <940622171016.27400a48@v1.ph.ox.ac.uk> Subject: Re: addressing. > 64 bit addresses: > 2**64 is 10**18 - gives you a lot of devices each for 10**9 people 64-bit addressing doesn't even begin to address the general addressing problem. The World's population is currently several times 10**9 and small lumps of material contain of the order of 10**23 molecules. While 64-bit addressing may extend the lifetime of IP for a few years, if it entails significant disruption for conversion, many people will be reluctant to adopt it as they will see it only as a stop-gap and not a long-term solution. However, before an endless discussion begins, it's worth noting that 'infinity' is not that large! The current estimate for the number of nuclei in the Universe is of the order of 10**80 which is very approx 2**266. So you see that even allowing for a hierarchical network address structure the upper limit on the address field is only a few multiples of 266 bits. John From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 02:30:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08199; Thu, 23 Jun 1994 02:10: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 CAA11846; Thu, 23 Jun 1994 02:10:06 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA11795; Thu, 23 Jun 1994 01:48:14 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06604; Thu, 23 Jun 1994 01:22:07 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 22 Jun 1994 11:21:57 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 22 Jun 1994 11:21:57 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA29901; Wed, 22 Jun 94 11:20:04 EDT Date: Wed, 22 Jun 94 11:20:04 EDT Message-Id: <9406221520.AA29901@mailserv-D.ftp.com> To: mohta@necom830.cc.titech.ac.jp Subject: Re: Why variable length? From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 751 > From: Masataka Ohta > Return-Path: > > OK. Let's assume that we need E12 (2^40) home networks. > Considering that an average home network would need about 256 addresses > and with another safety factor of 256, we need 16 bits more, 56 bits. > > Thus, a 64 bit EID space is enough for us with yet another safety > factor of 256. > > Isn't it safe enough? Only when enumerating them. And only when the space used to enumerate them is densely used. I believe that EIDs will be allocated in an administrative hierarchy and therefore the eid space will not be densely used. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 02:30:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08220; Thu, 23 Jun 1994 02:11: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 CAA11861; Thu, 23 Jun 1994 02:11:30 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA11814; Thu, 23 Jun 1994 01:58:50 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07851; Thu, 23 Jun 1994 01:58:43 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20149; Wed, 22 Jun 94 11:58:40 -0400 Date: Wed, 22 Jun 94 11:58:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406221558.AA20149@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, john@iastate.edu Subject: Re: non-geographical routing considered harmful Cc: jnc@ginger.lcs.mit.edu From: John Hascall I would be most pleased if someone more to the front of this future bus would discuss how IPng might improve this situation, (2 sites, ~30 miles apart connected to 2 different providers): First, you didn't send us a (complete) map of the physical network topology. If, in fact, there *is no shorter path through the existing physical topology*, there's obviously nothing to be done *by any means*. Do you happen to know the answer to this question (i.e. is there a shorter path available)? Second, if there is a better route currently available, but the routing architecture didn't discover it, *nothing* that this list has talked about over the last months is really related to doing something about this. A new internetwork layer packet format (i.e. IPng) isn't going to, and *can't*, fix this. A new routing architecture (such as Unified, or Nimrod, or a major rework of the existing one) is what will fix it. Everybody needs to understand that, and if anyone doesn't, say so. Bigger "addresses" won't help (they'll likely hurt optimality of routes, as a matter of fact: bigger addresses -> more levels -> less "flat" routing -> greater non-optimality of routes). If there is a better path available, but it wasn't discovered, I can only speculate about why. If you investigate to see if there is a better path, perhaps you could report back on why it's not being used; it would be very educational. For one, the relatively clunky policy tools which we have, which are used to secure the routing (i.e. prevent spoofing attacks from having a serious negative impact on the routing, which is otherwise unprotected), may not be configured to alow this path to be discovered and used. It's difficult to configure the tools, especially since they are so orthagonal to what policy goals most people want to accomplish. Most policy databases aren't configured to allow all possible reasonable routes, I'll bet. For another, older protocols, such as EGP, have problems which make use of alternate paths tricky; these problems used to be attacked with policy tools (see above). Also, I doubt CIDR aggregation has gotten to the point where this could be causing more non-optimal routes, but that will happen some day too. These are all guesses, so take them with quite a few grains of salt. Noel PS: It's a fact of life that the larger the network, the more non-optimal the routes will be, for a fixed amount of routing overhead. Post-gradutae seminar in routing to explain why left off for now! :-) From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 02:47:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08237; Thu, 23 Jun 1994 02:13: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 CAA11876; Thu, 23 Jun 1994 02:13:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA11800; Thu, 23 Jun 1994 01:54:35 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06603; Thu, 23 Jun 1994 01:22:08 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 22 Jun 1994 11:21:52 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 22 Jun 1994 11:21:52 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA29892; Wed, 22 Jun 94 11:20:00 EDT Date: Wed, 22 Jun 94 11:20:00 EDT Message-Id: <9406221520.AA29892@mailserv-D.ftp.com> To: bsimpson@MorningStar.Com Subject: Re: addressing elements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 6658 Bill Simpson Writes: > > From: kasten@ftp.com (Frank Kastenholz) > > First of all, you keep talking about enumeration of 10E15 elements. > > You are right, 10E15 elements can be enumerated in 64 bits. However, > > enumeration assumes 'dense' use of the space. > > > Not very dense. About 1E10-5. If you number them simply as 1,2,3,4,5... you are right. If there is administrative structure in the number (and I feel that there will be) then things will be very very different; blocks of numbers will be given to different administrative authorities (and sub-blocks to sub-authorities... apply recursion as desired) and those blocks won't be densely used. > > elements of the network (sometimes known as EIDs) then another > > pattern of use will prevail. If we are talking about something that > > combines both the unique name and the topological information > > (sometimes known as an IPv4 address), then a third pattern of use > > will prevail. > Topologically sensitive information (locator) never was, is not, and is > never likely to be heirarchical, and therefore not subject to more than > accidental aggregation. Therefore, we need only decide the size of > elements which name routing points in the topology. This is not correct. Today, the IPv4 Address is hierarchical. This is why it is easier to build large internetworks based on IPv4 Addresses and Routing than it is to use Ethernet Addresses and Bridging. The IPv4 Address has 2 or 3 levels of hierarchy in it: "network.subnetwork.host" And CIDR has added at least another level. Things outside the 'network' portion of this number (e.g. other 'networks', backbones and regionals) do not know and need not know the internal structure of a 'network'. This internal structure is represented by the 'subnet' portion of the IPv4 Address. Similarly, things outside a particular subnet do not need to know the structure of that subnet. > Since we need to number nodes in the network, it makes sense to use the > same naming elements for identifying nodes in the topology. Identifying them, yes. Giving their position in the topology; no. If you want to mail a letter to me, you would need to put more than "FranK Kastenholz" on the envelope, wouldn't you? Even if there is only one person named Frank Kastenholz in the world, the only way the postal system could get the letter to me would be to have a directory of every valid name, and some information on where each entry is (i.e. topological information!). They would look up Frank Kastenholz, get my postal address, stick it on the envelope, and send it on its way. The same holds true for networking. At some point, some entity has to translate from a nice human readable nodename (e.g. europa.ftp.com) into topologically sensitive information (128.127.145.82) that the routing and forwarding subsystems of the Internet can use to get packets to the named machine. > As to the rest of your argument (structure and number of levels), this > assumes heirarchy in the network topology. There demonstrably is no > heirarchy, therefore your level estimates serve only to show us that the > SIPP routing header has a likely maximum future size of 6 elements Bill, you are again wrong. There already is hierarchy. Its exact nature depends on who and where you are. For a company like ftp Software it roughly is "major-backbone.regional.subscriber.subnet.host" (specifically, the hierarchy would be: "nsfnet-backbone.nearnet.ftpsoftware.subnet.host" This is not, however, represented in the topological information carried around in the IPv4 Address. The IPv4 Address carries around ONLY the subscriber.subnet.host part (ignoring CIDR). The problem is that the number of "subscribers", which is what all levels "above" the "subscriber" route on, is growing too large to effectively and efficiently handle. CIDR has helped this somewhat. However, CIDR is a (very very elegant) hack and will merely put off the day of reckoning. If we continue simply routing in the 'subscriber' portion of the IPv4 address (or the equivalent in IPng) then the network will eventually fail. The number of entries in the NSFnet database is doubling every 7-8 months. Moore's(?) law in computer engineering states that computing power doubles every 18 months. Since the routing load on the backbone routers is roughly O(number of network numbers), it should be fairly obvious that the load on these routers is growing faster than the ability of those routers to handle the load (the load doubles every 7-8 months, the ability to handle that load doubles every 18 months). Now, we can certainly quibble about whether the NSFNET database doubles every 8 months or every 10 months, and whether computing power doubles every 18 or 16 months -- but the relationship between the 2 doublings (computer power increases slower than network size) will probably hold. Sooner or later, things will just be too big. So, we could continue to flat-route based at a fairly low level in the hierarchy, as we do today. However, our continuing ability to do this is not certain. This requires that backbone routers maintain a routing table that contains every possible destination network, and that the computer power available in these routers increases fast enough to cover this load (plus, of course, the increased load of forwarding more packets...). The alternative is to reduce the number of destinations that any particular element of the Internet needs to route to. (The efficacy of this technique is already demonstrated -- the router connecting ftp Software to the Internet needs to keep at most 256 routes -- up to 255 to 128.127.subnet.xxx and one to . This router can be very very simple.) To a degree, we already do this today, we have subnetting which allows places to hide their internal structure behind a single IPv4 network number -- the backbones only know about 128.127, they do not know about all of FTP's internal subnets (there are dozens). Also, by deploying CIDR and turning on aggregation, we are merging several IPv4 network numbers into a single number that is advertised to the rest of the world. However, now we start running into the problem that there are only 32 bits in the V4 address. The inefficiencies inherent in this sort of hierarchical structure eventually will use up all 32 bits, and we will be no where near 2**32 hosts. The best mechanism available to reduce destinations is aggregation, just as we do with IPv4 Subnets, networks, and CIDR areas. This means hierarchy in some form. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 04:06:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11650; Thu, 23 Jun 1994 04:06: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 EAA12104; Thu, 23 Jun 1994 04:06:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA12090; Thu, 23 Jun 1994 03:53:01 +1000 Precedence: list Received: from feta.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11296; Thu, 23 Jun 1994 03:52:58 +1000 (from dkatz@cisco.com) Received: (dkatz@localhost) by feta.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id KAA25046; Wed, 22 Jun 1994 10:52:53 -0700 Date: Wed, 22 Jun 1994 10:52:53 -0700 From: Dave Katz Message-Id: <199406221752.KAA25046@feta.cisco.com> To: john@iastate.edu Cc: big-internet@munnari.OZ.AU In-Reply-To: John Hascall's message of Wed, 22 Jun 1994 09:09:59 CDT <9406221410.AA13395@pooh.cc.iastate.edu> Subject: non-geographical routing considered harmful Sure, let's ensure that encapsulation is trivial and fast so that all the internal hops can be hidden. (half ;-) ) I think there are three (at least) separate issues here. How well interconnected are the multiple providers? My guess is "not very" so your well-travelled packets didn't have a lot of choice. How can routing/addressing improvements aid the situation? Some, but it's a fairly tough problem. How big of a problem is this really? A large part of your question is one of perception based on the hop count; to a lesser extent it's the transit delay. To some extent this will be market-driven if the economic models will make sense (it's easy to drive down delay in a single provider, but it's a lot harder to do so when multiple carriers are involved). Precedence: list Date: Wed, 22 Jun 1994 09:09:59 CDT From: John Hascall I would be most pleased if someone more to the front of this future bus would discuss how IPng might improve this situation, (2 sites, ~30 miles apart connected to 2 different providers): 1 router169 (129.186.169.254) 4 ms 4 ms 4 ms 2 isu-1 (192.245.179.1) 4 ms 4 ms 4 ms 3 [MIDnet, Lincoln] 128.242.21.1 (128.242.21.1) 12 ms 12 ms 12 ms 4 [MIDnet, Lincoln] 192.35.171.10 (192.35.171.10) 23 ms 16 ms 12 ms 5 t3-1.cnss81.St-Louis.t3.ans.net (140.222.81.2) 23 ms 31 ms 23 ms 6 mf-0.cnss80.St-Louis.t3.ans.net (140.222.80.222) 27 ms 27 ms 35 ms 7 t3-1.cnss24.Chicago.t3.ans.net (140.222.24.2) 31 ms 31 ms 31 ms 8 t3-0.cnss40.Cleveland.t3.ans.net (140.222.40.1) 43 ms 35 ms 39 ms 9 t3-1.cnss48.Hartford.t3.ans.net (140.222.48.2) 55 ms 55 ms 59 ms 10 t3-2.cnss32.New-York.t3.ans.net (140.222.32.3) 55 ms 59 ms 59 ms 11 t3-1.cnss56.Washington-DC.t3.ans.net (140.222.56.2) 62 ms 70 ms 62 ms 12 mf-0.cnss58.Washington-DC.t3.ans.net (140.222.56.194) 62 ms 62 ms 66 ms 13 t3-0.enss145.t3.ans.net (140.222.145.1) 62 ms 62 ms 70 ms 14 icm-fix-e-F0.icp.net (192.203.229.245) 129 ms 66 ms 62 ms 15 icm-dc-1-H1/0.icp.net (192.157.65.121) 70 ms 70 ms 62 ms 16 144.228.20.4 (144.228.20.4) 70 ms 74 ms 74 ms 17 144.228.20.1 (144.228.20.1) 102 ms 184 ms 148 ms 18 sl-chi-3-S1/0-T1.sprintlink.net (144.228.0.161) 121 ms 98 ms 90 ms 19 sl-chi-2-F0.sprintlink.net (144.228.129.2) 94 ms 90 ms 117 ms 20 sl-infotex-1-S0-56k.sprintlink.net (144.228.128.194) 117 ms 266 ms 164 ms 21 dsm6.dsmnet.com (198.202.223.38) 254 ms 133 ms 133 ms From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 04:27:28 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09452; Thu, 23 Jun 1994 02:46: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 CAA11969; Thu, 23 Jun 1994 02:46:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA11951; Thu, 23 Jun 1994 02:37:19 +1000 Precedence: list Received: from mailhub.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09037; Thu, 23 Jun 1994 02:37:14 +1000 (from john@iastate.edu) Received: from pooh.cc.iastate.edu by mailhub.iastate.edu id AA19101; Wed, 22 Jun 1994 11:37:22 -0500 Received: by pooh.cc.iastate.edu; id AA13632; Wed, 22 Jun 1994 11:37:10 -0500 Message-Id: <9406221637.AA13632@pooh.cc.iastate.edu> To: bmanning@sesqui.net (William Manning) Cc: big-internet@munnari.OZ.AU Subject: Re: non-geographical routing considered harmful In-Reply-To: Your message of Wed, 22 Jun 1994 10:21:00 -0500. <9406221521.AA11866@vinegar.sesqui.net> Date: Wed, 22 Jun 1994 11:37:09 CDT From: John Hascall > First off, why is this a bad thing? An existing analogy is the > neighbors, one with MCI and one with Sprint as the prefered carrier > of both local and long distance calls. It is in both MCI & Sprints > interests to keep the number of interconnects small (less $) > If the service is acceptable (delay, latency etc) then why should > it matter that they only exchange traffic in 6-10 locations around the > world? Exactly my point -- would you accept a 1/4 second latency on a 30 mile phone call? John From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 04:27:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09488; Thu, 23 Jun 1994 02:49: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 CAA11984; Thu, 23 Jun 1994 02:48:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA11932; Thu, 23 Jun 1994 02:28:11 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07292; Thu, 23 Jun 1994 01:42:52 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-01.dialip.mich.net (pm002-01.dialip.mich.net [35.1.48.82]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA09180 for ; Wed, 22 Jun 1994 11:42:38 -0400 Date: Wed, 22 Jun 94 14:27:00 GMT From: "William Allen Simpson" Message-Id: <2749.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: number of existing routing levels > From: bmanning@sesqui.net (William Manning) > > The current Internet has more than 1,000,000 nodes, and doesn't have 5 > > levels of routing heirarchy. > > > > Really? CIDR was introduced *precisely* because the 3+ (net, subnet(s), host) > > we had weren't enough. I'm not sure how many layers various parts of the > > network are using now that CIDR has been deployed (you can't tell just from > > looking at an address), but I wouldn't be surprised if parts are now using 5. > > > You are correct! I can measure 6 levels from here. Mr. Simpson, please return > to your homework. (Or perhaps I do not run part of the current Internet :) > Perhaps you could be more explicit. I do not seem to be alone in this assessment (referring to Dennis Ferguson's recent message regarding two tier routing). I have never seen more than subnet, administrative domain, provider. As far as I can tell, there is no meta-provider through which all traffic on the world-wide net is required to pass in order to arrive at another provider. So far, no root has become apparent to me. (Hosts are not part of the routing "level", unless you expect host routes to be propagated world-wide. I have not seen this yet.) Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 04:29:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09621; Thu, 23 Jun 1994 02:50: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 CAA11999; Thu, 23 Jun 1994 02:50:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA11943; Thu, 23 Jun 1994 02:29:34 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07300; Thu, 23 Jun 1994 01:42:54 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-01.dialip.mich.net (pm002-01.dialip.mich.net [35.1.48.82]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id LAA09183 for ; Wed, 22 Jun 1994 11:42:40 -0400 Date: Wed, 22 Jun 94 14:42:03 GMT From: "William Allen Simpson" Message-Id: <2750.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: addressing elements > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Since we need to number nodes in the network, it makes sense to use the > same naming elements for identifying nodes in the topology. > > Again, perhaps I'm reading this wrong, but a variety of applications > (mobility, etc) make is useful to have a name which stays the same no matter > where you are. At the same time, the routing needs names which say where you > are; i.e. they change depending on where you are. You can't do both with one > name! > A name is not an address. Routing uses addresses. You've been preaching this long enough yourself. We need to number nodes in a network (you cut out my rationale, so you'll just have to go back to the old message for that). The topology has nodes. Each node already has a number/name. To avoid having a separate administrative numbering space for elements of routing, the routing address can be composed from the number/name of nodes through which routing has to pass. Therefore, it makes sense to use the same naming elements for identifying nodes in the topology to build the routing address. This is the technique used for the IP source route. The SIPP Routing Header expands this to clusters of nodes, using the same naming space. > I can take a completely arbitrary random graph, and create a hierarchical > address structure for it, and you can create that hierarchy pretty much > randomly, and it will work pretty well. I beg to differ. If you take any graph, you can create a hierarchical _naming_ structure for it. It may work perfectly well for inspection, but not for routing. > If you do actually have a connectivity > graph which has some structure, then you will find the routing overhead is > lower if you use an addressing hieirarchy which takes that structure into > account. > Of course, this makes perfect sense. The hard part is finding the structure. But my point was, we don't have a connectivity graph with heirarchical structure, and the structure is dynamically changing. What little residual structure there is currently (mostly at administrative domains), is being nibbled away by multi-homed domains. Even lowly bulletin boards are multi-homed these days. So, we need to define our dynamic addressing elements using names that don't change dynamically. The same name space as node numbers. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 04:30:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10529; Thu, 23 Jun 1994 03:27: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 DAA12060; Thu, 23 Jun 1994 03:26:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA12046; Thu, 23 Jun 1994 03:10:29 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10036; Thu, 23 Jun 1994 03:10:23 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 22 Jun 1994 13:10:15 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 22 Jun 1994 13:10:15 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA02099; Wed, 22 Jun 94 13:08:25 EDT Date: Wed, 22 Jun 94 13:08:25 EDT Message-Id: <9406221708.AA02099@mailserv-D.ftp.com> To: bsimpson@MorningStar.Com Subject: Re: addressing elements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 946 Bill Simpson writes: > A name is not an address. Routing uses addresses. > > We need to number nodes in a network (you cut out my rationale, so > you'll just have to go back to the old message for that). > > The topology has nodes. Each node already has a number/name. > > To avoid having a separate administrative numbering space for elements > of routing, the routing address can be composed from the number/name of > nodes through which routing has to pass. > > Therefore, it makes sense to use the same naming elements for > identifying nodes in the topology to build the routing address. > > This is the technique used for the IP source route. The SIPP Routing > Header expands this to clusters of nodes, using the same naming space. Please enlighten us as to how a path from one arbitrary node to another is generated. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 04:46:44 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12923; Thu, 23 Jun 1994 04:46: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 EAA12167; Thu, 23 Jun 1994 04:46:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12164; Thu, 23 Jun 1994 04:43:35 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12853; Thu, 23 Jun 1994 04:43:28 +1000 (from conta@ucx.lkg.dec.com) Received: from hageln.ucx.lkg.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA19578; Wed, 22 Jun 94 11:38:08 -0700 Received: by hageln.ucx.lkg.dec.com (5.65/ULTRIX-fma-041391); id AA01622; Wed, 22 Jun 1994 14:38:04 -0400 Date: Wed, 22 Jun 1994 14:36:41 -0400 Message-Id: <94062214364174@ucx.lkg.dec.com> From: conta@ucx.lkg.dec.com (Alex Conta, Networks Engineering - TCP/IP) To: bmanning@sesqui.net, big-internet@munnari.OZ.AU Subject: Re: assignment efficiency X-Vms-To: SMTP%"bmanning@sesqui.net" X-Vms-Cc: SMTP%"big-internet@munnari.oz.au",CONTA >From: SMTP%"bmanning@sesqui.net" 22-JUN-1994 02:19:41.89 >To: jnc@ginger.lcs.mit.edu (Noel Chiappa) >Subj: Re: assignment efficiency >>... >> looking at an address), but I wouldn't be surprised if parts are now using 5. >> >> Noel >> > >You are correct! I can measure 6 levels from here. Mr. Simpson, please return >to your homework. (Or perhaps I do not run part of the current Internet :) > >-Bill Manning Would you please give more details? Thanks, Alex From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 04:49:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12991; Thu, 23 Jun 1994 04:49: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 EAA12182; Thu, 23 Jun 1994 04:48:57 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA12161; Thu, 23 Jun 1994 04:42:48 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12829; Thu, 23 Jun 1994 04:42:38 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21538; Wed, 22 Jun 94 14:42:31 -0400 Date: Wed, 22 Jun 94 14:42:31 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406221842.AA21538@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: addressing elements Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" >> Since we need to number nodes in the network, it makes sense to use the >> same naming elements for identifying nodes in the topology. > a variety of applications ... make [it] useful to have a name which > stays the same no matter where you are. At the same time, the routing > needs names which say where you are ... You can't do both with one name! A name is not an address. Routing uses addresses. I'm using "name" in the theoretical (e.g. RFC-1498) sense, where you have "names", and "objects" which they refer to. DNS-names, addresses, locators, NSAP's, EID's - they are all names. We need to number nodes in a network Sure. The topology has nodes. Each node already has a number/name. To avoid having a separate administrative numbering space for elements of routing, the routing address can be composed from the number/name of nodes through which routing has to pass. If followed this correctly (there are a couple of possible alternative interpretations, but this one is the most likely), you're saying the topologically sensitive name (TSN for short) should be composed of the unique numbers (as you defined above, UN's for short) of the routers through which the route(s) potentially pass? Is so, this is basically the same idea as one that Ohta-san already talked about. (On the Nimrod mailing list, I think?) It was discussed at length, and had a number of problems; it wasn't really popular. I refer you to the archive for details. Therefore, it makes sense to use the same naming elements for identifying nodes in the topology to build the routing address. This sounds slightly different; are you talking about using the names of the actual network objects to generate a hierarchically structured TSN? Of course, you'll have to figure out some way to assign UN's to objects which are aggregates (i.e. pieces of the topology); there are a large variety of ways to do this. We thought about doing this in the Nimrod WG (and still may), but it made locators awfully long if each element was a globally unique label. This is the technique used for the IP source route. The SIPP Routing Header expands this to clusters of nodes, using the same naming space. I know that there are those who think a source route and a TSN are much the same, but I think this is confusing, and offbase. A TSN says *where* something is (irrespective of where you are starting from, to go there), and a source route says something about *how* to get there (from a particular source or sets of sources). > I can take a completely arbitrary random graph, and create a hierarchical > address structure for it, and you can create that hierarchy pretty much > randomly, and it will work pretty well. I beg to differ. If you take any graph, you can create a hierarchical _naming_ structure for it. It may work perfectly well for inspection, but not for routing. No, I think it will work reasonably well, but I'll talk about this in a separate message, to keep the graph theory out of this one. > If you do actually have a connectivity graph which has some structure, > then you will find the routing overhead is lower if you use an > addressing hieirarchy which takes that structure into account. The hard part is finding the structure. But my point was, we don't have a connectivity graph with heirarchical structure ... What little residual structure there is currently ... is being nibbled away by multi-homed domains. Even lowly bulletin boards are multi-homed these days. If you mean "do we have a connectivity graph which is a tree", then no, we don't have a heirarchical topology. Any time you have alternate paths, whether for reliability, or to minimize path length (q.v Hascall's recent message), you don't have a tree. This doesn't mean we don't have a connectivity graph which does have some natural structure of a "hierarchical" form, though. For instance, if you look at the bandwidths available, you may see a hierarchy there. Also, routing doesn't go *just* by optimal number of hops; these human inputs also produce hierarchical structure (i.e. provider->regional->organization->network). Yes, dealing with all the multi-homed stuff is a problem, one we've been struggling with since Dave Clark pointed it out some years ago. There are a number of ideas, but it's a very hard problem (for reason I won't get into here). So, we need to define our dynamic addressing elements using names that don't change dynamically. The same name space as node numbers. If you're talking about the TSN as a complete entity, absolutely not! These will have to change. The *elements* may have names that stay the same (and as noted, the Nimrod WG toyed with the idea). I'll wait to hear which it is you meant... Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 06:26:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15969; Thu, 23 Jun 1994 06: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 GAA12288; Thu, 23 Jun 1994 06:26:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA12274; Thu, 23 Jun 1994 06:20:58 +1000 Precedence: list Received: from vinegar.sesqui.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15812; Thu, 23 Jun 1994 06:20:56 +1000 (from bmanning@sesqui.net) Received: by vinegar.sesqui.net (4.1/SMI-4.1 Jun93 - wcm) id AA01172; Wed, 22 Jun 94 15:21:20 CDT From: bmanning@sesqui.net (William Manning) Message-Id: <9406222021.AA01172@vinegar.sesqui.net> Subject: Re: number of existing routing levels To: bsimpson@morningstar.com Date: Wed, 22 Jun 1994 15:21:19 -0500 (CDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <2749.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Jun 22, 94 02:27:00 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: 352 With CIDR allocation we have at least six tiers of address administration that I have seen & helped to build.... Internic - global SESQUINET - regional 198.64/15 Neosoft - BBS 198.64.32/19 BLKBOX - BBS 198.64.32/20 HALPC - PCgroup 198.64.32/23 BillsHome - Homenet 198.64.32/28 But perhaps this does not fit your model. -bill From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 11:39:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22466; Thu, 23 Jun 1994 09:47: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 JAA12463; Thu, 23 Jun 1994 09:46:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA12449; Thu, 23 Jun 1994 09:37:50 +1000 Precedence: list Received: from Kitten-chibb.Mcs.Net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20648; Thu, 23 Jun 1994 08:56:05 +1000 (from karl@mcs.com) Received: by kitten.mcs.com (/\==/\ Smail3.1.28.1 #28.7) id ; Wed, 22 Jun 94 17:55 CDT Received: by mercury.mcs.com (/\==/\ Smail3.1.28.1 #28.3) id ; Wed, 22 Jun 94 17:55 CDT Message-Id: From: karl@mcs.com (Karl Denninger) Subject: Re: non-geographical routing considered harmful To: john@iastate.edu (John Hascall) Date: Wed, 22 Jun 1994 17:55:49 -0500 (CDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <9406221410.AA13395@pooh.cc.iastate.edu> from "John Hascall" at Jun 22, 94 09:09:59 am X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 2102 > I would be most pleased if someone more to the front of this future bus > would discuss how IPng might improve this situation, (2 sites, ~30 miles > apart connected to 2 different providers): > > 1 router169 (129.186.169.254) 4 ms 4 ms 4 ms > 2 isu-1 (192.245.179.1) 4 ms 4 ms 4 ms > 3 [MIDnet, Lincoln] 128.242.21.1 (128.242.21.1) 12 ms 12 ms 12 ms > 4 [MIDnet, Lincoln] 192.35.171.10 (192.35.171.10) 23 ms 16 ms 12 ms > 5 t3-1.cnss81.St-Louis.t3.ans.net (140.222.81.2) 23 ms 31 ms 23 ms > 6 mf-0.cnss80.St-Louis.t3.ans.net (140.222.80.222) 27 ms 27 ms 35 ms > 7 t3-1.cnss24.Chicago.t3.ans.net (140.222.24.2) 31 ms 31 ms 31 ms > 8 t3-0.cnss40.Cleveland.t3.ans.net (140.222.40.1) 43 ms 35 ms 39 ms > 9 t3-1.cnss48.Hartford.t3.ans.net (140.222.48.2) 55 ms 55 ms 59 ms > 10 t3-2.cnss32.New-York.t3.ans.net (140.222.32.3) 55 ms 59 ms 59 ms > 11 t3-1.cnss56.Washington-DC.t3.ans.net (140.222.56.2) 62 ms 70 ms 62 ms > 12 mf-0.cnss58.Washington-DC.t3.ans.net (140.222.56.194) 62 ms 62 ms 66 ms > 13 t3-0.enss145.t3.ans.net (140.222.145.1) 62 ms 62 ms 70 ms > 14 icm-fix-e-F0.icp.net (192.203.229.245) 129 ms 66 ms 62 ms > 15 icm-dc-1-H1/0.icp.net (192.157.65.121) 70 ms 70 ms 62 ms > 16 144.228.20.4 (144.228.20.4) 70 ms 74 ms 74 ms > 17 144.228.20.1 (144.228.20.1) 102 ms 184 ms 148 ms > 18 sl-chi-3-S1/0-T1.sprintlink.net (144.228.0.161) 121 ms 98 ms 90 ms > 19 sl-chi-2-F0.sprintlink.net (144.228.129.2) 94 ms 90 ms 117 ms > 20 sl-infotex-1-S0-56k.sprintlink.net (144.228.128.194) 117 ms 266 ms 164 ms > 21 dsm6.dsmnet.com (198.202.223.38) 254 ms 133 ms 133 ms Well, ANS and Sprint could peer at somewhere other than FIX-East. That might make a significant difference, and does not require IPng. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - The Finest Internet Connectivity Modem: [+1 312 248-0900] | (shell, PPP, SLIP, leased) in Chicagoland Voice/FAX: [+1 312 248-8649] | Email "info@mcs.com". MCSNet is a CIX member. Ask about "MCSNet Rewards" | WWW: http://www.mcs.net, gopher: gopher.mcs.net From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 11:47:30 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27439; Thu, 23 Jun 1994 11:47: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 LAA12577; Thu, 23 Jun 1994 11:46:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA12563; Thu, 23 Jun 1994 11:31:05 +1000 Precedence: list Received: from mail.ntt.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26920; Thu, 23 Jun 1994 11:30:46 +1000 (from francis@cactus.slab.ntt.jp) Received: by mail.ntt.jp (8.6.8/COREMAIL.3); Thu, 23 Jun 1994 10:30:22 +0900 Received: by slab.ntt.jp (8.6.9/core-slab.s5+) id KAA17333; Thu, 23 Jun 1994 10:30:21 +0900 Received: by cactus.slab.ntt.jp (4.1/core*slab.s5) id AA10000; Thu, 23 Jun 94 10:30:21 JST Date: Thu, 23 Jun 94 10:30:21 JST From: francis@cactus.slab.ntt.jp (Paul Francis) Message-Id: <9406230130.AA10000@cactus.slab.ntt.jp> To: Greg_Minshall@Novell.COM, J.Crowcroft@cs.ucl.ac.uk Subject: Re: variable length addresses Cc: big-internet@munnari.OZ.AU > > >Thoughts? > > tradeoffs, tradeoffs, tradeoffs, the mind boggles... and spins > While I fall on the side of fixed-length, I agree that there are trade-offs. Perhaps we should work out two packet formats, one for fixed length and one for variable length, and at the plenary of the next ietf, Mockapetris officiate over a coin toss. Heads it's fixed, tails it's variable.... PF From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 13:47:01 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01442; Thu, 23 Jun 1994 13:27: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 NAA12681; Thu, 23 Jun 1994 13:26:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA12667; Thu, 23 Jun 1994 13:16:46 +1000 Precedence: list Received: from mailhub.iastate.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01058; Thu, 23 Jun 1994 13:16:41 +1000 (from john@iastate.edu) Received: from pooh.cc.iastate.edu by mailhub.iastate.edu id AA17790; Wed, 22 Jun 1994 22:16:48 -0500 Received: by pooh.cc.iastate.edu; id AA15655; Wed, 22 Jun 1994 22:16:36 -0500 Message-Id: <9406230316.AA15655@pooh.cc.iastate.edu> To: karl@mcs.com (Karl Denninger) Cc: big-internet@munnari.OZ.AU Subject: Re: non-geographical routing considered harmful In-Reply-To: Your message of Wed, 22 Jun 1994 17:55:49 -0500. Date: Wed, 22 Jun 1994 22:16:35 CDT From: John Hascall > > would discuss how IPng might improve this situation, (2 sites, ~30 miles > > apart connected to 2 different providers): > > > > 1 router169 (129.186.169.254) 4 ms 4 ms 4 ms ... > > 21 dsm6.dsmnet.com (198.202.223.38) 254 ms 133 ms 133 ms > Well, ANS and Sprint could peer at somewhere other than FIX-East. That > might make a significant difference, and does not require IPng. Well, from what I've been hearing, it seems many are proposing hierarchical address structure with the provider at the top of the hierarchy, combined with routing aggregation. So, it seems to me that the packet would reach our provider who would just send it off to the other provider via whatever route it has to that provider. It would not look further in the hierarchy to route the packet `smartly' to the other provider (indeed it couldn't, since it might not even know what further hierarchy the other provider is using). John From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 15:06:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04865; Thu, 23 Jun 1994 15:06: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 PAA12798; Thu, 23 Jun 1994 15:06:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA12776; Thu, 23 Jun 1994 14:54:54 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29569; Thu, 23 Jun 1994 12:40:22 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-16.dialip.mich.net (pm002-16.dialip.mich.net [35.1.48.97]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id WAA24599 for ; Wed, 22 Jun 1994 22:40:11 -0400 Date: Thu, 23 Jun 94 01:47:50 GMT From: "William Allen Simpson" Message-Id: <2756.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: addressing elements > From: kasten@ftp.com (Frank Kastenholz) > Bill Simpson Writes: > > > From: kasten@ftp.com (Frank Kastenholz) > > > First of all, you keep talking about enumeration of 10E15 elements. > > > You are right, 10E15 elements can be enumerated in 64 bits. However, > > > enumeration assumes 'dense' use of the space. > > > > > Not very dense. About 1E10-5. > > If there is > administrative structure in the number (and I feel that there will > be) then things will be very very different; blocks of numbers will > be given to different administrative authorities (and sub-blocks to > sub-authorities... apply recursion as desired) and those blocks won't > be densely used. > That's right, Frank. We are in violent agreement. If 64-bit element size is used for the 10**15 nodes, no matter how many levels of administration occur, a maximum of 10**-5 density is allowed. Now, who thinks that the human administration is going to be so bad that we cannot allocate 10**15 entities with less than 10**-5 inefficiency? AND, even if we can't because of long term fragmentation issues, that automatic renumbering won't cure the problem? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 15:08:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05036; Thu, 23 Jun 1994 15:08: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 PAA12828; Thu, 23 Jun 1994 15:08:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA12795; Thu, 23 Jun 1994 15:03:02 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29610; Thu, 23 Jun 1994 12:41:31 +1000 (from bill.simpson@um.cc.umich.edu) Received: from merit.edu by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA15824 Thu, 23 Jun 1994 12:41:27 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-16.dialip.mich.net (pm002-16.dialip.mich.net [35.1.48.97]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id WAA24564 for ; Wed, 22 Jun 1994 22:40:07 -0400 Date: Thu, 23 Jun 94 01:22:55 GMT From: "William Allen Simpson" Message-Id: <2755.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: addressing elements > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Therefore, it makes sense to use the same naming elements for identifying > nodes in the topology to build the routing address. > > This sounds slightly different; are you talking about using the names of > the actual network objects to generate a hierarchically structured TSN? > Of course, you'll have to figure out some way to assign UN's to objects which > are aggregates (i.e. pieces of the topology); there are a large variety of > ways to do this. > Yes, you got the interpretation on the second try. I am advocating only one way -- the SIPP Cluster. > We thought about doing this in the Nimrod WG (and still may), but it made > locators awfully long if each element was a globally unique label. > Not really. Since there are really very few opportunities for topological aggregation (2, 3, 4 -- not 11 or 16), that means only a few need to be put in the message to correctly route. > This is the technique used for the IP source route. The SIPP Routing > Header expands this to clusters of nodes, using the same naming space. > > I know that there are those who think a source route and a TSN are much the > same, but I think this is confusing, and offbase. A TSN says *where* something > is (irrespective of where you are starting from, to go there), and a source > route says something about *how* to get there (from a particular source or > sets of sources). > Yes, you are correct. The source route can be a routing fragment (of a TSN). That means the Routing Header can be even shorter. > If you mean "do we have a connectivity graph which is a tree", then no, we > don't have a heirarchical topology. Any time you have alternate paths, > whether for reliability, or to minimize path length (q.v Hascall's recent > message), you don't have a tree. > Yes! My point exactly! > This doesn't mean we don't have a connectivity graph which does have some > natural structure of a "hierarchical" form, though. For instance, if you look > at the bandwidths available, you may see a hierarchy there. Maybe you will, maybe you won't. Right now, intra-regional bandwidths tend to be much higher than inter-regional. Local can vary from low (1,200 serial) to high (FDDI). So, there is no natural point of heirarchy there. > Yes, dealing with all the multi-homed stuff is a problem, one we've been > struggling with since Dave Clark pointed it out some years ago. There are > a number of ideas, but it's a very hard problem (for reason I won't get > into here). > Whatever we come up with has to deal with it. We are going more in this direction, not less. > So, we need to define our dynamic addressing elements using names that > don't change dynamically. The same name space as node numbers. > > If you're talking about the TSN as a complete entity, absolutely not! These > will have to change. The *elements* may have names that stay the same (and > as noted, the Nimrod WG toyed with the idea). I'll wait to hear which it > is you meant... > That's exactly what I'm saying. The TSN changes dynamically (and there are hundreds of them for each node), but the names of the elements of which a TSN is composed stay the same. This is easiest to understand and manage if the same name/number space is used for both nodes and TSN elements. Otherwise, choosing among TSNs (routing) would be virtually impossible. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 16:08:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04368; Thu, 23 Jun 1994 14:47: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 OAA12760; Thu, 23 Jun 1994 14:46:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA12746; Thu, 23 Jun 1994 14:33:30 +1000 Precedence: list Received: from access1.digex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03786; Thu, 23 Jun 1994 14:33:26 +1000 (from tdarcos@access.digex.net) Received: by access1.digex.net id AA13756 (5.67b8/IDA-1.5 for big-internet@munnari.oz.au); Thu, 23 Jun 1994 00:28:23 -0400 Newsgroups: tdr.paul.private.mail Date: Thu, 23 Jun 1994 00:28:23 -0400 (EDT) From: Paul Robinson Sender: Paul Robinson Reply-To: Paul Robinson Subject: Re: addressing..... To: big-internet@munnari.OZ.AU Message-Id: <01.1994Jun23.00h16m04s.PAUL-0100000@TDR.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII From: Paul Robinson Organization: Tansin A. Darcos & Company, Silver Spring, MD USA ----- May I suggest some people take a look at my Internet RFC 1375. I suggested that the granularity of networks be redefined to change the number of end nodes in a network, or in the alternative, to set the granularity to 8 bits and define groups to represent one or more networks of the correct size. For example, I have two computers networked together and use TCP/IP, for which I use a legal assigned IP number. But guess what: the assigned IP number represents a Class C address, which means I have more than 250 IP numbers which are wasted! (Assume 0 and 255 are not used, two numbers are, which means 252 IP numbers are wasted.) Had I been able to get a 16-site address, it would have only wasted about 12 numbers (assuming 0 and 15 must not be used). I still think we are better off with fixed boundaries for assignments; it makes the software easier to manage since you can know what the field means and don't have to calculate it. The more things you have to figure, the slower your machines have to run to handle it. We could go with a 4-56-4 combination, like this: 4 Bits for network type, from 0 to 16, 56 bytes to indicate network area, and 4 bits for site number. Each network would use one or more network blocks of 4 bits. Perhaps we can indicate smaller network groups and use the same method we have now, with network sizes of 4, 8, or 16 bits depending on the number of local sites there are. Of course this brings up a problem of sizes of network tables. But we can use lookups for this, but it does still mean we might have problems if the lookup tables become too large to handle. --- Paul Robinson - Paul@TDR.COM Voted "Largest Polluter of the (IETF) list" by Randy Bush ----- The following Automatic Fortune Cookie was selected only for this message: Brooke's Law: Whenever a system becomes completely defined, some damn fool discovers something which either abolishes the system or expands it beyond recognition. From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 16:18:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05026; Thu, 23 Jun 1994 15:08: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 PAA12813; Thu, 23 Jun 1994 15:07:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA12779; Thu, 23 Jun 1994 14:54:59 +1000 Precedence: list Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29564; Thu, 23 Jun 1994 12:40:19 +1000 (from bill.simpson@um.cc.umich.edu) Received: from pm002-16.dialip.mich.net (pm002-16.dialip.mich.net [35.1.48.97]) by merit.edu (8.6.8.1/merit-1.0) with SMTP id WAA24538 for ; Wed, 22 Jun 1994 22:40:04 -0400 Date: Thu, 23 Jun 94 00:58:25 GMT From: "William Allen Simpson" Message-Id: <2754.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.OZ.AU Reply-To: bsimpson@morningstar.com Subject: Re: number of existing routing levels > From: bmanning@sesqui.net (William Manning) > With CIDR allocation we have at least six tiers of address administration that > I have seen & helped to build.... > My message clearly said "routing heirarchy", so I will discuss your message as if you had said that, instead of "address administration", which is not related to "number of existing routing levels". > Internic - global > SESQUINET - regional 198.64/15 > Neosoft - BBS 198.64.32/19 > BLKBOX - BBS 198.64.32/20 > HALPC - PCgroup 198.64.32/23 > BillsHome - Homenet 198.64.32/28 > > But perhaps this does not fit your model. > I'm not even sure how this works. Are you saying that all traffic to Sesquinet from any other source passes through an Internic global router? (I didn't know Internic ran a backbone.) Are you saying that all datagrams to BillsHome pass from Internic router through Sequinet router through Neosoft router through BLKBOX router through HALPC router to BillsHome router? How do you send a directed broadcast to the Neosoft subnetwork? I will admit that this is not a network configuration style that I have seen anywhere else. I am deeply surprised that you don't have more mesh redundancy. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 16:40:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07254; Thu, 23 Jun 1994 16:06: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 QAA12897; Thu, 23 Jun 1994 16:06:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA12894; Thu, 23 Jun 1994 16:03:05 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07128; Thu, 23 Jun 1994 16:02:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25826; Thu, 23 Jun 94 02:02:51 -0400 Date: Thu, 23 Jun 94 02:02:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406230602.AA25826@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, francis@cactus.slab.ntt.jp Subject: Re: variable length addresses Cc: jnc@ginger.lcs.mit.edu From: francis@cactus.slab.ntt.jp (Paul Francis) While I fall on the side of fixed-length This interests me. PIP had a variable length header (well, the Initial Part was fixed length, but the Transit Part and Options Part were both variable length). Can you tell us what led you to change your thinking on this issue? Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 17:07:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09466; Thu, 23 Jun 1994 17:07: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 RAA12966; Thu, 23 Jun 1994 17:06:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA12961; Thu, 23 Jun 1994 16:55:29 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08902; Thu, 23 Jun 1994 16:55:13 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25989; Thu, 23 Jun 94 02:55:05 -0400 Date: Thu, 23 Jun 94 02:55:05 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406230655.AA25989@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, john@iastate.edu, karl@mcs.com Subject: Re: non-geographical routing considered harmful Cc: jnc@ginger.lcs.mit.edu From: John Hascall Well, from what I've been hearing, it seems many are proposing hierarchical address structure with the provider at the top of the hierarchy, combined with routing aggregation. ... the packet would reach our provider who would just send it off to the other provider via whatever route it has to that provider. It would not look further in the hierarchy to route the packet `smartly' to the other provider.. It has nothing to do with the hierarchical address structure. This is only the case if the routing aggregation goes so far as to enforce hierarchical routing. If you (or anyone) doesn't want hierarchical routing, don't turn the "reduce routing overhead" knob (a.k.a "routing aggregation" knob) so hard. Of course, you pay the price (in more routing overhead), but life's full of tradeoffs. (indeed it couldn't, since it might not even know what further hierarchy the other provider is using). You are correct that you have to know something about the routing inside the other provider to do what's called "optimal entry point selection", and to do *that* you have to be able to "speak the routing over there" some, which means you have to be able to parse their addresses a bit. There are two simple ways to do this. The first is to use a self parsing format (like DNS names, or UNIX filenames); their hierarchical boundary elements (in routes they pass to you, and in destinations in their part of the hierarchy) are apparent. The second is to pass around masks, which perform effectively the same function for non-self parsing formats. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 17:26:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10066; Thu, 23 Jun 1994 17:26: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 RAA13007; Thu, 23 Jun 1994 17:26:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA12982; Thu, 23 Jun 1994 17:08:53 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09506; Thu, 23 Jun 1994 17:08:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26100; Thu, 23 Jun 94 03:08:41 -0400 Date: Thu, 23 Jun 94 03:08:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406230708.AA26100@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: number of existing routing levels Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" My message clearly said "routing heirarchy", so I will discuss your message as if you had said that, instead of "address administration", which is not related to "number of existing routing levels". The issue here is the number of *naming* levels (i.e. levels at which it is intended that routing data be aggregated), which is probably fairly related, in the real world, to the number of different address administration levels. I'm not positive I understand (in a non-hierarchical routing system) what a "routing level" is, anyway, since the existence of routing data above and beyond the minimal (i.e. hierarchical set) can result in a single "longest match" routing decision being made which spans several naming levels; is this a single routing level, or not? Are you saying that all datagrams to BillsHome pass from Internic router through Sequinet router through Neosoft router through BLKBOX router through HALPC router to BillsHome router? This sounds like the same kind of "hierarchial addresses mean hierarchical routing" confusion that another thread is chasing. Maybe they've got the routing set up that way, maybe they don't. It's irrelevant to how they do the addressing, although the addressing can effect *how* you can set up the routing... Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 17:46:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11020; Thu, 23 Jun 1994 17:46: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 RAA13041; Thu, 23 Jun 1994 17:46:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA13036; Thu, 23 Jun 1994 17:43:36 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10907; Thu, 23 Jun 1994 17:43:32 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 23 Jun 94 16:36:43 +0900 From: Masataka Ohta Message-Id: <9406230736.AA17886@necom830.cc.titech.ac.jp> Subject: Re: Why variable length? To: kasten@ftp.com Date: Thu, 23 Jun 94 16:36:42 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9406221520.AA29901@mailserv-D.ftp.com>; from "Frank Kastenholz" at Jun 22, 94 11:20 am X-Mailer: ELM [version 2.3 PL11] > > Thus, a 64 bit EID space is enough for us with yet another safety > > factor of 256. > > > > Isn't it safe enough? > > Only when enumerating them. And only when the space used to enumerate > them is densely used. I believe that EIDs will be allocated in an > administrative hierarchy and And cable TV companies of your reasoning do not have much hierarchy. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 18:06:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11776; Thu, 23 Jun 1994 18:06: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 SAA13078; Thu, 23 Jun 1994 18:06:38 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA13071; Thu, 23 Jun 1994 17:56:34 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11379; Thu, 23 Jun 1994 17:56:26 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406230756.11379@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 23 Jun 1994 08:56:00 +0100 To: Dave Katz Cc: john@iastate.edu, big-internet@munnari.OZ.AU Subject: Re: non-geographical routing considered harmful In-Reply-To: Your message of "Wed, 22 Jun 94 10:52:53 PDT." <199406221752.KAA25046@feta.cisco.com> Date: Thu, 23 Jun 94 08:55:57 +0100 From: Jon Crowcroft > I would be most pleased if someone more to the front of this future bus > would discuss how IPng might improve this situation, (2 sites, ~30 miles > apart connected to 2 different providers): > 5 t3-1.cnss81.St-Louis.t3.ans.net (140.222.81.2) 23 ms 31 ms 23 ms ...... > 20 sl-infotex-1-S0-56k.sprintlink.net (144.228.128.194) 117 ms 266 ms 164 ms 1. say thank you that you are not in europe:-) 2. ask your providers why they have so many internal hops, and why they have engineered the links so your delays are so high. 3. ask the phone companies how many exchanges you go thru for a similar 2-carrier call.... 4. ask the postal service how many sorting offices.... cheers jon From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 18:08:14 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11809; Thu, 23 Jun 1994 18:08: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 SAA13093; Thu, 23 Jun 1994 18:07:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA13057; Thu, 23 Jun 1994 17:54:39 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11291; Thu, 23 Jun 1994 17:54:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26188; Thu, 23 Jun 94 03:54:34 -0400 Date: Thu, 23 Jun 94 03:54:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406230754.AA26188@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, bsimpson@morningstar.com Subject: Re: addressing elements Cc: jnc@ginger.lcs.mit.edu From: "William Allen Simpson" > This sounds slightly different; are you talking about using the names of > the actual network objects to generate a hierarchically structured TSN? Yes, you got the interpretation on the second try. Well, I think you misunderstood me, since your comment below ("there are hundreds of them for each node") pretty clearly indicates you meant the first variety (the kind Ohta-san came up with). See comments below. > We thought about doing this in the Nimrod WG (and still may), but it > made locators awfully long if each element was a globally unique label. Not really. Since there are really very few opportunities for topological aggregation (2, 3, 4 -- not 11 or 16), that means only a few need to be put in the message to correctly route. Kleinrock and Kamoun indicate that for the IPng target of 10^9 nodes (for which I read nets, since that's the lowest level objects the routing tracks directly), for optimal routes, to get an l/l* ratio (i.e. the ratio of actual routing table size to theoretical minimal routing table size) of better than 10:1 (i.e. 90% inefficient) you need 5 levels, which of course assumes a perfectly optimal addressing hierarchy (i.e. all branches contain the same number of levels, and the same degree of fanout at each level). So in practise, with real address heirarchies, you'd be off from that by a factor of a few levels. Try to jack the routing state efficiency, say, to 50%, and you need more; the K+K graph says about 8 (before adding some for the inefficient real-world addressing hierarchy). Throw in policy, and that's a few more. Etc, etc. 12 level addresses will probably be common in not too many years. (At an average of one and a half bytes per, figuring some will be two bytes, and some one, that's 18 bytes, before we get to the MAC address, but I digress.) > A TSN says *where* something is (irrespective of where you are starting > from, to go there), and a source route says something about *how* to get > there (from a particular source or sets of sources). The source route can be a routing fragment (of a TSN). This is back to front. A source route, or a route fragment (i.e. a piece of a source route) by definition cannot be a *piece* of a TSN, since they have to *consist* of TSN's. They have to consist of TSN's since the routing can't work on UN's. The TSN changes dynamically (and there are hundreds of them for each node), but the names of the elements of which a TSN is composed stay the same. So, this *is* the scheme Ohta-san came up with; the TSN consists of the UN's of the routers through which one travels to get to that destination. (If you were going what Nimrod suggested, and using globally unique labels for the elements of a locator, instead of labels which are only unique within the enclosing area, you'd still have only one locator per host interface, basically.) These aren't a good idea; please read the Nimrod archives to see why. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 19:26:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14898; Thu, 23 Jun 1994 19:26: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 TAA13203; Thu, 23 Jun 1994 19:26:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA13172; Thu, 23 Jun 1994 19:22:36 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14661; Thu, 23 Jun 1994 19:22:23 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 23 Jun 94 18:15:28 +0900 From: Masataka Ohta Message-Id: <9406230915.AA18579@necom830.cc.titech.ac.jp> Subject: Re: number of existing routing levels To: bmanning@sesqui.net (William Manning) Date: Thu, 23 Jun 94 18:15:27 JST Cc: bsimpson@morningstar.com, big-internet@munnari.OZ.AU In-Reply-To: <9406222021.AA01172@vinegar.sesqui.net>; from "William Manning" at Jun 22, 94 3:21 pm X-Mailer: ELM [version 2.3 PL11] > With CIDR allocation we have at least six tiers of address administration that > I have seen & helped to build.... > > > Internic - global > SESQUINET - regional 198.64/15 > Neosoft - BBS 198.64.32/19 > BLKBOX - BBS 198.64.32/20 > HALPC - PCgroup 198.64.32/23 > BillsHome - Homenet 198.64.32/28 Yes, with 32 bit IP, we may need bitwise-adjustable masks for layered administration of EIDs, which has nothing to do with locator levels. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 19:40:05 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15233; Thu, 23 Jun 1994 19:40: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 TAA13231; Thu, 23 Jun 1994 19:39:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA13222; Thu, 23 Jun 1994 19:37:13 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14558; Thu, 23 Jun 1994 19:17:46 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 23 Jun 94 18:11:12 +0900 From: Masataka Ohta Message-Id: <9406230911.AA18536@necom830.cc.titech.ac.jp> Subject: Re: addressing elements To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 23 Jun 94 18:11:10 JST Cc: big-internet@munnari.OZ.AU, bsimpson@morningstar.com, jnc@ginger.lcs.mit.edu In-Reply-To: <9406230754.AA26188@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 23, 94 3:54 am X-Mailer: ELM [version 2.3 PL11] > > This sounds slightly different; are you talking about using the names of > > the actual network objects to generate a hierarchically structured TSN? > > Yes, you got the interpretation on the second try. > > Well, I think you misunderstood me, since your comment below ("there are > hundreds of them for each node") pretty clearly indicates you meant the first > variety (the kind Ohta-san came up with). See comments below. As I think EID->locator mapping is the weak point of NIMROD, I just used SIPP's routing header mechanism and how it can work with NIMROD and DNS without difficulty. > > We thought about doing this in the Nimrod WG (and still may), but it > > made locators awfully long if each element was a globally unique label. > > Not really. Since there are really very few opportunities for topological > aggregation (2, 3, 4 -- not 11 or 16), that means only a few need to be > put in the message to correctly route. > > Kleinrock and Kamoun indicate that for the IPng target of 10^9 nodes (for > which I read nets, since that's the lowest level objects the routing tracks > directly), for optimal routes, For optimal routes, you must use flat routing. > to get an l/l* ratio (i.e. the ratio of actual > routing table size to theoretical minimal routing table size) of better than > 10:1 (i.e. 90% inefficient) you need 5 levels, Your goal is completely bogus. As memory is cheap and line speed inceasing, there is no merit to minimize routing table size. Instead, we should use as large a routing table as practically possible for near-optimal routing and other reasons. For example, for geography based routing, we should have a top level domain consisting of thousands or tens of thousands of domains connected as mesh. Having a few top level providers and connect them at only a few points results in points of excessive load concentration and is no good. If the goal is 10^9 nodes, 10^1 will be processed within datalink layer (that is, a subnet) and we need two layers with 10^4 members whose support is no difficult even today. > 12 level addresses will probably be common in not too many years. I wrongly thought that you now understood your model is wrong at least because of load concentration. > So, this *is* the scheme Ohta-san came up with; the TSN consists of the UN's > of the routers through which one travels to get to that destination. (If you > were going what Nimrod suggested, and using globally unique labels for the > elements of a locator, instead of labels which are only unique within the > enclosing area, you'd still have only one locator per host interface, > basically.) One of the major difficulty of locally unique labels is that something like connection setup is necessary for the source to have EID->locator mapping. > These aren't a good idea; please read the Nimrod archives to see why. > > Noel Because you failed to correctly estimate the difficulty of EID->locator mapping. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 19:40:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15238; Thu, 23 Jun 1994 19:40: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 TAA13233; Thu, 23 Jun 1994 19:39:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA13219; Thu, 23 Jun 1994 19:33:24 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14596; Thu, 23 Jun 1994 19:19:07 +1000 (from kre@munnari.OZ.AU) To: John Hascall Cc: big-internet@munnari.OZ.AU Subject: Re: non-geographical routing considered harmful In-Reply-To: Your message of "Wed, 22 Jun 1994 22:16:35 CDT." <9406230316.AA15655@pooh.cc.iastate.edu> Date: Thu, 23 Jun 1994 19:19:02 +1000 Message-Id: <24134.772363142@munnari.OZ.AU> From: Robert Elz Initially, I, and probably a lot of other people, thought that you were asking a serious question, which could conceivably come under the B-I banner, but doesn't fit well. Now I see that you were attempting to make a point (the long way, in multiple messages), that fits in exactly with B-I... Date: Wed, 22 Jun 1994 22:16:35 CDT From: John Hascall Message-ID: <9406230316.AA15655@pooh.cc.iastate.edu> Well, from what I've been hearing, it seems many are proposing hierarchical address structure with the provider at the top of the hierarchy, combined with routing aggregation. There seems to be a view around that hierarchical, that is, topological, routing necessarily means that to send from one lcoation to another packets must, of necessity, climb up through some series of providers to the common level, and then start down again. Route aggregation is certainly an aim, but that doesn't mean that it need to be total. The model I see somewhere in my tiny brain has natural route aggregation happening, which would be just fine for most subscribers, but where if you wanted your route exchanged in some other area, you'd approach the appropriate body (which may be a private company, provider, ...) and ask them to advertise a route to you via the path you prefer traffic from that destination to take (always assuming that links are up etc of course, nothing non-dynamic about this). Now in general this simply will not scale, which is why route aggregation is needed in the first place - but its obviously going to be a needed facility, so there needs to be some mechanism to allow it to scale (not to work, simply allowing the route into the network will make it work). The mechanism I'd adapt is simply to have those other providers charge you for supporting your route. That way if the number of these external routes gets very large the provider will collect lots of $'s to allow it to support higher capacity routers to manage all this extra data. I have no idea what a route would be worth, but $10 per route per month may be reasonable (per provider in which you need your route advertised). That way you could have your location, and a good path to you, advertised in your local area reasonably cheaply, but you would probably not want to bother advertising it here in Australia - partly because the cost of advertising it in all the intermediate providers would grow quite quickly, and partly because the "natural" (that is, follow the provider) routing will probably get data to you from here via a path that's nearly as good for free. This scales well and allows topological addressing without difficulties - including where you connect to multiple providers (the fee they charge you for connecting would include the cost to advertise your route, you'd probably want to advertise the extra route in a few other areas as well). Not all your traffic will come via what you may consider to be the optimal route, but no-one gets all that they desire. kre From owner-Big-Internet@munnari.OZ.AU Thu Jun 23 23:45:37 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22264; Thu, 23 Jun 1994 23:27: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 XAA13487; Thu, 23 Jun 1994 23:26:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA13484; Thu, 23 Jun 1994 23:25:06 +1000 Precedence: list Received: from ftp.std.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22063; Thu, 23 Jun 1994 23:24:54 +1000 (from hcb@world.std.com) Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0) id JAA26784; Thu, 23 Jun 1994 09:21:44 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA07988; Thu, 23 Jun 1994 09:21:43 -0400 From: hcb@world.std.com (Howard C Berkowitz) Message-Id: <199406231321.AA07988@world.std.com> Subject: Re: number of existing routing levels To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 23 Jun 1994 09:21:42 -0400 (EDT) Cc: big-internet@munnari.OZ.AU, bsimpson@MorningStar.Com, jnc@ginger.lcs.mit.edu In-Reply-To: <9406230708.AA26100@ginger.lcs.mit.edu> from "Noel Chiappa" at Jun 23, 94 03:08:41 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2245 > > From: "William Allen Simpson" > > My message clearly said "routing heirarchy", so I will discuss your > message as if you had said that, instead of "address administration", > which is not related to "number of existing routing levels". > > The issue here is the number of *naming* levels (i.e. levels at which it is > intended that routing data be aggregated), which is probably fairly related, > in the real world, to the number of different address administration levels. Let me follow up on the issue of administration. Someone raised the point (Bob Moskowitz?) that we needed to have structures that were under- standable by a "CNE," as opposed to a routing architect. In my agony/ecstasy professional life, agony part ;-), I teach Cisco software configuration to typical rout_er_ administrators. A CNE is often the more advanced level of these real-world students. I have been making an informal study of the number of levels with which students can cope. In this case, I am speaking of addressing and of routing hierarchy. My general sense is that most can deal with two-level, and with three-level as long as the computation does not become too complex. Perhaps 5-10% either cannot, or more importantly will not, cope with non-octet-aligned subnet masks. VLSM is not strictly part of the course, and I teach it as additional material perhaps 60% of the time. This typically loses another 20%. Why am I raising these points? I believe any discussion of administration needs to consider the user. This is not to say that the user has to deal with all the nuances of configuration and hierarchical routing algorithms, but I believe we need to come up with a "reasonability" test for conceptual complexity of the structures (naming, addressing, EID, etc.) that a typical end user administrator can follow. While we probably need levels of complexity beyond that, those additional levels will need to come from algorithms, AI, or possibly the provider (when present). What are the list's opinions on complexity levels that users can cope with? Should there be a complexity (or administration simplicity) rule in the requirements for IPng and NIMROD routers? Howard > From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 02:42:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22982; Thu, 23 Jun 1994 23:46: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 XAA13519; Thu, 23 Jun 1994 23:46:40 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA13498; Thu, 23 Jun 1994 23:29:12 +1000 Precedence: list Received: from ftp.std.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22340; Thu, 23 Jun 1994 23:29:04 +1000 (from hcb@world.std.com) Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0) id JAA26984; Thu, 23 Jun 1994 09:26:26 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA10321; Thu, 23 Jun 1994 09:26:24 -0400 From: hcb@world.std.com (Howard C Berkowitz) Message-Id: <199406231326.AA10321@world.std.com> Subject: Re: number of existing routing levels To: bsimpson@MorningStar.Com Date: Thu, 23 Jun 1994 09:26:24 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <2754.bill.simpson@um.cc.umich.edu> from "William Allen Simpson" at Jun 23, 94 00:58:25 am X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1612 > > > From: bmanning@sesqui.net (William Manning) > > With CIDR allocation we have at least six tiers of address administration that > > I have seen & helped to build.... > > > which is not related to "number of existing routing levels". > > > > Internic - global > > SESQUINET - regional 198.64/15 > > Neosoft - BBS 198.64.32/19 > > BLKBOX - BBS 198.64.32/20 > > HALPC - PCgroup 198.64.32/23 > > BillsHome - Homenet 198.64.32/28 > > > > But perhaps this does not fit your model. > > > I'm not even sure how this works. > > Are you saying that all traffic to Sesquinet from any other source > passes through an Internic global router? (I didn't know Internic ran a > backbone.) > > Are you saying that all datagrams to BillsHome pass from Internic router > through Sequinet router through Neosoft router through BLKBOX router > through HALPC router to BillsHome router? > > How do you send a directed broadcast to the Neosoft subnetwork? > > I will admit that this is not a network configuration style that I have > seen anywhere else. I am deeply surprised that you don't have more > mesh redundancy. Unfortunately, I see this sort of configuration not infrequently in commercial sites whose legacy is multiplexer or mainframe networks. This is not to say it is optimal, but it is culturally what many users will do. It is also something that may economically be necessary in a geographically diverse network where the additional links needed for mesh topologies are not affordable. In such a case, users often opt for switched network restoral rather than true meshes. Howard From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 04:27:17 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02133; Fri, 24 Jun 1994 04:27: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 EAA13905; Fri, 24 Jun 1994 04:26:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA13886; Fri, 24 Jun 1994 04:14:51 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01707; Fri, 24 Jun 1994 04:14:41 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id OAA06050; Thu, 23 Jun 1994 14:14:12 -0400 Date: Thu, 23 Jun 1994 14:14:12 -0400 From: Vadim Antonov Message-Id: <199406231814.OAA06050@titan.sprintlink.net> To: J.Crowcroft@cs.ucl.ac.uk, dkatz@cisco.com Subject: Re: non-geographical routing considered harmful Cc: big-internet@munnari.OZ.AU, john@iastate.edu > I would be most pleased if someone more to the front of this future bus > would discuss how IPng might improve this situation, (2 sites, ~30 miles > apart connected to 2 different providers): >2. ask your providers why they have so many internal hops, and why >they have engineered the links so your delays are so high. Nearly half of those hops are across FDDIs connecting routers in a cluster. I don't know how to engineer higher speed of light to reduce the delays on long-haul links. --vadim From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 04:33:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01169; Fri, 24 Jun 1994 03:46: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 DAA13845; Fri, 24 Jun 1994 03:46:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA13829; Fri, 24 Jun 1994 03:37:59 +1000 Precedence: list Received: from bru.mayo.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00868; Fri, 24 Jun 1994 03:37:40 +1000 (from martinr@mayo.EDU) Received: from orbison (orbison.mayo.edu) by bru.mayo.EDU (4.1/SMI-4.0) id AA09294; Thu, 23 Jun 94 12:37:33 CDT Received: by orbison (4.1/SMI-4.0) id AA09227; Thu, 23 Jun 94 12:42:05 CDT Date: Thu, 23 Jun 94 12:42:05 CDT From: martinr@mayo.EDU (Robert E. Martin) Message-Id: <9406231742.AA09227@orbison> To: big-internet@munnari.OZ.AU Subject: help help From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 04:35:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29261; Fri, 24 Jun 1994 02:47: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 CAA13741; Fri, 24 Jun 1994 02:46:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA13735; Fri, 24 Jun 1994 02:46:20 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23485; Thu, 23 Jun 1994 23:56:57 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Thu, 23 Jun 1994 09:56:47 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 23 Jun 1994 09:56:47 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA11514; Thu, 23 Jun 94 09:54:55 EDT Date: Thu, 23 Jun 94 09:54:55 EDT Message-Id: <9406231354.AA11514@mailserv-D.ftp.com> To: john@iastate.edu Subject: Re: non-geographical routing considered harmful From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 4238 > From: John Hascall > > Well, from what I've been hearing, it seems many are proposing > hierarchical address structure with the provider at the top > of the hierarchy, combined with routing aggregation. > > So, it seems to me that the packet would reach our provider > who would just send it off to the other provider via whatever > route it has to that provider. It would not look further in > the hierarchy to route the packet `smartly' to the other provider > (indeed it couldn't, since it might not even know what further > hierarchy the other provider is using). John, The routing and locator aggregation sub-systems are orthogonal to the forwarding subsystem. For example, consider a network that might look like this: +--------------+ +--------------+ | Provider A |--------| Provider B | +--------------+ L2 +--------------+ | L1 | L3 +--------------+ +--------------+ | University C | | Company D | +--------------+ +--------------+ The hierarchical locators for University C and Company D might be A:C and B:D, respectively. Provider A would 'advertise' into Provider B (over link L2) that it can reach all places with locator prefix A. Provider B would advertise into Company D (over link L3) that it could reach all places with locator prefix A as well as all places with locator prefix B (except places with locator prefix B:D). A routing table someplace in Company D might have the following entries: Destination Link A:* L3 B:* L3 B:D If the physical topology of the network is as I've drawn in the above diagram then packets going from Company D to University C would go along the path D->B->A->C. No form of Internetwork Protocol and Routing/Addressing Architecture can bridge the gap between C and D if there is no connection there. Now, suppose that the physical topology is as follows, with a link between B and C, drawn with '=' signs. +--------------+ +--------------+ | Provider A |--------| Provider B | +--------------+ L2 +--------------+ | L1 | L3 +--------------+ +--------------+ | University C |========| Company D | +--------------+ L4 +--------------+ The hierarchical locators are the same as in the earlier example, as are the advertisements. There is also an additional advertisement: University C will advertise over link L4, into Company D that A:C can be reached over that link. Routers in Company D will have routing tables that show something like: Destination Link A:* L3 A:C L4 B:* L3 B:D So, to send a packet from Company D to University C, a router would look at the routing table and do something like a longest match search, seeing that it can get to A:* over L3, but to A:C (its desired destination) over L4, and since the A:C entry is a longer match for the destination, this router would chose L4. There are, of course, more complications. For example, we might want to limit the traffic over L4 to just stuff between Company D and University C (otherwise it would become an alternate path between the two providers). Company D would then NOT advertise reachability to A:C over link L3. By 'advertise reachability' I do not strictly mean something like what is seen in a RIP packet. It is short hand for information disseminated by the routing information dissemination system... It could be simple Distance-Vector stuff ala RIP, it could be some form of link state advertisement ala OSPF, it could be maps ala Nimrod, it could be magic. Also, of course, more than just reachability may be advertised. All sorts of additional attributes (usage and charging policies, qos/tos, and so on) might be included in the disseminated information. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 04:36:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00551; Fri, 24 Jun 1994 03:26: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 DAA13813; Fri, 24 Jun 1994 03:26:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA13799; Fri, 24 Jun 1994 03:10:47 +1000 Precedence: list Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28246; Fri, 24 Jun 1994 02:18:20 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA17527; Thu, 23 Jun 94 09:20:24 -0700 Date: Thu, 23 Jun 94 09:20:24 -0700 From: Eric Fleischman Message-Id: <9406231620.AA17527@atc.boeing.com> To: big-internet@munnari.OZ.AU Subject: Re: number of existing routing levels Dear Bills, I believe that this thread started when I gave nine or so reasons which cumulatively led me to conclude that SIPP's 8 byte hierarchical addressing structure could not satisfy the Internet's long term needs nor Boeing's medium term needs and that SIPP, therefore, would probably be advised to seriously consider 16 byte addressing. One of these stated reasons was that I believe that Boeing will probably need five levels of internal addressing hierarchy. In my messages I explicitly stated that I was not discussing routing hierarchy but only addressing hierarchy in order to keep the discussion "focussed" (i.e., the interaction between these potentially related subjects (addressing and routing) has previously caused very large discussions on this list in the past and I only wanted to focus on Large Corporation's address administration needs). I, personally, did not recognize in Bill Simpson's replies that he was discussing routing hierarchy rather than addressing hierarchy until his latest posting -- despite his clear use of the word "routing". Perhaps this recognition will aid in mutual understanding? In any case, I believe that the topic for this thread should remain addressing hierarchy because this key address administration issue is at the heart of "dense versus sparse" addressing and the other address administration themes we have been discussing on this thread over the past week or so. Sincerely yours, --Eric Fleischman =From: "William Allen Simpson" => From: bmanning@sesqui.net (William Manning) => With CIDR allocation we have at least six tiers of address administration that => I have seen & helped to build.... => =My message clearly said "routing heirarchy", so I will discuss your =message as if you had said that, instead of "address administration", =which is not related to "number of existing routing levels". => Internic - global => SESQUINET - regional 198.64/15 => Neosoft - BBS 198.64.32/19 => BLKBOX - BBS 198.64.32/20 => HALPC - PCgroup 198.64.32/23 => BillsHome - Homenet 198.64.32/28 => => But perhaps this does not fit your model. => =I'm not even sure how this works. From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 04:37:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29370; Fri, 24 Jun 1994 02:50: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 CAA13756; Fri, 24 Jun 1994 02:50:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA13738; Fri, 24 Jun 1994 02:46:31 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23534; Thu, 23 Jun 1994 23:58:21 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Thu, 23 Jun 1994 09:58:18 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 23 Jun 1994 09:58:18 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA11517; Thu, 23 Jun 94 09:54:57 EDT Date: Thu, 23 Jun 94 09:54:57 EDT Message-Id: <9406231354.AA11517@mailserv-D.ftp.com> To: bsimpson@MorningStar.Com Subject: Re: addressing elements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 4580 > > > > First of all, you keep talking about enumeration of 10E15 elements. > > > > You are right, 10E15 elements can be enumerated in 64 bits. However, > > > > enumeration assumes 'dense' use of the space. > > > > > > > Not very dense. About 1E10-5. > > > > If there is > > administrative structure in the number (and I feel that there will > > be) then things will be very very different; blocks of numbers will > > be given to different administrative authorities (and sub-blocks to > > sub-authorities... apply recursion as desired) and those blocks won't > > be densely used. > > > That's right, Frank. We are in violent agreement. > > If 64-bit element size is used for the 10**15 nodes, no matter how many > levels of administration occur, a maximum of 10**-5 density is allowed. > > Now, who thinks that the human administration is going to be so bad that > we cannot allocate 10**15 entities with less than 10**-5 inefficiency? Bill, again, it depends on how the administrative structure is set up and what operations are to be performed on these numbers. Just asserting that we will be able to have better than 10**-5 inefficiency is simply not good enough. You have to show it. Suppose that we come up with a numbering plan that divides the 8-byte unique name into two parts, an owner field and an id field. If someone wants some numbers, they go to a numbering authority, who gives them an 'owner' number. Then this owner can do whatever they want with the 'owner' field. The numbers look like: I am using, as an assumption here, that we want to use these unique names to do lookups into DNS. Eg, if I have a packet, I might want to find out who sent it -- so I'd have to do the equivalent of an in-addr.arpa lookup. This implies that some hierarchy is definitely needed. Zones need to be delegated down the DNS hierarchy. Given a Unique Name for someplace within a particular DNS Zone, the root servers have to eventually get you to an authoritative server for that Zone. Lets assume that the number of 'owners' is going to be approximately equal to the number of 2nd level domains (i.e. all the 'foos' of foo.com, foo.edu, foo. and so on). In TODAY'S Internet this number is well over 100,000, not yet over 1,000,000. So 20 bits would be enough to enumerate all these domains -- if we did it 'flatly'. How many would be needed in the future? 2**32 may well be adequate. But, we are already facing scaling problems with DNS servers. The .com zone is already too big to reasonably handle (look into the big-zone work). These zones are growing faster than the ability of the top-level servers to handle them. My conclusion is that if we have problems handling O(100,000) domains, when we get to several million, things will only be worse. What's do we do? We could assume that computers will grow fast enough, or the Internet slow enough, that this isn't a real problem. I do not think that this is a viable solution -- though it may be, feel free to convince me :-) Or we could distribute the load; which to me implies more hierarchy. There might have to be 2 or 3 levels of hierarchy in these Unique Names before we get to the 'local' part. Now the names might be: Let's assume a 1,000,000:1 aggregation in these things. Two levels of hierarchy would give 1,000,000,000,000 possible names (hopefully enough! :-) with 1,000 individual names at the . Simple bit adding here gives us 20 bits for each of the 2 hierarchy levels plus 10 bits at the local-part level; for 50 bits. Will certainly fit into 64 bits. Except for psychology --- administrators will probably want to have everything on byte-boundaries. So each of the 2 levels will be 3-bytes long, and the local-part will be 2 bytes long. This gives exactly 8 bytes. Still pretty good, eh. Of course, my math assumes optimum aggregation in the top levels. As an administrative matter, we might only do ~1000:1 aggregating, which would require 4 levels, at 2 bytes/level... But for things like auto-configuration, we might want to use an IEEE 802 number for the local part. Now we'd need a 6-byte local part, not a 2-byte local part. 12-byte Unique names now... My conclusion: 8 byte unique names can probably be made to just work. But we will be cutting things very close. 16 byte unique names should not be a problem. There should be plenty of margin. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 05:51:15 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03841; Fri, 24 Jun 1994 05: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 FAA13951; Fri, 24 Jun 1994 05:06:44 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA13948; Fri, 24 Jun 1994 04:49:18 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03409; Fri, 24 Jun 1994 05:08:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01718; Thu, 23 Jun 94 15:08:50 -0400 Date: Thu, 23 Jun 94 15:08:50 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406231908.AA01718@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: help Cc: jncjnc@ginger.lcs.mit.edu From: martinr@mayo.edu (Robert E. Martin) help A feeling held pretty unanimously, I'm sure! :-) Noel From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 08:57:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06417; Fri, 24 Jun 1994 06:46: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 GAA14041; Fri, 24 Jun 1994 06:26:45 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA14027; Fri, 24 Jun 1994 06:14:25 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05982; Fri, 24 Jun 1994 06:33:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02848; Thu, 23 Jun 94 16:33:55 -0400 Date: Thu, 23 Jun 94 16:33:55 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406232033.AA02848@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: addressing elements Cc: jnc@ginger.lcs.mit.edu From: Masataka Ohta As I think EID->locator mapping is the weak point of NIMROD We only talked about doing that mapping as an interim kludge to allow interoperability with unchanged hosts. The basic design does not use it. > Kleinrock and Kamoun indicate that for the IPng target of 10^9 nodes (for > which I read nets, since that's the lowest level objects the routing > tracks directly), for optimal routes, For optimal routes, you must use flat routing. For truly optimal routes, yes; I merely meant to indicate that one would be computing routes that were as optimal as possible within that addressing hierarchy. (They prove that in large graphs you can get fairly optimal, and in fact, they were able to place an upper bound on the increase in path lengths due to use of hierarchical addressing, along with hierarchical routes). > to get an l/l* ratio (i.e. the ratio of actual routing table size to > theoretical minimal routing table size) of better than 10:1 (i.e. 90% > inefficient) you need 5 levels, we should use as large a routing table as practically possible for near-optimal routing and other reasons. A better counterpoint would be to mention that K+K assume lots of very tiny layers, which is somthign I spaced on in that message. E.g. for a 10^9 node graph, they show the shortest routing tables are given by 20 layers, with a fanout of 2/3 at each layer. Presumably the use of fewer, and larger, layers would provide routes even better than the fairly good ones mentioned above. Of course, this is all in the context of graphs which can be characterized by single metrics, which is not really very applicable directly... If the goal is 10^9 nodes, 10^1 will be processed within datalink layer (that is, a subnet) I was speaking of "graph nodes" there; the 10^9 was the number of nets. I wrongly thought that you now understood your model is wrong at least because of load concentration. I agree load needs to be shared across multiple connecting points, but continue to disagree that hierarchical addresses make this substantially more difficult. Noel From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 10:32:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13933; Fri, 24 Jun 1994 10:32: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 JAA14243; Fri, 24 Jun 1994 09:06:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA14177; Fri, 24 Jun 1994 08:47:06 +1000 Precedence: list Received: from ftp.std.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08008; Fri, 24 Jun 1994 07:48:42 +1000 (from hcb@world.std.com) Received: from world.std.com by ftp.std.com (8.6.8.1/Spike-8-1.0) id RAA28765; Thu, 23 Jun 1994 17:48:38 -0400 Received: by world.std.com (5.65c/Spike-2.0) id AA27201; Thu, 23 Jun 1994 17:48:37 -0400 From: hcb@world.std.com (Howard C Berkowitz) Message-Id: <199406232148.AA27201@world.std.com> Subject: Re: number of existing routing levels To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 23 Jun 1994 17:48:36 -0400 (EDT) Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406232042.AA02945@ginger.lcs.mit.edu> from "Noel Chiappa" at Jun 23, 94 04:42:22 pm X-Mailer: ELM [version 2.4 PL21] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2212 > > From: hcb@world.std.com (Howard C Berkowitz) > > Someone raised the point ... that we needed to have structures that were > under-standable by a "CNE," as opposed to a routing architect. ... I have > been making an informal study of the number of levels with which students > can cope. ... My general sense is that most can deal with two-level, and > with three-level as long as the computation does not become too complex. > > How much of this is atttributable to the crufty way we do multi-level > addresses in IPv4? Do they should any signs of being confused by DNS names, or > filenames, with many levels? Would 's with similar clean > ways of showing levels be equally easily understood? There is no question that the dotted decimal notation and the lack of relationship of bytes to fields is a large part of the problem. DNS names present much less of a problem, but there are still subtleties that cause confusion. Real example: An unnamed U.S. state had its naming structure held up for some time, because the governor's office felt that his/her status would only be properly indicated if their _office_ was "the top of the tree" as .gov. It took a significant amount of time for the network designers to convince them that they really wanted to be gov..gov. Beyond the issue of basic IP masking, VLSM seems to be an especially opaque idea, as does anything else that aliases or restricts. A very common error in Cisco configurations is to include commands to advertise every network known to the admin, as opposed to the ones to which the router is adjacent. > > I believe we need to come up with a "reasonability" test for conceptual > complexity of the structures ... that a typical end user administrator can > follow. > > I agree, and that's one factor in my preference for variable-length > topologically-sensitive internetwork-level "names" (VL-TSILN's - sigh, I'm > reduced to ISOspeak by the ability of people here to damage short names :-). > Apropos of ISOspeak, I was once asked if a British networking engineer was knighted, would he have an Application Entity Title? Howard, a recovering OSIholic. From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 10:33:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10577; Fri, 24 Jun 1994 09:06: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 IAA14175; Fri, 24 Jun 1994 08:46:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA14158; Fri, 24 Jun 1994 08:32:01 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06333; Fri, 24 Jun 1994 06:42:26 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02945; Thu, 23 Jun 94 16:42:22 -0400 Date: Thu, 23 Jun 94 16:42:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406232042.AA02945@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, hcb@world.std.com Subject: Re: number of existing routing levels Cc: jnc@ginger.lcs.mit.edu From: hcb@world.std.com (Howard C Berkowitz) Someone raised the point ... that we needed to have structures that were under-standable by a "CNE," as opposed to a routing architect. ... I have been making an informal study of the number of levels with which students can cope. ... My general sense is that most can deal with two-level, and with three-level as long as the computation does not become too complex. How much of this is atttributable to the crufty way we do multi-level addresses in IPv4? Do they should any signs of being confused by DNS names, or filenames, with many levels? Would 's with similar clean ways of showing levels be equally easily understood? I believe we need to come up with a "reasonability" test for conceptual complexity of the structures ... that a typical end user administrator can follow. I agree, and that's one factor in my preference for variable-length topologically-sensitive internetwork-level "names" (VL-TSILN's - sigh, I'm reduced to ISOspeak by the ability of people here to damage short names :-). Noel From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 10:34:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10656; Fri, 24 Jun 1994 09: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 IAA14193; Fri, 24 Jun 1994 08:50:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA14155; Fri, 24 Jun 1994 08:28:13 +1000 Precedence: list Received: from titan.sprintlink.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04844; Fri, 24 Jun 1994 06:02:35 +1000 (from avg@sprint.net) Received: (from avg@localhost) by titan.sprintlink.net (8.6.9/8.6.8) id QAA06983; Thu, 23 Jun 1994 16:02:18 -0400 Date: Thu, 23 Jun 1994 16:02:18 -0400 From: Vadim Antonov Message-Id: <199406232002.QAA06983@titan.sprintlink.net> To: jnc@ginger.lcs.mit.edu, mohta@necom830.cc.titech.ac.jp Subject: Re: addressing elements Cc: big-internet@munnari.OZ.AU, bsimpson@morningstar.com >For optimal routes, you must use flat routing. It depends on topology. In 90% cases a significan amount of route aggregation can be achieved w/o losing optimality. >> to get an l/l* ratio (i.e. the ratio of actual >> routing table size to theoretical minimal routing table size) of better than >> 10:1 (i.e. 90% inefficient) you need 5 levels, >Your goal is completely bogus. As memory is cheap and line speed inceasing, >there is no merit to minimize routing table size. Your approach is completely bogus; the memory technology barely can catch the growth of routing tables and CPU technology definitely can't. Using BIIIG addresses will only aggravate the situation. >Instead, we should use as large a routing table as practically possible >for near-optimal routing and other reasons. Instead we should do as much as possible to do automatical aggregation driven by topology and routing domain boundaries. >For example, for geography based routing, we should have a top level >domain consisting of thousands or tens of thousands of domains connected >as mesh. Have the thought that routing is still done on the top of wires (or fibers) which are very few in reality? The BEST routing topology is the one isomorphical to the physical signal propagation paths. Few big pipes instead of zillions of smaller wires will stay here just because it is much cheaper to transfer a bit across DS-3 than across a 9.6kbps. >Having a few top level providers and connect them at only a few points >results in points of excessive load concentration and is no good. That's economy and politics. Interconnection does not generate revenue. The rest is skipped because as logic goes you can make any conclusion out of false premise. --vadim From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 10:37:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10804; Fri, 24 Jun 1994 09:12: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 IAA14208; Fri, 24 Jun 1994 08:51:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA14161; Fri, 24 Jun 1994 08:39:02 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05598; Fri, 24 Jun 1994 06:20:36 +1000 (from corecom@tigger.jvnc.net) Received: from [128.121.50.145] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA14120 Fri, 24 Jun 1994 05:42:12 +1000 (from corecom@tigger.jvnc.net) Received: from franklin-tty18.jvnc.net. (franklin-tty18.jvnc.net) by tigger.jvnc.net with SMTP id AA20863 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Thu, 23 Jun 1994 16:17:17 -0400 Message-Id: Date: Thu, 23 Jun 94 16:16:31 EDT From: "David M. Piscitello" Subject: Re: Why variable length? Reply-To: dave@corecom.com To: "Tony Li" , big-internet@munnari.OZ.AU X-Mailer: VersaTerm Link v1.1.1 Thank you, Tony, for presenting the first real attempt at engineering the address space. I'd like to add that your analysis doesn't consider the aspect of addressing that scares me most, which is the assignment of network numbers to things like automobiles (for total automotive maintenance, evaluation, testing), appliances (for finely grained, complete residential management), etc., which may be considered "expendable" by the addressing authority (i.e., Foo motor company expects the address to die along with the car when it is sent to the dump). This is hundreds or thousands of organizations wanting the ability to assign millions of *networks* *somewhere* in the bits outside the space reserved for hosts per year or *per month*. You don't get 7 or 8 hierarchies out of 16 octets in this scenario. Also, the automobile may have an IPng address for its internal maintenance network and one for the traffic report network. (And yes, this could certainly be perceived as an imprudent way to assign addresses, but I heard of any discussions on the subject of "enforcement of prudent assignment of addresses" here or on any other mailing list.) > >Folks, > >Here are some numbers which help explain why I'm very concerned about >16 byte addresses. The reasoning here is a bit long and tortuous. >Please bear with me. > >Currently, for IPv4 we've allocated about 1.6e9 host addresses. We >have, approximately, 2e6 hosts actually connected. That means that we >have an efficiency of 1.25e-3. [Yes, that's right, about 800 >allocated addresses per actual used address. ;-( ] > >Why are these numbers so bad? Because there's a lot of waste when we >assign an address to an organization. Typically, a site has two >levels of hierarchy, with a network number and then subnets and hosts >on each subnet. Some subnets go unused because the organization just >doesn't need them yet. They can't be easily given away because the >organization will need to grow, and if their address allocation is TOO >tight, they'll need another network number. That would be bad for >routing, for reasons that I won't go into here. So there's some >unavoidable waste. Further, there's waste because each subnet can't >be completely filled. Usually this is simply because the subnet mask >is fixed across the organization and was chosen to simplify human >factors. The subnets are just plain bigger than they need to be. >There's also some unavoidable wasteage here because the subnet is >sized to be a power of two. > >Axiom 1: Hierarchical addressing on bit boundaries has a considerable >amount of unavoidable waste. > >If we restrict where we're willing to put hierarchical boundaries on >more granular boundaries (byte, nibble) so that network managers are >able to work with them more easily, we lose more addresses because >there's more waste at both within each subnet, and probably we need >more subnets within each network. This leads to > >Corollary 1: Hierarchical addressing on byte or nibble boundaries is >even more wasteful. > >While we do know that CIDR will help these numbers, we're just >beginning to see how that will really work in the real world. >Certainly only the early adopters have deplyed CIDR within their >networks and are making effective use of variable length subnet masks. > >Nonetheless, we can use our existing numbers as a worst case >measurement for IPng addressing efficiency. To this end, we'd like to >characterize the efficiency of IPng multi-level addresses. We can >easily see that > >Axiom 2: The cummulative efficiency of an addressing plan is the >product of the efficiencies at each level. > >For example, if we have 100 subnets and we are 10% efficient, and each >subnet could have 100 hosts and we're again 10% efficient, then we've >only used 10*10 = 100 addresses out of 100 * 100 = 10000 possible >addresses, giving 1% efficiency. > >Approximation 1: Thus, with the IPv4 two level addressing hierarchy, >we can get a first approximation of the efficiency at each level as >sqrt(1.25e-3) ~= .03. > >Now, let's take a look at 16 byte addresses. If we take an addressing >plan such as has been proposed for BigTen, we see that we have some >administrative wasteage up front, and 6 bytes for an IEEE 802 address. >Dividing up the remaining space, we see that it's convenient to have >approximately 7 or 8 levels of hierarchy. > >Approximation 2: A 7 level hiearchical system has a worst-case >efficiency of .03^7 = 2e-11. > >How many addresses are there _really_ in a 16 byte address? Well, the >IEEE 802 address consumes 6 bytes, and we also have approximately one >byte of administrative overhead at the front of the address. The >result is that we have 16 - 6 - 1 = 9 bytes of effective address space. > >Approximation 3: There are roughly 2^(9 * 8) = 2^72 = 4e21 addresses >useable. > >Given approximation 2 and 3, we see that > >Approximation 4: 16 byte addresses with a 7 level hierarchical >addressing system can support an Internet of 4e21 * 2e-11 = 8e10 >hosts, in the worst case. > >And that's why I'm scared that 16 bytes is not enough. > >Tony > David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 11:37:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14728; Fri, 24 Jun 1994 10: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 JAA14286; Fri, 24 Jun 1994 09:26:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id JAA14270; Fri, 24 Jun 1994 09:11:56 +1000 Precedence: list Received: from brolga.cc.uq.oz.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12086; Fri, 24 Jun 1994 09:45:34 +1000 (from G.Michaelson@cc.uq.oz.au) Received: from cc.uq.oz.au by brolga.cc.uq.oz.au id <17718-0@brolga.cc.uq.oz.au>; Fri, 24 Jun 1994 09:45:22 +1000 To: big-internet@munnari.OZ.AU Subject: Nato NSAP size & SIPP 16-octet consensus Date: Fri, 24 Jun 1994 09:45:22 +1000 From: George Michaelson Sender: G.Michaelson@cc.uq.oz.au Message-Id: <"brolga.cc.uq:177220:940623234528"@cc.uq.oz.au> At a mildly incoherent "debate" between OSI & TCP held in Melbourne yesterday, somebody from the SC6 ISO framework stated that NATO has standardized on a 5 or 6 deep structured NSAP which consumes "20 digits" If that maps into 20 octets, Then It presents an issue to me at least. If they are decimal digits, and occupy a Nybble each its not a problem to assert they'd fit into a 16-octet SIPP address. Should this be a concern? -George From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 12:52:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB19159; Fri, 24 Jun 1994 12:52: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 LAA14420; Fri, 24 Jun 1994 11:26:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA14406; Fri, 24 Jun 1994 11:20:21 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17035; Fri, 24 Jun 1994 12:00:16 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 24 Jun 94 10:47:47 +0859 From: Masataka Ohta Message-Id: <9406240148.AA22226@necom830.cc.titech.ac.jp> Subject: Re: addressing elements To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 24 Jun 94 10:47:44 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406232033.AA02848@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 23, 94 4:33 pm X-Mailer: ELM [version 2.3 PL11] > A better counterpoint would be to mention that K+K assume lots of very tiny > layers, which is somthign I spaced on in that message. E.g. for a 10^9 node > graph, they show the shortest routing tables are given by 20 layers, with a > fanout of 2/3 at each layer. You don't have to prove that we don't need more than 20 layers. We already know that we only need 2 or 3 layers. > I agree load needs to be shared across multiple connecting points, but > continue to disagree that hierarchical addresses make this substantially > more difficult. Hierarchy, in general, including that of routing, concentrates load at root. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 13:00:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17523; Fri, 24 Jun 1994 12:13: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 KAA14365; Fri, 24 Jun 1994 10:46:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA14351; Fri, 24 Jun 1994 10:30:30 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16745; Fri, 24 Jun 1994 11:54:21 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Fri, 24 Jun 94 10:47:47 +0859 From: Masataka Ohta Message-Id: <9406240148.AA22226@necom830.cc.titech.ac.jp> Subject: Re: addressing elements To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Fri, 24 Jun 94 10:47:44 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406232033.AA02848@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 23, 94 4:33 pm X-Mailer: ELM [version 2.3 PL11] > A better counterpoint would be to mention that K+K assume lots of very tiny > layers, which is somthign I spaced on in that message. E.g. for a 10^9 node > graph, they show the shortest routing tables are given by 20 layers, with a > fanout of 2/3 at each layer. You don't have to prove that we don't need more than 20 layers. We already know that we only need 2 or 3 layers. > I agree load needs to be shared across multiple connecting points, but > continue to disagree that hierarchical addresses make this substantially > more difficult. Hierarchy, in general, including that of routing, concentrates load at root. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 18:12:57 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03365; Fri, 24 Jun 1994 18:12: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 SAA14703; Fri, 24 Jun 1994 18:12:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA14687; Fri, 24 Jun 1994 17:57:14 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29143; Fri, 24 Jun 1994 16:59:53 +1000 (from brian@dxcoms.cern.ch) Received: from dxmint.cern.ch by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA03323 Fri, 24 Jun 1994 16:58:11 +1000 (from brian@dxcoms.cern.ch) Received: from dxcoms.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) id AA01149; Fri, 24 Jun 1994 08:55:30 +0200 Received: by dxcoms.cern.ch (5.65/DEC-Ultrix/4.3) id AA29430; Fri, 24 Jun 1994 08:55:29 +0200 From: brian@dxcoms.cern.ch (Brian Carpenter CERN-CN) Message-Id: <9406240655.AA29430@dxcoms.cern.ch> Subject: Re: A Serious Proposal To: 0003858921@mcimail.com (Robert G. Moskowitz) Date: Fri, 24 Jun 1994 08:55:29 +0200 (MET DST) Cc: big-internet@munnari.OZ.AU In-Reply-To: <80940622114108/0003858921NA3EM@mcimail.com> from "Robert G. Moskowitz" at Jun 22, 94 06:41:00 am Reply-To: Brian.Carpenter@cern.ch X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 625 Robert, It doesn't do it for me. 1. I do not believe people will pay for numbers. Providers and major users will pay a reasonable service charge for NIC-style activities (we already pay a service charge for the RIPE NCC in Europe), but we are talking about modest sums of money. (BTW our OSI AFI cost exactly one second-class stamp and gives us effectively infinite address space. What a bargain :-) 2. It is out of the question, if a user has only 8 bytes to allocate locally, to sacrifice these as an EID field. Regards, Brian.Carpenter@cern.ch (brian@dxcoms.cern.ch) voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 19:42:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05237; Fri, 24 Jun 1994 18:32: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 SAA14736; Fri, 24 Jun 1994 18:32:26 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA14708; Fri, 24 Jun 1994 18:13:03 +1000 Precedence: list Received: from primus.cstp.umkc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03367; Fri, 24 Jun 1994 18:12:59 +1000 (from lee@PRIMUS.CSTP.UMKC.EDU) Received: by PRIMUS.CSTP.UMKC.EDU (MX V4.0-1 AXP) id 1; Fri, 24 Jun 1994 03:11:34 CST Date: Fri, 24 Jun 1994 03:11:33 CST From: Sung Jong Lee (David) Reply-To: LEE@vax2.cstp.umkc.edu To: big-internet@munnari.OZ.AU Cc: lee@PRIMUS.CSTP.UMKC.EDU Message-Id: <00980697.33D561EB.1@PRIMUS.CSTP.UMKC.EDU> Subject: Unsubsribe unsubcribe please From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 19:46:43 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05300; Fri, 24 Jun 1994 18: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 SAA14753; Fri, 24 Jun 1994 18:34:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id SAA14714; Fri, 24 Jun 1994 18:17:21 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03613; Fri, 24 Jun 1994 18:16:46 +1000 (from tli@cisco.com) Received: from [131.108.11.55] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA05467 Fri, 24 Jun 1994 18:16:27 +1000 (from tli@cisco.com) Received: (tli@localhost) by lager.cisco.com (8.6.8+c/CISCO.SERVER.1.1) id BAA14737; Fri, 24 Jun 1994 01:12:03 -0700 Date: Fri, 24 Jun 1994 01:12:03 -0700 From: Tony Li Message-Id: <199406240812.BAA14737@lager.cisco.com> To: J.Crowcroft@cs.ucl.ac.uk Cc: dave@corecom.com, tli@cisco.com, big-internet@munnari.OZ.AU In-Reply-To: Jon Crowcroft's message of Fri, 24 Jun 94 08:53:29 +0100 <199406240753.AAA08513@hubbub.cisco.com> Subject: Why variable length? this is a question of economics Exactly! How much are you willing to pay for insurance? i) a variable address gives lower performace (not a lotm, but everyone agrees at least some) So stipulated. ii) a large address gives lower performance coz of header:data ratio and on slow links, unless you change your architecture, it s bad news - i suggest that addressing your car radio will entail something very deep in the 'hierarchy' and typically therefore a long long address... Perhaps it's not clear. The only time we would need to have a substantial deployment with longer addresses is if 16 byte addresses are not enough. an ecomony of addresses would fix this - if loinger addresses cost more, people would think about using the address space efficiently True. And in fact, one would expect that enlightened users would notice this and respond accordingly. However at some point "more is more" takes hold and just being efficient isn't enough. we need to price CIDRng, something like k1 + k2 * 2**n dollars, where n is the bits in the prefix/mask... k1 & k2 can be determined from the cost functions above quite easily Now I'm really lost. Jon, can you say that again, without the accent? ;-) Tony From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 20:57:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10217; Fri, 24 Jun 1994 19:52: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 TAA14834; Fri, 24 Jun 1994 19:52:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA14820; Fri, 24 Jun 1994 19:35:45 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02997; Fri, 24 Jun 1994 18:05:31 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406240805.2997@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 24 Jun 1994 08:53:32 +0100 To: dave@corecom.com Cc: Tony Li , big-internet@munnari.OZ.AU Subject: Re: Why variable length? In-Reply-To: Your message of "Thu, 23 Jun 94 16:16:31 EDT." Date: Fri, 24 Jun 94 08:53:29 +0100 From: Jon Crowcroft >>For example, if we have 100 subnets and we are 10% efficient, and each >>subnet could have 100 hosts and we're again 10% efficient, then we've >>only used 10*10 = 100 addresses out of 100 * 100 = 10000 possible >>addresses, giving 1% efficiency. this is a question of economics i) a variable address gives lower performace (not a lotm, but everyone agrees at least some) ii) a large address gives lower performance coz of header:data ratio and on slow links, unless you change your architecture, it s bad news - i suggest that addressing your car radio will entail something very deep in the 'hierarchy' and typically therefore a long long address... an ecomony of addresses would fix this - if loinger addresses cost more, people would think about using the address space efficiently we need to price CIDRng, something like k1 + k2 * 2**n dollars, where n is the bits in the prefix/mask... k1 & k2 can be determined from the cost functions above quite easily jon From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 21:37:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13067; Fri, 24 Jun 1994 21:32: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 VAA14943; Fri, 24 Jun 1994 21:32:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA14940; Fri, 24 Jun 1994 21:28:28 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12981; Fri, 24 Jun 1994 21:28:11 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA29526; Fri, 24 Jun 94 06:29:33 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ad29920; 24 Jun 94 11:25 GMT Date: Fri, 24 Jun 94 06:26 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: "Brian.Carpenter" To: "Tansin A. Darcos & Company" <0005066432@mcimail.com> Cc: big internet Subject: Re: A Serious Proposal Message-Id: <52940624112625/0003858921NA4EM@mcimail.com> Brian said: >1. I do not believe people will pay for numbers. Providers >and major users will pay a reasonable service charge for >NIC-style activities (we already pay a service charge for >the RIPE NCC in Europe), but we are talking about modest >sums of money. Either our tax dollars or our usage dollars goes to fund the general administration of TCP/IP global usage. I just presented one model for the usage side. It was submitted on recyclable bits :) BTW, in my view the provider numbers are a magnitude more expensive than an agency number. And a second provider number is a magnitude more expensive than the first to prevent 'buying up the internet'. >(BTW our OSI AFI cost exactly one second-class stamp and gives us >effectively infinite address space. What a bargain :-) Plus tax dollars. There is no free lunch. >2. It is out of the question, if a user has only 8 bytes to >allocate locally, to sacrifice these as an EID field. If the user is only an 'addressing agency' then they would have 4 bytes for their EID and nothing for topology. Of course as discussed here already about how sparse EID addressing will be the rule and dense the exception, 4 bytes is more than most agencies have today. These agencies will be dependent upon their provider for locator values. In some cases, I can see a provider giving over 2 bytes of the locator to their customers for local topology. This is more than B class owners have today. This sort of thing is what will distinguish providers and attrack customers. For the 'really big organizations' they can be their own provider and have 6 bytes for locator topology. This is more than A class owners have today. And remember this is for topology, not for devices. 2^32 devices for most organizations is a lot. What is that, 10^8? Bob Moskowitz From owner-Big-Internet@munnari.OZ.AU Fri Jun 24 23:13:39 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16256; Fri, 24 Jun 1994 23:13: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 XAA15045; Fri, 24 Jun 1994 23:12:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA15031; Fri, 24 Jun 1994 22:55:59 +1000 Precedence: list Received: from gecko.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15715; Fri, 24 Jun 1994 22:55:52 +1000 (from desjardi@eos.nasa.gov) Received: by eos.nasa.gov (5.65/SunOS-ldap-sendmail) id AA04739; Fri, 24 Jun 94 08:55:43 -0400 From: desjardi@eos.nasa.gov (Dick desJardins) Message-Id: <9406241255.AA04739@eos.nasa.gov> Subject: Re: Nato NSAP size & SIPP 16-octet consensus To: G.Michaelson@cc.uq.oz.au (George Michaelson) Date: Fri, 24 Jun 1994 08:55:43 -0400 (EDT) Cc: big-internet@munnari.OZ.AU In-Reply-To: <"brolga.cc.uq:177220:940623234528"@cc.uq.oz.au> from "George Michaelson" at Jun 24, 94 09:45:22 am Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1009 > > > At a mildly incoherent "debate" between OSI & TCP held in Melbourne > yesterday, somebody from the SC6 ISO framework stated that NATO has > standardized on a 5 or 6 deep structured NSAP which consumes "20 digits" > > If that maps into 20 octets, Then It presents an issue to me at least. > If they are decimal digits, and occupy a Nybble each its not a problem > to assert they'd fit into a 16-octet SIPP address. > > Should this be a concern? > > -George > It's my understanding that all the various government NSAP addressing schemes fit into the ISO/CCITT 20-octet maximum, of which several octets are effectively unused. (Used to identify the scheme or version.) It would be a useful exercise for someone to map these schemes into the 16-octet SIPP address proposal. Certainly "convergence" to a single scheme satisfying NSAP needs as well as IP needs looks a lot more doable with the 16-octet frameworks being discussed. The 8-octet limitation was really problematical. Dick desJardins From owner-Big-Internet@munnari.OZ.AU Sat Jun 25 02:44:02 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17723; Fri, 24 Jun 1994 23:52: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 XAA15095; Fri, 24 Jun 1994 23:52:27 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA15076; Fri, 24 Jun 1994 23:38:22 +1000 Precedence: list From: kimjd@brutus.snu.ac.kr Received: from ercc.snu.ac.kr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17296; Fri, 24 Jun 1994 23:38:11 +1000 (from kimjd@brutus.snu.ac.kr) Received: from brutus. (brutus.snu.ac.kr) by ercc.snu.ac.kr (4.1/SMI-4.1) id AA15209; Fri, 24 Jun 94 22:40:56 KST Received: from windy (windy.snu.ac.kr) by brutus. (4.1/SMI-4.1) id AA00277; Fri, 24 Jun 94 22:39:23 KDT Message-Id: <9406241239.AA00277@brutus.> Date: Fri Jun 24 19:52:35 1994 To: big-internet@munnari.OZ.AU Subject: Request Request. I want to include my address to the mailing list. help me. Kim Jong Deok. Dept. of Computer Science. Seoul National University. Seoul Korea. kimjd@brutus.snu.ac.kr From owner-Big-Internet@munnari.OZ.AU Sat Jun 25 02:52:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24781; Sat, 25 Jun 1994 02:52: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 CAA15349; Sat, 25 Jun 1994 02:52:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA15332; Sat, 25 Jun 1994 02:37:51 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24270; Sat, 25 Jun 1994 02:37:49 +1000 (from solensky@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Fri, 24 Jun 1994 12:37:39 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Fri, 24 Jun 1994 12:37:39 -0400 Received: from solensky.fenway.ftp.com by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA01966; Fri, 24 Jun 94 12:35:42 EDT Date: Fri, 24 Jun 94 12:35:42 EDT Message-Id: <9406241635.AA01966@mailserv-D.ftp.com> To: tli@cisco.com Subject: Re: Why variable length? From: solensky@ftp.com (Frank T Solensky) Cc: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.OZ.AU Sender: solensky@mailserv-D.ftp.com Repository: mailserv-D.ftp.com, [message accepted at Fri Jun 24 12:35:38 1994] Originating-Client: fenway.ftp.com Content-Length: 582 > From: Tony Li > To: J.Crowcroft@cs.ucl.ac.uk > > we need to price CIDRng, something like k1 + k2 * 2**n dollars, where > n is the bits in the prefix/mask... > > k1 & k2 can be determined from the cost functions above quite easily > > Now I'm really lost. Jon, can you say that again, without the accent? > ;-) ... set the cost proportional to the numeric value of the mask with some fixed fudging cost, I think. Doubling the cost for each additional bit seems on the high side, but >> k2 * n makes sense ('>>': much greater than). -- Frank From owner-Big-Internet@munnari.OZ.AU Sat Jun 25 02:57:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17793; Fri, 24 Jun 1994 23:55: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 XAA15138; Fri, 24 Jun 1994 23:55:34 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA15092; Fri, 24 Jun 1994 23:48:58 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13522; Fri, 24 Jun 1994 21:48:48 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AB29992; Fri, 24 Jun 94 06:50:24 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id af00827; 24 Jun 94 11:46 GMT Date: Fri, 24 Jun 94 06:42 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: dave To: big internet Subject: Re: Why variable length? Message-Id: <65940624114256/0003858921NA1EM@mcimail.com> Dave said: >Thank you, Tony, for presenting the first real attempt at >engineering the address space. I'd like to add that your >analysis doesn't consider the aspect of addressing that >scares me most, which is the assignment of network numbers to >things like automobiles (for total automotive maintenance, evaluation, >testing), appliances (for finely grained, complete residential management), >etc., which may be considered "expendable" by the addressing authority >(i.e., Foo motor company expects the address to die along with the car >when it is sent to the dump). This is hundreds or thousands of >organizations wanting the ability to assign millions of *networks* >*somewhere* in the bits outside the space reserved for hosts per year >or *per month*. You don't get 7 or 8 hierarchies out of 16 octets in >this scenario. Also, the automobile may have an IPng address for its >internal maintenance network and one for the traffic report >network. (And yes, this could certainly be perceived as an >imprudent way to assign addresses, but I heard of any discussions >on the subject of "enforcement of prudent assignment of addresses" >here or on any other mailing list.) Since EID is globally unique, each car would have an EID assigned by the manufacturer. This can either come out of their base 2^32 addresses, or they might get a second agency number for actual product. At an annual production rate of under 10^7, it will take a while to exhaust one 4 byte EID allocation for the whole North American auto production. As that car comes down the assembly line, it will have the locator of the line. When that car is at a dealership, it should 'inherit' the locator of the dealership. And as it goes down the road, it might have a different locator, that of the provider for the roadway. Bob Moskowitz Chrysler Corp From owner-Big-Internet@munnari.OZ.AU Sat Jun 25 04:05:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25070; Sat, 25 Jun 1994 02:58: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 CAA15375; Sat, 25 Jun 1994 02:58:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA15346; Sat, 25 Jun 1994 02:48:45 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24679; Sat, 25 Jun 1994 02:48:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07694; Fri, 24 Jun 94 12:47:03 -0400 Date: Fri, 24 Jun 94 12:47:03 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406241647.AA07694@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: addressing elements Cc: jnc@ginger.lcs.mit.edu From: Valdis.Kletnieks@vt.edu I am convinced that 3 can be made sufficient in the current network. ... it's safe to assume we must design such that no one level has more than 20,000 or so entries, lest the poor owner of that level be swamped with administrivia.... These calculations are all of only limited interest, because you're effectively assuming a single-metric system. The information explosion will happen much faster when you start to think about routing in the kind of multi-metric system we'll get with QOS (let alone policy). 20K entities per object is simply not goign to be a plausible aggregation size when each entity has numerous attributes. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jun 25 05:52:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01323; Sat, 25 Jun 1994 05:52: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 FAA15585; Sat, 25 Jun 1994 05:52:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA15582; Sat, 25 Jun 1994 05:52:12 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01308; Sat, 25 Jun 1994 05:52:12 +1000 (from valdis@black-ice.cc.vt.edu) Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id PAA20416; Fri, 24 Jun 1994 15:52:09 -0400 Message-Id: <199406241952.PAA20416@black-ice.cc.vt.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Subject: Re: addressing elements In-Reply-To: Your message of "Fri, 24 Jun 1994 12:47:03 EDT." <9406241647.AA07694@ginger.lcs.mit.edu> From: Valdis.Kletnieks@vt.edu Date: Fri, 24 Jun 1994 15:52:08 +22306356 Sender: valdis@black-ice.cc.vt.edu On Fri, 24 Jun 1994 12:47:03 EDT, Noel Chiappa said: > These calculations are all of only limited interest, because you're effective ly > assuming a single-metric system. The information explosion will happen much > faster when you start to think about routing in the kind of multi-metric syst em > we'll get with QOS (let alone policy). 20K entities per object is simply not > goign to be a plausible aggregation size when each entity has numerous > attributes. Noel: Thanks for correcting my first-order calculation to include the very real second-order effects. I'm not sure whether this is most accurately modelled by simply adding a fixed value to N to shift to the right in the table (i.e. add 1 level for QOS, and 1 for policy, or some such), or whether some variety of N log M taking into account both the number of machines and number of levels is more appropriate.. Looking at the numbers, I get the "feel" that a "good" number of objects/level is acheived somewhere near N=(0.75*log10 M) for N levels and M machines. Of course, this means we need a crystal ball to predict M. ;) /Valdis From owner-Big-Internet@munnari.OZ.AU Sat Jun 25 05:57:50 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26340; Sat, 25 Jun 1994 03:32: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 DAA15421; Sat, 25 Jun 1994 03:32:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA15407; Sat, 25 Jun 1994 03:16:24 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25717; Sat, 25 Jun 1994 03:16:16 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07921; Fri, 24 Jun 94 13:16:10 -0400 Date: Fri, 24 Jun 94 13:16:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406241716.AA07921@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: addressing elements Cc: jnc@ginger.lcs.mit.edu From: Masataka Ohta > I agree load needs to be shared across multiple connecting points, but > continue to disagree that hierarchical addresses make this substantially > more difficult. Hierarchy, in general, including that of routing, concentrates load at root. If we were using our hierarchical addressing to do hiearchical routing, I would agree. However, there's no *necessary* link between the two. If you are willing to pay the overhead of pasing around more routing data than you would have in the hierarchical routing case, you can use hierarchical addressing to produce routes that approximate, as closely as you want, the optimal routes generated with a flat addressing scheme. More data, more overhead, more optimal routes; a nice knob the users can adjust to put the cost/benfit tradeoff where they want it. For example, consider the graph where I have internal nodes 1-100 gathered together inside area A, which has border nodes a-j on the boundary between to the outside (i.e. A contains nodes 1-100 and a-j.) If I use pure hierarchical routing, A appears as a single object outside A, and traffic bound for destinations inside A has no idea which is the best border node to pick for entry into A. E.g., if internal node A.1 is next to border node A.a, there's no way for incoming traffic for A.1 to be directed in through A.a, as opposed to A.j, which is all the way on the other side of A. If I allow information as to how close all A.[1-100] are to each entry node A.[a-j] to leak out into the area of the graph outside, but *near* A, then you can get better routes. More overhead, of course, but more routes. Using hierarchical addressing, you can produce routes which can approximate the optimal routes you get with flat addressing *as closely as you want*, albeit at higher routing overhead (but still much less than pure flat routing). The fallacy in your statement that "hierarchy, in general ... concentrates load at root" can now be seen. If we have a physical topology which, with *flat* routing, does not concentrate load, we can create a hierarchical addressing scheme for it, which, with proper adjustments to the routing data distribution, will have basically the same traffic patterns; i.e. does not concentrate load. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jun 25 06:10:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27778; Sat, 25 Jun 1994 04:12: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 EAA15487; Sat, 25 Jun 1994 04:12:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA15460; Sat, 25 Jun 1994 03:56:37 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23846; Sat, 25 Jun 1994 02:28:27 +1000 (from valdis@black-ice.cc.vt.edu) Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id MAA21302; Fri, 24 Jun 1994 12:26:54 -0400 Message-Id: <199406241626.MAA21302@black-ice.cc.vt.edu> To: Masataka Ohta Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU Subject: Re: addressing elements In-Reply-To: Your message of "Fri, 24 Jun 1994 10:47:44 EST." <9406240148.AA22226@necom830.cc.titech.ac.jp> From: Valdis.Kletnieks@vt.edu Date: Fri, 24 Jun 1994 12:26:53 +22306356 Sender: valdis@black-ice.cc.vt.edu On Fri, 24 Jun 1994 10:47:44 EST, Masataka Ohta said: > You don't have to prove that we don't need more than 20 layers. > > We already know that we only need 2 or 3 layers. I am convinced that 3 can be made sufficient in the current network. I am also however convinced that over the next 10 to 15 years, network addresses and devices will become ubiquitous enough that 2 or 3 layers won't suffice. In the optimal case, N layers over M addresses results in M**(-N) entries per layer. Thus we have: M N=2 N=3 N=4 N=5 N=6 N=7 1e+06 1000 100 31 15 10 7 1e+07 3162 215 56 25 14 10 1e+08 10000 464 100 39 21 13 1e+09 31622 1000 177 63 31 19 1e+10 100000 2154 316 100 46 26 1e+11 316228 4641 562 158 68 37 1e+12 1e+06 10000 1000 251 100 51 1e+13 3e+06 21544 1778 398 146 71 1e+14 1e+07 46415 3162 630 215 100 Now, looking at this table, we can see a few things: 1) Those calling for 6 or 7 levels *now* need to re-think - distributed evenly over 1 million objects only get you 10-14 things per level. And if you want 30 things at one level, you have to cut back to 5 or so at another. At that point, you may as well drop out a level and regroup. ;) 2) On the other hand, N=2 or 3 will get unmanagable for very large values of M. Given our current crisis in managing 19,000 connected networks, I think it's safe to assume we must design such that no one level has more than 20,000 or so entries, lest the poor owner of that level be swamped with administrivia.... /Valdis From owner-Big-Internet@munnari.OZ.AU Sat Jun 25 13:13:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15299; Sat, 25 Jun 1994 13:13: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 NAA15961; Sat, 25 Jun 1994 13:12:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA15958; Sat, 25 Jun 1994 13:12:00 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15177; Sat, 25 Jun 1994 13:11:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10996; Fri, 24 Jun 94 23:11:55 -0400 Date: Fri, 24 Jun 94 23:11:55 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406250311.AA10996@ginger.lcs.mit.edu> To: Valdis.Kletnieks@vt.edu, big-internet@munnari.OZ.AU Subject: Re: addressing elements Cc: jnc@ginger.lcs.mit.edu From: Valdis.Kletnieks@vt.edu > routing in the kind of multi-metric system > we'll get with QOS (let > alone policy). I'm not sure whether this is most accurately modelled by simply adding a fixed value to N to shift to the right in the table (i.e. add 1 level for QOS, and 1 for policy, or some such) The problem with attempting to do numerical calculations of this sort is that we simply don't have any large-scale experience with routing systems that can handle this kind of multi-metric routing. So, we simply have no way to quantify, in advance, what they will need in the way of topology-sensitive internetwork-level names (TSILN's) in actual service, to produce reasonable good routes, at an acceptable routing overhead level. Of course, the ideal answer would be to allow time for some prototyping and field trials before designing the final version of the TSILN, but we don't appear to be able to put this off in this manner. This is but one of the many reasons I favor variable length TSILN's, and indeed VL-TSILN's with a flexible internal format. Noel From owner-Big-Internet@munnari.OZ.AU Sat Jun 25 14:36:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15936; Sat, 25 Jun 1994 13:32: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 NAA15991; Sat, 25 Jun 1994 13:32:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA15977; Sat, 25 Jun 1994 13:24:36 +1000 Precedence: list Received: from brolga.cc.uq.oz.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15718; Sat, 25 Jun 1994 13:24:37 +1000 (from G.Michaelson@cc.uq.oz.au) Received: from brolga.cc.uq.oz.au by brolga.cc.uq.oz.au with SMTP (PP); Sat, 25 Jun 1994 13:24:21 +1000 To: desjardi@eos.nasa.gov (Dick desJardins) Cc: big-internet@munnari.OZ.AU Subject: Re: Nato NSAP size & SIPP 16-octet consensus In-Reply-To: Your message of "Fri, 24 Jun 1994 08:55:43 -0400." <9406241255.AA04739@eos.nasa.gov> Date: Sat, 25 Jun 1994 13:24:17 +1000 Message-Id: <11519.772514657@brolga.cc.uq.oz.au> From: George Michaelson It's my understanding that all the various government NSAP addressing schemes fit into the ISO/CCITT 20-octet maximum, of which several octets are effectively unused. (Used to identify the scheme or version.) Right. I clearly mis-understood his statement. But the effectively unused part makes me very uneasy. I have dim memory of breakdowns in IPv4 interoperation when fields not expected to become active did so. Also from guesswork, If you remove or pack the sparce encodings for version and scheme you'd loose speed of parsing if you had to consider looking into structure to determine what *was* a legal parse. Likewise performing header mungs on CLNP packets as they wormed around would be a bummer (recalculating checksums presumably will have to be done anyway, but it might be nice if there was convergeance on checksumming as well as addressing so that none of this was needed) I read that as "SIPP flows at wire speed but converged CLNP runs at some degredation" which is hardly a selling point to OSI-philes. It would be a useful exercise for someone to map these schemes into the 16-octet SIPP address proposal. My word yes! Certainly "convergence" to a single scheme satisfying NSAP needs as well as IP needs looks a lot more doable with the 16-octet frameworks being discussed. The 8-octet limitation was really problematical. But the assumption that certain fields remain "unused" looks like a minefield. Is the 25% difference in 20 and 16 octet fixed size SIPP addresses enough to make a 25% difference in cache/parsing costs? If not, I don't see that "coercing" 20-octet values by hoping "reserved" fields never get woken up is such a good idea. Certainly one would want ISO/ITU people aware of the constraints... -George From owner-Big-Internet@munnari.OZ.AU Sun Jun 26 22:13:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11076; Sun, 26 Jun 1994 22: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 WAA17602; Sun, 26 Jun 1994 22:13:07 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA17588; Sun, 26 Jun 1994 22:03:20 +1000 Precedence: list Received: from hsdndev.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10872; Sun, 26 Jun 1994 22:03:24 +1000 (from sob@hsdndev.harvard.edu) Date: Sun, 26 Jun 94 08:03:16 -0400 From: sob@hsdndev.harvard.edu (Scott Bradner) Message-Id: <9406261203.AA10683@hsdndev.harvard.edu> To: big-internet@munnari.OZ.AU Subject: IPng ADs request A question much like this one went to the SIPP list last week but due to the pressures of too much travel etc we forgot to send it to the other relevant lists. Sorry for the confusion. ---- Picking up on something that Noel mentioned in a posting a while back, we would like to request that a particular issue be discussed. One thing that seems to have been missing in the recent extensive discussions about address size options is a understanding of whether the transport level 'name' should be the same as the internetwork level 'name', as they are with the current IPv4 "address", or be different in some way. In IPv4 the transport name is: The question referrs to the two IP address fields. Different people seem to often be making different assumptions about the answer to this question in recent notes, with the result that a lot of the discussion was not as productive as it could have been, due to inconsistant terminology. If it is possible to reach consensus on this issue, it will almost certainly make it easier to reach consensus on some of the other open issues regarding "addresses". Note that it is not necessary to assume that the names in question are either fixed or variable length. Obviously, whether you have one or two is related to the details of what each would look like, but it should be possible to consider this without getting diverted by the contentious issue of fixed/variable. Please address the following questions: 1/ are the transport and internetwork level names the same thing? 2/ if not, are they totally different or is the transport level name part of the internetwork level name? Scott & Allison From owner-Big-Internet@munnari.OZ.AU Mon Jun 27 03:13:49 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20144; Mon, 27 Jun 1994 03:13: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 DAA17864; Mon, 27 Jun 1994 03:13:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA17861; Mon, 27 Jun 1994 03:12:02 +1000 Precedence: list Received: from netcom12.netcom.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20134; Mon, 27 Jun 1994 03:12:10 +1000 (from kck@netcom.com) Received: by netcom.com (8.6.8.1/SMI-4.1/Netcom) id KAA03880; Sun, 26 Jun 1994 10:12:26 -0700 Date: Sun, 26 Jun 1994 10:12:26 -0700 From: kck@netcom.com (Richard Fox) Message-Id: <199406261712.KAA03880@netcom12.netcom.com> To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request > If it is possible to reach consensus on this issue, it will almost >certainly make it easier to reach consensus on some of the other open >issues regarding "addresses". >Scott & Allison Why? The connection is very very small. From owner-Big-Internet@munnari.OZ.AU Mon Jun 27 18:13:25 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18993; Mon, 27 Jun 1994 16:34: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 QAA18535; Mon, 27 Jun 1994 16:33:31 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id QAA18532; Mon, 27 Jun 1994 16:26:20 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18548; Mon, 27 Jun 1994 16:26:12 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 27 Jun 94 15:16:51 +0859 From: Masataka Ohta Message-Id: <9406270617.AA01954@necom830.cc.titech.ac.jp> Subject: Re: Why variable length? To: 0003858921@mcimail.com (Robert G. Moskowitz) Date: Mon, 27 Jun 94 15:16:49 JST Cc: dave@corecom.com, big-internet@munnari.OZ.AU In-Reply-To: <65940624114256/0003858921NA1EM@mcimail.com>; from "Robert G. Moskowitz" at Jun 24, 94 6:42 am X-Mailer: ELM [version 2.3 PL11] > Since EID is globally unique, each car would have an EID assigned by the > manufacturer. Since EID would be used for administration purposes such as DNS query, each owner of the car should, through autoconfiguration, assign EID within EID subspace which may be delegated from cable TV providers and is under the control of the owner. Of course, car manifacturers may also act as EID registry for their customers but some customers will want to assign their own EID for various reasons such as for better security than that of car manufacturers. > This can either come out of their base 2^32 addresses, or > they might get a second agency number for actual product. At an annual > production rate of under 10^7, it will take a while to exhaust one 4 byte > EID allocation for the whole North American auto production. Each car should need hundreds of of EIDs for various electric equipments. Still, 2^64 is large enough. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jun 27 19:09:52 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20948; Mon, 27 Jun 1994 17:33: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 RAA18602; Mon, 27 Jun 1994 17:33:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id RAA18588; Mon, 27 Jun 1994 17:18:45 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20495; Mon, 27 Jun 1994 17:18:39 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 27 Jun 94 16:12:21 +0900 From: Masataka Ohta Message-Id: <9406270712.AA02161@necom830.cc.titech.ac.jp> Subject: Re: addressing elements To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 27 Jun 94 16:12:19 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406241647.AA07694@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 24, 94 12:47 pm X-Mailer: ELM [version 2.3 PL11] Valdis; > M N=2 N=3 N=4 N=5 N=6 N=7 > 1e+06 1000 100 31 15 10 7 > 1e+07 3162 215 56 25 14 10 > 1e+08 10000 464 100 39 21 13 > 1e+09 31622 1000 177 63 31 19 > 1e+10 100000 2154 316 100 46 26 > 1e+11 316228 4641 562 158 68 37 > 1e+12 1e+06 10000 1000 251 100 51 > 1e+13 3e+06 21544 1778 398 146 71 > 1e+14 1e+07 46415 3162 630 215 100 > 2) On the other hand, N=2 or 3 will get unmanagable for very large values of > M. Given our current crisis in managing 19,000 connected networks, I think > it's safe to assume we must design such that no one level has more than > 20,000 or so entries, lest the poor owner of that level be swamped with > administrivia.... Please don't forget to scale what poor routers can do. By the time we will be having 1E12 networks, poor routers should have 2.4Gbps interfaces and 1GB of memory. > These calculations are all of only limited interest, because you're effectively > assuming a single-metric system. The information explosion will happen much > faster when you start to think about routing in the kind of multi-metric system > we'll get with QOS (let alone policy). 20K entities per object is simply not > goign to be a plausible aggregation size when each entity has numerous > attributes. 20KB*1000 is merely 20MB. It will take only a second to transmit that 20MB over 156Mbps ATM. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jun 27 19:13:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24764; Mon, 27 Jun 1994 19: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 TAA18707; Mon, 27 Jun 1994 19:13:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA18690; Mon, 27 Jun 1994 19:09:25 +1000 Precedence: list Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21862; Mon, 27 Jun 1994 17:56:31 +1000 (from huitema@mitsou.inria.fr) Received: by mitsou.inria.fr (5.65c8/IDA-1.2.8) id AA26008; Mon, 27 Jun 1994 09:55:29 +0200 Message-Id: <199406270755.AA26008@mitsou.inria.fr> To: George Michaelson Cc: big-internet@munnari.OZ.AU Subject: Re: Nato NSAP size & SIPP 16-octet consensus In-Reply-To: Your message of "Sat, 25 Jun 1994 13:24:17 +1000." <11519.772514657@brolga.cc.uq.oz.au> Date: Mon, 27 Jun 1994 09:55:28 +0200 From: Christian Huitema George, I dont believe anyone is seriously proposing to translate CLNP packets into SIPP "on the fly". I though that the TUBA group insisted on dual stack in their proposed transition from IP to CLNP; the same would certainly lead to dual stack transition from CLNP to SIPP. The real question is whether individual organization can easily translate their internal CLNP addressing plan into a 16 bits addressing plan. The fact is that NSAPs are really 19 bytes (20th is a payload field), that the IDI + first bytes of the DSP can probably be replaced by a much shorter "provider ID" or "very large customer ID", and that the unused bytes in the middle can just remain unused... Note that routers have no need to parse the internal structure of addresses. Doing that for CLNP's NSAP would actually be an interesting exercise... Christian Huitema From owner-Big-Internet@munnari.OZ.AU Mon Jun 27 20:40:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24931; Mon, 27 Jun 1994 19:19: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 TAA18722; Mon, 27 Jun 1994 19:19:28 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA18704; Mon, 27 Jun 1994 19:10:24 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21414; Mon, 27 Jun 1994 17:45:53 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Mon, 27 Jun 94 16:39:42 +0900 From: Masataka Ohta Message-Id: <9406270739.AA02238@necom830.cc.titech.ac.jp> Subject: Re: addressing elements To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 27 Jun 94 16:39:40 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406241716.AA07921@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 24, 94 1:16 pm X-Mailer: ELM [version 2.3 PL11] > > I agree load needs to be shared across multiple connecting points, but > > continue to disagree that hierarchical addresses make this substantially > > more difficult. > > Hierarchy, in general, including that of routing, concentrates load at > root. > > If we were using our hierarchical addressing to do hiearchical routing, I > would agree. However, there's no *necessary* link between the two. If we don't route hiearchically, we have no reason to have hierarchical locators. > If I allow > information as to how close all A.[1-100] are to each entry node A.[a-j] > to leak out into the area of the graph outside, but *near* A, then you > can get better routes. More overhead, of course, but more routes. We can do the same thing with 2 or 3 layers. Moreover, with fewer and larger layers, the data is leaked to smaller number of graph nodes *nearer* to A. > Using hierarchical addressing, you can produce routes which can approximate > the optimal routes you get with flat addressing *as closely as you want*, You don't have to prove that we CAN use 20 layers. Instead, you should prove we HAVE TO do so. > albeit at higher routing overhead (but still much less than pure flat > routing). No one says "pure flat routing". > The fallacy in your statement that "hierarchy, in general ... concentrates > load at root" can now be seen. If we have a physical topology which, with > *flat* routing, does not concentrate load, we can create a hierarchical > addressing scheme for it, which, with proper adjustments to the routing > data distribution, will have basically the same traffic patterns; i.e. > does not concentrate load. The "proper adjustments to the routing data distribution" is called "flat routing". Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Mon Jun 27 22:31:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28045; Mon, 27 Jun 1994 21: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 VAA18836; Mon, 27 Jun 1994 21:13:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA18822; Mon, 27 Jun 1994 21:06:28 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27902; Mon, 27 Jun 1994 21:06:21 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA11660; Mon, 27 Jun 94 06:07:54 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id bq23735; 27 Jun 94 11:04 GMT Date: Mon, 27 Jun 94 05:40 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Masataka Ohta Cc: dave Cc: big internet Subject: Re: Why variable length? Message-Id: <55940627104055/0003858921NA5EM@mcimail.com> >Each car should need hundreds of of EIDs for various electric equipments. >Still, 2^64 is large enough. Sigh, As of last month, USCar is pushing for a proprietary protocol between electrical components on cars. Only one device is seen as having the interface to the rest of the world.... This info is from our electrical people that are designing the components. USCar is a research group under the American Automotive Manufacturer's Association (AAMA). My influence is with the Automotive Industry Action Group (AIAG). I've been told that even IPv4 is viewed as too expensive per component. Bob From owner-Big-Internet@munnari.OZ.AU Tue Jun 28 01:53:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07887; Tue, 28 Jun 1994 01: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 BAA19174; Tue, 28 Jun 1994 01:53:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA19110; Tue, 28 Jun 1994 01:34:49 +1000 Precedence: list Received: from quern.epilogue.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05888; Tue, 28 Jun 1994 00:56:17 +1000 (from dab@epilogue.com) From: Dave Bridgham Sender: dab@epilogue.com To: mohta@necom830.cc.titech.ac.jp Cc: big-internet@munnari.OZ.AU In-Reply-To: Masataka Ohta's message of Mon, 27 Jun 94 16:39:40 JST <9406270739.AA02238@necom830.cc.titech.ac.jp> Subject: addressing elements Date: Mon, 27 Jun 94 10:55:54 -0400 Message-Id: <9406271055.aa27960@quern.epilogue.com> Precedence: list From: Masataka Ohta Date: Mon, 27 Jun 94 16:39:40 JST X-Mailer: ELM [version 2.3 PL11] > If we were using our hierarchical addressing to do hiearchical routing, I > would agree. However, there's no *necessary* link between the two. If we don't route hiearchically, we have no reason to have hierarchical locators. We use the locators to find network information which goes into the routing computation. The network connectivity and policy information is kept heirarchically, this heirarchical locators. The route thus generated need not follow that heirarchy. Dave From owner-Big-Internet@munnari.OZ.AU Tue Jun 28 02:13:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08500; Tue, 28 Jun 1994 02:13: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 CAA19217; Tue, 28 Jun 1994 02:13:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA19179; Tue, 28 Jun 1994 01:53:57 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07884; Tue, 28 Jun 1994 01:53:51 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id IAA25575; Mon, 27 Jun 1994 08:53:35 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Mon, 27 Jun 1994 08:53:42 -0700 To: mo@uunet.uu.net (Mike O'Dell) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: smart buildings, cars, doorknobs, coffee-cups, etc.... Cc: big-internet@munnari.OZ.AU At 5:54 AM 6/27/94, Mike O'Dell wrote: >Remember O'Dell's Law of New Technology: Mike, interesting description, thanks. A minor followup: Internet Law of Addressing: An address is different from a protocol. We can, should and will give addresses to things that might not be running a particular protocol, since this makes reference to those things much easier, including proxy/gateway access. Internet address has evolved to a model of global, unique, homogeneous addressing largely because it is so much easier to deal with the administration, and because what is local today may well turn out to need to be global tomorrow. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Tue Jun 28 02:33:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09278; Tue, 28 Jun 1994 02:33: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 CAA19248; Tue, 28 Jun 1994 02:33:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA19233; Tue, 28 Jun 1994 02:19:52 +1000 Precedence: list Received: from black-ice.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08822; Tue, 28 Jun 1994 02:19:38 +1000 (from valdis@black-ice.cc.vt.edu) Received: (from valdis@localhost) by black-ice.cc.vt.edu (8.6.9/8.6.9) id MAA05876; Mon, 27 Jun 1994 12:19:03 -0400 Message-Id: <199406271619.MAA05876@black-ice.cc.vt.edu> To: Masataka Ohta Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU Subject: Re: addressing elements In-Reply-To: Your message of "Mon, 27 Jun 1994 16:12:19 EST." <9406270712.AA02161@necom830.cc.titech.ac.jp> From: Valdis.Kletnieks@vt.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Id: <5875.772733942.1@black-ice.cc.vt.edu> Date: Mon, 27 Jun 1994 12:19:03 +22306356 Sender: valdis@black-ice.cc.vt.edu On Mon, 27 Jun 1994 16:12:19 EST, Masataka Ohta said: > Please don't forget to scale what poor routers can do. By the time we > will be having 1E12 networks, poor routers should have 2.4Gbps interfaces > and 1GB of memory. Actually, I'm not interested in what the routers can do - I am quite sure that we can/will build hardware that can manage. The problem is that you have to keep track of the administrivia. > 20KB*1000 is merely 20MB. It will take only a second to transmit that 20MB > over 156Mbps ATM. Again - the issue is not "can we download 20MB of data to a router in a second". The point I was making was that if you have too many entries at one level, the paperwork gets difficult (witness the current explosion of *.com addresses, with attendant registration issues, or the manpower that Merit has to invest to type in all the entries into their data bases, etc). Remember - that 20M had to come from *someplace*, and most likely it's a summary abstract of a much larger database that also includes postal addresses, contact names, service agreement invoice numbers, and all the other things that the beancounter types like to know... /Valdis (who was trying to inject a 'human factors' point) From owner-Big-Internet@munnari.OZ.AU Tue Jun 28 02:36:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03171; Mon, 27 Jun 1994 23:55: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 XAA18972; Mon, 27 Jun 1994 23:53:35 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA18969; Mon, 27 Jun 1994 23:49:31 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00915; Mon, 27 Jun 1994 22:54:29 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwwch26985; Mon, 27 Jun 1994 08:54:25 -0400 Date: Mon, 27 Jun 1994 08:54:25 -0400 From: mo@uunet.uu.net (Mike O'Dell) Message-Id: To: big-internet@munnari.OZ.AU Subject: smart buildings, cars, doorknobs, coffee-cups, etc.... The likelyhood that all these "smart things" will adopt IP within themselves any time soon is extremely remote. Take for instance the "Neuron" chip. This is a remarkable widget - it has 3 cpus - one does network stuff, one does interface, and the other does, well, more stuff. It is designed to be *very* cheap for the "one springhead per light fixture" applications in smart buildings. further, the chip can do carrier current without external glue (maybe a couple of capacitors). and it has a very cute, very lightweight network protocol, and it interfaces to the external world (solid-state relays, current probes, etc) very easily. It has been carefully engineered to do this job quite well. I can imagine major subsystem controllers for smart buildings will get IPng addresses some day, but the little chips are already being stamped out in the zillions, and IT JUST WORKS. Remember O'Dell's Law of New Technology: Noone changes basic technology for less than a 10x aggregate improvement. And just changing the addressing structure of these tiny-net chips won't ever make escape velocity. Likewise, the folks doing intra-car networks are probably busily adapting the existing technology like the heavily multi-sourced Neuron part for their problem, and you can forget worrying about the IPng address of your headrest controller. Besides, I don't want to think about tuning the firewall for my car. -mo From owner-Big-Internet@munnari.OZ.AU Tue Jun 28 02:53:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10245; Tue, 28 Jun 1994 02:53: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 CAA19296; Tue, 28 Jun 1994 02:53:36 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA19265; Tue, 28 Jun 1994 02:36:47 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09433; Tue, 28 Jun 1994 02:36:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25187; Mon, 27 Jun 94 12:36:17 -0400 Date: Mon, 27 Jun 94 12:36:17 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406271636.AA25187@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mohta@necom830.cc.titech.ac.jp Subject: Re: addressing elements Cc: jnc@ginger.lcs.mit.edu From: Masataka Ohta > If we were using our hierarchical addressing to do hiearchical routing, I > would agree. However, there's no *necessary* link between the two. If we don't route hiearchically, we have no reason to have hierarchical locators. Sorry, I wasn't clear. By "hierarchical routing" I mean "pure hierarchical routing"; i.e. a packet from A.B.C to X.Y.X is first sent to A.B, then to A, then to X, then to X.Y, etc. Second, any large-scale routing system is necssarily going to use some sort of routing in which large groups of destinations are given labels which refer to the entire group, so that the entire group may be tracked as a single entity (since the cost of dealing with each individual destination with that group, on a system-wide basis, is prohibitive). This process is going to be applied recursively. Whether the labels for those groups are globally unique, or only unique within some enclosing scope, the resulting sequence of group labels is a hierarchical address. In other words, large scale routing has to use hieraarchically structured topologically sensitive naming information; i.e. hierarchical addresses. > If I allow information as to how close all A.[1-100] are to each entry > node A.[a-j] to leak out into the area of the graph outside, but *near* > A, then you can get better routes. More overhead, of course, but more routes. We can do the same thing with 2 or 3 layers. Moreover, with fewer and larger layers, the data is leaked to smaller number of graph nodes *nearer* to A. The improvements in choice of entry router into A are related in part to how far information goes outside A, and in part to the number of layers of abstraction inside A. (I.e. *more* information outside A about how close individual destinations inside A are to the entry routers into A - the kind you'd get with flat addressing inside A - will produce some improvement in choice of entry router.) The exact balance between which produces better routing is very dependant on the exact topology, both inside and outside A. However, in the general case, it seems that increases in the amount of detail of information about the inside of A will usually produce only marginal improvments in the choice of entry router, at least compared to the cost. This result is particularly true if the address hierarchy inside A is reasonable; i.e. not non-optimal. It's not very useful to try and characterize this exactly, since any result would more or less have to assume single-metric routing, which is not what we are seeing in the Internet now. > The fallacy in your statement that "hierarchy, in general ... > concentrates load at root" can now be seen. If we have a physical > topology which, with *flat* routing, does not concentrate load, we can > create a hierarchical addressing scheme for it, which, with proper > adjustments to the routing data distribution, will have basically the > same traffic patterns; i.e. does not concentrate load. The "proper adjustments to the routing data distribution" is called "flat routing". No. I can show you topologies which are hierarchically addressed in which it is possible to create routing which produces *exactly* the same routes as flat addressing (i.e. optimal), but without as much routing overhead. This is obviously not definitive, since these are manufactured cases, but it shows that it is possible. Kleinrock and Kamoun's general result ("As regards network path length, we were able to place an upper bound on its increase due to the introduction of hierarchical routing...") is in fact directly applicable here, as is their further conclusion: "in the limit of very large networks, enormous table reductions may be achieved with essentially no increase in network path lengths". The reduction in table lengths is due to use of hierarchical addressing, but the result on path length is what's important. It shows that traffic patterns will be about the same, and thus, if the topology in question did not concentrate load with *flat* routing, we can see that creating a hierarchical addressing scheme for it won't concentrate load either. Noel From owner-Big-Internet@munnari.OZ.AU Tue Jun 28 04:13:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12801; Tue, 28 Jun 1994 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 EAA19384; Tue, 28 Jun 1994 04:13:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA19370; Tue, 28 Jun 1994 04:03:28 +1000 Precedence: list Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12443; Tue, 28 Jun 1994 04:03:23 +1000 (from barney@databus.databus.com) Date: Mon, 27 Jun 94 14:03 EDT Message-Id: <9406271403.AA29092@databus.databus.com> From: Barney Wolff To: dcrocker@mordor.stanford.edu (Dave Crocker) Cc: big-internet@munnari.OZ.AU Subject: Re: smart buildings, cars, doorknobs, coffee-cups, etc.... Content-Length: 935 Content-Type: text > Date: Mon, 27 Jun 1994 08:53:42 -0700 > From: dcrocker@mordor.stanford.edu (Dave Crocker) > > Internet Law of Addressing: > > An address is different from a protocol. We can, should and will give > addresses to things that might not be running a particular protocol, since > this makes reference to those things much easier, including proxy/gateway > access. > > Internet address has evolved to a model of global, unique, homogeneous > addressing largely because it is so much easier to deal with the > administration, and because what is local today may well turn out to need > to be global tomorrow. Yes but. Port # should count as part of the address in that case, so we have an extra 16 bits to play with if the protocol is TCP or UDP. This happens today with terminal servers. It's only when they run SLIP or PPP that each port gets its own IP address, and the TS is really a router. Barney Wolff From owner-Big-Internet@munnari.OZ.AU Tue Jun 28 05:43:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14111; Tue, 28 Jun 1994 04: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 EAA19434; Tue, 28 Jun 1994 04:53:37 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA19417; Tue, 28 Jun 1994 04:34:55 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10734; Tue, 28 Jun 1994 03:11:14 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25939; Mon, 27 Jun 94 13:11:10 -0400 Date: Mon, 27 Jun 94 13:11:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406271711.AA25939@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, kck@netcom.com Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: kck@netcom.com (Richard Fox) > If it is possible to reach consensus on this issue, it will almost > certainly make it easier to reach consensus on some of the other open > issues regarding "addresses". Why? The connection is very very small. I think the point is that if you have transport level names (TLN's) which are separate from the internetwork level names (ILN's), you can optimize each to their intended uses without having to worry about disoptimizing them to the other use in the process. I.e. it's easier to get agreement on how to make two things do one job each, than get agreement on how to make one thing do two jobs (especially if the two jobs have diametrically opposed requirements). E.g., you can think about whether the ILN's are variable length without having to drag in the issues of the cost to the transport layer (e.g. TCP) of variable length TLN's. (C.f. much of our recent discussions....) Noel From owner-Big-Internet@munnari.OZ.AU Tue Jun 28 05:44:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14262; Tue, 28 Jun 1994 04:58: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 EAA19460; Tue, 28 Jun 1994 04:58:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA19420; Tue, 28 Jun 1994 04:35:18 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10680; Tue, 28 Jun 1994 03:07:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25911; Mon, 27 Jun 94 13:06:58 -0400 Date: Mon, 27 Jun 94 13:06:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406271706.AA25911@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, sob@hsdndev.harvard.edu Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: sob@hsdndev.harvard.edu (Scott Bradner) A question much like this one went to the SIPP list last week .. One thing that seems to have been missing in the recent extensive discussions about address size options is a understanding of whether the transport level 'name' should be the same as the internetwork level 'name' I'm quite surprised this didn't generate more comment, since it seems (to me at least) to be a fairly crucial point. Maybe it already got talked out on the SIPP list (although since I can't find the archives, I can't see), or maybe everyone is just tired of this whole topic? Please address the following questions: 1/ are the transport and internetwork level names the same thing? From my own point of view, I think separate names are necessary (for various reasons, supplied if anyone still cares), but I'd like to hear reasons as to why that's not a good idea. 2/ if not, are they totally different or is the transport level name part of the internetwork level name? I can see circumstances under which you might want to make the TLN part of the ILN. However, what you are doing there is saying that at some level, the routers have to be able to translate the TLN's into last-hop hardware addresses - maybe it's only an ARP type thing, maybe the routing has to actually track TLN's across some limited scope. While I think it's OK to *allow* this, I don't want to *mandate* this, so I'd say that TLN's *may* be part of the ILN, but do not have to be. Noel From owner-Big-Internet@munnari.OZ.AU Tue Jun 28 14:14:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04636; Tue, 28 Jun 1994 14: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 OAA19944; Tue, 28 Jun 1994 14:13:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA19930; Tue, 28 Jun 1994 14:08:08 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04437; Tue, 28 Jun 1994 14:07:59 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 28 Jun 94 13:01:52 +0859 From: Masataka Ohta Message-Id: <9406280402.AA05429@necom830.cc.titech.ac.jp> Subject: Re: addressing elements To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 28 Jun 94 13:01:51 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406271636.AA25187@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 27, 94 12:36 pm X-Mailer: ELM [version 2.3 PL11] > However, in the general case, > it seems that increases in the amount of detail of information about the > inside of A will usually produce only marginal improvments in the choice of > entry router, at least compared to the cost. I'm afraid you are still assuming 20MB costs. > This result is particularly > true if the address hierarchy inside A is reasonable; i.e. not non-optimal. What "optimal" means when we don't have common sense on "cost"? > It's not very useful to try and characterize this exactly, since any result > would more or less have to assume single-metric routing, which is not what > we are seeing in the Internet now. I have already shown that multiple-metric 20KB of routing information per node does not cost so much. > > The fallacy in your statement that "hierarchy, in general ... > > concentrates load at root" can now be seen. If we have a physical > > topology which, with *flat* routing, does not concentrate load, we can > > create a hierarchical addressing scheme for it, which, with proper > > adjustments to the routing data distribution, will have basically the > > same traffic patterns; i.e. does not concentrate load. > > The "proper adjustments to the routing data distribution" is called > "flat routing". > > No. I can show you topologies which are hierarchically addressed in which it > is possible to create routing which produces *exactly* the same routes as flat > addressing (i.e. optimal), but without as much routing overhead. Obviously, tree topology is such an example and you will have load consentration. Anyway, we don't want to restrict connectivity topology because of a brain-dead routing algorithm. > Kleinrock and Kamoun's general result ("As regards network path length, we > were able to place an upper bound on its increase due to the introduction of > hierarchical routing...") is in fact directly applicable here, as is their > further conclusion: "in the limit of very large networks, enormous table > reductions may be achieved with essentially no increase in network path > lengths". We don't need "enormous table reduction". The issue is how much number of level should we support to have reasonable table size. OK? BTW, the result is wrong at least when the graph is densely, for example completely, connected where path length with flat routing is 1 but path length with hierarchical routing is logarithmic. > The reduction in table lengths is due to use of hierarchical addressing, but > the result on path length is what's important. It shows that traffic patterns > will be about the same, Wrong. As long as you have "border routers", load concentrates at the border routers. The solution is to have larger top level layer. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jun 28 15:11:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01782; Tue, 28 Jun 1994 12:54: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 MAA19852; Tue, 28 Jun 1994 12:53:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA19849; Tue, 28 Jun 1994 12:50:11 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01607; Tue, 28 Jun 1994 12:50:05 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 28 Jun 94 11:43:54 +0859 From: Masataka Ohta Message-Id: <9406280244.AA05154@necom830.cc.titech.ac.jp> Subject: Re: addressing elements To: dab@epilogue.com (Dave Bridgham) Date: Tue, 28 Jun 94 11:43:52 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9406271055.aa27960@quern.epilogue.com>; from "Dave Bridgham" at Jun 27, 94 10:55 am X-Mailer: ELM [version 2.3 PL11] > > If we were using our hierarchical addressing to do hiearchical routing, I > > would agree. However, there's no *necessary* link between the two. > > If we don't route hiearchically, we have no reason to have hierarchical > locators. > > We use the locators to find network information which goes into the > routing computation. The network connectivity and policy information > is kept heirarchically, this heirarchical locators. The route thus > generated need not follow that heirarchy. If network connectivity information is kept hierarchically, the generated route automatically follows the hierarchy. If you loosen the hierarchy of connectivity information for *near* routers as Noel mentioned, the hierarchy of generated route is also loosened. Still, routing between *far* routers are more strictly hierarchical and that's why we need hierarchical locators. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Tue Jun 28 17:48:22 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07627; Tue, 28 Jun 1994 15:34: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 PAA20021; Tue, 28 Jun 1994 15:33:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA20018; Tue, 28 Jun 1994 15:28:07 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02542; Tue, 28 Jun 1994 13:20:08 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 28 Jun 94 12:13:08 +0900 From: Masataka Ohta Message-Id: <9406280313.AA05277@necom830.cc.titech.ac.jp> Subject: Re: addressing elements To: Valdis.Kletnieks@vt.edu Date: Tue, 28 Jun 94 12:13:07 JST Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <199406271619.MAA05876@black-ice.cc.vt.edu>; from "Valdis.Kletnieks@vt.edu" at Jun 27, 94 12:19 pm X-Mailer: ELM [version 2.3 PL11] > Again - the issue is not "can we download 20MB of data to a router in a > second". The point I was making was that if you have too many entries > at one level, the paperwork gets difficult (witness the current explosion > of *.com addresses, with attendant registration issues, or the manpower that > Merit has to invest to type in all the entries into their data bases, etc). Maybe, you are right. But, I think we can automate most of the effort with secure e-mail. > Remember - that 20M had to come from *someplace*, and most likely it's a > summary abstract of a much larger database that also includes postal > addresses, contact names, service agreement invoice numbers, and all the > other things that the beancounter types like to know... I don't think the 20M information contains what should be available from DNS. I think the only measure to construct the best locator is, in most cases, cost/performance, for which purpose exchange of current quality (such as remaining capacity, delay, hop count etc.) and admission fee for various service types is enough. In some cases, policy control may be based on administrative hierarchy, that is, by EIDs. > /Valdis (who was trying to inject a 'human factors' point) But it is really difficult to guess future "human factors". So, based on the current figures, it's safe to say 20,000 node per host is acceptable. But it is unsafe to predict 200,000 will be unacceptable forever. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 02:05:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26399; Wed, 29 Jun 1994 00:34: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 AAA20468; Wed, 29 Jun 1994 00:33:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA20465; Wed, 29 Jun 1994 00:32:23 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23403; Tue, 28 Jun 1994 23:18:56 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Tue, 28 Jun 94 22:10:31 +0900 From: Masataka Ohta Message-Id: <9406281310.AA07286@necom830.cc.titech.ac.jp> Subject: Re: addressing elements To: kasten@ftp.com Date: Tue, 28 Jun 94 22:10:30 JST Cc: dab@epilogue.com, big-internet@munnari.OZ.AU In-Reply-To: <9406281232.AA25666@mailserv-D.ftp.com>; from "Frank Kastenholz" at Jun 28, 94 8:32 am X-Mailer: ELM [version 2.3 PL11] > I sent this note to Big-I about a week ago. It shows an example of > hierarchical locators, with a non-hierarchical topology, and the > selected route does not follow the hierarchy. (Well, the second part > of the note shows this...) It's a variant of Noel's local optimizaiton, local flattening of hierarchy. As I mentioned already, it is not useful for global communication. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 02:06:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27127; Wed, 29 Jun 1994 00:54: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 AAA20498; Wed, 29 Jun 1994 00:53:48 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id AAA20473; Wed, 29 Jun 1994 00:36:37 +1000 Precedence: list Received: from ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21878; Tue, 28 Jun 1994 22:34:12 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Tue, 28 Jun 1994 08:34:08 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Tue, 28 Jun 1994 08:34:08 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA25666; Tue, 28 Jun 94 08:32:12 EDT Date: Tue, 28 Jun 94 08:32:12 EDT Message-Id: <9406281232.AA25666@mailserv-D.ftp.com> To: mohta@necom830.cc.titech.ac.jp Subject: Re: addressing elements From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: dab@epilogue.com, big-internet@munnari.OZ.AU Content-Length: 4195 > If network connectivity information is kept hierarchically, the generated > route automatically follows the hierarchy. Masataka Ohta I sent this note to Big-I about a week ago. It shows an example of hierarchical locators, with a non-hierarchical topology, and the selected route does not follow the hierarchy. (Well, the second part of the note shows this...) Obviously, either you are wrong, or I am wrong, or we disagree about something. We should clear this up. Frank Kastenholz --------------------------------------------------------------------------- The routing and locator aggregation sub-systems are orthogonal to the forwarding subsystem. For example, consider a network that might look like this: +--------------+ +--------------+ | Provider A |--------| Provider B | +--------------+ L2 +--------------+ | L1 | L3 +--------------+ +--------------+ | University C | | Company D | +--------------+ +--------------+ The hierarchical locators for University C and Company D might be A:C and B:D, respectively. Provider A would 'advertise' into Provider B (over link L2) that it can reach all places with locator prefix A. Provider B would advertise into Company D (over link L3) that it could reach all places with locator prefix A as well as all places with locator prefix B (except places with locator prefix B:D). A routing table someplace in Company D might have the following entries: Destination Link A:* L3 B:* L3 B:D If the physical topology of the network is as I've drawn in the above diagram then packets going from Company D to University C would go along the path D->B->A->C. No form of Internetwork Protocol and Routing/Addressing Architecture can bridge the gap between C and D if there is no connection there. Now, suppose that the physical topology is as follows, with a link between B and C, drawn with '=' signs. +--------------+ +--------------+ | Provider A |--------| Provider B | +--------------+ L2 +--------------+ | L1 | L3 +--------------+ +--------------+ | University C |========| Company D | +--------------+ L4 +--------------+ The hierarchical locators are the same as in the earlier example, as are the advertisements. There is also an additional advertisement: University C will advertise over link L4, into Company D that A:C can be reached over that link. Routers in Company D will have routing tables that show something like: Destination Link A:* L3 A:C L4 B:* L3 B:D So, to send a packet from Company D to University C, a router would look at the routing table and do something like a longest match search, seeing that it can get to A:* over L3, but to A:C (its desired destination) over L4, and since the A:C entry is a longer match for the destination, this router would chose L4. There are, of course, more complications. For example, we might want to limit the traffic over L4 to just stuff between Company D and University C (otherwise it would become an alternate path between the two providers). Company D would then NOT advertise reachability to A:C over link L3. By 'advertise reachability' I do not strictly mean something like what is seen in a RIP packet. It is short hand for information disseminated by the routing information dissemination system... It could be simple Distance-Vector stuff ala RIP, it could be some form of link state advertisement ala OSPF, it could be maps ala Nimrod, it could be magic. Also, of course, more than just reachability may be advertised. All sorts of additional attributes (usage and charging policies, qos/tos, and so on) might be included in the disseminated information. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 02:54:06 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01954; Wed, 29 Jun 1994 02:54: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 CAA20689; Wed, 29 Jun 1994 02:53:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA20686; Wed, 29 Jun 1994 02:47:32 +1000 Precedence: list Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01843; Wed, 29 Jun 1994 02:47:29 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag.Eng.Sun.COM) by Sun.COM (sun-barr.Sun.COM) id AA23837; Tue, 28 Jun 94 09:41:45 PDT Received: from jurassic.Eng.Sun.COM (jurassic-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA10370; Tue, 28 Jun 94 09:42:12 PDT Received: by jurassic.Eng.Sun.COM (5.x/SMI-SVR4) id AA13053; Tue, 28 Jun 1994 09:41:00 -0700 Date: Tue, 28 Jun 1994 09:41:00 -0700 From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9406281641.AA13053@jurassic.Eng.Sun.COM> To: "Robert G. Moskowitz" <0003858921@mcimail.com> Cc: big internet In-Reply-To: <55940627104055/0003858921NA5EM@mcimail.com> Subject: IP in Cars [was Re: Why variable length?] Bob, > This info is from our electrical people that are designing the components. > USCar is a research group under the American Automotive Manufacturer's > Association (AAMA). My influence is with the Automotive Industry Action > Group (AIAG). I've been told that even IPv4 is viewed as too expensive per > component. Any data on why they think it is too expensive? It would be good to understand this. Bob From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 02:57:11 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02182; Wed, 29 Jun 1994 02: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 CAA20718; Wed, 29 Jun 1994 02:56:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA20683; Wed, 29 Jun 1994 02:42:58 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29014; Wed, 29 Jun 1994 01:44:17 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 29 Jun 94 00:37:50 +0859 From: Masataka Ohta Message-Id: <9406281538.AA07902@necom830.cc.titech.ac.jp> Subject: Re: addressing elements To: dab@epilogue.com (Dave Bridgham) Date: Wed, 29 Jun 94 0:37:48 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9406281058.aa05578@quern.epilogue.com>; from "Dave Bridgham" at Jun 28, 94 10:58 am X-Mailer: ELM [version 2.3 PL11] > Hierarchy > in the routing information means you *can* hide routing information. > It doesn't mean you must. If you don't hide anything behind hierarchy, the result is pure flat routing. > Whatever routing system we design should have the ability to tune this > parameter of routing efficiency vs fowarding efficiency. Ideally we'd > be able to adjust that parameter on a site by site and connection by > connection basis. You completely misunderstand the issue. Ideally, it should be unnecessary to tune anything. If a routing system needs a lot of hand configuration to make it run at moderate efficiency, it is a poor routing system. Wasn't a goal of NIMROD to make router configuration easy? Considering that even poor routers have capacity to handle a layer consisting of a lot of entities, we should use a small number of layers and near-best optimality is assured with default setting. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 03:14:00 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02696; Wed, 29 Jun 1994 03:14: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 DAA20745; Wed, 29 Jun 1994 03:13:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA20694; Wed, 29 Jun 1994 02:54:46 +1000 Precedence: list Received: from quern.epilogue.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01984; Wed, 29 Jun 1994 02:54:42 +1000 (from dab@epilogue.com) From: Dave Bridgham Sender: dab@epilogue.com To: mohta@necom830.cc.titech.ac.jp Cc: big-internet@munnari.OZ.AU In-Reply-To: Masataka Ohta's message of Wed, 29 Jun 94 0:37:48 JST <9406281538.AA07902@necom830.cc.titech.ac.jp> Subject: addressing elements Date: Tue, 28 Jun 94 12:53:33 -0400 Message-Id: <9406281253.aa06152@quern.epilogue.com> If you don't hide anything behind hierarchy, the result is pure flat routing. I didn't say don't hide anything. I said don't necessarily hide everything. Actually, what I said originally was simply that using heirarchical locators doesn't necessarily mean you *have* to hide everything. You completely misunderstand the issue. Ideally, it should be unnecessary to tune anything. If a routing system needs a lot of hand configuration to make it run at moderate efficiency, it is a poor routing system. The issue I sent mail about was only your comment that heirarchical locators then require you to use heirarchical routing. I may completely misunderstand the issue but you've said nothing to cause me to change my opinion that one does not imply the other. As to the question of should this routing information efficiency vs forwarding efficiency be tunable: the only way it would be rational for us to make it not tunable is if we have reasonable confidence that one answer is right for the entire network and that we can determine that answer now. I think both of those answers are `no' thus I conclude that leaving it tunable is the best choice. Wasn't a goal of NIMROD to make router configuration easy? Not as far as I know. Actually, I suppose it depends on what you mean by `router'; the route calculator or the packet forwarder are the usual two possible meanings but the context of our conversation I think applies more to the map generators of Nimrod. They are the ones concerned with what information gets eliminated at each step up the locator heirarchy. Considering that even poor routers have capacity to handle a layer consisting of a lot of entities, we should use a small number of layers and near-best optimality is assured with default setting. Well, actually I agree with this. And that's how I'd configure a net I was designing. But if I'm architecting a network layer protocol that I want to scale to an inconceivable size, I have to allow for a lot more layers than I think the Internet needs today. Since the tuning that I talk about happens at layer boundries, there would be additional layers added for tuning purposes. Layers would be used for administrative and policy aggregation, more layers. So be it. We need lots more layers than the minimum we can calculate strictly from number of destination on the net calculations. Dave From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 03:26:32 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01324; Wed, 29 Jun 1994 02:36: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 CAA20656; Wed, 29 Jun 1994 02:33:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA20653; Wed, 29 Jun 1994 02:31:23 +1000 Precedence: list Received: from quern.epilogue.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27453; Wed, 29 Jun 1994 00:59:21 +1000 (from dab@epilogue.com) From: Dave Bridgham Sender: dab@epilogue.com To: mohta@necom830.cc.titech.ac.jp Cc: big-internet@munnari.OZ.AU In-Reply-To: Masataka Ohta's message of Tue, 28 Jun 94 11:43:52 JST <9406280244.AA05154@necom830.cc.titech.ac.jp> Subject: addressing elements Date: Tue, 28 Jun 94 10:58:56 -0400 Message-Id: <9406281058.aa05578@quern.epilogue.com> Precedence: list From: Masataka Ohta Date: Tue, 28 Jun 94 11:43:52 JST X-Mailer: ELM [version 2.3 PL11] If network connectivity information is kept hierarchically, the generated route automatically follows the hierarchy. If the network connectivity information includes connectivity that shortcuts the heirarchy, there is no reason why the route can't also shortcut the heirarchy. If you loosen the hierarchy of connectivity information for *near* routers as Noel mentioned, the hierarchy of generated route is also loosened. Still, routing between *far* routers are more strictly hierarchical and that's why we need hierarchical locators. Near or far routers doesn't really matter. Doing less information hiding means you're being less efficient with information but perhaps more efficient with packet forwarding due to better routes. Hierarchy in the routing information means you *can* hide routing information. It doesn't mean you must. Whatever routing system we design should have the ability to tune this parameter of routing efficiency vs fowarding efficiency. Ideally we'd be able to adjust that parameter on a site by site and connection by connection basis. Dave From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 05:28:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03448; Wed, 29 Jun 1994 03:33: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 DAA20778; Wed, 29 Jun 1994 03:33:49 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA20775; Wed, 29 Jun 1994 03:32:51 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03068; Wed, 29 Jun 1994 03:21:09 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 29 Jun 94 02:14:43 +0900 From: Masataka Ohta Message-Id: <9406281714.AA08181@necom830.cc.titech.ac.jp> Subject: Re: addressing elements To: dab@epilogue.com (Dave Bridgham) Date: Wed, 29 Jun 94 2:14:41 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9406281253.aa06152@quern.epilogue.com>; from "Dave Bridgham" at Jun 28, 94 12:53 pm X-Mailer: ELM [version 2.3 PL11] > If you don't hide anything behind hierarchy, the result is pure flat > routing. > > I didn't say don't hide anything. Then, you need hierarchical locators. > The issue I sent mail about was only your comment that heirarchical > locators then require you to use heirarchical routing. Read the log. My comment was: :If we don't route hiearchically, we have no reason to have hierarchical :locators. Hierarchical routing requires hierarchical locators. > I may completely misunderstand the issue Yes, you do. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 05:28:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03553; Wed, 29 Jun 1994 03: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 DAA20793; Wed, 29 Jun 1994 03:36:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA20772; Wed, 29 Jun 1994 03:28:16 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02274; Wed, 29 Jun 1994 03:02:29 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id KAA01179; Tue, 28 Jun 1994 10:02:22 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Jun 1994 10:02:27 -0700 To: "Robert G. Moskowitz" <0003858921@mcimail.com> From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: use of crypto (was: assignment efficiency) Cc: big internet (Bob knows about this, but for the rest of you...) At 4:06 AM 6/22/94, Robert G. Moskowitz wrote: >I really don't believe in the VAN trust model. We have seen the taps off to >the gov in the TELCO NOCS. Whoops shouldn't have said that in public :) The questions of Internet security, reliability and performance are of very major interest to the EDI working group. It is about to begin development of an informational "usage" document to give guidance to potential users of EDI (electronic data interchange, structured forms) over the Internet. An obvious and major question concerns applicability and tradeoffs among the private line, third-party trust, and encryption options. The third-party trust (VAN) model is fundamental to much current EDI use, so there is pointed interest in whether incorporation of the Internet alternative can or should be accomplished differently. (Shameless plug: The working group will be holding two sessions on this topic at the Toronto IETF and both will be broadcast over the Mbone.) Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 05:34:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07768; Wed, 29 Jun 1994 05:34: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 FAA20912; Wed, 29 Jun 1994 05:33:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA20909; Wed, 29 Jun 1994 05:26:59 +1000 Precedence: list Received: from quern.epilogue.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03288; Wed, 29 Jun 1994 03:31:01 +1000 (from dab@epilogue.com) From: Dave Bridgham Sender: dab@epilogue.com To: mohta@necom830.cc.titech.ac.jp Cc: big-internet@munnari.OZ.AU In-Reply-To: Masataka Ohta's message of Wed, 29 Jun 94 2:14:41 JST <9406281714.AA08181@necom830.cc.titech.ac.jp> Subject: addressing elements Date: Tue, 28 Jun 94 13:30:32 -0400 Message-Id: <9406281330.aa06493@quern.epilogue.com> From: Masataka Ohta Date: Wed, 29 Jun 94 2:14:41 JST X-Mailer: ELM [version 2.3 PL11] > If you don't hide anything behind hierarchy, the result is pure flat > routing. > > I didn't say don't hide anything. Then, you need hierarchical locators. I never argued against heirarchical locators. > The issue I sent mail about was only your comment that heirarchical > locators then require you to use heirarchical routing. My comment was: :If we don't route hiearchically, we have no reason to have hierarchical :locators. Hierarchical routing requires hierarchical locators. Your second statement may be true, I havn't thought about it and since I'm trying to avoid heirarchical routing I'm not that interested right now. Your first statement though is not true. I've been attempting to describe to you how heirarchical locators are useful even if you're not doing heirarchical routing. > I may completely misunderstand the issue Yes, you do. Fine, I give up. Dave From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 07:26:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10043; Wed, 29 Jun 1994 06:33: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 GAA20979; Wed, 29 Jun 1994 06:33:50 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA20963; Wed, 29 Jun 1994 06:19:03 +1000 Precedence: list Received: from THIALFI.CS.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05679; Wed, 29 Jun 1994 04:28:19 +1000 (from vogels@cs.cornell.edu) Received: from CLOYD.CS.CORNELL.EDU by thialfi.cs.cornell.edu (5.67/I-1.99F) id AA04972; Tue, 28 Jun 94 14:28:02 -0400 Received: from GUNGNIR.CS.CORNELL.EDU by cloyd.cs.cornell.edu (5.67/I-1.99F) id AA04740; Tue, 28 Jun 94 14:28:07 -0400 Message-Id: <9406281828.AA09654@gungnir.cs.cornell.edu> Received: by gungnir.cs.cornell.edu (5.67/N-0.13aa) id AA09654; Tue, 28 Jun 94 14:28:01 -0400 To: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Cc: big internet Subject: Re: IP in Cars [was Re: Why variable length?] In-Reply-To: Your message of "Tue, 28 Jun 1994 09:41:00 PDT." <9406281641.AA13053@jurassic.Eng.Sun.COM> Date: Tue, 28 Jun 1994 14:28:00 -0400 From: Werner Vogels > > This info is from our electrical people that are designing the components. > > USCar is a research group under the American Automotive Manufacturer's > > Association (AAMA). My influence is with the Automotive Industry Action > > Group (AIAG). I've been told that even IPv4 is viewed as too expensive per > > component. > > Any data on why they think it is too expensive? It would be good to > understand this. Bob, I do not know about the decision process for American manufacturers but in Europe a simular decision was made. For device operation in a closed environment like a car network it is desirable to use protocols that produce minimal overhead. For this the protocols used need to be dedicated to the specific tasks and may not include any additional overhead. Bytes and bits on the wire and in the components used really count. [ this in contrast with the current internetworking addressing proposals ... ] The embedded software does not run a generic operating system with dynamic allocation of UPD ports, etc. The whole environment is static, expect for possible mode changes (to the next static environment) and as such there is no need for any flexibility, no (tcp) flow control, no fragmentation, no dynamic routing, no forwarding, etc. Only two things could be taken out of it and that would be station and endpoint addressing. All other functionality is not needed in such a static environment. To use a worldwide IPv4 numbering scheme would waste to many bytes on the wire and in the components. The new bus technologies used in these type of environments often requir close interaction between protocols and bus access method. Exploiting TDMA access allows for complete removal of network and transport layers, collapsing them into a few bytes. A good example of this type of protocol is TTP from Herman Kopetz's MARS project (not proprietary yet) which will possibly turn up in your Mercedes Benz in the very near future. The Time Triggered Protocol does not only provide TDMA based transport, but also time synchronization, multicast,component group membership and others. All in a minimum of rom, ram and wire space. In the automotive industry a major cost factor is component and wire costs, every 50 cents that can be cut back on components, from wire to memory, will result in millions of dollars more revenue. Incorporating full IPv4/TCP/UDP into the car network would cost every manufacturer millions with no advantage at the network level. -- Werner [ the current old fashioned wired cars have about 60 to 80 kilograms of wires in them, the new car networks will not weigh more than 1 to 2 kilograms. think what that will do to your fuel efficiency .... ] From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 07:54:04 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12609; Wed, 29 Jun 1994 07:54: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 HAA21073; Wed, 29 Jun 1994 07:53:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id HAA21059; Wed, 29 Jun 1994 07:38:22 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10591; Wed, 29 Jun 1994 06:50:00 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from localhost by Mordor.Stanford.EDU (8.6.4/inc-1.0) id NAA02496; Tue, 28 Jun 1994 13:49:54 -0700 Message-Id: <199406282049.NAA02496@Mordor.Stanford.EDU> To: Werner Vogels Cc: big internet Cc: dcrocker@Mordor.Stanford.EDU Subject: Re: IP in Cars [was Re: Why variable length?] Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 28 Jun 94 14:28:00 -0400. <9406281828.AA09654@gungnir.cs.cornell.edu> Date: Tue, 28 Jun 94 13:49:54 -0700 From: Dave Crocker X-Mts: smtp While it's always dangerous to use a technology beyond its capabilities, I wonder... ---- Included message: For device operation in a closed environment like a car network it is desirable to use protocols that produce minimal overhead. For this the protocols used need to be dedicated to the specific tasks and may not include any additional overhead. Bytes and bits on the wire and in I believe that the original debates about TCP, IP, etc. considered this question frequently. For example, when TCP was put on a LAN -- a very controversial topic at the time -- exactly this concern about 'wasted' bits was raised. The feeling then was that homogeneity was so useful that the localized "inefficiencies" were worth it. It will be interesting to see if the assumptions of limited scope, used to justify using other core protocols, hold up in this case. d/ From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 08:34:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14020; Wed, 29 Jun 1994 08:33: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 IAA21126; Wed, 29 Jun 1994 08:33:52 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA21112; Wed, 29 Jun 1994 08:20:56 +1000 Precedence: list Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13321; Wed, 29 Jun 1994 08:13:57 +1000 (from kre@munnari.OZ.AU) To: Dave Crocker Cc: big internet Subject: Re: IP in Cars [was Re: Why variable length?] In-Reply-To: Your message of "Tue, 28 Jun 1994 13:49:54 MST." <199406282049.NAA02496@Mordor.Stanford.EDU> Date: Wed, 29 Jun 1994 08:13:52 +1000 Message-Id: <25209.772841632@munnari.OZ.AU> From: Robert Elz Date: Tue, 28 Jun 94 13:49:54 -0700 From: Dave Crocker Message-ID: <199406282049.NAA02496@Mordor.Stanford.EDU> The feeling then was that homogeneity was so useful that the localized "inefficiencies" were worth it. I know nothing whatever about what goes on inside cars (either related to the networking in there, or just the boring old combustion stuff, etc), but I do write code sometimes for small embedded processor type things - including comms systems. On some of these its simply impossible to implement IP - often I work on processors (systems) with something of the order of 100 bytes of ram available. That means its simply impossible to receive (and reassemble if necessary) the minimum required IP packet (576 bytes). Implementing some form of bastard IP would be possible, but it wouldn't generally interoperate with anything much because of the packet size limitation. Incidentally, lots of useful control & comms stuff can be implemented in 100 bytes of ram - packet sizes are typically of the order of 5 or 6 bytes (total, incl checksums) and just report status or accept simple commands. I wouldn't be in the least surprised to learn that networks inside cars need something of this nature, and run in processors of this size. kre From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 11:54:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22505; Wed, 29 Jun 1994 11: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 LAA21303; Wed, 29 Jun 1994 11:53:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA21300; Wed, 29 Jun 1994 11:41:33 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21983; Wed, 29 Jun 1994 11:41:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07568; Tue, 28 Jun 94 21:41:19 -0400 Date: Tue, 28 Jun 94 21:41:19 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406290141.AA07568@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: sob@hsdndev.harvard.edu (Scott Bradner) whether the transport level 'name' should be the same as the internetwork level 'name', as they are with the current IPv4 "address" ... Please address the following questions: 1/ are the transport and internetwork level names the same thing? Yo! Wake up out there! If you *don't* reply, the IPng AD's are going to think that *nobody* wants to separate end-end names (e.g. EID's) from toplogically sensitive names (e.g. locators). If you favor such a split (e.g. into locators and EID's,), *SAY SO NOW*. Can everyone who thinks we need to split these two apart *please* send a message, at least to Allison and Scott, if not to Big-I? For those who don't understand the question, here's the reasoning in a nutshell. For things like TCP, you want a "name" which stays the same no matter where you go in the network, so you can tell the thing you're talking to over here is the same thing you were talking to over there. However, the routing requires a "name" which depends on where you are in the network, since it uses that to get the data to you. You can't have one "name" which stays the same wherever you are, and changes depending on where you are; ergo, you need two "names". Noel From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 12:54:31 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25094; Wed, 29 Jun 1994 12: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 MAA21368; Wed, 29 Jun 1994 12:53:55 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA21354; Wed, 29 Jun 1994 12:37:48 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24294; Wed, 29 Jun 1994 12:37:40 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Wed, 29 Jun 94 11:31:11 +0900 From: Masataka Ohta Message-Id: <9406290231.AA09767@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs request To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 29 Jun 94 11:31:09 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406290141.AA07568@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 28, 94 9:41 pm X-Mailer: ELM [version 2.3 PL11] > From: sob@hsdndev.harvard.edu (Scott Bradner) > > whether the transport level 'name' should be the same as the internetwork > level 'name', as they are with the current IPv4 "address" ... Please > address the following questions: 1/ are the transport and internetwork > level names the same thing? > > Yo! Wake up out there! If you *don't* reply, the IPng AD's are going to think > that *nobody* wants to separate end-end names (e.g. EID's) from toplogically > sensitive names (e.g. locators). What a confusion of terminology! I think EID is, like domain name, a network level name. From EID, through DNS or other mechanism, host specific information such as host's public key or host's locators could be looked up. At least, I think "end-end" means "end_port-end_port". On the other hand, I don't think "locator" a name. It is, at least, not at network layer, as transport connections with different policies will use different locators. > If you favor such a split Yes, but is it really what IPng directorates are asking? > You can't have one "name" which stays the > same wherever you are, and changes depending on where you are; ergo, you need > two "names". Given SMIP, I don't think we need two names for location independence. I want to have locators and EID as separate concept because: EID should follow administration hierarchy. EID should not be forced to follow geographical hierarchy. Locators should not be forced to follow administration hierarchy, which enables us to have only 2 or 3 layers for routing. Locators should follow geographical hierarchy. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 16:59:09 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03043; Wed, 29 Jun 1994 15:54: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 PAA21529; Wed, 29 Jun 1994 15:53:58 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA21526; Wed, 29 Jun 1994 15:48:33 +1000 Precedence: list Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29343; Wed, 29 Jun 1994 14:32:33 +1000 (from dcrocker@mordor.stanford.edu) Received: from [128.102.17.23] by Mordor.Stanford.EDU (8.6.4/inc-1.0) id VAA05211; Tue, 28 Jun 1994 21:32:25 -0700 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 28 Jun 1994 21:32:27 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: dcrocker@mordor.stanford.edu (Dave Crocker) Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu At 6:41 PM 6/28/94, Noel Chiappa wrote: >Yo! Wake up out there! If you *don't* reply, the IPng AD's are going to think >that *nobody* wants to separate end-end names (e.g. EID's) from toplogically whoah! thanks, Noel. I almost missed that point. **IPng ADs**: You listening out there? I wish to register my view. I, for one, DO NOT want to separate end-end names (e.g. EID's) from toplogically sensitive names. Dave +1 408 246 8253 (fax: +1 408 249 6205) From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 21:34:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15747; Wed, 29 Jun 1994 21: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 VAA21824; Wed, 29 Jun 1994 21:34:04 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA21821; Wed, 29 Jun 1994 21:28:43 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15672; Wed, 29 Jun 1994 21:28:39 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA01222; Wed, 29 Jun 94 06:30:20 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ae26155; 29 Jun 94 11:26 GMT Date: Wed, 29 Jun 94 06:27 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Bob Hinden Cc: big internet Subject: Re: IP in Cars [was Re: Why variable length?] Message-Id: <20940629112702/0003858921NA1EM@mcimail.com> >>This info is from our electrical people that are designing the components. >>USCar is a research group under the American Automotive Manufacturer's >>Association (AAMA). My influence is with the Automotive Industry Action >>Group (AIAG). I've been told that even IPv4 is viewed as too expensive >>per component. >Any data on why they think it is too expensive? It would be good to >understand this. I am working on getting in contact with one of the engineers in electrical to get a correct answer to this. Bob From owner-Big-Internet@munnari.OZ.AU Wed Jun 29 21:38:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15815; Wed, 29 Jun 1994 21:38: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 VAA21839; Wed, 29 Jun 1994 21:38:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id VAA21818; Wed, 29 Jun 1994 21:28:29 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15664; Wed, 29 Jun 1994 21:28:24 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA01209; Wed, 29 Jun 94 06:29:50 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id ad26155; 29 Jun 94 11:26 GMT Date: Wed, 29 Jun 94 06:26 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Scott Bradner To: big internet Subject: Re: IPng ADs request Message-Id: <25940629112652/0003858921NA1EM@mcimail.com> > Picking up on something that Noel mentioned in a posting a while >back, we would like to request that a particular issue be discussed. I've been busy caring for my family's flu bugs and have not gotten around to this one. > One thing that seems to have been missing in the recent extensive >discussions about address size options is a understanding of >whether the transport level 'name' should be the same as the internetwork >level 'name', as they are with the current IPv4 "address", or be different >in some way. > In IPv4 the transport name is: > > The question referrs to the two IP address fields. I for one like EIDs as a part of the IPng address for a number of reasons. I thus see the IPng TLN being: One value of EIDs is in the decoupling of topology from address density. Of course if we role out a new routing protocol along with IPng, this might not be needed. That is any association of IPng address with topology. I think that all of the IPng address bit twiddling that involve have locator as some sort of network topology and EID as an absolute address. Many of them seem to assume, as well they might, that topology locator <> routing. I think I've gotten the drift of a number of the discussions here. Another potential value to corporations of the EID is inventorying. EIDs can be assigned to devices as they come into the organization and then tracked as they move around. It becomes almost an asset tag. Another value of EIDs to manufactures is their potential as a serial number. I can just see EIDs becoming a part of the VIN :) The industry would just love another change to VINs.... Oh, for those of you that have a car older than about 10 years, the Vehicle Information Number has to be clearly displayed on all cars sold in the US, typically right at the base of the front windshield on the driver's side. Yes I disagree that users will have or need complete numbering control of all devices on their networks. In special purpose cases (like electric meters, cars, toasters, etc) the value of a vendor supply number is great and you still can have the security you need. Bob Moskowitz Chrysler Corp From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 03:02:20 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26476; Thu, 30 Jun 1994 02:17: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 CAA22138; Thu, 30 Jun 1994 02:14:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id BAA22124; Thu, 30 Jun 1994 01:59:48 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25775; Thu, 30 Jun 1994 01:59:44 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11726; Wed, 29 Jun 94 11:59:29 -0400 Date: Wed, 29 Jun 94 11:59:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406291559.AA11726@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, pvm@isi.edu Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: Paul Mockapetris It would also really help to understand when the binding should take place and how permanent it is. Well, the example I mentioned (host mobility) shows that the binding is not terribly strong. I view the binding as being made at the time a DNS lookup is done (multi-homed hosts would return multiple "routing names"), and it can be changed thereafter in the case of mobile hosts (with that mechanism being adequately secured to prevent denial-of-service or other attacks). For example, if I have a host with two network adapter cards, and one card breaks, so I swap in a network card from another host, how did I keep track of these EIDs and how many were there? You're assuming that the transport level name (TLN) is generated from a "unique number" on the interface, but a number of people have pointed out that you can't rely on 802 numbers to really be unique. Case B: same story but I change disk drives. This is exactly the same problem as changing disk drives now, with IPv4 addresses, if the address is configured in the host, and not on a BOOTP server. Similarly, why not push this problem into a higher level protocol. The three best answers are i) we wish to identify the end-end entity (i.e. fate-sharing region) inside the host explicitly, and not have it be dependent on which transport protocol is in use; ii) we wish to avoid having multiple naming spaces, one for each transport protocol, but would rather have a single naming mechanism that all can use; iii) a variety of problems, such as mobile hosts, multiple interfaces, etc are easier to solve if this TLN->"routing name" binding is visible at the internetwork layer. I have heard different answers when I ask these questions and would like to understand if there is consensus. My guess (and I emphasize that) is that the majority of people who would like to see separate namespaces more or less agree about when they each do, etc. I have no idea what the balance is between those who do and do not want separate names. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 03:11:56 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26997; Thu, 30 Jun 1994 02: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 CAA22168; Thu, 30 Jun 1994 02:34:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA22165; Thu, 30 Jun 1994 02:30:15 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26895; Thu, 30 Jun 1994 02:30:12 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12022; Wed, 29 Jun 94 12:30:09 -0400 Date: Wed, 29 Jun 94 12:30:09 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406291630.AA12022@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, mohta@necom830.cc.titech.ac.jp Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: Masataka Ohta I think EID is, like domain name, a network level name. Yes. From EID, through DNS or other mechanism, host specific information such as host's public key or host's locators could be looked up. I would think that usually you'd pass around the (EID, locator) as a pair, so you wouldn't need to do this lookup, but I suppose there might be uses for it. At least, I think "end-end" means "end_port-end_port". Well, I was more thinking in terms of "end-end" as used in the classic paper "End-End Arguments in System Design" (by Clark, Saltzer and Reed; which I keep meaning to get put up as an RFC... sigh); i.e. the ultimate source, and the final consumer, of the data. On the other hand, I don't think "locator" a name. I was using "name" in the formal computer-science sort of way, as an "identifier" or "label". > If you favor such a split Yes, but is it really what IPng directorates are asking? Yes, I'm certain this is their question. Given SMIP, I don't think we need two names for location independence. Sorry, I just gave location independence as one example of a reason for separating the two. There are, of course, many others, such as the one you point out. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 03:12:20 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27864; Thu, 30 Jun 1994 02:59:46 +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 AA26141 Thu, 30 Jun 1994 02:59:42 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id CAA22198; Thu, 30 Jun 1994 02:54:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id CAA22195; Thu, 30 Jun 1994 02:51:17 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24412; Thu, 30 Jun 1994 01:27:46 +1000 (from pvm@ISI.EDU) Received: from zephyr.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Wed, 29 Jun 1994 08:26:20 -0700 Message-Id: <199406291526.AA24425@zephyr.isi.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Reply-To: pvm@isi.edu Subject: Re: IPng ADs request In-Reply-To: Your message of Tue, 28 Jun 1994 21:41:19 -0400. <9406290141.AA07568@ginger.lcs.mit.edu> Date: Wed, 29 Jun 94 08:26:19 PDT From: Paul Mockapetris It would also really help to understand when the binding should take place and how permanent it is. For example, if I have a host with two network adapter cards, and one card breaks, so I swap in a network card from another host, how did I keep track of these EIDs and how many were there? Case B: same story but I change disk drives. Similarly, why not push this problem into a higher level protocol. I apologize for asking these questions, which are probably straight out of the "opening book moves" for this debate, but I have heard different answers when I ask these questions and would like to understand if there is consensus. paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 03:23:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28925; Thu, 30 Jun 1994 03:23: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 DAA22278; Thu, 30 Jun 1994 03:23:03 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA22242; Thu, 30 Jun 1994 03:11:52 +1000 Precedence: list Received: from gatekeeper.mcimail.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27480; Thu, 30 Jun 1994 02:47:00 +1000 (from 0003858921@mcimail.com) Received: by gatekeeper.mcimail.com (5.65/fma-120691); id AA16720; Wed, 29 Jun 94 11:48:17 -0500 Received: from mcimail.com by MCIGATEWAY.MCIMail.com id cb18132; 29 Jun 94 16:44 GMT Date: Wed, 29 Jun 94 11:41 EST From: "Robert G. Moskowitz" <0003858921@mcimail.com> To: Noel Chiappa To: big internet Subject: Re: IPng ADs request Message-Id: <30940629164103/0003858921NA2EM@mcimail.com> >>I for one like EIDs as a part of the IPng address for a number of reasons. >Err, did you mean this "part of" business literally, that the transport >name (e.g. EID) and "routing name" (e.g. locator) would be an indissoluble >pair? The whole charm of having two is that you can have one->many bindings >(e.g. for a host which has multiple interfaces), or that the binding can >change (e.g. for a mobile host, mobile processes, etc). not indissoluble. After all if the manufacture of an imbedded system set the EID, the owner of it would need to set the locator. And the multiple interface is another excellent example. The EID identifies the unit. This could thus factor into a access selection method independent to DNS if that were needed. I don't see it for mobile processes, we are defining hardware components here I thought, not applications. But definitely the mobile host stuff might change considerablely with this, but somehow I don't think it will. Oh, another definition of a mobile host, one that attaches to different networks at different times, like sniffers, RMONs, etc, then yes, they would 'learn' their locator from a locator server, but the EID is fixed. >>all of the IPng address bit twiddling that involve have >>locator as some sort of network topology and EID as an absolute address. >>Many of them seem to assume, as well they might, that topology locator <> >>routing. >I didn't catch this last sentence? That is to say the locator in the IPng address is not the routing path of the packet. That routing can be determined by some mechinism outside of the IPng address. Of course, the trivial case would equate them I suppose. Does this clearify my views? Bob From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 03:26:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28581; Thu, 30 Jun 1994 03:14: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 DAA22248; Thu, 30 Jun 1994 03:14:09 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA22239; Thu, 30 Jun 1994 03:11:43 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28180; Thu, 30 Jun 1994 03:07:12 +1000 (from asp@uunet.uu.net) Received: from [153.39.128.10] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA26059 Thu, 30 Jun 1994 02:54:53 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwwkh12546; Wed, 29 Jun 1994 12:52:11 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: Subject: Re: IPng ADs request To: big-internet@munnari.OZ.AU Date: Wed, 29 Jun 1994 12:52:10 -0400 (EDT) In-Reply-To: from "Dave Crocker" at Jun 28, 94 09:32:27 pm X-Mailer: ELM [version 2.4 PL17] Content-Type: text Content-Length: 137 I'll register my vote too. I think that seperating EIDs from topoligical names is a very good idea. --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 03:26:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28765; Thu, 30 Jun 1994 03:18: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 DAA22263; Thu, 30 Jun 1994 03:18:33 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA22225; Thu, 30 Jun 1994 03:00:28 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26526; Thu, 30 Jun 1994 02:19:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11941; Wed, 29 Jun 94 12:19:06 -0400 Date: Wed, 29 Jun 94 12:19:06 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406291619.AA11941@ginger.lcs.mit.edu> To: 0003858921@mcimail.com, big-internet@munnari.OZ.AU Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: "Robert G. Moskowitz" <0003858921@mcimail.com> I for one like EIDs as a part of the IPng address for a number of reasons. Err, did you mean this "part of" business literally, that the transport name (e.g. EID) and "routing name" (e.g. locator) would be an indissoluble pair? The whole charm of having two is that you can have one->many bindings (e.g. for a host which has multiple interfaces), or that the binding can change (e.g. for a mobile host, mobile processes, etc). all of the IPng address bit twiddling that involve have locator as some sort of network topology and EID as an absolute address. Many of them seem to assume, as well they might, that topology locator <> routing. I didn't catch this last sentence? Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 03:29:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29369; Thu, 30 Jun 1994 03:29: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 DAA22304; Thu, 30 Jun 1994 03:28:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id DAA22245; Thu, 30 Jun 1994 03:12:49 +1000 Precedence: list Received: from tigger.jvnc.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28177; Thu, 30 Jun 1994 03:07:05 +1000 (from corecom@tigger.jvnc.net) Received: from franklin-tty16.jvnc.net. (franklin-tty16.jvnc.net) by tigger.jvnc.net with SMTP id AA19039 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Wed, 29 Jun 1994 13:06:51 -0400 Message-Id: Date: Wed, 29 Jun 94 13:06:01 EDT From: "David M. Piscitello" Subject: Re: Assignment Efficiency Reply-To: dave@corecom.com To: big-internet@munnari.OZ.AU X-Mailer: VersaTerm Link v1.1.1 in response to statements like... >To that end, are we in agreement that nowhere would we allow 2**28 >inefficiency in subscriber assignment? Would 2**4 be an acceptable >maximum, or should we stick to the current 2**2? and >You, the NON-paying customers, are requesting the rest of us to pay to >support your fantasy. >I have not yet seen your offer to pay even at a annual rate of $0.001 >for each allocated address, since that would be _vast_ quantities of >money for a sparse space. and especially, >To paraphrase yet another, "You can't have it!" I'd like to offer a comment regarding ownership and enforcement of same. I think the current reality is (a) organizations will either obtain what they need from an address registration authority, or (b) they will not register; IP technology is purchased independently of addressing, and we have absolutely no means of preventing folks from assigning addresses without registering. We ought to make it desirable to register, not daunting or difficult. We all suffer if we don't. We ought to care that folks aren't registering addresses *today*, for several reasons. First, we are unnaturally balkanizing the internet by driving them away. Second, even if we conclude that driving them away is good, we don't necessarily drive them away forever. Eventually, those same folks show up at the door of an Internet provider with (presumably) large numbers of connection points (they did ask for lots of numbers in the first place, and while they express a strong unwillingness to renumber from net 10.0.0.0, they are willing to pay ENORMOUS sums of money to be connected to or through the public Internet. In a competitive environment, if one ISP says no, another will agree. Several ISPs are already attempting to cope with such users, and it's not a pretty sight. David M. Piscitello Core Competence, Inc. 1620 Tuckerstown Road Dresher, PA 19025 USA dave@corecom.com 1.215.830.0692 From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 04:34:38 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00706; Thu, 30 Jun 1994 04:34: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 EAA22389; Thu, 30 Jun 1994 04:34:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA22386; Thu, 30 Jun 1994 04:30:00 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00452; Thu, 30 Jun 1994 04:29:51 +1000 (from kasten@mailserv-D.ftp.com) Received: from [128.127.2.122] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27294 Thu, 30 Jun 1994 04:06:41 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 29 Jun 1994 14:04:03 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 29 Jun 1994 14:04:03 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA02666; Wed, 29 Jun 94 14:02:07 EDT Date: Wed, 29 Jun 94 14:02:07 EDT Message-Id: <9406291802.AA02666@mailserv-D.ftp.com> To: pvm@isi.edu Subject: Re: IPng ADs request From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 3180 > It would also really help to understand when the binding should take > place and how permanent it is. For example, if I have a host with two > network adapter cards, and one card breaks, so I swap in a network card > from another host, how did I keep track of these EIDs and how many > were there? Case B: same story but I change disk drives. This is a tough question. My stock answer is that a name should last as long as the thing which it names. This is as much an administrative issue as it is a technical one. Consider, suppose that the PC on my desk is taken and given to another person here at ftp, the machine gets a new node name, new IP Address (or IPng Locator), new person, and so on. From the network's perspective, is this the same node? Would it keep the same transport level name(s)? Perhaps. Perhaps not (I could imagine that the PC has several transport level names -- one assigned by our systems department which stays with each piece of hardware through its life at ftp in order to track it for inventory and network management operations; another name might be for a mobile process that is wandering around here trying to find large prime numbers as background compute tasks, and so on). Names should not necessarily be bound to IEEE numbers (you give a real good example showing why not). However, if a local administration wishes to, it should be allowed (presumably, this local administration understands the risk/benefit tradeoff). As to disk drives, presumably you backup your system? Either this change was unexpected, in which case you have to restore the system from backup (in which case, the backup has all the names assigned to the machine) or re-install the software, in which case you have a whole lot of stuff to rebuild and transport-level-names are only a small, minor, headache. Or the change was expected, in which case, you restore the information from the backup made before the change. The binding (or re-binding) between transport- and network-level names is a key to this whole thing. By being able to dynamically change the binding we'll be able to support mobility of anything that can be named. > Similarly, why not push this problem into a higher level protocol. To a certain degree, having two names (transport- and network- level) _is_ pushing some problems to a higher level. It removes an interdependancy between the two. Now, issues that are somewhat more the transport-level's business instead of the network-level's business can be dealt with solely at the transport level... Each would have its own name space to be structured and used as best fits the needs of that level. > I apologize for asking these questions, which are probably straight > out of the "opening book moves" for this debate, but I have heard > different answers when I ask these questions and would like to > understand if there is consensus. I don't know about consensus, but we've not had a good spirited debate on big-i for oh, maybe a week, and things were getting a bit dull so perhaps this will spice things up a bit... -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 04:54:18 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01550; Thu, 30 Jun 1994 04: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 EAA22422; Thu, 30 Jun 1994 04:54:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA22400; Thu, 30 Jun 1994 04:37:41 +1000 Precedence: list Received: from dns2.anl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00826; Thu, 30 Jun 1994 04:37:37 +1000 (from b30118@benedick.ctd.anl.gov) Received: from benedick.ctd.anl.gov by anl.gov (4.1/SMI-4.1) id AA23159; Wed, 29 Jun 94 13:37:21 CDT Received: by benedick.ctd.anl.gov (931110.SGI/930416.SGI) for @anl.gov:big-internet@munnari.oz.au id AA05541; Wed, 29 Jun 94 13:37:20 -0500 Date: Wed, 29 Jun 94 13:37:20 -0500 Message-Id: <9406291837.AA05541@benedick.ctd.anl.gov> To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request From: "Richard Carlson" From- jnc@ginger.lcs.mit.edu (Noel Chiappa) >Yo! Wake up out there! If you *don't* reply, the IPng AD's are going to think >that *nobody* wants to separate end-end names (e.g. EID's) from toplogically >sensitive names (e.g. locators). I've said it before and I'll say it again. There _must_ be separate names to identify the system (EID, TA, TLN, ...) and path to that system (IP, IPng address). In any system there are design tradeoffs. With a single name, the designer needs to strike a balance between identification and location. This compromise can lead to future problems (i.e. IPv4 to IPng transition). Separate names allow the designer to tailor each name for a specific purpose. The 'price' of linking these two names together is, in my mind, outwayed by the benefits increased flexibility. As an example, the advantage of using ARP to map IP addreses to MAC addreses greatly outways the 'cost' of creating static maping tables. I feel that simular benefits will be found when end names (TCP EIDs) and location names (IP addresses) are separated. Richard A Carlson email: RACarlson@anl.gov Computer Network Section X.400: /s=RACarlson/prmd=anl/admd=/c=us/ Argonne National Laboratory (708) 252-7289 9700 Cass Ave. S. Argonne, IL 60439 From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 04:56:29 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01572; Thu, 30 Jun 1994 04:56: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 EAA22448; Thu, 30 Jun 1994 04:56:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id EAA22406; Thu, 30 Jun 1994 04:38:04 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00430; Thu, 30 Jun 1994 04:29:35 +1000 (from kasten@mailserv-D.ftp.com) Received: from [128.127.2.122] by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA27293 Thu, 30 Jun 1994 04:06:36 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Wed, 29 Jun 1994 14:03:59 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Wed, 29 Jun 1994 14:03:59 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA02657; Wed, 29 Jun 94 14:02:03 EDT Date: Wed, 29 Jun 94 14:02:03 EDT Message-Id: <9406291802.AA02657@mailserv-D.ftp.com> To: mankin@cmf.nrl.navy.mil, sob@harvard.edu Subject: Re: IPng ADs request From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU Content-Length: 2564 Scott and Allison: I strongly favor having two names; transport-level-names and network-level-names. Doing this will allow us to continue the split between network-layer and transport-layer functions that began over a decade ago when a very bright person suggested splitting NCP into TCP and IP. The Transport-level name is something that is under the control of the transport level. It is used to uniquely and globally identify an end of a transport-level association (I hesitate to use the work connection since these names would be used for both connection-ful and connection-less transports). These names - Have no network-topological significance, - May have administrative structure to ease and distribute the task of allocating them to individual nodes, - Are shortish (8 or maybe 16 bytes) and fixed length, - May be assigned to anything in the network which may be the target of some communication - they could be individual nodes, processes (making it simple to do mobile processes), maybe people, and so on, The Network-level name is used by the routing and forwarding systems. These names: - Have topological significance. They are used to indicate where in the network a particular node (actually, a transport-level name) is. - Are used by the routing system to develop a database (aka the routing tables) which reflects the network structure and which can be used to quickly and efficiently dispatch a packet. - Are used by the routing system to deduce and identify topological boundaries so that routing aggregation can be performed -- this is vital in order to reduce the routing information load that is being placed on routers. - Are hierarchically structured in order to allow distributed and decentralized administration of the space, and to allow the network to be broken up into clusters which share common attributes (connectivity, transit policies, and so on). - Are used as 'keys' into the routing database by the forwarding system in order locate the information needed to forward a packet. - These names may be longish (perhaps up to 24 or 32 bytes). They are probably varying in length, though perhaps in 'nice' quanta of 4 or 8 bytes, or 36 bits. - Are most likely 'highly auto-configured' -- prefixes would be advertised onto a network and the individual nodes on the network would pick up that advertisement, combine it with a locally significant number, and create their own network-level-name. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 05:34:24 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03444; Thu, 30 Jun 1994 05:34: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 FAA22497; Thu, 30 Jun 1994 05:34:10 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA22494; Thu, 30 Jun 1994 05:26:24 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03007; Thu, 30 Jun 1994 05:26:20 +1000 (from yakov@watson.ibm.com) Message-Id: <9406291926.3007@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1477; Wed, 29 Jun 94 15:26:19 EDT Date: Wed, 29 Jun 94 15:25:42 EDT To: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU Subject: assignment efficiency Ref: Your note of Tue, 21 Jun 94 16:46:22 -0400 Noel, >CIDR was introduced *precisely* because the 3+ (net, subnet(s), host) >we had weren't enough. I'm not sure how many layers various parts of the >network are using now that CIDR has been deployed (you can' tell just from >looking at an address), but I wouldn't be surprised if parts are now using >5. In addition to (net, subnet(s), host), we have today 2 more levels -- (provider, site). So, the total number of levels in the routing hierarchy used *today* is 5 -- you are correct. Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 07:59:51 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03527; Thu, 30 Jun 1994 05:39:27 +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 AA28565 Thu, 30 Jun 1994 05:39:24 +1000 (from owner-Big-Internet@munnari.OZ.AU) Received: from mailing-list by murtoa.cs.mu.OZ.AU (8.6.9/1.0) id FAA22512; Thu, 30 Jun 1994 05:36:42 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id FAA22480; Thu, 30 Jun 1994 05:21:49 +1000 Precedence: list From: yakov@watson.ibm.com Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02832; Thu, 30 Jun 1994 05:21:32 +1000 (from yakov@watson.ibm.com) Message-Id: <9406291921.2832@munnari.oz.au> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1367; Wed, 29 Jun 94 15:21:28 EDT Date: Wed, 29 Jun 94 15:19:41 EDT To: jnc@ginger.lcs.mit.edu, Christian.Huitema@sophia.inria.fr, big-internet@munnari.OZ.AU Subject: Assignment Efficiency Ref: Your note of Tue, 21 Jun 94 15:10:50 -0400 Noel, > From: Christian Huitema > > By the way, the SIPP loose "source route" are precisely there to > provide an escape and a path of evolution. We may not know the details > yet, but all works on flexible routing (nimrod, sdrp, idpr, route > segments) points towards this type of solution. > >I can't speak for the other designs, but the SIPP "source route" probably >won't be very useful to Nimrod. To see whether the SIPP "source route" would be useful for another routing architecture, namely Unified, I appended the list of requirements taken from draft-estrin-ipng-unified-routing-00.txt: IPng should provide a source routing mechanism with the following capabilities (i.e. flexibility): - Specification of either individual routers or collections of routers as the entities in the source route. - The option to indicate that two consecutive entities in a source route must share a common subnet in order for the source route to be valid. - Specification of the default behavior when the route to the next entry in the source route is unavailable: - The packet is discarded, or - The source route is ignored and the packet is forwarded based only on the destination address (and the packet header will indicate this action). - A mechanism to verify the feasibility of a source route. Comparing these requirements against SIPP capabilities makes me to believe that the SIPP "source route" wouldn't be very useful to Unified as well -- SIPP meets only one of the listed requirements. Yakov. From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 08:18:53 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06564; Thu, 30 Jun 1994 06:54: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 GAA22591; Thu, 30 Jun 1994 06:54:11 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id GAA22588; Thu, 30 Jun 1994 06:47:57 +1000 Precedence: list Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06183; Thu, 30 Jun 1994 06:47:49 +1000 (from kre@munnari.OZ.AU) Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.83--+1.3.1+0.50); id AA29336 Thu, 30 Jun 1994 06:37:36 +1000 (from kre@munnari.OZ.AU) To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request In-Reply-To: Your message of "Wed, 29 Jun 1994 08:26:19 PDT." <199406291526.AA24425@zephyr.isi.edu> Date: Thu, 30 Jun 1994 06:36:18 +1000 Message-Id: <25369.772922178@munnari.OZ.AU> From: Robert Elz I thought this question had an answer that was pretty well known, plenty of people believe each way, I doubt asking it again is going to change that much. I favour separating the functions of identification, and location, into two separate numbers, whether the location includes the identification as a trailing component or not I doubt is terribly important to anything. Rather than say (yet again) why identifiers are a good idea, in addition to locators, I want to make one corremt wrt a question Paul asked, and then make a few comments about some of the objections that others have made. Date: Wed, 29 Jun 94 08:26:19 PDT From: Paul Mockapetris Message-ID: <199406291526.AA24425@zephyr.isi.edu> Similarly, why not push this problem into a higher level protocol. Mainly because none of this is really a function of any protocol, its a matter of identification, which transcends all protocols - the identifier would be used everywhere identification of the node (whatever - come to that later) is needed - including in things like MIBs - its not just a matter of identifying TCP connections, though as they also need identifying the identifier is also the right thing to use. Now to some objections ... One has been that EIDS (which I have been trying not to use, but never mind) are still an unknown quantity, still a research issue, and its too early to include them yet. This is really pretty silly, we have been using identifiers (albeit bundled with the locator) in IP forever, there's nothing new about this function, nothing that needs lots of work or heavy contemplation - its just an identifier. Its certainly true that there are lots of potential uses for EIDs that do still need research, that's nice, it indicates that EIDs do have more new roles that probably aren't all known yet - that's a reason for including them, not for excluding them. If a potential use for something that still needed research meant that we should wait with the thing to see if any changes may be needed, then we wouldn't have IPv4 yet, as IP (v4, ng, whatever) still has lots of potential uses we haven't found yet, with lots more research needed. Next objection - how are EIDs assigned? This is easy, they're assigned just the same way as IPv4 addresses are, but with less structure and in smaller lumps (to aboid fragmentation losses). As there are no topological relevances at all, doing the assignments is much easier for everyone - you always assign the next number in your block without regard for any other influencees (as there are none). My plan would be that the IANA has a 64 bit space to assign, it assigns that in groups of 2^32 bits to major NICs - so it has 2^32 blocks to assign, which it assigns 1, 2, 3, 4, ..., in order as those NICs ask for blocks. "Major" NICs are those that handle handle continents, large countries, etc. The major NICs then hand out blocks or 2^16 or 2^24 size to the providers in their area (which basically means anyone who asks that NIC - most likely anyone in roughly the same timezone). Smallish blocks (2^16 EIDs) would be assigned to small providers, large blocks (2^24) to larger ones - the NICs itself decide what is appropriate. The providers then hand out blocks of 2^8 (256) EIDs to end user organisations as requested (obviously assigning more than one group if an organisation has an immediate need for more than 256 - but not assigning space for "future growth", when more numbers are needed, they're assigned when they are actually needed). This basically prevents (as much as possible) fragmentation of the number space. We can talk about whether I have the block sizes exactly right, but the idea will work fine. Note that there are absolutely no manufacturer assigned parts in the EID, most definitely no IEEE (48 bit) numbers in there anywhere. They waste far too much space, and cause too many complications. I would start the allocation by allocating the top 32 bits of all zeroes to contain the entire IPv4 address space, so all currently allocated IPv4 numbers are EIDs automatically. They would lose all other IPv4 semantics when used in this way of course - this is purely to avoid a huge startup hump of people needing to apply for EIDs in a big rush at the start. Craig asked about EIDs for broadcast & multicast - I'd simply ban broadcast in IPng, its never the right mechanism for anything, which leaves just multicast. For that I'd reserve the top 32 bits of all 1's, giving 2^32 multicast identifiers. If that doesn't look like enough, we could make it 2^40, which I'm sure would be plenty. I believe that Christian suggested that this was a TCP function, and should wait for a revision of TCP. As I said above EIDs aren't really a transport function, transport is just one user of them - but even if they were, TCP isn't the only transport protocol, defining identifiers afresh for every transport protocol would be a needless waste of effort, and cause endless confusion. Further, even if TCP were to be the only user of EIDs, there is no immediate prospect, or need, of a new TCP any time soon - if there was we should be doing it right now so it could be deployed at the same time as IPng, and so avoid having to do 2 upgrades. "Leave it till the next TCP" is essentially "Forget it forever" in current circumstances. I should also say here that the proposed "transport connection identifier" label is absolutely wrong - the EID (will) form part of transport connection ID's, along with the port number, but by itself doesn't identify transport anythings. The EID, as a globally unique number, can also be used to make unique transaction numbers by appending a locally unique transaction id's (however big they need to be for the protocol in question) which avoids having to work out yet another way to get globally unique numbers (one good way is enough). Next objection - how do we guarantee that the EID is globally unique? Basically the same way we guarantee IPv4 is globally unique - in general we don't, only parties that need to communicate really care (that set need to have unique numbers - this means the entire internet, but doesn't require anything of other users, who can use internet unique numbers but on't have to). On the internet, the directory (DNS) assigns the numbers - as each delegation of a block is done, its simultaneously entered in the directory. That can be made to check there is no more than one delegation, as its built as a tree, there's only ever a need to check the sub-identifiers at the same level. This stuff is all easy. EIDs on the internet that are not in the directory are not assigned and are invalid - this is easy to check when needed. Next objection - "security" - with EIDs doing the identification we are going to need some kind of authentication protocol, as we can no longer rely on the "if the packet gets back to him it must have been him who sent it" that works with IPv4 (or kind of works well enough for most purposes). This is absolutely right - but we know we need authentication anyway, this is nothing new. However, for immediate use we lose nothing if we couple the EID and the locator for identification purposes - simply check that the locator we are receiving is that which we are expecting, this brings us back to IPv4 level security until we get some real security deployed. It does mean that some of the (hoped for) advantages of EIDs wrt mobility may not be achievable until security appears, but I would expect that mobility is going to need some kind of real authentication in any case. Final objection (that I will answer here anyway) - we don't know EIDs are useful for anything in particular, so eliminate them and simplify things. As with everthing, its a trade off, simplify the packet formats perhaps - complicate the address that's left by making it fill both roles - the locator function will need to be compromised a little in order to make the address (which is an identifier and locator) be also able to identify things - its syntax has to be amenable to serving as a DNS key, which limits its flexibility. For me this "simplicity of function of the address functions" is the basic reason for wanting EIDs, the two functions that addresses currently handle are clearly two independant roles. They ought to be handled by separate identifiers. Other reasons are that they will (eventually) permit locators to be altered without upsetting identification functions (like that which has to go in the MIB). They will also permit transparent gatewaying between different network level protocols - provided only that they maintain the EID. This will both permit exprimentation with new IPngng's, and allow graceful transitions as we need to switch network level protocols in the future. Further, use of an EID that can be built out of an IPv4 address, padded with zeroes, along with the TCP checksum algorithm, in which zeroes are meaningless, may just have some application in allowing on the fly conversion from IPv4 to IPng, as the TCP checksum wouldn't need to be altered, and its possible that even encrytpted TCP could be carried from an IPv4 to an IPng node safely (this is perhaps a pipe dream). kre From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 08:57:48 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09634; Thu, 30 Jun 1994 08: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 IAA22694; Thu, 30 Jun 1994 08:34:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA22680; Thu, 30 Jun 1994 08:19:42 +1000 Precedence: list Received: from wilbur.nas.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09201; Thu, 30 Jun 1994 08:19:39 +1000 (from lekash@nas.nasa.gov) Received: (from lekash@localhost) by wilbur.nas.nasa.gov (8.6.8.1/NAS.5.b) id PAA08349; Wed, 29 Jun 1994 15:19:36 -0700 Date: Wed, 29 Jun 1994 15:19:36 -0700 From: lekash@nas.nasa.gov (John Lekashman) Message-Id: <199406292219.PAA08349@wilbur.nas.nasa.gov> To: mankin@cmf.nrl.navy.mil, sob@harvard.edu, big-internet@munnari.OZ.AU Subject: IPng ADs request From- jnc@ginger.lcs.mit.edu (Noel Chiappa) >Yo! Wake up out there! If you *don't* reply, the IPng AD's are going to think >that *nobody* wants to separate end-end names (e.g. EID's) from toplogically >sensitive names (e.g. locators). Hi there. Noel was whining (see above) that no one was stating we wanted/needed separate EIDs from locators. Ok, I want them. The current address overload in IP makes various things involving multihomed hosts, data striping, re-routing around broken interfaces, annoying to deal with. Separating these seems to be a good avenue to help me with these problems. Right now, we do various random kludges in the OS (usually in device drivers) to deal with it. Being lazy, I'd prefer to not have to do so anymore. john From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 08:59:18 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09736; Thu, 30 Jun 1994 08:39:50 +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 AA01417 Thu, 30 Jun 1994 08:38: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 IAA22709; Thu, 30 Jun 1994 08:35:53 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id IAA22677; Thu, 30 Jun 1994 08:17:13 +1000 Precedence: list Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07272; Thu, 30 Jun 1994 07:30:42 +1000 (from ihanson@pcs.dec.com) Received: from cssec4.pcs.dec.com by inet-gw-1.pa.dec.com (5.65/27May94) id AA26255; Wed, 29 Jun 94 14:21:24 -0700 Received: by cssec4.pcs.dec.com (5.57/jmh-inet-gw-v1.05); id AA22675; Wed, 29 Jun 94 23:21:10 +0200 Message-Id: <9406292121.AA22675@cssec4.pcs.dec.com> To: sob@hsdndev.harvard.edu (Scott Bradner) Cc: big-internet@munnari.OZ.AU, ihanson@cssec4.pcs.dec.com Subject: Re: IPng ADs request In-Reply-To: Scott Bradner's message of "Sun, 26 Jun 94 08:03:16 EDT." <9406261203.AA10683@hsdndev.harvard.edu> Date: Wed, 29 Jun 94 23:21:09 +0200 From: "Iain K. Hanson" X-Mts: smtp Hi, My appologies in advance if any of this is a little naive, but I am more familar with using protocols than designing them. Scott Bradner wrote: > One thing that seems to have been missing in the recent extensive >discussions about address size options is a understanding of >whether the transport level 'name' should be the same as the internetwork >level 'name', as they are with the current IPv4 "address", or be different >in some way. > > In IPv4 the transport name is: > > The question referrs to the two IP address fields. As far as I can recall, there has been virtually no discussion of TLN's other than whether an EID is a TLN or not. >1/ are the transport and internetwork level names the same thing? I don't beleive so. As I understand it, a transport level name should be relative to the internetwork level name(s) and identifies an end-point ( process, application, etc ) that is uniquely addressed by the combination. However, I see no need for the TLN itself, to be globally unique. Is an EID a TLN? I don't think so. I know that there appear to be a number of views on what such a beast is, but as I see it, based on the discussions on this list, it has the following ( possibly conflicting ) properties: It identifies N internetwork level interfaces. Each EID is globally unique. There can be a number of EIDs with ?overlapping? groups of interfaces. There could be an EID at the top of this that owns all other EIDs and identifies the whole end-system ( host/box/whatever... ). Users wish to allocate EIDs themselves hierarchically, probably in a sparse tree with arbitary depth. EIDs can be auto-configured without a server ( or router ) for plug-and-play out of the box. Auto-configuration can be prevented by routers or servers if so required. EIDs when carried in packets should be as small as possible and the space that they occupy should be efficiently used. An EID has N Locators associated with it. And I think that it follows from the above, that a locator can have more than one EID!!! EIDs live as long as the Administrators chose and can be re-allocated or moved to suit their requirements. BTW something that several people can close to, and sounds reasonable to me ( but I not sure how practical it would be ) is that an EID should have two forms. One for the Administrators/users and one for the packet. I.e. the user would allocate a DNS name which would then be mapped to a more efficient form by a server. Most of these properties seem to me to indicate that an EID is an internetwork level name that has administrative, but *no* topological significance. Locators on the other hand seem to be internetwork level names with routing significance - althopugh whether they are geographically, provider, or topologically organised, is a yet unclear to me. Each physical interface has at least one locator. I presume that two physical interfaces could share a Locator ( for instance if they were both connected to the same piece of Ethernet ). >2/ if not, are they totally different or is the transport level name > part of the internetwork level name? I think that the internetwork level name is made up of an EID and Locator but the end point can only be idenified by the addition of a TLN. I.e. there can be many applications sharing a single EID, Locator pair. If I have got anything incorrect then please let me know. I currently feel a little confused about the whole issue :-(. /ikh From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 11:14:23 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16000; Thu, 30 Jun 1994 11:14: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 LAA22897; Thu, 30 Jun 1994 11:14:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA22894; Thu, 30 Jun 1994 11:12:55 +1000 Precedence: list Received: from saturn.csd.unb.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11889; Thu, 30 Jun 1994 09:34:44 +1000 (from bdk@saturn.csd.unb.ca) Received: by saturn.csd.unb.ca (AIX 3.2/UCB 5.64/4.03) id AA15680; Wed, 29 Jun 1994 20:28:45 -0300 Date: Wed, 29 Jun 1994 20:28:44 -0300 (ADT) From: Brian Kaye Subject: Re: IPng ADs request To: Noel Chiappa Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406290141.AA07568@ginger.lcs.mit.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 28 Jun 1994, Noel Chiappa wrote: > For those who don't understand the question, here's the reasoning in a > nutshell. For things like TCP, you want a "name" which stays the same no > matter where you go in the network, so you can tell the thing you're talking > to over here is the same thing you were talking to over there. However, the > routing requires a "name" which depends on where you are in the network, since > it uses that to get the data to you. You can't have one "name" which stays the > same wherever you are, and changes depending on where you are; ergo, you need > two "names". > > Noel As a recent "joiner" to this discussion, I have not followed what went on earlier in this thread. Are you basically saying you need one name to say "who" you are and another name to say "where" you are? ..... Brian Kaye ..... UNB From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 12:02:07 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16938; Thu, 30 Jun 1994 11:34: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 LAA22934; Thu, 30 Jun 1994 11:34:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA22924; Thu, 30 Jun 1994 11:28:45 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16621; Thu, 30 Jun 1994 11:28:38 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA11846; Wed, 29 Jun 94 19:28:08 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB04686; Wed, 29 Jun 94 18:24:26 PDT Date: Wed, 29 Jun 94 18:24:26 PDT Message-Id: <9406300124.AB04686@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: "Richard Carlson" From: Greg Minshall Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU Richard Carlson, >I've said it before and I'll say it again. There _must_ be separate names >to identify the system (EID, TA, TLN, ...) and path to that system (IP, IPng >address). Maybe you could define "must". To me, "must" says there is no other way. However, there clearly is an existence proof of another way - IPv4 addresses. Greg Minshall From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 12:03:10 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17005; Thu, 30 Jun 1994 11: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 LAA22949; Thu, 30 Jun 1994 11:35:54 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA22930; Thu, 30 Jun 1994 11:29:26 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16651; Thu, 30 Jun 1994 11:29:21 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA11856; Wed, 29 Jun 94 19:28:47 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB04686; Wed, 29 Jun 94 18:25:02 PDT Date: Wed, 29 Jun 94 18:25:02 PDT Message-Id: <9406300125.AB04686@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: jnc@ginger.lcs.mit.edu (Noel Chiappa) From: Greg Minshall Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU, pvm@ISI.EDU Noel, I haven't read the Nimrod mobility draft, but i will. In the meantime, i *do* have a question. >Well, the example I mentioned (host mobility) shows that the binding is not >terribly strong. I view the binding as being made at the time a DNS lookup >is done (multi-homed hosts would return multiple "routing names"), and it >can be changed thereafter in the case of mobile hosts (with that mechanism >being adequately secured to prevent denial-of-service or other attacks). One of the key things, imho, that makes DNS scale so well is the caching that DNS provides. Thus, there can be various replicas of one zone distributed widely, but they only have to "synchronize" when the minimum TTL on the data in the zone expires (approximately). In a scheme that stores *current location* information of a mobile host inside DNS, don't we either lose this caching (== scalability) principle or, alternatively, have to enforce some minimum time between moves ("don't touch that laptop!")? One of the advantages in a scheme like the current mobile-ip scheme is that DNS doesn't lose its caching property, but a "natural" second query is made to the (purported) home location of a mobile host (via the "first" packet of an internet interaction). This home location can keep up with those peksy mobile hosts, without perturbing the DNS. And, if "locality" holds in which mobile hosts are often located "close" to the home location (there is certainly room for doubt on this premise), this scheme actually wins (since if the mobile host is "close enough" to the home location, there wouldn't need to be *any* notification to the correspondent host). (I don't think the mobile-ip scheme is ideal; but i doubt that today we know what the "ideal" scheme would be, though it seems likely to involve solutions at different levels - of the hierarchy as well as the stack.) Greg From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 12:03:27 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15288; Thu, 30 Jun 1994 10:54: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 KAA22856; Thu, 30 Jun 1994 10:54:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id KAA22853; Thu, 30 Jun 1994 10:49:26 +1000 Precedence: list Received: from rodan.UU.NET by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07941; Thu, 30 Jun 1994 07:49:06 +1000 (from mo@uunet.uu.net) Received: by rodan.UU.NET (maildrop) id QQwwlb06013; Wed, 29 Jun 1994 17:48:59 -0400 Message-Id: To: big-internet@munnari.OZ.AU Subject: Save the skeets - transport names and mobile Date: Wed, 29 Jun 1994 17:48:58 -0400 From: "Mike O'Dell" With all due deference to our august Mobile IP folks who are working very hard to make mobility work within the straightjacket of the current IPv4 architecture, there are some fundamental problems which must be addressed, one way or another, for mobility to really work well You (I) don't want connections to fail when the mobile unit moves between coverage areas of providers (so-called inter-system mobility, as opposed to intra-system mobility which may be dealt with by some amazingly clever switching fabric withing a mobile coverage system). This means that whatever we call the bits that get put into the TCP and UDP (and whatever else comes along) upper level protocol state records (Transport Name??) CANNOT change during that transion, at least without dramatically changing the Buddah-nature of the upper level protocols, and that is completely out of scope. Changing that information breaks the connection, so there must be SOME piece of identifier bits which are INVARIANT of the network attachment topology which can get used for the purpose of identifying the endpoint. Now the question is "are these INVARIANT bits part of the 16 bytes or not?" It depends. If you want to burden all mobile traffic with additional source-routing headers (and all the additional authentication freight tha implies, by the way), then you don't need to do anything special with the 16 bytes and just point at "a free additional routing header in every box of New and Improved Mobility." However, if you believe that low-to-moderate bandwidth mobility is one of the largest currently-unexploited markets that IPng could help realize, then maybe you don't want one of the largest potential sources of new traffic to *require* carrying extra source-routes to work. Further, where is the source-routing stuff gonna get stored in hosts?? In local routing tables? Then we gotta think carefully about how existing source-routes get superceded by new source routes from arriving traffic indicating the station has moved. more troubling is the rich potential for denial of service attacks this brings up. Just the thing to convince a new market to use our shiny new technology. Therefore, I believe having the INVARIANT part be some subset of the 16-byte address is a good tradeoff. Mobile traffic doesn't extract extra work for routes to do fast source-routing, and it mitigates the security problems introduced by source routes (discussed so eloquently by Steve Bellovin). That's why I originally proposed 8+8, or maybe 10+6. Also, to revisit the "unique identifier" red-herring, doing a globally-unique ANYTHING is one of the hardest things there is to do in the world. it is a trivial mathematical concept, but when it must be realized in the physical world, ANY scheme designed to provide it will fail with some probablity. The question then becomes "how robust is the design in the face of occassional failures?" I assert that the amount of grief in the world caused by lapses in the IEEE MAC assignment process is microscopic in the extreme, compared to the network problems caused by using a worn or cheezy crimp-tool when making a 10-base-T cable. Let's not even bring up the story of how a fat-net problem at Bellcore caused 9 months of hell until it was discovered that when an "N" connector was installed on a piece of yellow coax, the center conductor was nipped 1/64" too short, thereby causing a thermal intermittent as the building expansion stretched the cable, causing the center conductor contact to become marginal. So in my experience, I'd rather outlaw N connectors than worry about duplicate ethernet address assignments - hell, a PROGRAM can identify that, and quickly, on a network. SO what's the point??? Well, a lot of this discussion has proceeded as if all events are of equally probability and represent the same cost to address. They are not. Further, it is impossible to create an assignment mechanism of any kind which will not fail, but that's not so bad because it isn't a horrible problem when it happens, and it doesn't happen very often at all. This leads me to assert that you can assign a 6-byte MAC field quite densely and have more than enough endpoint computing/communications objects for everyone on the planet many times over. (and no, I'm not worried about light-switches and doorknobs having IPng addresses - I've explained why that won't happen already). This then leaves 10 bytes of routing/bureaucracy/political-entity-ameliorization, which really ought to be enough to build anything. Saying "no it isn't" is essentially claiming that whatever network you have in mind cannot be represented as an embedding in a hypercube with a staggering number of dimensions. again, the global Internet isn't that complex, and will never be, because we cannot manage it if it comes within lightyears of that complexity. So enough of my soapbox. Scott and Allison wanted comments to Big-I, so here they are. Mike O'Dell Resident Crank From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 12:03:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17020; Thu, 30 Jun 1994 11:37: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 LAA22964; Thu, 30 Jun 1994 11:36:51 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA22927; Thu, 30 Jun 1994 11:28:53 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16629; Thu, 30 Jun 1994 11:28:43 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA11849; Wed, 29 Jun 94 19:28:22 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB04686; Wed, 29 Jun 94 18:24:39 PDT Date: Wed, 29 Jun 94 18:24:39 PDT Message-Id: <9406300124.AB04686@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Masataka Ohta From: Greg Minshall Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU Masataka, I *very much* want to have locators separate from EIDs. But, i'm not convinced that right now we know how to do this in a way that would make it work. >I want to have locators and EID as separate concept because: > > EID should follow administration hierarchy. > > EID should not be forced to follow geographical hierarchy. > > Locators should not be forced to follow administration hierarchy, > which enables us to have only 2 or 3 layers for routing. > > Locators should follow geographical hierarchy. WHAT IS AN EID USED FOR? An IPv4 address, for example, identifies a node in the topology. Since it identifies a node in the topology, it is a good candidate for identifying the endpoint of a connection, transport say, as well as for verifying that the incoming packet did, indeed, come from the endpoint. Also, an IPv4 address is assigned in a hierarchical (more or less...) fashion. Since it is assigned in a hierarchical fashion, it is a good candidate for looking up a host name from the contents of a datagram (gethostbyaddr()). What are the uses of an EID? WHAT ARE THE CONSEQUENCES OF A DUPLICATE EID? If two nodes are using the same IPv4 address, for example, and they are both on the same wire, they, and the hosts with which they are communicating will see anomalous behaviour. If the two nodes are on different wires then most likely one node will be non-functional. If an EID is duplicated, it is not clear to me the consequences, nor how "local" the effects are likely to be. WHO CAN "FIX" DUPLICATE EIDS? If two nodes are using the same IPv4 address, for example, and they are on the same wire, there is likely an administrator in common (or, two administrators "closely related") who can fix the problem (assuming they can detect the problem rather than just the non-deterministic symptoms!). In "flat" EID schemes (IEEE 802 addresses, say), there is "no one" to say to one of the duplicate nodes "you must change". In hierarchical schemes, there *IS* someone who can say this, but it isn't clear (to me) how that someone will enforce this edict. The very *topology insensitivity* of EIDs, which is so attractive to us all, is one of the key features that makes them potentially difficult to monitor and manage. In IPv4, there is an entire routing system(*) which helps enforce the uniqueness of IPv4 addresses (outside of a local "fate sharing" domain). The primary goal of this routing system is *probably* to make routing "work". But, a very nice side effect of this is helping enforcing the uniqueness (again, outside of a local "fate sharing" domain) of IPv4 EIDs (i.e., IPv4 addresses). I don't know how to build such a system for "EIDs" which are not, in effect, addresses. Greg (*) developed over many years... From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 12:04:25 1994 Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17851; Thu, 30 Jun 1994 11:57:06 +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 AA07525 Thu, 30 Jun 1994 11:57: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 LAA23014; Thu, 30 Jun 1994 11:54:15 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA23008; Thu, 30 Jun 1994 11:41:35 +1000 Precedence: list Received: from databus.databus.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16384; Thu, 30 Jun 1994 11:22:03 +1000 (from barney@databus.databus.com) Date: Wed, 29 Jun 94 21:21 EDT Message-Id: <9406292122.AA05578@databus.databus.com> From: Barney Wolff To: big-internet@munnari.OZ.AU Subject: Re: IPng ADs request Content-Length: 1981 Content-Type: text > Date: Wed, 29 Jun 94 14:02:07 EDT > From: kasten@ftp.com (Frank Kastenholz) > > As to disk drives, presumably you backup your system? Either this > change was unexpected, in which case you have to restore the system > from backup (in which case, the backup has all the names assigned to > the machine) or re-install the software, in which case you have a > whole lot of stuff to rebuild and transport-level-names are only a > small, minor, headache. Or the change was expected, in which case, > you restore the information from the backup made before the change. I took the question to mean: Suppose you swap the hard disk from one configured system into another, without changing anything on it? Today, the system will come up with the hostname and IPv4 address configured on the disk, but with the ethernet address from the adapter (assuming no bootp). In IPng, is the EID bound to the disk or to the chassis the disk sits in and/or the adapter? > The binding (or re-binding) between transport- and network-level > names is a key to this whole thing. By being able to dynamically > change the binding we'll be able to support mobility of anything that > can be named. > > > Similarly, why not push this problem into a higher level protocol. > > To a certain degree, having two names (transport- and network- level) > _is_ pushing some problems to a higher level. It removes an > interdependancy between the two. Now, issues that are somewhat more > the transport-level's business instead of the network-level's > business can be dealt with solely at the transport level... Each > would have its own name space to be structured and used as best fits > the needs of that level. Now I'm really confused. I took the question to mean: Is the (eg) TCP name = EID + port, or +port? But Noel clearly took it to mean is the EID = Locator? I vote for TCPname = EID+port and EID != Locator (and not a subset either). Barney Wolff From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 12:04:59 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17850; Thu, 30 Jun 1994 11:57: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 LAA23040; Thu, 30 Jun 1994 11:55:29 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id LAA23011; Thu, 30 Jun 1994 11:46:10 +1000 Precedence: list Received: from access1.digex.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14023; Thu, 30 Jun 1994 10:25:47 +1000 (from tdarcos@access.digex.net) Received: by access1.digex.net id AA28032 (5.67b8/IDA-1.5 for On the Growth of the Internet ); Wed, 29 Jun 1994 20:25:31 -0400 Newsgroups: tdr.paul.private.mail Date: Wed, 29 Jun 1994 20:25:30 -0400 (EDT) From: Paul Robinson Sender: Paul Robinson Reply-To: Paul Robinson Subject: In the matter of 64-bit addresses To: On the Growth of the Internet , IETF List , Namedroppers Message-Id: <01.1994Jun29.17h27m45s.PAUL-0100000@TDR.COM> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII From: Paul Robinson Organization: Tansin A. Darcos & Company, Silver Spring, MD USA ----- For those of you who might have already thought of this, please excuse my ignorance and tell me why this doesn't seem to be a good idea for the "new" version of IP to come along. It seems too simple and yet it seems like it might work. I am not sure whether the plans are for 64-bit or 128-bit addresses. I think that 64-bits are enough if the system is set up to allow for expansion by correctly scaling the system. I also think we can simplify some of the routings currently in use. This scheme I am proposing seems so simple that I suspect either someone already proposed it or I'm missing something that makes it impractical. Let's take the first 4 bits of the address. Drop 0 and 15 because those are to be used for other purposes, e.g. local and broadcast. Drop 13 for future expansion. Use 14 to indicate the network is mobile. Take the other numbers, 1 through 12, and divide up the world into 12 portions, as follows in this example (this is a rough cut from my world atlas and is not as precise as it would otherwise be if I was cutting by major population zones.) 1. Europe SW (UK, Ireland, France, Spain, Belgium) 2. Europe SC (Luxembourg, Switzerland, Germany) 3. Europe N (Netherlands, Denmark, Sweden) 4. Europe SE (Poland, Hungary, Austria, Latvia, Bulgaria, Former Czech, Yugoslavia) 5. Asia N (Russia, Turkmenistan, Mongolia) 6. Asia SW (Afghanistan, Pakistan, India, Myanmar, PR China) 7. Asia E (Japan, Hong Kong, Taiwan, Macao, Kampuchea, Thailand, Vietnam) 8. Australia (Singapore, Malaysia, FS Micronesia, Marshall Islands, Borneo, New Guinea, Australia, New Zealand, Antartica and everything at or south of 60 degrees S. Latitude) 9. Middle East (Turkey, Iran, Iraq, Saudi Arabia, Oman, Israel, Jordan) 10. Africa (Africa, Madagascar; all islands at or W of 60 E lat or E of 30 W lat and N of 60 deg S lat and at or south of the equator; all islands at or S of 30 N latitude to N of 60 S lat. which are at or E of 30 deg W and N of 60 deg S) 11. North America (US, Canada, Greenland, Iceland, Mexico, Cuba, Puerto Rico, Virg. Islands, plus all islands E of 180 deg. W Latitude (our side of date line) or west of 30 deg W. Latitude, and at or North of 15 deg N Latitude.) 12. South America (Everything south of Mexico; all islands at or E of 180 Deg. W Lat. or W of 30 deg W Lat. and S. of 15 deg. N lat. and N. of 60 deg. S. Latitude) If I was trying to make the areas so that areas of high connectivity are small and areas expecting little connectivity are large, I'd probably make some areas slightly different inclusions according to network tables of connectivity so that I mix some light areas in with heavy users, e.g. perhaps Mongolia goes with Japan. As this shows, it's an attempt to roughly group portions according to density, e.g. all of Africa is less dense than, say, Japan in terms of IP connectivity which can be expected in the next 20-100 years. Each of these 12 portions is further subdivided into 14 sections (or 254, see below) according to the potential for population growth in IP connectivity, with 0 and 15 (or 0 and 255) not being used. Each section is further divided into 254 (or 14) areas (0 and 255 (or 0 and 14) not used). Using 16 (or 12) bits we have identified an area to a precise portion of the earth, section of that portion, and area in that section. If we take North America, portion 11, we might have the following sections: 1. Alaska and Canada at or W of 120 W Latitude. 2. Canada E of 120 W lat and at or W of 90 W lat. 3. Canada E of 90 W lat and at or W of 75 W lat. 4. All points in N. America N of 45 N lat and E of 75 W lat. 5. All points in N. America W of Easternmost land point of the Baja Peninsula which are below the Canadian Border. (W. Coast) 6. All parts of Mexico not in 5. 7. All parts of USA not in 5 which are at or W of 105 W lat. 8. All parts of USA which are E of 105 and at or W of 110 W lat. 9. All parts of USA E of 100 W Lat and at or W of the easternmost point of the shore of lake Michigan. 10. All parts of USA E of 9 and W of the Westernmost point of Canada reaching the Detroit area. 11. All parts of USA E of 10 which are at or W of 75 W latitude. 12. All parts of USA E of 75 W lat. 13. North America portions not identified. (For sites preferring not to give precise address). I live in silver Spring, MD which puts me in section 11. That area, which includes Philadelphia, Florida, S. Carolina, Washington DC and Baltimore. This section is then divided into 254 areas, with large cities being in separate areas while (much larger) rural areas would surround them. We take every city in this area over, say, 100,000 people and define a space amounting to perhaps 10 miles from the center and call that an area. Cities with over 250,000 people might get 2 or more areas. In Section 12, for example, New York City, or Los Angeles in Section 5, each have about 7 million people. Each one might get perhaps 10 area assignments or be placed in its own "zone" as stated below. One way to divide up each section is to partition the areas into perhaps 14 zones, then assigning the major area to number 1 in that zone, and then each major city to its own area. A zone's boundary could then be adjusted to push some large cities into their own zone. This is just for administrative convenience, areas could simply be sequentially assigned as needed and thus a section might use zones 1 through 25, while another might use 1 through 10, 22, 34, 66 and 80-83. Now, in 16 bits, we can define where a particular site is down to aproximately the size of a town or province. And the nice thing about it is that it can be scaled into a small package. By having each major area be defined to 4 bits ("a quad"), all we have to know is where to send whatever is defined with the 4 bits we are looking at. Or we can use 8 bits and define a good-sized chunk of the world to aim for. All we have to know is how to reach that 1/256th of the world (minus the reserved 2 fields of 0 and 15 in each 4 bits). If the IP is to have 64 bits, then bits 20-24 can define the size of the network address in quads, from 1 to 11. If the number is 8, then the next 24 bits represent the network in this area. This uses 48 bits, leaving 12 bits for the local device in that network. The identifier looks like this: (4+4) xxxx xxxx | xxxxxxxx | xxxx xxxx | xxxxxxxx xxxxxxxx xxxxxxxx World local Net xxxxxxxx xxxxxxxx Por- Sec- area Addr tion tion Size Network and local address We could also have: (4+8) xxxx xxxx| xxxx xxxx In this example, each portion of the World Local world is divided into 256 sections, Por- Section Area and each section has up to 16 areas. tion In either case, the last 44 bits are used for net size, network number and local address. In both of the above cases, 16 bits uniquely identifies where a network is located and only 12 of them are needed to cover a large portion of the world. This seems so simple that I can't figure out what's wrong with it; I would have suspected someone else would have thought of this. The thing about it is that things scale as needed; where you need a large local address, they just change the 'net addr size' and (if it's not in use) the portion of your address that was part local address becomes available for you to reuse as local addresses. And so on through a 40 bit network and 4 bit local, giving 200+ billion networks in an "area". By this scheme, each "area", you can have half a million of the equivalent of a current class A address. An "area" might be as large as 1/2 of Wyoming to as small as 2 blocks in downtown Manhattan. For example, if I have (under 4+4 addressing) the assignment 11 11 | 24 | 6 | 238.147.240. | 1.1.1 through 14.254.254 Then if I need more space, they could assign me 11 11 | 24 | 5 | 238.147.14 | 1.1.1 through 254.254.254 For the sake of this argument, it could be assumed that 11.11.24 is the routing code for Silver Spring, MD. If 4+8 is used, it might be 11.935.3 or something else; we might go with octal. For each local area, this allows a total of 14 40-bit addresses (1 quad/4 bit net; 40 bit local) address. 196 36-bit (2 quad/8 net; 36 local) address 2744 32-bit (3 quad/12 net; 32 local) addresses 38416 28-bit (4 quad/16 net; 28 local) addresses 537824 24-bit (5 quad/20 net; 24 local) addresses ("A") 7529536 20-bit (6 quad/24 net; 20 local) addresses 105413504 16-bit (28 net; 16 local) addresses ("B") And so on through a 40 bit network and 4 bit local, giving 200+ billion 4-bit networks in an "area". By this scheme, each "area", you can have half a million of the equivalent of a current class A address. An "area" might be as large as 1/2 of Wyoming to as small as 2 blocks in downtown Manhattan. Given the size of each "portion" of the earth, each portion would probably be better divided into 256 sections, and then each section have from 1 to 14 areas. This will even scale to supporting the (in)famous 'toasternet' where even every appliance and light socket in one's house gets an IP number. And the thing about this is that it gives us room to provide other features. For example, net address sizes of 12, 13 and 14 can be used for something else, giving 3 48-bit addresses for various things. Am I making a mistake here? This seems to indicate that 64-bit IP addressing can be scaled to the point that it will handle anything we want to throw at it for years and still provide plenty of room, and yet allow for scaling the routing down to a mere 256 major places. (Or change the section group to divide each portion into 256 sections, then each section into 16 areas, then the routers can hold routing into the 1024 sections of the earth, many of which won't be used for a while.) This means the routing tables only have to know how to find out which of a mere 1024 points (if we use a 4+8 routing of the first 12 bits) the particular address is located at. It might even indicate that we can, with some adjustments, scale the address portion to 48 or 56 bits and thus not have to make the address so large. (But using 64 bits makes it fit easy into 8 bytes and is probably less trouble for computers to use.) Thus any way I look at it, 64 bits should be able to handle anything we might throw at it over several years since if an area gets to large it can be split and new customers moved into a new area. This seems to indicate that 64 bits should be enough to handle anything we can throw at it for any conceivable time frame. --- Paul Robinson - Paul@TDR.COM Voted "Largest Polluter of the (IETF) list" by Randy Bush ----- The following Automatic Fortune Cookie was selected only for this message: The human mind treats a new idea the way the body treats a strange protein -- it rejects it. -- P. Medawar From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 12:34:45 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19434; Thu, 30 Jun 1994 12:34: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 MAA23085; Thu, 30 Jun 1994 12:34:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA23082; Thu, 30 Jun 1994 12:28:37 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19309; Thu, 30 Jun 1994 12:28:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15458; Wed, 29 Jun 94 22:28:16 -0400 Date: Wed, 29 Jun 94 22:28:16 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406300228.AA15458@ginger.lcs.mit.edu> To: bdk@saturn.csd.unb.ca, big-internet@munnari.OZ.AU Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: Brian Kaye Are you basically saying you need one name to say "who" you are and another name to say "where" you are? Yes, exactly. The analogy is with what you put on a postal letter; there's the name of an individual (which stays the same no matter where you go), which says *who* it's to. Then, there's the street address (well, a postal address, technically), which is used to say *where* you are. The post office generally only looks at the latter to deliver mail (unless you're left written instructions to say that the old binding between who you are and where you are has changed, and there's a new value for where you are). Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 14:01:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20239; Thu, 30 Jun 1994 12:54: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 MAA23139; Thu, 30 Jun 1994 12:54:16 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA23133; Thu, 30 Jun 1994 12:48:36 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19920; Thu, 30 Jun 1994 12:48:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15618; Wed, 29 Jun 94 22:48:29 -0400 Date: Wed, 29 Jun 94 22:48:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406300248.AA15618@ginger.lcs.mit.edu> To: barney@databus.com, big-internet@munnari.OZ.AU Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: Barney Wolff >> Similarly, why not push this problem into a higher level protocol. I took the question to mean: Is the (eg) TCP name = EID + port, or +port? The EID is just one possibility for a TLN, so unless by "" you mean, say, a topologically-sensitive ILN, I'd say the first (EID + port) is a subset of the second, which I take to mean "TLN + port". But Noel clearly took it to mean is the EID = Locator? Well, Noel took the question to mean "why not stick the TLN inside the transport layer, and hide it totally from the internetworking layer", actually. I vote for TCPname = EID+port and EID != Locator (and not a subset either). In case it's not clear, this is what I like too. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 14:04:51 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19471; Thu, 30 Jun 1994 12: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 MAA23103; Thu, 30 Jun 1994 12:35:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA23068; Thu, 30 Jun 1994 12:22:13 +1000 Precedence: list Received: from uu.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18923; Thu, 30 Jun 1994 12:22:01 +1000 (from pjnesser@rocket.com) Received: by uu.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP; id AA15360 for ; Wed, 29 Jun 94 22:15:15 -0400 Received: from asgaard.rocket.com (asgaard.ARPA) by earth.rocket.com (4.1/3.2.083191-Olin Aerospace Company - Redmond Wa) id AA20015; Wed, 29 Jun 94 18:51:39 PDT Organization: Olin Aerospace Company Telephone: (206)885-5000 Fax: (206)882-5804 Received: by asgaard.rocket.com (4.1/SMI-4.1) id AA29027; Wed, 29 Jun 94 18:51:41 PDT Date: Wed, 29 Jun 94 18:51:41 PDT Message-Id: <9406300151.AA29027@asgaard.rocket.com> To: PAUL@tdr.com Cc: Big-Internet@munnari.OZ.AU, ietf@CNRI.Reston.VA.US, namedroppers@rs.internic.net In-Reply-To: <01.1994Jun29.17h27m45s.PAUL-0100000@TDR.COM> (message from Paul Robinson on Wed, 29 Jun 1994 20:25:30 -0400 (EDT)) Subject: Re: In the matter of 64-bit addresses From: "Philip J. Nesser" Sender: pjnesser@rocket.com Us-Snail: 15825 Leary Way NE #306, Redmond WA, 98052 The scheme may seem nice fails miserably in the real world. If the "Internet" was a huge monopoly (like AT&T was in the US, but even more monopolistic) and everyone trusted everyone else (or security was at such a sophisticated and pervasive level that having everything open didn't matter) then it might, just might work (It is so difficult to think of a world where everything was so perfect that its hard to think of other flaws). The world is not a trusting place. Routing is not so easy, because of proprietary networks. As an example, Company A was 50 sites, one in each US state. They are all connected via an internal company backbone of whatever flavor, but there is only one site (the corporate data center in Nevada say) which connects to the general Internet. Now my site which has a geographical IP address is New Jersey has a path which goes through Nevada. How do you route that? If my Nevada site has to start advertising static/special routes for all of my internal sites then routing tables grow like mad. How about Internet providors. Do PSI and UUNET have to divide up the heirarchy between the clients in a specific geographical site. How about moves. If I manage a company and we move to a different site which is in a different geographical zone, I then have to redo all of my ip addresses. You say that you will leave 14 for mobile devices. How does that work? I could go on, but let me just say that location dependent addressing for general addresses and specifically networks are not practical at all. The whole concept is one that is being dealt to some degree by the mobile ip people but I am assuming that they are more concerned with point-to-point type connections for single machines (ie your laptop in your car, or on a train/plane whatever.) I haven't been paying much attention to it so hopefully someone with more knowledge will correct me if I am way off base with that statement. ---> Phil From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 14:05:55 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20289; Thu, 30 Jun 1994 12:57: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 MAA23180; Thu, 30 Jun 1994 12:57:32 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA23130; Thu, 30 Jun 1994 12:42:08 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19730; Thu, 30 Jun 1994 12:42:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15580; Wed, 29 Jun 94 22:41:39 -0400 Date: Wed, 29 Jun 94 22:41:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406300241.AA15580@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, pvm@isi.edu Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: Paul Mockapetris Actually I was trying to be vague and get someone to tell me how the EIDs worked. ... If not 802 numbers, then what? Well, I personally liked the idea of having a part of the EID space be assigned to 802 numbers, so that would be an easy source of EID's, but there are those who think that's not workable due to duplicates. Some people seem to like EID's which are assigned much the same way IPv4 addresses are now; i.e. via an assignment hierarchy. I don't have a strong position on any of these, as long as i) EID's are basically globally unique (and we can talk about what happens when they aren't; there are failure modes akin to having two Ethernet cards with the same IPv4 address, something we don't currently explicitly detect), and ii) it stays the same no matter where you go. The next question in above scenario is are there two TLNs for every process in a multi network adapter machine? No. First, you wouldn't need a separate TLN for each process unless they are mobile; if they are all forced to stay on the same machine (e.g. your average Unix), they're all part of the same fate-sharing region, and they can all share a single TCP port-space, for example. Second, there would be multiple ILN's, one for each network adapter, but these would all be mapped to the same TLN, since they all lead to the same fate-sharing entity. (Of course, if you have multiple TLN's in the machine, you have an NxM mapping, but let's not get too crazed..) Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 14:06:40 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20287; Thu, 30 Jun 1994 12:57: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 MAA23165; Thu, 30 Jun 1994 12:56:02 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA23136; Thu, 30 Jun 1994 12:54:07 +1000 Precedence: list Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18791; Thu, 30 Jun 1994 12:18:19 +1000 (from pvm@ISI.EDU) Received: from aloha.isi.edu by zephyr.isi.edu (5.65c/5.61+local-16) id ; Wed, 29 Jun 1994 19:17:21 -0700 Message-Id: <199406300217.AA12839@zephyr.isi.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.OZ.AU Reply-To: pvm@isi.edu Subject: Re: IPng ADs request In-Reply-To: Your message of Wed, 29 Jun 1994 11:59:29 -0400. <9406291559.AA11726@ginger.lcs.mit.edu> Date: Wed, 29 Jun 94 19:14:08 PDT From: Paul Mockapetris > Well, the example I mentioned (host mobility) shows that the binding is not > terribly strong. I view the binding as being made at the time a DNS lookup > is done (multi-homed hosts would return multiple "routing names"), and it > can be changed thereafter in the case of mobile hosts (with that mechanism > being adequately secured to prevent denial-of-service or other attacks). > > For example, if I have a host with two network adapter cards, and one card > breaks, so I swap in a network card from another host, how did I keep > track of these EIDs and how many were there? > > You're assuming that the transport level name (TLN) is generated from a > "unique number" on the interface, but a number of people have pointed out that > you can't rely on 802 numbers to really be unique. Actually I was trying to be vague and get someone to tell me how the EIDs worked. If you said "EIDs have nothing to do with network adapter cards and are magic unique numbers associated with a host" or "EIDs are ROMs on network boards" I could start going down one branch of the decision tree or another. If not 802 numbers, then what? The next question in above scenario is are there two TLNs for every process in a multi network adapter machine? paul USC/Information Sciences Institute phone: 310-822-1511 x285 4676 Admiralty Way, Marina del Rey, CA fax: 310-823-6714 90292 From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 14:07:16 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20333; Thu, 30 Jun 1994 12:58: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 MAA23195; Thu, 30 Jun 1994 12:58:43 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id MAA23093; Thu, 30 Jun 1994 12:34:45 +1000 Precedence: list Received: from ns.Novell.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16653; Thu, 30 Jun 1994 11:29:23 +1000 (from Greg_Minshall@Novell.COM) Received: from WC.Novell.COM (optics.wc.novell.com) by ns.Novell.COM (4.1/SMI-4.1) id AA11860; Wed, 29 Jun 94 19:29:03 MDT Received: from by WC.Novell.COM (4.1/SMI-4.1) id AB04686; Wed, 29 Jun 94 18:25:21 PDT Date: Wed, 29 Jun 94 18:25:21 PDT Message-Id: <9406300125.AB04686@WC.Novell.COM> X-Sender: minshall@optics.wc.novell.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: kasten@ftp.com From: Greg Minshall Subject: Re: IPng ADs request Cc: big-internet@munnari.OZ.AU Frank, >The Transport-level name is something that is under the control of >the transport level. It is used to uniquely and globally identify an >end of a transport-level association (I hesitate to use the work >connection since these names would be used for both connection-ful >and connection-less transports). I remember one night 10 or so years ago at SCIDS at SHARE explaining IP to some IBMers from Raleigh. Finally, one of them said to the others, "oh, i get it - they do resequencing at a different level". SNA is, of course, very "connection oriented"; IP is, of course, very "connectionless". Nonetheless, several years ago i was sorely tempted to write a paper with the title "The pervasiveness of connections at all levels of IP". There are "connections", which is to say state stored to connect end-to-end, EVERYWHERE. There are ARP tables, forwarding tables, redirect caches. I remember a session at InterOp 7 or 8 years ago or so (maybe the first in Santa Clara?) when a friend of mine, then with Sun, who shall remain nameless, claiming - CLAIMING IN PUBLIC mind you - that it was because NFS was running on top of UDP that it was stateless; that if you made NFS run on TCP, it would no longer be stateless. Pure silliness (my friend will, no doubt, forgive me)! Ah, it feels good to rant and rave! The point, however, is not that there *isn't* a connection (there is, or if "there isn't", the difference is semantics on the head of a pin). The true point is "what are the characteristics of the connection?" (well, yeah, OK, something like "the true religion"). Sorry. Back to your regularly scheduled debate... Greg From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 14:14:34 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23053; Thu, 30 Jun 1994 14:14: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 OAA23274; Thu, 30 Jun 1994 14:14:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id NAA23249; Thu, 30 Jun 1994 13:54:17 +1000 Precedence: list From: smb@research.att.com Received: from ninet.research.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19864; Thu, 30 Jun 1994 12:45:34 +1000 (from smb@research.att.com) Message-Id: <9406300245.19864@munnari.oz.au> Received: by gryphon; Wed Jun 29 22:43:53 EDT 1994 To: Paul Robinson Cc: On the Growth of the Internet , IETF List , Namedroppers Subject: Re: In the matter of 64-bit addresses Date: Wed, 29 Jun 94 22:43:52 EDT This seems so simple that I can't figure out what's wrong with it It's useless for routing in the real world, where connectivity often has to follow administrative links, rather than political ones. To give one simple example, AT&T Bell Laboratories needs the flexibility to engineer the bandwidth of our links from New Jersey to Columbus based on our traffic and cost needs -- and we're not going to invite others onto our private links simply because they happen to be routing packets in the same direction. From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 14:36:19 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24019; Thu, 30 Jun 1994 14:36: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 OAA23327; Thu, 30 Jun 1994 14:36:12 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA23282; Thu, 30 Jun 1994 14:14:45 +1000 Precedence: list Received: from mail.crl.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23060; Thu, 30 Jun 1994 14:14:41 +1000 (from gwh@crl.com) Received: from crl2.crl.com by mail.crl.com with SMTP id AA20127 (5.65c/IDA-1.5 for ); Wed, 29 Jun 1994 21:12:11 -0700 Received: from localhost.crl.com.0.0.127.IN-ADDR.ARPA by crl2.crl.com with SMTP id AA12140 (5.65c/IDA-1.5); Wed, 29 Jun 1994 21:12:09 -0700 Message-Id: <199406300412.AA12140@crl2.crl.com> To: smb@research.att.com Cc: Paul Robinson , On the Growth of the Internet , IETF List , Namedroppers , gwh@crl.com Subject: Re: In the matter of 64-bit addresses In-Reply-To: Your message of "Wed, 29 Jun 1994 22:43:52 EDT." <199406300241.WAA03283@rs.internic.net> Date: Wed, 29 Jun 1994 21:12:09 -0700 From: George Herbert There is no reason why a big enough net can't have both administrative and geographical mapping schemes. Say, first bit says if it's to an independent network or open geographical based. Why would anyone ever think that more bits is anything but more flexible in letting us do things like this? 8-) From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 15:34:41 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26777; Thu, 30 Jun 1994 15:34: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 PAA23425; Thu, 30 Jun 1994 15:34:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA23422; Thu, 30 Jun 1994 15:25:36 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26239; Thu, 30 Jun 1994 15:25:19 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 30 Jun 94 14:16:51 +0859 From: Masataka Ohta Message-Id: <9406300517.AA15011@necom830.cc.titech.ac.jp> Subject: Re: assignment efficiency To: yakov@watson.ibm.com Date: Thu, 30 Jun 94 14:16:49 JST Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.OZ.AU In-Reply-To: <9406291926.3007@munnari.oz.au>; from "yakov@watson.ibm.com" at Jun 29, 94 3:25 pm X-Mailer: ELM [version 2.3 PL11] > Noel, > > >CIDR was introduced *precisely* because the 3+ (net, subnet(s), host) > >we had weren't enough. I'm not sure how many layers various parts of the > >network are using now that CIDR has been deployed (you can' tell just from > >looking at an address), but I wouldn't be surprised if parts are now using > >5. > > In addition to (net, subnet(s), host), we have today 2 more levels -- > (provider, site). So, the total number of levels in the routing > hierarchy used *today* is 5 -- you are correct. > > Yakov. Both of you are mixing locator layers and EID layers. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 15:43:58 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23958; Thu, 30 Jun 1994 14:34: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 OAA23312; Thu, 30 Jun 1994 14:34:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA23276; Thu, 30 Jun 1994 14:14:26 +1000 Precedence: list Received: from primus.cstp.umkc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23042; Thu, 30 Jun 1994 14:14:20 +1000 (from lee@PRIMUS.CSTP.UMKC.EDU) Received: by PRIMUS.CSTP.UMKC.EDU (MX V4.0-1 AXP) id 1; Wed, 29 Jun 1994 23:13:24 CST Date: Wed, 29 Jun 1994 23:13:23 CST From: Sung Jong Lee (David) Reply-To: LEE@vax2.cstp.umkc.edu To: big-internet@munnari.OZ.AU Message-Id: <00980B2C.ECA1F182.1@PRIMUS.CSTP.UMKC.EDU> Subject: I am having a big problem!!!!! I am receiving a same mail more than 5 times in some case . Most of mails are delivered to my account at least twice. what is wrong in this mailing list. in face i want to be removed from th elist .. pl Yx onzU zIDeas|4pe hK+Ot llp. Cz(1 From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 15:51:03 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24094; Thu, 30 Jun 1994 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 OAA23342; Thu, 30 Jun 1994 14:37:13 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA23307; Thu, 30 Jun 1994 14:28:46 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23655; Thu, 30 Jun 1994 14:28:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16294; Thu, 30 Jun 94 00:28:29 -0400 Date: Thu, 30 Jun 94 00:28:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406300428.AA16294@ginger.lcs.mit.edu> To: Greg_Minshall@novell.com, big-internet@munnari.OZ.AU Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: Greg Minshall In a scheme that stores *current location* information of a mobile host inside DNS, don't we either lose this caching (== scalability) principle or, alternatively, have to enforce some minimum time between moves I'm not sure that storing the current locator of a highly mobile object in the DNS is the way to go, but I don't know for sure. For one thing, I thought you could set a separate TTL on each item in the DNS, so *if* you were storing the locators for mobile hosts in DNS you could set a short TTL on them, forcing you to go back to an authoritative serve for just those entries. I mean, what's more efficient: get the wrong locator from your local cache, send a packet to that locator (the base station), get back the right answer, and off you go, or send a packet to the authoritative DNS server for a given DNS name (and this you presumably *could* cache), and get back the right data, and off you go? It's one packet either way, right? This of course assumes the person doesn't *want* triangle routing (e.g. for security, so you don't know they're not home). In this case, the distant host *never* discovers the move... I suspect the question of whether the DNS, or the base station, is the right place to keep this binding probably has more to do with how expensive it is to update either one than anything else.... One of the advantages in a scheme like the current mobile-ip scheme is that DNS doesn't lose its caching property But if the number of DNS sites that are authoritative is the same as the number of base stations, and in the same places, you'll get exactly the same traffic patterns (modulo the forwarding of the first packet). What's the difference? And, if "locality" holds in which mobile hosts are often located "close" to the home location ... this scheme actually wins (since if the mobile host is "close enough" to the home location, there wouldn't need to be *any* notification to the correspondent host). The existence of a binding betwen a TLN and an ILN gives you the choice of keeping the binding intact, or explicity breaking it. There may well be some cases in which the former is the way to go (such as the one you mention), but just because you *can* modify the binding doesn't mean you *have* to. On the other hand, there probably will be cases in which modifying the binding *is* the way to go, but if you can't do it, you're stuck. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 15:53:13 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25052; Thu, 30 Jun 1994 14: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 OAA23372; Thu, 30 Jun 1994 14:54:18 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id OAA23358; Thu, 30 Jun 1994 14:38:35 +1000 Precedence: list Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22484; Thu, 30 Jun 1994 14:01:38 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16128; Thu, 30 Jun 94 00:01:01 -0400 Date: Thu, 30 Jun 94 00:01:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9406300401.AA16128@ginger.lcs.mit.edu> To: big-internet@munnari.OZ.AU, ihanson@pcs.dec.com Subject: Re: IPng ADs request Cc: jnc@ginger.lcs.mit.edu From: "Iain K. Hanson" As I understand it, a transport level name should be relative to the internetwork level name(s) and identifies an end-point ... that is uniquely addressed by the combination. However, I see no need for the TLN itself, to be globally unique. If it's not, but is relative to the ILN (the thing the routers use to deliver the packets to where they are going), a number of nifty applications (such as multi-homed hosts, mobility, etc) don't work very well. As a matter of fact, this would be little different from the current IPv4, except you'd be able to have multiple TCP port spaces in any given host. Is an EID a TLN? I don't think so. Well, that sort of astonishes me, since when I defined the concept of an EID, I fully intended that it be a TLN. Let's see what gives... as I see it ... it has the following ( possibly conflicting ) properties: It identifies N internetwork level interfaces. No, it doesn't identify interfaces at all. It identifies endpoints (that's the 'E'), which you may think of as hosts (to a first approximation). There is a binding between an EID and the interface(s) through which it's currently reachable, but that's it. There can be a number of EIDs with ?overlapping? groups of interfaces. This would be hard to manage without very strange hardware; endpoint A is reachable through interfaces X and Y, and endpoint B is only reachable via X? There could be an EID at the top of this that owns all other EIDs and identifies the whole end-system ( host/box/whatever... ). It's not clear whether EID's have hierarchical organizational structure. Users wish to allocate EIDs themselves hierarchically, probably in a sparse tree with arbitary depth. Some want to do this. EIDs can be auto-configured without a server ( or router ) for plug-and-play out of the box. Without ROM, or use of 802 numbers as a sourc for "unique" numbers, this is kind of hard. Auto-configuration can be prevented by routers or servers if so required. I think you're getting confused with the "serverless autoconfiguration of addresses" discsussion. An EID has N Locators associated with it. An endpoint which is named with a particular EID (when you're standing on the street, *you* are standing on the street, *your name* is not standing on the street) might be bound to one or more interfaces, each of which might have one or more locators (precise definition of "locator" skipped), yes. And I think that it follows from the above, that a locator can have more than one EID!!! More than one endpoint can be reached through the same interface (i.e. the same locator), yes. For instance, if some EID's name mobile processes, you could have several in one machine. Most of these properties seem to me to indicate that an EID is an internetwork level name that has administrative, but *no* topological significance. This is about right. EID's inhabit a hazy plane which is sort of at the top of the internetwork layer, and the bottom of the transport layer. Locators on the other hand seem to be internetwork level names with routing significance - althopugh whether they are geographically, provider, or topologically organised, is a yet unclear to me. The inventor thinks that the significance is topological, since this is the only thing that's useful to the routing.. I presume that two physical interfaces could share a Locator ( for instance if they were both connected to the same piece of Ethernet ). Uggh; if you have a local mapping layer, like ARP, which can hide a one-> several mapping, yes. Very ugly, and I wouldn't recommend it *at all*. A locator is a name for an interface, and if you have mroe than one interface, that's what the flexible EID->locator binding is for. I think that the internetwork level name is made up of an EID and Locator but the end point can only be idenified by the addition of a TLN. See initial comments. The locator is as much of a name as the internetwork level needs, and an endpoint is identified by an EID standing alone. I currently feel a little confused about the whole issue :-(. Don't worry, you're not alone, by a long shot. Noel From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 16:46:47 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27471; Thu, 30 Jun 1994 15:54: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 PAA23455; Thu, 30 Jun 1994 15:54:17 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id PAA23452; Thu, 30 Jun 1994 15:43:16 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23741; Thu, 30 Jun 1994 14:31:02 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 30 Jun 94 13:24:13 +0900 From: Masataka Ohta Message-Id: <9406300424.AA14687@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs request To: Greg_Minshall@Novell.COM (Greg Minshall) Date: Thu, 30 Jun 94 13:24:11 JST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9406300124.AB04686@WC.Novell.COM>; from "Greg Minshall" at Jun 29, 94 6:24 pm X-Mailer: ELM [version 2.3 PL11] > Masataka, > > I *very much* want to have locators separate from EIDs. Really? I'm rather concerned about conceptual and administrative separation. > But, i'm not > convinced that right now we know how to do this in a way that would make it > work. I hate people who believes DNS can solve all the mapping problems. But, considering that the most difficult part, mobility, could be handled by something like SMIP, I think DNS should work in this case for mapping between hostname, EID, and locators. > > EID should follow administration hierarchy. > > > > EID should not be forced to follow geographical hierarchy. > WHAT IS AN EID USED FOR? As a fixed length ID of a node. > What are the uses of an EID? For example, EID combined with flow ID is useful to identify a flow on intermediate routers. > WHAT ARE THE CONSEQUENCES OF A DUPLICATE EID? Same as that caused by duplicated domain name. > WHO CAN "FIX" DUPLICATE EIDS? When bidirectional mapping between EID and hostname is maintained by secure DNS with certain root servers, it will be detected and fixed as security violation. > In hierarchical schemes, > there *IS* someone who can say this, but it isn't clear (to me) how that > someone will enforce this edict. By (secured) delegation of DNS subtree. > The very *topology insensitivity* of EIDs, which is so attractive to us > all, is one of the key features that makes them potentially difficult to > monitor and manage. Both hostname and EID share the same difficulty to monitor and manage though EID is a little more easier and a lot more efficient to handle. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 19:54:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07917; Thu, 30 Jun 1994 19:54: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 TAA23665; Thu, 30 Jun 1994 19:54:19 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id TAA23662; Thu, 30 Jun 1994 19:46:50 +1000 Precedence: list Received: from necom830.cc.titech.ac.jp by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01249; Thu, 30 Jun 1994 17:36:09 +1000 (from mohta@necom830.cc.titech.ac.jp) Received: by necom830.cc.titech.ac.jp (5.65+/necom-mx-rg); Thu, 30 Jun 94 16:29:40 +0900 From: Masataka Ohta Message-Id: <9406300729.AA15692@necom830.cc.titech.ac.jp> Subject: Re: IPng ADs request To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 30 Jun 94 16:29:38 JST Cc: big-internet@munnari.OZ.AU, jnc@ginger.lcs.mit.edu In-Reply-To: <9406291630.AA12022@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jun 29, 94 12:30 pm X-Mailer: ELM [version 2.3 PL11] > I think EID is, like domain name, a network level name. > > Yes. I'm afraid you said EID a transport layer name elsewhere. > On the other hand, I don't think "locator" a name. > > I was using "name" in the formal computer-science sort of way, as an > "identifier" or "label". Yes, "locator" is a name for location. "locator" identifies or labels location. "locator" does not identify nor label a host. So, "locator" is not a name of a host. Transport layer policy such as bandwidt requirement affects "locator", it is not a network layers name. Masataka Ohta From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 22:14:33 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15215; Thu, 30 Jun 1994 22:14: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 WAA23803; Thu, 30 Jun 1994 22:14:21 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA23789; Thu, 30 Jun 1994 22:06:29 +1000 Precedence: list Received: from tipper.oit.unc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15032; Thu, 30 Jun 1994 22:06:25 +1000 (from ses%tipper@tipper.oit.unc.edu) Received: from localhost.oit.unc.edu by tipper.oit.unc.edu (SMI4.1/FvK 1.02) id AA02402; Thu, 30 Jun 94 08:06:14 EDT Message-Id: <9406301206.AA02402@tipper.oit.unc.edu> To: Greg Minshall Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU, pvm@isi.edu Subject: Re: IPng ADs request In-Reply-To: Your message of "Wed, 29 Jun 94 18:25:02 PDT." <9406300125.AB04686@WC.Novell.COM> Date: Thu, 30 Jun 94 08:06:14 -0400 From: Simon E Spero >>>>> "Greg" == Greg Minshall writes: Greg> In a scheme that stores *current location* information of a Greg> mobile host inside DNS, don't we either lose this caching Greg> (== scalability) principle or, alternatively, have to Greg> enforce some minimum time between moves ("don't touch that Greg> laptop!")? DNS allows caching to be disabled for individual records; disabling caching makes sense for values which are dynamic. You could use a best effort approach of allowing resolvers to cache potentially wrong values, and then look up the authoratative values if the value is determined to be wrong, which is ugly, but should work ok. Incidentally, all UNC laptops are labeled with standard tags which require the user to "notify asset accounting if this equipment is moved".... From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 22:47:54 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15925; Thu, 30 Jun 1994 22:34: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 WAA23833; Thu, 30 Jun 1994 22:34:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id WAA23819; Thu, 30 Jun 1994 22:16:50 +1000 Precedence: list Received: from wd40.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15268; Thu, 30 Jun 1994 22:16:44 +1000 (from kasten@mailserv-D.ftp.com) Received: from ftp.com by ftp.com ; Thu, 30 Jun 1994 08:16:41 -0400 Received: from mailserv-D.ftp.com by ftp.com ; Thu, 30 Jun 1994 08:16:41 -0400 Received: by mailserv-D.ftp.com (5.0/SMI-SVR4) id AA10143; Thu, 30 Jun 94 08:14:44 EDT Date: Thu, 30 Jun 94 08:14:44 EDT Message-Id: <9406301214.AA10143@mailserv-D.ftp.com> To: jnc@ginger.lcs.mit.edu Subject: Re: IPng ADs request From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.OZ.AU, pvm@isi.edu, jnc@ginger.lcs.mit.edu Content-Length: 1555 > From: Paul Mockapetris > > Actually I was trying to be vague and get someone to tell me how the > EIDs worked. ... If not 802 numbers, then what? > >Well, I personally liked the idea of having a part of the EID space be >assigned to 802 numbers, so that would be an easy source of EID's, but there >are those who think that's not workable due to duplicates. Some people seem to >like EID's which are assigned much the same way IPv4 addresses are now; i.e. >via an assignment hierarchy. Duplicates are only one issue. There are also: 1. what about systems without 802 interfaces (eg ppp)? 2. do we have to map from an eid number to something else via dns? if so then we will need to have some structure in the eids so that dns can make efficient use of them (i.e. they have to be assigned by the owner of a machine so that dns can map the 'prefix' of the eid back to the owner's dns server) 3. in high up-time systems you might be able to swap 802 interfaces without bringing the 'fate sharing region' down. does everything get a new eid then? what happens to the associations that were going on and are now 're-eid-ed'? 4. if a machine has one 802 interface, how does it get multiple eids? 802 numbers are useful in many circumstances, but they are not _the_ solution. when it comes time to specify eids, i'd suggest that one form of eid include an embedded 802 number, but this should not be the only form. -- Frank Kastenholz FTP Software 2 High Street North Andover, Mass. USA 01845 (508)685-4000 From owner-Big-Internet@munnari.OZ.AU Thu Jun 30 23:14:35 1994 Received: from murtoa.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17175; Thu, 30 Jun 1994 23:14: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 XAA23904; Thu, 30 Jun 1994 23:14:22 +1000 Received: from munnari.oz.au by murtoa.cs.mu.OZ.AU (8.6.9/1.0) with SMTP id XAA23901; Thu, 30 Jun 1994 23:12:03 +1000 Precedence: list Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17084; Thu, 30 Jun 1994 23:11:54 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9406301311.17084@munnari.oz.au> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 30 Jun 1994 14:10:32 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.OZ.AU Subject: Re: IPng ADs request In-Reply-To: Your message of "Thu, 30 Jun 94 14:15:38 +0100." <9406301215.AA07544@cssec4.pcs.dec.com> Date: Thu, 30 Jun 94 14:10:33 +0100 From: Jon Crowcroft EI-addio, i spose i should vote for this. but the argument about structure inside an EID seems to me to be irellevant to the IPng - we should only care about how many bits an EID need be to accommodate all the options (mac addr, arbirtraryily assigned code, social security # etc) the only structure we're worried about in IPng is that nheeded to do good mobility, multicast, policy routes, and not impede efficient use of low bandwdith links and easy parsing, in the LOCATOR... cheers jon