From owner-Big-Internet@munnari.oz.au Sat Aug 1 00:42:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29803; Sat, 1 Aug 1992 00:43:03 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29793; Sat, 1 Aug 1992 00:42:58 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Fri, 31 Jul 92 10:42:50 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Fri, 31 Jul 92 10:42:48 EDT Date: Fri, 31 Jul 92 10:42:48 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207311442.AA03624@chiya.bellcore.com> To: tli@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: Route fragments, a routing proposal Cc: Big-Internet@munnari.oz.au > > I believe that we _cannot_ get routing info in the header to be > sufficiently general. This is not intended to be a slight to Pip or > Nimrod. It is a simple recognition of the fact that our crystal ball > is flawed and that we cannot possibly predict the future applications > that we will need to support within the lifetime of this protocol. Of course we cannot predict all of the future, but I believe that Pip anticipates all current ideas for the "forseeable" future. (I know, gag me with a spoon). > > So given that we cannot possibly do it _right_ today, what do we do? > We have to provide the services that we have available now, and we > have to leave in the hooks so that we can extend and adapt the > protocol to new and interesting environments. So to be concrete, I > would advocate a) designing an optimized header for maximal > performance in the simplest cases, b) leaving in enough hooks so that > we can change the routing algorithm later, and c) insuring that the > extension/adaptation mechanism is very efficient, so that there is not > a big penalty for processing extensions. Ah. But, in a very real sense, this is a perfect description of Pip. A very good header for simple cases (maybe not "optimized", whatever that means, but looks good to me), nice hooks for change later (expecially because Pip doesn't deal in option fields--every field in Pip header is looked at by every router, so you lessen the problem of "oops, we can't do this new option because XYZ router don't know that option", and the extension/adaptation mechanism is efficient because it consists of the same fields already used. And, if it turns out the Pip can't do some future thing, then we seem to be no worse off than any other protocol that can't do some future thing. > > Lest anyone accuse me of being creative, please note that this is just > a transliteration of Unix design philosophy: Small and extensible is > beautiful. I hope that this appeals to at least the gentleman from > Bellcore... ;-) > Well, it appeals to me, because you describe Pip to a tee. Thanks for the support! PT From owner-Big-Internet@munnari.oz.au Sat Aug 1 00:49:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29952; Sat, 1 Aug 1992 00:49:26 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29949; Sat, 1 Aug 1992 00:49:18 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA18330; Fri, 31 Jul 1992 16:48:56 +0200 Message-Id: <199207311448.AA18330@mitsou.inria.fr> To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: avalon@coombs.anu.edu.au, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: Re: Host Identifier and Location In-Reply-To: Your message of "Fri, 31 Jul 92 09:14:05 EDT." <9207311314.AA03500@chiya.bellcore.com> Date: Fri, 31 Jul 92 16:48:54 -0400 From: Christian Huitema X-Mts: smtp It seems very clear that the next thing we will see on the Internet is a generalization of some form of loose source routing. How loose is the routing will be highly variable: * if doing ressource reservation, say for 140mbps full blast video, the source should make pretty sure that the packets go on precisely the route on which resource have been allocated. * if using source routing for policy obeidance, a very generic specification like the "MIT>NEARnet>NSF>BARnet>Stanford" example of DDC is prefered: there may well be many possible paths between NSF and BARnet, and the source has no real interest in specifying which one. * if using source routing for simple access to mobile hosts, one has to give a path to the "hub" to which the host is attached. But the way to that path may remain largely unspecified. It is very clear that we could use the host "unique identifiers" for specifying a source route -- after all, we do that already in IPv4. It is obvious that using these identifiers has one big advantage -- easy to specify and understand -- and one potentiel disadvantage -- huge headers. IMHO, this looks like a case for variable length UI's: * short UI's for often used names, e.g. "NSF". * long UI's (64?) for hosts. * something in between for transit networks. By the way, the expression "NSF" in the "route fragment" looks like "any relay within NSF". It would be logical to identify this by the "NSF prefix", if we suppose a CIDR like allocation of the UI's. The classical argument against variable length addresses is that they are longer to parse + misaligned. I believe that the alignment argument is a lot weaker if we mix 16+32+64 bits CPUs, and that there is always a benefit in having shorter packets. Or do I have it all wrong? Christian Huitema From owner-Big-Internet@munnari.oz.au Sat Aug 1 01:03:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00584; Sat, 1 Aug 1992 01:03:54 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00579; Sat, 1 Aug 1992 01:03:46 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25477; Fri, 31 Jul 92 11:02:04 -0400 Message-Id: <9207311502.AA25477@ginger.lcs.mit.edu> To: Paul Tsuchiya Cc: Big-Internet@munnari.oz.au Subject: Re: Question on Clark's route fragments In-Reply-To: Your message of Thu, 30 Jul 92 20:53:25 -0400. <9207310053.AA03217@chiya.bellcore.com> From: David Clark Date: Fri, 31 Jul 92 11:02:03 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp Paul, I think you have slightly misunderstood my idea. (Or else I misunderstand; let's see.) I did not think that all AD identifiers would include net and host. A net and host compontent is needed, but only once, to be used inside the final AD. I agree that 4 byte AD identifiers might be fine. I do not see why this complicates the routing process. I agree that the router needs to know the context in which it is routing, but this is not a big deal. It is like knowing if the packet is destined for a locally attached net. But the more important point, which was also coming up at the PIP BOF, is that there are two different times at which a route needs to be represened inside the system. One is the time at which topology information is presented to the routing algorithm as input, with the objective of computing the desired route. The second is when the packet is presented to the router. The routes do not have to look the same at those two times. Let me put this in terms of a change to PIP. (This will also let me test if I understand PIP.) PIP routes are composed of elements which are named by names that have local significance. To navigate in this space, PIP adds a rather compex model of hierarchy, which lets you know when to go up, sideways, or down. At the BOF, I was getting all messed up trying to see where this was going. Imagine instead that AD have global names, and as well each AD assigns a local name to each AD for which it maintains routing knowledge. To compute the route, you use the global names. It does not matter how big they are, since they are not going in a packet header. Then, once you have found the intended route, you look up the local name which each AD in the path has for the next AD in the path. You don't need any framework such as hierarchy to deal with these names. They are just small numbers. Now build the "short-form" route as a sequence of these local names with a pointer, as in PIP. You can no longer do any global computation on these routes, all you can do is follow them. But that is what packets do. These local names will have to stay bound to the global names for a long time. This may seem a problem, but I don't think so. Anyway, the local names in PIP have to keep their meaning in the same way. These local names could actually be stored as additional information inside the route fragments, so that once you have computed the route using the long names, you just take the short names out of the same object you got from the "route fragment server". Now the additional twist is that we might do route setup and then use a CI, so that even this "short-form" route does not have to be in each packet. But I think the local names might well be as short as 2 bytes. (Rash, I know.) Dave From owner-Big-Internet@munnari.oz.au Sat Aug 1 01:05:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00620; Sat, 1 Aug 1992 01:05:38 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00616; Sat, 1 Aug 1992 01:05:32 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Fri, 31 Jul 92 08:05:24 -0700 Date: Fri, 31 Jul 92 08:05:24 -0700 From: Tony Li Message-Id: <9207311505.AA08052@cider.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: tsuchiya@thumper.bellcore.com, Big-Internet@munnari.oz.au In-Reply-To: Paul Tsuchiya's message of Fri, 31 Jul 92 10:42:48 EDT <9207311442.AA03624@chiya.bellcore.com> Subject: Route fragments, a routing proposal > I believe that we _cannot_ get routing info in the header to be > sufficiently general. This is not intended to be a slight to Pip or > Nimrod. It is a simple recognition of the fact that our crystal ball > is flawed and that we cannot possibly predict the future applications > that we will need to support within the lifetime of this protocol. Of course we cannot predict all of the future, but I believe that Pip anticipates all current ideas for the "forseeable" future. (I know, gag me with a spoon). Hmmm... I think I have to disagree. For example, one of the things that Deborah, Yakov and I have been mulling over is the concept of computing policy routes over heterogeneous network layers. So you get a route through domaints that speak: IPv4, CLNP, IPv7, IPv4. How would Pip support this? It can't. How does Pip support packet coloring (NOT QoS)? How would Pip express the concept of "you have permission to dynamically recompute my policy route as long as you ...."? I think that you underestimate human (and especially your own) creativity. The "forseeable" future is a very short time. Far less than the 20 years that we expect this protocol to last, and much less than the 100 years that we should be designing for. A very good header for simple cases (maybe not "optimized", whatever that means, but looks good to me), nice hooks for change later (expecially because Pip doesn't deal in option fields--every field in Pip header is looked at by every router, so you lessen the problem of "oops, we can't do this new option because XYZ router don't know that option", and the extension/adaptation mechanism is efficient because it consists of the same fields already used. And, if it turns out the Pip can't do some future thing, then we seem to be no worse off than any other protocol that can't do some future thing. Unless, of course, the other protocol has an extension/adaptation mechanism which we can hack to carry the information that we want. Tony From owner-Big-Internet@munnari.oz.au Sat Aug 1 01:28:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01057; Sat, 1 Aug 1992 01:28:22 +1000 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01046; Sat, 1 Aug 1992 01:28:15 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA10308; Fri, 31 Jul 92 11:25:54 -0400 Date: Fri, 31 Jul 92 11:25:54 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9207311525.AA10308@er.doe.gov> To: Big-Internet@munnari.oz.au, tsuchiya@thumper.bellcore.com Subject: Re: Route fragments, a routing proposal If we have to design the routing architecture in detail first we're in a lot of trouble because the chances of a global uniform routing architecture are about zero. Different autonomous domains, universities, commercial carriers, federal agencies, companies,... will all implement these things differently. In addition, if you're some poor user whose campus has bought internetwork service from some SMDS carrier you want to have to know the internals of the carriers SMDS routing (which the carrier doesn't want to tell you anyways) like you want a hole in your head. What I think you do want is to be able to specify which administrative domains your packets go through and leave the internal routing to those domains. It is I suppose possible that in some cases you might want to be able to specify some internal points within a domain that allowed that,... and network monitoring will probably require that. So the issue seems to be the "coarseness" of the source route information. NOte that in this architecture the difference between a loose source route and a strict source route is not meaningful because the only difference could be whether all intermediate points are specified. In the California example: Go from LA to Oakland the best way you know; take 880 to Ashby Ave; Ashby to Shattuck;Shattuck to University; University to I80; Interstate Highways to Sacramento. There has also been discussion of querying route server or DNS by destination rather than reversing RHF. It seems to me that this might be a mistake because the specification of intermediate carrier could be differnet... ie destinatin campus uses MCI as internet carrier and source uses Sprint (examples fictitious). Whil this in principal would not affect connect- ivity it could affect performance and foul up accounting. Foe example, if the source has bought T3 internetwork services and the destination has bought internetwork service but T3 local service then the performance of both schemes will be very different to the user. Finally about options, we do not understand now the options we will need. However we could make some progress in defining option structure: fixed length, variable length, classes of default specification, so that we could add options later. Personally favor SMDS style option_header_flag, option_code,option_length, option_value,Option_trailer structure with perhaps several classes of option header flags... ignore if you don't understand, kill packet if you don't understand,...,etc. From owner-Big-Internet@munnari.oz.au Sat Aug 1 01:54:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01339; Sat, 1 Aug 1992 01:54:57 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207311554.1339@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01336; Sat, 1 Aug 1992 01:54:51 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 6654; Fri, 31 Jul 92 11:54:20 EDT Date: Fri, 31 Jul 92 11:50:23 EDT From: yakov@watson.ibm.com To: Christian.Huitema@sophia.inria.fr, tsuchiya@thumper.bellcore.com Cc: avalon@coombs.anu.edu.au, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: Host Identifier and Location Ref: Your note of Fri, 31 Jul 92 16:48:54 -0400 >the next thing we will see on the Internet is a generalization of some >form of loose source routing.... Hierarchical addressing/routing is nothing more than such a generalization. So, CIDR is in fact nothing more than loose source routing (which gets embedded into IP addresses assigned hierarchically). With multiple addresses (as was proposed by Paul Tsuchiya) you may get different loose source routes to the same destination. >if using source routing for simple access to mobile hosts, one has to give a >a path to the "hub" to which the host is attached. This is the essence of the IBM proposal on routing for Mobile Hosts (it uses IP Loose Source Route Option). Yakov Rekhter. From owner-Big-Internet@munnari.oz.au Sat Aug 1 02:32:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02092; Sat, 1 Aug 1992 02:32:29 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207311632.2092@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02089; Sat, 1 Aug 1992 02:32:24 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 31 Jul 1992 17:32:01 +0100 To: Tony Li Cc: tsuchiya@thumper.bellcore.com, Big-Internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal In-Reply-To: Your message of "Fri, 31 Jul 92 08:05:24 PDT." <9207311505.AA08052@cider.cisco.com> Date: Fri, 31 Jul 92 17:31:59 +0100 From: Zheng Wang >Hmmm... I think I have to disagree. For example, one of the things >that Deborah, Yakov and I have been mulling over is the concept of >computing policy routes over heterogeneous network layers. So you get >a route through domaints that speak: IPv4, CLNP, IPv7, IPv4. How >would Pip support this? It can't. How does Pip support packet >coloring (NOT QoS)? How would Pip express the concept of "you have >permission to dynamically recompute my policy route as long as you >...."? I think that you underestimate human (and especially your own) >creativity. The "forseeable" future is a very short time. Far less >than the 20 years that we expect this protocol to last, and much less >than the 100 years that we should be designing for. Clearly it is impossible to express all possible cases in the packet header. A simple solution might be: 1) to design a packet header for a set of common and simple cases so the hosts can do datagram-style of lookup-and-send. 2) and leave complicated/special cases to route setup/flow ID so the hosts have to wait the full route to be sorted out/set up before sending any packets. Zheng From owner-Big-Internet@munnari.oz.au Sat Aug 1 02:40:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02234; Sat, 1 Aug 1992 02:40:27 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02231; Sat, 1 Aug 1992 02:40:22 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA01732; Fri, 31 Jul 92 09:40:07 PDT Message-Id: <9207311640.AA01732@Mordor.Stanford.EDU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: smart@mel.dit.csiro.au, big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 29 Jul 92 02:29:44 -0400. <9207290629.AA08607@ginger.lcs.mit.edu> Date: Fri, 31 Jul 92 09:40:06 -0700 From: Dave Crocker This is in reply to a message you sent (on July 16) when we were going down the thread of my claim that it's wrong to design the address before yo u have done the routing architecture. Noel, The routing architecture for the postal service has changed quite a bit over the centuries, but the basic model of addressing hasn't changed all that much. Certainly the telephone addressing system was designed with topology in mind, but finding out that my calls from Washington to Boston were being routed through San Francisco suggests that there is quite a bit of decoupling from routing decisions. So, why is it mandatory to define the Internet routing architecture prior to specification of an addressing structure (on the theory that the addressing structure may be attentive to other factors such as administration of assignments and connection topology)? Dave From owner-Big-Internet@munnari.oz.au Sat Aug 1 03:04:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02733; Sat, 1 Aug 1992 03:04:26 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02728; Sat, 1 Aug 1992 03:04:18 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 31 Jul 92 12:56:19 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Fri, 31 Jul 92 12:56:17 EDT Date: Fri, 31 Jul 92 12:56:17 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207311656.AA03780@chiya.bellcore.com> To: clynn@BBN.COM, tsuchiya@thumper.bellcore.com Subject: Re: Host Identifier and Location Cc: big-internet@munnari.oz.au, pip@thumper.bellcore.com > > Folks, > > Have we agreed to accept the "CI" field for flow identification? If > so, it sounds like it ought to be positioned next to the source host > ID as that combination uniquely identifies the flow. > > Charlie Have I missed something? (I may have, because I've been out of commision last couple of weeks.) Last I heard on this topic was that there are concerns about scaling, and as a mechanism for making the routing lookup faster, I question the need for it in general. (I mean, I don't question that it is a faster routing lookup than more complicated addresses, but it hasn't been shown, for instance, that the routing lookup in Pip (the RD) is "too slow". PT From owner-Big-Internet@munnari.oz.au Sat Aug 1 03:15:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02923; Sat, 1 Aug 1992 03:15:47 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02920; Sat, 1 Aug 1992 03:15:42 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Fri, 31 Jul 92 10:15:16 -0700 Date: Fri, 31 Jul 92 10:15:16 -0700 From: Tony Li Message-Id: <9207311715.AA14183@cider.cisco.com> To: Z.Wang@cs.ucl.ac.uk Cc: tsuchiya@thumper.bellcore.com, Big-Internet@munnari.oz.au In-Reply-To: Zheng Wang's message of Fri, 31 Jul 92 17:31:59 +0100 <9207311632.AA10743@wolf.cisco.com> Subject: Route fragments, a routing proposal 2) and leave complicated/special cases to route setup/flow ID so the hosts have to wait the full route to be sorted out/set up before sending any packets. Setup alone cannot express all different types of routing algorithms. So, yes, we have to allow for setup, but we will still need the flexibility to do more... Tony From owner-Big-Internet@munnari.oz.au Sat Aug 1 03:15:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02951; Sat, 1 Aug 1992 03:16:03 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02939; Sat, 1 Aug 1992 03:15:57 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 31 Jul 92 13:13:54 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Fri, 31 Jul 92 13:13:51 EDT Date: Fri, 31 Jul 92 13:13:51 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207311713.AA03844@chiya.bellcore.com> To: Christian.Huitema@sophia.inria.fr, tsuchiya@thumper.bellcore.com Subject: Re: Host Identifier and Location Cc: avalon@coombs.anu.edu.au, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu > > It seems very clear that the next thing we will see on the Internet is a > generalization of some form of loose source routing. How loose is the routing will > be highly variable: > > * if doing ressource reservation, say for 140mbps full blast video, the source > should make pretty sure that the packets go on precisely the route on which > resource have been allocated. > > * if using source routing for policy obeidance, a very generic specification like > the "MIT>NEARnet>NSF>BARnet>Stanford" example of DDC is prefered: there may well > be many possible paths between NSF and BARnet, and the source has no real interest > in specifying which one. > > * if using source routing for simple access to mobile hosts, one has to give a > path to the "hub" to which the host is attached. But the way to that path may > remain largely unspecified. Yes. This is why the Pip Routing Directive structure is basicly a loose source route. It is because all these types of routing can be represented by a loose source route. > > It is very clear that we could use the host "unique identifiers" for specifying a > source route -- after all, we do that already in IPv4. It is obvious that No. IPv4, when used by routers, is not treated as an ID (except if the router is using it as a key to a hash function, but this is an optimization, not a fundamental aspect of IP). It is treated as a hierarchical address, which means that a router could route only on the "network" part, for instance. In this case, the fact that the same address is also a host ID is irrelavent. > using these identifiers has one big advantage -- easy to specify and understand -- > and one potentiel disadvantage -- huge headers. IMHO, this looks like a case for > variable length UI's: > > * short UI's for often used names, e.g. "NSF". > * long UI's (64?) for hosts. > * something in between for transit networks. You get these semantics out of the Pip RD (short "numbers" (although they are not UIs) for identifying backbones, areas, etc.) PT From owner-Big-Internet@munnari.oz.au Sat Aug 1 03:56:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03551; Sat, 1 Aug 1992 03:57:02 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03546; Sat, 1 Aug 1992 03:56:56 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Fri, 31 Jul 92 13:56:44 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Fri, 31 Jul 92 13:56:41 EDT Date: Fri, 31 Jul 92 13:56:41 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207311756.AA03920@chiya.bellcore.com> To: ddc@lcs.mit.edu, tsuchiya@thumper.bellcore.com Subject: Re: Question on Clark's route fragments Cc: Big-Internet@munnari.oz.au > I did not think that all AD identifiers would include net and host. > A net and host compontent is needed, but only once, to be used inside the > final AD. I agree that 4 byte AD identifiers might be fine. > I do not see why this complicates the routing process. I agree that the > router needs to know the context in which it is routing, but this is not a > big deal. It is like knowing if the packet is destined for a locally > attached net. I agree that it is not a big deal. > But the more important point, which was also coming up at the PIP BOF, > is that there are two different times at which a route needs to be > represened inside the system. One is the time at which topology information > is presented to the routing algorithm as input, with the objective of > computing the desired route. The second is when the packet is presented to > the router. The routes do not have to look the same at those two times. I have thought in these terms also. The routing protocol would pass around rather lenghty AD identifiers, and some mapping would occur to map them into smaller identifiers that the packets carry. > names that have local significance. To navigate in this space, PIP adds a > rather compex model of hierarchy, which lets you know when to go up, > sideways, or down. At the BOF, I was getting all messed up trying to see > where this was going. Imagine instead that AD have global names, and as well > each AD assigns a local name to each AD for which it maintains routing > knowledge. To compute the route, you use the global names. It does not > matter how big they are, since they are not going in a packet header. Then, > once you have found the intended route, you look up the local name which > each AD in the path has for the next AD in the path. You don't need any I see. The thing I envisioned had "big" and "small" identifiers, but both were global (except the small ones were only global in the context of a hierarchy level and parent). That is, any router that had a routing table entry for AD X would have the same small identifier. Yor are proposing that the identifiers be *truly* local to each AD. I agree that this has the advantage of making hierarchical "address" assignment easier (it basically disappears), but it has a real disadvantage, at least in the context of Pip. (By the way, address assignment in the context of Pip should be easier than current address assignment, because it is easier to deal with multiple addresses, and because you don't have to worry about running out of numbers at a certain level of the hierarchy and so on.) The disadvantage is that ADs must know the values chosen by other ADs to represent still other ADs. (I'm not assuming that the AD path in the packet header will necessarily contain every AD in the path. Some hop-by-hop routing is good.) As an example, if the path (and packet header content) is AD1-AD2-AD3-AD4, then the host that forms the packet must know AD1's value for AD2, AD2's value for AD3, and AD3's value for AD4. Either that, or each domain must remap ALL of the route fragment fields at each AD hop. That is, the original packet will contain AD1's values for AD2, AD3, and AD4, but when the packet leaves AD1, it must remap the values for all the ADs into what AD2 understands them to be. With current Pip, each AD only needs to worry about the field that is currently being working on, so processing is easier. > > These local names will have to stay bound to the global names for a long > time. This may seem a problem, but I don't think so. Anyway, the local names > in PIP have to keep their meaning in the same way. These local names could Yes. > actually be stored as additional information inside the route fragments, so > that once you have computed the route using the long names, you just take > the short names out of the same object you got from the "route fragment > server". But, as mentioned above, it seems that the "route fragment server" must know all ADs values for all other ADs. > > Now the additional twist is that we might do route setup and then use a CI, > so that even this "short-form" route does not have to be in each packet. But > I think the local names might well be as short as 2 bytes. (Rash, I know.) > I agree with 2 bytes. In general, though, I'm more comfortable with a packet header where the "worst case" processing is acceptable, rather than the CI case where the worst case processing is not acceptable, so you hope that you can get away with CI-only processing most of the time. PT From owner-Big-Internet@munnari.oz.au Sat Aug 1 04:02:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03616; Sat, 1 Aug 1992 04:02:51 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03612; Sat, 1 Aug 1992 04:02:43 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Fri, 31 Jul 92 14:02:35 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Fri, 31 Jul 92 14:02:33 EDT Date: Fri, 31 Jul 92 14:02:33 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207311802.AA03938@chiya.bellcore.com> To: tli@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: Route fragments, a routing proposal Cc: Big-Internet@munnari.oz.au > > Of course we cannot predict all of the future, but I believe that > Pip anticipates all current ideas for the "forseeable" future. (I > know, gag me with a spoon). > > Hmmm... I think I have to disagree. For example, one of the things > that Deborah, Yakov and I have been mulling over is the concept of > computing policy routes over heterogeneous network layers. So you get > a route through domaints that speak: IPv4, CLNP, IPv7, IPv4. How > would Pip support this? It can't. How does Pip support packet Sure. If you have to translate out of a Pip header into something else, then naturally you lose what Pip gave you. > coloring (NOT QoS)? How would Pip express the concept of "you have Pip supports packet coloring with the HD (handling directive) and RC (routing context) fields. These need not be QoS. > permission to dynamically recompute my policy route as long as you I wouldn't rule out that Pip can do this. Off hand, I can imagine RC values or even FTIF (forwarding table index fields) whose semantics are "you can change blah". We'd have to look at the specific thing you have in mind. > ...."? I think that you underestimate human (and especially your own) > creativity. The "forseeable" future is a very short time. Far less > than the 20 years that we expect this protocol to last, and much less > than the 100 years that we should be designing for. I agree that 20 years is further than forseeable, but if something can work into the forseeable future, it seems to me we have a better chance of getting it into the non-forseeable future than something that doesn't even get us into the forseeable future. > > Unless, of course, the other protocol has an extension/adaptation > mechanism which we can hack to carry the information that we want. Do you have the extension/adaptation mechanism designed? I'd like to see it. PT From owner-Big-Internet@munnari.oz.au Sat Aug 1 04:06:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03652; Sat, 1 Aug 1992 04:06:14 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207311806.3652@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03649; Sat, 1 Aug 1992 04:06:08 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0129; Fri, 31 Jul 92 14:05:38 EDT Date: Fri, 31 Jul 92 13:58:59 EDT From: yakov@watson.ibm.com To: tsuchiya@thumper.bellcore.com, clynn@BBN.COM, tsuchiya@thumper.bellcore.com Cc: big-internet@munnari.oz.au, pip@thumper.bellcore.com Subject: Host Identifier and Location Ref: Your note of Fri, 31 Jul 92 12:56:17 EDT While we may argue that flow setup may be useful in *certain* cases, I would suggest to avoid generalization of this to make the flow setup required for *all* cases. For one thing, if the flow setup is required for all the traffic the amount of state on the routers is likely to be large enough to guarantee impracticality of the whole scheme. In addition, it is far from obvious that flow setup is required for *all* the applications in the Internet to begin with. As a matter of fact, before jumping on the flow setup bandwagon we should look very carefully at what are the problems the setup is intended to solve, and whether there is any better way to solve these problems. In other words, rather than creating problem for a solution (where "a solution" is flow setup), we should be focusing on the solution to a problem (so, what is the problem ?). Yakov From owner-Big-Internet@munnari.oz.au Sat Aug 1 04:05:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03640; Sat, 1 Aug 1992 04:06:02 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03637; Sat, 1 Aug 1992 04:05:56 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Fri, 31 Jul 92 14:05:46 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Fri, 31 Jul 92 14:05:45 EDT Date: Fri, 31 Jul 92 14:05:45 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207311805.AA03950@chiya.bellcore.com> To: Big-Internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov, tsuchiya@thumper.bellcore.com Subject: Re: Route fragments, a routing proposal > > Finally about options, we do not understand now the options we will need. > However we could make some progress in defining option structure: > fixed length, variable length, classes of default specification, so > that we could add options later. Personally favor SMDS style > option_header_flag, option_code,option_length, option_value,Option_trailer > structure with perhaps several classes of option header flags... ignore > if you don't understand, kill packet if you don't understand,...,etc. > This seems worth exploring for Pip. Pip has options fields, but nothing has been said about them (except that I've thought of splitting them into "host" options, and "router" options, so that routers can ignore the host options, and vice versa. But, this seems to be just another variation of the above theme of partially-self-describing options. PT From owner-Big-Internet@munnari.oz.au Sat Aug 1 04:08:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03702; Sat, 1 Aug 1992 04:08:49 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03698; Sat, 1 Aug 1992 04:08:43 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Fri, 31 Jul 92 11:08:33 -0700 Date: Fri, 31 Jul 92 11:08:33 -0700 From: Tony Li Message-Id: <9207311808.AA27168@cider.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: tsuchiya@thumper.bellcore.com, Big-Internet@munnari.oz.au In-Reply-To: Paul Tsuchiya's message of Fri, 31 Jul 92 14:02:33 EDT <9207311802.AA03938@chiya.bellcore.com> Subject: Route fragments, a routing proposal Do you have the extension/adaptation mechanism designed? I'd like to see it. No, not at all. But then again, I'm not proposing a new protocol... ;-) Tony From owner-Big-Internet@munnari.oz.au Sat Aug 1 04:23:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04051; Sat, 1 Aug 1992 04:23:48 +1000 (from owner-Big-Internet) Return-Path: Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04048; Sat, 1 Aug 1992 04:23:40 +1000 (from VALDIS@vtvm1.cc.vt.edu) Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 3851; Fri, 31 Jul 92 14:22:22 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 7478; Fri, 31 Jul 92 14:22:22 EDT Date: Fri, 31 Jul 92 14:21:08 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Route fragments, a routing proposal To: Tony Li , tsuchiya@thumper.bellcore.com Cc: Big-Internet@munnari.oz.au In-Reply-To: <9207310607.AA28516@cider.cisco.com> Message-Id: <920731.142108.EDT.VALDIS@vtvm1.cc.vt.edu> On Thu, 30 Jul 92 23:07:56 -0700 you said: >Lest anyone accuse me of being creative, please note that this is just >a transliteration of Unix design philosophy: Small and extensible is >beautiful. I hope that this appeals to at least the gentleman from >Bellcore... ;-) In the 1980's, the big issue was "Kernel Bloat" Will the big issue for the 1990's be "IP Header Bloat"? Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Sat Aug 1 04:40:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04254; Sat, 1 Aug 1992 04:40:14 +1000 (from owner-Big-Internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04251; Sat, 1 Aug 1992 04:40:06 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA01746 (5.65/1.23); Fri, 31 Jul 92 14:39:40 -0400 Date: Fri, 31 Jul 92 14:39:40 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9207311839.AA01746@sadye.emba.uvm.edu> To: Tony Li Cc: Big-Internet@munnari.oz.au, Z.Wang@cs.ucl.ac.uk, tsuchiya@thumper.bellcore.com Subject: Route fragments, a routing proposal In-Reply-To: <9207311715.AA14183@cider.cisco.com> References: <9207311632.AA10743@wolf.cisco.com> <9207311715.AA14183@cider.cisco.com> On Fri, 31 Jul 92 10:15:16 -0700, Tony Li said: > Setup alone cannot express all different types of routing algorithms. > So, yes, we have to allow for setup, but we will still need the > flexibility to do more... I thought the point was that, by pushing these things off to a separate protocol (a `flow setup protocol' which has yet to be defined), you could have the flexibility to make changes in your flow setup capabilities without worrying about making major changes to hosts. I believe (hope) that we can all agree that there will be more routers than hosts, right? Let's say you wanted to implement some really strange criteria in your flow setup. So, you go out and develop MFTFSP (My Favo[u]rite Toy Flow-Setup Protocol), and teach it to your host and a few routers in your area. If we make the flow-setup architecture general enough, then the last-hop router can tell the end system ``I have a flow number abcdef for you, from host a.b.c.def.gh.ijk'', without the end system having to understand the strange criteria under which the flow was established. And you can do all of this without making any changes to the basic packet format, once the generic ability to identify flows has been built in. To pick an analogy in today's Internet, I can send an IPv4 packet from here to Lawrence Livermore, without caring that the route to get there was developed through an unwieldy combination of RIP, IGRP, BGP (or is it still EGP on that link), OSPF, and probably others. If and when some other protocol gets implemented somewhere in between here, I not only *don't have to know* what it is and how it works, I don't even have any *way to find out*. -GAWollman -- Garrett A. Wollman = wollman@emba.uvm.edu = UVM is welcome to my opinions = uvm-gen!wollman = That's what being alive is all about. No deity, no higher goal exists, than to bring joy to another person. - Elf Sternberg From owner-Big-Internet@munnari.oz.au Sat Aug 1 05:16:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04843; Sat, 1 Aug 1992 05:16:38 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04840; Sat, 1 Aug 1992 05:16:32 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27803; Fri, 31 Jul 92 15:15:38 -0400 Date: Fri, 31 Jul 92 15:15:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207311915.AA27803@ginger.lcs.mit.edu> To: Z.Wang@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: Host Identifier and Location Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The current Internet does not provide a binary equivalent of domain name simply because it is not carried by the packets. So what? The DNS name *still* has attributes that are not good for an identifier, such as variable length, etc. Pip includes Host IDs from the very first version. Yes, but they weren't mandatory in every packet at first. But the point is that the Host IDs are not used for forwarding. I have a messsage here from Paul where he assured me that you could forward based on the ID. Does the packet contains both Host IDs and the new type of address??? Who cares? Some will, some won't. This is a low level engineeering detail of no relevance, to be decided when detailed specs are written. Okay, I should have used forwarding instead of routing. Precise language is very necesssary here if we expect everyone to understand what we are saying. Noel From owner-Big-Internet@munnari.oz.au Sat Aug 1 05:25:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04928; Sat, 1 Aug 1992 05:25:13 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04925; Sat, 1 Aug 1992 05:25:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27833; Fri, 31 Jul 92 15:25:02 -0400 Date: Fri, 31 Jul 92 15:25:02 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207311925.AA27833@ginger.lcs.mit.edu> To: desjardi@boa.gsfc.nasa.gov, jnc@ginger.lcs.mit.edu Subject: Re: Host identifier length Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu they're more long-term solution oriented. That's good: we have to get that right. But we also have to operate in the mid-term. I understand and agree heartily with that sentiment. The problem I have is that without a sound idea of where you are going to wind up, it's hard to evaluate whether intermediate steps are getting you closer to that destination or not. I happen to believe that I have a good idea (for reasons of fundamentals) where we are going to have to go, and think that a lot of the ideas I hear on what the intermediate steps ought to be don't make sense to me in the light of that long-term view. I'll have to take a while to respond to your comments on the Host Location part of my suggestions. I await your comments! Noel From owner-Big-Internet@munnari.oz.au Sat Aug 1 05:46:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05191; Sat, 1 Aug 1992 05:46:12 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05185; Sat, 1 Aug 1992 05:46:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28126; Fri, 31 Jul 92 15:45:12 -0400 Date: Fri, 31 Jul 92 15:45:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207311945.AA28126@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, oran@sneezy.lkg.dec.com Subject: Re: Host Identifier and Location Cc: big-internet@munnari.oz.au, colella@osi.ncsl.nist.gov, desjardi@boa.gsfc.nasa.gov, dkatz@cisco.com, jnc@ginger.lcs.mit.edu, medin@nsipo.nasa.gov Many maps have big black spots on them. Maps published in the US had big black spots where the Soviet Union is (was) during the 1930s. If you buy this argument, then link state can't be used for interdomain routing, since the raw (even aggregated versions of the raw) information can't be globally distributed. I think you disproved your point with your own example, no? In fact, this exact policy requirement was one of the ones considered by the Open Routing WG when we classified policy restrictions. (You will find it described as 'information hiding' in section 2.2 of Nimrod.) The way you do it in an LS system is exactly the way the Soviet Union did it for real; detailed maps of the stuff you want to hide are military secrets, and not everyone can get at that detail. Noel From owner-Big-Internet@munnari.oz.au Sat Aug 1 07:21:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09327; Sat, 1 Aug 1992 07:21:44 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207312121.9327@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09321; Sat, 1 Aug 1992 07:21:37 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5799; Fri, 31 Jul 92 17:21:04 EDT Date: Fri, 31 Jul 92 17:08:27 EDT From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu, jnc@ginger.lcs.mit.edu, oran@sneezy.lkg.dec.com Cc: big-internet@munnari.oz.au, colella@osi.ncsl.nist.gov, desjardi@boa.gsfc.nasa.gov, dkatz@cisco.com, jnc@ginger.lcs.mit.edu, medin@nsipo.nasa.gov Subject: Host Identifier and Location Ref: Your note of Fri, 31 Jul 92 15:45:12 -0400 The discussion about LS as the panacea for all problems in routing in general, and in inter-domain routing in particular reminds me of an attempt to find a problem to a solution (where LS is a solution). A more rational approach would be to look at the solution to the problem. LS is not the most efficient way to implement inter-domain routing (for more details explanation see RFC1322). So far, the only attempt to use LS for inter-domain routing is IDPR, and the protocol provides *NO* support for information aggregation above the domain level. So, if the purpose of this list is to look at a scalable technique for inter-domain routing, then proponents of the LS should put specific proposals on how to deal with information aggregation/abstraction, and what are the implications of doing this on: (a) source policies (b) transit policies (c) flexibility in aggregation/abstration. Yakov Rekhter. From owner-Big-Internet@munnari.oz.au Sat Aug 1 08:20:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10847; Sat, 1 Aug 1992 08:21:04 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10844; Sat, 1 Aug 1992 08:20:52 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29873; Fri, 31 Jul 92 18:20:35 -0400 Message-Id: <9207312220.AA29873@ginger.lcs.mit.edu> To: Paul Tsuchiya Cc: ddc@lcs.mit.edu, Big-Internet@munnari.oz.au Subject: Re: Question on Clark's route fragments In-Reply-To: Your message of Fri, 31 Jul 92 13:56:41 -0400. <9207311756.AA03920@chiya.bellcore.com> From: David Clark Date: Fri, 31 Jul 92 18:20:34 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp Paul, I thik we understood each other. I was assuming that it was not a big deal to ask AD1 to tell you its name for AD2, since this would happen at the time you put the route fragment together, which is a really background sort of thing. There could be a special sort of packet, which you send into the network, with the global form of the AD route fragment, and each AD along the way would fill in the local form that it would like you to use for the thing that it is going to route to. Then you get it back and remember it. Dave From owner-Big-Internet@munnari.oz.au Sat Aug 1 09:13:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12013; Sat, 1 Aug 1992 09:13:25 +1000 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12007; Sat, 1 Aug 1992 09:13:03 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17956; Fri, 31 Jul 92 16:12:53 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA00548; Fri, 31 Jul 92 16:12:57 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA20709; Fri, 31 Jul 92 16:12:33 PDT Date: Fri, 31 Jul 92 16:12:33 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9207312312.AA20709@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA22471; Fri, 31 Jul 92 16:12:47 PDT To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au In-Reply-To: <9207312121.9327@munnari.oz.au> Subject: Host Identifier and Location Yakov, I agree with your statement about finding solutions for a problem instead of having a solution and looking for problems. But, for the rest of your message, I think you are mixing a specific implementation of an algorithm with what can be done with the algorithm in general. Sort of like making an argument about the limits of distance vector algorithms by using the original Arpanet DV implementation as the example, and ignoring what has been done with BGP4 or IDRP. Bob From owner-Big-Internet@munnari.oz.au Sat Aug 1 14:30:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19229; Sat, 1 Aug 1992 14:30:30 +1000 (from owner-Big-Internet) Return-Path: Received: from wilbur.nas.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19223; Sat, 1 Aug 1992 14:30:15 +1000 (from lekash@nas.nasa.gov) Received: by wilbur.nas.nasa.gov (5.61/1.34) id AA18986; Fri, 31 Jul 92 21:29:55 -0700 Date: Fri, 31 Jul 92 21:29:55 -0700 From: lekash@nas.nasa.gov (John Lekashman) Message-Id: <9208010429.AA18986@wilbur.nas.nasa.gov> To: dcrocker@Mordor.Stanford.EDU Cc: big-internet@munnari.oz.au In-Reply-To: Dave Crocker's message of Fri, 31 Jul 92 09:40:06 -0700 <9207311640.AA01732@Mordor.Stanford.EDU> Subject: Route fragments, a routing proposal Dave, the discussion below is one of the reasons argument by analogy is often the wrong thing. There are many differences between postal, telephone, and network service. The routing architecture for the postal service has changed quite a bit over the centuries, but the basic model of addressing hasn't changed all that much. For the following reasons: 1. Not enough major earthquakes, volcanos, tidal waves occur to markedly change the planet's surface structure every couple of weeks. 2. The postal service still does what it did when it started, deliver physical objects from place to place. The only changes have been in transport, as we got faster modes. Please note that we don't need different network addresses for 56 kbps lines and 800 Mbps HPPI channels, 4 orders difference in speed. The post has only gone from 6 mph (slow horses) to 600 mph (planes). Speed isn't the only thing going on here. 3. The focus on physical objects causes all sorts of things. There is easy, timely, out of band control (telephone address lookup) There are admin domains, (countries, states, provinces, ...) already grandfathered in. Rerouting can be done on the fly, as it were, by looking around for a street sign. The time scale is very different. Certainly the telephone addressing system was designed with topology in mind, but finding out that my calls from Washington to Boston were being routed through San Francisco suggests that there is quite a bit of decoupling from routing decisions. Not at all. All that is being decoupled is an implicit statement by you that perhaps San Francisco is a sub-optimal route from Washington to Boston. Perhaps it was good for the phone company that week, due to a backhoe in New Jersey cutting the direct underground line, and they used a satellite to San Francisco for restoration. So, why is it mandatory to define the Internet routing architecture prior to specification of an addressing structure (on the theory that the addressing structure may be attentive to other factors such as administration of assignments and connection topology)? Largely because there are a lot of things to be expected from the routing architecture, and some aren't even defined yet. Dealing with explosive growth; frequent, dynamic topology change; path characterization; multiple delivery modes; (Just see if you can give one copy of a letter to the post office, and say you want it delivered to these 57 addresses) and so on. The addressing architecture we mostly expect to be something that doesn't cause irritation. I really don't much care what the address actually is, as long as I can manage the traffic flows, now and in the future. Mostly I want an address structure with three properties: 1. There is enough space so we can sparsely address every particle in the known universe, so chicken little can never complain about the sky falling again. 2. The address space is really easy to deal with in a routing and control sense. 3. There is no hierarchy inherent in the static address, so that bureaucratic fumblebutts can't assert that they are in charge of addresses and won't let anyone have one until they face due north and bow three times to Arachnid, the god of burnt toast. (or similar nonsense). Hierarchy appears on the fly, in the live routed systems, via any of a variety of flow setup, lightweight virtual circuits, route path fragments, or whatever scheme happens to be the right thing. john From owner-big-internet@munnari.oz.au Sun Aug 2 00:23:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01193; Sun, 2 Aug 1992 00:23:52 +1000 (from owner-big-internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28331; Sat, 1 Aug 1992 22:34:39 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA02416 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 1 Aug 1992 22:34:53 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA10973; Sat, 1 Aug 92 22:34:35 EST Message-Id: <9208011234.AA10973@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: Some comments/queries on PIP In-Reply-To: Your message of "Fri, 31 Jul 92 13:38:40 +1000." <28447.712553920@munnari.oz.au> Date: Sat, 01 Aug 92 22:34:33 +1000 From: Bob Smart Robert Elz writes: >I fully support carrying src & dst ID's in every packet - if >Noel's recent message is correct (and I've just seen Paul's >confirmation), this is no longer an issue. Does anybody else have the vague feeling that the separation of ID from address should be accompanied by a protocol layer separation? I.e. that there should be a routing layer that has the address, and above that an authentication/security/ accounting/whatever layer that has the IDs. The routing layer could be used to transport other sorts of things as well: to IP4 and CLNP it might look like a funny sort of link layer (with multiple networks on it and short-cut routing I guess). >I strongly believe that fragmentation is necessary I strongly agree. Partly because it is required by Noel's scheme for allowing IP4 hosts to keep working as long as IDs stay within 32 bits. When you get an IP4 packet and you want to convert/encapsulate it you are likely to make the header bigger, so have less room for data, and so sometimes have to fragment. And if you are going to convert rather than encapsulate (much better for various reasons) you need to handle already fragmented packets. However the main reason we need fragmentation in IPv7 is that existing higher level software depends on it. It is easy to say that higher level software should do MTU discovery and do its own optimal fragmentation on that basis. Yes we should encourage that, but is this the moment in history to demand it? The transition will cause enough problems. We want people to be able to upgrade their applications and libraries with a few small changes. To do this we have to allow network layer fragmentation to continue. Because we don't see fragmentation as existing in the long term it should be implemented as an option so it doesn't normally take space in a packet header. [I have only seen announcements for 2 WGs, TUBA and PIP. The IESG specified July for the formation of such groups, but I presume we will see a late announcement for IPAE. Any others? Anyway TUBA, PIP and IPAE are the detailed proposals which I consider below.] The only one of the 3 proposals which has fragmentation is TUBA/CLNP. Perhaps the IAB were on to something. What about IPAE, doesn't that have fragmentation automatically because it uses the IP4 header and only adds to it? Wrong. Consider: IPAE-host ------- IP4-router ------ IPAE-border-router ----> Suppose the IPAE-host sends an IPAE packet along this path. The IP4-router knows nothing about IPAE and decides to fragment the packet. The packet is now in two. Fragment1 has the IPAE extended header, but Fragment2 doesn't. In fact the IPAE-border-router _must_ defragment that packet itself before it can forward it. If the resulting packet is too big to send the IPAE-border-router can't use IP4 fragmentation on the packet: it can only send packets into the big bad IPAE world that have IPAE extended addresses in them. And clearly the meaning of the IP4 fragmentation doesn't handle that. I submit that we can't use the same fragmentation fields for two very different and incompatible forms of fragmentation. This, and Craig Partridge's comments about difficulties with ICMP packets in IPAE, show that the IPAE scheme is not as simple as it makes out. And commonwealths will have to keep splitting up as they run out of IP4 address space internally. But my main concern about IPAE is that the core part of the Network, i.e. America, will get to keep going by reusing our IP4 addresses so we can't talk to them that way. They will also not be under great pressure to implement IPAE so we won't be able to talk to them that way. If we are going to fragement the Internet [and I'd rather not] then it will be better to fragment in the obvious way between old and new and put everyone under equal pressure to make "new" work. >For the semantics to be understood, there's going to need to >be agreements reached amongst the implementors of the routers I guess we need WKRCs (Well Known Routing Contexts). As I understand it the initial implementation of Basic PIP will only use a small number of WKRCs to correspond to a routing architecture which is more-or-less identical to the current net/subnet/host scheme but with one or two extra levels of hierarchy. Because of this the current routing protocols would be applicable with minor modification. Is that right? Bob Smart From owner-Big-Internet@munnari.oz.au Sun Aug 2 00:36:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01301; Sun, 2 Aug 1992 00:37:05 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9208011437.1301@munnari.oz.au> Received: from PIZZA.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01296; Sun, 2 Aug 1992 00:36:56 +1000 (from msteenst@BBN.COM) To: oran@sneezy.lkg.dec.com Cc: big-internet@munnari.oz.au Subject: black spots Date: Sat, 01 Aug 92 10:31:24 -0400 From: Martha Steenstrup hi dave, i am having trouble understanding why you believe that distance vector algorithms are good for information hiding while link state algorithms are bad for information hiding. both distance vector and link state algorithms are capable of restricting distribution of routing information. with distance vectors, restricted distribution of routing information is inherent in the distance vector distribution algorithm. not so with link states which are often globally distributed (through flooding, for example). however, there is no reason that link state information cannot also be distributed in a directed fashion (through source routing to selected destinations, for example). in fact, this is exactly how IDPR restricts distribution of routing information to selected domains. in the link state case, restricted distribution of link state information results in inconsistent routing databases maintained by different domains. hence, one cannot rely on hop-by-hop message forwarding to be loop-free. therefore, one must apply source-specified data message forwarding to prevent looping. IDPR uses source-specified message forwarding partly for this reason and partly because differences in routing databases are inherent with IDPR. in particular, sources may have routing preferences that they wish to keep private (often termed "source-specific policies"). hence, other domains cannot make the correct forwarding decisions for traffic from individual sources, because they do not have the proper information. note that the current distance vector algorithms do not support source-specific policies. perhaps i've misunderstood your argument. m From owner-big-internet@munnari.oz.au Sun Aug 2 14:06:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26537; Sun, 2 Aug 1992 14:06:58 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25385; Sun, 2 Aug 1992 13:16:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01718; Sat, 1 Aug 92 23:15:30 -0400 Date: Sat, 1 Aug 92 23:15:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208020315.AA01718@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, oran@sneezy.lkg.dec.com, yakov@watson.ibm.com Subject: Re: Host Identifier and Location Cc: big-internet@munnari.oz.au, colella@osi.ncsl.nist.gov, desjardi@boa.gsfc.nasa.gov, dkatz@cisco.com, jnc@ginger.lcs.mit.edu, medin@nsipo.nasa.gov The discussion about LS as the panacea for all problems in routing in general, and in inter-domain routing in particular reminds me of an attempt to find a problem to a solution (where LS is a solution). Yakov, I've personally seen many instances in the history of computer science of this error being comitted, so I don't understate the danger of it! What you may not realize is that at a time which is now a while ago (like mid 80's, I think?), I too preferred DV for large scale routing because of what seemed to me like an obvious aggregation algorithm with "optimal" routing. I was argued out of this at a meeting with Lixia and John Moy (which they may recall :-) at MIT, in room 539 (or so :-). The reasons they gave don't particularly matter, as I believe that in the interim even more powerful ones have been discovered. (We can cover these in subsequent debate in whatever level of detail anyone wants to hget into; I don't want to make this message so long everyone discards it as another unreadable Noelgram! :-) I suppose that it's possible, as commonly happen with religions, that the "converts" are more fervent than the people who are brought up in it, as it were. Still, I changed to LS for a long series of rational reasons, and a long time ago. It's also worth noting that after a question to the list from Jon Postel, I found out that this supposed 'optimal' algorithm is in fact not to optimal as I though, but I won't rehash that. (Anyone who cares can find it in the Big-I archives for April, 1992.) It turns out (not exactly to my suprise) that both DV and LS algorithms seem to have the same fundamental limits when it comes to handling abstraction, but LS (as detailed below) gives you more flexibility in how you tackle this 'unsolvable' problem. LS is not the most efficient way to implement inter-domain routing So? Even granting this for the sake of argument (and I'm not sure I agree with this statement), as I've said before, efficiency is not the only consideration in computer science. If it were, we'd all still be programming in assembly language. Other things, such as robustness, flexibility (which maximizes design lifetime, perhaps most critical of all goals for a large system), etc, are also critical, and play their part in a overall engineering solution which considers entire life-cycle costs. In area of routing area, there are other specific technical goals like stabilization time, etc. So, efficiency alone is not the last word, and when I consider the *system* benefits of the LS approach, I consider it much superior. So far, the only attempt to use LS for inter-domain routing is IDPR, and the protocol provides *NO* support for information aggregation above the domain level. Yes, and this was a concious decision on the part of the people doing the work (at BBN, and maybe elsewhere) to limit the scope of their work, in reponse to pressure from their funding agency to get something up and working. This is not a hypothesis; I personally sat in a meeting with people from BBN and DARPA some years back at which this very tradeoff was rationally discussed and chosen. As we have discussed before, I too find this aspect of IDPR very limiting, and it's the reason I haven't paid much attention to the IDPR work; I've been thinking about how to add abstraction mechanisms to the basic LS model, and believe I have some important results to show in the Nimrod work. proponents of the LS should put specific proposals on how to deal with information aggregation/abstraction, and what are the implications of doing this on: (a) source policies (b) transit policies (c) flexibility in aggregation/abstration. Yakov, I have considered this most deeply and at very great length, for years. We used to think (in the early 80's) that policy routing was the 'hard' problem in routing, and abstraction was easier. It has been clear to me for some time now that in fact the order is reversed, and policy routing is in fact easy compared to abstraction. Deborah and Dave Clark, I am sure, can tell you of diagrams I have been drawing for years in an attempt to understand these issues, and also how long ago I worked on things like the "blister model" (now called Local Abstraction Control in Nimrod) to answer these problems. My conclusions (as stated in the Nimrod document) are that there are no 'neat' solutions. In too many cases, 'abstraction' (terms defined in section 3 of Nimrod) can only be done by 'thinning', and the consequent loss of information produces either sub-optimal routes, or no route at all which meets the policy requirements. (There is more discussion on this topic at the end of 3.2 in Nimrod, and it was covered in some detail in the Atlanta IETF presentation on Nimrod.) As I alluded to above, this is a fundamental truth about routing in general, I believe, and not limited to DV or LS architecture; I believe *any* routing architecture would show these fundamental limits. (Think of it as the equivalent of the Law of Thermodynamics of routing.) Anway, given this nasty truth, as an engineer I have come to two conclusions: - First, the decision as to what routing information to discard when you do abstraction is a policy decision, not a technical one, and there is no such thing as an 'optimal' algorithm for this. Any routing architecture must provide for human input into this decision, and also for different 'semi-automatic' algorithms to meet different classes of operational requirement. (Section 5.4 covers this in more detail.) - Second, users have to have a means available to defeat the abstraction, if they find the cost of the non-optimal routes is more important to them than the cost of running the routing protocol. As I alluded to, there is an unavoidable tradeoff between these, and I don't see it as the job of an archiect to pick a particular setting of this tradeoff, but rather to provide the users the means to make the choice themselves (provided, of course, adding this mechanism is not in itself too costly, but I don't believe the one in Nimrod is so). (Section 4.2.3 covers this in more detail.) Anyway, I appreciate your concern for abstraction; I know this has not been the hottest topic on this list, but I agree with your focus upon it. However, everyone needs to realize that abstraction, which is unavoidable, produces certain unavoidable costs. This is equally true of LS DV, and any other routing systems. These costs can no more be avoided than you can make entropy diminish. LS systems, in my opinion, simpy provide you with better tools to struggle with these hard problems. Noel From owner-big-internet@munnari.oz.au Mon Aug 3 12:51:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23045; Mon, 3 Aug 1992 12:52:03 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21117; Mon, 3 Aug 1992 11:50:10 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sun, 2 Aug 92 21:49:53 EDT Received: by chiya.bellcore.com (4.1/4.7) id for jnc@ginger.lcs.mit.edu; Sun, 2 Aug 92 21:49:52 EDT Date: Sun, 2 Aug 92 21:49:52 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208030149.AA05497@chiya.bellcore.com> To: Z.Wang@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: Host Identifier and Location Cc: big-internet@munnari.oz.au > > But the point is that the Host IDs are not used for forwarding. > > I have a messsage here from Paul where he assured me that you could > forward based on the ID. > Huh? Could I see that message. My intent is that forwarding doesn't take place on the ID. PT From owner-big-internet@munnari.oz.au Mon Aug 3 13:55:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24842; Mon, 3 Aug 1992 13:55:37 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21734; Mon, 3 Aug 1992 12:11:20 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Sun, 2 Aug 92 22:11:04 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Sun, 2 Aug 92 22:11:04 EDT Date: Sun, 2 Aug 92 22:11:04 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208030211.AA05555@chiya.bellcore.com> To: ddc@lcs.mit.edu, tsuchiya@thumper.bellcore.com Subject: Re: Question on Clark's route fragments Cc: Big-Internet@munnari.oz.au > > Paul, > I thik we understood each other. I was assuming that it was not a big > deal to ask AD1 to tell you its name for AD2, since this would happen at the > time you put the route fragment together, which is a really background sort > of thing. There could be a special sort of packet, which you send into the > network, with the global form of the AD route fragment, and each AD along > the way would fill in the local form that it would like you to use for the > thing that it is going to route to. Then you get it back and remember it. > It occured to me that having the up/down/none bits in the route fragment fields is nothing more than a form of local identifier for another AD. However, rather than the identifier being a completely arbitrary local identifier, as you propose, it is predictable and easy to pass around in DNS, so you don't have the extra setup packet. By the way, do you have a particular problem with the up/down/none stuff? Before you mentioned complexity, but I don't see why it is particular complex. PT From owner-big-internet@munnari.oz.au Mon Aug 3 14:39:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26038; Mon, 3 Aug 1992 14:39:43 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22325; Mon, 3 Aug 1992 12:30:20 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Sun, 2 Aug 92 22:28:50 EDT Received: by chiya.bellcore.com (4.1/4.7) id for smart@mel.dit.csiro.au; Sun, 2 Aug 92 22:28:50 EDT Date: Sun, 2 Aug 92 22:28:50 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208030228.AA05616@chiya.bellcore.com> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: Some comments/queries on PIP > > Does anybody else have the vague feeling that the separation > of ID from address should be accompanied by a protocol layer > separation? I.e. that there should be a routing layer that > has the address, and above that an authentication/security/ > accounting/whatever layer that has the IDs. The routing layer > could be used to transport other sorts of things as well: to > IP4 and CLNP it might look like a funny sort of link layer > (with multiple networks on it and short-cut routing I guess). I have had this vague feeling also, and my original Pip header had all of the non-router stuff after the router stuff (so, it was sort-of like two layers). But, I can imagine any number of reasons that a router might want to look at the ID field (although still not for forwarding), for instance for billing of filtering. So, now I'm thinking of putting the IDs before the routing directive. > > However the main reason we need fragmentation in IPv7 is that > existing higher level software depends on it. It is easy to say > that higher level software should do MTU discovery and do its > own optimal fragmentation on that basis. Yes we should encourage > that, but is this the moment in history to demand it? The > transition will cause enough problems. We want people to be > able to upgrade their applications and libraries with a few > small changes. To do this we have to allow network layer > fragmentation to continue. I'm interested in seeing lots of opinions on this issue. At the Pip bof, I asked for a show of hands for people that thought fragmentation should and should not be in Pip. Opinions were split about 50/50. Perhaps the answer is to have both fragmentation AND discovery, so that as applications implement discovery, fragmentation occurs less and less. > > Because we don't see fragmentation as existing in the long term > it should be implemented as an option so it doesn't normally > take space in a packet header. Interesting idea. > > I guess we need WKRCs (Well Known Routing Contexts). As I > understand it the initial implementation of Basic PIP will > only use a small number of WKRCs to correspond to a routing > architecture which is more-or-less identical to the current > net/subnet/host scheme but with one or two extra levels of > hierarchy. Because of this the current routing protocols > would be applicable with minor modification. Is that right? BGP4 and OSPF needs only minor modification, because they can deal with general bit masks. Routing protocols that assume class A/B/C structure may not be as simple to modify. Hopefully there will be internet-drafts on changes to BGP4 and OSPF for basic Pip quite soon. PT From owner-Big-Internet@munnari.oz.au Mon Aug 3 22:17:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07146; Mon, 3 Aug 1992 22:17:41 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA07143; Mon, 3 Aug 1992 22:17:28 +1000 (from huitema@mitsou.inria.fr) Received: from mitsou.inria.fr by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA02596; Mon, 3 Aug 92 08:11:18 -0400 Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA23001; Mon, 3 Aug 1992 14:02:51 +0200 Message-Id: <199208031202.AA23001@mitsou.inria.fr> To: David Clark Cc: Paul Tsuchiya , Big-Internet@munnari.oz.au Subject: Re: Question on Clark's route fragments In-Reply-To: Your message of "Fri, 31 Jul 92 11:02:03 EDT." <9207311502.AA25477@ginger.lcs.mit.edu> Date: Mon, 03 Aug 92 14:02:51 -0400 From: Christian Huitema X-Mts: smtp >These local names will have to stay bound to the global names for a long >time. This may seem a problem, but I don't think so. Anyway, the local names >in PIP have to keep their meaning in the same way. These local names could >actually be stored as additional information inside the route fragments, so >that once you have computed the route using the long names, you just take >the short names out of the same object you got from the "route fragment >server". > >Now the additional twist is that we might do route setup and then use a CI, >so that even this "short-form" route does not have to be in each packet. But >I think the local names might well be as short as 2 bytes. (Rash, I know.) If the local names have to be long lived, what would be the cost of making them globally unique? UUCP started with this kind of "locally significant names", and steadily evolved towards "globally unique names". Unique names have a number of advantages, e.g. that you dont have to invent them, and that you can rework the routes "on the fly". In short, it enables a much looser form of routing. How long do unique names have to be? It seems that most transit networks already have a globally unique class A or class B address, at worst a class C. If we just state that address (no host info), then one get a variable length self describing 1 to 3 byte identifier! Christian Huitema From owner-Big-Internet@munnari.oz.au Mon Aug 3 22:51:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08069; Mon, 3 Aug 1992 22:51:39 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9208031251.8069@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08065; Mon, 3 Aug 1992 22:51:27 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3104; Mon, 03 Aug 92 08:50:51 EDT Date: Mon, 3 Aug 92 08:51:17 EDT From: yakov@watson.ibm.com To: msteenst@bbn.com Cc: big-internet@munnari.oz.au, oran@sneezy.lkg.dec.com Subject: black spots >i am having trouble understanding why you believe that distance vector >algorithms are good for information hiding while link state algorithms >are bad for information hiding. Both distance vector and link state >algorithms are capable of restricting distribution of routing >information. For those on the list who are interested in looking at *technical* arguments why distance vector is more suitable for information hiding I would suggest to read RFC1322. While both distance vector and link state are capable of restricting distribution of routing information, the capabilities are different. With distance vector you have more flexible mechanisms with less preconditions, as compared to the link state. >current distance vector algorithms do not support source-specific >policies. That is certainly an unsubstantiated claim. BGP does not require domains to exchange their source policies. Each domain can choose its routes based on local to the domain's criteria. Claim that IDPR supports source-specific policies needs to be qualified. IDPR supports source-specific policies AS LONG AS such policies and the amount of information the domain needs to deal with do not involve algorithms with high space and/or computational complexity. >In the link state case, restricted distribution of link state >information results in inconsistent routing databases maintained >by different domains. Hence, one cannot rely on hop-by-hop message >forwarding to be loop-free. Therefore, one must apply source-specified >data message forwarding to prevent looping. You just pointed out to one of the reasons why distance vector algorithms are better than link state for information hiding. Link state leaves you no options, but require to use source-specified forwarding. With distance vector you can do both. Importance of hop-by-hop forwarding, combined with hierarchical routing should not be underestimated, especially in view of scaling issues in inter-domain routing. Or may be there are just few "hot-spots" and we should ignore them for now ? Yakov From owner-Big-Internet@munnari.oz.au Mon Aug 3 23:22:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08806; Mon, 3 Aug 1992 23:23:00 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9208031323.8806@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08803; Mon, 3 Aug 1992 23:22:48 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3844; Mon, 03 Aug 92 09:22:18 EDT Date: Mon, 3 Aug 92 09:22:44 EDT From: yakov@watson.ibm.com To: hinden@eng.sun.com Cc: big-internet@munnari.oz.au Subject: Host Identifier and Location Bob >I think you are mixing a specific implementation of an algorithm >with what can be done with the algorithm in general. Sort of like >making an argument about limits of distance vector algorithms by >using the original Arpanet DV implementation as the example, and >ignoring what has been done with BGP4 or IDRP. As you correctly pointed out, arguments about limitations of distance vector based on the ARPANET DV implementations are incorrect *because* we already have DV protocols that addresses and solved these limitations. Situation with LS is very different. There is a great disparity between what is promised by the IDPR architecture and what is delivered by the IDPR protocol. And that is precisely why your analogy failed. In absence of any specific proposals it is hard to have *technical* arguments about what can be done with an algorithm in general. Of course, we can all waive our hands and just hope that in due time the proper algorithms with suitable complexity (to make the whole thing practical) will be developed to realize the full IDPR architecture. But, it is all subject of future research. And, by definition of what constitutes a research, all that may fail. To summarize, on the one hand we have very specific protocols (e.g. IDRP) that provide quite powerful capabilities for information aggregation and abstraction, and on the other hand we have some speculations about "what can be done with the algorithm in general". Yakov From owner-Big-Internet@munnari.oz.au Mon Aug 3 23:32:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09064; Mon, 3 Aug 1992 23:32:43 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09061; Mon, 3 Aug 1992 23:32:33 +1000 (from dave@japan.bellcore.com) Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA05417; Mon, 3 Aug 92 09:35:20 EDT Return-Path: Received: by japan (4.1/4.7) id AA27864; Mon, 3 Aug 92 09:17:03 EDT Date: Mon, 3 Aug 92 09:17:03 EDT From: dave@sabre.bellcore.com (Dave Piscitello) X-Station-Sent-From: japan.bellcore.com Message-Id: <9208031317.AA27864@japan> To: big-internet@munnari.oz.au Ross wrote: An AFI for IP (or for the ISOC) could have a null IDI, and then a binary DSP assigned however we want it to which Dave Katz replied: I think this is true only if ISO actually assigns the AFI to ISOC; otherwise, the trail of adminstrative authority is lost. One of the functions of the NSAP structure is to show a clear hierarchy of administrative authority. The only reason that the "local AFIs" (48/49) can be owned by ISO and have no IDI is because there is *no* administrative authority defined for such addresses. Think about it--what would 8348 say about this AFI w/o IDI? I think Ross and I are operating under the assumption that the AFI would indeed be assigned to ISOC; in other words, cede control of part of the administrative space. My assumption is that 8348, the NSAPA document, would say "this AFI codepoint is assigned to ISOC, see RFC iiii" for details. From owner-Big-Internet@munnari.oz.au Mon Aug 3 23:35:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09114; Mon, 3 Aug 1992 23:35:11 +1000 (from owner-Big-Internet) Return-Path: Received: from OERV01.er.doe.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09110; Mon, 3 Aug 1992 23:35:04 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA04033; Mon, 3 Aug 92 09:32:46 -0400 Date: Mon, 3 Aug 92 09:32:46 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9208031332.AA04033@er.doe.gov> To: dcrocker@mordor.stanford.edu, lekash@nas.nasa.gov Subject: Re: Route fragments, a routing proposal Cc: big-internet@munnari.oz.au However for this to make sense the granularity at which routing architecture needs to be viewed probably cannot be finer than the boundary between autonomous routing domains. Also, I think you underestimate the cleverness of bureaucratic fumblebuts in finding things to control whether they have value or not. From owner-big-internet@munnari.oz.au Tue Aug 4 01:07:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12176; Tue, 4 Aug 1992 01:07:32 +1000 (from owner-big-internet) Return-Path: Message-Id: <9208031507.12176@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09543; Mon, 3 Aug 1992 23:57:40 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 4809; Mon, 03 Aug 92 09:57:08 EDT Date: Mon, 3 Aug 92 09:57:32 EDT From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Subject: Host Identifier and Location >>...reminds me of an attempt to find a problem to a solution... >Yakov, I've personally seen many instances in the history of computer >science of this error being committed, so I don't understand the danger >of it! Are you saying that you have no scruples to commit this error one more time ? >I changed to LS for a long series of rational reasons It would certainly help if you'll enumerate them. >efficiency is not the only consideration in computer science While efficiency may not be the only consideration in *computer science*, it is certainly a significant factor in *computer industry* and in the *operational environment*. The Internet is an *operational* environment, and any solution applicable to the Internet shall take this into account. In fact, efficiency is *the factor* that in large scale systems makes a solution either practical or not. >Other things, such as robustness, flexibility, etc... are also >critical... That is precisely why Unified came into existence, why Unified combines hop-by-hop with source-specified forwarding, and why for the hop-by-hop Unified selected path-vector technique (rather than LS). >So, efficiency alone is not the last word, and when I consider the >"system" benefits of the LS approach, I consider it much superior. Is that a *technical* or an *emotional* statement. If the former, then it would be useful to put specific technical arguments (other than "I consider"). If the latter, then you should state this more explicitly. >In too many cases "abstraction" can only be done by "thinning", >and the consequence loss of information produces either sub-optimal >routes, or no route at all which meets the policy requirements. >As I alluded to above, this is a fundamental truth to DV or LS >architecture. But acknowledging this "fundamental truth" suggests that all the benefits that LS claim it has, as compared to the DV are ephemeral. As soon as you start to do abstraction these benefits are likely to disappear. And at this point we should ask ourselves a very basis question: "What are the real (vs perceived) benefits of LS vs DV ?" I suspect the answer will be "none". At the same time you need to look at the flexibility of doing abstraction, and preconditions for doing abstraction in LS vs DV. >However, everyone needs to realize that abstraction, which is unavoidable, >produces certain unavoidable cost. This is equally true of LS and DV, >and any other routing systems. While unavoidable, the cost of doing abstraction in LS is different as compared with DV. Careful technical analysis (see RFC1332, 1992 SIGCOMM paper by Estrin) shows that DV allows more flexible abstractions with less preconditions, as compared to LS. >LS systems, in my opinion, simply provide you with better tools If DV provides more flexible abstraction with less preconditions, as compared with LS, then it is *not* intuitively obvious why LS provide you with better tools for abstraction. Yakov From owner-Big-Internet@munnari.oz.au Tue Aug 4 02:45:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14633; Tue, 4 Aug 1992 02:45:19 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9208031645.14633@munnari.oz.au> Received: from PIZZA.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14625; Tue, 4 Aug 1992 02:45:11 +1000 (from msteenst@BBN.COM) To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au Subject: policy routing Date: Mon, 03 Aug 92 12:40:40 -0400 From: Martha Steenstrup hello yakov, as you might well expect, i do not entirely agree with your characterization of IDPR. a few opinions follow. >So far, the only attempt to use LS for inter-domain routing is IDPR, >and the protocol provides *NO* support for information aggregation >above the domain level. this is a misleading statement. while it is true that the IDPR architecture does not support aggregation according to arbitrary criteria, it does support aggregation of domains. in particular, the IDPR architecture supports aggregation of a set of continguous domains into a single "super domain". this aggregation can recur to arbitrary levels, forming a hierarchy of domains. so, while it is true that the IDPR architecture does not support information aggregation above the "domain" level, it is also true that a "domain" may itself be an aggregation of domains. within the IDPR architecture, information reduction through aggregation occurs when one groups together a set of domains, with similar transit policies, into a super domain. however, if the transit policies are dissimilar, there is no information reduction. if a domain has a source policy that precludes its traffic from traversing a particular domain within a super domain, then the source domain will generate routes that avoid the given super domain containing the domain to avoid. version 1 of the IDPR protocols (the current version) supports a limited form of aggregation. the IDPR protocols will function among the domains at the top level of the hierarchy. however, if some entity needs information from a domain deep with the hierarchy, it will not be able to obtain this information. the reason is that we do not have arbitrary domain addressing within IDPR messages; in particular only one level of domain addressing is possible. in developing the first version of the IDPR protocols, we decided to postpone determining the proper address format for domain hierarchies in favor of developing the rest of the protocols. the reason for this decision was that the internet does not currently contain enough domains to warrant aggregation; IDPR will work just fine in the current environment. having put together version 1 of IDPR, we are now in a position to return to those aspects of the IDPR architecture that we intentionally left out of the first version of the IDPR protocols. as a matter of fact, we are currently at work on a definition for the addressing of arbitrary levels of domains within a hierarchy. >BGP does not require >domains to exchange their source policies. Each domain can choose >its routes based on local to the domain's criteria. Claim that IDPR >supports source-specific policies needs to be qualified. IDPR supports >source-specific policies AS LONG AS such policies >and the amount of information the domain needs to deal with do not >involve algorithms with high space and/or computational >complexity. while BGP allows a domain to select routes based on that domain's source policies, it does not provide general support for source policies. in particular, an intermediate domain has no idea of other domains' source policies and thus has no idea about which routes will be acceptable to which source domains. without distribution of source policies in BGP, it is possible that none of the routes about which a source domain learns are acceptable according to that domain's source policies, although acceptable routes may exist. only if the intermediate domains that pass along routing information are aware of other domains' source policies can one guarantee that a specific source domain will learn of any acceptable routes. IDPR does not distribute source policies. instead, it distributes transit policy information, leaving it up to a source domain to compute routes accounting for the transit policies distributed and for the domain's own source policies. source-specified message forwarding ensures that messages travel the source-selected route to the destination. i don't deny that computation of policy routes can be complex and hence expensive in terms of processing and memory. but i do not agree with your statement that IDPR supports only those source policies that make routes easy to compute. IDPR places the burden of route generation on the source domains that require the routes, rather than distributing it throughout the internet. thus, administrators of source domains can decide how much computational power they wish to throw at route generation and hence how elaborate their source policies can be. this is a source domain specific decision. >Situation with LS is very different. There is a great disparity >between what is promised by the IDPR architecture and what is delivered >by the IDPR protocol. And that is precisely why your analogy failed. In >absence of any specific proposals it is hard to have *technical* >arguments about what can be done with an algorithm in general. yakov, i would like to hear about the "great disparity". as i mentioned before, IDPR version 1 currently doesn't have arbitrary levels of domain addressing in the packet format. but as i also mentioned, we are is the process of designing this. please let me know about other areas in which you do not believe the architecture and the protocols line up. m From owner-Big-Internet@munnari.oz.au Tue Aug 4 04:01:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16187; Tue, 4 Aug 1992 04:01:44 +1000 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16184; Tue, 4 Aug 1992 04:01:34 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA22948; Mon, 3 Aug 92 11:01:26 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA02916; Mon, 3 Aug 92 11:01:26 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA05799; Mon, 3 Aug 92 11:01:04 PDT Date: Mon, 3 Aug 92 11:01:03 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9208031801.AA05799@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA25702; Mon, 3 Aug 92 11:01:18 PDT To: yakov@watson.ibm.com Cc: hinden@Eng.Sun.COM, big-internet@munnari.oz.au In-Reply-To: <9208031322.AA28324@Sun.COM> Subject: Host Identifier and Location Yakov, > As you correctly pointed out, arguments about limitations of distance > vector based on the ARPANET DV implementations are incorrect *because* > we already have DV protocols that addresses and solved these > limitations. > > Situation with LS is very different. There is a great disparity > between what is promised by the IDPR architecture and what is delivered > by the IDPR protocol. And that is precisely why your analogy failed. In > absence of any specific proposals it is hard to have *technical* > arguments about what can be done with an algorithm in general. I don't think the situation is different. You were saying in your original message that LS algorithms were inappropriate for use in inter-domain routing protocols and I believe basing that assumption on the current version of IDPR. I think that is the same as making statements about the limitations of DV algorithms based on the ARPANET DV implementation. > Of course, we can all waive our hands and just hope that in due time the > proper algorithms with suitable complexity (to make the whole thing > practical) will be developed to realize the full IDPR architecture. > But, it is all subject of future research. And, by definition of what > constitutes a research, all that may fail. Unless, I missed something, I did not think this discussion was about the suitability of IDPR (or IDRP for that matter) for large scale (aka Big Internet) routing. > To summarize, on the one hand we have very specific protocols (e.g. > IDRP) that provide quite powerful capabilities for information > aggregation and abstraction, and on the other hand we have some > speculations about "what can be done with the algorithm in general". To paraphrase your earlier message, I don't think we should propose solutions until we understand the problem that needs to be solved. Then we can decide if one of our existing routing protocls (BGP, IDPR, IDRP, EGP, ....) will work or if we need to develop a new one. Bob From owner-Big-Internet@munnari.oz.au Tue Aug 4 04:37:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17174; Tue, 4 Aug 1992 04:38:00 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9208031838.17174@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17157; Tue, 4 Aug 1992 04:37:53 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3729; Mon, 03 Aug 92 14:37:22 EDT Date: Mon, 3 Aug 92 14:37:47 EDT From: yakov@watson.ibm.com To: Bob.Hinden@Eng.Sun.COM Cc: big-internet@munnari.oz.au Subject: Host Identifier and Location Ref: Your note of Mon, 3 Aug 92 11:01:03 PDT >To paraphrase your earlier message, I don't think we should propose >solutions until we understand the problem that needs to be solved. >Then we can decide if one of our existing routing protocols will work >or if we need to develop a new one. I fully agree with your suggestion. Can you point me to the mailing list that is focused on trying to understand the problem (rather than trying to push various solutions) ? Yakov. From owner-Big-Internet@munnari.oz.au Tue Aug 4 04:45:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17490; Tue, 4 Aug 1992 04:45:50 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17482; Tue, 4 Aug 1992 04:45:35 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03483; Mon, 3 Aug 92 14:45:07 -0400 Message-Id: <9208031845.AA03483@ginger.lcs.mit.edu> To: Paul Tsuchiya Cc: ddc@lcs.mit.edu, Big-Internet@munnari.oz.au Subject: Re: Question on Clark's route fragments In-Reply-To: Your message of Sun, 02 Aug 92 22:11:04 -0400. <9208030211.AA05555@chiya.bellcore.com> From: David Clark Date: Mon, 03 Aug 92 14:45:07 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp I do not mind up/down so long as it implies a polyarchy, not a hierarchy. You were using the up/down in a number of ways, and I did not manage to internalize all of them in real time, but some of them seem to depend on being able to find the top level name space without using the route in the PIP header. This means, to me, a hierarchy, since we must assume that without naming the root the system can find it. So my problem with up/down is the general experience that it usually is not general enough. If you require that any path up or down have both a direction and a name (which gives you polyarchy) then it works, But once you do this, I suspect that up/down stops being a particularly useful notation. What you want is a more general notion that the router has a number of tables, each indexed with a small integer, and the local name is the pair (table-name, index). Then you can use up/down or 1,2,3 as the table-name. Up/down stops having any particular semantics. Dave From owner-Big-Internet@munnari.oz.au Tue Aug 4 04:51:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17579; Tue, 4 Aug 1992 04:51:41 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17572; Tue, 4 Aug 1992 04:51:31 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Mon, 3 Aug 92 14:51:09 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Mon, 3 Aug 92 14:51:08 EDT Date: Mon, 3 Aug 92 14:51:08 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208031851.AA00354@chiya.bellcore.com> To: ddc@lcs.mit.edu, tsuchiya@thumper.bellcore.com Subject: Re: Question on Clark's route fragments Cc: Big-Internet@munnari.oz.au > > I do not mind up/down so long as it implies a polyarchy, not a hierarchy. > You were using the up/down in a number of ways, and I did not manage to > internalize all of them in real time, but some of them seem to depend on > being able to find the top level name space without using the route in the > PIP header. This means, to me, a hierarchy, since we must assume that > without naming the root the system can find it. I thought your notion of polyarchy was that a leaf AD could have multiple parents in the hierarchy. Pip can allow for multiple root name spaces-- they would be distinguishable using the "routing context" field. > > So my problem with up/down is the general experience that it usually is not > general enough. If you require that any path up or down have both a > direction and a name (which gives you polyarchy) then it works, But once you > do this, I suspect that up/down stops being a particularly useful notation. > What you want is a more general notion that the router has a number of > tables, each indexed with a small integer, and the local name is the pair > (table-name, index). Then you can use up/down or 1,2,3 as the table-name. > Up/down stops having any particular semantics. I think I understand you, but it would be useful to get together and discuss it some time. In any event, I think Pip can handle things ("your" way or "my" way). But, eventually we have to decide on a way. PT From owner-big-internet@munnari.oz.au Tue Aug 4 06:20:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19808; Tue, 4 Aug 1992 06:21:03 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18717; Tue, 4 Aug 1992 05:37:41 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA21242; Mon, 3 Aug 92 12:36:08 -0700 Received: by us1rmc.bb.dec.com; id AA12768; Mon, 3 Aug 92 15:33:21 -0400 Message-Id: <9208031933.AA12768@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Mon, 3 Aug 92 15:33:22 EDT Date: Mon, 3 Aug 92 15:33:22 EDT From: Ross Callon To: smart@mel.dit.csiro.au Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Apparently-To: smart@mel.dit.csiro.au, big-internet@munnari.oz.au Subject: re: Re: Some comments/queries on PIP (ID vs rest of address) > Does anybody else have the vague feeling that the separation > of ID from address should be accompanied by a protocol layer > separation? I.e. that there should be a routing layer that > has the address, and above that an authentication/security/ > accounting/whatever layer that has the IDs. The routing layer > could be used to transport other sorts of things as well: to > IP4 and CLNP it might look like a funny sort of link layer > (with multiple networks on it and short-cut routing I guess). This depends upon what the rest of the address looks like (I will assume that the ID is a flat field which is globally unique, and leave the details of how we administer the ID field for a different mail message). We might assume that the rest of the address (what I have been calling "location"), contains enough information to get you "close" to the destination. For example, it might get you to the subnet (if you route to subnets) or to the area. We need to either (i) Include the global ID in the same packet level as the rest of the address (so that the last part of the route can be followed, such as from a router on the right subnet to the host), or (ii) include another local ID in the packet (i.e., have a "location" part of the address which gets you all the way to the right host, not just to the right subnet or area). I don't think that it makes a lot of difference which approach we use. The first approach (consider the global ID to be the low order part of the address) saves a few bytes, but I am dubious as to whether the number of bytes saved will be significant given how many bytes are likely to be needed to accomplish global routing in an internet with 10^9 routing domains. Ross From owner-Big-Internet@munnari.oz.au Tue Aug 4 06:25:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19911; Tue, 4 Aug 1992 06:25:56 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9208032025.19911@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19908; Tue, 4 Aug 1992 06:25:46 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 7514; Mon, 03 Aug 92 16:25:16 EDT Date: Mon, 3 Aug 92 16:25:41 EDT From: yakov@watson.ibm.com To: msteenst@BBN.COM Cc: big-internet@munnari.oz.au Subject: policy routing Ref: Your note of Mon, 03 Aug 92 12:40:40 -0400 Hello Martha, >>So far, the only attempt to use LS for inter-domain routing is IDPR, >>and the protocol provides *NO* support for information aggregation >>above the domain level. >this is a misleading statement. ... >the IDPR architecture supports aggregation of a set of contiguous >domains.... I've been talking about the protocol, you are talking about the architecture !!! Keep them separate (to avoid confusion) !!! It is rather difficult to maintain a *technical* discussion when on the one hand you claim that the architecture supports feature X, and on the other hand there is nothing in the protocol to support this feature, and meantime you jistify the whole scheme based on the architecture. Shall we expect that any feature enumerated in the architecture will be supported by some future version of the protocol ? Shall we expect that the algorithms employed by some future version of the protocol (in order to support some feature from the architecture) will be feasible (in terms of their complexity) ? >thus, administrators of source domains can decide how much computational >power they wish to through at route generation and hence how elaborate >their source policies can be. This is a source domain specific decision. This is all true if one is concern with exercising fancy algorithms, and burning CPU. However, if one is concerned with routing that can adapt to topological changes, then the time to compute a route is crucial (or otherwise you are computing routes for the sake of computation). Yakov. From owner-Big-Internet@munnari.oz.au Tue Aug 4 07:16:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20855; Tue, 4 Aug 1992 07:16:52 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20842; Tue, 4 Aug 1992 07:16:16 +1000 (from craig@aland.bbn.com) Received: from port14.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA13786; Mon, 3 Aug 92 17:15:41 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA29610; Mon, 3 Aug 92 14:15:19 PDT Message-Id: <9208032115.AA29610@aland.bbn.com> To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au, pip@thumper.bellcore.com Subject: re: Host Identifier and Location From: Craig Partridge Date: Mon, 03 Aug 92 14:15:19 -0700 Sender: craig@aland.bbn.com > While we may argue that flow setup may be useful in *certain* cases, > would suggest to avoid generalization of this to make > the flow setup required for *all* cases. I'd say this more strongly. First, a large fraction of applications will not want to wait for any flow setup to occur. They don't send enough data to amortize effective doubling of the first RTT. Second, I believe that flow setup may well require negotiation between sender and receiver before the setup request can be made. So there needs to be some way to communicate with a peer before a setup is done. Craig From owner-Big-Internet@munnari.oz.au Tue Aug 4 07:23:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20964; Tue, 4 Aug 1992 07:24:19 +1000 (from owner-Big-Internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20959; Tue, 4 Aug 1992 07:23:56 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA17442; Mon, 3 Aug 92 14:23:50 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA18773; Mon, 3 Aug 92 14:23:53 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA11640; Mon, 3 Aug 92 14:23:29 PDT Date: Mon, 3 Aug 92 14:23:29 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9208032123.AA11640@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA26247; Mon, 3 Aug 92 14:23:43 PDT To: yakov@watson.ibm.com Cc: Bob.Hinden@Eng.Sun.COM, big-internet@munnari.oz.au In-Reply-To: <9208031837.AA27401@Sun.COM> Subject: Host Identifier and Location Yakov, Big-internet is probably the best we have. How about if you take a cut at what you think the problem (requirements) is for large scale internet routing. I am certain that an interesting discussion would ensue. This could help to generate a consensus. If we can agree on the problem, the solution should be easy :-) Bob From owner-Big-Internet@munnari.oz.au Tue Aug 4 07:47:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21459; Tue, 4 Aug 1992 07:47:38 +1000 (from owner-Big-Internet) Return-Path: Received: from wilbur.nas.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21455; Tue, 4 Aug 1992 07:47:27 +1000 (from lekash@nas.nasa.gov) Received: by wilbur.nas.nasa.gov (5.61/1.34) id AA07458; Mon, 3 Aug 92 14:47:08 -0700 Date: Mon, 3 Aug 92 14:47:08 -0700 From: lekash@nas.nasa.gov (John Lekashman) Message-Id: <9208032147.AA07458@wilbur.nas.nasa.gov> To: hitchcoc@oerv01.er.doe.gov Cc: big-internet@munnari.oz.au In-Reply-To: Dan Hitchcock's message of Mon, 3 Aug 92 09:32:46 -0400 <9208031332.AA04033@er.doe.gov> Subject: Route fragments, a routing proposal However for this to make sense the granularity at which routing architecture needs to be viewed probably cannot be finer than the boundary between autonomous routing domains. Depends on your point of view of what an autonomous routing domain happens to be. For instance, I don't particularily worry at all about routing between my IP network and someone else's SNA network. Because the two live in different planets, that's an application layer problem. However, different autonomous systems that forward IP datagrams between them, which happen to be autonomous because DOE manages one, and NASA another, will still have a common underlying routing paradigm. In the current scheme, IP datagrams look like , and we do destination based hop-by-hop routing. Whether I use OSPF or you use IGRP to propagate routing information, the same paradigm happens. Also, I think you underestimate the cleverness of bureaucratic fumblebuts in finding things to control whether they have value or not. No I don't. But I would prefer it be as difficult as possible, and that the architecture lend itself to being able to ignore their nonsense as much as possible. (Rather than make it embarrassingly easy.) john From owner-Big-Internet@munnari.oz.au Tue Aug 4 08:18:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22162; Tue, 4 Aug 1992 08:19:10 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22157; Tue, 4 Aug 1992 08:18:51 +1000 (from craig@aland.bbn.com) Received: from port14.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA17890; Mon, 3 Aug 92 18:18:39 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA01153; Mon, 3 Aug 92 15:18:27 PDT Message-Id: <9208032218.AA01153@aland.bbn.com> To: big-internet@munnari.oz.au Subject: too many IDs Reply-To: Craig Partridge From: Craig Partridge Date: Mon, 03 Aug 92 15:18:27 -0700 Sender: craig@aland.bbn.com Hi folks: I just came back from four days of vacation and discovered I couldn't figure out what different writers meant by ids. Can we agree on a terminology? How about: HID - host ID (from some notes, I think this would be the globally unique name of the host). FID - flow identifier. A value used to identify a flow's properties (which in some cases *will not* include routing information). Craig E-mail: craig@aland.bbn.com or craig@bbn.com From owner-big-internet@munnari.oz.au Tue Aug 4 08:22:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22216; Tue, 4 Aug 1992 08:23:04 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21313; Tue, 4 Aug 1992 07:40:33 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA28101; Mon, 3 Aug 92 14:39:59 -0700 Received: by us1rmc.bb.dec.com; id AA15435; Mon, 3 Aug 92 17:37:05 -0400 Message-Id: <9208032137.AA15435@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Mon, 3 Aug 92 17:37:12 EDT Date: Mon, 3 Aug 92 17:37:12 EDT From: Ross Callon To: desjardi@boa.gsfc.nasa.gov, jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Apparently-To: desjardi@boa.gsfc.nasa.gov, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: re: Host identifier length This may seem like a small detailed nit, but we might want to think somewhat about how large a global host ID would need to be. Clearly we need to distinguish here between an "address" which contains some sort of hierarchical information used to distinguish the location of a host (and which therefore is likely to be assigned in a topology-dependent manner which requires sparse assignment), vs an identifier, which is only required to be globally unique (and to have no other useful property). I would think that for an ID which only needs to be unique, we should be able to get reasonably dense utilization of the address space. There are currently somewhere around 4 billion people in the world (using the Canadian/American definition of 1 billion = 10^9, with apologies to my British colleagues). If we account for a doubling of population, this comes to about 10^10 people (I read recently that the worlds population would double by about 2050, so this would last us into the second half of the next century). If you figure on 100 globally addressable hosts per person in the world, then this implies a need to come up with 10^12 globally meaningful IDs. [It has been argued that the number of computers in the world is likely to approach the number of electric motors -- using the model that anything which turns electric power into physical motion is a motor, then I have counted about 60 motors in my house, including my car, workbench and tools]. 2^48 is equal to approximately 2.81 * 10^14. This implies that we need to obtain nearly 1% utilization of the ID field if we want to use a 48 bit ID to identify 100 computers for every person in the world in 50 or 60 years. My feeling therefore is that 48 bits is probably enough. However, this is based on the assumptions that: (i) 100 globally addressible computers per person in the world is sufficient (we could have additional computers -- they just wouldn't be globally addressible); and (ii) we can achieve 1% utilization of a global Identifier space. The next issue is how do we administer this space. As Dick as pointed out, it would be very useful to make use of an ID space which has already been handed out. However, we also need to hold on to a large part of the space for Internet-specific administration. We can observe that we already have a 32-bit IP address space which is (up to now, and for a few more years) good for global identification, and the IEEE has already administered a 48-bit ID space, although they really only have a 46-bit space for global identification of individual systems (since they leave half of the space unassigned for local use, and another overlapping half used for multicast). Thus, I would propose that, for the purpose of unique global identification of individual internet systems, we could make use of a 48 bit space in which: - One quarter of the space (any ID starting with some particular two bit value) corresponds to the IEEE globally assigned unicast system IDs (ie, if you already have an IEEE globally assigned unicast system ID, then you also have a 48-bit global Internet ID). - A small part of the space (any ID starting with some particular 16 bit value, obviously chosen to not collide with the IEEE IDs) which corresponds to the IP 32-bit address space. Again, this means that if you already have a 32-bit global IP address, then you also have a 48-bit global Internet ID. - The rest of the address space (nearly 3/4 of the space) would be administered by the IANA. Thus, for example, a small site could obtain a small number of ID assignments for their own use. Ross From owner-big-internet@munnari.oz.au Tue Aug 4 09:02:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23088; Tue, 4 Aug 1992 09:02:48 +1000 (from owner-big-internet) Return-Path: Message-Id: <9208032302.23088@munnari.oz.au> Received: from PIZZA.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21825; Tue, 4 Aug 1992 08:06:33 +1000 (from msteenst@BBN.COM) To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au Subject: policy routing Date: Mon, 03 Aug 92 18:01:08 -0400 From: Martha Steenstrup hi yakov, >It is rather difficult to maintain a *technical* discussion >when on the one hand you claim that the architecture >supports feature X, and on the other hand there is nothing in the >protocol to support this feature, and meantime you jistify the whole scheme >based on the architecture. as i said before, i would really like to have your list of all of the discrepancies between the IDPR architecture and the IDPR protocols. your general complaint is intriguing to me, but without specifics i am having a hard time understanding your problem. >This is all true if one is concern with exercising fancy algorithms, >and burning CPU. However, if one is concerned with routing >that can adapt to topological changes, then the time to compute >a route is crucial (or otherwise you are computing routes for >the sake of computation). the more topological changes in the internet, the more link bandwidth expended in distributing routing information and the more processing bandwidth consumed in distributing the routing information and in recomputing routes. this is true for any routing algorithm. IDPR is inter-domain POLICY routing. as such, policy considerations have been the central focus in the design of all of the component protocols. if a source wishes to have a route that supports particular services and traverses particular domains, then the entity that generates routes on behalf of that source must take these requirements into account. yes, this does complicate route generation at the source. however, this is the type of route the source requested. IDPR was not developed to "burn CPU" or "exercise fancy algorithms". instead, it was developed in an attempt to satisfy a perceived need for policy-based routing in the internet. m From owner-big-internet@munnari.oz.au Tue Aug 4 14:39:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02002; Tue, 4 Aug 1992 14:39:28 +1000 (from owner-big-internet) Return-Path: Received: from sadye.emba.uvm.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26320; Tue, 4 Aug 1992 11:26:38 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA02537 (5.65/1.23); Mon, 3 Aug 92 21:26:09 -0400 Date: Mon, 3 Aug 92 21:26:09 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9208040126.AA02537@sadye.emba.uvm.edu> To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: too many IDs In-Reply-To: <9208032218.AA01153@aland.bbn.com> References: <9208032218.AA01153@aland.bbn.com> On Mon, 03 Aug 92 15:18:27 -0700, Craig Partridge said: > HID - host ID (from some notes, I think this would be the globally > unique name of the host). I'm not sure if this is really what you want... I've been using ``EPID'' for ``Endpoint ID''; this refers to anywhere you might want to send an IP-gram, which might not necessarily be the same as a host. (It seems like it would be useful to have distinct EPIDs for multicast groups, for example.) -GAWollman -- Garrett A. Wollman = wollman@emba.uvm.edu = UVM is welcome to my opinions = uvm-gen!wollman = That's what being alive is all about. No deity, no higher goal exists, than to bring joy to another person. - Elf Sternberg From owner-big-internet@munnari.oz.au Tue Aug 4 15:12:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02868; Tue, 4 Aug 1992 15:14:39 +1000 (from owner-big-internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26108; Tue, 4 Aug 1992 11:17:30 +1000 (from kre) To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: Host identifier length In-Reply-To: Your message of Mon, 03 Aug 92 17:37:12 -0400. <9208032137.AA15435@us1rmc.bb.dec.com> Date: Tue, 04 Aug 92 01:17:18 +1000 Message-Id: <602.712891038@munnari.oz.au> From: Robert Elz Ross, your thinking on this almost duplicates mine, except that I would use 64 bit ID's rather than 48. I'm not sure that its reasonable to hope for 1% effeciency, and in any case, handling the problem of number allocation authorities would be trickier with limited free bits. Since these things are just (conceptually) flat - it doesn't matter where the number comes from, as long as its unique, so there's no reason to either burden some overloaded authority (or two) managing the whole thing, or to deny other seemingly apparent authorities the possibility of managing a reasonably sized space. I'd use the top 16 bits (of the 64) to specify the number authority - one reserved for IEEE, allowing IEEE 48 bit ID's to be one for of ID - without turning off either the IEEE multicast ID's (which might be useful to retain) or the IEEE locally allocated ID's either (which probably aren't, but some form of locally allocated ID is probably worth having). Another value would be delegated to the IANA - they could either allow 65K IP sized address spaces, or use the combination of AS number, and IP number to form the ID - allowing the AS's later to act as number allocation authorities, and re-use the IP numbers not allocated in their area. Other values reserved for now - though I could conceive of 4 different IEEE numbers, to allow for the various ways of transcribing the IEEE allocated number - sites could pick the one they prefer, and simply prepend the top 16 bits that conform to that notational use (one for the ethernet form, another for token ring, another for token bus (is it?) and the fourth for the one form that isn't used yet as far as I'm aware). If ISO, or CCITT want to be number allocation authorities (apart from ISO's role in the IEEE number space these days) there's plenty of space left over for them. Plenty to allocate 48 bit spaces to every country if their governments want them, and it wouldn't be likely that we might come close to running out in 100 years, 64 bit numbers should last quite a bit longer than that. Aside from all of this, 64 is a nicer number than 48 - easier to process... kre From owner-big-internet@munnari.oz.au Tue Aug 4 15:50:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03826; Tue, 4 Aug 1992 15:50:48 +1000 (from owner-big-internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01665; Tue, 4 Aug 1992 14:29:09 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA10686 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 4 Aug 1992 14:29:18 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA18625; Tue, 4 Aug 92 14:28:59 EST Message-Id: <9208040428.AA18625@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Cc: smart@mel.dit.csiro.au Subject: MiniPIP -- Splitting the Network Layer Date: Tue, 04 Aug 92 14:28:58 +1000 From: Bob Smart Following up my own suggestion here is a proposal to split the IP layer into 2. I call the proposal MiniPIP. It has a number of advantages: 1. It partly implements the suggestion that we defer a new packet format. 2. It extends the life of IPv4 packet format by making the IP4 addresses act as IDs, but uses and takes advantage of IP4 routing technology in a natural way for the transition. 3. It uses the PIP RD but new RDs are possible if there are Routing Architectures not implementable with PIP (which I doubt). 4. It is morally superior because it has more layers :-). Comments positive and negative are solicited. I suggest that discussion of this proposal be on the PIP mailing list. Given the slightest encouragement I'll knock it into shape as an Internet Draft. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MiniPIP -- Splitting the Network Layer ======================================== Bob Smart CSIRO Division of Information Technology 723 Swanston St, Carlton VIC 3053 Australia phone: +61 3 282 2625 fax: +61 3 282 2600 smart@mel.dit.csiro.au 0. Introduction --------------- There is widespread support for the idea of separating the address function used for routing from the end-point identification function. However the discussion of how to do this has tended to bog down because people are conscious of various important emerging areas where we are not currently in a good position to give the final answer: security, authentication, accounting. The following proposal avoids this problem by splitting the IP layer into two: a routing layer and an identification layer. The problem areas in the identification layer don't need to be solved immediately because the routing layer can be used to extend the life of the IPv4 packet. While the ID layer is primarily an end system area, it is also used by ID-routers which examine packets at the ID and higher layers for purposes such as security, filtering and accounting. 1. The Routing Layer -------------------- There are people saying we don't know how to do routing and/or high speed packet forwarding. On the other hand it seems to some of us that PIP is neutral with regard to routing architecture and should be hard to beat on speed. At any rate the following proposal doesn't specify the routing directive: the default is PIP until someone comes up with something else. It also allows for a change in the future. It is also possible to set it up initially so that it is invisible to the hosts, so that only the routers will have to change later. Can we do more? The miniPIP packet format is bits name description 16 optind offset of options (or 0 if no options) 16 datind offset of ID-layer data 16 pktid identify packet for some purposes 8 ttl time to live 8 vers version number = 1 if compliant with this document. 8 reserved 8 pkttyp type of data packet * rd PIP routing directive. * opts options. * data ID layer data The version number allows new versions of this packet format to be used at the same time as old ones. So if PIP is not found to be adequate for future routing technology then a new format RD can be defined. This also allows new fields or options which can't be ignored to be defined. The pkttyp field allows multiple packet types to be moved using this routing layer. In particular the following packet types are defined initially 1 PCMP (PIP Message Control Protocol) 2 IP version 4 3 reserved for IP version 7 (not defined in this document) 4 CLNP The use of IP4 over miniPIP is described in a later section. There are no options defined at the moment. The first 2 bits of the option type say if it is: mandatory (return PCMP and drop packet if you don't support); optional; informational (ignore always). The pktid identifies the packet. It can be used to discard multiple copies of a packet that are close together: same RD + same pktid = same packet. Note that this is only likely to happen as a result of faulty link layer operation. The pktid is also returned with PCMP error packets and so it is possible for the sender to structure the field (or remember all recent pktids) so that the returning PCMP packet can be associated with the relevant process. There is no field for the length of the data. The link layer is expected to return some length which may be somewhat larger than the actual length. The ID layer is expect to have its own length field. There is no fragmentation at this level. If we add options which require putting data in the options field then the space has to be preallocated (because you can't make the header bigger and fragment the data). Fragmentation is expected to be done at higher levels (after MTU discovery) or at the link layer. 1.1 PCMP -------- - MTU discovery and return - address unreachable - packet too big - unknown mandatory option - translation registration - translation request and response - redirect - ... 2. IP Version 7 over MiniPIP ---------------------------- MiniPIP is meant to run with a purpose built ID layer above it. That layer will have: o 64 bit IDs with no routing significance. Maybe 48 is enough. o Security features to be designed: e.g. it might have a message digest of the contents encrypted with the sending ID's private key (but not often). o Accounting features to be defined: e.g. it might allow for accounting tokens that an anonymous ftp server might use so that packets from the ftp server to the user are charged to the user. o ??? It has been argued that activities related to security, filtering, accounting should be in the PIP header because they are performed by routers. However when performing these functions routers are being more than routers. And in fact when they perform these functions routers tend to look arbitrarily deeply into packets: e.g. our ciscos are configured to look at TCP port numbers, and filtering on that basis is bound to continue. The design of an optimal ID layer protocol is left as an exercise for the Internet community. 3. IP version 4 over MiniPIP ---------------------------- Initially miniPIP will be used with IP4. To IP4 miniPIP is just another link layer. It is rather odd one since it will have a lot of different networks on it, however we are learning to cope with that in SMDS and other large public data networks. To show how this will work, and how it will save IP4 address space a simple situation is considered first. 3.1 A Simple Example -------------------- Assume that Australia gets a Class A network to use with miniPIP/IP4. It would need to install miniPIP/IP4 software in all the routers connected to physical networks which will be using that address space. Hosts on those physical networks would be allocated an arbitrary address from the class A without regard to topology. Because of this the class A's address space can be allocated very densely. There is still some fanout loss because of the need to delegate subdomains of the in-addr.arpa domain, but that loss should be less than 50%. Hosts would be configured with the default class A address mask. Routers would know which hosts are on their ethernet(/whatever). If a host wants to speak to another host on the miniPIP class A then it will naturally arp for it. If it is not one of the other hosts on that wire then the router will respond with a proxy arp response. The router will do the IP4-address -> PIP-address translation, build the miniPIP packet and fire it off. There are a number of ways to do IP4-address -> PIP address translation. The method considered to date has been DNS: in this case it would be PA entries in the in-addr.arpa domain. While this is probably a good place to initially enter the information for static hosts, it has some disadvantages for mobile hosts and for high speed access to the information. It would be nice to devise routing contexts and addressing schemes which will allow a number of route servers to sit on a single multi-cast address and receive updates to translations for the domain (i.e. for the class A). There would be another address used when seeking a translation which would go to just one of the servers, presumably the closest. Translation servers would also return the PIP address of routers for external IP4 networks. This could include a router for default. 3.2 Extending the Simple Case ----------------------------- There is no need to do more than is described in 3.1. Using class As for dense allocation in this way gives us a lot of breathing space. The different class-A/miniPIP networks don't have to be able to speak to each other at the miniPIP level initially. IP4 packets can be sent between them using existing IP4 routing technology. There will however be advantages in keeping the packet in miniPIP format. To do this the translation servers for a domain will, before they look for IP4 routers, look to see if the destination is another miniPIP/IP4 network (perhaps by looking in the DNS -- there won't be a lot of these if they are all class As). If the destination is another miniPIP/IP4 network then the PIP address of the translation server for that network will be obtained, and the PCMP translation request will be passed to that translation server. I'm not quite sure whether the RD should be built to return the packet to the requestor, or to come back to the translation service to be cached and passed on. 3.3 Involving the Hosts ----------------------- The next step is to allow end-systems to talk miniPIP directly. This would allow, for example, a mobile computer from Australia to connect into a LAN in America, and send a (secure) "this is where I am" packet to the translation server in the class A in Australia so that the mobile host can be directly found. 4. Summary ---------- - Avoids premature decisions that can be avoided. - Keeps existing hosts going. - Gives time for a full transition that doesn't fragment the Internet. - Take immediate advantage of PIP flexibility. - Potential platform for efficient routing of multiple protocols. From owner-Big-Internet@munnari.oz.au Tue Aug 4 19:53:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09645; Tue, 4 Aug 1992 19:53:35 +1000 (from owner-Big-Internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09631; Tue, 4 Aug 1992 19:53:13 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA24170 (5.65b/CWI-2.173); Tue, 4 Aug 1992 11:52:57 +0200 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA02845; Tue, 4 Aug 92 09:44:59 +0200 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA25445; Tue, 4 Aug 92 09:44:37 +0200 Message-Id: <9208040744.AA25445@dxcern.cern.ch> Subject: why not? To: big-internet@munnari.oz.au Date: Tue, 4 Aug 92 9:44:35 MET DST From: Brian Carpenter CERN-CN Cc: Vint Cerf X-Mailer: ELM [version 2.3 PL11 CERN 11] While discussing whether or not to use NSAPs and whether or not to ask for an AFI, why not in parallel, for the cost of an airmail stamp, request an ICD code for the ISOC? This is a very easy piece of insurance which would give the Internet, if I am not mistaken, 14 bytes of address space to allocate _any way it wants_ independent of any other authority. ** This suggestion is not intended as an endorsement of CLNP. ** On 2 August 1990 I wrote to ISO 6523 Registration Dept (Mrs L. Evans) British Standards Institute Linford Wood Milton Keynes MK14 6LE United Kingdom and one week later we were allocated ICD 0020. Below is the text the ISOC would have to include. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 ----- ICD: Name of coding system: Internet Society (ISOC) Name and address of Internet Society (ISOC) issuing organistaion: Suite 100 1895 Preston White Drive Reston, VA 22091 USA Tel. +1 703 620 8990 Fax. +1 703 620 0913 Structure of code: As defined in ISO-6523 i.e. 4 digit ICD code Organisation code (up to 14 characters) Organisation name (up to 250 characters) No check digits needed Description of organisations ISOC itself and academic, research covered by coding system: and commercial sites connected to the international Internet. Notes on use of code: The ICD code forms the initial part of the OSI network addressing and naming tree as depicted in Addendum 2 of ISO-8348. Sponsoring Authority: Internet Society (ISOC) Date of issue: Additional comments: None ------------- From owner-Big-Internet@munnari.oz.au Tue Aug 4 23:46:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14450; Tue, 4 Aug 1992 23:46:22 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14444; Tue, 4 Aug 1992 23:46:11 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09975; Tue, 4 Aug 92 09:45:47 -0400 Message-Id: <9208041345.AA09975@ginger.lcs.mit.edu> To: Christian Huitema Cc: Big-Internet@munnari.oz.au Subject: Re: Question on Clark's route fragments In-Reply-To: Your message of Mon, 03 Aug 92 14:02:51 -0400. <199208031202.AA23001@mitsou.inria.fr> From: David Clark Date: Tue, 04 Aug 92 09:45:47 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp I think that you could easily assign global names to trasit ADs. If you want to assign global names to every terminal AD (each campus, company or living unit) then the size of the identifier gets somewhat bigger, I fear. It is just an intuition, but I find that I cross a break-point in mind when I move from naming all the transit ADs to naming the larger set of all ADs. JNC wants a very abstract representation of topology. If you go for abstract and general models, then you have to name everything from a uniform name space. I have argued that it might be worth it to make an architectural distinction between transit AD and terminal ADs. If you did that, naming, aggregation and route finding might all get more simple, because they would be more constrained. Dave From owner-big-internet@munnari.oz.au Wed Aug 5 02:32:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19469; Wed, 5 Aug 1992 02:32:32 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17038; Wed, 5 Aug 1992 00:57:47 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA17839; Tue, 4 Aug 92 07:57:30 -0700 Received: by us1rmc.bb.dec.com; id AA04479; Tue, 4 Aug 92 10:54:44 -0400 Message-Id: <9208041454.AA04479@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Tue, 4 Aug 92 10:54:45 EDT Date: Tue, 4 Aug 92 10:54:45 EDT From: Ross Callon To: brian@dxcern.cern.ch Cc: big-internet@munnari.oz.au Apparently-To: brian@dxcern.cern.ch, big-internet@munnari.oz.au Subject: re: why not? > While discussing whether or not to use NSAPs and whether > or not to ask for an AFI, why not in parallel, for the > cost of an airmail stamp, request an ICD code for the ISOC? > This is a very easy piece of insurance which would give the > Internet, if I am not mistaken, 14 bytes of address space to > allocate _any way it wants_ independent of any other authority. Given a maximum length of 20 bytes, and given the recent removal of the requirement that the binary NSAPs all be fully encodable in decimal, this actually leaves us with 17 bytes (20, minus one byte for the AFI, minus two bytes for the ICD). Ross From owner-Big-Internet@munnari.oz.au Wed Aug 5 03:16:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20405; Wed, 5 Aug 1992 03:16:21 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20402; Wed, 5 Aug 1992 03:16:13 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11500; Tue, 4 Aug 92 13:16:06 -0400 Date: Tue, 4 Aug 92 13:16:06 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208041716.AA11500@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: too many IDs Cc: jnc@ginger.lcs.mit.edu HID - host ID (from some notes, I think this would be the globally unique name of the host). Craig, I think host is too limited a concept. I've been using the term Endpoint ID, which I would abbreviate to EID. (Garrett's "EPID" might be mistaken as having something to do with processes, which it doesn't, really.) Here's what I said on Big-I a while back about what an endpoint (and an address) is: 'Endpoints' are end-end/fate-sharing locales; think of an endpoint as one end of a TCP connection. Endpoints names are 'identifiers', which tells you nothing about where it is in the network, etc, etc; it's simply a globally unique binary string (probably shortish fixed length). Each endpoint has one identifier (probably, no good reason to do otherwise?). Network interfaces are another fundamental object class. They have names, called 'addresses' (only for lack of a better term :-) which are structured, and the structure is related to the network topology. Endpoints do not have addresses, the only kind of names they have are identifiers. The mapping from the obkjects of this class of object (and their names, identifiers) to the interface class of object (and their names, i.e. 'addresses'), is very flexible. One endpoint can have mutiple interfaces (thus multiple addresses), e.g. multi-homed host, or several endpoints can be at a single interface (thus a single address), e.g. a MIMD multi-processor. Noel From owner-Big-Internet@munnari.oz.au Wed Aug 5 03:27:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20641; Wed, 5 Aug 1992 03:27:57 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20638; Wed, 5 Aug 1992 03:27:35 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA22911; Mon, 3 Aug 1992 13:54:27 +0200 Message-Id: <199208031154.AA22911@mitsou.inria.fr> To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: avalon@coombs.anu.edu.au, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: Host Identifier and Location In-Reply-To: Your message of "Fri, 31 Jul 92 13:13:51 EDT." <9207311713.AA03844@chiya.bellcore.com> Date: Mon, 03 Aug 92 13:54:18 -0400 From: Christian Huitema X-Mts: smtp >Yes. This is why the Pip Routing Directive structure is basicly a >loose source route. It is because all these types of routing can >be represented by a loose source route. Then, I would suggest that we launch rapidly an IPv4 based experiment to acquire a bit more experience with source routing. I know it has been specified for years, and is supposed to be well known, but I can think of a number of gray areas -- in fact, it strongly smells like the problem that plague gateway routing of email: * source routing states the name of intermediate relays, much the same way "MX record" do. How do we express the fact that someone is actually to use the relay? How does the relay check? * source routing use user-computed routes. This has been used for years by UUCP. And one great debate in UUCP was to know whether intermediate relays should be authorized to "rewrite the source route". Are we sure we dont risk something of that kind? I can also think of at least two more area where experience would be beneficial: * current IP address, as you mentioned, are analysed as "net + subnet + host". Could we not, for the purpose of source routing, treat some addresses as "group address", e.g. reserve one particular 32 bits configuration to mean "go through NSF"? * source routing enables a lot of end to end control. In particular, if several routes can be used, the source could decide to spread the packets over these several routes. If you make that apparent to the control level (TCP, or whatever) and combine that with end-2-end congestion detect you get a neat way to perform "load adaptative routing"? Rather than polishing up paper specs, should we not try to get some hands-on experience? That would certainly be most valueable! Christian Huitema From owner-big-internet@munnari.oz.au Wed Aug 5 04:01:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21391; Wed, 5 Aug 1992 04:01:22 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16393; Wed, 5 Aug 1992 00:24:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10271; Tue, 4 Aug 92 10:24:22 -0400 Date: Tue, 4 Aug 92 10:24:22 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208041424.AA10271@ginger.lcs.mit.edu> To: Z.Wang@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu, tsuchiya@thumper.bellcore.com Subject: Re: Host Identifier and Location Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Huh? Could I see that message. My intent is that forwarding doesn't take place on the ID. Paul, this was from the time a month ago when we were arguing over whether a hardware forwarding engine that could process PIP headers was completely general, whether you could change the routing architecture without changing the forwarding stuff, and whether we were going to be able to change the routing architecture again. Here's the message (excerpted): To: big-internet@munnari.oz.au Subject: Re: meta matters Date: Fri, 26 Jun 92 08:34:27 +0100 From: Paul Tsuchiya > E.g. if you built a forwarding chip which used the the RD to forward > packets, and then, using the flexibility in PIP, decided to switch to an > architecture like Nimrod, which tagged packets to flows with the ID > (or ESI in PIPese), would that chip really still work? Yes. My question was asking if you could forward based on the endpoint ID (I guess EID is the jargon for this now, right?), expecting the answer 'No', which was not what I got! Now, it turns out, on rereading the message carefully, you didn't really mean 'Yes', since you went on to expand your reply: An "ID-to-flow tagging" packet would setup the flow info in the routers, and for data packets, the flow tag itself would be carried in a Routing Hints field, with the Logical Router field indicating that the Routing Hint is a "flow tag" and not a full address. In fact, both tagging and full addresses could both be used at the same time by the same hardware. It was probably unwise of you to answer with a 'Yes', since it caused (perhaps understandable) confusion. What you did (and I obviously didn't fully grok it at the time, or I would have called you on it) was propose an *alternate* mechanism which did the same thing. However, that wasn't what I was asking! (I could have figured out that hack myself, but I wasn't interested in that!) As a sidelight, let's analyse your proposal. It seems to me that to take the path you propose, you'd either have to i) make lots of local flow id's, in which case you'd have to either tell the source all the local flow id's, so it could put them in the header, or have each switch notify the previous switch of the local flow-id, so the previous switch could modify theheader on the way out, or ii) assign a global flow-id. However, the best way to do this latter option looks just like what we are already talking about; a source-local-unique flow-id, plus a global- unique source id (the EID). Now, if we do what you propose, we'd have to duplicate the source EID in two places in the header; in the ESI, and also in the RH. Since these EID's are pretty big (64, maybe 96 bits), that's fair amount of overhead, and it buys you *zip*. Wouldn't you be better off simply allowing the ESI to be part of the forwarding key? I'd go on at slightly more length, but I see some message from Yakov that need a reply (after I finish a Nimrod thingy :-). Noel From owner-Big-Internet@munnari.oz.au Wed Aug 5 04:32:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21997; Wed, 5 Aug 1992 04:32:07 +1000 (from owner-Big-Internet) Return-Path: Received: from [132.151.1.35] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21994; Wed, 5 Aug 1992 04:32:01 +1000 (from vcerf@NRI.Reston.VA.US) Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05826; 4 Aug 92 14:25 EDT To: Brian Carpenter CERN-CN Cc: big-internet@munnari.oz.au Subject: Re: why not? In-Reply-To: Your message of "Tue, 04 Aug 92 09:44:35 +0700." <9208040744.AA25445@dxcern.cern.ch> Date: Tue, 04 Aug 92 14:25:28 -0400 From: vcerf@NRI.Reston.VA.US Message-Id: <9208041425.aa05826@IETF.NRI.Reston.VA.US> Brian, ISOC would be pleased to take this action on behalf of the iab and ietf if this is desired - it certainly sounds like a reasonable thing to do - just an option to have available if we need it. Vint From owner-big-internet@munnari.oz.au Wed Aug 5 04:37:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22152; Wed, 5 Aug 1992 04:37:49 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19530; Wed, 5 Aug 1992 02:35:14 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11162; Tue, 4 Aug 92 12:35:10 -0400 Date: Tue, 4 Aug 92 12:35:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208041635.AA11162@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, ddc@lcs.mit.edu Subject: Re: Question on Clark's route fragments Cc: Big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu JNC wants a very abstract representation of topology. JNC has to think for a while to decide whether he agrees with this statement. If you go for abstract and general models, then you have to name everything from a uniform name space. Yes, but that doesn't prevent you from being able to easily tell what it is you have named, and in fact I think features to allow you to do that are not just useful but necessary. E.g., just because Unix directories have similar names to files, that doesn't mean a) it's not useful to name them both from the same namespace, or b) that's it's hard to tell, when you've got you hands on one, what you've got. I have argued that it might be worth it to make an architectural distinction between transit AD and terminal ADs. No dispute here; the question is how deep do the effects go? Do you want to be able to tell just by looking at the name of the AD? How about looking at the attributes of the AD as stored in the topology map? Etc, etc. If you look in Nimrod section 6.3, one of the possible proposed ways of doing the 'pick the best carrier to get you to MIT' optimization (we need a better name for that :-) is exactly this different treatment; 'stub' AD's would not appear in the map, unless they were the destinations of traffic. Noel From owner-big-internet@munnari.oz.au Wed Aug 5 04:50:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22364; Wed, 5 Aug 1992 04:50:09 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20870; Wed, 5 Aug 1992 03:35:41 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11816; Tue, 4 Aug 92 13:35:33 -0400 Date: Tue, 4 Aug 92 13:35:33 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208041735.AA11816@ginger.lcs.mit.edu> To: craig@aland.bbn.com, yakov@watson.ibm.com Subject: re: Host Identifier and Location Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, pip@thumper.bellcore.com First, a large fraction of applications will not want to wait for any flow setup to occur. They don't send enough data to amortize effective doubling of the first RTT. Craig, please distinguish a bit between the Resource Allocation aspect of flows, and the Routing and Addressing aspects (Darn, both have RA as their acronym! OK, we call the first one RA/Congestion Avoidiance-Control, or RA/CAC, and the second one R&A) Some of the things you want to do for RA/CAC do have to be end-end, true, and have an unavoidable RTT delay. However, others may not, and the R&A aspects certainly will not. Remember the old ARPANet RA/CAC mechanism, where the request for a reassembly buffer allocation at the destination IMP was sent along with the first fragment? The flow set-up request can carry data, sort of like a TCP SYN. Of course, your *basic* point, that some things don't send enough packets to make an effective amortization of the *overall* cost of flow setup, it quite valid. Thus, both R&A and RA/CAC aspects probably have to have escapes to allow traffic to flow without the setup costs. I used to think that we needed to try this and see whether the costs of providing these escapes cost us more than the benefits, but I am coming to a view (in line with my general feeling on not making resource decisions up front as an architect) where we have to provide these escapes since there probably will be places where theya re just absolutely necessary. Thus, even Nimrod contains a number of *possible* optimizations to avoid setting up a flow if it is not warranted. Section 6.1 contains an optimization that would avoid a flow setup. Section 4.2.2 does not make this clear, unfortunately, but I can also see a place for source routes in packets to prevent dependency loops (as referred to in a number of places). Second, I believe that flow setup may well require negotiation between sender and receiver before the setup request can be made. So there needs to be some way to communicate with a peer before a setup is done. This is a good point. We need to be able to modify the characteristics of a flow (not distinguishing between RA/CAC and R&A flows here deliberately) once it is set up, otherwise we either i) have a dependency loop, or ii) have to set up a second flow, (blargh). Noel From owner-big-internet@munnari.oz.au Wed Aug 5 04:58:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22569; Wed, 5 Aug 1992 04:58:55 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20846; Wed, 5 Aug 1992 03:34:17 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA23783; Tue, 4 Aug 92 10:34:02 PDT Message-Id: <9208041734.AA23783@Mordor.Stanford.EDU> To: Bob Smart Cc: big-internet@munnari.oz.au Subject: Some IPAE issues (was: Re: Some comments/queries on PIP) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Sat, 01 Aug 92 22:34:33 +1000. <9208011234.AA10973@wanda.mel.dit.CSIRO.AU> Date: Tue, 04 Aug 92 10:34:01 -0700 From: Dave Crocker Robert, Your note had some discussion concerning IPAE... [I have only seen announcements for 2 WGs, TUBA and PIP. The IESG specified July for the formation of such groups, but I presume we will see a late announcement for IPAE. Any others? At the IPAE BoF in Boston, we announced the mailing list (ip-encaps-request@sunroof.eng.sun.com) and the intent to issue formal working group papers. The delay on the latter is largely my fault and I hope to get that off my action list by the end of the week. At the BoF we also anounced a meeting/videoconference schedule and held the first such meeting last week. Next one is scheduled for 27 August. I suspect the video sites will remain Sun Mountain View and Boston-area. What about IPAE, doesn't that have fragmentation automatically because it uses the IP4 header and only adds to it? Wrong. The IPAE working group actually pre-dates Boston and had several design meetings. Fragmentation was discussed twice, including at the first meeting. I invite you and others to join in the discussion... Basically, IPAE is trying to add features and fields to its extension header only under duress and after very clear agreement that the world can't live without the enhancement. In other words, we are quite pointed in not claiming to solve the world's future networking needs, instead focusing on the current address-space problem (and any others that come along essentially for free.) To date, we've rejected adding fragmentation. At worst, IPAE forces a datagram to need splitting into two (to account for the number of bytes of the extension header that pushes the datagram over the maximum.) As clearly useful as fragmentation can be, it also is expensive and potentially dangerous. Hence, including it is not an obvious choice. Our feeling so far is that use of MTU discovery and application adjustment of datagram requirements are viable options. (But please note, this is not a religious issue. It is simply a current assessment of the cost-benefit tradeoff.) By the way, the I-D version of the IPAE proposal, in section 4.2.4 IPAC Router Transition Procedures, there is mention of the possible requirement for a IPAE-level fragmentation facility. IPAE-host ------- IP4-router ------ IPAE-border-router ----> Suppose the IPAE-host sends an IPAE packet along this path. The IP4-router knows nothing about IPAE and decides to fragment the packet. The packet is now in two. Fragment1 has the IPAE extended header, but Fragment2 doesn't. In fact the IPAE-border-router _must_ defragment that packet itself before it can forward it. If the resulting packet is Absolutely correct. In such Commonwealths, the IPAE border router must perform reassembly. I can't find that point in the I-D version of the IPAE proposal, but it was discussed at two IPAE meetings, so it looks like a documentation error on my part. Thanks for catching it. Please note that this is a different issue from having IPAE-level fragmentation. ... I submit that we can't use the same fragmentation fields for two very different and incompatible forms of fragmentation. I agree. This, and Craig Partridge's comments about difficulties with ICMP packets in IPAE, show that the IPAE scheme is not as simple as it makes out. And commonwealths will have to keep The proposal cites the need to have IPAE routers forward ICMP messages, so I am unclear what "simplicity" you are asserting IPAE touts incorrectly. My own feeling is that moving mega-nodes of installed base to new infrastructure is inherently complicated. IPAE seeks only to reduce the pain as much as seems feasible and to give users as much control over the timing of the pain as seems feasible. Also, I'll cite a minor escape-hatch that I've become fond of: Many of the "peculiarities" associated with IPAE, such as the ICMP forwarding requirement, come into play iff an addressing commonwealth chooses to operate in old-IP mode. That is, the IP Commonwealth Border Router needs to do clever things if the interior of a commonwealth is sending around IP, not IPAE, packets so that the interior routers are not IP-knowledgeable. While I, personally, feel that the ability to operate in this mode is essential for transition ease and reduced transition cost, it is not required! A commonwealth which has interor routers that are IPAE knowledgeable, for example, would have routers that would send IPAE-level ICMPs directly, thereby eliminating the need for border router translation. In other words, the complexity that you express concern for is strictly an option, though I think an appealin gone. Once again: this is a complicated realm and there do not appear to be any trivial solutions, only ones that move the pain and suffering around and minimize/maxmimize the pain. But pain there will be. splitting up as they run out of IP4 address space internally. But my main concern about IPAE is that the core part of the Network, i.e. America, will get to keep going by reusing our IP4 addresses so we can't talk to them that way. They will also not be under great pressure to implement IPAE so we won't be able to talk to them that way. If we are going to fragement Robert, I agree that what you describe is feasible, but I don't agree that it is likely. I believe that internet-centrism (variant of enthnocentrism) is most likely when the pain and effort of upgrading is maximally disruptive. IPAE seeks to minimize the disruption so that only nodes wishing to communicate with the _full_ internet need to make the change and that they do not need to make large-scale coordination efforts to accomplish this. In the operating system realm, I like to view this as adding one more application, rather than replacing the kernel. Dave From owner-Big-Internet@munnari.oz.au Wed Aug 5 05:02:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22643; Wed, 5 Aug 1992 05:03:00 +1000 (from owner-Big-Internet) Return-Path: Received: from usc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22637; Wed, 5 Aug 1992 05:02:51 +1000 (from estrin%caldera.usc.edu@usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA27577; Tue, 4 Aug 92 12:02:42 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA07990; Tue, 4 Aug 92 12:02:40 PDT Date: Tue, 4 Aug 92 12:02:40 PDT Message-Id: <9208041902.AA07990@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin%caldera.usc.edu@usc.edu To: jnc@ginger.lcs.mit.edu Cc: Big-Internet@munnari.oz.au Subject: Re: Question on Clark's route fragments Reply-To: estrin@usc.edu From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Noel...YOU are the source of the "ack stream" that is clocking in all the responses... :} From owner-Big-Internet@munnari.oz.au Wed Aug 5 05:54:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23780; Wed, 5 Aug 1992 05:54:54 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23776; Wed, 5 Aug 1992 05:54:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14276; Tue, 4 Aug 92 15:54:14 -0400 Date: Tue, 4 Aug 92 15:54:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208041954.AA14276@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, tsuchiya@thumper.bellcore.com Subject: Re: Host Identifier and Location Cc: jnc@ginger.lcs.mit.edu (Boy, first he's at UCL, now he's at Bellcore; good thing we have 'Tsuchiya' as a pretty unique ID; his address keeps changing! :-) Both you and Dave Crocker still seem to be assuming we need a new packet format Real Soon Now (or have you backed off and are only pushing PIP as a router-visible packet format)? I am just astonished that some people in this group are giving serious consideration to staring a two-front war; deploying a new R&A architecture, which is going to be a major hassle, *and* doing a new host-visible packet format. This is folly; why on earth would you bite off two things this size at the same time unless you absolutely had to? A lot of people seem to assume they are connected, but I claim they are not, and still have not heard a good explanation of why the following suggestion which decouples them will not work; I'd like to hear why people think it won't. I propose a deployment plan with a new R&A architecture as an adjunct to the current IP layer, and the current IP header 'address' field re- interpreted as an EID. Note that this is not Nimrod specific; exactly the same scheme can be used with, e.g. IDRP. What won't work? Noel PS: Here's a clip from an older message, giving more details to the argument: ... Nimrod (or any solution) might well decide that we change the *router-visible* header format, but not the one the host sees. ... However, if you accept that: i) we need to add endpoints to the architecture ii) the existing source and destination 'address' fields in the IP packet can be 're-semanticed' to do this iii) a new routing and addressing architecture can be deployed (primarily or entirely in the routers) as an adjunct to the existing packet layer if we do i) and ii) then we only need a new packet format for one of two reasons: i) other fields that we need in packets to make a new R&A architecture work won't fit in the existing host-visible header, and we want to put them in that header, or ii) we run out of 32 bit identifiers Clearly, the second is going to happen, but not in a year or two. We need a new host-visible header before that happens. However, I'm not at all sure about i). A number of people ... have expressed nervousness about a change to the header now being premature. We might end up having to make a similar change *again* at a later date. My thinking is, if this has a chance of being true, and there is *not* a *large* benefit that we *cannot* get without a change to the header now, why take a chance? If we can deploy something in the scaling problem in R&A which in fact does not require a new host-visible packet format, why risk such a cost? What are we gaining? Most folks seem to have decided that we're ostriches if we don't tackle the header problem ASAP. It's true that as time goes on there are more and more hosts to change. This worries me greatly! The sooner we make the change, the argument goes, the better, and it's a good point. On the other hand, if we *do* make a change, and it's *still* not right, then the energies expended in that change are not maximally well spent. What I am hearing from lots of people is that we just don't know enough yet in lots of important areas (resource allocation, congestion avoidance, security architecture, auto-configuration) to do it right. If this is so, waiting may not be bad. Yes, I know about 'the best being the enemy of the good'. I don't see that here. The question is "Can we get the existing format to do 98% of what a new format would do, albeit at some cost (e.g. using options)?" If so, you have to balance two costs; one is the cost of making a change to a new format, the other is what it will cost to kludge keeping going with the existing one. From owner-big-internet@munnari.oz.au Wed Aug 5 06:24:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24291; Wed, 5 Aug 1992 06:24:32 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23230; Wed, 5 Aug 1992 05:29:54 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 4 Aug 92 15:29:44 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Tue, 4 Aug 92 15:29:43 EDT Date: Tue, 4 Aug 92 15:29:43 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208041929.AA02158@chiya.bellcore.com> To: Christian.Huitema@sophia.inria.fr, tsuchiya@thumper.bellcore.com Subject: Re: Host Identifier and Location Cc: avalon@coombs.anu.edu.au, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu > > Then, I would suggest that we launch rapidly an IPv4 based experiment to acquire a > bit more experience with source routing. I know it has been specified for years, > and is supposed to be well known, but I can think of a number of gray areas -- in > fact, it strongly smells like the problem that plague gateway routing of email: I agree that experience is needed here, but some of this is being gotten already with IDPR, although different kinds are needed (for instance, of the non-path-setup variety). But, I still maintain that "basic" Pip (just emulating plain old hierarchical addresses), while definately requiring experimentation, will require less, because it has so much in common with current way of doing things. Meaning, we can install basic Pip over the short term, and experiment with source routing stuff as we go. PT From owner-Big-Internet@munnari.oz.au Wed Aug 5 07:21:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25248; Wed, 5 Aug 1992 07:21:18 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25245; Wed, 5 Aug 1992 07:21:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14797; Tue, 4 Aug 92 17:21:00 -0400 Date: Tue, 4 Aug 92 17:21:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208042121.AA14797@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Packet formats, continued Cc: jnc@ginger.lcs.mit.edu Oh, I forgot another good reason to keep the same packet format going for a while. Any future Internet packet level system, no matter what we do for packet formats, addresses, etc, is going to need a routing architecture. There are precisely two on the table; IDRP/BGP and Nimrod/IDPR. We are going to be running of those two in the future. (Unified is not really a third different option, but a mix of the two, and in any case Nimrod thinks it can do basically the same things in a cleaner fashion, and in fact proposes to so do.) I don't think we are all going to be able to agree on a new routing and addressing architecture; the two camps just have views of the world which differ too widely. (Which reminds me, I have to answer those messages from Yakov...) Given that, I think we are going to see some deployment of competing schemes before a 'decision' is made (as much as the Internet/IETF ever makes 'decisions'). All the operational/product people are going to jump up and down and yell and scream that we can't do this, that this sort of confusion is simply not allowable. Well, I don't think you can prevent it. The IETF is not a police force; it is a reflection of the Internet itself. If a large group of Internet types want to go in one direction, and another group in another, and you can't talk one group out of it (and I doubt either camp can be talked out of it), it is just going to happen, and you might as well figure out how to do it gracefully, and how to get some good out of it. I don't view such a dual deployment as a Bad Thing. I am always in favor of letting experience be a strong guide to design. With two fundamentlaly different choices like this, it's probably wise to experiment a bit and see which works best. People are smart, but not smart enough to make decision like that on desk designs. I don't mean to bash ISO here, but I think the ISO people out there would admit that the reliance on testing and experience was and is one the big strengths of the IETF process. Anyway, where all this is going is that any new R&A solution is going to *have* to be interoperable with the current system; we simply cannot deploy a new thing everywhere overnight. We have to have an interoperable deployment plan to interact with the unmodified parts of the Internet. Given that we have two interoperable schemes anyway, it will be relatively easy to do trial deployments of them both to see which works better. This trial deployment will be much less work and hassle if we don't have to deal with two different packet formats in the hosts. Noel From owner-Big-Internet@munnari.oz.au Wed Aug 5 08:24:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26679; Wed, 5 Aug 1992 08:24:56 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26675; Wed, 5 Aug 1992 08:24:38 +1000 (from kasten@ftp.com) Received: by ftp.com id AA23310; Tue, 4 Aug 92 18:23:17 -0400 Date: Tue, 4 Aug 92 18:23:17 -0400 Message-Id: <9208042223.AA23310@ftp.com> To: jnc@ginger.lcs.mit.edu Subject: Re: Packet formats, continued From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au hmmmmmmm perhaps this leads to a "requirement" for the new IP (or at least its header)... it must be able to support multiple routing/addressing architectures, though those architectures (probably) will not coexist within the same routing space. i.e. may space may use architecture A, protocol A while your space could use architecture B, protocol B. this means that we will have places where "A" butts up against "B" and we will have to do the right thing there. just like we do today where, e.g., igps and egps meet. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Wed Aug 5 10:07:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00274; Wed, 5 Aug 1992 10:07:47 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00270; Wed, 5 Aug 1992 10:07:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16476; Tue, 4 Aug 92 20:07:38 -0400 Date: Tue, 4 Aug 92 20:07:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208050007.AA16476@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kasten@ftp.com Subject: Re: Packet formats, continued Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu it must be able to support multiple routing/addressing architectures, though those architectures (probably) will not coexist within the same routing space. Martha and I had a discussion along these lines a while back, and it turns out you can pretty much do this in Nimrod anyway. First, so little of what we think of when we think of 'routing' is a mandatory part of Nimrod; the route generation algorithm, etc is all local anyway. Second, there is the capability to have multiple addressing heirarchies, if the basic abstraction framework doesn't work well for you; we were talking about having unique names for interfaces, etc, in Nimrod to make multiple hierarchies easier. I mean, what's left?! A topology description language and a topology database transfer protocol? Pretty minimal... Other than destination specified routes (and I'm thinking about those :-), if there anythiong you *can't* do in Nimrod? (Serious request; I'd like a list of capabilities people would like their pet routing architecture to be able to do, which Nimrod can't.) just like we do today where, e.g., igps and egps meet. Something else that makes steam, etc, etc. Bad example! I'm just really down on multiple routing architectures; it makes things really complex, *prevents* you from doing things you want to do, and doesn't get you anything. Why bother? Do *one* and do it right. Selah. Noel From owner-Big-Internet@munnari.oz.au Wed Aug 5 12:28:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05049; Wed, 5 Aug 1992 12:28:20 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05043; Wed, 5 Aug 1992 12:28:14 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 4 Aug 92 22:28:06 EDT Received: by chiya.bellcore.com (4.1/4.7) id for kasten@ftp.com; Tue, 4 Aug 92 22:28:05 EDT Date: Tue, 4 Aug 92 22:28:05 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208050228.AA02796@chiya.bellcore.com> To: jnc@ginger.lcs.mit.edu, kasten@ftp.com Subject: Re: Packet formats, continued Cc: big-internet@munnari.oz.au > it must be able to support multiple routing/addressing architectures, > though those architectures (probably) will not coexist within the same > routing space. i.e. may space may use architecture A, protocol A while > your space could use architecture B, protocol B. this means that we will > have places where "A" butts up against "B" and we will have to do the > right thing there. just like we do today where, e.g., igps and egps meet. > > -- > frank kastenholz Sounds like another good reason for Pip, since Pip can handle multiple different routing algorithsm/addressing schemes. And, with packet tagging, I think dealing with the interface between "A" and "B" becomes easier. PT From owner-Big-Internet@munnari.oz.au Wed Aug 5 13:34:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10043; Wed, 5 Aug 1992 13:34:37 +1000 (from owner-Big-Internet) Return-Path: Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10040; Wed, 5 Aug 1992 13:34:32 +1000 (from hwb@upeksa.sdsc.edu) Received: Tue, 4 Aug 1992 20:34:28 -0700 by upeksa.sdsc.edu (AIX/1.6) From: Hans-Werner Braun Message-Id: <9208050334.AA15566@upeksa.sdsc.edu> Subject: Re: The IP protocol for generations to come. (fwd) To: big-internet@munnari.oz.au Date: Tue, 4 Aug 92 20:34:27 PDT Forwarded message: From root Tue Aug 4 03:24:17 1992 Message-Id: <9208041024.AA11912@upeksa.sdsc.edu> To: Hans-Werner Braun Subject: Re: The IP protocol for generations to come. In-Reply-To: Your message of "Mon, 03 Aug 92 15:57:50 PDT." <9208032257.AA04876@upeksa.sdsc.edu> Date: Tue, 04 Aug 92 11:24:02 +0100 From: Jon Crowcroft >A GUP Protocol Data Unit (GUPPDU) consists of an unlimited sequence of >triplets of the form . how can yo uclaim this is Generic or ultimate - surely you need to supprt n-tuples, for n=0..2**64 so you have <>, <1, value>, <2, type, value>, <3, type, lenght, value> <4, purpose, type, length, value>, <5, intent, purpose, type, length, value>, <6, meaning, intent, purpose, type, length, value>, <7, signification, meaning, intent, purpose, type, length, value> etc... :-) From owner-Big-Internet@munnari.oz.au Wed Aug 5 16:55:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16803; Wed, 5 Aug 1992 16:56:11 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA16799; Wed, 5 Aug 1992 16:55:59 +1000 (from brian@dxcern.cern.ch) Received: from mcsun.EU.net by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA14427; Wed, 5 Aug 92 02:50:26 -0400 Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA26405 (5.65b/CWI-2.173); Wed, 5 Aug 1992 08:46:38 +0200 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA18072; Wed, 5 Aug 92 08:46:55 +0200 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA01033; Wed, 5 Aug 92 08:46:33 +0200 Message-Id: <9208050646.AA01033@dxcern.cern.ch> Subject: Re: Host Identifier and Location To: big-internet@munnari.oz.au Date: Wed, 5 Aug 92 8:46:32 MET DST From: Brian Carpenter CERN-CN In-Reply-To: <9208041954.AA14276@ginger.lcs.mit.edu>; from "Noel Chiappa" at Aug 4, 92 3:54 pm X-Mailer: ELM [version 2.3 PL11 CERN 11] >--------- Text sent by Noel Chiappa follows: > ... > > I am just astonished that some people in this group are giving serious > consideration to staring a two-front war; deploying a new R&A architecture, > which is going to be a major hassle, *and* doing a new host-visible packet > format. This is folly; why on earth would you bite off two things this size at > the same time unless you absolutely had to? Yes, YES, *YES* Thanks for saying this, Noel. Being in charge of an operational network, and of a de facto FIX, I cannot over-state the importance of ensuring that transition to a new R&A architecture implies essentially zero change to campus nets & host software. Otherwise, transition simply won't happen. In fact I joined this list exactly because the transition _frightens_ me. (If you want a living (?) proof look at the DECnet IV to V transition. Sorry, Ross.) Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.oz.au Wed Aug 5 20:53:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24360; Wed, 5 Aug 1992 20:53:46 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24357; Wed, 5 Aug 1992 20:53:42 +1000 (from smart@mel.dit.csiro.au) Received: from manta.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA06369 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 5 Aug 1992 20:53:59 +1000 Received: by manta.mel.dit.CSIRO.AU (4.1/SMI-4.0.1) id AA03671; Wed, 5 Aug 92 20:52:39 EST Message-Id: <9208051052.AA03671@manta.mel.dit.CSIRO.AU> To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: Some IPAE issues (was: Re: Some comments/queries on PIP) In-Reply-To: Your message of "Tue, 04 Aug 92 10:34:01 MST." <9208041734.AA23783@Mordor.Stanford.EDU> Date: Wed, 05 Aug 92 20:52:37 +1000 From: Bob Smart >The proposal cites the need to have IPAE routers forward ICMP >messages, I think Craig Partridge's point was the following: IPAE-hostA -- IPAE-router -- IP4-router -- IPAE-hostB If IPAE-hostA is sending a packet to IPAE-hostB and if IP4-router returns an ICMP it will not have the IPAE address of IPAE-hostA so it won't get back. >My own feeling is that moving mega-nodes of installed base to new >infrastructure is inherently complicated. IPAE seeks only to reduce >the pain as much as seems feasible and to give users as much control >over the timing of the pain as seems feasible. So does miniPIP. I don't try to get away with sending new packets through old routers. The point I was trying to make about IPAE is that it is not as easy to successfully and reliably send new packets through old routers as the first reading of the IPAE doc would suggest. And if you can't do that then perhaps it is better to make better use of the IP4 address space than to start multiply using it which fragments the Internet. > IPAE seeks to minimize the disruption so that >only nodes wishing to communicate with the _full_ internet need to >make the change On the subject of how much people want to do local versus world-wide communication: When AARNet (the Australian branch of the Internet) was still based on 48Kb links to the 6 states, still we had to upgrade our link to the USA from 64Kb to 128Kb. A large proportion of our traffic has always been in to the hub and out to the world. Bob Smart From owner-Big-Internet@munnari.oz.au Wed Aug 5 22:24:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26467; Wed, 5 Aug 1992 22:24:55 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26464; Wed, 5 Aug 1992 22:24:46 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23505; Wed, 5 Aug 92 08:24:36 -0400 Date: Wed, 5 Aug 92 08:24:36 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208051224.AA23505@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, brian@dxcern.cern.ch Subject: Re: Host Identifier and Location Cc: jnc@ginger.lcs.mit.edu Being in charge of an operational network, and of a de facto FIX, I cannot over-state the importance of ensuring that transition to a new R&A architecture implies essentially zero change to campus nets & host software. Otherwise, transition simply won't happen. Brian, a comment, and two questions. Note, everyone, that *any* new R&A architecture (including IDRP) can be deployed in such a way as to meet the constraint that Brian requests. Simply use the identifier trick. Yes, it's not pretty, and unmodified hosts will incur a nasty and dirty expense in the routers (actually, I suppose it doesn't *have* to be in the routers; a router could send a packet for a dest EID which it doesn't have an address for in its cache to a lookup server, possibly the local DNS server or something...). However, a very small change in the hosts (i.e. having get_host_by_name look up both EID and address, and sending the mapping to the routers) makes it operate totally efficiently. First, are you willing to undertake some *slow* (i.e. phased in over some years, at your leisure), *interoperable* change to the packet format as seen by the host, *after* the new R&A architecture is deployed? The reason I ask is that we *are* going to run out of all 2^32 identifiers, and when that day comes, we either a) have to do some variety of NAT (eeccchhh, the thought fills me with fear and loathing), or b) adopt a new packet format. The latter is possibly a good idea for other (security, resource allocation, etc) reasons. Second, how many other network managers out there agree with Brian about the desirability of not changing the hosts, if at all possible to avoid in this phase? Noel From owner-Big-Internet@munnari.oz.au Wed Aug 5 22:49:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26916; Wed, 5 Aug 1992 22:49:27 +1000 (from owner-Big-Internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26913; Wed, 5 Aug 1992 22:49:18 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA13049 (5.65b/CWI-2.173); Wed, 5 Aug 1992 14:49:06 +0200 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA07808; Wed, 5 Aug 92 14:49:22 +0200 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA11401; Wed, 5 Aug 92 14:49:00 +0200 Message-Id: <9208051249.AA11401@dxcern.cern.ch> Subject: Re: Host Identifier and Location To: big-internet@munnari.oz.au Date: Wed, 5 Aug 92 14:48:59 MET DST From: Brian Carpenter CERN-CN In-Reply-To: <9208051224.AA23505@ginger.lcs.mit.edu>; from "Noel Chiappa" at Aug 5, 92 8:24 am X-Mailer: ELM [version 2.3 PL11 CERN 11] Noel, > > Being in charge of an operational network, and of a de facto FIX, I > cannot over-state the importance of ensuring that transition to a new > R&A architecture implies essentially zero change to campus nets & host > software. Otherwise, transition simply won't happen. > > > Brian, a comment, and two questions. > > Note, everyone, that *any* new R&A architecture (including IDRP) can > be deployed in such a way as to meet the constraint that Brian requests. > Simply use the identifier trick. > Yes, it's not pretty, and unmodified hosts will incur a nasty and > dirty expense in the routers (actually, I suppose it doesn't *have* to be in > the routers; a router could send a packet for a dest EID which it doesn't have > an address for in its cache to a lookup server, possibly the local DNS server > or something...). However, a very small change in the hosts (i.e. having > get_host_by_name look up both EID and address, and sending the mapping to the > routers) makes it operate totally efficiently. Makes sense. > > First, are you willing to undertake some *slow* (i.e. phased in over > some years, at your leisure), *interoperable* change to the packet format as > seen by the host, *after* the new R&A architecture is deployed? > The reason I ask is that we *are* going to run out of all 2^32 > identifiers, and when that day comes, we either a) have to do some variety of > NAT (eeccchhh, the thought fills me with fear and loathing), or b) adopt a new > packet format. The latter is possibly a good idea for other (security, > resource allocation, etc) reasons. Yes. My statement above is too black and white. If old and new are interoperable for an indefinite period, even with the restriction that old systems cannot see the whole of the new address space, or can only see it with a performance penalty, it is workable. To be fair to DEC, it is achieving this state which has made the DECnet IV to V transition take years longer than hoped. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 From owner-big-internet@munnari.oz.au Thu Aug 6 01:18:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01960; Thu, 6 Aug 1992 01:18:29 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01017; Thu, 6 Aug 1992 00:48:21 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Wed, 5 Aug 92 10:48:07 EDT Received: by chiya.bellcore.com (4.1/4.7) id for brian@dxcern.cern.ch; Wed, 5 Aug 92 10:48:05 EDT Date: Wed, 5 Aug 92 10:48:05 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208051448.AA03491@chiya.bellcore.com> To: big-internet@munnari.oz.au, brian@dxcern.cern.ch Subject: Re: Host Identifier and Location > > Yes. My statement above is too black and white. If old and new are > interoperable for an indefinite period, even with the restriction that > old systems cannot see the whole of the new address space, or can only > see it with a performance penalty, it is workable. To be fair to DEC, > it is achieving this state which has made the DECnet IV to V transition > take years longer than hoped. > It seems to me that all the proposals have this characteristic. The ROAD group decided early on that we would have to float old-style IP hosts for a long time. The question is, what is the pain caused by floating old-style hosts with regards to each of the schemes. Also, I agree with Noel (I think Noel said this, but he owes me one mis-quote, so it is alright even if he didn't :-), that pretty much any of the transition schemes can be applied to any of the new protocols. PT From owner-big-internet@munnari.oz.au Thu Aug 6 01:34:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02493; Thu, 6 Aug 1992 01:34:26 +1000 (from owner-big-internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00612; Thu, 6 Aug 1992 00:34:59 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA00117; Wed, 5 Aug 92 07:34:45 PDT Message-Id: <9208051434.AA00117@Mordor.Stanford.EDU> To: Bob Smart Cc: big-internet@munnari.oz.au Subject: Re: Some IPAE issues (was: Re: Some comments/queries on PIP) Org: The Branch Office, Sunnyvale CA Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 05 Aug 92 20:52:37 +1000. <9208051052.AA03671@manta.mel.dit.CSIRO.AU> Date: Wed, 05 Aug 92 07:34:44 -0700 From: Dave Crocker Bob, I'm not sure that detailed, technical explication of the proposals is appropriate to this list, and I certainly hope that we don't move into IPAE-hostA -- IPAE-router -- IP4-router -- IPAE-hostB If IPAE-hostA is sending a packet to IPAE-hostB and if IP4-router returns an ICMP it will not have the IPAE address of IPAE-hostA so it won't get bac k. The IPAE-router, serving as a 'border router' must perform explicit ICMP relaying. That is what the reference in the IPAE proposal (admittedly a _very_ brief reference, but then it was only a proposal...) is trying to say. The IP4-router in your example will generate ICMP messages which it thinks are for IPAE-router. IPAE-router will get it and have to re-write the destination address to be IPAE-hostA. In other words, border routers must support the unusual features of ICMP-relaying and IP reassembly as part of their router functions. >My own feeling is that moving mega-nodes of installed base to new >infrastructure is inherently complicated. IPAE seeks only to reduce >the pain as much as seems feasible and to give users as much control >over the timing of the pain as seems feasible. So does miniPIP. I don't try to get away with sending new packets through old routers. The point I was trying to make about IPAE is that it is not In other words, an end-to-end path, through the relevant parts of the Internet, must be converted to miniPIP before end-systems can obtain service? as easy to successfully and reliably send new packets through old routers as the first reading of the IPAE doc would suggest. And if you can't do Well, we did try to list the issues we saw. Sorry they didn't stand out enough... that then perhaps it is better to make better use of the IP4 address space than to start multiply using it which fragments the Internet. Bob, in may people's view, "making better use of IP4 address space" is at best a very, very short-term approach and we simply must create more addressing bits Real Soon Now. > IPAE seeks to minimize the disruption so that >only nodes wishing to communicate with the _full_ internet need to >make the change On the subject of how much people want to do local versus world-wide communication: When AARNet (the Australian branch of the Internet) was still based on 48Kb links to the 6 states, still we had to upgrade our link to the USA from 64Kb to 128Kb. A large proportion of our traffic has always been in to the hub and out to the world. Different question: How many of your hosts and how many of your routers need to know about and directly use that link? Dave From owner-Big-Internet@munnari.oz.au Thu Aug 6 02:35:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04336; Thu, 6 Aug 1992 02:35:41 +1000 (from owner-Big-Internet) Return-Path: Received: from mts-gw.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04332; Thu, 6 Aug 1992 02:35:31 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA21028; Wed, 5 Aug 92 09:35:08 -0700 Received: by sneezy (5.57/ULTRIX-4.2-3)id AA20134; Wed, 5 Aug 92 12:35:06 -0400 Subject: Re: Some comments/queries on PIP To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Cc: tsuchiya@thumper.bellcore.com X-Mailer: Poste 2.0B3 From: Dave Oran Date: Wed, 5 Aug 92 12:35:02 -0400 Message-Id: <920805123502.19811@sneezy.lkg.dec.com> From Bob Smart's comment and Paul Tsuchiya's reply... >> >> Because we don't see fragmentation as existing in the long term >> it should be implemented as an option so it doesn't normally >> take space in a packet header. >> >Interesting idea. Which was incorporated by the dreaded, awful, obsolete, complicated, hard-to-parse, too big CLNP in 1983. :-) :-) From owner-big-internet@munnari.oz.au Thu Aug 6 03:02:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05114; Thu, 6 Aug 1992 03:02:42 +1000 (from owner-big-internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03594; Thu, 6 Aug 1992 02:13:45 +1000 (from craig@aland.bbn.com) Received: from port12.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA21735; Wed, 5 Aug 92 12:13:31 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA08899; Wed, 5 Aug 92 09:13:13 PDT Message-Id: <9208051613.AA08899@aland.bbn.com> To: Dave Crocker Cc: big-internet@munnari.oz.au Subject: Re: Some IPAE issues (was: Re: Some comments/queries on PIP) From: Craig Partridge Date: Wed, 05 Aug 92 09:13:13 -0700 Sender: craig@aland.bbn.com >> IPAE-hostA -- IPAE-router -- IP4-router -- IPAE-hostB >> > The IPAE-router, serving as a 'border router' must perform explicit > ICMP relaying. Right, except the IPAE router can't do this because the ICMP header will only inlude the first 8 bytes of the IPAE header (which is the reserved bits, E-bit, protocol field, checksum, and first four bytes of the IPAE src address). So the IPAE router can't relay the ICMP request because it doesn't know who to relay it to. The ICMP spec has to be changed for this work, and we're assuming the IP4 router doesn't change. Craig From owner-big-internet@munnari.oz.au Thu Aug 6 03:11:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05315; Thu, 6 Aug 1992 03:11:36 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04606; Thu, 6 Aug 1992 02:45:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26349; Wed, 5 Aug 92 12:45:02 -0400 Date: Wed, 5 Aug 92 12:45:02 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208051645.AA26349@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, brian@dxcern.cern.ch, tsuchiya@thumper.bellcore.com Subject: Re: Host Identifier and Location Cc: jnc@ginger.lcs.mit.edu Also, I agree with Noel (I think Noel said this, but he owes me one mis-quote, so it is alright even if he didn't :-), that pretty much any of the transition schemes can be applied to any of the new protocols. Well, Noel did sort of say this, so I'll let you get away with it! I'd like to beg to differ on my error, though: I didn't so much mis-quote, as *incompletely* quote.... Grrr, people who mean 'no' and say 'yes'! :-) Noel From owner-Big-Internet@munnari.oz.au Thu Aug 6 03:19:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05652; Thu, 6 Aug 1992 03:19:44 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05639; Thu, 6 Aug 1992 03:19:24 +1000 (from craig@aland.bbn.com) Received: from port12.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA26345; Wed, 5 Aug 92 13:19:02 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA08967; Wed, 5 Aug 92 10:18:54 PDT Message-Id: <9208051718.AA08967@aland.bbn.com> To: big-internet@munnari.oz.au Subject: my protocol does that too! Reply-To: Craig Partridge From: Craig Partridge Date: Wed, 05 Aug 92 10:18:54 -0700 Sender: craig@aland.bbn.com Hi folks: Maybe I'm over sensitive but it seems like I'm seeing a whole bunch of messages of the form "I think Y is a good idea and by the way, proposal XXX which I support already does Y." I realize that there's an attempt to develop support for various proposals but I'd prefer to see notes of the form "I think Y is a rotten idea because..." or "Y is a nice idea because it supports...." I'm much more interested in elucidating issues at this stage. I also understand there's a fine line. For example, I've found some of Bob Smart's notes asking detailed questions about various proposals very valuable because I think he's pointing up important questions through his studies of the various protocols. So I'm not asking that we don't mention IPAE, PIP, Nimrod or even the dreaded TUBA :-). But could we turn down the advertising music? Thanks! Craig E-mail: craig@aland.bbn.com or craig@bbn.com From owner-Big-Internet@munnari.oz.au Thu Aug 6 03:50:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06536; Thu, 6 Aug 1992 03:50:48 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06530; Thu, 6 Aug 1992 03:50:39 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Wed, 5 Aug 92 13:50:27 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Wed, 5 Aug 92 13:50:26 EDT Date: Wed, 5 Aug 92 13:50:26 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208051750.AA03819@chiya.bellcore.com> To: big-internet@munnari.oz.au, brian@dxcern.cern.ch, jnc@ginger.lcs.mit.edu, tsuchiya@thumper.bellcore.com Subject: Re: Host Identifier and Location > > Well, Noel did sort of say this, so I'll let you get away with it! I'd like > to beg to differ on my error, though: I didn't so much mis-quote, as > *incompletely* quote.... Grrr, people who mean 'no' and say 'yes'! :-) > > Noel > Come on Noel, we all know that incomplete quotes (that is, quoting out of context) is the most insidious kind, used by sleazy politicians the world over. Not that I'm accusing you of intentional incomplete qouting...... :-) PT From owner-Big-Internet@munnari.oz.au Thu Aug 6 04:13:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07019; Thu, 6 Aug 1992 04:14:02 +1000 (from owner-Big-Internet) Return-Path: Received: from mts-gw.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07016; Thu, 6 Aug 1992 04:13:53 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA26154; Wed, 5 Aug 92 11:13:35 -0700 Received: by sneezy (5.57/ULTRIX-4.2-3)id AA20382; Wed, 5 Aug 92 14:13:33 -0400 To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Subject: Segmentation and PIP (was comments/queries on PIP) In-Reply-To: <9208051748.AA03799@chiya.bellcore.com> References: <9208051748.AA03799@chiya.bellcore.com> Cc: big-internet@munnari.oz.au, smart@mel.dit.csiro.au X-Mailer: Poste 2.0B3 From: Dave Oran Date: Wed, 5 Aug 92 14:13:30 -0400 Message-Id: <920805141330.19811@sneezy.lkg.dec.com> > BTW Dave, what is your opinion as to whether the new protocol > should have segmentation or not......? > Hmmm... this would take a long time to go through. Let me try in a nutshell what my thinking on segmentation is. 1. Segmentation is ugly. 2. Segmentation is very hard to implement fast on the existing protocols 3. Since the assumption is made by most switch/router vendors that packets needing segmentation are a very small percentage of the traffic, the implementation is so slow as to be crippling. 4. Segmentation is necessary unless: a) we can agree on a "Maximum MAximum" MTU for the whole internet (good luck) b) cut through ala ATM is universally implemented so that MTU-sized packets never have to be completely buffered in routers c) fast packet memories become so cheap and functional that scatter-gather I/O can prevent early binding of buffer resources to arriving packets. d) We can change all the transport protocols so that they can re-segment already-transmitted data if the chosen segment size was too big (TCP is ok on this, UDP will produce duplicates, and TP4 falls over. I don't know about IPX and friends, XTP or other beasties) I think the ideal situation would be to design the protocol so that segmentation can be done in the fast path, reassembly in the hosts is cheap (and do-able directly in user rather than kernel memory) and then make fast Segmentation mandatory. UNFORTUNATELY, I have no idea how to accomplish this, technically or politically. What I think is realistic is to build better support for MTU discovery into the base protocol and the associated routing protocols so that the heavy price for segmenting is in fact paid on only a few packets. Getting rid of segmentation entirely and relying on MTU discovery to converge doesn't appeal to me because it introduces too much startup delay for infrequent and/or delay-sensitive applications. This sufficient prevarication for your tastes? Dave :-) From owner-Big-Internet@munnari.oz.au Thu Aug 6 04:58:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07983; Thu, 6 Aug 1992 04:58:19 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07977; Thu, 6 Aug 1992 04:58:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28078; Wed, 5 Aug 92 14:58:00 -0400 Date: Wed, 5 Aug 92 14:58:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208051858.AA28078@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Subject: re: Re: Some comments/queries on PIP (ID vs rest of address) Cc: jnc@ginger.lcs.mit.edu We might assume that the rest of the address (what I have been calling "location"), contains enough information to get you "close" to the destination. For example, it might get you to the subnet (if you route to subnets) or to the area. We need to either (i) Include the global ID in the same packet level as the rest of the address (so that the last part of the route can be followed, such as from a router on the right subnet to the host), or (ii) include another local ID in the packet (i.e., have a "location" part of the address which gets you all the way to the right host, not just to the right subnet or area). Ross, this is very similar to some thoughts I had when I was fighting the battle about whether or not to flush ARP. I don't think that it makes a lot of difference which approach we use. The first approach (consider the global ID to be the low order part of the address) saves a few bytes, but I am dubious as to whether the number of bytes saved will be significant given how many bytes are likely to be needed to accomplish global routing in an internet with 10^9 routing domains. The most important reason to use the gloabl, as opposed to local, ID is simplicity. If you have a local identifier which is not automatically generated (e.g. 48 bit IEEE interface addresses), it's just one more namespace you have to manage (like host numbers on an Ethernet now in IP), although we could do it automatically, like Appletalk. Howver, this isn't the real question, which is "to what degree do you want local name binding (i.e. EID -> actual interface) info to flow out into the larger world"? In other words, maybe your address *doesn't* identify an interface, but rather a name binding context in which the system is prepared to map your global ID (which you have to have, along with this 'partial' address) into a full interface address, but only on a local basis, so that the binding is not visible outside the context. Smaller contexts mean less invisible dynamicity, but probably smaller costs to manage the local binding process. To give an example, think of the existing ARP system as this working on a one-network scale; the net number (plus subnet, if needed) identify a name-binding context; the host number is the ID (local, I know, but that's just 'cause IP is so brain-damaged :-), and ARP is the name-binding process. Clearly, you have some invisible dynamicity (you can change Ethernet cards and nobody outside your network cares), it's not widespread (you can't change subnets without telling people), and it's cost is directly related to the size of the context size (the cost of ARP type solutions go up as the size of a single ARP translation domain, i.e. network, increases). Noel From owner-big-internet@munnari.oz.au Thu Aug 6 05:04:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08081; Thu, 6 Aug 1992 05:04:25 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07391; Thu, 6 Aug 1992 04:32:43 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Wed, 5 Aug 92 14:32:30 EDT Received: by chiya.bellcore.com (4.1/4.7) id for craig@aland.bbn.com; Wed, 5 Aug 92 14:32:29 EDT Date: Wed, 5 Aug 92 14:32:29 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208051832.AA03955@chiya.bellcore.com> To: big-internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: my protocol does that too! > studies of the various protocols. So I'm not asking that we don't mention > IPAE, PIP, Nimrod or even the dreaded TUBA :-). But could we turn down the > advertising music? > By the way, Pip is an excellent protocol for controlling advertising music volume. PT From owner-big-internet@munnari.oz.au Thu Aug 6 07:05:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10265; Thu, 6 Aug 1992 07:05:40 +1000 (from owner-big-internet) Return-Path: Received: from mts-gw.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05254; Thu, 6 Aug 1992 03:08:29 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA22756; Wed, 5 Aug 92 10:08:20 -0700 Received: by sneezy (5.57/ULTRIX-4.2-3)id AA20177; Wed, 5 Aug 92 13:08:13 -0400 To: Ross Callon Cc: desjardi@boa.gsfc.nasa.gov, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: re: Host identifier length In-Reply-To: <9208032137.AA15435@us1rmc.bb.dec.com> References: <9208032137.AA15435@us1rmc.bb.dec.com> X-Mailer: Poste 2.0B3 From: Dave Oran Date: Wed, 5 Aug 92 13:08:08 -0400 Message-Id: <920805130808.19811@sneezy.lkg.dec.com> > > This may seem like a small detailed nit, but we might want to think > somewhat about how large a global host ID would need to be. > Does the ID need to provide only spacial uniqueness, or temporal uniqueness as well? If only the former, then 64 bits is likely to be enough. Even 48 bits is probably adequate, if the granularity is what we now associate with an Internet host, and as long as the cost of getting one can be in the $1.00 range and not in the $.001 range, so that the administration can be appropriately subsidized. Things that might break this assumption is for example, a) if there were strong engineering reasons to associate a global host ID with every processor in an MPP. (Don't laugh, this might not be so unreasonable since some form of network-level parallelism is going to be needed to get around the serial network bottlenecks we're already seeing with this class of machines. b) if every light bulb, switch, etc. in every house is a host. However, I would like to at least ask if temporal uniqueness is not also an important property for host identifiers. If so, 64 bits is NOT adequate. In fact, if the identifiers need to have both spacial and temporal uniqueness, then a ready-made standard already exists for these: UUIDs. These are used by the NCS and OSF RPCs and are 128 bits long, and have reasonably fast code available for generating them, checking them, etc. I know 128 bits is awfully big, and you need two of the beasts in every packet. Just asking... From owner-big-internet@munnari.oz.au Thu Aug 6 07:22:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10581; Thu, 6 Aug 1992 07:22:31 +1000 (from owner-big-internet) Return-Path: Received: from boa-f.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06387; Thu, 6 Aug 1992 03:45:23 +1000 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.57/Ultrix3.0-C) id AA01971; Wed, 5 Aug 92 13:44:54 -0400 Message-Id: <9208051744.AA01971@boa.gsfc.nasa.gov> Subject: re: Host identifier length To: oran@sneezy.lkg.dec.com (Dave Oran) Date: Wed, 5 Aug 92 13:44:54 EDT From: Dick desJardins Cc: big-internet@munnari.oz.au In-Reply-To: <920805130808.19811@sneezy.lkg.dec.com>; from "Dave Oran" at Aug 5, 92 1:08 pm X-Mailer: ELM [version 2.3 PL11] Dave, The thing identified with the host identifier (endpoint ID) is the Transport entity implementation. That's the destination that you're trying to reach through the internetwork, so that is what has to be globally unique. 64 bits looks right for that by all the arguments that have been brought up, and even that is not necessary for the mid-term, only for the future. In mid-term, you have to support IEEE style 48-bit IDs and current IP addresses used as IDs, which means a six-byte scheme will work in the mid-term. The thing identified with the UUID is, I believe, the Application entity instance, which has temporal aspects, and probably most of the parallelism aspects of MPP implementations although that could be debated, I suppose. OSI ACSE uses object identifiers for the unique calling and called entities. These are variable length, but they are globally unique. In any event, they're longer than 64 bits. In summary, I don't believe application entity instance identifiers (or whatever they're called) are bound by the "host identifier" fixed-length criteria being discussed in this topic. Dick From owner-big-internet@munnari.oz.au Thu Aug 6 07:33:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10801; Thu, 6 Aug 1992 07:33:28 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06522; Thu, 6 Aug 1992 03:50:09 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Wed, 5 Aug 92 13:48:32 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Wed, 5 Aug 92 13:48:30 EDT Date: Wed, 5 Aug 92 13:48:30 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208051748.AA03799@chiya.bellcore.com> To: big-internet@munnari.oz.au, oran@sneezy.lkg.dec.com, smart@mel.dit.csiro.au Subject: Re: Some comments/queries on PIP Cc: tsuchiya@thumper.bellcore.com > > >From Bob Smart's comment and Paul Tsuchiya's reply... > >> > >> Because we don't see fragmentation as existing in the long term > >> it should be implemented as an option so it doesn't normally > >> take space in a packet header. > >> > >Interesting idea. > > > Which was incorporated by the dreaded, awful, obsolete, complicated, > hard-to-parse, too big CLNP in 1983. > > :-) :-) > Gee, I didn't know that. But after I wiped the egg off of my face and looked at the spec, I see that it is not a normal option, but a pseudo-fixed part of the header. That is, if the "Segmentation Permitted" bit is set, then the segmentation part of the header is in a fixed place. So, I was only half wrong. BTW Dave, what is your opinion as to whether the new protocol should have segmentation or not......? PT From owner-big-internet@munnari.oz.au Thu Aug 6 07:51:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11217; Thu, 6 Aug 1992 07:51:08 +1000 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08243; Thu, 6 Aug 1992 05:12:26 +1000 (from kasten@ftp.com) Received: by ftp.com id AA20917; Wed, 5 Aug 92 15:12:07 -0400 Date: Wed, 5 Aug 92 15:12:07 -0400 Message-Id: <9208051912.AA20917@ftp.com> To: oran@sneezy.lkg.dec.com Subject: Re: Segmentation and PIP (was comments/queries on PIP) From: kasten@ftp.com (Frank Kastenholz) Cc: tsuchiya@thumper.bellcore.com, big-internet@munnari.oz.au, smart@mel.dit.csiro.au dave, > b) cut through ala ATM is universally implemented so that MTU-sized > packets never have to be completely buffered in routers i wouldn't worry about having to buffer MTU-sized packets in routers. the router has to be able to deal with full sized packets for all of its local interfaces -- e.g. the routing protocols might send MTU-sized packets. > c) fast packet memories become so cheap and functional that > scatter-gather I/O can prevent early binding of buffer resources to > arriving packets. scatter-gather, or its lack, seems to be more a function of the i/o interface chip designers and not due to memory constraints. e.g. for ethernet chips, the intel and amd parts will do scatter-gather while the nat'l semi (at least i think its ns) parts do not. > d) We can change all the transport protocols so that they can re-segment > already-transmitted data if the chosen segment size was too big (TCP is > ok on this, UDP will produce duplicates, and TP4 falls over. I don't > know about IPX and friends, XTP or other beasties) the big loss for fragmentation is that if one fragment is lost then the entire stream of fragments must end up being retransmitted since there is no ack-ing of the individual fragments. -- frank kastenholz From owner-big-internet@munnari.oz.au Thu Aug 6 08:05:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11534; Thu, 6 Aug 1992 08:05:59 +1000 (from owner-big-internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09050; Thu, 6 Aug 1992 05:46:52 +1000 (from milt@tenon.com) Received: from mawby.tenon.com (mawby.slip.tenon.com) by shark.mel.dit.csiro.au with SMTP id AA11396 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 6 Aug 1992 05:36:42 +1000 Received: from [192.83.246.5] (parson.tenon.com) by mawby.tenon.com (4.0/SMI-4.1) id AA00418; Wed, 5 Aug 92 12:35:27 PDT Date: Wed, 5 Aug 92 12:35:26 PDT Message-Id: <9208051935.AA00418@mawby.tenon.com> To: big-internet@munnari.oz.au From: milt@tenon.com Subject: Re: my protocol does that too! > Maybe I'm over sensitive but it seems like I'm seeing a whole bunch >of messages of the form "I think Y is a good idea and by the way, proposal >XXX which I support already does Y." > >E-mail: craig@aland.bbn.com or craig@bbn.com Is there agreement on a problem definition that proposals XXX thru ZZZ are solving? In many cases we're comparing proposals that solve different problems. Until there is a complete shopping list of "must have" features for the "IP of the future" many of these comparative discussions will degrade into religious wars. The closest thing to this list that I've seen posted was the IAB's now retracted announcement that called for CLNP to become IP7, but that didn't mention policy routing support or many of the issues that have become major threads of discussion. Is there currently an effort (maybe in the IAB) to generate this list? milt Milt Roselinsky milt@tenon.com Tenon Intersystems (805) 963-6983 1123 Chapala St. Santa Barbara, Ca. 93101 From owner-big-internet@munnari.oz.au Thu Aug 6 08:34:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12086; Thu, 6 Aug 1992 08:34:50 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10103; Thu, 6 Aug 1992 06:57:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA29016; Wed, 5 Aug 92 16:57:28 -0400 Date: Wed, 5 Aug 92 16:57:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208052057.AA29016@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: my protocol does that too! Cc: jnc@ginger.lcs.mit.edu I'm seeing a whole bunch of messages of the form "I think Y is a good idea and by the way, proposal XXX which I support already does Y." I realize that there's an attempt to develop support for various proposals... But could we turn down the advertising music? Craig, I can't speak for everyone, but let me offer one somewhat more charitable explanation for why I at least am doing this. (Motivations, we all remember them, right? And we don't speculate about them, right!?) I have discovered a great number of cases in which people had misapprehensions (for a variety of reasons, including length document, terminology problems, etc) about what Nimrod did and why it did it. We have seen instances of people (e.g. me :-) misunderstanding other proposals (e.g. PIP :-). In such an atmosphere, it's very natural to, when discussing feature X, to say "and proposal Y also does X", because experience has shown that probably a good number of people out there *simply don't realize* that Y *can do* X. Having said that, your general point (keep the advertising for a *particular scheme* down) is well put, but it *is* a fine line, particularly in the IETF, where what tends to be adopted are *protocols*, not *architectural principles*. The only way to get an AP you believe in adopted, sometimes, is to get the protocol it is embodied in adopted. Hence the advertising... Noel From owner-big-internet@munnari.oz.au Thu Aug 6 12:28:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18280; Thu, 6 Aug 1992 12:28:29 +1000 (from owner-big-internet) Return-Path: Received: from p.lanl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13663; Thu, 6 Aug 1992 09:43:45 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA03804; Wed, 5 Aug 92 17:43:30 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA23132; Wed, 5 Aug 92 17:43:29 MDT Message-Id: <9208052343.AA23132@goshawk.lanl.gov> To: brian@dxcern.cern.ch Cc: big-internet@munnari.oz.au Subject: Re: Host Identifier and Location Date: Wed, 05 Aug 92 17:43:29 MST From: peter@goshawk.lanl.gov Brian, Are you, or are you planning on, running any other network protocol other than IP at CERN? More specifically, is CERN running as part of the international DECNET phase IV network and do you plan to support CLNP in the future? Would you have any interest in using a similar routing and addressing architecture for IP and CLNP? Thanks for your insight into these matters, peter peter@lanl.gov From owner-big-internet@munnari.oz.au Thu Aug 6 13:33:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20283; Thu, 6 Aug 1992 13:33:51 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15815; Thu, 6 Aug 1992 11:13:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01269; Wed, 5 Aug 92 21:11:42 -0400 Date: Wed, 5 Aug 92 21:11:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208060111.AA01269@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, milt@tenon.com Subject: Re: my protocol does that too! Cc: jnc@ginger.lcs.mit.edu Until there is a complete shopping list of "must have" features for the "IP of the future" many of these comparative discussions will degrade into religious wars. The closest thing to this list that I've seen posted was the IAB's now retracted announcement that called for CLNP to become IP7, but that didn't mention policy routing support or many of the issues that have become major threads of discussion. For the routing half of the equation, there's always RFC-1126, "Goals and functional requirements for inter-autonomous system routing." In addition to Mike Little's useful rundown, it includes Appendix A, which was the collected/combined output of the Open Routing WG's *years* (and I do not exaggerate :-) of thought/debate on the subject of exactly what a new routing architecture should do. (Lots of alumni of those days making noise here; hi to all of you! :-) For the new packet half, well, I won't get in to that again... If some people want to tilt at windmills, the Nimrods won't argue! :-) Noel From owner-Big-Internet@munnari.oz.au Thu Aug 6 14:47:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22498; Thu, 6 Aug 1992 14:47:15 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22493; Thu, 6 Aug 1992 14:47:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02226; Thu, 6 Aug 92 00:47:01 -0400 Date: Thu, 6 Aug 92 00:47:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208060447.AA02226@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kasten@ftp.com Subject: re: ID vs rest of address (long geneology omitted) Cc: big-internet@munnari.oz.au From reading your message, I think I was a bit too cryptic in my comments. What I was talking about was: do 'addresses' (JNC definition :-) specify a single interface by themselves, or do they do so *in conjunction with* the EID? I.e., do you have to go through some further resolution phase when you get close to the destination, e.g. ARP? There is no connection here to IEEE 48 bit numbers; ask yourself this question in a world in which the EID's have *no relationship* to IEEE 48's. regardless of how my eid was created, you can not, you should not, you must not assume that the numbers actually mean anything. for eids for which there is a hardware address mapping... These two statements seem to be in direct conflict. Either the EID's don't mean *anything* (except that they are unique names), or they do. Which is it? (I claim they don't; they are just globally unique names.) suppose that host 1 is a multi-homed host with interfaces A and B on ... arp for the hardware address of the eid in the packets. This problem goes away if you don't assume the EID is *anything* but a unique name. should the eid be decoupled from the addressable network entity (node) Well, I don't know about you, but to me an EID never had anything to do with nodes. It's simply a name for (effectively) one end of a TCP connection; i.e. an end-end entity (i.e. *something* which is one end of end-end things like checksums, etc). i think that, maybe, the eid should be limited to being some addressable box on the net Terminology alert: to me, an 'address' is the structured name of a network interface. I know 'address' is an existing term, and is way overloaded with meanings, but either we have to agree on a strict one or give up using it. any further subdivision ought to be left to the protocol numbers and port numbers and so on No problem here! Noel From owner-big-internet@munnari.oz.au Thu Aug 6 15:04:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22830; Thu, 6 Aug 1992 15:04:21 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18240; Thu, 6 Aug 1992 12:27:43 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA23614; Wed, 5 Aug 92 19:27:38 -0700 Received: by us1rmc.bb.dec.com; id AA13472; Wed, 5 Aug 92 22:24:53 -0400 Message-Id: <9208060224.AA13472@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Wed, 5 Aug 92 22:24:53 EDT Date: Wed, 5 Aug 92 22:24:53 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 05-Aug-1992 2227" To: clynn@bbn.com Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au Subject: RE: Re: Host Identifier and Location Assume 96 bit host IDs. If the CI (connection id) is unique when coupled with just the source ID and you allow really big servers, I think it has to be more than 16 bit, probably 32, even if the handling of similar flows to he same destination are aggregated. So you are doing some sort of hash lookup on 128 bits. Alternatively, how many bits would it take to make the flow unique in the context of both the source and destination IDs? I think 8 bits would be more than enough. True, you could have thousands of connections between the partcular source and destination but, as a practical matter, they would usually need to be aggregated. (It does not seem reasonable to burden dozens of intervening routers with the detailed specs of thousands of connections between a particular source/destination pair any more than it seems reasonable for them to keep track of routes to zillions of individual hosts. Seems like a good idea for this aggregation of flows to be done in the host.) So you have a flow identified by 2*96 + 8 or 200 bits. Is it worth adding a 32 bit CI field to have to hash on 128 bits instead of 200 bits? (Feel free to plug your own numbers into the calculations above.) Donald -------------- From: US1RMC::"clynn@BBN.COM" "Charles Lynn" 31-JUL-1992 10:19 To: Paul Tsuchiya CC: big-internet@munnari.oz.au, pip@thumper.bellcore.com Subj: Re: Host Identifier and Location Folks, Have we agreed to accept the "CI" field for flow identification? If so, it sounds like it ought to be positioned next to the source host ID as that combination uniquely identifies the flow. Charlie From owner-Big-Internet@munnari.oz.au Thu Aug 6 16:44:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25786; Thu, 6 Aug 1992 16:44:43 +1000 (from owner-Big-Internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25773; Thu, 6 Aug 1992 16:44:28 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA06299 (5.65b/CWI-2.173); Thu, 6 Aug 1992 08:44:05 +0200 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA24098; Thu, 6 Aug 92 08:44:20 +0200 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA11354; Thu, 6 Aug 92 08:43:58 +0200 Message-Id: <9208060643.AA11354@dxcern.cern.ch> Subject: Re: Some comments/queries on PIP To: big-internet@munnari.oz.au Date: Thu, 6 Aug 92 8:43:57 MET DST From: Brian Carpenter CERN-CN In-Reply-To: <920805123502.19811@sneezy.lkg.dec.com>; from "Dave Oran" at Aug 5, 92 12:35 pm X-Mailer: ELM [version 2.3 PL11 CERN 11] >--------- Text sent by Dave Oran follows: > > >From Bob Smart's comment and Paul Tsuchiya's reply... > >> > >> Because we don't see fragmentation as existing in the long term > >> it should be implemented as an option so it doesn't normally > >> take space in a packet header. > >> > >Interesting idea. > > > Which was incorporated by the dreaded, awful, obsolete, complicated, > hard-to-parse, too big CLNP in 1983. > > :-) :-) > Dave, I am *not* necessarily endorsing CLNP as a protocol of the future, (unlike at least one Boston-based computer company :-) ), but when I implemented a toy version of CLNP in 1984, only about 200 lines of code out of 1500 were dedicated to fragmentation/reassembly. Admittedly designing that part requires an ice-pack on the brain. Don't exagerrate the overhead, especially if it's an option. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 From owner-Big-Internet@munnari.oz.au Thu Aug 6 18:10:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27561; Thu, 6 Aug 1992 18:11:11 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9208060811.27561@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27553; Thu, 6 Aug 1992 18:10:58 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 6 Aug 1992 08:28:47 +0100 To: Dave Oran Cc: tsuchiya@thumper.bellcore.com (Paul Tsuchiya), big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: Segmentation and PIP (was comments/queries on PIP) In-Reply-To: Your message of "Wed, 05 Aug 92 14:13:30 EDT." <920805141330.19811@sneezy.lkg.dec.com> Date: Thu, 06 Aug 92 08:28:41 +0100 From: Jon Crowcroft >I think the ideal situation would be to design the protocol so that >segmentation can be done in the fast path, reassembly in the hosts >is cheap (and do-able directly in user rather than kernel memory) >and then make fast Segmentation mandatory. actually, i've always been puzzled at this - many network interfaces support scatter gather read/write dma - system call code implements read/write vector of buffers - so all you code has to do is shuffle a few points, i.e. IP can sort fragments, tcp just has to sort segments assuming a) the device drivers are written to use this (rare - rarer than doing multicast groups:-), and applkciations are written to use read/write vector interfaces... you then get a zero copy stack j. From owner-Big-Internet@munnari.oz.au Thu Aug 6 23:14:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03601; Thu, 6 Aug 1992 23:15:01 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9208061315.3601@munnari.oz.au> Received: from CLynn.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03588; Thu, 6 Aug 1992 23:14:47 +1000 (from clynn@BBN.COM) Date: Thu, 6 Aug 92 9:11:58 EDT From: Charles Lynn To: big-internet@munnari.oz.au Subject: Re: Host identifier length Folks, If the EID identifies a fate-sharing region, such as the end of a TCP connection, how can it be derived from something like the 48-bit IEEE space? There is no reason to assume either that my TCP connection dies when a failed network interface is replaced, or that repair of a broken interface involves changing its built-in identifier. This leads to my unique identifier changing when my system reboots, or, if the EID is remembered, to some other system, which got the recycled interface, using the same EID. It does not seem that we can easily avoid the number space administration problem. Charlie From owner-Big-Internet@munnari.oz.au Fri Aug 7 01:35:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10474; Fri, 7 Aug 1992 01:35:34 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10466; Fri, 7 Aug 1992 01:35:21 +1000 (from craig@aland.bbn.com) Received: from port12.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA22421; Thu, 6 Aug 92 11:35:08 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA14938; Thu, 6 Aug 92 08:34:57 PDT Message-Id: <9208061534.AA14938@aland.bbn.com> To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 05-Aug-1992 2227" , clynN@bbn.com Cc: big-internet@munnari.oz.au Subject: re: Host Identifier and Location From: Craig Partridge Date: Thu, 06 Aug 92 08:34:56 -0700 Sender: craig@aland.bbn.com Hi folks: Before we sign on to mapping CI to src or src/dst pair, let me point out that there are arguments (as I was reminded yesterday by someone I talked with -- can't recall who) for making the connection id unique with the destination address. Consider that for a multicast conference, the src address may not be useful, what matters is the destination multicast address and connection id. Craig E-mail: craig@aland.bbn.com or craig@bbn.com From owner-Big-Internet@munnari.oz.au Fri Aug 7 03:20:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12609; Fri, 7 Aug 1992 03:21:02 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12605; Fri, 7 Aug 1992 03:20:45 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07238; Thu, 6 Aug 92 13:20:14 -0400 Message-Id: <9208061720.AA07238@ginger.lcs.mit.edu> To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 05-Aug-1992 2227" Cc: clynn@bbn.com, big-internet@munnari.oz.au Subject: Re: Host Identifier and Location In-Reply-To: Your message of Wed, 05 Aug 92 22:24:53 -0400. <9208060224.AA13472@us1rmc.bb.dec.com> From: David Clark Date: Thu, 06 Aug 92 13:20:13 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp The idea was not to hash on the combination of the CI and the source name. That is the wrong way to implement it. The better idea is to use the CI as a precomputed hash value, and use the full CI plus the source name as the comparision to see if you found the correct hash entry. So its a probe using a subset of the CI field, with a compare of the CI and the source. That does not seem scary to me. ??? Dave From owner-big-internet@munnari.oz.au Fri Aug 7 03:30:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12824; Fri, 7 Aug 1992 03:30:13 +1000 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09797; Thu, 6 Aug 1992 06:35:41 +1000 (from kasten@ftp.com) Received: by ftp.com id AA24389; Wed, 5 Aug 92 16:35:06 -0400 Date: Wed, 5 Aug 92 16:35:06 -0400 Message-Id: <9208052035.AA24389@ftp.com> To: jnc@ginger.lcs.mit.edu Subject: re: ID vs rest of address (long geneology omitted) From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com noel let's not confuse the "meaning" of the eid with how the number that is my eid was generated. by definition the eid has no internal meaning or structure (other than the split into two fields of "giving-authority-id" and "number-given-by-the-authority"). regardless of how my eid was created, you can not, you should not, you must not assume that the numbers actually mean anything. regardless of the form of the eid, the moral equivalent of an arp should probably be done when i have an eid and i want to get to a host. this seems to me to be intuitively true for eids for which there is no mapping to a hardware address. for eids for which there is a hardware address mapping it's a bit less obvious... suppose that host 1 is a multi-homed host with interfaces A and B on networks A and B. host 1 wishes to communicate with host 2 and the traffic must go out over interface A. host 1 uses interface A's 802 address as the basis for the eid. now, suppose that, due to the vagaries of routing, traffic from host 2 back to host 1 comes in on net B, and would be received on interface B. but the traffic is destined to the eid based on interface A's 802 address. if these packets are unicast to A's 802 address then host 1 may never see them. so, the router that transmits these packets onto net B should arp for the hardware address of the eid in the packets. on a related but different track: if 1. a single node can have multiple endpoints, and 2. ieee-802 derived eids will be the most common type (my own supposition), and 3. the host has one 802 interface, and 4. we have 8-byte eids, then the other two bytes of the eid must contain both the "authority id" under which the eid was assigned (ieee 802 in this case) and some form of locally (i.e. on that host) assigned "demultiplexing" number to identifiy the various endpoints. the eid must be a 3-tuple of this can obviously be solved: the authority id portion of the eid should probably be varying in length and self-encoding (like the class encoding in ip addresses). for example, if the first byte of the authority id is 0 then the second byte represents the local endpoint demux and the last 6 are the 802 address (or whatever). unless 255 local endpoints is not enough, then maybe if the first bit is 0 the next 15 bits are the local demux and so on. but, perhaps, more fundamentally, should the eid be decoupled from the addressable network entity (node)? are we overloading the eid? i think that, maybe, the eid should be limited to being some addressable box on the net. any further subdivision ought to be left to the protocol numbers and port numbers and so on. -- frank kastenholz From owner-big-internet@munnari.oz.au Fri Aug 7 04:35:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14188; Fri, 7 Aug 1992 04:35:23 +1000 (from owner-big-internet) Return-Path: Message-Id: <9208061835.14188@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27515; Thu, 6 Aug 1992 18:09:46 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 6 Aug 1992 09:00:30 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: my protocol does that too! In-Reply-To: Your message of "Wed, 05 Aug 92 21:11:42 EDT." <9208060111.AA01269@ginger.lcs.mit.edu> Date: Thu, 06 Aug 92 09:00:27 +0100 From: Jon Crowcroft > Until there is a complete shopping list of "must have" features for the "IP there are several sources but first of all you need to define scope IPAE (and EIP, but we'll bow out on that one) addresses the short/medium term problems supposedly addressed by the IPv7 CNLP not gosip proposal i.e. 1. address space exhaustion 2. routing table explosion problem and as part of its desing must (-) compromise becuase it (+) incorporates a reasonable migration path PIP is a protocol, and nimrod a propsoal for mechanism/architecture for the long term including 3. complex, but real world, policy requirements 4. scalable multicast 5. QoS reservation 6. mobility 7. migration to ATM/AAL5 (and other technologiers) TUBA is really an essential part of the end2end support for any of these - i.e. TCP, UDP and any other transports need to be fixed up to cope with anything that comes up from 1,2 and in longer term 3,4,5 of course there are all the infrastructural considferations (e.g. ARP, ICMP, DNS - and any ad hoc stuff that does layer crossing (i.e. includes info in a data packet that refers to link, internet or even transport layer, like broken RPC designs:-(). the only excuse for a two step deployment would be to do a limited scope IPAE + TUBA, then TUBA2 + PIP i dont see the point in CLNP 1 at all, since it doesnt solve 1,2 if CLNP 2 were to solve 3,4,5,6,7, then it might as well be pip-ish now i'm sure i've missed something... actually, maybe there should be a proper IPv7 shopping list pair of RFCs a) based on host + router requirements b) including these possible two phases if we were really smart IPAE+TUBA would be a step on a migrationary path to PIP+Nimrod - the implication here is that it might be sub-optimal as a first step, but compromise to give us a boost to a solution to the larger problem, but maintinaing the clean fresh minty Internet air... now I think Ross's list for TUBA means that it will probably address most 1-7 - except that he is, of course, thiningg in terms of "BA" = NSAP however, i'm not sure how we leapfrog from IPAE to PIP RDs...(paul T are you there?) one reason for the separation of phases i'm tentatively proposing here is that we have now succeeded in fragmenting the community into several discussions (one thing i'm sure the IAB would like of there was more time, but there is only just a bit more time:-) anher way to motivate this would be to demand code from each proposal group - my expectation is that CLNP or IPAE & TUBA will be there very soon ... but i`d like it if they admitted of the next step... j. layout will be adopted, presumably with an extended mapping of IP class A, B and C networks, for the sake of argument under the ISOC's future ICD 00XX. This implies (to me, but I'm ready to be corrected) a _second_ set of ES-IS and IS-IS configurations running in parallel (maybe in the same routers). It implies that a host which is running both DECnet V and TUBA is multihomed, with one address under ICD 0020 and another one under ICD 00XX. It would be even worse if GOSIP survives, because then hosts might have to have a _third_ NSAP under their country's DCC, and a third routing regime would be needed. Have I got it wrong? I hope so. If not, the simplification compared to today is marginal, and the routers will need biiig memories. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of CIDR, C#, | | IPv7, EIP, IPAE, (Mini)PIP, Nimrod or even the dreaded TUBA. | From owner-big-internet@munnari.oz.au Fri Aug 7 05:36:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15391; Fri, 7 Aug 1992 05:36:27 +1000 (from owner-big-internet) Return-Path: Message-Id: <9208061936.15391@munnari.oz.au> Received: from Relay.Prime.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB03567; Thu, 6 Aug 1992 23:12:00 +1000 (from @Relay.Prime.COM:AL@TURBO.Kean.EDU) Received: from TURBO.Kean.EDU by Relay.Prime.COM; 06 Aug 92 09:15:53 EST Received: (from user AL) by TURBO.Kean.EDU; 06 Aug 92 09:11:08 EDT To: big-internet@munnari.oz.au Cc: fddi@list.kean.edu From: Al Costanzo Organization: Kean College of New Jersey Security: -- none -- Comment: Sender Phone# (908) 527-2061 Comment: Sender Fax# (908) 527-2243 Subject: Using FDDI as the Backbone Date: 06 Aug 92 09:11:08 EDT Hello, I have been listening to all of these protocol suggestions. Has anyone considered the ramifications of changing all backbone traffic to an FDDI token ring format. And if done, in such a way as to free up all the address space associated with the change , would this not help? And why is everyone so set on changing tcp/ip? What's wrong with a 64 bit address space? From owner-big-internet@munnari.oz.au Fri Aug 7 05:51:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15637; Fri, 7 Aug 1992 05:51:19 +1000 (from owner-big-internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06038; Thu, 6 Aug 1992 23:54:16 +1000 (from dave@japan.bellcore.com) Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA29089; Thu, 6 Aug 92 09:57:14 EDT Return-Path: Received: by japan (4.1/4.7) id AA12547; Thu, 6 Aug 92 09:38:39 EDT Date: Thu, 6 Aug 92 09:38:39 EDT From: dave@sabre.bellcore.com (Dave Piscitello) X-Station-Sent-From: japan.bellcore.com Message-Id: <9208061338.AA12547@japan> To: big-internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: my protocol does that too! Somehow, Craig, posting an "I'm sensitive..." message about this subject, and describing TUBA as "dreaded" strikes me as incredibly bad taste (yes, I saw the cutesy smiley face). I'm not angered by this, just surprised at the BLATENT HYPOCRACY:-) From owner-big-internet@munnari.oz.au Fri Aug 7 06:07:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15829; Fri, 7 Aug 1992 06:07:23 +1000 (from owner-big-internet) Return-Path: Received: from mts-gw.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05843; Thu, 6 Aug 1992 23:51:18 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA15239; Thu, 6 Aug 92 06:50:53 -0700 Received: by sneezy (5.57/ULTRIX-4.2-3)id AA21671; Thu, 6 Aug 92 09:50:50 -0400 To: Brian Carpenter CERN-CN Subject: Re: Some comments/queries on PIP In-Reply-To: <9208060643.AA11354@dxcern.cern.ch> References: <9208060643.AA11354@dxcern.cern.ch> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.0B3 From: Dave Oran Date: Thu, 6 Aug 92 09:50:45 -0400 Message-Id: <920806095045.19811@sneezy.lkg.dec.com> Encoding: 32 TEXT, 6 TEXT SIGNATURE > Dave, I am *not* necessarily endorsing CLNP as a protocol of the future, > (unlike at least one Boston-based computer company :-) ), but when I > implemented a toy version of CLNP in 1984, only about 200 lines of code > out of 1500 were dedicated to fragmentation/reassembly. Admittedly > designing that part requires an ice-pack on the brain. Don't exagerrate > the overhead, especially if it's an option. > Ahhh...you're right, it isn't hard to implement, but to implement it with zero extra data copies...that's the trick! Did you independently figure out the clever hack of overwriting the parsed parts of the header to keep track of the reassembly state without extra reassembly data structures? Did you try to combine CLNP and TP4 reassembly so that you didn't have to do each separately with the implied extra buffer memory and data copy? The reason I was prevaricating on this subject wrt. PIP is that the details of the encoding and processing rules for segmentation (e.g. what are legal segmentation boundaries, can packets other than the last be small, is there a penalty for recursive segmentation) can have a dramatic effect on how fast you can make it go. Given that all the transport protocols have segmentation, the network protocol would be best tuned if the two interacted constructively and not destructively, much as the details of the checksum algorithm can affect your ability to unroll the loops and/or piggyback it onto the receive data copy that most systems require. Dave. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@sneezy.lkg.dec.com 550 King Street Littleton, MA 01460 From owner-big-internet@munnari.oz.au Fri Aug 7 06:06:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15824; Fri, 7 Aug 1992 06:06:42 +1000 (from owner-big-internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10630; Fri, 7 Aug 1992 01:42:23 +1000 (from craig@aland.bbn.com) Received: from port12.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA22888; Thu, 6 Aug 92 11:41:56 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA15415; Thu, 6 Aug 92 08:41:49 PDT Message-Id: <9208061541.AA15415@aland.bbn.com> To: dave@sabre.bellcore.com (Dave Piscitello) Cc: big-internet@munnari.oz.au Subject: tuba and music From: Craig Partridge Date: Thu, 06 Aug 92 08:41:48 -0700 Sender: craig@aland.bbn.com > Somehow, Craig, posting an "I'm sensitive..." > message about this subject, and describing > TUBA as "dreaded" strikes me as incredibly > bad taste (yes, I saw the cutesy smiley face). Hi Dave: Well, actually I was trying to highlight the TUBA acronym to set up the line about advertising music. I guess I didn't pull it off. Oh well. Craig From owner-big-internet@munnari.oz.au Fri Aug 7 06:16:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15969; Fri, 7 Aug 1992 06:16:56 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09372; Fri, 7 Aug 1992 00:48:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04130; Thu, 6 Aug 92 10:47:49 -0400 Date: Thu, 6 Aug 92 10:47:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208061447.AA04130@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: my protocol does that too! Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu nimrod a propsoal for mechanism/architecture for the long term I hope you mean by this that Nimrod has a long lifetime, not that it will take geological time to get it deployed, right? Nimrod Phase 0 (aka IDPR) is being deployed As We Speak. People who think Nimrod is some way off, distant thingy we *might* see in 8 years are another steam generator! One of the whole points of the Nimrod architecture was to *avoid* the tough problems, and put them off for another day, *precisely* so we could get something with lasting utility out quickly! migration to ATM/AAL5 (and other technologiers) I'm not sure exactly what you mean by this, but not everyone thinks fine tuning a new IP to the characteristics of ATM is a reasonable goal for an Internet architecture. There will always be new transmission media, and a range of deployed transmission technologies (just like we still have a range of memory technologies, even though the particiular technologies extant in the late 50's when automatic multi-level memory management was devised are now gone), and we need an architecture which is flexible enough to respond without a new packet format for each new technology. Let's look for the timeless principles of internetworking, and build those in, OK? IPAE + TUBA This is a interesting mix I hadn't thought about before! Make TUBA the inter-commonwealth format for IPAE? IPAE+TUBA would be a step on a migrationary path to PIP+Nimrod Boy, this is a pretty bizarre path. Why make a total change twice? we have now succeeded in fragmenting the community into several discussions So? As I pointed out before, any new solution is going to have to interoperate with what's already here, so we can deploy them *both* in a field trial, and pick the one that's best. 'Chose based on experience' is the IETF way, right? Competition improves the breed, yes? Noel From owner-big-internet@munnari.oz.au Fri Aug 7 06:16:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15968; Fri, 7 Aug 1992 06:16:52 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08880; Fri, 7 Aug 1992 00:34:14 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04046; Thu, 6 Aug 92 10:33:23 -0400 Date: Thu, 6 Aug 92 10:33:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208061433.AA04046@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: my protocol does that too! Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu PIP is a protocol, and nimrod a propsoal for mechanism/architecture for the long term including I'm going to suggest that everyone look at this with a slightly different way of dividing up the problem. ***This message everyone ought to read; it provides what I think is an important framework for thinking about *all* the proposals, and is *not* about Nimrod.*** Here's the chain of reasoning: 1 - What we have is a *routing* problem just as much as an *addressing* problem. Even if IP magically had 2^24 class B network numbers, getting rid of the addressing problem (sort-of :-), we'd *still* have routing problem. 2 - A routing solution (i.e. a routing architecture) includes not just address formats (and I'll punt for the moment on arguing which you design first :-), but also: some idea of what the routing info you are going to ship around looks like (e.g. routing tables, topology maps, etc), how you are going to use it to compute routes, how you are going to deal with the issues raised by the necessity of doing abstraction/aggregation, etc. 3 - Proposals which *only* include a packet format, and *not* a routing architecture (e.g. PIP, IPAE, EIP, etc) do not solve the routing problem, although they may be a *component* of a solution to the routing problem. 4 - To be a solution to the routing problem, you have to have a routing architecture, as defined in 2. 5 - There are only *two* routing architetures on the table: those which are in IDRP/BGP and IDPR/Nimrod (although both of these include other things, such as interoperable deployment plans). 6 - Either of these two can be mixed together with any of the packet format solutions; however, most IDRP backers seem to have settled on TUBA/CLNP, and Nimrod has punted on a new packet format for now altogether. Having said all this, I think it's going be to much harder to have this discussion if we persist in lumping the two debates (new packet format, new routing architeture) into one big snarl. Yes, there are *some* minor connections between the two, but *they are really minor*! They can be *very usefully* discussed separately. This happens all the time in networking. Older works on routing used to automatically handle congestion avoidance and routing as a single topic; now we separate them. 'Divide and conquer' is a engineering motto, after all! I think the debate will be more focused, and thus more useful, fruitful, and likely to come to closure, if we try and tackle one of these at a time, and not mix them all into one giant rolling mass of confusion, OK? Noel From owner-big-internet@munnari.oz.au Fri Aug 7 06:57:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16536; Fri, 7 Aug 1992 06:57:08 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09762; Fri, 7 Aug 1992 01:03:36 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04566; Thu, 6 Aug 92 11:03:30 -0400 Date: Thu, 6 Aug 92 11:03:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208061503.AA04566@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, clynn@bbn.com Subject: Re: Host identifier length Cc: jnc@ginger.lcs.mit.edu how can it be derived from something like the 48-bit IEEE space repair of a broken interface [does not] involves changing its built-in identifier. This leads to my unique identifier changing when my system reboots, or, if the EID is remembered, to some other system, which got the recycled interface, using the same EID. Ross and I discussed this. We agreed that there had to be something to allow a host's EID to be manually configured, and not picked up from their interface, to allow cases like this. Yes, there is a great deal of potential for screwing up, but it hard to see how to use IEEE numbers and not face this. One thing that will make this less of a problem as time goes by, and the system gets bigger, and more used by naive users, is that more and more itnerafces are being built straight on to the mother-board of workstations, etc. Pretty hard to separate the computer and the EID there. Perhaps we can also convince workstation manufacturers to number their workstations, and not just the interface cards, for those which don't have the interface on the mother-board? Most workstations these days are going onto networks *anyway*, and if we build an architeture in which having a number *in the machine* makes the user's configuration job easier, it's a big selling point, right? And IEEE is already set up to sell blocks of numbers to vendors.. Noel From owner-big-internet@munnari.oz.au Fri Aug 7 08:09:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17532; Fri, 7 Aug 1992 08:10:06 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10277; Fri, 7 Aug 1992 01:27:40 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA08829; Thu, 6 Aug 92 08:27:30 -0700 Received: by us1rmc.bb.dec.com; id AA21616; Thu, 6 Aug 92 11:24:45 -0400 Message-Id: <9208061524.AA21616@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Thu, 6 Aug 92 11:24:46 EDT Date: Thu, 6 Aug 92 11:24:46 EDT From: Ross Callon To: "craig@aland.bbn.com"@crl.enet.dec.com, "jnc@ginger.lcs.mit.edu"@crl.enet.dec.com Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com Apparently-To: big-internet@munnari.oz.au Subject: re: Re: my protocol does that too! >> I'm seeing a whole bunch of messages of the form "I think Y is a good idea >> and by the way, proposal XXX which I support already does Y." >> >> I realize that there's an attempt to develop support for various >> proposals... But could we turn down the advertising music? >> (Craig) > > Craig, I can't speak for everyone, but let me offer one somewhat more > charitable explanation for why I at least am doing this. (Motivations, we all > remember them, right? And we don't speculate about them, right!?) > I have discovered a great number of cases in which people had > misapprehensions (for a variety of reasons, including length document, > terminology problems, etc) about what Nimrod did and why it did it. We have > seen instances of people (e.g. me :-) misunderstanding other proposals (e.g. > PIP :-). > In such an atmosphere, it's very natural to, when discussing feature > X, to say "and proposal Y also does X", because experience has shown that > probably a good number of people out there *simply don't realize* that Y > *can do* X. > > Having said that, your general point (keep the advertising for a > *particular scheme* down) is well put, but it *is* a fine line, particularly > in the IETF, where what tends to be adopted are *protocols*, not > *architectural principles*. The only way to get an AP you believe in adopted, > sometimes, is to get the protocol it is embodied in adopted. Hence the > advertising... > (noel) My first reaction was to agree with Craig: That there is too much advertising music going on and not enough technical reality. However, last night I got to thinking, and came to the same conclusion as Noel: There is a lot of mis- understanding of all of the proposals. This is not surprising, since none of them are fully written down and even if they were folks would not have had time to read all of them. Thus, to the extent that the "my protocol does Y" messages serve to clear up mis-understandings, I think that this is valuable. Perhaps the real point of Craig's message is to keep things in balance. There is a fine line between clarifying remarks, and advertising. We should try to stay on the clarifying side of this line. Finally, on the point of motivations: It is frustrating to hear multiple complaints to the extent of "your protocol can't do X as well as IP", when in fact you know that support for X was intentionally built in and you can handle it very well. Thus, I think that one of the main motivators is to clear up mis-understandings, on the basis that the proponents of any particular approach would like the approach to be evaluated on its technical merits, and not on the basis of which approaches suffer from the most mis-understanding. Ross From owner-big-internet@munnari.oz.au Fri Aug 7 08:11:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17547; Fri, 7 Aug 1992 08:11:07 +1000 (from owner-big-internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10789; Fri, 7 Aug 1992 01:47:23 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA00156 (5.65b/CWI-2.173); Thu, 6 Aug 1992 17:47:07 +0200 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA21233; Thu, 6 Aug 92 17:47:23 +0200 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA18607; Thu, 6 Aug 92 17:47:00 +0200 Message-Id: <9208061547.AA18607@dxcern.cern.ch> Subject: Re: Some comments/queries on PIP To: big-internet@munnari.oz.au Date: Thu, 6 Aug 92 17:46:59 MET DST From: Brian Carpenter CERN-CN In-Reply-To: <920806095045.19811@sneezy.lkg.dec.com>; from "Dave Oran" at Aug 6, 92 9:50 am X-Mailer: ELM [version 2.3 PL11 CERN 11] >--------- Text sent by Dave Oran follows: > > > > Dave, I am *not* necessarily endorsing CLNP as a protocol of the future, > > (unlike at least one Boston-based computer company :-) ), but when I > > implemented a toy version of CLNP in 1984, only about 200 lines of code > > out of 1500 were dedicated to fragmentation/reassembly. Admittedly > > designing that part requires an ice-pack on the brain. Don't exagerrate > > the overhead, especially if it's an option. > > > Ahhh...you're right, it isn't hard to implement, but to implement it > with zero extra data copies...that's the trick! > > Did you independently figure out the clever hack of overwriting the > parsed parts of the header to keep track of the reassembly state without > extra reassembly data structures? > > Did you try to combine CLNP and TP4 reassembly so that you didn't > have to do each separately with the implied extra buffer memory and > data copy? No, indeed, the implementation was a perfect piece of computer science with clear data structures and _lots_ of procedure calls (mainly put_fifo and get_fifo, but these were pointer operations, not data copies). The results are that (a) I looked at the code this morning for the first time in eight years and I could still understand it!!! (b) Stuff got copied once from driver to buffer pool and once from buffer pool to user buffer. Not too bad, but I was killed by the need for a semaphore lock/unlock on every fifo operation. I am even now not prepared to reveal the CPU time per datagram :-( Your remarks are all true: I just wanted to avoid the idea of segmentation as an _option_ being lost in the general anti-OSI blurr. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of CIDR, C#, | | IPv7, EIP, IPAE, (Mini)PIP, Nimrod or even the dreaded TUBA. | From owner-big-internet@munnari.oz.au Fri Aug 7 10:21:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20237; Fri, 7 Aug 1992 10:26:50 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12698; Fri, 7 Aug 1992 03:26:07 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA11734; Thu, 6 Aug 92 10:25:55 -0700 Received: by us1rmc.bb.dec.com; id AA24251; Thu, 6 Aug 92 13:23:07 -0400 Message-Id: <9208061723.AA24251@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Thu, 6 Aug 92 13:23:09 EDT Date: Thu, 6 Aug 92 13:23:09 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 06-Aug-1992 1325" To: craig@aland.bbn.com Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, craig@aland.bbn.com Subject: RE: re: Host Identifier and Location Craig, It is not clear to me that for all multicast addresses all packets sent to them need have the same quality of service. In some cases, it may be reasonable for different sources to want to send packets to the same multicast destination but with different qualities of service. If a CI is to be unique when paired with the destination address then something associated with that destination address must allocate it, presumably at the request of the source, and it must be communicated to the source. All of this is certainly do-able but more comples than the source generating a locally unique CI. If the CI is unique when coupled with the source or destination address but not both, then you probably need a bit assocaited with the CI to say which it is. However, my argument was that a very small CI (probably 8 bits or less) that is only unique when coupled with both the source and destiation addresses should be adequate and the combined result (src+dst+smallCI) is not that much bigger than (src+bigCI or dst+bigCI) for hashing purposes and saves bigCI-smallCI in the overall header size. Donald -------------- From: US1RMC::"craig@aland.bbn.com" "Craig Partridge" 6-AUG-1992 11:37 To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 05-Aug-1992 2227" , clynN@bbn.com CC: big-internet@munnari.oz.au Subj: re: Host Identifier and Location Hi folks: Before we sign on to mapping CI to src or src/dst pair, let me point out that there are arguments (as I was reminded yesterday by someone I talked with -- can't recall who) for making the connection id unique with the destination address. Consider that for a multicast conference, the src address may not be useful, what matters is the destination multicast address and connection id. Craig E-mail: craig@aland.bbn.com or craig@bbn.com From owner-big-internet@munnari.oz.au Fri Aug 7 16:32:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28563; Fri, 7 Aug 1992 16:32:43 +1000 (from owner-big-internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20441; Fri, 7 Aug 1992 10:34:49 +1000 (from hugh@rschp1.anu.edu.au) Received: from rschp1.anu.edu.au by shark.mel.dit.csiro.au with SMTP id AA06094 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 7 Aug 1992 10:08:27 +1000 Message-Id: <199208070008.AA06094@shark.mel.dit.csiro.au> Received: by rschp1.anu.edu.au (16.8/16.2) id AA20299; Fri, 7 Aug 92 10:04:24 +1000 From: Hugh Fisher Subject: Host identifiers and hardware addresses To: big-internet@munnari.oz.au Date: Fri, 7 Aug 92 10:04:24 EST Mailer: Elm [revision: 70.30] I was under the impression that host/endpoint identifiers were to be a unique 64 bit or whatever binary number for us API types, with no relation to the actual hardware address. Using the existing Ethernet or IP address as the basis for the EID is just to avoid having to distribute EIDs to the 800,000+ (?) existing hosts - upgraded machines would get their new, arbitrary EID from a configuration file or RARP, and if the Ethernet card for an older host broke you would still keep the old EID. Hugh Fisher hugh@rschp1.anu.edu.au From owner-Big-Internet@munnari.oz.au Fri Aug 7 18:51:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02777; Fri, 7 Aug 1992 18:51:40 +1000 (from owner-Big-Internet) Return-Path: Received: from mitsou.inria.fr by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02764; Fri, 7 Aug 1992 18:51:25 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA20921; Fri, 7 Aug 1992 10:51:25 +0200 Message-Id: <199208070851.AA20921@mitsou.inria.fr> To: Brian Carpenter CERN-CN Cc: big-internet@munnari.oz.au Subject: Re: Some comments/queries on PIP In-Reply-To: Your message of "Thu, 06 Aug 92 17:46:59 +0700." <9208061547.AA18607@dxcern.cern.ch> Date: Fri, 07 Aug 92 10:51:25 -0400 From: Christian Huitema X-Mts: smtp >Your remarks are all true: I just wanted to avoid the idea >of segmentation as an _option_ being lost in the general anti-OSI >blurr. Two points should be clear: * Asking the network to perform hop by hop segmentation is a bad idea, as one loose the "end to end" control possibility. * Some protocols, e.g. TP4 and a number of naive RPC implementations above UDP, do not work if the network layer cannot handle segmentation. The reason why TCP can do it is because it numbers octets, not packets. Any protocol like TP4 that only numbers packet is bound to retransmit whole packets, and is thus bound to break the connection if for some reason (rerouting) the packet size supported by the network becomes lower than the packet size negociated at connection time. The consequence is that: * "Real men need no segments". Thus they should not have to fill up segmentation information in the headers. * "Quiche eaters use segments". Let them pay the price, i.e. fill up an option field. Christian Huitema From owner-Big-Internet@munnari.oz.au Fri Aug 7 19:05:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03038; Fri, 7 Aug 1992 19:05:13 +1000 (from owner-Big-Internet) Return-Path: Received: from haig.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03033; Fri, 7 Aug 1992 19:05:06 +1000 (from S.Kille@isode.com) Received: from glengoyne.isode.com by haig.cs.ucl.ac.uk with Internet SMTP id ; Fri, 7 Aug 1992 08:43:46 +0100 Received: from localhost by glengoyne.isode.com with SMTP (PP) id <00944-0@glengoyne.isode.com>; Fri, 7 Aug 1992 08:10:02 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: my protocol does that too! Phone: +44-71-223-4062 In-Reply-To: Your message of Thu, 06 Aug 92 10:33:23 -0400. <9208061433.AA04046@ginger.lcs.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Fri, 07 Aug 92 08:09:57 +0100 Message-Id: <942.713171397@isode.com> From: Steve Hardcastle-Kille Noel, As a (usually) silent observer on this list, I'd like to strongly agree with the point that you are making here (and have made before). This list should focus on the (harder) problem of routing architecture and the problems of packet and address format will come out in the wash. Steve From owner-big-internet@munnari.oz.au Fri Aug 7 19:09:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03125; Fri, 7 Aug 1992 19:09:28 +1000 (from owner-big-internet) Return-Path: Received: from EMU.NCSL.NIST.GOV by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16243; Fri, 7 Aug 1992 06:34:02 +1000 (from colella@emu.ncsl.nist.gov) Received: by emu.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA04115; Thu, 6 Aug 92 16:35:02 EDT Date: Thu, 6 Aug 92 16:35:02 EDT Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9208062035.AA04115@emu.ncsl.nist.gov> To: brian@dxcern.cern.ch Subject: Re: Host Identifier and Location Cc: big-internet@munnari.oz.au From: colella@nist.gov Brian, > > It would be even worse if GOSIP survives, because then hosts might > have to have a _third_ NSAP under their country's DCC, and a third > routing regime would be needed. > There is no technical reason that a third NSAP format is needed to run OSI stacks (in addition to a DECNet IV-V transition NSAP and a TUBA NSAP from, e.g., the ISOC ICD). The TUBA NSAP addresses a transport entity, with the NSAP Selector as the discriminator among the possible entities (e.g., TCP, TP4). On the non-technical side, some countries may have policies about resident systems having NSAPs taken from their country's DCC-based NSAP space. I've heard enough anecdotal stories about this to suggest there is some truth to it. But I don't have any hard information. However, having an NSAP is not the same as using an NSAP :^). [Note: US GOSIP doesn't mandate any particular NSAP format, just makes one available for those who choose t use it.] --Richard From owner-big-internet@munnari.oz.au Fri Aug 7 19:10:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03173; Fri, 7 Aug 1992 19:10:23 +1000 (from owner-big-internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16407; Fri, 7 Aug 1992 06:45:26 +1000 (from dkatz@cisco.com) Received: by cider.cisco.com; Thu, 6 Aug 92 13:44:43 -0700 Date: Thu, 6 Aug 92 13:44:43 -0700 From: Dave Katz Message-Id: <9208062044.AA02681@cider.cisco.com> To: brian@dxcern.cern.ch Cc: peter@goshawk.lanl.gov, big-internet@munnari.oz.au In-Reply-To: Brian Carpenter CERN-CN's message of Thu, 6 Aug 92 9:48:32 MET DST <9208060748.AA20554@dxcern.cern.ch> Subject: Host Identifier and Location I think that the addressing issue is a bit of a red herring; none of the OSI routing protocols really give a hoot about the structure of addresses, save for the IS-IS requirement that all of the machines in the routing domain have the same size system ID. If TUBA required a particular NSAP format, I would be in violent opposition to it. Rather, I would expect/hope that, in concert with TUBA, an *additional* addressing authority would be created for the benefit of organizations that aren't able/don't want to use existing authorities. Interdomain routing will have to deal with all addressing formats regardless, and IDRP should be able to handle this. Since you already have ICD 0020 addresses, I would expect that you would use them for DECNET, TUBA, and any other flavor of the OSI network layer that you desire. Date: Thu, 6 Aug 92 9:48:32 MET DST From: Brian Carpenter CERN-CN X-Mailer: ELM [version 2.3 PL11 CERN 11] >--------- Text sent by peter@goshawk.lanl.gov follows: > > > Brian, > > Are you, or are you planning on, running any other network > protocol other than IP at CERN? More specifically, is CERN > running as part of the international DECNET phase IV network and > do you plan to support CLNP in the future? Peter, on site we run a MAC-level bridged network of at least 4500 nodes (mainly Ether, some FDDI). No, folks, we are neither crazy nor masochistic but we _have to_ support or allow: IPv4 DECnet IV DECnet V Novell IPX Appletalk II Some XNS (we suspect!) A little bit of ISO TP4 running over the null network layer Odd bits of home-made this and that. Off site we have managed to limit ourselves to IPv4 and DECnet IV datagrams, except for our participation in the transatlantic CLNP pilot. (Well, a few percent of our traffic still travels over X.400/X.25, RSCS/BSC or even SNA, but let's not talk about that.) We are one of the main nodes in the particle physics/space science DECnet (IV) and we will be a lead site in its migration to DECnet V. > Would you have any interest in > using a similar routing and addressing architecture for IP > and CLNP? > As a manager and budget holder: yes, strategically I would like to reduce diversity. As a pragmatic technical person: I'm full of doubt, as are my colleagues who have to do the real work. Today, for example, we use Brand X routers for IP, and DECrouters for DECnet (with multiplexers on the lines), because we are not yet convinced that Brand X can support smooth transition to DECnet V. (In this we have chosen to disagree with the approach chosen by ESnet and by Milo, sorry I mean NASA.) Even on a theoretical basis I can see a big problem. It still looks like the first real-world CLNP deployment will be DECnet V. Here a particular NSAP layout has been adopted, which happens to be some sort of extended mapping of the old DECnet area/node scheme. Let's assume (just for this piece of theory) that we use the CERN ICD, 0020, for the physics DECnet. So we can use ES-IS very effectively and IS-IS as a makeshift until something decent comes along, and use the level 1/level 2 scheme to implement policy based routing (so that Milo doesn't have to route traffic between CERN and LANL, or whatever). Suppose the next CLNP deployment is TUBA. (I'm assuming that GOSIP goes to the same place as ADA :-) Here some other NSAP layout will be adopted, presumably with an extended mapping of IP class A, B and C networks, for the sake of argument under the ISOC's future ICD 00XX. This implies (to me, but I'm ready to be corrected) a _second_ set of ES-IS and IS-IS configurations running in parallel (maybe in the same routers). It implies that a host which is running both DECnet V and TUBA is multihomed, with one address under ICD 0020 and another one under ICD 00XX. It would be even worse if GOSIP survives, because then hosts might have to have a _third_ NSAP under their country's DCC, and a third routing regime would be needed. Have I got it wrong? I hope so. If not, the simplification compared to today is marginal, and the routers will need biiig memories. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of CIDR, C#, | | IPv7, EIP, IPAE, (Mini)PIP, Nimrod or even the dreaded TUBA. | From owner-big-internet@munnari.oz.au Fri Aug 7 19:10:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03179; Fri, 7 Aug 1992 19:10:41 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17066; Fri, 7 Aug 1992 07:39:52 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA17819; Thu, 6 Aug 92 14:38:37 -0700 Received: by us1rmc.bb.dec.com; id AA00509; Thu, 6 Aug 92 17:35:51 -0400 Message-Id: <9208062135.AA00509@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Thu, 6 Aug 92 17:35:52 EDT Date: Thu, 6 Aug 92 17:35:52 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 06-Aug-1992 1738" To: ddc@lcs.mit.edu Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au Subject: RE: Re: Host Identifier and Location Dave, I see. The Source & CI (or sometimes the Destination & CI) still have to be unique though. So you are saving time computing a hash over a number of bits at the cost of (1) the burden on the Source (or sometimes Destination) host of producing pseudo random numbers that are all different from each other (until they time out or are torn down or whatever) and from those produced by similar hosts (to avoid excessive hash conflicts) and (2) more bits in the packet. I must admit the cost versus benefit balance is not clear to me. However, in the long run the cost of computation is declining more rapidly than that of communications so the cost computing the hash code may become minimal compared with the cost of moving the extra bits around. Donald -------------- From: US1RMC::"ddc@lcs.mit.edu" "David Clark" 6-AUG-1992 13:20 To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 05-Aug-1992 2227" CC: clynn@bbn.com, big-internet@munnari.oz.au Subj: Re: Host Identifier and Location The idea was not to hash on the combination of the CI and the source name. That is the wrong way to implement it. The better idea is to use the CI as a precomputed hash value, and use the full CI plus the source name as the comparision to see if you found the correct hash entry. So its a probe using a subset of the CI field, with a compare of the CI and the source. That does not seem scary to me. ??? Dave From owner-big-internet@munnari.oz.au Fri Aug 7 19:11:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03217; Fri, 7 Aug 1992 19:11:44 +1000 (from owner-big-internet) Return-Path: Received: from boa-f.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19247; Fri, 7 Aug 1992 09:32:10 +1000 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.57/Ultrix3.0-C) id AA08662; Thu, 6 Aug 92 19:31:30 -0400 Message-Id: <9208062331.AA08662@boa.gsfc.nasa.gov> Subject: re: ID vs rest of address (long geneology omitted) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Thu, 6 Aug 92 19:31:30 EDT From: Dick desJardins Cc: big-internet@munnari.oz.au In-Reply-To: <9208060447.AA02226@ginger.lcs.mit.edu>; from "Noel Chiappa" at Aug 6, 92 12:47 am X-Mailer: ELM [version 2.3 PL11] Terminology alert: to me, an 'address' is the structured name of a network interface. I know 'address' is an existing term, and is way overloaded with meanings, but either we have to agree on a strict one or give up using it. Well, here's where ISO incomprehensible jargon comes to the rescue :-) The EID identifies what you're trying to reach in the Internet. The Location provides the routing processes with the information needed to get to the local vicinity, so that a local process can resolve the address efficiently. OSI ES-IS identifies the mapping between the EID (called 'System ID') and the network interface address (called 'Subnetwork Point of Attachment (SNPA)'). The IS then knows that it gets to the EID by sending to the subnetwork SNPA. Nothing prevents multiple EIDs from being located at the same SNPA, since when the packet arrives it contains the destination EID inside to identify the intended destination at that SNPA. In summary, the EID is not equal to an "addressable box on the net", but the EID is *inside* an addressable box on the net, and the mapping (via ARP or ES-IS) has to be provided for separately. Dick From owner-big-internet@munnari.oz.au Fri Aug 7 19:11:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03228; Fri, 7 Aug 1992 19:12:16 +1000 (from owner-big-internet) Return-Path: Received: from bridge2.NSD.3Com.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19593; Fri, 7 Aug 1992 09:50:31 +1000 (from cmj@bridge2.NSD.3Com.COM) Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA09526 (5.65c/IDA-1.4.4nsd for ); Thu, 6 Aug 1992 16:49:40 -0700 Received: by jaspar.NSD.3Com.COM id AA18555 (5.65c/IDA-1.4.4-910730); Thu, 6 Aug 1992 16:49:38 -0700 Date: Thu, 6 Aug 1992 16:49:38 -0700 From: "Cyndi M. Jung" Message-Id: <199208062349.AA18555@jaspar.NSD.3Com.COM> To: brian@dxcern.cern.ch Subject: Re: Host Identifier and Location Cc: big-internet@munnari.oz.au >Suppose the next CLNP deployment is TUBA. >(I'm assuming that GOSIP goes to the same place as ADA :-) >Here some other NSAP layout will be adopted, presumably with >an extended mapping of IP class A, B and C networks, for the >sake of argument under the ISOC's future ICD 00XX. > >This implies (to me, but I'm ready to be corrected) a _second_ set of >ES-IS and IS-IS configurations running in parallel (maybe in the same >routers). It implies that a host which is running both DECnet V and TUBA >is multihomed, with one address under ICD 0020 and another one under ICD >00XX. Both ES-IS and IS-IS allow nodes to have multiple NSAPs, and IS-IS allows areas to have more than one Area Address - so I don't see why you would have multiple ES-IS and IS-IS configurations "running in parallel". The default limit on Area Addresses per area in IS-IS is 3, so a GOSIP address added in wouldn't place any special requirements on the routers - more than that and you might have trouble finding routers willing to support additional Area Addresses per area. The Area boundaries would need to be the same for all formats. >IS-IS as a makeshift until something decent comes along What are you looking for? Cyndi Jung 3Com Corporation From owner-big-internet@munnari.oz.au Fri Aug 7 19:15:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03442; Fri, 7 Aug 1992 19:15:55 +1000 (from owner-big-internet) Return-Path: Received: from SPECTRUM.CMC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26038; Fri, 7 Aug 1992 14:45:02 +1000 (from lars@CMC.COM) Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA05582; Thu, 6 Aug 92 21:44:23 PDT Newsgroups: ietf.big-internet Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: Host identifier length Message-Id: <1992Aug7.044415.5544@spectrum.CMC.COM> Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA References: <9208061503.AA04566@ginger.lcs.mit.edu> Date: Fri, 7 Aug 92 04:44:15 GMT Apparently-To: Big-Internet@munnari.OZ.AU In article <9208061503.AA04566@ginger.lcs.mit.edu> jnc@ginger.lcs.mit.edu (Noel Chiappa) writes: > One thing that will make this less of a problem as time goes by, and >the system gets bigger, and more used by naive users, is that more and more >itnerafces are being built straight on to the mother-board of workstations, >etc. Pretty hard to separate the computer and the EID there. Sorry, Noel, it doesn't work that way. The woman two doors down the hall from me had a problem with her workstation. Field service just swapped the logic board - ethernet interface and all. I do believe that they swapped the system-ID prom back to the new board, though. > Perhaps we can also convince workstation manufacturers to number their >workstations, and not just the interface cards, for those which don't have the >interface on the mother-board? Most workstations these days are going onto >networks *anyway*, and if we build an architeture in which having a number *in >the machine* makes the user's configuration job easier, it's a big selling >point, right? And IEEE is already set up to sell blocks of numbers to vendors.. They are numbered, all right. The last major computer family that I know of that wasn't properly numbered, was the VAX family. The 780 had a few bits for plant and serial number; the 750 had only a microcode revision level, which was subject to change while the system was running. Software vendors complained because they couldn't easily node-lock licenses. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC (Rockwell Digital Systems) Telephone: +1-805-968-4262 Santa Barbara, CA 93117-5503 TeleFAX: +1-805-968-8256 From owner-big-internet@munnari.oz.au Fri Aug 7 19:20:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03626; Fri, 7 Aug 1992 19:20:11 +1000 (from owner-big-internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01496; Fri, 7 Aug 1992 17:56:56 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA12407 (5.65b/CWI-2.173); Fri, 7 Aug 1992 09:56:42 +0200 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA28379; Fri, 7 Aug 92 08:37:42 +0200 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA20183; Fri, 7 Aug 92 08:37:20 +0200 Message-Id: <9208070637.AA20183@dxcern.cern.ch> Subject: Re: Host Identifier and Location To: big-internet@munnari.oz.au Date: Fri, 7 Aug 92 8:37:17 MET DST From: Brian Carpenter CERN-CN X-Mailer: ELM [version 2.3 PL11 CERN 11] Richard, Dave, Cyndi, Thanks for the comments on use of NASAPs and the risk of multi-homing. You reassure me a bit, but I talked to our DECnet V and CLNP expert Denise Heagerty . She has also reassured me a bit, but she is also worried that multihoming remains a risk. In other words, avoidance of multihoming has to become a design criterion _shared_ between everybody planning CLNP deployment. Specifically, > (from Richard) > There is no technical reason that a third NSAP format is needed to run > OSI stacks (in addition to a DECNet IV-V transition NSAP and a TUBA > NSAP from, e.g., the ISOC ICD). The TUBA NSAP addresses a transport > entity, with the NSAP Selector as the discriminator among the possible > entities (e.g., TCP, TP4). That still leaves two, doesn't it? > > On the non-technical side, some countries may have policies about > resident systems having NSAPs taken from their country's DCC-based NSAP > space. I've heard enough anecdotal stories about this to suggest there > is some truth to it. But I don't have any hard information. However, > having an NSAP is not the same as using an NSAP :^). [Note: US GOSIP > doesn't mandate any particular NSAP format, just makes one available > for those who choose to use it.] Well, until a couple of years ago these same countries "banned" TCP/IP. I think the people who actually configure systems are not generally politicians. > (from Dave) > I think that the addressing issue is a bit of a red herring; none of the > OSI routing protocols really give a hoot about the structure of addresses, > save for the IS-IS requirement that all of the machines in the routing > domain have the same size system ID. If TUBA required a particular NSAP > format, I would be in violent opposition to it. Rather, I would expect/hope > that, in concert with TUBA, an *additional* addressing authority would be > created for the benefit of organizations that aren't able/don't want to > use existing authorities. Interdomain routing will have to deal with > all addressing formats regardless, and IDRP should be able to handle this. You cheered me up. > > Since you already have ICD 0020 addresses, I would expect that you would use > them for DECNET, TUBA, and any other flavor of the OSI network layer that > you desire. That is absolutely what we want. > (from Cyndi) > Both ES-IS and IS-IS allow nodes to have multiple NSAPs, and IS-IS allows > areas to have more than one Area Address - so I don't see why you would have > multiple ES-IS and IS-IS configurations "running in parallel". The default > limit on Area Addresses per area in IS-IS is 3, so a GOSIP address added > in wouldn't place any special requirements on the routers - more than that > and you might have trouble finding routers willing to support additional > Area Addresses per area. The Area boundaries would need to be the same for > all formats. You cheered me up too > > >IS-IS as a makeshift until something decent comes along > > What are you looking for? > I can't answer that. If you want to follow up please talk to Denise (address above). She's not reading big-internet but is on the tuba list. Thanks again Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of CIDR, C#, | | IPv7, EIP, IPAE, (Mini)PIP, Nimrod or TUBA. | From owner-big-internet@munnari.oz.au Fri Aug 7 22:04:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06334; Fri, 7 Aug 1992 22:08:33 +1000 (from owner-big-internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06172; Fri, 7 Aug 1992 21:58:10 +1000 (from kre) To: Dave Katz Cc: brian@dxcern.cern.ch, peter@goshawk.lanl.gov, big-internet@munnari.oz.au Subject: Re: Host Identifier and Location In-Reply-To: Your message of Thu, 06 Aug 92 13:44:43 -0700. <9208062044.AA02681@cider.cisco.com> Date: Fri, 07 Aug 92 21:58:00 +1000 Message-Id: <1936.713188680@munnari.oz.au> From: Robert Elz Date: Thu, 6 Aug 92 13:44:43 -0700 From: Dave Katz Message-ID: <9208062044.AA02681@cider.cisco.com> If TUBA required a particular NSAP format, I would be in violent opposition to it. I have exactly the opposite feeling - if TUBA (using CLNP or any other technology for its big addresses) doesn't require a particular addressing format I think I'll be in violent opposition to it. If all we gain out of big addresses is simply more of them we're just creating a bigger routing headache, in some senses it would be better to run out of addresses, and so impose a fundamental limit on the size of the internet, or the useful part of it, than to simply increase the number of addresses in an unstructured way, which would certainly result in total collapse due to routing overload. Its essential that addresses be assigned so as to allow sane routing aggregation (as in CIDR for IPv4) - for TUBA NSAP addresses would have to have that requirement imposed upon them. Other NSAPs that a site, or host, may have must be ignored, the NSAP's used for TUBA must be assigned in a way that they can be used for routing, and so that the mechansisms scale well. kre ps: I really don't want to hear that protocol X supports whatever, unless you can demonstrate that it works with 10^9 hosts out there. ould obtain them from the site's list of available id's, obtained elsewhere. This could be a use for some of the "spare" bits available using IP addresses padded out to 48 bits - 8, or even all 16, of those bits could be a site assigned identifier, so for each IP address you own, you'd have 256, or 64K ID's available to assign as you saw fit - not necessarily to the host that currently uses that IP address of course. This would mean that a site that currently owns a class C would probably have enough ID's already assigned to them to last a long time. This is all really just to the point of hierarchies of ID allocation authorities though, it seems obvious to me (which might mean its wrong) that IDs need to be handed out in ever smaller blocks to authorities closer to the final consumer, which necessarily means wastage of the id space. That being so, 48 bits is not big enough, though with 64 we can probably make do for a long time, even with the wastage. kre From owner-Big-Internet@munnari.oz.au Fri Aug 7 23:27:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07951; Fri, 7 Aug 1992 23:28:05 +1000 (from owner-Big-Internet) Return-Path: Received: from xap.xyplex.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07938; Fri, 7 Aug 1992 23:27:51 +1000 (from milan@mjm.xyplex.com) Received: from mjm.xyplex.com by xap.xyplex.com id ; Fri, 7 Aug 92 11:26:19 -0500 Received: by mjm.xyplex.com.eng.xyplex.com (4.1/SMI-4.1) id AA02199; Fri, 7 Aug 92 09:28:21 EDT Date: Fri, 7 Aug 92 09:28:21 EDT From: milan@mjm.xyplex.com (Milan Merhar) Message-Id: <9208071328.AA02199@mjm.xyplex.com.eng.xyplex.com> To: big-internet@munnari.oz.au In-Reply-To: Noel Chiappa's message of Thu, 6 Aug 92 11:03:30 -0400 <9208061503.AA04566@ginger.lcs.mit.edu> Subject: Host identifier length I've been reading with interest the ongoing discussion about host identifiers. I must admit that I am a bit concerned about using a hardware interface address as a host's unique identifier. First of all, there are protocols (DECnet IV, for one) that modify the datalink address to reconcile it with a higher-level protocol layer address. Subsequent datalink users must live with the modified address. Until DECnet IV goes away, this is a sad fact of networking life. Second, one must assume that hosts can and do have multiple datalinks and, contrary to our desires, current practice requires that each unique datalink has its own address. We _are_ talking about IEEE 802 (Media Access a.k.a. "Data Link") addresses, that is, addresses of the datalink level. Multiple data links, multiple addresses. I have seen designs that attempt to subsume multiple physical interfaces into a single entity sharing a single address; they generally assume that the interfaces are attached to independent networks, and with LAN bridges and routers as common as fleas, who can guarantee that? It is very tempting to use an already-available, known-to-be-unique number as the "seed" for a global identification code. It means that there is one less thing to configure. On the other hand, if it means "network management hell" when you have to reconfigure, it may not be worth it. ___ Milan J. Merhar milan@eng.xyplex.com Phone:(508)264-9900 330 Codman Hill Rd. Boxborough, MA 01915 Fax:(508)264-9930 From owner-Big-Internet@munnari.oz.au Fri Aug 7 23:44:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08225; Fri, 7 Aug 1992 23:44:47 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08220; Fri, 7 Aug 1992 23:44:37 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 7 Aug 92 09:44:25 EDT Received: by chiya.bellcore.com (4.1/4.7) id for jnc@ginger.lcs.mit.edu; Fri, 7 Aug 92 09:44:24 EDT Date: Fri, 7 Aug 92 09:44:24 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208071344.AA06953@chiya.bellcore.com> To: J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: my protocol does that too! Cc: big-internet@munnari.oz.au > > I think the debate will be more focused, and thus more useful, > fruitful, and likely to come to closure, if we try and tackle one of these at > a time, and not mix them all into one giant rolling mass of confusion, OK? > > > Noel > I agree, but how to do it is the question. I'm still interested in the notion of breaking these discussions into multiple mailing lists: bi-transition bi-routing bi-protocol Where bi = big-internet I guess that the membership of these three groups would be almost identical to the membership of big-internet, but I think posting on one or the other of these would have the effect of forcing people to recognize the topic at hand. Is this silly? PT From owner-Big-Internet@munnari.oz.au Sat Aug 8 00:40:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10195; Sat, 8 Aug 1992 00:41:01 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9208071441.10195@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10192; Sat, 8 Aug 1992 00:40:52 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1789; Fri, 07 Aug 92 10:40:19 EDT Date: Fri, 7 Aug 92 10:40:45 EDT From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu, J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: my protocol does that too! Ref: Your note of Thu, 6 Aug 92 10:47:49 -0400 >One of the whole points of the Nimrod architecture was to >*avoid* the tough problems, and put them off for another day, >*precisely* so we can get something with lasting utility out quickly. And of course, sooner or later that "another day" will come, and the Internet will discover that the "tough problems" are still tough, and still have no solution. So, what would be "the lasting utility" of that that was deployed "to get something quickly" ? One "lasting utility" would be to spend our time and energy in building more and more elaborate and elaborately flawed designs whose perceived plausibility will be directly correlated to our ability to mystify. Yakov Rekhter From owner-big-internet@munnari.oz.au Sat Aug 8 01:29:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11138; Sat, 8 Aug 1992 01:29:11 +1000 (from owner-big-internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06990; Fri, 7 Aug 1992 22:49:07 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA29648 (5.65b/CWI-2.173); Fri, 7 Aug 1992 14:48:54 +0200 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA18807; Fri, 7 Aug 92 14:49:07 +0200 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA01790; Fri, 7 Aug 92 14:48:44 +0200 Message-Id: <9208071248.AA01790@dxcern.cern.ch> Subject: Re: Host Identifier and Location To: big-internet@munnari.oz.au Date: Fri, 7 Aug 92 14:48:42 MET DST From: Brian Carpenter CERN-CN In-Reply-To: <1936.713188680@munnari.oz.au>; from "Robert Elz" at Aug 7, 92 9:58 pm X-Mailer: ELM [version 2.3 PL11 CERN 11] >--------- Text sent by Robert Elz follows: > > If TUBA required a particular NSAP > format, I would be in violent opposition to it. > > I have exactly the opposite feeling - if TUBA (using CLNP > or any other technology for its big addresses) doesn't > require a particular addressing format I think I'll be > in violent opposition to it. ... > > Its essential that addresses be assigned so as to allow sane > routing aggregation (as in CIDR for IPv4) - for TUBA NSAP > addresses would have to have that requirement imposed upon > them. Other NSAPs that a site, or host, may have must be > ignored, the NSAP's used for TUBA must be assigned in a way > that they can be used for routing, and so that the mechansisms > scale well. My view is (taking my own site as an example): if we are under ICD 0020 for DECnet we would like to be under ICD 0020 for everything else, including TUBA. The reason is precisely to facilitate routing aggregation; the reasoning is as for CIDR. I can't accept that "Other NSAPs that a site, or host, may have must be ignored" - if you assume use of NSAPs then in some sense the Internet address space merges with the (metaphysical?) OSI address space and it will become a purely philosophical discussion where the Internet stops and something else starts. So my compromise between your two statements is: TUBA should recommend a particular NSAP format, chosen to facilitate routing aggregation, but should allow any other format (within reasonable limits). Isn't this what CIDR does for IPv4 addresses? Is this discussion on the right list? Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of CIDR, C#, | | IPv7, EIP, IPAE, (Mini)PIP, Nimrod or TUBA. | From owner-big-internet@munnari.oz.au Sat Aug 8 01:29:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11145; Sat, 8 Aug 1992 01:29:20 +1000 (from owner-big-internet) Return-Path: Message-Id: <9208071529.11145@munnari.oz.au> Received: from Relay.Prime.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07305; Fri, 7 Aug 1992 23:02:18 +1000 (from @Relay.Prime.COM:AL@TURBO.Kean.EDU) Received: from TURBO.Kean.EDU by Relay.Prime.COM; 07 Aug 92 09:02:53 EST Received: (from user AL) by TURBO.Kean.EDU; 07 Aug 92 08:58:09 EDT To: rlr@jhuvms.hcf.jhu.edu, fddi@list.kean.edu Cc: big-internet@munnari.oz.au From: Al Costanzo Organization: Kean College of New Jersey Security: -- none -- Comment: Sender Phone# (908) 527-2061 Comment: Sender Fax# (908) 527-2243 Subject: FDDI as the backbone Date: 07 Aug 92 08:58:09 EDT RLR: You missed the point of my statement.... Yes, you can configure FDDI to run TCP and give it an address -but- that would buy you nothing ... Consider this: What would happen if all the regional networks talked to the NSF backbone and their members via something else? FDDI is a token based network, you can run whatever you want on top of it. Even if just the regional nets and the NSF converted, do you realize that would free up some address space, would it not? Now I am not saying this is a permanent solution -but- considering the NSF is now running T3 links and actually CDDI can run over copper, it should at least be considered even for a fleeting moment. The people on the big-intenet list seem to be nothing more than using the address space issue to re-invent the wheel and throw in their own little "perks" into a perfectly good working product. Just increase the address space, don't re-invent the wheel! What I am saying is the Internet should take a lesson from Apple Computer and appletalk. Local talk, runs local, appletalk2 connects it to Ethernet. Two different speeds, zones etc. and tons of (excuse me Kilos) of address space. Why not let FDDI be the backbone -not running TCP/IP- and leave TCP/IP alone until you have time to increase the address space to 64 bits? Comments? -al From owner-Big-Internet@munnari.oz.au Sat Aug 8 01:31:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11190; Sat, 8 Aug 1992 01:31:44 +1000 (from owner-Big-Internet) Return-Path: Received: from SERVER.AF.MIL by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11181; Sat, 8 Aug 1992 01:31:18 +1000 (from jonson@server.af.mil) Received: by server.af.mil (5.59/25-eef) id AA05050; Fri, 7 Aug 92 10:07:49 CDT From: Matt Jonson Message-Id: <9208071507.AA05050@server.af.mil> Subject: Re: Host identifier length To: lwei@sparky.Eng.Sun.COM (Liming Wei) Date: Fri, 7 Aug 92 10:07:47 CDT Cc: clynn@BBN.COM, big-internet@munnari.oz.au In-Reply-To: <9208061956.AA06330@sparky.Eng.Sun.COM>; from "Liming Wei" at Aug 6, 92 12:56 pm X-Mailer: ELM [version 2.3 PL11] > Subject: Re: Host identifier length > From: Charles Lynn > Subject: Re: Host identifier length > > > > > > ... > > connection, how can it be derived from something like the 48-bit IEEE > > space? There is no reason to assume either that my TCP connection > > dies when a failed network interface is replaced, or that repair of a > > broken interface involves changing its built-in identifier. This > > leads to my unique identifier changing when my system reboots, or, if > > the EID is remembered, to some other system, which got the recycled > > interface, using the same EID. > > If you make the 48-bit IEEE number the station ID (probably what > it was originally defined for), not the interface ID, it will be > unique all the time. > On the one hand, this seems to have the same problem that Charles Lynn pointed out when a network interface has to be replaced, and on the other, there are plenty of non-unique ethernet boards out there in the world. Quite a few manufacturers required some configuration by the customer. It's a nice thing to have an address that is unique to a machine independent of its interfaces id. Is this something worth preserving? What are the trade-offs? Seems to me most of the issues in that case surround dynamic host configuration.It seems easier to map a local network only address on the fly to a globally unique address that is associated with a globally unique hostname than to have to map a globally unique hostname to potentially changing globally unique address even if it is trivially derived from an interface ID. /matt -- Lt Matthew W Jonson jonson@server.af.mil snail-mail: Network Systems Engineer 205-416-4075 SSC/SSDN USAF DDN Program Office AV: 596-4075 Gunter AFB, AL 36114 From owner-big-internet@munnari.oz.au Sat Aug 8 01:30:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11173; Sat, 8 Aug 1992 01:30:24 +1000 (from owner-big-internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10705; Sat, 8 Aug 1992 01:04:57 +1000 (from kasten@ftp.com) Received: by ftp.com id AA18592; Fri, 7 Aug 92 11:04:06 -0400 Date: Fri, 7 Aug 92 11:04:06 -0400 Message-Id: <9208071504.AA18592@ftp.com> To: jnc@ginger.lcs.mit.edu Subject: Re: Host identifier length From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au, clynn@bbn.com, jnc@ginger.lcs.mit.edu > how can it be derived from something like the 48-bit IEEE space > > repair of a broken interface [does not] involves changing its built-in > identifier. This leads to my unique identifier changing when my system > reboots, or, if the EID is remembered, to some other system, which got the > recycled interface, using the same EID. > > Ross and I discussed this. We agreed that there had to be something to >allow a host's EID to be manually configured, and not picked up from their >interface, to allow cases like this. Yes, there is a great deal of potential >for screwing up, but it hard to see how to use IEEE numbers and not face this. use of ieee 802 address has been posed as one possible way of deriving ones eid. not the only way. remember, one of the reasons we are arguing for 8 byte eids is that some of the bytes would be used to identify the "eid-granting authority". another mechanism could be a simple block of linear numbers given out by the nic. > Perhaps we can also convince workstation manufacturers to number their >workstations, and not just the interface cards, for those which don't have the >interface on the mother-board? Most workstations these days are going onto >networks *anyway*, and if we build an architeture in which having a number *in >the machine* makes the user's configuration job easier, it's a big selling >point, right? And IEEE is already set up to sell blocks of numbers to vendors.. the fly in this ointment is the millions of systems out there today which do not have such a hard-wired number in them. there are going to be many ways of getting eids. 802 addresses and system serial numbers are just two of them. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Sat Aug 8 01:38:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11350; Sat, 8 Aug 1992 01:39:05 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11346; Sat, 8 Aug 1992 01:38:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18029; Fri, 7 Aug 92 11:38:47 -0400 Date: Fri, 7 Aug 92 11:38:47 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208071538.AA18029@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, kasten@ftp.com Subject: Re: Host identifier length Cc: big-internet@munnari.oz.au, clynn@bbn.com use of ieee 802 address has been posed as one possible way of deriving ones eid. not the only way. Oh, I know, I'm just fiddling with the bits, a major pastime on this list! there are going to be many ways of getting eids. 802 addresses and system serial numbers are just two of them. Yes, we need to keep the problems with IEEE numebrs in perspective. Noel From owner-Big-Internet@munnari.oz.au Sat Aug 8 02:01:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11672; Sat, 8 Aug 1992 02:01:29 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11669; Sat, 8 Aug 1992 02:01:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18339; Fri, 7 Aug 92 11:56:09 -0400 Date: Fri, 7 Aug 92 11:56:09 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208071556.AA18339@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu, yakov@watson.ibm.com Subject: Re: my protocol does that too! Cc: big-internet@munnari.oz.au And of course, sooner or later that "another day" will come, and the Internet will discover that the "tough problems" are still tough, and still have no solution. So, what would be "the lasting utility" of that that was deployed "to get something quickly" ? Yakov, the *chief point* of Nimrod, and one which you seem sublimely indifferent to, is to provide a routing archiecture which is the *most minimal possible* framework. This has two goals: one, future work by people smarter than me on how to handle the admittedly touch problems of routing amaid complex policy constraints, abstration, etc, can be integrated without changing the basic (minimal) structure, and two, by making as few choices as possible about the unavoidable tradeoffs created by unsolvable problems, to leave it to future users how they want to balance those tradeoffs. One "lasting utility" would be to spend our time and energy in building more and more elaborate and elaborately flawed designs whose perceived plausibility will be directly correlated to our ability to mystify. I see. I suppose you think putting out an incremental thing which is tuned to to making good use of current cpu/bandwidth/memory resources is better? I don't know about you, but I (and other people who've been in this game a long time) are pretty tired of painful changes to things for incremental improvements. I'd like to remind everyone that an early version of TCP (2, I think?) had variable length addresses, but they took them out. The reasons I'm not completely clear on, I wasn't around then, and probably different people had different ones, but I suspect faster processing, and smaller header size (for line overhead), were among them. (The story I've heard about the number of registers available as pointer registers in the interrupt routines in TENEX, is, I am sure, probably apocryphal, or at least I hope it is!) The only true measure of an architecture is how long it lasts, because the change to a new one is so painful. This is true cubed of a communication architecture, since it's even harder to change it bit by bit. I can see not everyone agrees totally with that. I'm sure it's painfully obvious to everyone that that sort of thinking is the reason we are here today on this list. Yes, it has to be barely practical with today's technology, but beyond that you should stretch things are far as you can. Noel From owner-big-internet@munnari.oz.au Sat Aug 8 03:07:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12886; Sat, 8 Aug 1992 03:07:45 +1000 (from owner-big-internet) Return-Path: Received: from Sun.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11957; Sat, 8 Aug 1992 02:20:44 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA26422; Fri, 7 Aug 92 09:20:26 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA16923; Fri, 7 Aug 92 09:20:27 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA06075; Fri, 7 Aug 92 09:20:04 PDT Date: Fri, 7 Aug 92 09:20:04 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9208071620.AA06075@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA05922; Fri, 7 Aug 92 09:20:20 PDT To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au In-Reply-To: <9208071344.AA06953@chiya.bellcore.com> Subject: Re: my protocol does that too! Paul, > bi-transition > bi-routing > bi-protocol An interesting thought, but I think the issues are very interrelated. Bob From owner-big-internet@munnari.oz.au Sat Aug 8 07:23:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17097; Sat, 8 Aug 1992 07:23:46 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12966; Sat, 8 Aug 1992 03:10:38 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19833; Fri, 7 Aug 92 13:10:25 -0400 Date: Fri, 7 Aug 92 13:10:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9208071710.AA19833@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: So long, and thanks for all the packets Cc: jnc@ginger.lcs.mit.edu Well, I'm off to the wilds of Canada for two weeks for a family reunion, so you'll have a couple of weeks of peace and quiet (from me, at least :-). See you all soon, and remember: routing architecture != address structure != packet format Obviously, they are connected (and let's not argue about which to design first :-), but the connections aren't as tight as you might think. E.g. a PIP 'address' almost never appears in a packet; the thing in the RD is much more a source route.... Have fun, keep cool, may the best design win, and *no speculating about motives*! Noel From owner-big-internet@munnari.oz.au Sat Aug 8 08:00:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18230; Sat, 8 Aug 1992 08:00:21 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13556; Sat, 8 Aug 1992 03:30:26 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 7 Aug 92 13:30:10 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Fri, 7 Aug 92 13:30:10 EDT Date: Fri, 7 Aug 92 13:30:10 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208071730.AA07442@chiya.bellcore.com> To: Bob.Hinden@Eng.Sun.COM, tsuchiya@thumper.bellcore.com Subject: Re: my protocol does that too! Cc: big-internet@munnari.oz.au > > Paul, > > > bi-transition > > bi-routing > > bi-protocol > > An interesting thought, but I think the issues are very interrelated. > > Bob Yes, of course they are inter-related (so your point is that it would be impossible to decide which list to put what on). But I'm in complete sympathy with Noel. We have got to find a way to divide and conquer here. PT From owner-big-internet@munnari.oz.au Sat Aug 8 08:18:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18584; Sat, 8 Aug 1992 08:18:49 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13440; Sat, 8 Aug 1992 03:25:58 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 7 Aug 92 13:25:22 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Fri, 7 Aug 92 13:25:21 EDT Date: Fri, 7 Aug 92 13:25:21 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208071725.AA07400@chiya.bellcore.com> To: kasten@ftp.com, tsuchiya@thumper.bellcore.com Subject: Re: recognizing the topic at hand Cc: J.Crowcroft@cs.ucl.ac.uk, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu > > Is this silly? > > not silly, merely unrealistic. > > first, many of these issues are all inter-related, so, if multiple > lists are created, we will have the dreaded cross-post hydra rear its > ugly head (three copies of every message? i can barely keep track > of one copy...) Of course they are unrelated, but since I guess that most of the membership of the three groups would overlap, one could always post to only one of them, and to big-internet if it can't be decided which is right. > > second, this is another form of the "why can't people put the right > subject: in their header" complaint. if one does not make the subject: > correct, why assume that one would send stuff to the right list? and > since i would be on all three lists, i'll end up relying on the > subject field to differentiate between messages... You're right. Sigh. PT From owner-Big-Internet@munnari.oz.au Sat Aug 8 08:31:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18740; Sat, 8 Aug 1992 08:31:28 +1000 (from owner-Big-Internet) Return-Path: Received: from usc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18737; Sat, 8 Aug 1992 08:31:15 +1000 (from estrin%caldera.usc.edu@usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA23776; Fri, 7 Aug 92 15:30:57 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA07743; Fri, 7 Aug 92 15:30:56 PDT Date: Fri, 7 Aug 92 15:30:56 PDT Message-Id: <9208072230.AA07743@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin%caldera.usc.edu@usc.edu To: big-internet@munnari.oz.au Subject: map analogy Reply-To: estrin@usc.edu (slowly catching up on big-internet mail)... Noel used the metaphor of navigating a car based on a map and not a list of turn instructions. But another way is to get a trip-tix (sp?) from the Automobile Club. Very useful, particularly if you can get hold of the real map when/if the route fails for some reason (traffic accident, road repairs, dont want to pay tolls,etc). SO the trip-tix is the analog of a Path Vector. From owner-big-internet@munnari.oz.au Sat Aug 8 13:17:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24912; Sat, 8 Aug 1992 13:18:06 +1000 (from owner-big-internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17744; Sat, 8 Aug 1992 07:38:38 +1000 (from dee@ranger.enet.dec.com) Received: from inet-gw-2.pa.dec.com by shark.mel.dit.csiro.au with SMTP id AA18847 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 8 Aug 1992 04:39:55 +1000 Received: by inet-gw-2.pa.dec.com; id AA12438; Fri, 7 Aug 92 11:36:58 -0700 Received: by us1rmc.bb.dec.com; id AA19245; Fri, 7 Aug 92 14:34:12 -0400 Message-Id: <9208071834.AA19245@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Fri, 7 Aug 92 14:34:14 EDT Date: Fri, 7 Aug 92 14:34:14 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 07-Aug-1992 1436" To: al@kean.edu Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, al@kean.edu Subject: RE: Using FDDI as the Backbone Al, Avoiding details for brevity, there are two problems in the short term: address space due to the way the 32 bits is structured and routing table size due to the flatness of the 32 bit addresses. In the longer run, there are lots of additional problems 32 bits not being enough how to handle isochronous traffic the IP message id field not being big enough how to handle ubiquitous security how to handle mobile hosts policy routing questions etc. "Just increasing the address to 64 bits" actually requires lots of changes at lots of places in the system including DNS, FTP, all routing protocols, etc. The solution chosen for the short term crisis is CIDR (Classless Interdomain Routing) which will stave off collapse from possibly happening early in 1993 to some number of years from now. It involves much more minor changes than going to 64 bit addresses because it keeps 32 bit addresses. In fact, much of its benefits will come from its implementation at high level backbone nodes and many smaller IP4 nets may never bother with it. Donald -------------- From: US1RMC::"Al@Kean.EDU" "Al Costanzo" 7-AUG-1992 11:12 To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 07-Aug-1992 1056" CC: Subj: RE: Using FDDI as the Backbone Donald, Quite right! What I am say is change IP from a 32 bit to 64 bit address space period and leave everything else alone. No PIP or other protocol ideas. Just increase the address space if that is what the problem is! Do you see my point? Or am I lost? ---- original message: Forward-Path: Return-Path: Received: from inet-gw-2.pa.dec.com by TURBO.Kean.EDU; 07 Aug 92 10:56:02 EDT Received: by inet-gw-2.pa.dec.com; id AA06996; Fri, 7 Aug 92 07:56:40 -0700 Received: by us1rmc.bb.dec.com; id AA14158; Fri, 7 Aug 92 10:53:54 -0400 Message-Id: <9208071453.AA14158@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Fri, 7 Aug 92 10:53:55 EDT Date: Fri, 7 Aug 92 10:53:55 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 07-Aug-1992 1056" To: al@kean.edu Apparently-To: al@kean.edu Subject: RE: Using FDDI as the Backbone Al, TCP/IP (really just IP in this case) doesn't have a 64 bit address space, it has a 32 bit address space. Furthermore, the routing table expansions will kill things with current IP even if 32 bits were enough. Donald -------------- From: US1RMC::"Al@Kean.EDU" "Al Costanzo" 6-AUG-1992 17:49 To: big-internet@munnari.oz.au CC: fddi@list.kean.edu Subj: Using FDDI as the Backbone Hello, I have been listening to all of these protocol suggestions. Has anyone considered the ramifications of changing all backbone traffic to an FDDI token ring format. And if done, in such a way as to free up all the address space associated with the change , would this not help? And why is everyone so set on changing tcp/ip? What's wrong with a 64 bit address space? From owner-big-internet@munnari.oz.au Sat Aug 8 13:19:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24978; Sat, 8 Aug 1992 13:19:37 +1000 (from owner-big-internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17514; Sat, 8 Aug 1992 07:34:39 +1000 (from dkatz@cisco.com) Received: from cider.cisco.com by shark.mel.dit.csiro.au with SMTP id AA19171 (5.65c/IDA-1.4.4/DIT-1.3); Sat, 8 Aug 1992 05:35:35 +1000 Received: by cider.cisco.com; Fri, 7 Aug 92 12:32:41 -0700 Date: Fri, 7 Aug 92 12:32:41 -0700 From: Dave Katz Message-Id: <9208071932.AA26428@cider.cisco.com> To: kre@munnari.oz.au Cc: brian@dxcern.cern.ch, peter@goshawk.lanl.gov, big-internet@munnari.oz.au In-Reply-To: Robert Elz's message of Fri, 07 Aug 92 21:58:00 +1000 <1936.713188680@munnari.oz.au> Subject: Host Identifier and Location Date: Fri, 07 Aug 92 21:58:00 +1000 From: Robert Elz Date: Thu, 6 Aug 92 13:44:43 -0700 From: Dave Katz Message-ID: <9208062044.AA02681@cider.cisco.com> If TUBA required a particular NSAP format, I would be in violent opposition to it. I have exactly the opposite feeling - if TUBA (using CLNP or any other technology for its big addresses) doesn't require a particular addressing format I think I'll be in violent opposition to it. I guess my point is that if CLNP is used, then hosts should be able to interoperate regardless of their address format, but that a specific format (and allocation system) be provided to maximize efficiency. It's my belief that "the Internet" (whatever that actually includes) will be routing to arbitrary CLNP addresses to the extent that the service providers are willing to carry routes--I don't think it's possible to mandate an addressing scheme in this case, but only to provide economic carrots (and hammers). I doubt that router implementations will care particularly whether a route has a TUBA-style address or any other format (it's all just CLNP after all), so where is the mandate actually implemented? Mandating a particular address format means that all hosts using some other format are disenfranchised, which would seem to run counter to most people's desires. If all we gain out of big addresses is simply more of them we're just creating a bigger routing headache, in some senses it would be better to run out of addresses, and so impose a fundamental limit on the size of the internet, or the useful part of it, than to simply increase the number of addresses in an unstructured way, which would certainly result in total collapse due to routing overload. Its essential that addresses be assigned so as to allow sane routing aggregation (as in CIDR for IPv4) - for TUBA NSAP addresses would have to have that requirement imposed upon them. Other NSAPs that a site, or host, may have must be ignored, the NSAP's used for TUBA must be assigned in a way that they can be used for routing, and so that the mechansisms scale well. I certainly am not advocating unstructured addresses, nor is anyone involved in the deployment of CLNP. The requirements for scaling are well understood and the necessary hooks were put into IDRP before the CIDR effort even came about (the extensions for BGP4 were essentially lifted from IDRP). Now if TUBA runs over anything *other* than CLNP, then all bets are off, because you've just thrown away the leverage of existing product development, deployed base, and architecture familiarity, and you may as well invent something completely new and revolutionary, since it won't be worth anybody's time to invent yet another IP-and-CLNP-like protocol, its attendant routing protocols, and you might have difficulty convincing vendors to implement something that doesn't have a clear gain over what the work that's already been done. The PIP/Nimrod/etc. efforts are important and I think it's a good time to consider a paradigm shift, but people should not underestimate the time it will take to bring any of this to fruition. This seems to me to be a research effort that will hopefully pay off handsomely in the future, but it will be years before a production service will be fielded. From owner-big-internet@munnari.oz.au Sat Aug 8 13:33:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25508; Sat, 8 Aug 1992 13:33:56 +1000 (from owner-big-internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17751; Sat, 8 Aug 1992 07:38:47 +1000 (from estrin%caldera.usc.edu@usc.edu) Received: from usc.edu by shark.mel.dit.csiro.au with SMTP id AA18860 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 8 Aug 1992 04:41:06 +1000 Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA11245; Fri, 7 Aug 92 11:38:11 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA03602; Fri, 7 Aug 92 11:38:11 PDT Date: Fri, 7 Aug 92 11:38:11 PDT Message-Id: <9208071838.AA03602@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@caldera.usc.edu To: big-internet@munnari.oz.au Subject: OK, lets discuss routing... Reply-To: estrin@usc.edu While I Don't see the point of separating the addressing discussion off to some other list, I am delighted to shift focus for a while to the routing architecture. In particular, and in the local tradition of self-advertising, I would like to get comments from this group on the "Unified" routing architecture being developed by Yakov Rekhter, Steve Hotz, Tony Li and myself (others welcome! theme song goes here)... (IN truth, I was hoping someone ELSE on the list, aside from one of its developers was going to PIPE in and say all these things but I "timed out") At the end of this message i have listed references and we would GREATLY appreciate comments and discussion. But let me make a couple of general comments first to entice you to go "read the book"...and to move on for those of you who have done so already... (NOTE: these are my personal comments and do not necessarily reflect the exact opinions of my coauthors; well, you know sometimes people are a bit slow... :}) 1. Although Unified was inspired by the complementary characteristics of IDRP and IDPR, it is NOT simply running both protocols. In my mind, AND I expect to get some response out of Noel on this one..., it is taking the key architectural ideas of IDPR/Nimrod work (Source demand routing based on "map"/LS style protocol) and SOLVING the scaling/aggregation problems by using HBH, Path Vector computation of generic routes (of course needing good addressing scheme as all these things do), i.e., the HARD stuff that Noel refers to.... Note I said Path vector, not Distance vector. I think of Path vector as a form of aggregation/Thinning, or whatever the right term is (Don't yell at me noel, I admit that I am being lazy in not going back to your message in which you define those terms, but in part i expect it would only lead others to have to do the same so...). And because we have the complementary mechanism of getting around/through the aggregation with Source Demand Routing we get richness and scaling in the architecture. The Source Demand Routing Protocol (SDRP) component of the architecture is what I, and admittedly I ALONE, think of as IDPR version 2....Because it is still source demand routing based on maps, but many of the mechanisms are changed for two reasons: #1 it is designed in recognition of the complementary HBH PV mechanism being in place. #2 As with any successful research/adv development project I think we ("we" with my IDPR WG member hat on) figured out how to do some things (IN MY OPINION) better on round two... 2. Although The Path Vector protocol referred to is implemented in IDRP, this DOES NOT MEAN that UNified is intended as a routing architecture for CLNP (alone)!!!!! I think that Unified could as well be used with ipv4 (as we are working out details for as we speak), or PIP, for example. I am not saying that any routing works, and scales, with any addressing and packet format scheme. But that Unified needs the same thing from addressing and pkt format as perhaps Nimrod does. You need the kind of NSAP assignment that yakov referred to, but that seems to be common across the board... Anyway, maybe i am on a bit of a limb/off the subject here but the point is that this is not something that you should ignore because you think of it as part of the CLNP package... 3. So, For those of you who have read Unified, I would like to hear some discussion of how it succeeds and fails as a routing architecture for our target environment and time frame. Below is a) a pointer to the RFC, and a more concise version of it b) a note that we have a general description of our SDRP design; previously sent to a couple of WG lists; if you want that, send me email and i will send you the most recent version. c) status of current work *We published the rationale of our approach in RFC1322 earlier this year and a somewhat more concise/cleaned up version is available for anon ftp on: caldera.usc.edu ftp/pub/papers/idr-sigcomm.final.ps (as you can tell by its name it will be presented later this month at Sigcomm; if you cant print postscript, let me know and i can send you latex source or hard copy) ** Since writing those architecture papers we have made some progress on defining the Source Demand Routing Protocol (SDRP) component of the architecture and a draft overview of it to bgp-wg, idpr-wg, idrp-ip wg just before IETF. If you did not receive it and would like a copy, just send me mail. ** Tony, Yakov and I are in the midst of version 1 spec which we hope to submit as an Internet Draft at the end of the month; so once you read the above and are "anxious" for some detail, we would greatly appreciate comments on the "specifics" as well as the "generals"... From owner-Big-Internet@munnari.oz.au Sun Aug 9 20:09:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02774; Sun, 9 Aug 1992 20:09:22 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02771; Sun, 9 Aug 1992 20:09:19 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA28845 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sun, 9 Aug 1992 20:09:33 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA04478; Sun, 9 Aug 92 20:09:13 EST Message-Id: <9208091009.AA04478@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Evaluation issues Date: Sun, 09 Aug 92 20:09:13 +1000 From: Bob Smart One issue to discuss on the big-internet list is the criterion for evaluation of the proposals. There are a number of dimensions and all proposals are clearly behind on some [even Noel's]. 1. Does it solve the basic problems of address exhaustion and router resource overload? Proposals like Noel's which aim to postpone the address exhaustion problem need a clear path to an ultimate solution. 2. Does it make a start and/or lay a foundation for solving emerging problems: security/authentication, resource allocation, accounting, high packet rates? Since these are problems which we don't hope to solve now, we can not be sure that anything we do now will ultimately help. However a choice which is clearly going to require another change later will not go down too well. 3. How hard will it be to implement? This includes questions like: do we have to change hosts? routers? both? Can we use existing code with minor modifications? Experimental implementations are important here: notice how Craig Partridge's implementation investigation brought up issues with IPAE. 4. How will the new compare with the old for performance? The answer will often be different for a 4800 baud async line where you want small headers and don't care about processing requirements compared to a gigabit network where the reverse applies. 5. What are the dynamics of transition? For example if when we run out of IP4 addresses we send a message to the next requester: "You've just missed out on an IP4 network number, however here is an IP7 network number. We sure hope everybody else in the world will support IP7 soon so you can talk to them." That would be poor dynamics. Ideal dynamics will have no penalty on the new site with no IP4-routable address, but still have significant and increasing pressure on all sites to upgrade well before the first address which is not reachable from IP4-land is issued. 6. Aesthetics. Many will say this is not an issue, but if the chosen solution is too obviously a hack this will not be good for the Internet protocol suite. Bob Smart P.S. "The Hunting of the Snark" by Lewis Carroll is well worth reading. If we choose a boojum we'll softly and silently vanish away. You can get the complete text from ftp.uu.net:/doc/literary/gutenberg/etext91/snark12.txt.Z [it's in DOS format with CRLF at the end of each line]. Purchasing the real thing is worthwhile if it has the magnificent original illustrations. Martin Gardner's annotated version is good value. Anyway here are some quotes, the middle one perhaps refers to me :-). "Just the place for a Snark!" the Bellman cried, As he landed his crew with care; Supporting each man on the top of the tide By a finger entwined in his hair. "Just the place for a Snark! I have said it twice: That alone should encourage the crew. Just the place for a Snark! I have said it thrice: What i tell you three times is true." ... "His form is ungainly--his intellect small--" (So the Bellman would often remark) "But his courage is perfect! And that, after all, Is the thing that one needs with a Snark." ... He had bought a large map representing the sea, Without the least vestige of land: And the crew were much pleased when they found it to be A map they could all understand. "What's the good of Mercator's North Poles and Equators, Tropics, Zones, and Meridian Lines?" So the Bellman would cry: and the crew would reply "They are merely conventional signs! "Other maps are such shapes, with their islands and capes! But we've got our brave Captain to thank: (So the crew would protest) "that he's bought us the best-- A perfect and absolute blank!" ... [Later on there is an attempt to work out if a statement is true by using some intricate sounding mathematics to see if it has been said 3 times. I'm sure there's a relevant moral in that.] From owner-Big-Internet@munnari.oz.au Sun Aug 9 23:31:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06357; Sun, 9 Aug 1992 23:31:50 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9208091331.6357@munnari.oz.au> Received: from Relay.Prime.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06353; Sun, 9 Aug 1992 23:31:40 +1000 (from @Relay.Prime.COM:AL@TURBO.Kean.EDU) Received: from TURBO.Kean.EDU by Relay.Prime.COM; 09 Aug 92 09:33:54 EST Received: (from user AL) by TURBO.Kean.EDU; 09 Aug 92 09:28:04 EDT To: BIG-INTERNET@MUNNARI.OZ.AU Cc: smart@mel.dit.csiro.au From: Al Costanzo Organization: Kean College of New Jersey Security: -- none -- Comment: Sender Phone# (908) 527-2061 Comment: Sender Fax# (908) 527-2243 Subject: Re: Evaluation Issues Date: 09 Aug 92 09:28:04 EDT Bravo Bob! Much too often as I sit and read proposal after proposal on this list I wonder if the author of the proposal is off on some tangent or another with no sight to the actual problem in mind. (Or at least being somewhat obscurred by this- or-that in the proposal itself.) Now the basic problem left is (as I see it) ... Did they read and ingest what you said? Regards, Al Costanzo From owner-Big-Internet@munnari.oz.au Mon Aug 10 04:14:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13627; Mon, 10 Aug 1992 04:14:45 +1000 (from owner-Big-Internet) Return-Path: Received: from itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13623; Mon, 10 Aug 1992 04:14:36 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA26128; Sun, 9 Aug 92 14:14:26 EDT Date: Sun, 9 Aug 92 14:14:26 EDT From: atkinson@itd.nrl.navy.mil (Randall Atkinson) Message-Id: <9208091814.AA26128@itd.nrl.navy.mil> To: Big-Internet@munnari.oz.au Subject: Re: Evaluation Issues Cc: iesg@venera.isi.edu If I might, I'd like to put in a small plug for ensuring that authentication at the network layer isn't precluded. Towards this end, it would be nice if I could have an option (to whatever network layer protocol gets chosen) that would let me send along some kind of digital signature computed over the rest of the network frame (i.e. over everthing except the contents of this hypothetical digital signature option). It would also be nice if said protocol would allow plenty of space for options so that there is room for the digital signature, maybe some flavour of IPSO label, and whatever the normal options are. There is clearly a need for some kind of IP Sensitivity Label option in whatever gets selected. Those unfamiliar with such things might best glance at Mike St. Johns' "Son of IPSO" Internet-Draft (which is the best written proposal I've seen). Those of us in the US DoD (and probably some folkls in other places as well) would very much like to be able to build multi-level secure networks using as many conventional ("off the shelf" in government parlance) protocols as possible because that approach is cheaper, more interoperable, etc. While the NIST (now proposed to ANSI) SP3 network layer (SP4 is for the transport layer) protocol is one approach that is supported within DoD, it is by no means the only approach being explored. There is also a fair bit of interest in an authenticated -- but not confidential (i.e. not encrypted) -- network layer. I understand that what I've mentioned here are not dealing with the primary problems motivating change, but I hope that by mentioning them here that designers will try to ensure that they haven't precluded these pieces. (PIP in particular appears more difficult to authenticate end-host to end-host). Randall Atkinson Naval Research Laboratory Washington, DC 20375 From owner-Big-Internet@munnari.oz.au Mon Aug 10 10:44:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23489; Mon, 10 Aug 1992 10:44:51 +1000 (from owner-Big-Internet) Return-Path: Received: from usc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23485; Mon, 10 Aug 1992 10:44:45 +1000 (from estrin%caldera.usc.edu@usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA08968; Sun, 9 Aug 92 17:44:35 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA17749; Sun, 9 Aug 92 17:44:35 PDT Date: Sun, 9 Aug 92 17:44:35 PDT Message-Id: <9208100044.AA17749@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin%caldera.usc.edu@usc.edu To: big-internet@munnari.oz.au Subject: sorry, no anon ftp right now, send me email Reply-To: estrin@usc.edu if you want the sigcomm version of Unified paper . I forgot that we were having some problems with people posting junk on our system with anon ftp and no one has taken the time yet to set things up to disallow only anonymous puts... So for now send me email if you want the paper. Sorry for the inconvenience; this all just happened recently... From owner-Big-Internet@munnari.oz.au Mon Aug 10 17:19:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07038; Mon, 10 Aug 1992 17:19:48 +1000 (from owner-Big-Internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07035; Mon, 10 Aug 1992 17:19:39 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA09293 (5.65b/CWI-2.173); Mon, 10 Aug 1992 09:19:34 +0200 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA06329; Mon, 10 Aug 92 08:33:32 +0200 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA27396; Mon, 10 Aug 92 08:32:50 +0200 Message-Id: <9208100632.AA27396@dxcern.cern.ch> Subject: Re: my protocol does that too! To: big-internet@munnari.oz.au Date: Mon, 10 Aug 92 8:32:49 MET DST From: Brian Carpenter CERN-CN In-Reply-To: <9208071344.AA06953@chiya.bellcore.com>; from "Paul Tsuchiya" at Aug 7, 92 9:44 am X-Mailer: ELM [version 2.3 PL11 CERN 11] > > bi-transition > bi-routing > bi-protocol > > Where bi = big-internet > (1) You need to add bi-addressing. What address format you use is independent of the "protocol." (*) By the way, what's a "protocol"? It's certainly not a packet format, which is the only thing anyone has been discussing. (2) You need to add bi-strategy. How it all hangs together. This is where the overlpa issues would be covered. (*) New thread: You can argue that CLNP is an old fashioned design with no discernible advantage over IPv4. However, the NSAP address structure has a lot going for it (universal, flexible, structured, biiig). Has anybody seriously considered NSAP addresses but a new "protocol"? Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of CIDR, C#, | | IPv7, EIP, IPAE, (Mini)PIP, Nimrod or TUBA. | From owner-Big-Internet@munnari.oz.au Mon Aug 10 17:19:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07033; Mon, 10 Aug 1992 17:19:26 +1000 (from owner-Big-Internet) Return-Path: Received: from mcsun.EU.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07030; Mon, 10 Aug 1992 17:19:18 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA09241 (5.65b/CWI-2.173); Mon, 10 Aug 1992 09:19:10 +0200 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA07522; Mon, 10 Aug 92 08:55:06 +0200 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA28088; Mon, 10 Aug 92 08:54:28 +0200 Message-Id: <9208100654.AA28088@dxcern.cern.ch> Subject: Re: FDDI as the backbone To: big-internet@munnari.oz.au Date: Mon, 10 Aug 92 8:54:27 MET DST From: Brian Carpenter CERN-CN In-Reply-To: <9208071529.11145@munnari.oz.au>; from "Al Costanzo" at Aug 7, 92 8:58 am X-Mailer: ELM [version 2.3 PL11 CERN 11] > > What I am saying is the Internet should take a lesson from Apple Computer > and appletalk. Local talk, runs local, appletalk2 connects it to Ethernet. > Two different speeds, zones etc. and tons of (excuse me Kilos) of address > space. > No, NO, *NO*, to coin a phrase. At the risk of needing to call my lawyer, let's just say that Appletalk (Phase II) is NO model to be followed by anyone who wants a manageable, reliable and _big_ network. Appletalk, like ARP, assumes that multicasts are cheap and its whole philosophy on how to find resources is based on this. We _must_ get away from this approach if we want to scale to millions of nodes. The nearest thing to a unique, never-changing ID is the domain name of a system (although I could give lots of reasons why this may change too.) If we need a unique (binary) ID it had better be tied to the name by a DNS RR, so that I can change my computer (even the vendor) without changing ID. Regards, Brian Carpenter CERN, brian@dxcern.cern.ch voice +41 22 767 4967, fax +41 22 767 7155 | This is a personal opinion, and not an endorsement of CIDR, C#, | | IPv7, EIP, IPAE, (Mini)PIP, Nimrod or TUBA. | From owner-Big-Internet@munnari.oz.au Mon Aug 10 23:22:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16795; Mon, 10 Aug 1992 23:22:38 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16784; Mon, 10 Aug 1992 23:22:22 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Mon, 10 Aug 92 09:22:15 EDT Received: by chiya.bellcore.com (4.1/4.7) id for jnc@ginger.lcs.mit.edu; Mon, 10 Aug 92 09:22:14 EDT Date: Mon, 10 Aug 92 09:22:14 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208101322.AA09568@chiya.bellcore.com> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: So long, and thanks for all the packets > > routing architecture != address structure != packet format > > Obviously, they are connected (and let's not argue about which to design first > :-), but the connections aren't as tight as you might think. E.g. a PIP > 'address' almost never appears in a packet; the thing in the RD is much more a > source route.... > I'm trying to decide if this parting shot is a joke or not. But, just in case it isn't----one big point behind Pip is the recognition that a hierarchical address *is* essentially a source route. Therefore, Noel's sentence doesn't make sense, because address == source route. PT From owner-Big-Internet@munnari.oz.au Tue Aug 11 00:18:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19558; Tue, 11 Aug 1992 00:18:44 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-2.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19554; Tue, 11 Aug 1992 00:18:32 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA27498; Mon, 10 Aug 92 07:18:15 -0700 Received: by us1rmc.bb.dec.com; id AA15634; Mon, 10 Aug 92 10:15:27 -0400 Message-Id: <9208101415.AA15634@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Mon, 10 Aug 92 10:15:30 EDT Date: Mon, 10 Aug 92 10:15:30 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 10-Aug-1992 1018" To: big-internet@munnari.oz.au Cc: tuba@lanl.gov Apparently-To: tuba@lanl.gov, big-internet@munnari.oz.au Subject: 255 hops It was my impression that currently packets are usually sent with a Time-To- Live of around 64 to 127 and that, unless you have routing loops or something, around 30 to 35 hops is the max you need to get between any two points that can communicate on the current Internet of 10**6 hosts. I would think that doubling the number of hops roughly squares the size of net you can traverse. Thus going to a TTL of 128 to 255 and actually having to do a max of 70 or so hops should be adequate for 10**12 hosts which is about what people are predicting. Why is it then that the IAB draft on IP7 and discussions in the TUBA mailing list talk about the one byte TTL field as if it were a significant limitaion? Donald From owner-Big-Internet@munnari.oz.au Tue Aug 11 00:38:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20018; Tue, 11 Aug 1992 00:38:48 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20013; Tue, 11 Aug 1992 00:38:43 +1000 (from kasten@ftp.com) Received: by ftp.com id AA02366; Mon, 10 Aug 92 10:38:15 -0400 Date: Mon, 10 Aug 92 10:38:15 -0400 Message-Id: <9208101438.AA02366@ftp.com> To: dee@ranger.enet.dec.com Subject: Re: 255 hops From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au, tuba@lanl.gov >Why is it then that the IAB draft on IP7 and discussions in the TUBA mailing >list talk about the one byte TTL field as if it were a significant limitaion? > >Donald > donald i'm guilty of this. i was using it merely as an example in the discussion of how to deal with changing the tuba/clnp header in ways that may not be compatible with what iso wants. while the ttl size is something we may need to think about i have no data that shows that 1 byte is not enough. sorry for any confusion. -- frank kastenholz From owner-big-internet@munnari.oz.au Tue Aug 11 01:19:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21228; Tue, 11 Aug 1992 01:19:48 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17625; Mon, 10 Aug 1992 23:47:35 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Mon, 10 Aug 92 09:47:01 EDT Received: by chiya.bellcore.com (4.1/4.7) id for estrin@usc.edu; Mon, 10 Aug 92 09:46:59 EDT Date: Mon, 10 Aug 92 09:46:59 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208101346.AA09615@chiya.bellcore.com> To: big-internet@munnari.oz.au, estrin@usc.edu Subject: Re: OK, lets discuss routing... > > In particular, and in the local tradition of self-advertising, I > would like to get comments from this group on the > "Unified" routing architecture being developed by Yakov Rekhter, Steve > Hotz, Tony Li and myself (others welcome! theme song goes here)... Well, perhaps I should have spoken up earlier, but my life has been hectic lately, and I'm working hard on Pip, and blah blah blah.... I have for some time now considered the unified proposal to be the most sensible routing architecture on the table. I have long felt that good 'ol hierarchical addresses with path-vector routing would satisfy 90% or 99% of people's routing needs, and should be there. As for the other 10% or 1%, something more needs to be done. The work I did on multiple hierarchical addresses was an attempt to eek the remaining 1% out of an otherwise path-vector/hop-by-hop architecture, but in the end I don't think that multiple hierarchical addresses alone goes far enough, and some kind of source-based routing is needed. I still have reservations about real path setup, however, because of possible scaling problems. But, if the minority of packets are being routed this way, maybe not a big deal. ****Now for the Pip advertisement**** (Craig may wish to not read this part so as not to upset his sensibilities :-) I think Pip may have some very nice features with respect to unified. This is because the "plain old hierarchical addresses" needed for the "idrp" part of unified, and the "source route" needed for the "idpr" part of unified come out of the same structure (the Routing Directive). Therefore, to some extent, it seems to me that you can "tune in" additional policy as it is needed, and as the control protocol infrastructure evolves to provide the information needed to sources to decide how to compose source routes. In the extreme, you might need to do a real source setup, but Pip even allows for this in the same RD structure. ****End of Pip advertisement***** Actually, I decided just two nights ago that I would propose that the Pip proposal to be submitted in November essentially embrace the unified architecture (which has so many elements of idpr and nimrod that I hope the author's of those works do not feel that this is a rejection of their ideas). Indeed, my talks on Pip in Boston discussed mainly the "plain old hierarchical addresses" aspect of Pip for near term deployment, but evolution into sourc-based policy is so natural both with unified and with the Pip header structure that I would like to expand the initial Pip proposal to include a clear path towards full unified. Sorry I don't have more comments on unified per se. But I hope we can have a discussion about it on this list (especially now that Noel is away........ :-) PT From owner-Big-Internet@munnari.oz.au Tue Aug 11 01:51:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22073; Tue, 11 Aug 1992 01:52:00 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22070; Tue, 11 Aug 1992 01:51:54 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Mon, 10 Aug 92 08:51:41 -0700 Date: Mon, 10 Aug 92 08:51:41 -0700 From: Tony Li Message-Id: <9208101551.AA09807@cider.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: big-internet@munnari.oz.au, estrin@usc.edu In-Reply-To: Paul Tsuchiya's message of Mon, 10 Aug 92 09:46:59 EDT <9208101346.AA09615@chiya.bellcore.com> Subject: OK, lets discuss routing... ****Now for the Pip advertisement**** (Craig may wish to not read this part so as not to upset his sensibilities :-) I think Pip may have some very nice features with respect to unified. This is because the "plain old hierarchical addresses" needed for the "idrp" part of unified, and the "source route" needed for the "idpr" part of unified come out of the same structure (the Routing Directive). The problem is that the RD lacks the space for some of the more esoteric things that we want to be able to do for SDRP. For example, we are considering the case where you want to run SDRP over multiple different network layers. You might want to do this if there is a IPv7 cloud in the middle of the IPv4 network, for example. To do this, you must carry around all sorts of other interesting information (what am I doing now? oops, time to change network protocols...). So SDRP will end up using encapsulation, even over Pip. Yes, I can think of some intersting optimizations that can be done with SDRP over Pip, but these should certainly NOT impact the design of Pip. Tony From owner-Big-Internet@munnari.oz.au Tue Aug 11 04:33:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27085; Tue, 11 Aug 1992 04:33:46 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9208101833.27085@munnari.oz.au> Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27082; Tue, 11 Aug 1992 04:33:43 +1000 (from kre) Date: Tue, 11 Aug 1992 04:33:43 +1000 From: Robert Elz To: Big-Internet@munnari.OZ.AU Subject: Deborah Estrin's SIGCOMM Paper Is now available for anon ftp from munnari.oz.au - its in the big-internet directory, filename idr-sigcomm.final.ps kre From owner-Big-Internet@munnari.oz.au Tue Aug 11 05:31:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28775; Tue, 11 Aug 1992 05:31:10 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28768; Tue, 11 Aug 1992 05:31:03 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Mon, 10 Aug 92 15:30:47 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Mon, 10 Aug 92 15:30:46 EDT Date: Mon, 10 Aug 92 15:30:46 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208101930.AA10313@chiya.bellcore.com> To: tli@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: OK, lets discuss routing... Cc: big-internet@munnari.oz.au, estrin@usc.edu > > The problem is that the RD lacks the space for some of the more > esoteric things that we want to be able to do for SDRP. For example, > we are considering the case where you want to run SDRP over multiple > different network layers. You might want to do this if there is a > IPv7 cloud in the middle of the IPv4 network, for example. To do > this, you must carry around all sorts of other interesting information > (what am I doing now? oops, time to change network protocols...). So > SDRP will end up using encapsulation, even over Pip. Tony, I am having trouble understanding what you are really getting at here without additional context. Is there some document that describes your scenario that will help me? Are you assuming that the hosts on both ends are running SDRP, but there are routers in the middle that do not recognize SDRP? So, in order to get from one SDRP router to the next, you have to encapsulate in the protocol of the routers that lie between SDRP hops? (Or, in other words, SDRP is just a super-IP on top of existing IPs, which then get delegated to the current role of "networks" (in IP terminology). If this is the case, I can't figure out what all this other sorts of interesting information is that must go into the internet header. Current IP doesn't have to carry all kinds of interesting information about the subnetworks it crosses, so why should this be any different? For instance, lets say you have the following: H1-----ipv4-----S1------ipv4------S2-----ipv7-----H2 where H = host S = SDRP router ipvX = IP version X (non-SDRP) cloud So, the host forms an SDRP header, encapsulates it in ipv4, and ships it to S1. S1 decapsulates this and encaplulates in another ipv4 to get it to S2, etc. In other words, you are tunneling through ipvX clouds. But, it seems to me Pip can help you here, and at worst it doesn't hurt you. For instance, if nothing else you could make SDRP = Pip (that is, encode the SDRP identifiers into Pip headers). Is there something in the SDRP header that cannot be encoded in the Pip header? If so, I'd like to know about it. Then you have at least the same situation as if you made up a new SDRP header. And, tunneling (either through the explicit tunnel field or through self-encapsulation) is an intergral part of Pip, so encapsulating over ipv7, if ipv7 = Pip, is no big deal. But perhaps better yet is to don't do a cache-type source route setup, but just put the whole path (or as much of it as is necessary for the given policy) in the Pip header, ala my examples in the overview doc. In this case, the S boxes in the above diagram become Pip boxes, and if ipv7 also equals Pip, then you have one less level of complexity to deal with. You still have to encapsulate Pip over ipv4 to get through those clouds, but that goes without saying. PT From owner-Big-Internet@munnari.oz.au Tue Aug 11 07:41:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02127; Tue, 11 Aug 1992 07:41:38 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02124; Tue, 11 Aug 1992 07:41:32 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Mon, 10 Aug 92 14:41:21 -0700 Date: Mon, 10 Aug 92 14:41:21 -0700 From: Tony Li Message-Id: <9208102141.AA17484@cider.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: tsuchiya@thumper.bellcore.com, big-internet@munnari.oz.au, estrin@usc.edu In-Reply-To: Paul Tsuchiya's message of Mon, 10 Aug 92 15:30:46 EDT <9208101930.AA10313@chiya.bellcore.com> Subject: OK, lets discuss routing... I am having trouble understanding what you are really getting at here without additional context. Is there some document that describes your scenario that will help me? Sorry, not yet. It's still 'research'. The SDRP article that Deborah posted here earlier does describe some of the intent, without fleshing it out. Are you assuming that the hosts on both ends are running SDRP, but there are routers in the middle that do not recognize SDRP? No. We assume that either the hosts are speak SDRP, the routers speak SDRP, or some combination of these. So, in order to get from one SDRP router to the next, you have to encapsulate in the protocol of the routers that lie between SDRP hops? (Or, in other words, SDRP is just a super-IP on top of existing IPs, which then get delegated to the current role of "networks" (in IP terminology). Yes, exactly. And since the source route must be specified relative to the network layer that you're encapsulating in, the source route may end up being a hybrid of multiple protocol stacks with different levels of information (e.g, an OSI RD, and IP AS #, etc.). If this is the case, I can't figure out what all this other sorts of interesting information is that must go into the internet header. Exactly! Which is why it takes MORE than the Pip RD to do this. For example look at the probe bit. When and if we do setup, we would end up carrying around a path ID. Some folks want the QOS and UCI fields in the SDRP header. Do you put all of these in the Pip RD? For every packet? Current IP doesn't have to carry all kinds of interesting information about the subnetworks it crosses, so why should this be any different? What is "this"? For instance, lets say you have the following: H1-----ipv4-----S1------ipv4------S2-----ipv7-----H2 where H = host S = SDRP router ipvX = IP version X (non-SDRP) cloud So, the host forms an SDRP header, encapsulates it in ipv4, and ships it to S1. S1 decapsulates this and encaplulates in another ipv4 to get it to S2, etc. In other words, you are tunneling through ipvX clouds. Exactly. But, it seems to me Pip can help you here, and at worst it doesn't hurt you. I don't see how it helps significantly. For instance, if nothing else you could make SDRP = Pip (that is, encode the SDRP identifiers into Pip headers). Is there something in the SDRP header that cannot be encoded in the Pip header? Yes, please see Deborah's article. Please bear in mind that this describes only the first pass at SDRP, which needs further extension. I feel that we're still having the same discussion about extensibility of Pip.... Tony From owner-Big-Internet@munnari.oz.au Tue Aug 11 08:25:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03493; Tue, 11 Aug 1992 08:25:27 +1000 (from owner-Big-Internet) Return-Path: Received: from usc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03487; Tue, 11 Aug 1992 08:25:19 +1000 (from estrin@jerico.usc.edu) Received: from excalibur.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA15367; Mon, 10 Aug 92 15:25:12 PDT Received: by excalibur.usc.edu (4.1/SMI-3.0DEV3) id AA00651; Mon, 10 Aug 92 15:18:37 PDT Date: Mon, 10 Aug 92 15:18:37 PDT Message-Id: <9208102218.AA00651@excalibur.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@jerico.usc.edu To: big-internet@munnari.oz.au In-Reply-To: apology #2...triptix defn Subject: Re: map analogy Reply-To: estrin@usc.edu Sigh, i guess it is better when I DONT get around to answering mail... ANyway, i forgot to tell you what a triptix is...it is a list of directions and the narrow strips of map that you traverse in following them. So it is not just a bunch of relative terms, turn left, right, etc; it gives you an explicit path... From owner-Big-Internet@munnari.oz.au Tue Aug 11 12:01:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11118; Tue, 11 Aug 1992 12:01:34 +1000 (from owner-Big-Internet) Return-Path: Received: from Angband.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11114; Tue, 11 Aug 1992 12:01:26 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA05115; Mon, 10 Aug 92 19:01:02 -0700 Date: Sat, 8 Aug 92 12:32:47 EDT From: "William Allen Simpson" Message-Id: <610.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: group editor Over the last several weeks, this group seems to be coming to a consensus on features and terminology for a big internet. I think that we really need an editor to put together a document or documents which save the current rationale, and pro and con arguments for posterity. Any volunteers? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Tue Aug 11 17:12:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21623; Tue, 11 Aug 1992 17:12:18 +1000 (from owner-Big-Internet) Return-Path: Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21618; Tue, 11 Aug 1992 17:12:07 +1000 (from kre) To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au Subject: Re: So long, and thanks for all the packets In-Reply-To: Your message of Mon, 10 Aug 92 09:22:14 -0400. <9208101322.AA09568@chiya.bellcore.com> Date: Tue, 11 Aug 92 17:12:03 +1000 Message-Id: <2841.713517123@munnari.oz.au> From: Robert Elz Date: Mon, 10 Aug 92 09:22:14 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-ID: <9208101322.AA09568@chiya.bellcore.com> I'm trying to decide if this parting shot is a joke or not. But, just in case it isn't----one big point behind Pip is the recognition that a hierarchical address *is* essentially a source route. Therefore, Noel's sentence doesn't make sense, because address == source route. No no no no ... they're not the same at all, and its very important to distinguish between them. Source routes may be what we want to put in packets (as with pip, and other schemes), and they do replace what has traditionally been the "destination address" field in the packet (or augment it), but that doesn't make them the same. To use a physical analogy, if I were to tell you my address so you could come and visit me, it would be Robert Elz Room C137 Richard Berry Building University of Melbourne Parkville Victoria Australia Now, you might treat that as a source route, in the sense of "get to Australia", then "go to Victoria" (state), then to Parkville (town, city, or something, its really a suburb of Melbourne), then to the University of Melbourne (almost the whole of Parkville), then find the building (this is a tricky bit), then find the room (even harder), then find me (even harder, as I'm rarely here at the time when visitors come...) Now I know that people like to think of this kind of hierarchical address as being a source route, but its really not, as I could give the same thing to Bob Smart, and most of it is meaningless, so he just ignores it all and comes directly to my room. The kind of source route that we want for packets, which I believe is generally the kind that PIP uses, is more like Go to Newark airport Catch a flight to SFO Change planes, get a flight to Melbourne (via Sydney) From Melbourne airport, get the skybus to one of the city hotels on Swanston St Take tram number 1 north to the university tram stop Enter the university and the Richard Berry building is right there down the corridor, up the flight of stairs, ring the doorbell, ask for kre (which is the kind of thing I actually tell people). Now that's fine asssuming you're really at Bellcore just now, when you were at UCL, something more like "get to Heathrowe, catch a flight via Singapore, ..." would be more appropriate. Or then again, in some circumstances, you may want to "catch a flight via Huston" - which my brother happens to be doing later this month, for policy reasons .. that is, on flights through the US airlines allow 2 pieces of baggage per person, on others the limit is 20Kg, he's willing to take the longer, slower, flight to avoid the excess baggage he would otherwise have to pay... Similarly, if I handed the above source route to Bob Smart and expected him to follow it, he'd probably exceed his TTL before he ever reached me... This relates to the questions I asked about PIP a week or two ago ... directories will contain addresses, that's all we can expect, as they're the only thing that's independant of the source of the packet - something has to convert these addresses into source routes to go in PIP headers, which includes optimising away redundant parts of the address, finding a suitable path taking into account policy constraints, and merging that with the path out of the local domain (which is where the route fragments stuff may be appicable). But please don't equate source routes with addresses, hierarchical addresses may be (simplistically) a degenerate form of a source route, but they most certainly aren't the same. kre From owner-Big-Internet@munnari.oz.au Tue Aug 11 23:13:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02102; Tue, 11 Aug 1992 23:14:05 +1000 (from owner-Big-Internet) Return-Path: Received: from mts-gw.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02097; Tue, 11 Aug 1992 23:13:57 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA21672; Tue, 11 Aug 92 06:13:44 -0700 Received: by sneezy (5.57/ULTRIX-4.2-3)id AA26751; Tue, 11 Aug 92 09:13:29 -0400 To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: tli@cisco.com, big-internet@munnari.oz.au, estrin@usc.edu Subject: Re: OK, lets discuss routing... In-Reply-To: <9208101930.AA10313@chiya.bellcore.com> References: <9208101930.AA10313@chiya.bellcore.com> X-Mailer: Poste 2.0B3 From: Dave Oran Date: Tue, 11 Aug 92 09:12:59 -0400 Message-Id: <920811091259.19811@sneezy.lkg.dec.com> Encoding: 39 TEXT, 6 TEXT SIGNATURE > Are you assuming that the hosts on both ends are running SDRP, > but there are routers in the middle that do not recognize SDRP? > So, in order to get from one SDRP router to the next, you have > to encapsulate in the protocol of the routers that lie between > SDRP hops? (Or, in other words, SDRP is just a super-IP on top > of existing IPs, which then get delegated to the current role > of "networks" (in IP terminology). > At the risk of completely misinterpreting what Tony's getting at, perhaps I should add to the confusion by throwing in my interpretation. Let's suppose you have different regions of an Internet that use different network layer datagram protocols. Further, it is possible to translate among the data packet formats (e.g. IPv4-->IPv7, CLNP-->IPv7, and their inverses) at the boundaries of the regions. (It may also be possbile to handle yet other DG protocols like XNS and DECnet Phase IV in this fashion). In such a topology, you probably want to run a single SDRP independent of the data packet protocol. The reason is that SIN routing won't get you the end-to-end path/policy semantics SDRP advertises as its main feature. Further, transit policy boundaries might be forced to be coincident with protocol carriage boundaries, which people have objected to in the case of Integrated ISIS. I'm not necessarily advocating translation over encapsulation here, but it may be worthwhile figuring out if pathological scenarios involving three or four levels of encapsulation might arise in the SDRP case. Lastly, since the SDRP folks have gone to great lengths in their work to keep independent of a particular data carriage protocol it seems prudent to avoid giving up this property unless there are persuasive arguments why exploiting the particular features of a new internet protocol outweigh the potential problems involved of working around the absence of those features when forced to carry the data in a different packet format. So, did I completely miss the boat here? Dave O. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@sneezy.lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Wed Aug 12 00:15:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04611; Wed, 12 Aug 1992 00:15:36 +1000 (from owner-Big-Internet) Return-Path: Received: from hobbit.gandalf.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04605; Wed, 12 Aug 1992 00:15:28 +1000 (from chris@cannibal.gandalf.ca) Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA18309; Tue, 11 Aug 92 10:15:21 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA21645; Tue, 11 Aug 92 10:15:19 EDT Date: Tue, 11 Aug 92 10:15:19 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9208111415.AA21645@cannibal.gandalf.ca> To: big-internet@munnari.oz.au Subject: Forwarding What if packets could tell routers which interface to forward onto? Something like record route might be used to record a locally valid interface number, to be used at the discretion of a router to reach the next hop. So each recorded hop would have associated with it a number which was the interface number used by the previous hop router to reach it. Kind of a distributed forward cache or something. Could this only-locally-valid info be distributed with a forwarding info distribution protocol, or piggybacked onto a routing protocol? Could the numbering of interfaces by routers be organized such that the same data types/widths are used by all/most routers? Just random neural firings. -Chris Sullivan From owner-Big-Internet@munnari.oz.au Wed Aug 12 01:09:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05734; Wed, 12 Aug 1992 01:09:22 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05731; Wed, 12 Aug 1992 01:09:17 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 11 Aug 92 11:09:04 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Tue, 11 Aug 92 11:09:02 EDT Date: Tue, 11 Aug 92 11:09:02 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208111509.AA11039@chiya.bellcore.com> To: tli@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: OK, lets discuss routing... Cc: big-internet@munnari.oz.au, estrin@usc.edu > > So, in order to get from one SDRP router to the next, you have > to encapsulate in the protocol of the routers that lie between > SDRP hops? (Or, in other words, SDRP is just a super-IP on top > of existing IPs, which then get delegated to the current role > of "networks" (in IP terminology). > > Yes, exactly. And since the source route must be specified relative > to the network layer that you're encapsulating in, the source route > may end up being a hybrid of multiple protocol stacks with different > levels of information (e.g, an OSI RD, and IP AS #, etc.). Oh. Maybe now I understand what you are thinking about. You envision a source route setup with information derived *from the numbering space* of the incident protocol. That is, the route setup might have an actual NSAP address, and an actual AS #, etc? I was assuming that you would have a separate "overlay" numbering space that SDRP understands. So, you could take a CLNP island, and give it an SDRP number, and an IP island, and give it another SDRP number, and so on. If you do it this way, then you don't have to worry about putting all kinds of disparate information in a packet header (or the route setup). > example look at the probe bit. When and if we do setup, we would end > up carrying around a path ID. Some folks want the QOS and UCI fields > in the SDRP header. Do you put all of these in the Pip RD? For every > packet? Is the UCI you are referring to here the connection identifier of Clark's? If so, I guess you don't want both a path ID and a UCI. If it is something else, then you need to tell me what it is. But you can certainly put QOS and path ID in the Pip RD. Upon thinking about it, you could even put QOS, path ID, *and* full address information in every packet, but I'm not sure why you would need both path ID and full address info, since forwarding on full address info in Pip is pretty fast anyway. > > I feel that we're still having the same discussion about extensibility > of Pip.... > I think perhaps we should stop talking about extensibility of Pip, and just determine whether it can do the things people are thinking about now (even if those things are researchy and out in the future). If you can tell me what you are thinking about, I can tell you whether and how Pip can do them. PT From owner-Big-Internet@munnari.oz.au Wed Aug 12 01:23:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06207; Wed, 12 Aug 1992 01:23:50 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06203; Wed, 12 Aug 1992 01:23:46 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Tue, 11 Aug 92 08:19:54 -0700 Date: Tue, 11 Aug 92 08:19:54 -0700 From: Tony Li Message-Id: <9208111519.AA03308@cider.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: tsuchiya@thumper.bellcore.com, big-internet@munnari.oz.au, estrin@usc.edu In-Reply-To: Paul Tsuchiya's message of Tue, 11 Aug 92 11:09:02 EDT <9208111509.AA11039@chiya.bellcore.com> Subject: OK, lets discuss routing... > example look at the probe bit. When and if we do setup, we would end > up carrying around a path ID. Some folks want the QOS and UCI fields > in the SDRP header. Do you put all of these in the Pip RD? For every > packet? Is the UCI you are referring to here the connection identifier of Clark's? If so, I guess you don't want both a path ID and a UCI. If it is something else, then you need to tell me what it is. But you can certainly put QOS and path ID in the Pip RD. Upon thinking about it, you could even put QOS, path ID, *and* full address information in every packet, but I'm not sure why you would need both path ID and full address info, since forwarding on full address info in Pip is pretty fast anyway. No, I was thinking of the User Class Identifier (ala IDPR). Yes, this could go in the Pip RD. I think perhaps we should stop talking about extensibility of Pip, and just determine whether it can do the things people are thinking about now (even if those things are researchy and out in the future). If you can tell me what you are thinking about, I can tell you whether and how Pip can do them. I think that Dave has just done that more eloquently than I ever could. Do you still have questions? Tony From owner-Big-Internet@munnari.oz.au Wed Aug 12 03:04:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08176; Wed, 12 Aug 1992 03:04:41 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08173; Wed, 12 Aug 1992 03:04:36 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 11 Aug 92 13:04:26 EDT Received: by chiya.bellcore.com (4.1/4.7) id for chris@gandalf.ca; Tue, 11 Aug 92 13:04:26 EDT Date: Tue, 11 Aug 92 13:04:26 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208111704.AA11351@chiya.bellcore.com> To: big-internet@munnari.oz.au, chris@gandalf.ca Subject: Re: Forwarding > > What if packets could tell routers which interface to forward onto? > This was proposed by Cheriton et. al.--something called Sirpent. It is in one of the Sigcomm conferences (several years back). PT From owner-Big-Internet@munnari.oz.au Wed Aug 12 03:05:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08184; Wed, 12 Aug 1992 03:05:47 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08181; Wed, 12 Aug 1992 03:05:42 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 11 Aug 92 13:05:31 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Tue, 11 Aug 92 13:05:30 EDT Date: Tue, 11 Aug 92 13:05:30 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208111705.AA11359@chiya.bellcore.com> To: tli@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: OK, lets discuss routing... Cc: big-internet@munnari.oz.au, estrin@usc.edu > > I think that Dave has just done that more eloquently than I ever > could. Do you still have questions? > Yes, but I think I need to go off and read the SDRP docs before asking more questions...... PT From owner-Big-Internet@munnari.oz.au Wed Aug 12 05:00:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12303; Wed, 12 Aug 1992 05:01:08 +1000 (from owner-Big-Internet) Return-Path: Received: from vtvm1.cc.vt.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12286; Wed, 12 Aug 1992 05:00:58 +1000 (from VALDIS@vtvm1.cc.vt.edu) Received: from vtvm1.cc.vt.edu by VTVM1.CC.VT.EDU (IBM VM SMTP V2R2) with BSMTP id 1602; Tue, 11 Aug 92 15:00:25 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 9938; Tue, 11 Aug 92 15:00:24 EDT Date: Tue, 11 Aug 92 14:41:41 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Forwarding To: Chris Sullivan , big-internet@munnari.oz.au In-Reply-To: <9208111415.AA21645@cannibal.gandalf.ca> Message-Id: <920811.144141.EDT.VALDIS@vtvm1.cc.vt.edu> On Tue, 11 Aug 92 10:15:19 EDT Chris Sullivan said: >Something like record route might be used to record a locally valid interface >number, to be used at the discretion of a router to reach the next hop. So >each recorded hop would have associated with it a number which was the >interface number used by the previous hop router to reach it. Chris: Are you saying that a collection of these would look like: or should it be: I'm not sure that in either case, forward-propogating this information would be a sensible thing to do, as you're not as "sure" about the info as you would be about (say) an EGP update packet. The random data packet may have been wandering around a routing swamp for a while, and emerged at an inappropriate place. You have to take *special* care with ICMP packets so that "Net Unreachable" errors don't further pollute things if a route goes astray. Of course, assuming that all the vendors do TTL "right", you *know* that there exists a path from your current location, to the source site, that was operational within the relatively near past. Opinions anybody? Is this method of gathering network routing info any better/worse than relying on routing table packets? I'm slightly concerned about the overhead involved - how many "flows" does the average Internet router support concurrently now? Would you want to sample *every* packet, or do things on a statistical basis? In addition, this would tend to enforce symmetric routing between two endpoints - I'm not positive if it's a Good Thing or not - symmetry is nice, but may not always be appropriate? Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Wed Aug 12 10:26:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21617; Wed, 12 Aug 1992 10:26:49 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21603; Wed, 12 Aug 1992 10:26:42 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Tue, 11 Aug 92 17:26:35 -0700 Date: Tue, 11 Aug 92 17:26:35 -0700 From: Tony Li Message-Id: <9208120026.AA20779@cider.cisco.com> To: big-internet@munnari.oz.au Subject: IP address allocation ID now available A new draft of the IP address allocation recommendations is now available as ftp.cisco.com:tli/address.txt. This version has already been submitted as an Internet Draft and should appear there very shortly. Tony From owner-Big-Internet@munnari.oz.au Wed Aug 12 18:27:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05570; Wed, 12 Aug 1992 18:27:19 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9208120827.5570@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05565; Wed, 12 Aug 1992 18:27:11 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 12 Aug 1992 09:26:40 +0100 To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au Subject: Re: Forwarding In-Reply-To: Your message of "Tue, 11 Aug 92 13:04:26 EDT." <9208111704.AA11351@chiya.bellcore.com> Date: Wed, 12 Aug 92 09:26:38 +0100 From: Jon Crowcroft >> What if packets could tell routers which interface to forward onto? >This was proposed by Cheriton et. al.--something called Sirpent. >It is in one of the Sigcomm conferences (several years back). sigcomm 89, "Sirpent: A High Performance Internetwork Architecture" D Cheriton - mainly on cut through, but also highly relevant routing architecture to pip - worth a re-read... jon From owner-Big-Internet@munnari.oz.au Thu Aug 13 07:47:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04368; Thu, 13 Aug 1992 07:48:36 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04353; Thu, 13 Aug 1992 07:47:49 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11961>; Wed, 12 Aug 1992 14:47:18 PDT Received: from localhost ([127.0.0.1]) by skylark.parc.xerox.com with SMTP id <10779>; Wed, 12 Aug 1992 14:47:12 -0700 To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: So long, and thanks for all the packets In-Reply-To: Your message of Tue, 11 Aug 92 00:12:03 -0700. <2841.713517123@munnari.oz.au> Date: Wed, 12 Aug 1992 14:47:11 PDT From: Steve Deering Message-Id: <92Aug12.144712pdt.10779@skylark.parc.xerox.com> > But please don't equate source routes with addresses, > hierarchical addresses may be (simplistically) a degenerate > form of a source route, but they most certainly aren't the same. Hear, hear! I had been meaning to post a very similar message. I think those who are saying the hierarchical addresses are just an example of source routes are fuzzifying an important distinction: hierarchical addresses are *addresses*, i.e., they tell *where* something is, at several levels of granularity/abstraction. source routes are *routes*, i.e., they tell *how* to reach something; they are made up of a sequence of addresses, with no notion of levels of granularity/abstraction. That the processing of hierarchical addresses and source routes may be made superficially similar, as in Pip (which still needs the "up" and "down" indicators for hierarchical addresses, but not for source routes, if I understand correctly), should not be used to hide the fact that they have very different semantics. Steve From owner-big-internet@munnari.oz.au Fri Aug 14 03:53:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27594; Fri, 14 Aug 1992 03:53:15 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13196; Thu, 13 Aug 1992 23:32:38 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 13 Aug 92 09:32:22 EDT Received: by chiya.bellcore.com (4.1/4.7) id for kre@munnari.oz.au; Thu, 13 Aug 92 09:32:22 EDT Date: Thu, 13 Aug 92 09:32:22 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208131332.AA13304@chiya.bellcore.com> To: deering@parc.xerox.com, kre@munnari.oz.au Subject: Re: So long, and thanks for all the packets Cc: big-internet@munnari.oz.au > Hear, hear! I had been meaning to post a very similar message. I think > those who are saying the hierarchical addresses are just an example of > source routes are fuzzifying an important distinction: > > hierarchical addresses are *addresses*, i.e., they tell *where* > something is, at several levels of granularity/abstraction. I completely disagree. The notion of "where" in a network has absolutely no meaning outside the context of routing tables. That is, if a router had no routing table, an address, hierarchical or not, would hold no meaning for it. But, a routing table tells a router *how* to reach something. So, and address is a trigger for the router to know *how* to reach something. Perhaps we are arguing angels on a pin here, but to me the simple fact that you can use a source-route construct to capture the semantics of a hierarchical address means that a hierarchical address is indeed a form of source route. > > That the processing of hierarchical addresses and source routes may be made > superficially similar, as in Pip (which still needs the "up" and "down" > indicators for hierarchical addresses, but not for source routes, if I The "up" and "down" indicators are merely to allow for number reuse in the addressing space. If you were to use globally unique numbers for every "element" in the hierarchy, then there would be no need for the "up" and "down". Viewed this way, I think the semantic similarity between a source route and a hierarchical address (or, a route segment-- same thing) become more clear. > understand correctly), should not be used to hide the fact that they have > very different semantics. Anyway, in spite of my inclination to argue this point, I think we should not worry about whether a address is or is not a source route, and worry instead about what header formats can do what (among other things to worry about). PT From owner-big-internet@munnari.oz.au Fri Aug 14 04:05:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28515; Fri, 14 Aug 1992 04:05:32 +1000 (from owner-big-internet) Return-Path: Received: from usage.csd.unsw.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13618; Thu, 13 Aug 1992 23:45:14 +1000 (from pwb%newt@newt.phys.unsw.EDU.AU) Received: from newt.phys.unsw.EDU.AU by usage.csd.unsw.OZ.AU with SMTP id AA05172 (5.65c/IDA-1.4.4 for ); Thu, 13 Aug 1992 23:44:36 +1000 Received: by newt.phys.unsw.edu.au (5.57/Ultrix3.0-C) id AA12471; Thu, 13 Aug 92 23:44:28 +1000 Message-Id: <9208131344.AA12471@newt.phys.unsw.edu.au> From: pwb@newt.phys.unsw.edu.au (Paul W. Brooks esq.) Date: Thu, 13 Aug 1992 23:44:27 EST X-Mailer: Mail User's Shell (7.1.1 5/02/90) To: big-internet@munnari.oz.au Subject: Re: Hierarchical addressing vs Source Routes (was Re:So long, and...) Thus expounded Steve Deering on Aug 12, 2:47pm: /-------------------- |those who are saying the hierarchical addresses are just an example of |source routes are fuzzifying an important distinction: | | hierarchical addresses are *addresses*, i.e., they tell *where* | something is, at several levels of granularity/abstraction. | | source routes are *routes*, i.e., they tell *how* to reach something; | they are made up of a sequence of addresses, with no notion of | levels of granularity/abstraction. This may be duplicating something everyone knows already, but I feel the need to take a step back and reflect on what what we are trying to achieve. Forgive me if this has been thrashed out before, but I've been listening to this list for just long enough to get confused by the specifics and acronyms, and lose the big picture! Maybe I'm missing something, but this has jelled a view that has been running around my head for a while - it seems to me that the routing-table size problem would be best solved by hierarchical addressing. At the moment we map a hierarchical address (A DNS name) into a non-hierarchical ID (The IP number) and send the IP number to the lower layer. It seems self-evident to me that things would be much simpler if we just used something with the same properties as the FQ Domain Name (only reversed) possibly geographically based. Take my hosts name - newt.phys.unsw.edu.au. Routers outside Australia shoudn't have to know about all the networks inside Australia - all they should need to know is the direction to shunt packets for *.au - a single entry. Once it gets to a router which has its own 'address' as *.au, it looks at the next field, and so on. This gets the packet to a router (something).phys.unsw.edu.au, who knows about host 'newt', and passes it along. Each router then needs to know about: 1) All hosts and routers of the next level down (but none at any lower levels). 2) One router at the higher level (and none above that). 3) Routers (and hosts) at the same level, to remove the need for a bottleneck 'root router'. ...a sort of tree arrangement like postal addressing. This provides route aggregation, can provide support for mobile hosts (If you are changing addresses, put an optional 'return address' or 'my new address is..' on the back of the envelope/packet. It also provides for variable-length addressing. I don't know if this is generally true, but here the majority of traffic is for machines within the campus. A lesser proportion is for machines within Australia but outside campus, and a lesser proportion still for further machines. Variable length addressing means that the majority of the traffic has the shortest addresses embedded in them, which are faster to parse. As 'newt.phys.unsw.edu.au' I could send each packet to 'isaac.phys.unsw.edu.au' by just using the address 'isaac.phys'. Its also easily extensible - when we open colonies on Mars and the Moon we just tack another component on the end. The local host only needs to know its own name component and (possibly) the next highest component, and the whole address of the host being communicated with (at least,up to the point where the address components become the same) and best of all it scales O(log n) (n = total number of hosts). - If we open settlements on other planets, we add one component to the maximum possible length. If we go to another star, we should probably start using yet another level. We don't need to add another level until we get to Andromeda! Oh, and the addresses are globally unique, and hierchically assignable :-) This is getting a little long-winded. I guess I'm saying that it seems to me that if we addressed and routed on DNS name rather than IP number, the limited address problem and routing table size problem would go away, although thats rather simplistic. I know the DNS name as we know it is not allways suitable (The '.edu','.com' etc parts are not very helpful for geographically-based addressing). If I'm way off-base feel free to email me direct... -- Paul Brooks |Internet: pwb@newt.phys.unsw.edu.au Uni. of N.S.W. |If you have trouble sleeping, try lying on the end of Kensington NSW 2033| your bed. With a little luck you'll drop off. AUSTRALIA | - Mark Twain. From owner-Big-Internet@munnari.oz.au Fri Aug 14 04:21:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29210; Fri, 14 Aug 1992 04:22:12 +1000 (from owner-Big-Internet) Return-Path: Received: from alpha.Xerox.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29200; Fri, 14 Aug 1992 04:21:58 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11678>; Thu, 13 Aug 1992 11:21:40 PDT Received: from localhost ([127.0.0.1]) by skylark.parc.xerox.com with SMTP id <10779>; Thu, 13 Aug 1992 11:21:32 -0700 To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: So long, and thanks for all the packets In-Reply-To: Your message of Thu, 13 Aug 92 06:32:22 -0700. <9208131332.AA13304@chiya.bellcore.com> Date: Thu, 13 Aug 1992 11:21:28 PDT From: Steve Deering Message-Id: <92Aug13.112132pdt.10779@skylark.parc.xerox.com> > > hierarchical addresses are *addresses*, i.e., they tell *where* > > something is, at several levels of granularity/abstraction. > > I completely disagree. I completely disagree with your disagreement. > The notion of "where" in a network has absolutely no meaning outside the > context of routing tables. That is, if a router had no routing table, > an address, hierarchical or not, would hold no meaning of it. But, a > routing table tells a router *how* to reach something. Right. It's not enough just to know where something is (its address), but you also need to know how to reach it (a route). You have pointed out another distinction between hierarchical addresses and source routes: - When handed a packet with a hierarchical address, a router needs some additional state -- a routing table -- to know where to forward the packet. - When handed a packet with a strict source route, a router has all it needs to know where to forward the packet. Loose source routing is a hybrid: you need a routing table to tell you how to get to the next address in the loose source route. Another distinction is that, with a source route, each element must be processed in turn, whereas with a hierarchical address, it's possible to ignore the boundaries between address parts, treating the concatenation of several address parts as a single identifier. Thus, the notion of "longest match" makes sense for routing on hierarchical addresses, but not for source routing. > Anyway, in spite of my inclination to argue this point, I think we > should not worry about whether a address is or is not a source route, > and worry instead about what header formats can do what (among other > things to worry about). Well, let's first decide what it is we want to do with addressing/routing, and then see if particular header formats can accommodate that. The fact that a particular header format can dice carrots is of little interest if we don't want to dice carrots. Steve From owner-Big-Internet@munnari.oz.au Fri Aug 14 04:26:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29404; Fri, 14 Aug 1992 04:26:40 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29400; Fri, 14 Aug 1992 04:26:32 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 13 Aug 92 14:26:23 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Thu, 13 Aug 92 14:26:23 EDT Date: Thu, 13 Aug 92 14:26:23 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9208131826.AA13808@chiya.bellcore.com> To: deering@parc.xerox.com, tsuchiya@thumper.bellcore.com Subject: Re: So long, and thanks for all the packets Cc: big-internet@munnari.oz.au > > Well, let's first decide what it is we want to do with addressing/routing, > and then see if particular header formats can accommodate that. The fact > that a particular header format can dice carrots is of little interest > if we don't want to dice carrots. > > Steve > I agree we should first decide what we want to do. On the other hand, even if we don't want to dice carrots now, who knows if we might want to dice carrots next year. Also, if a device both dices carrots and makes julian fries, AND it costs no more and is as easy to use as a device that only makes julian fries, I'd buy the carrot dicer/julian fry maker. This is not quite to say that you don't pay something for Pips generality, but I'm not convinced that you pay much. PT From owner-Big-Internet@munnari.oz.au Fri Aug 21 04:56:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18089; Fri, 21 Aug 1992 04:56:17 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18080; Fri, 21 Aug 1992 04:56:10 +1000 (from dave@sabre.bellcore.com) Return-Path: Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA25780; Thu, 20 Aug 92 14:59:01 EDT Received: by sword.bellcore.com;id 9208201857.AA29570 Message-Id: <9208201857.AA29570@sword.bellcore.com> Date: Thu, 20 Aug 1992 15:01:29 -0500 To: big-internet@munnari.oz.au From: dave@sabre.bellcore.com Subject: I-D available on CLNP for TUBA For those of you who are not on both big-internet and tuba, but wish to keep informed on at least the "milestones": A copy of the Internet-draft I'm submitting to the IESG Secretariat describing the use of ISO 8473 (CLNP) in TUBA environments is available via anonymous ftp from host thumper.bellcore.com under the directory pub/davep in the file named draft-tuba-clnp.txt I will be on vacation 8/22-8/30; please post comments to tuba@lanl.gov --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) From owner-Big-Internet@munnari.oz.au Fri Aug 21 05:42:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19724; Fri, 21 Aug 1992 05:42:22 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19719; Fri, 21 Aug 1992 05:42:14 +1000 (from dave@sabre.bellcore.com) Return-Path: Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA26133; Thu, 20 Aug 92 15:45:05 EDT Received: by sword.bellcore.com;id 9208201944.AA00784 Message-Id: <9208201944.AA00784@sword.bellcore.com> Date: Thu, 20 Aug 1992 15:47:52 -0500 To: John Curran From: dave@sabre.bellcore.com Subject: Re: Internet-draft of CLNP for TUBA Cc: tuba@lanl.gov, big-internet@munnari.oz.au > John writes: > draft-tuba-clnp.txt > >Hmm.. it's there, but I get permission denied. I hate unix:-( I've changed mode, and tried to anonymous ftp, it works now --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax)