From owner-Big-Internet@munnari.oz.au Thu Oct 1 00:13:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00324; Thu, 1 Oct 1992 00:13:35 +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 AA00321; Thu, 1 Oct 1992 00:13:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: from GINGER.LCS.MIT.EDU by shark.mel.dit.csiro.au with SMTP id AA14954 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 1 Oct 1992 00:09:41 +1000 Received: by ginger.lcs.mit.edu id AA08915; Wed, 30 Sep 92 10:06:48 -0400 Date: Wed, 30 Sep 92 10:06:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209301406.AA08915@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu, tli@cisco.com Subject: Re: SIP Cc: jnc@ginger.lcs.mit.edu BGP carries NO expensive policy baggage. In contrast, IDPR has the wonderful property that it floods your policies througout the ENTIRE world. This is true, in a sense, but only because the policy tools in BGP are so poorly and minimally integrated into the protocol. (Actually, this is sort of hard to avoid, given the simplistic attributes of Destination Vector routing, so I won't get too exercised about it.) On the surface, there is no policy info being sent in BGP, but BGP policies and their effects *do* flood throughout the entire network. Because BGP policies effect what goes into the BGP routing table, and thus, what gets sent on to the neighbours, BGP policy information *does* flood throughout the entire system. It's just not in an immediately visible (and perhaps useful) form, but rather implicit in the AS paths which are tagged onto each route. Even more perniciously, local BGP policy decisions are enforced on distant sites, whether they like it or not. For example, when a BGP site R which is the only path from source S to destination D has two alternate paths from itself to D, P1 and P2, and elects for local policy reasons to only use P1, then S can never use P2 to get to D, even if it would prefer to, or must! So here too, BGP policies are being flooded throughout the entire system, only again, not in an explicit (and perhaps manageable) way. This is not to say that BGP is not a useful tool; clearly it is better than EGP, and we need to get it implemented and deployed, particularly the BGP-4 variant which we need for CIDR. It's just not the right thing for the long term. Also, other DV protocols do have a little better support for policy routing (IGRP has a tiny bit, and the NR part of Unified has some), but it's inevitably limited becuase of the limitation ofthe DV approach when used to handle policies (because of the distributed nature of the algorithm, which requires shipping partial results around). Your point about IDPR policies flooding the system is sort of true; there are some provisions in IDPR to have super-domains which reduce the global visibility of local policy information, but in general local policies (I guess this is a tautology; all policies are local to some degree) are visible throughout the system. In any case, it's not clear that this represents more actual overhead than the path-vectors in BGP, and it may be less. Parenthetically, it was in an attempt to manage this global visibility of policy (and topology) information that the Nimrod and IDPR efforts parted ways. They (for good reasons, including the funding agency wanted to see something working :-) bit off a certain amount and masticated it to produce the working IDPR protocols. I continued on to think about the issues of abstraction in the presence of policies, and how to manage the inevitable "thinning" (technical term) which comes with this; Nimrod is the result of this thinking. Noel From owner-Big-Internet@munnari.oz.au Thu Oct 1 00:14:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00359; Thu, 1 Oct 1992 00:14:28 +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 AA00356; Thu, 1 Oct 1992 00:14:24 +1000 (from jnc@ginger.lcs.mit.edu) Received: from GINGER.LCS.MIT.EDU by shark.mel.dit.csiro.au with SMTP id AA14961 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 1 Oct 1992 00:10:35 +1000 Received: by ginger.lcs.mit.edu id AA08859; Wed, 30 Sep 92 09:46:11 -0400 Date: Wed, 30 Sep 92 09:46:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9209301346.AA08859@ginger.lcs.mit.edu> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: SIP Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Wow, a really impressive melt-down! Still, it lacks the fine quality of one of Yakov's, so you only get 3 stars. :-) Well, on to serious business. What's hierarchical routing??! ... If you don't know what hierarchical routing is ... Go away and study the elementary routing literature (Kleinrock and Kamoun, "Hierarchical routing for large networks; performance evaluation and optimization", ... and then take a look at OSPF and IS-IS ... for examples of hierarchical routing protocols (albeit, only supporting two levels of hierarchy) I'm afraid you missed the point I was trying to make, perhaps because I didn't give the 3 page version nobody would read :-). Let me do so explicitly. *Every* scheme for dealing with a large network uses a heirarchy; I've not heard (nor can I conceive) of any other way of handling routing in a very large network. To say that you are using 'hierarchical' routing in a large network is thus like saying that you are designing a car 'with an engine'; doesn't really tell you very much about the car! What's important about a routing architecture are the elements I listed (what information, etc), and I got no information on that front from your message. For instance (and this is *just* an example) you seem, by implication of retaining BGP, OSPF, etc, to be retaining the architectural split between EGP's and IGP's. Is this a deliberate design decision, and if so, can you give me your reasoning as to why? The *chief* current problem with routing is *scaling*, not lack of *policy* machinery! If you want to work on policy routing, that's fine, but we have an immediate engineering problem of how to let the Internet grow bigger [interfering] in what could otherwise be the smooth operation of conventional, hierarchical, hop-by-hop routing protocols. You don't know how much I wish I believed this. I used to be very loath to let people play with the routing; I was convinced that automatic algorithms could as good a job as humans, and I thought that if you let the humand poke around, they would just foul things up. Unfortunately, I had some real world experience that taught me otherwise. The first generations of the Proteon router product embodied this spirit of routing; the routing protocols just found the best route for you, and that was that; no knobs. This did not please the customers. In fact, they were fairly unhappy (i.e. they bought other boxes). They demanded knobs; square knobs, round knobs, red knobs, blue knobs, etc, etc. I resisted this impulse on their part with a fair amount of vigor, because I though it was the Wrong Thing, which shows how little I knew about business. I'm now wiser (and poorer than if I hadn't had this destructive vision, alhough this was a minor problem alongside many larger ones). Anyway, real demand for policy routing is just the way the world works. People don't always want just the best route, but have funny little reasons and desires having little to do with 'best' for making their traffic go other places. If you really think otherwise, how would *you* react if you were only allowed to take a single path from A to B when driving your car, for all A and B? there is *too much* policy intervention (in the form of static tables in various boundary routers) I agree with you that these tables are too large. However, I attribute this more to the brain damaged designs you have to resort to to make policy routing work in a Destination Vector architecture. The mechansisms available to you (large tables which modify incoming routing table info) are very orthagonal to what you are trying to do (e.g. get to a certain class of destinations through one carrier if that carrier is up). It's sort of like to spread grass seed with a spoon, instead of a seed spreader; because the tool is poorly conformed to the job, it takes much more work than it should. Who said anything about IDPR? With apologies to Martha, I don't consider IDPR to be part of the current Internet routing architecture. It may well become so, some day, but the SIP proposal certainly does not depend on that being the case. In other words, the SIP proposal has no individual vision for a routing architecture, but you'll take whatever others decide on? Now, to the degree that IDPR is a link-state inter-domain routing protocol that can be used to compute routes for hop-by-hop forwarding, The whole point of IDPR is that it *does not allow* hop-by-hop forwarding (at least at the levels at which it operates). it may in fact be preferable to BGP, which is burdened with expensive policy baggage. This is probably the most minor problem with BGP. Even better might be simply to add a few more levels of hierarchy to OSPF, and use that for inter-domain routing. Am I to understand that you don't favor the EGP/IGP split, then? (Don't worry; I think the EGP/IGP split is almost complete brain-damage myself although I do concede there was a time when it was useful and necessary. :-) In case you haven't guessed, "policy-based routing" is one of my hot buttons I'm shocked, *shocked*, to find gambling, uh, people who hate policy routing... :-) I'd like to hear more than handwaving arguments from you about nebulous new routing and addressing architectures Sad to say, it's an unfortunate characteristic of architectures that they don't have packet formats. If the various funding sources to which Martha and I have applied for Nimrod funding will cough up the $$$, we can provide an actual design based on these ideas for you all to kick the tires on. In the meantime, IDPR contains about 65% of what's in Nimrod, so people who want real bits can start there. which you can't explain concretely enough for anyone else to understand I think the "anyone" is a bit of an exxageration. A number of people, including some of the more talented routing protocol designers in the Internet, seem to be able to understand them quite well, and have signed up to help with Nimrod when the funding arrives. There is a straightforward solution to the Internet scaling problems that involves increasing the address size and, hence, changing the packet format I disagree with the reasoning step there (i.e. I don't believe that the conclusion follows necessarily from the premise), and in any case, the characterization of "straightforward" is wholly inappropriate. Something that involves deploying a new packet format in hosts is not "straightforward". Noel PS: Just out of interest, it would be useful to know what percentage of the people on this list have read the IDPR specs, or even the IDPR architecture document... if there some way to poll a subset of the list to get a representative sample? From owner-Big-Internet@munnari.oz.au Thu Oct 1 00:43:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02460; Thu, 1 Oct 1992 00:43:32 +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 AA02449; Thu, 1 Oct 1992 00:43:19 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA02611; Wed, 30 Sep 92 07:42:49 -0700 Date: Wed, 30 Sep 92 09:18:12 EDT From: "William Allen Simpson" Message-Id: <773.bill.simpson@um.cc.umich.edu> Cc: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: packet format v. routing architecture It seems to me that it will be a very long time (if ever) before the issues of routing architecture are solved. Individual historical anecdotes have shown that most of the issues raised here in the past few months have been raised many other times in the past decade. If we wait another 10 years until the routing issues are completely resolved, we will not have the new platform ready on which to implement. It has been estimated that we have only 3 to 5 years. I do not know when in the past decade Van Jacobson stated that we should wait before defining a new packet format, or whether he indicated a specific event which would determine that the time for waiting was over. I think that we have run out of research time, but then ... I'm no Van Jacobson ;-) We can try to add the appropriate features to the new platform to support the possible future routing architectures. - SIP designers are currently debating whether to add a single field which could better support flow reservation and/or type of service, and already includes a source routing feature. - PIP designers are currently debating how to add a variable number of variable length fields to better support source routing, flow reservation, type of service, the universe and everything. However, it can *absolutely* be stated that: - if Nimrod+IDPR can run over IP4, it can run over PIP, SIP, or TUCAN. - if BGP/IDPR/Unified can run over IP4, it can run over PIP, SIP, or TUCAN. Therefore, the issue is merely whether to bother adding type of service and/or flow reservation to the header in the hopes that it might be useful at some future time. We have managed to get along without it in IP4 for some years now (TOS having been widely ignored). I am personally in favor of adding such a feature, as long as it doesn't take up too much room. If it is never used, there is no great loss. Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Thu Oct 1 01:11:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03554; Thu, 1 Oct 1992 01:11:40 +1000 (from owner-Big-Internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03549; Thu, 1 Oct 1992 01:11:29 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA00377 (5.65c/UK-2.1-920831); Wed, 30 Sep 1992 11:16:06 -0400 From: Gary Scott Malkin Date: Wed, 30 Sep 1992 11:16:06 -0400 Message-Id: <377.199209301516@atlas.xylogics.com> To: kre@munnari.oz.au Cc: big-internet@munnari.oz.au In-Reply-To: Robert Elz's message of Wed, 30 Sep 92 13:07:43 +1000 <8048.717822463@munnari.oz.au> Subject: SIP > Keeping (some kind of) checksum field is important so that > those options all remain open to the router. It is true that a router can always decide not to check an incoming checksum. However, the existance of the field will require that all routers compute an outgoing checksum. So it's not entirely optional. I tend to agree with those who believe that an IP header checksum is unnecessary. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Thu Oct 1 02:02:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05312; Thu, 1 Oct 1992 02:02:30 +1000 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05303; Thu, 1 Oct 1992 02:02:20 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA12689; Wed, 30 Sep 92 09:02:11 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA00704; Wed, 30 Sep 92 12:02:10 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA18082; Wed, 30 Sep 92 12:00:38 EDT Date: Wed, 30 Sep 92 12:00:38 EDT From: Frank T. Solensky Message-Id: <9209301600.AA18082@fenway.andr.UB.com> To: sob@hsdndev.harvard.edu Subject: Re: thanks but ... :-) Cc: big-internet@munnari.oz.au >From: sob@hsdndev.harvard.edu (Scott Bradner) > >> By way of a reminder, I've just put the updated graphs onto munnari.oz.au >> for general distribution. > >can I get a bit more of a hint as to just were on munnari? > big-internet/nsf-netnumbers-9210.ps From owner-Big-Internet@munnari.oz.au Thu Oct 1 02:43:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06810; Thu, 1 Oct 1992 02:43:50 +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 AA06797; Thu, 1 Oct 1992 02:43:36 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA09493; Wed, 30 Sep 1992 17:44:32 +0100 Message-Id: <199209301644.AA09493@mitsou.inria.fr> To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au Subject: Re: packet format v. routing architecture In-Reply-To: Your message of "Wed, 30 Sep 92 09:18:12 EDT." <773.bill.simpson@um.cc.umich.edu> Date: Wed, 30 Sep 92 17:44:30 -0500 From: Christian Huitema X-Mts: smtp Bill, Thanks for tuning down the discussion. A while ago, I thought that the kind of exchanges we saw on the list was typically French, a symptom of a libertarian + equalitarian society where diplomacy is regarded as "aristocratic" (or other names to same effect). I have learnt better since. As far as routing vs format, and scrap iron vs pie in the sky, lets observe simply that todays scrap iron can handle reasonably 10**6 hosts and 5000 nets with three levels of hierarchy and 32 bits of addresses. 10**12 hosts could probably be accomodated with recycled scrap iron, six levels of hierarchy and 64 bits of addresses. Steve is probably correct; but any advance in the scrap iron recycling process will certainly be welcomed. Christian Huitema From owner-Big-Internet@munnari.oz.au Thu Oct 1 02:58:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07556; Thu, 1 Oct 1992 02:58:55 +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 AA07548; Thu, 1 Oct 1992 02:58:46 +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 2287; Wed, 30 Sep 92 12:57:50 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 2189; Wed, 30 Sep 92 12:57:50 EDT Date: Wed, 30 Sep 92 12:53:58 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: TOS in SIP To: William Allen Simpson , big-internet@munnari.oz.au, bsimpson@angband.stanford.edu In-Reply-To: <771.bill.simpson@um.cc.umich.edu> Message-Id: <920930.125358.EDT.VALDIS@vtvm1.cc.vt.edu> On Tue, 29 Sep 92 18:08:30 EDT you said: >That's a good example. The servers that I'm familiar with use a >separate IP address for each terminal. How else would you keep the >sessions separate (using IP4)? What kind of terminal server is this that you use? All our gear sorts out connections based on the 4-tuple (remote IP, remote port, local IP, local port) - where the "server" port is usually 23, and the other one some random unique number. Maybe you're thinking of terminal servers that support SLIP? That's a seperate beast entirely, and *does* require a seperate IP address for each physical connection, because it has to pass the port numbers on to the machine at the other end of the wire... But of course, the proper name for a terminal server that's doing SLIP or PPP is a 'router'... Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Thu Oct 1 03:12:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08188; Thu, 1 Oct 1992 03:15:01 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08099; Thu, 1 Oct 1992 03:12:41 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-1.pa.dec.com; id AA00918; Wed, 30 Sep 92 10:07:16 -0700 Received: by us1rmc.bb.dec.com; id AA12470; Wed, 30 Sep 92 13:03:23 -0400 Message-Id: <9209301703.AA12470@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Wed, 30 Sep 92 13:03:24 EDT Date: Wed, 30 Sep 92 13:03:24 EDT From: Ross Callon To: tracym@nsd.3com.com Cc: deering@parc.xerox.com, big-internet@munnari.oz.au Apparently-To: tracym@nsd.3com.com, deering@parc.xerox.com, big-internet@munnari.oz.au Subject: re: Re: SIP - a summary of the field allocation debate > > I've always hated the TCP psuedo-header, since it made TCP unreasonably > > dependent on the particular lower layer. Look at the efforts to define > > TCP over CLNP. > > That's just a result of an inadequate abstraction. The TCP pseudo-header > checksum should be thought of as a sum over the packet length value plus the > network layer's addressing information, for whatever network layer you are > using. In the case of IP, the addressing information is source address, > destination address, and protocol; for CLNP, it's the source and destination > NSAP addresses. What is the particular difficulty that has been encountered > with CLNP? I am not aware of any problems. Basically, for TUBA we need a definition of what to use in the pseudoheader, but this is not hard to do. Either the entire address is included in the pseudoheader, or the address contains a global ID, and the ID is included in the pseudoheader. Now, finding the time to work on Internet scaling issues, that is hard! Ross From owner-big-internet@munnari.oz.au Thu Oct 1 04:12:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09629; Thu, 1 Oct 1992 04:12:34 +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 AA07339; Thu, 1 Oct 1992 02:53:44 +1000 (from estrin@jerico.usc.edu) Received: from excalibur.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.0) id AA09276; Wed, 30 Sep 92 09:53:30 PDT Received: by excalibur.usc.edu (4.1/SMI-3.0DEV3) id AA03045; Wed, 30 Sep 92 09:58:16 PDT Date: Wed, 30 Sep 92 09:58:16 PDT Message-Id: <9209301658.AA03045@excalibur.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@jerico.usc.edu To: deering@parc.xerox.com Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au In-Reply-To: Steve Deering's message of Wed, 30 Sep 1992 00:39:19 PDT <92Sep30.003928pdt.10779@skylark.parc.xerox.com> Subject: Re: SIP Reply-To: estrin@usc.edu I agree with quite a bit of Steve's note, minus the anti-policy-rhetoric. A few corrections 1) BGP has no more policy baggage than does IDPR 2) BGP and its more refined cousin IDRP both are designed to exploit hierarchical aggregation. THat is there number one feature. 3) HOWEVER, where I disagree with you steve is in downplaying the need to handle exceptions and flexible aggregation. We want maximal use of aggregation and hierarchy for all the common cases, BUT we want to be able to route around that in those cases where the generic routes dont fit the needs. OTHERWISE, if our only choice is AGGREGATION FOR ALL OR NONE we will end up WITHOUT the aggregation for even the common cases. Path Vector routing has very good scaling properties when it comes to aggregation for the common case. Sorry, I am spewing Unified propaganda again...Details are available in Internet RFCs and Internet Drafts and Papers on BGP, IDRP and SDRP... From owner-Big-Internet@munnari.oz.au Thu Oct 1 04:54:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10875; Thu, 1 Oct 1992 04:54:15 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9209301854.10875@munnari.oz.au> Received: from OAKLAND.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10869; Thu, 1 Oct 1992 04:54:05 +1000 (from malis@BBN.COM) To: Christian Huitema Cc: Steve Deering , big-internet@munnari.oz.au, malis@BBN.COM Subject: Re: SIP - a summary of the field allocation debate In-Reply-To: Your message of Tue, 29 Sep 92 10:25:13 -0500. <199209290925.AA06767@mitsou.inria.fr> Date: Wed, 30 Sep 92 14:50:53 -0400 From: Andy Malis If I can briefly interrupt Steve and Noel's fisticuffs ... > Old New Comment > Version 4 bits 0 Redundant with subnet level protocol ID. I would still like to lobby for a Version field, even if, as Steve suggested (perhaps jestingly) it just has its high bit on in the proper position with the other bits used for another purpose. Given that the size of the header is going to increase to at least 24 or 32 bytes, we should try to keep link-layer protocol IDs as compact as possible for the benefit of those folks still running slow links (remember, for example, that >90% of the leased lines in Europe are still 64 Kb or less, and there's lots of X.25 and ISDN in use as well). For X.25, Frame Relay, and ISDN, IP has the benefit of having a compact, one-octet protocol ID (CC). If you move to something requiring an Ethertype, then you have to add five more bytes for a SNAP header (see RFCs 1294 and 1356). In addition, reusing the same protocol ID means less implementation work; you don't have to change your link layer driver to recognize and send a new protocol type - you just kick the packet up to your switching process, which cases on the version number (as it should anyway). For those worried about the use of anything other than 4 in the Version field, 5 (ST and ST-II) has been in use in the Internet for quite some time. Cheers, Andy From owner-Big-Internet@munnari.oz.au Thu Oct 1 07:03:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15906; Thu, 1 Oct 1992 07:03:58 +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 AA15898; Thu, 1 Oct 1992 07:03:33 +1000 (from kre) To: Gary Scott Malkin Cc: big-internet@munnari.oz.au Subject: Re: SIP In-Reply-To: Your message of Wed, 30 Sep 92 11:16:06 -0400. <377.199209301516@atlas.xylogics.com> Date: Thu, 01 Oct 92 07:03:26 +1000 Message-Id: <8359.717887006@munnari.oz.au> From: Robert Elz Date: Wed, 30 Sep 1992 11:16:06 -0400 From: Gary Scott Malkin Message-ID: <377.199209301516@atlas.xylogics.com> However, the existance of the field will require that all routers compute an outgoing checksum. Not recompute, adjust. I wouldn't think we'd pick a checksum algorithm that requires the router to recompute it - nor would we want to encourage that, or perhaps even allow it - I would strongly advise against recomputing without validating the original first, that would truly make the checksum a waste of time. As for how much effort is involved to do the adjustment, I'd like to hope that on many modern processors, with careful header design, we can make it be zero - ie: get the checksum adjustment for free - or if not completely free, close enough that it will bother no-one. How? Simple - put the checksum in the same word as something that has to be changed anyway, for which I'd suggest the TTL. Modern processors have to read the word (or if they're capable of only reading part of a word, don't run any faster because of it) anyway - so they load the ttl & checksum together. the ttl has to be changed, probably by 1, the checksum has to be changed to compensate. I'm sure there's someone out there able to design a single instruction for each of the likely choice of router processors that will do the two changes with one add or subtract, possibly by requesting some particular layout of the header to make it function, and perhaps some specific checksum algorithm to help. Then the modified ttl must be written back to memory, the modified checksum can go along for the ride. If we have packets that require modifications to more than the ttl, then the corresponding checksum changes can be folded in between the load of the ttl/checksum and store back into the header, adding perhaps one (non memory referencing) instruction for each other modification. Routers that use custom silicon for the common path forwarding functions should be able to use just the same techniques. I don't really think the checksum update is an issue at all, of itself, its certainly something to bear in mind when the final question of which bits go where in the header is being nailed down. kre From owner-Big-Internet@munnari.oz.au Thu Oct 1 14:45:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07992; Thu, 1 Oct 1992 14:45:27 +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 AA07984; Thu, 1 Oct 1992 14:45:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17051; Thu, 1 Oct 92 00:45:08 -0400 Date: Thu, 1 Oct 92 00:45:08 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210010445.AA17051@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, bsimpson@angband.stanford.edu Subject: Re: packet format v. routing architecture Cc: jnc@ginger.lcs.mit.edu (I'm restricting myself to one or two bouts of mail answering per day, to minimize traffic!) It seems to me that it will be a very long time (if ever) before the issues of routing architecture are solved. I'm not sure I can completely go along with this. A lot of progress has been made in the past 25+ years, and while we probably have a long way to go on some of the algorithms, I think it's now possible to design an overall architecture which is pretty good. I realize you can't make an ironclad logical case for this, but I will note that programming languages reached a pretty good plateau in a shorter time... Individual historical anecdotes have shown that most of the issues raised here in the past few months have been raised many other times in the past decade. All this *really* shows is that there is a repeating process of education happening, as each new wave of people joining walks down the same path. If we wait another 10 years until the routing issues are completely resolved Research on better algorithms is going to be going on for a lot longer than that. That's why you *have* to build an architecture in which new route finding algorithms can be easily and interoperably deployed. That architecture we know how to build today, I think. However, it can *absolutely* be stated that: - if Nimrod+IDPR can run over IP4, it can run over PIP, SIP, or TUCAN. - if BGP/IDPR/Unified can run over IP4, it can run over ... Exactly, although I suppose we should add the current Internet lashup as a third option for a routing architecture. I'd *love* to see another *well thought out* candidate routing architecture show up, but I'm not holding my breath. We have managed to get along without it in IP4 for some years now (TOS having been widely ignored). I am personally in favor of adding such a feature, as long as it doesn't take up too much room. If it is never used, there is no great loss. Don't you see a contradiction between these two statements? The original TOS was added to IP at a time when we didn't really understand what we needed for TOS. Result? We've got a header field that doesn't do the right thing, and has probably *impeded* progress in getting that capability out. Noel From owner-Big-Internet@munnari.oz.au Thu Oct 1 15:22:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09725; Thu, 1 Oct 1992 15:22:26 +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 AA09715; Thu, 1 Oct 1992 15:22:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17160; Thu, 1 Oct 92 01:22:07 -0400 Date: Thu, 1 Oct 92 01:22:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210010522.AA17160@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, estrin@usc.edu Subject: Re: SIP Cc: jnc@ginger.lcs.mit.edu (Sorry, no time for complete Unified analysis, but here are a few comments on some of your points..) 2) BGP and its more refined cousin IDRP both are designed to exploit hierarchical aggregation. THat is there number one feature. Any protocol with masks (in the current addressing architecture) meets this test, and that includes a lot more than BGP. By this simplistic measure, RIP-II is a winner. Unfortunately, their capabilities for non-local decision making in handling the difficulties raised by the thinning component of abstraction are non-existent (due to the purely local decision making inherent in the abstraction decision process in Destination Vector), so I wouldn't exactly call them advanced. We want maximal use of aggregation and hierarchy for all the common cases, BUT we want to be able to route around that in those cases where the generic routes dont fit the needs. OTHERWISE, if our only choice is AGGREGATION FOR ALL OR NONE we will end up WITHOUT the aggregation for even the common cases. If I understand what you are saying here, you seem to be referring to two different things? In the last sentence, you seem to be referring to the technique of handling special cases by use of exception routes and longest match lookups (i.e. your routing table includes routes to A and A.X, and all A.n other than A.X use the A entry). The reference to 'generic routes' might refer to the policy capabilities of SDR, or were you simply referring to the ability to split out A.X even if you have an entry for A? As far as exception routes go, any routing table based system with a longest match lookup function has this property. An identical capability can be had from any link state system (even OSPF as it now stands has this capability); even a pure source routed LS system does this easily. I'll skip the long theoretical analysis with abstraction naming boundaries, etc; the example is pretty simple. You have a map in which one node is labelled A, and another A.X, and you just have to do a longest match on map nodes instead of routing table entries. Path Vector routing has very good scaling properties when it comes to aggregation for the common case. Any routing architecture which supports aggregation has good scaling properties when it comes to the common case, in that you get the same percentage reduction in routing information in all designs (for a given topology and addressing/abstraction allocation). What make you think PV (or any DV) is better? Noel From owner-Big-Internet@munnari.oz.au Thu Oct 1 17:26:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14293; Thu, 1 Oct 1992 17:26:45 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14274; Thu, 1 Oct 1992 17:26:34 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 1 Oct 92 00:26:27 -0700 Date: Thu, 1 Oct 92 00:26:27 -0700 From: Tony Li Message-Id: <9210010726.AA26861@lager.cisco.com> To: big-internet@munnari.oz.au Subject: routing architectures [This is a batched response. My apologies if I've messed up attributions.] From: jnc@ginger.lcs.mit.edu (Noel Chiappa) The whole point of IDPR is that it *does not allow* hop-by-hop forwarding (at least at the levels at which it operates). That is one of the points of IDPR. I would not consider it to be a benefit as it disallows HBH forwarding for those who want it. The other points of IDPR are dissemination of larger amounts of topological information than are available with DV protocols and the dissemination of policy information. [Deborah:] We want maximal use of aggregation and hierarchy for all the common cases, BUT we want to be able to route around that in those cases where the generic routes dont fit the needs. OTHERWISE, if our only choice is AGGREGATION FOR ALL OR NONE we will end up WITHOUT the aggregation for even the common cases. [Noel:] If I understand what you are saying here, you seem to be referring to two different things? In the last sentence, you seem to be referring to the technique of handling special cases by use of exception routes and longest match lookups (i.e. your routing table includes routes to A and A.X, and all A.n other than A.X use the A entry). The reference to 'generic routes' might refer to the policy capabilities of SDR, or were you simply referring to the ability to split out A.X even if you have an entry for A? Well, I won't pretend to speak for Deborah, but I will make the point that aggregation of routing information (including policy information!) eliminates some of the fine distinction which may be very relevant in policy routing. Look at the restrictions on super-domains in IDPR. Thus when performs an aggregation function, it may be filtering out relevant information, and it generates what we call a generic route. If the only alternative to retrieving this information is to disable this aggregation, then you are quickly left in the situation where *any* aggregation is impossible, since you are overtaken by entropy. On the other hand, if the routing architecture can also extract information _on_ _demand_ from within this aggregation, then the minutae lost in the aggregation process can be recovered, overhead is minimized to the parties involved, and all is right with the world. As far as exception routes go, any routing table based system with a longest match lookup function has this property. An identical capability can be had from any link state system (even OSPF as it now stands has this capability); even a pure source routed LS system does this easily. I'll skip the long theoretical analysis with abstraction naming boundaries, etc; the example is pretty simple. You have a map in which one node is labelled A, and another A.X, and you just have to do a longest match on map nodes instead of routing table entries. The concept of an exception route goes far beyond longest match. It is simply a source route, calculated by _some_ other means. It may, depending on implementation, depend on the source host, the protocol involved, the TCP ports involved, the phase of the moon, and the color of the Lotus that you last drove. Because it *is* a source route, and avoids the onus of HBH forwarding, the exact nature of the routing algorithm is completely left to the source. Tony p.s. No apologies for the Unified propaganda. ;-) I would ask that anyone who has comments on SDRP (or anyone who has even read it) to please let me know. We await a NoelGram with baited breath. From owner-Big-Internet@munnari.oz.au Thu Oct 1 18:03:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15882; Thu, 1 Oct 1992 18:03:11 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15871; Thu, 1 Oct 1992 18:03:00 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 1 Oct 92 01:02:48 -0700 Date: Thu, 1 Oct 92 01:02:48 -0700 From: Tony Li Message-Id: <9210010802.AA27503@lager.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu, tli@cisco.com, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Wed, 30 Sep 92 10:06:48 -0400 <9209301406.AA08915@ginger.lcs.mit.edu> Subject: SIP On the surface, there is no policy info being sent in BGP, but BGP policies and their effects *do* flood throughout the entire network. You are confusing the statement of the policy (which IDPR distributes, along with the topology), with the topological information which has been filtered by the policy. The significant difference is that BGP, in the common case, will reduce the amount of bandwidth used as policy increases. Further, no other AS must maintain state about the policy of a foreign AS. Even more perniciously, local BGP policy decisions are enforced on distant sites, whether they like it or not. This is a fault of HBH forwarding, NOT the routing protocol. Note that a LS protocol which does HBH has the exact same problem. Please try doing policy routing within OSPF... Also, other DV protocols do have a little better support for policy routing (IGRP has a tiny bit, and the NR part of Unified has some), I would like to hear you argue that IGRP has better policy routing support than BGP. Pretty please? ;-) The only thing that I can think of is the non-functional TOS bits in IGRP. Your point about IDPR policies flooding the system is sort of true; Is this like "sort of pregnant"? Or are we dealing with fuzzy logic here? ;-) If you are a (super)domain in IDPR, I _must_ maintain state about your policies in my IDPR routers. Whether or not I care. Whether or not you are in east Hilbert space. In any case, it's not clear that this represents more actual overhead than the path-vectors in BGP, and it may be less. Please recall that BGP path vectors are NOT there to support policy, but are there to guarantee that BGP is free from static loops. Even if there was NO policy in BGP, you cannot remove the path vectors. I will beat you to the punch and stipulate that this is an unfortunate necessity for purely pragmatic reasons. So it goes, Tony From owner-Big-Internet@munnari.oz.au Thu Oct 1 22:08:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24742; Thu, 1 Oct 1992 22:09:03 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210011209.24742@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24737; Thu, 1 Oct 1992 22:08:56 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3726; Thu, 01 Oct 92 08:08:48 EDT Date: Thu, 1 Oct 92 08:08:47 EDT From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au >In any case, it's not clear that this represents more actual >overhead than the path-vector in BGP, and it may be less. Rather than playing guessing games, I would recommend you to look at the paper I published in ACM CCR April 1992. I hope that would "clear" the issue, and help to steer the discussion away from unsubstantiated speculations towards a more formal and scientific analysis. Yakov Rekhter. From owner-Big-Internet@munnari.oz.au Thu Oct 1 23:23:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28218; Thu, 1 Oct 1992 23:23:31 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210011323.28218@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28213; Thu, 1 Oct 1992 23:23:25 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5176; Thu, 01 Oct 92 09:23:20 EDT Date: Thu, 1 Oct 92 09:23:20 EDT From: yakov@watson.ibm.com To: jnc@ginger.lsc.mit.edu Cc: big-internet@munnari.oz.au >The references to the current suite of IP routing protocols >positively dis-impress me, frankly; the current IP routing architecture (such as it is) is a fouth rate confection of scrap iron and tin foil glued together with massive quantities of bubble gum and string. Noel, While I was really impressed by the emotions you put behind describing the current IP routing architecture, I failed to see any technical substance in your assessment of it. Since the purpose of this mailing list is to discuss *technical* issue (or am I making a wrong assumption ?) it would *really* help if you'll replace "confection", "iron", "bubblegum", etc... with more technically solid arguments. >I can make a rough analogy to a patient who comes in with terminal >pheumonia and a small pre-cancerous lump, and the doctors spend all the >time worrying about how to treat the lump. If you're a good doctor, >looking at this, you have to point out to them that the patient has >other, more serious problems which they need to attend to first. >Well, I'm just pointing out what I think people ought to be keeping >their eye on. The real issue is what is the analogy of "terminal pheumonia" and "a small pre-cancerous lump" in the current Internet. You think that routing architecture and protocols represent "terminal pheumonia", while scaling and changing the size of IP address to something larger than 32 bits represents "a pre-cancerous lump". But this is only *one* possible mapping. Another mapping, which is shared by a large number of people, is that scaling and the size of IP addresses is the "terminal pheumonia", while "a small pre-cancerous lump" is the routing architecture and protocols. I think your concerns, *but not your mapping*, should be taken seriously; as a matter of fact, work on CIDR and IP addressing plans show your concerns, albeit with *different mapping*, are taken quite seriously. >I'd like to hear an argument made that will convince Van Jacobsen (and me :-) >that we need a new packet format now. With no insult intended, I wonder why it is only you and Van who need to be convinced ? And, by the way, I think quite a few people on this list would really like to hear some good and solid *technical* arguments that will convince them that the Internet needs a brand new routing arcthitecture. Yakov. From owner-big-internet@munnari.oz.au Fri Oct 2 00:21:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01633; Fri, 2 Oct 1992 00:21:28 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210011421.1633@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00593; Fri, 2 Oct 1992 00:04:13 +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, 1 Oct 1992 15:03:45 +0100 To: yakov@watson.ibm.com Cc: jnc@ginger.lsc.mit.edu, big-internet@munnari.oz.au In-Reply-To: Your message of "Thu, 01 Oct 92 09:23:20 EDT." <9210011323.28218@munnari.oz.au> Date: Thu, 01 Oct 92 15:03:44 +0100 From: Jon Crowcroft >>The references to the current suite of IP routing protocols >>positively dis-impress me, frankly; the current IP routing architecture ... >list would really like to hear some good and solid *technical* arguments >that will convince them that the Internet needs a brand new routing >arcthitecture. what convinces me is the number of staff employed to keep things working is growing faster than the network - i.e. we have not automated something to do with scaling in a computer system, so as designers, we have failed... jon From owner-Big-Internet@munnari.oz.au Fri Oct 2 00:37:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02227; Fri, 2 Oct 1992 00:38:03 +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 AA02224; Fri, 2 Oct 1992 00:37:55 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18637; Thu, 1 Oct 92 10:34:47 -0400 Message-Id: <9210011434.AA18637@ginger.lcs.mit.edu> To: Noel Chiappa Cc: deering@parc.xerox.com, big-internet@munnari.oz.au Subject: Re: SIP In-Reply-To: Your message of Wed, 30 Sep 92 09:46:11 -0400. <9209301346.AA08859@ginger.lcs.mit.edu> From: David Clark Date: Thu, 01 Oct 92 10:34:46 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp No. You cannot poll them because they lie. From owner-Big-Internet@munnari.oz.au Fri Oct 2 00:55:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02966; Fri, 2 Oct 1992 00:55:40 +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 AA02960; Fri, 2 Oct 1992 00:55:33 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AB16311; Thu, 1 Oct 92 08:55:25 -0600 Received: by goshawk.lanl.gov (4.1/5.17) id AA08073; Thu, 1 Oct 92 08:55:23 MDT Date: Thu, 1 Oct 92 08:55:23 MDT From: peter@goshawk.LANL.GOV (Peter S. Ford) Message-Id: <9210011455.AA08073@goshawk.lanl.gov> To: jnc@ginger.lsc.mit.edu, yakov@watson.ibm.com Subject: New routing architecture Cc: big-internet@munnari.oz.au Noel, The Internet operators are implementing the routing architecture which is a product of the IETF. The operators who have switched over to using BGP to implement that architecture seem to feel it is a significant step in the right direction. Today they are tool limited by insufficient effort in getting working BGPs out into the field. We could get into a big digression as to why this happened ... It appears that there is a need for additional capabilities in the routing architecture, but at this time I think it is fair to say that it is not crystal clear what features are needed. I hear a lot of "we need policy", but not very many answers in terms of what policies, at what granularity, etc. It is quite clear that the vendors have heard a lot of requests for some kind of enhancements and currently they implement this in terms of filtering. The customers keep buying, and if you talk to the vendors they are not hearing that they need to worry about a new routing architecture. In fact, we finally have the attention of the router vendors in terms of implementing BGP, which I view a a big step forward. Some view this as not a significant enough step forward, but to those who operate networks it appears to make a *real* difference. I encourage anyone to work on a new routing architecture. But, for it to be deployed you will have to convince the vendors to implement the tools and the operators to turn the features on. As people develop new architectures I hope they work constructively with the two communities to insure that the new architecture solves their problems. Many of these routing architecture discussions remind me of the dabates between the Algol 68 and Pascal communities. Makes me wonder where the CPL of routing architectures resides. Yours in darwinian evolution and a new packet format, peter From owner-Big-Internet@munnari.oz.au Fri Oct 2 00:59:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03151; Fri, 2 Oct 1992 00:59: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 AA03148; Fri, 2 Oct 1992 00:59:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18885; Thu, 1 Oct 92 10:59:01 -0400 Date: Thu, 1 Oct 92 10:59:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210011459.AA18885@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, tli@cisco.com Subject: Re: routing architectures Cc: jnc@ginger.lcs.mit.edu That is one of the points of IDPR. I would not consider it to be a benefit as it disallows HBH forwarding for those who want it. I wasn't making a statement about whether it was good or not, just pointing out what it did. I will make the point that aggregation of routing information (including policy nformation!) eliminates some of the fine distinction which may be very relevant in policy routing. Exactly. There's no automatic mechanism that will help this, but rather human input (to decide which information you can suffer the cost of losing, and which you can't, although in the long run a very complex algorithm with a database of actual traffic might be able to semi-automate the process) and careful topology design are what's needed. On the other hand, if the routing architecture can also extract information _on_ _demand_ from within this aggregation, then the minutae lost in the aggregation process can be recovered, overhead is minimized to the parties involved, and all is right with the world. This is exactly the point of the local abstraction control mechanism in Nimrod, which Deborah will no doubt remember me inventing some years back under the name "blister model". I take it you are referring to the similar capability in SDR? The concept of an exception route goes far beyond longest match. I was speaking of exception routing with the routing table model (i.e. not source routed). We await a NoelGram with baited breath. God, one person who *likes* (well, maybe that's too strong :-) the damn things. You, sir, get a gold star! Noel From owner-Big-Internet@munnari.oz.au Fri Oct 2 01:25:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04146; Fri, 2 Oct 1992 01:25:59 +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 AA04143; Fri, 2 Oct 1992 01:25:52 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19077; Thu, 1 Oct 92 11:25:48 -0400 Date: Thu, 1 Oct 92 11:25:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210011525.AA19077@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Re: SIP Cc: jnc@ginger.lcs.mit.edu You are confusing the statement of the policy (which IDPR distributes, along with the topology), with the topological information which has been filtered by the policy. This is only a surface distinction, which I am aware of and ignored since it's a mechanism question. (I was responding to a sweeping statement on your part that might have confused the less cognizant on the list.) Policy influences on routes are the net effect here, and whether they happen by distributing policy info widely and calculating locally (as in IDPR), or by distributed affect of policy on route calculation (as in IDRP) is of only engineering importance. The significant difference is that BGP, in the common case, will reduce the amount of bandwidth used as policy increases. Yes, but it does so at the cost of severly limited policy capabilities. Further, no other AS must maintain state about the policy of a foreign AS. Explicitly, no, but implicitly, in the AS chains, yes. (See the top point! :-) This is a fault of HBH forwarding, NOT the routing protocol. Note that a LS protocol which does HBH has the exact same problem. Please try doing policy routing within OSPF... Yes, but how do you do non-HBH routing in a Destination Vector system? What's the point of computing those routing tables if you aren't going to use them? I would like to hear you argue that IGRP has better policy routing support than BGP. Pretty please? ;-) The only thing that I can think of is the non-functional TOS bits in IGRP. I think of TOS (and I speak here of real TOS, not the lobotomized stuff in the IP header) as a subset of policy routing; there's not really much difference between saying "I want my traffic to go on links with >1Mbit/sec" and saying "I want my traffic to go on links paid for by X". So the minimal TOS support in IGRP is sort of minimal policy routing; I know, I know, it's not really very strong TOS support even. (I must say I am mildly amused by hearing someone from Cisco dump on IGRP! :-) Is this like "sort of pregnant"? Or are we dealing with fuzzy logic here? ;-) Touche! If you are a (super)domain in IDPR, I _must_ maintain state about your policies in my IDPR routers. Whether or not I care. Whether or not you are in east Hilbert space. I haven't read the IDPR specs recently, I recall some talk of people being able to retain incomplete maps, but I haven't checked to see if that's still true. In any case, the lack of scaling support in IDPR is what caused me to become less interested in the details of it. Please recall that BGP path vectors are NOT there to support policy, but are there to guarantee that BGP is free from static loops. Even if there was NO policy in BGP, you cannot remove the path vectors. I will beat you to the punch and stipulate that this is an unfortunate necessity for purely pragmatic reasons. Yes, but the fact that you can use PV's to do some limited policy routing is undoubtly a factor in chosing them, yes? I mean, wouldn't some of the SRI algorithms, etc, be a better way to do a DV (and by DV I *always* mean Destination Vector, which includes both Distance and Path Vector subtypes) architecture if you wanted DV, and didn't need the policy stuff? Noel From owner-Big-Internet@munnari.oz.au Fri Oct 2 01:50:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05177; Fri, 2 Oct 1992 01:51:07 +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 AA05169; Fri, 2 Oct 1992 01:50:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19282; Thu, 1 Oct 92 11:50:51 -0400 Date: Thu, 1 Oct 92 11:50:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210011550.AA19282@ginger.lcs.mit.edu> To: jnc@ginger.lsc.mit.edu, yakov@watson.ibm.com Subject: Routing architectures Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu You think that routing architecture and protocols represent "terminal pheumonia", while scaling and changing the size of IP address to something larger than 32 bits represents "a pre-cancerous lump". This is absolutely not what I think. Clearly, address size (mechanism) and scaling (problem to be solved) are all part of the same thing as routing architecture (overall design approach) and protocols (mechanism). The thing I was referring to as the minor issue (to my eyes) is the issue of a new packet format, which *IS NOT NECESSARILY* related to a bigger address. Parenthetically, shouldn't you understand my points better before you attack them as unsound? Another mapping, which is shared by a large number of people, is that scaling and the size of IP addresses is the "terminal pheumonia", while "a small pre-cancerous lump" is the routing architecture and protocols. I see. So we can separate address design and routing design, right? I didn't realize *that* battle was still going on... With no insult intended, I wonder why it is only you and Van who need to be convinced? None taken. I mention Van to give him credit as the person who first raised the point. I certainly didn't think that way until I talked to Van. I mention myself since nobody else on the list seems to be arguing that we don't need a new packet format right now. If anyone else out there does agree, feel free to speak up, and I'm sorry if I slighted anyone. And, by the way, I think quite a few people on this list would really like to hear some good and solid *technical* arguments that will convince them that the Internet needs a brand new routing arcthitecture. If this wasn't such a depressing statement I would find it hilariously funny. For one, your own Unified protocol set *embodies* a new routing architecture! It's different from the Nimrod architecture (which I cheerfully admit is not yet embodied fully in protocols), of course, but there's still a (new) routing architecture inside. Are you perhaps saying we don't need Unified? I'll leave the question of whether we need a new one until we sort this point out, let this turn into a major Noelgram. Noel From owner-Big-Internet@munnari.oz.au Fri Oct 2 02:16:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06084; Fri, 2 Oct 1992 02:16:24 +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 AA06081; Fri, 2 Oct 1992 02:16:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19404; Thu, 1 Oct 92 12:16:14 -0400 Date: Thu, 1 Oct 92 12:16:14 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210011616.AA19404@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, peter@goshawk.lanl.gov Subject: Re: New routing architecture Cc: jnc@ginger.lcs.mit.edu The Internet operators are implementing the routing architecture which is a product of the IETF. I would think the term "waste byproduct" would be more appropriate, actually. What we have is a series of pieces (EGP, BGP, IDRP, RIP, IS-IS, OSPF, etc) which were only loosly designed to work with each other, and which require complex 'boxes' to interconnect, the design of which is only now starting to be formalized (e.g. the BGP-OSPF interactions document). In general, each router vendor has radically different mechanisms available to interconnect these various protocols. These all fit within a basic framework (the EGP/IGP split) which, well, I'd better stop there. There is no unified view of the current Internet routing architecture, and no document which expresses that view. The operators who have switched over to using BGP to implement that architecture seem to feel it is a significant step in the right direction. I've said before that I though BGP was a substantial improvement, particularly BGP-4, and I hope it gets widely imlemented and deployed ASAP. Today they are too limited by insufficient effort in getting working BGPs out into the field. True, but this is a problem with the vendors, over whom the IETF has little influence. They respond to $$$, specifically equipment sales. It appears that there is a need for additional capabilities in the routing architecture, but at this time I think it is fair to say that it is not crystal clear what features are needed. I would disagree. The Open Routing WG examing the issue of policy routing fairly closely, and by looking (informally, albeit) at a large numebr of sample requests from users, we came up with a classification of routing policy into 3 classes (source policies, transit policies, and information hiding) which still seems to hold pretty well. Since the intervening years have provided no surprises, I would think that a system that can support these 3 classes (in an extensible way) would be adequate. I hear a lot of "we need policy", but not very many answers in terms of what policies, at what granularity, etc. Oh yes, the specifics are not clear, but they will probably continue to change over time. There's no way we can do a set *anytime* which will be good forever. That's why we need an extensible policy system, which both major routing architeture contenders (Unified and Nimrod/IDPR) provide. The customers keep buying, and if you talk to the vendors they are not hearing that they need to worry about a new routing architecture. The vendors?!?! Don't make me laugh. Their vision is too limited. Some view this as not a significant enough step forward, but to those who operate networks it appears to make a *real* difference. I hope you aren't including me here. I've been pushing (if not enthusiastic) about BGP for a *long* time, inside the IAB and IESG, for precisely this reason. Made a real pest of myself with the IAB (I think you all know how good I am at that :-) when they wanted to bounce the documents back because they weren't well enough done. I'm currently looking out a little further, though. But, for it to be deployed you will have to convince the vendors to implement the tools and the operators to turn the features on. That's a little simplistic. You have to get it designed, tested, standardized, and then get the operators to ask (berate, actually)x the vendors for it. Most vendors don't seem to have enough foresight to do anything else, as I'm sure your BGP experiences have shown! Noel From owner-Big-Internet@munnari.oz.au Fri Oct 2 02:32:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06747; Fri, 2 Oct 1992 02:32:24 +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 AA06738; Fri, 2 Oct 1992 02:32:08 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA23628; Thu, 1 Oct 92 09:31:58 -0700 Received: by us1rmc.bb.dec.com; id AA15742; Thu, 1 Oct 92 12:29:23 -0400 Message-Id: <9210011629.AA15742@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Thu, 1 Oct 92 12:29:24 EDT Date: Thu, 1 Oct 92 12:29:24 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 01-Oct-1992 1231" To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: RE: TOS ( was Re: packet format v. routing architecture ) Noel, I'd like to see why the TOS field is a wrong thing, if that is what you are saying. Sure, it does not provide for reservations of network resources, etc., which lots of people would want, but it provides a way to specify very useful and reasonable facilities. If I'm going to do a bulk file transfer, I don't care much about latency but I want what bandwidth I can be given and I should be able to ask the network for that. I'll probably get less bandwidth than I want but I almost certainly will want to go ahead with the transfer anyway. Same for low latency for interactive use, etc. I like the current TOS field. It's lack of implementation just seems to be a symptom of the relative crudeness of the current routing stuff and the lack of multiple paths with different characteristics in the Internet (ie, satellite versus land line). For further capabilities, you need additional set up and the like. Perhaps with these additional capabilities you could also ask for what you can as for with the current TOS but the extra overhead in set up traffice and in state along the way would frequently not be worth it. Donald -------------- From: US1RMC::"jnc@ginger.lcs.mit.edu" "Noel Chiappa" 1-OCT-1992 01:41 Subj: Re: packet format v. routing architecture .. We have managed to get along without it in IP4 for some years now (TOS having been widely ignored). I am personally in favor of adding such a feature, as long as it doesn't take up too much room. If it is never used, there is no great loss. Don't you see a contradiction between these two statements? The original TOS was added to IP at a time when we didn't really understand what we needed for TOS. Result? We've got a header field that doesn't do the right thing, and has probably *impeded* progress in getting that capability out. Noel From owner-Big-Internet@munnari.oz.au Fri Oct 2 02:38:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07033; Fri, 2 Oct 1992 02:38:42 +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 AA07017; Fri, 2 Oct 1992 02:38:26 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA23885; Thu, 1 Oct 92 09:38:19 -0700 Received: by us1rmc.bb.dec.com; id AA16082; Thu, 1 Oct 92 12:35:43 -0400 Message-Id: <9210011635.AA16082@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Thu, 1 Oct 92 12:35:44 EDT Date: Thu, 1 Oct 92 12:35:44 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 01-Oct-1992 1237" To: peter@goshawk.lanl.gov Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, peter@goshawk.lanl.gov Subject: RE: New routing architecture I'm not convinced "we need policy". The Internet needs resource reservation / flow type things for some services and it very much needs ubiquitous security in terms of strong authentication and encryption. If you had both of those, the remaining "need" for policy routing seems pretty minimal to me. Donald -------------- From: US1RMC::"peter@goshawk.LANL.GOV" "Peter S. Ford" 1-OCT-1992 11:44 To: jnc@ginger.lsc.mit.edu, yakov@watson.ibm.com CC: big-internet@munnari.oz.au Subj: New routing architecture Noel, ... It appears that there is a need for additional capabilities in the routing architecture, but at this time I think it is fair to say that it is not crystal clear what features are needed. I hear a lot of "we need policy", but not very many answers in ^^^^^^^^^^^^^^ terms of what policies, at what granularity, etc. It is quite clear that the vendors have heard a lot of requests for some kind of enhancements and currently they implement this in terms of filtering. The customers keep buying, and if you talk to the vendors they are not hearing that they need to worry about a new routing architecture. ... ... peter From owner-Big-Internet@munnari.oz.au Fri Oct 2 02:55:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07890; Fri, 2 Oct 1992 02:57:03 +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 AA07829; Fri, 2 Oct 1992 02:55:50 +1000 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA02363 (5.65b/CWI-2.177); Thu, 1 Oct 1992 17:55:32 +0100 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA09781; Thu, 1 Oct 92 17:56:00 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA12166; Thu, 1 Oct 92 17:55:26 +0100 Message-Id: <9210011655.AA12166@dxcern.cern.ch> Subject: Re: growth To: big-internet@munnari.oz.au Date: Thu, 1 Oct 92 17:55:24 MET From: Brian Carpenter CERN-CN In-Reply-To: <9210011421.1633@munnari.oz.au>; from "Jon Crowcroft" at Oct 1, 92 3:03 pm X-Mailer: ELM [version 2.3 PL11 CERN 11] >--------- Text sent by Jon Crowcroft follows: > ... > >list would really like to hear some good and solid *technical* arguments > >that will convince them that the Internet needs a brand new routing > >arcthitecture. > > what convinces me is the number of staff employed to keep things > working is growing faster than the network I thought this was due to the increasing overhead caused by European Commission contract formalities :-) Seriously, jon, is this true? Since CERN has a permanent hiring freeze we have certainly not increased staff even as fast as log(connectivity), and increased bandwidth has essentially zero staff cost. Can you actually quote numbers to back up your conviction? Brian From owner-Big-Internet@munnari.oz.au Fri Oct 2 02:59:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07975; Fri, 2 Oct 1992 02:59:40 +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 AA07963; Fri, 2 Oct 1992 02:59:07 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA02912; Thu, 1 Oct 92 12:58:46 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA19432; Thu, 1 Oct 92 09:57:39 PDT Message-Id: <9210011657.AA19432@aland.bbn.com> To: Noel Chiappa Cc: yakov@watson.ibm.com Subject: Routing architectures Cc: big-internet@munnari.oz.au From: Craig Partridge Date: Thu, 01 Oct 92 09:57:39 -0700 Sender: craig@aland.bbn.com > None taken. I mention Van to give him credit as the person who first raised > the point. I certainly didn't think that way until I talked to Van. I > mention myself since nobody else on the list seems to be arguing that we > don't need a new packet format right now. If anyone else out there does > agree, feel free to speak up, and I'm sorry if I slighted anyone. Well, Noel, I can agree that I think the rush to a new packet format is a bit premature. My argument runs as follows (and apologies to those who've heard it before): * we know IP has to change, but it has to change for several reasons: better scaling (addresses and routing) and better TOS to name two. * we don't seem to have perfect answers to these problems, and while I think SIP's doing a good job of defining a new packet format, given what we know, the heavy SIP discussion is rapidly revealing how much we don't know. [As an aside, I'd like to thank Steve Deering. By introducing a protocol that only has a feature if you can prove to Steve the feature is needed, he's really pushed us to think about what is required]. * we need an architecture good for at least 20 years. * we don't know how long CIDR and other conservation effects will buy us The net result is that we're pushing to decide *this fall*, because *we are scared* we don't know how long CIDR will help, and we're trying to decide issues which *we clearly don't understand* well, and we expect these decisions to work for the next 20 years???? If you went to your manager with such a project plan, what would she say? Probably the first thing she'd say is give me a better estimate on CIDR. I'm afraid these aren't full technical arguments but rather managerial arguments. (Some technical arguments below for those who need them). Craig PS: OK, so you believe there are good technical arguments for deciding now. Good! So let us know the correct answer to the following questions (formal proofs encouraged): * How big should the TOS/flow field be? How should it be encoded? * How big should the address space be? * how should this address space be structured? Prove it scales to a few billion mobile end-systems and supports multicasting, while keeping routing tables manageably small. From owner-Big-Internet@munnari.oz.au Fri Oct 2 04:03:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09536; Fri, 2 Oct 1992 04:03:25 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210011803.9536@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09533; Fri, 2 Oct 1992 04:03:12 +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, 1 Oct 1992 19:02:55 +0100 To: Brian Carpenter CERN-CN Cc: big-internet@munnari.oz.au Subject: Re: growth In-Reply-To: Your message of "Thu, 01 Oct 92 17:55:24 +0700." <9210011655.AA12166@dxcern.cern.ch> Date: Thu, 01 Oct 92 19:02:51 +0100 From: Jon Crowcroft >Seriously, jon, is this true? Since CERN has a permanent hiring >freeze we have certainly not increased staff even as fast as >log(connectivity), and increased bandwidth has essentially zero >staff cost. Can you actually quote numbers to back up your >conviction? yes - look at the amount of email on this list and not just from jnc:-) jon From owner-Big-Internet@munnari.oz.au Fri Oct 2 04:54:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11039; Fri, 2 Oct 1992 04:54:34 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210011854.11039@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11031; Fri, 2 Oct 1992 04:54:21 +1000 (from kwe2@BBN.COM) From: "Kent W. England" Subject: You ask "Why a New Routing Architecture?" To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au, jnc@ginger.lsc.mit.edu In-Reply-To: <9210011323.28218@munnari.oz.au> Date: Thu, 1 Oct 92 14:45:41 EDT Mail-System-Version: > ... And, by the way, I think quite a few people on this >list would really like to hear some good and solid *technical* arguments >that will convince them that the Internet needs a brand new routing >arcthitecture. > >Yakov. Consider the NSFnet, the CIX, a mid-level network, and the difficulties involved in configuring routing to accomodate "commercial" and "R&E" traffic. I find that a sufficient proof that we need a new routing architecture. --Kent From owner-Big-Internet@munnari.oz.au Fri Oct 2 05:07:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11362; Fri, 2 Oct 1992 05:08:07 +1000 (from owner-Big-Internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11357; Fri, 2 Oct 1992 05:07:57 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA14124 (5.65c/UK-2.1-921001); Thu, 1 Oct 1992 15:12:52 -0400 From: Gary Scott Malkin Date: Thu, 1 Oct 1992 15:12:52 -0400 Message-Id: <14124.199210011912@atlas.xylogics.com> To: big-internet@munnari.oz.au Subject: routing architecture Perhaps I'm over simplifying the problem, but it seems to me that the object is to be able to handle routing for billions of hosts, which is what we expect to have in the next 20 years. The mechanism should be simple and should not use too large an address. And it should not impose too large a burden on hosts or routers. Suppose we start with what we can do, then take the divide and conquer approach. We know that we can route on internets with 2^12 networks. We know that because the Internet is already bigger than that. We know that we'd like to be able to route 2^30 networks (at least). So it seems to me, that if we have a three level hierarchy, with 2^12 addresses at each level, we can handle 2^36 hosts (which exceeds our original requirement). As Noel has said many times, the address falls out of the routing architecture as a natural by-product. The address would be A.B.C, where each is a 12 bit number. Now, to make life simpler for the hardware, we expand each of those to 16 bit numbers, and reserve the high 4 bits of each part for exceptional stuff. Exceptional stuff includes multicasting, mobile hosts, etc. So here we are with a 48 bit address, routers which need never handle more than 4096 routes, and existing routing protocols which will work quite well. It also means that the only changes we need to make to TCP/IP Protocol Suite involve handling a slightly larger address and going "classless". It seems too easy. Have I missed something? ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-big-internet@munnari.oz.au Fri Oct 2 05:23:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11770; Fri, 2 Oct 1992 05:23:59 +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 AA09954; Fri, 2 Oct 1992 04:18:15 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA04622; Thu, 1 Oct 92 11:17:44 -0700 Date: Thu, 1 Oct 92 12:51:39 EDT From: "William Allen Simpson" Message-Id: <784.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Cc: jnc@ginger.lcs.mit.edu, estrin@usc.edu Reply-To: bsimpson@angband.stanford.edu Subject: Re: SIP Sticking to SIP, without all of the bickering, we were trying to determine what new fields are useful for the various proposed routing architectures. Deborah: - What fields do you need for IDRP/SDRP? - Is the TOS cum Flow field appropriate (yes/no)? - What about bit fields (the "probe" bit in SDRP)? Noel: - What fields do you need for Nimrod/IDPR? - Is the TOS cum Flow field appropriate (yes/no)? Bill.Simpson@um.cc.umich.edu From owner-big-internet@munnari.oz.au Fri Oct 2 05:33:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11981; Fri, 2 Oct 1992 05:34:02 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210011934.11981@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09426; Fri, 2 Oct 1992 03:59:05 +1000 (from lyman@BBN.COM) From: "Lyman Chapin" Subject: Re: size and alignment of Hop Limit field in SIP To: kre@munnari.oz.au Cc: big-internet@munnari.oz.au, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu In-Reply-To: <7588.717725062@munnari.oz.au> Date: Thu, 1 Oct 92 12:13:52 EDT Mail-System-Version: Steve, The question is not whether you or I or Robert can come up with a plausible scenario for a path approaching 255 traditional "hops", but whether we are comfortable with a design that has a hard limit of 255 for the value of the TTL field. Experience tells me that whenever someone insists that "clearly could *never* get any bigger than X", and wires a hard limit of X into something as fundamental to the Internet as [S]IP, we eventually regret it - either because eventually does get bigger than X, or because people come up with a novel new way in which to exploit (which is one of the reservations that Robert refers to in his message). If we end up adopting SIP for the Internet, it will be in use ten years from now; thinking back to what you "knew for sure" about the Internet ten years ago, are you really certain that ten years from now there is no conceivable way in which a TTL field could hold a value greater than 255? - Lyman >To: Steve Deering >Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au >Subject: Re: size and alignment of Hop Limit field in SIP >Date: Tue, 29 Sep 92 10:04:22 +1000 >From: Robert Elz > > Date: Sun, 27 Sep 1992 18:33:55 PDT > From: Steve Deering > Message-ID: <92Sep27.183407pdt.10779@skylark.parc.xerox.com> > > I wish you would try to present a non-emotional argument as > to why a solar-system-wide Internet ought to have or must > have a diameter greater than 255 hops. > >I'm not sure that there is one - if you consider diameter in >the intuitive way, then 255 is a lot, even with just 1ms >transit, processing, and queueing time, which is pretty fast, >a path that had to approach 255 hops would have a pretty >long rtt. However, I agree with Frank that its hard to >anticipate what the future might bring - remember that even >though IP has an 8 byte TTL field, 4.2 BSD used just half >of it (4 bits) by making the default TTL be 15 when packets >were originated. When it was coded 15 was plenty... From owner-big-internet@munnari.oz.au Fri Oct 2 05:47:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12396; Fri, 2 Oct 1992 05:47:58 +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 AA09949; Fri, 2 Oct 1992 04:17:55 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA04619; Thu, 1 Oct 92 11:17:28 -0700 Date: Thu, 1 Oct 92 12:00:43 EDT From: "William Allen Simpson" Message-Id: <783.bill.simpson@um.cc.umich.edu> To: Tony Li Cc: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: routing architectures (from Tony) > anyone who has comments on SDRP (or anyone who has even read it) to > please let me know. > I read a short version (no packet encapsulation format) in July. Perhaps there's a later version. Quite frankly, I wasn't that pleased with SDRP itself. As far as I could see, SDRP relies primarily on local human configuration. I would prefer a more global approach, modified locally only when necessary. I think that the thrust of "Unified" is heading in the right direction, when it says that the two architectural proposals aren't that far apart. There seems to be a similarity of goals, and differences in the details. I think that we'll probably need to allow hop-by-hop *and* source-routing to co-exist forever. But I would prefer that the hop-by-hop be *only* policy-less and anything else be pre-calculated. The provider/exterior/interior split doesn't do it for me. I really *hate* the single level of administrative domains. I would prefer a dynamic multi-level structure. My biases stem from practical experience here in Michigan. When BGP first went in, throughput to the Internet was terrible, because of Merit's advertisement that the entire state was behind Ann Arbor. Everyone here had net 35 addresses and the BGP routers weren't classless and didn't do longest match. Two years ago, most of the universities switched to their own net addresses (a dozen class B's), but nearly everything still goes through Ann Arbor anyway. (It did help internally to Merit as a provider.) Worse, the largest (Michigan State) refused to change from sub-net 35.8, since they had so many machines. And they are connected to 4 or 5 providers. As far as I can tell, BGP/IDRP/SDRP won't fix that mess, and Nimrod/IDPR claims that it will. Of course, it may be a "grass is greener on the other side of the fence" phenomenon. But I felt more of a "click" when I read the latter. (From Noel) > PS: Just out of interest, it would be useful to know what percentage of the > people on this list have read the IDPR specs, or even the IDPR architecture > document... if there some way to poll a subset of the list to get a > representative sample? > I have, but only once (late July). The design seems well thought out, but suffers from too much domain-ness, just like BGP. The Nimrod I read about 7 times over a year. Not light reading. ;-) Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Fri Oct 2 06:08:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13001; Fri, 2 Oct 1992 06:08:33 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210012008.13001@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12988; Fri, 2 Oct 1992 06:08:25 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 9296; Thu, 01 Oct 92 16:08:20 EDT Date: Thu, 1 Oct 92 16:08:19 EDT From: yakov@watson.ibm.com To: kwe2@BBN.COM Cc: big-internet@munnari.oz.au, jnc@ginger.lsc.mit.edu Subject: You ask "Why a New Routing Architecture?" Ref: Your note of Thu, 1 Oct 92 14:45:41 EDT >Consider the NSFNet, the CIX, a mid-level network, and the difficulties >involved in configuring routing to accommodate "commercial" and >"R&E" traffic. I find that a sufficient proof that we need a new >routing architecture. I find that a sufficient proof that we need to define a particular TOS, meaning "R&E" and do TOS sensitive routing, which, by the way *does not require* a new routing architecture. You don't need a tactical nuke to shoot a mosquito. Meantime, while waiting to reach a rough consensus on what exact TOS value should be used for "R&E", people may use something like SDRP (published as an ID) to do it without any TOS. Again, *no new routing architecture required*. Yakov. From owner-Big-Internet@munnari.oz.au Fri Oct 2 06:10:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13063; Fri, 2 Oct 1992 06:11:05 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210012011.13063@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13056; Fri, 2 Oct 1992 06:10:57 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 9456; Thu, 01 Oct 92 16:10:51 EDT Date: Thu, 1 Oct 92 16:10:51 EDT From: yakov@watson.ibm.com To: oran@sneezy.lkg.dec.com, J.Crowcroft@cs.ucl.ac.uk Cc: jnc@ginger.lsc.mit.edu, big-internet@munnari.oz.au Subject: Growth Ref: Your note of Thu, 1 Oct 92 15:16:39 -0400 >what convinces me is the number of staff employed >to keep things working is growing faster than the network... May be we should ask folks at MERIT about this assertion. After all, they've been running the NSFNET Backbone for the past 5 years. Yakov From owner-big-internet@munnari.oz.au Fri Oct 2 06:21:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13333; Fri, 2 Oct 1992 06:21:09 +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 AA11575; Fri, 2 Oct 1992 05:17:16 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA21763; Thu, 1 Oct 92 12:16:42 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA03131; Thu, 1 Oct 1992 15:16:40 -0400 To: Jon Crowcroft Subject: Growth In-Reply-To: <9210011421.1633@munnari.oz.au> References: <9210011421.1633@munnari.oz.au> Cc: yakov@watson.ibm.com, jnc@ginger.lsc.mit.edu, big-internet@munnari.oz.au X-Mailer: Poste 2.0 From: David R. Oran Date: Thu, 1 Oct 92 15:16:39 -0400 Message-Id: <921001151639.12546@sneezy.lkg.dec.com> Encoding: 20 TEXT, 6 TEXT SIGNATURE > > > >>The references to the current suite of IP routing protocols > >>positively dis-impress me, frankly; the current IP routing architecture > ... > >list would really like to hear some good and solid *technical* arguments > >that will convince them that the Internet needs a brand new routing > >arcthitecture. > > what convinces me is the number of staff employed to keep things > working is growing faster than the network - i.e. we have not > automated something to do with scaling in a computer system, so as > designers, we have failed... > > jon > While I am emotionally inclined to agree with you that scaling of people is more important than scaling of memory or bandwidth, where is the data to support the assertion that the number of staff needed is growing faster than the network? -+-+-+-+-+-+-+ 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 Oct 2 06:27:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13466; Fri, 2 Oct 1992 06:27:24 +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 AA13461; Fri, 2 Oct 1992 06:27:14 +1000 (from estrin@jerico.usc.edu) Received: from excalibur.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.1) id AA01345; Thu, 1 Oct 92 12:17:11 PDT Received: by excalibur.usc.edu (4.1/SMI-3.0DEV3) id AA06792; Thu, 1 Oct 92 12:21:54 PDT Date: Thu, 1 Oct 92 12:21:54 PDT Message-Id: <9210011921.AA06792@excalibur.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@jerico.usc.edu To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: "William Allen Simpson"'s message of Thu, 1 Oct 92 12:51:39 EDT <784.bill.simpson@um.cc.umich.edu> Subject: Re: SIP Reply-To: estrin@usc.edu From: "William Allen Simpson" Sticking to SIP, without all of the bickering, we were trying to determine what new fields are useful for the various proposed routing architectures. Deborah: - What fields do you need for IDRP/SDRP? - Is the TOS cum Flow field appropriate (yes/no)? - What about bit fields (the "probe" bit in SDRP)? From my point of view everything in SIP is compatible with IDRP/SDRP. But this is true for most of the packet format proposals on the table. But maybe I am not understanding your question... D. From owner-Big-Internet@munnari.oz.au Fri Oct 2 06:39:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13796; Fri, 2 Oct 1992 06:39:57 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210012039.13796@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13793; Fri, 2 Oct 1992 06:39:46 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0476; Thu, 01 Oct 92 16:39:37 EDT Date: Thu, 1 Oct 92 16:39:37 EDT From: yakov@watson.ibm.com To: bsimpson@angband.stanford.edu, tli@cisco.com Cc: big-internet@munnari.oz.au Subject: routing architectures Ref: Your note of Thu, 1 Oct 92 12:00:43 EDT >As far as I can tell, BGP/IDRP/SDRP won't fix that mess, >and Nimrod/IDPR claims that it will. It would be quite useful to see the exact details that would substantiate the Nimrod/IDPR claim. In a similar spirit, what makes you feel that BGP/IDRP/SDRP won't fix that mess ? Yakov Rekhter. From owner-Big-Internet@munnari.oz.au Fri Oct 2 08:17:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16568; Fri, 2 Oct 1992 08:17:36 +1000 (from owner-Big-Internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16557; Fri, 2 Oct 1992 08:17:26 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA22809 (5.65c/UK-2.1-921001); Thu, 1 Oct 1992 18:22:16 -0400 From: Gary Scott Malkin Date: Thu, 1 Oct 1992 18:22:16 -0400 Message-Id: <22809.199210012222@atlas.xylogics.com> To: solensky@andr.ub.com Cc: big-internet@munnari.oz.au In-Reply-To: Frank T. Solensky's message of Thu, 1 Oct 92 18:03:59 EDT <9210012203.AA19831@fenway.andr.UB.com> Subject: routing architecture > No offense, Gar, but, uh, yeah. :-) > It still can't do things like resource allocation, policy, stuff like that.. None taken. But it wasn't my intention that the entire header should be nothing more than a source and destination address. I figured you'd need to include other bits to do other things :-) I was primarily targeting the scaling issue. ------------------------------------------------- -------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-big-internet@munnari.oz.au Fri Oct 2 08:18:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16581; Fri, 2 Oct 1992 08:18:19 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210012218.16581@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15931; Fri, 2 Oct 1992 08:00:50 +1000 (from kwe2@BBN.COM) From: "Kent W. England" Subject: Re: You ask "Why a New Routing Architecture?" To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au Date: Thu, 1 Oct 92 17:58:58 EDT Mail-System-Version: >>Consider the NSFNet, the CIX, a mid-level network, and the difficulties >>involved in configuring routing to accommodate "commercial" and >>"R&E" traffic. I find that a sufficient proof that we need a new >>routing architecture. > >I find that a sufficient proof that we need to define a particular >TOS, meaning "R&E" and do TOS sensitive routing, which, by the >way *does not require* a new routing architecture. You don't >need a tactical nuke to shoot a mosquito. > If by "TOS" you mean within our current IP definition, how do you deal with the routing table explosion/scaling problem of TOS routing? Are you counting on CIDR to counteract the TOS multiplier effect? --Kent From owner-big-internet@munnari.oz.au Fri Oct 2 08:35:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17270; Fri, 2 Oct 1992 08:35:27 +1000 (from owner-big-internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16079; Fri, 2 Oct 1992 08:05:50 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA04474; Thu, 1 Oct 92 15:05:36 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA01667; Thu, 1 Oct 92 18:05:34 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA19831; Thu, 1 Oct 92 18:03:59 EDT Date: Thu, 1 Oct 92 18:03:59 EDT From: Frank T. Solensky Message-Id: <9210012203.AA19831@fenway.andr.UB.com> To: gmalkin@xylogics.com Subject: Re: routing architecture Cc: big-internet@munnari.oz.au >Perhaps I'm over simplifying the problem, but ... >..[s]uppose we start with what we can do, then take the divide and conquer >approach. > >It seems too easy. Have I missed something? No offense, Gar, but, uh, yeah. :-) It still can't do things like resource allocation, policy, stuff like that.. Ya see, one weakness of the "start where we are" approach is that it places us well along a path that we've already traveled, and causes us to bring along some of the baggage that we just never thought about not bringing along. An example: network number assignments that indicate roughly what time-series order the numbers were requested in. It also causes us to leave behind the things we think would be nice to have but didn't forsee having in the mid '70s, like bandwidth allocation (Noel's missing 'cute analogy'). I dunno. If we're going to be living with this for any appreciable amount of time, I'd rather spend the extra couple of hours making sure we all get the concept of what an "address" is straight before we decide what it's size or memory alignment is. (* shrug *) -- Frank Now 'the extra couple of _years_' would be another thing.. From owner-big-internet@munnari.oz.au Fri Oct 2 10:16:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21633; Fri, 2 Oct 1992 10:16:41 +1000 (from owner-big-internet) Return-Path: Received: from asylum.sf.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20913; Fri, 2 Oct 1992 10:00:12 +1000 (from dab@asylum.sf.ca.us) Received: from dab.refuge.asylum.sf.ca.us by asylum.sf.ca.us via PCMAIL with DMSP id AA01925; Thu, 1 Oct 92 20:00:03 -0400 (EDT) Date: Thu, 1 Oct 92 20:00:03 -0400 (EDT) Message-Id: <9210020000.AA01925@asylum.sf.ca.us> To: big-internet@MUNNARI.OZ.AU Subject: maps From: dab@asylum.sf.ca.us (David Bridgham) Reply-To: dab@asylum.sf.ca.us Sender: dab@asylum.sf.ca.us Repository: asylum Originating-Client: refuge.asylum.sf.ca.us I like Nimrod's idea of using maps for routing. The analogy to navigating in the real world works well for me. There is one piece I havn't been able to get a handle on though. In the real world you know when to drop to a smaller scale map based on how close you are to your destination (and how dense the roads are in your general area). You know how close you are because we navigate in 2 space and distance estimates are a simple calculation. In network space, distance is a lot more complicated. How do you know when to switch map scales? Maybe I'm pushing the analogy too far. Dave From owner-big-internet@munnari.oz.au Fri Oct 2 10:32:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22243; Fri, 2 Oct 1992 10:32:43 +1000 (from owner-big-internet) Return-Path: Received: from asylum.sf.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20914; Fri, 2 Oct 1992 10:00:13 +1000 (from dab@asylum.sf.ca.us) Received: from dab.refuge.asylum.sf.ca.us by asylum.sf.ca.us via PCMAIL with DMSP id AA01907; Thu, 1 Oct 92 19:59:54 -0400 (EDT) Date: Thu, 1 Oct 92 19:59:54 -0400 (EDT) Message-Id: <9210012359.AA01907@asylum.sf.ca.us> To: Gary Scott Malkin Subject: Re: routing architecture From: dab@asylum.sf.ca.us (David Bridgham) Reply-To: dab@asylum.sf.ca.us Cc: big-internet@MUNNARI.OZ.AU Sender: dab@asylum.sf.ca.us Repository: asylum Originating-Client: refuge.asylum.sf.ca.us [proposal for three levels of addressing hierarchy, each 12 bits in a 16 bit field.] It seems too easy. Have I missed something? First, you're assuming a fairly dense use of the address space, denser that we've achieved to date. More importantly, you're assuming that each level of the addressing heirarchy allows you to completely abstract away the lower levels for the purpose of routing. Basically, the packet routing would be forced to follow the addressing heirarchy. If the addressing heirarchy matches the network's topology then this is fine. I think that is a bad assumption. The real world would quickly build lots of kludges around this nice theoretical abstraction and you'd have a mess. Dave From owner-Big-Internet@munnari.oz.au Fri Oct 2 11:18:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25481; Fri, 2 Oct 1992 11:19:22 +1000 (from owner-Big-Internet) Return-Path: Received: from ucsd.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25450; Fri, 2 Oct 1992 11:18:59 +1000 (from tots!tots.Logicon.COM!tep@UCSD.EDU) Received: from tots.UUCP by ucsd.edu; id AA29999 sendmail 5.67/UCSD-2.2-sun via UUCP Thu, 1 Oct 92 18:14:28 -0700 From: tots!tots.Logicon.COM!tep@UCSD.EDU Received: from galt by tots.Logicon.COM (3.2/4.16) id AA10629; Thu, 1 Oct 92 16:49:14 PDT Received: by galt.tots.Logicon.COM (3.2/4.02-client) id AA00140; Thu, 1 Oct 92 16:49:11 PDT Date: Thu, 1 Oct 92 16:49:11 PDT Message-Id: <9210012349.AA00140@galt.tots.Logicon.COM> To: BBN.COM!Lyman@ucsd.EDU Cc: kre@munnari.oz.au, big-internet@munnari.oz.au, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu In-Reply-To: "Lyman Chapin"'s message of Thu, 1 Oct 92 12:13:52 EDT <9210011934.11981@munnari.oz.au> Subject: size and alignment of Hop Limit field in SIP Reply-To: tep@tots.Logicon.COM X-Organization: Logicon, Inc., San Diego, California My first message to this list, please be gentle :-) On the subject of TTL as raised by Lyman, I have no problem with an 8-bit TTL field, but I would bias that by about 4 bits, e.g. a TTL field of 1 indicates a TTL of 2^4, and a TTL field of 255 indicates a TTL value of 4080. Of course you can't specify a TTL < 16, but who cares? This is enough network radius to last a long, long time. Since I am new here: Tom E. Perrine (tep) | tep@Logicon.COM |Voice: +1 619 597 7221 Logicon, Inc. | sun!suntan!tots!tep | or : +1 619 455 1330 4010 Sorrento Valley Blvd| | FAX: +1 619 552 0729 San Diego CA 92121-1498 |Been there, done that, bought the T-shirt... From owner-Big-Internet@munnari.oz.au Fri Oct 2 11:40:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26773; Fri, 2 Oct 1992 11:41:21 +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 AA26746; Fri, 2 Oct 1992 11:40:56 +1000 (from kre) To: Gary Scott Malkin Cc: big-internet@munnari.oz.au Subject: Re: routing architecture In-Reply-To: Your message of Thu, 01 Oct 92 15:12:52 -0400. <14124.199210011912@atlas.xylogics.com> Date: Fri, 02 Oct 92 11:40:47 +1000 Message-Id: <8781.717990047@munnari.oz.au> From: Robert Elz In addition to what David Bridgham said, your assumption that routers would only need to deal with 4096 routes will not work except in very constrained circumstances. In many cases, the routers in the centre of the world, which are the only ones that really need to deal with huge routing tables in any case, will have to know at the very least their own 'level' (4096 routes) and at least one level below (another 4096), but two or three lower levels would be common (up to about 16K routes total), and perhaps the immediate level above (now 20K routes). And this still assumes no exception cases (backdoor routes) to deal with. kre From owner-Big-Internet@munnari.oz.au Fri Oct 2 12:41:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00910; Fri, 2 Oct 1992 12:41:25 +1000 (from owner-Big-Internet) Return-Path: Received: from venera.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00898; Fri, 2 Oct 1992 12:41:11 +1000 (from hotz@ISI.EDU) Received: from LOCALHOST by venera.isi.edu (5.65c/5.65+local-6) id ; Thu, 1 Oct 1992 19:41:23 -0700 Message-Id: <199210020241.AA05021@venera.isi.edu> To: dab@asylum.sf.ca.us Subject: Re: maps Cc: big-internet@MUNNARI.OZ.AU Reply-To: hotz@ISI.EDU Date: Thu, 01 Oct 92 19:41:22 PDT From: Steve Hotz From: dab@asylum.sf.ca.us (David Bridgham) >> I like Nimrod's idea of using maps for routing. [...] >> In the real world you know when to drop to a smaller scale map >> based on how close you are to your destination ... >> You know how close you are because we navigate in 2 space and >> distance estimates are a simple calculation. In network space, >> distance is a lot more complicated. How do you know when to switch >> map scales? Maybe I'm pushing the analogy too far. Hi, The extended analogy is fine. Therein lies the rub ... The answer is: we don't know yet, and the problem isn't ready to be "engineered", but requires some basic research first (similar things are being looked at in the context of SDRP). Unfortunately, the straight-forward model of the game is a graph search. If from some intermediate node you can not see a good path in any "direction", you have to acquire more detailed maps of the network in (one or more of) those directions. After asking for a detailed map of one "neighboring area", you still may not have enough detail, or may find it is the wrong direction (perhaps the required ToS is not supported). In the worst case you have to search in every direction at each step, and will end up acquiring a very detailed map of the entire globe. You can't know, a priori, which direction to search because this implies you already know the route! The most promising approachs being looked at (by SDRP folks) are: (1) some sort of "fake" heuristic distance -- the problem being that a single "distance" metric may not be enough, because the maps may change depending on the ToS required, and (2) schemes similar to (based on) Clark's route fragment idea -- this is basically an organization of the maps by destination, so you do have a handle/index (a priori) for someone who can give you several possible parts of the route (a map shopping list to further stretch the analogy). cheers, steve From owner-big-internet@munnari.oz.au Fri Oct 2 13:15:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02143; Fri, 2 Oct 1992 13:15:17 +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 AA29882; Fri, 2 Oct 1992 12:25:37 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA06751; Thu, 1 Oct 92 20:25:32 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA13087; Thu, 1 Oct 92 20:25:31 MDT Message-Id: <9210020225.AA13087@goshawk.lanl.gov> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: New routing architecture In-Reply-To: Your message of Thu, 01 Oct 92 12:16:14 -0400. <9210011616.AA19404@ginger.lcs.mit.edu> Date: Thu, 01 Oct 92 20:25:31 MST From: peter@goshawk.lanl.gov (let me apologize in advance for heavy editing of the Noelgram) . Noel, >> I would think the term "waste byproduct" would be more appropriate, >> actually. (What should we infer from this wrt the Internet and Routing Directorates which has been steering the IETF for the past couple of years?) I am glad to see that we are once again helping to present the results of the Internet community in the best possible light. However, this doesn't seem to jibe with your professed interest in getting the vendors to adopt other products from the IETF, such as BGP. IN short, simpleton that I am: I am, once again, confused. >>> which were only loosly designed to work with each other, and which Perhaps loose design is not a bug, it could provide the resilience to avoid brittle failure. >>> These all fit within a basic framework (the EGP/IGP split) which, >>> well, I'd better stop there. Isolation, fate sharing regions, speciation, etc. etc. All good things. If we could discover routing sex we could probably speed up the adaptation rate. >>> True, but this is a problem with the vendors, over whom the IETF has little >>> influence. They respond to $$$, specifically equipment sales. A mighty fine genetic operator. Hopefully the IETF will get back to being in the feedback loop of the network ecology where the market (actually the customer) is king. >>> hiding) which still seems to hold pretty well. Since the intervening years >>> have provided no surprises, And no perceptable demand from the market place. 1 million hosts and counting >>> The vendors?!?! Don't make me laugh. Their vision is too limited. They seem to be able to provide the opportunity for many to do interesting work in the IETF, IESG, etc. etc. I have even heard of people retiring from them and doing fun stuff afterwards. >>> That's a little simplistic. You have to get it designed, tested, standardized, >>> and then get the operators to ask (berate, actually)x the vendors for it. Most >>> vendors don't seem to have enough foresight to do anything else, as I'm sure >>> your BGP experiences have shown! The vendors seem to be carrot ($$$) kind of folk and not stick kind folk. They did pay for much of the design, testing, standardization and deployment of OSPF, BGP, CLNP, atm, frame relay, ethernet, T-1, ..., etc., etc. Sure the IETF is and has been the forum for much of this, and the government contributes a lot in terms of networks and funds for I**4 activities, but from looking at InterOp my guess is that networking is BIG business. So, I guess I might be less critical of their involvement than you on this topic. As far as the BGP experience, I suspect that the IESG and others who seem so ambivalent about BGP didn't help much. >>> Noel Don't revolt, evolve, peter From owner-Big-Internet@munnari.oz.au Fri Oct 2 13:35:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02984; Fri, 2 Oct 1992 13:35:51 +1000 (from owner-Big-Internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02981; Fri, 2 Oct 1992 13:35:40 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA03027 (5.65c/UK-2.1-921001); Thu, 1 Oct 1992 23:35:23 -0400 From: Gary Scott Malkin Date: Thu, 1 Oct 1992 23:35:23 -0400 Message-Id: <3027.199210020335@atlas.xylogics.com> To: dab@asylum.sf.ca.us Cc: big-internet@munnari.oz.au In-Reply-To: (David Bridgham's message of Thu, 1 Oct 92 19:59:54 -0400 (EDT) <9210012359.AA01907@asylum.sf.ca.us> Subject: routing architecture > First, you're assuming a fairly dense use of the address space, denser > that we've achieved to date. Just because we've made sparse use of the address space so far, doesn't mean we have to do it in the future. > More importantly, you're assuming that each level of the addressing > heirarchy allows you to completely abstract away the lower levels for > the purpose of routing. Basically, the packet routing would be forced > to follow the addressing heirarchy. If the addressing heirarchy In order to reduce overall overhead throughout the system, I'd be willing to accept slightly suboptimal routing for some packets. Is there anything wrong with forcing packets to go up then down? > The real world would quickly build lots of kludges > around this nice theoretical abstraction and you'd have a mess. If anyone wants to build a backdoor path, or simply wants to know about more things than might otherwise be necessary, they can buy a bigger router which can handle the load. Just don't let them advertise that as a transit route to everyone else. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Fri Oct 2 13:45:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03367; Fri, 2 Oct 1992 13:45:26 +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 AA03356; Fri, 2 Oct 1992 13:45:13 +1000 (from upadhyay@caldera.usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.1) id AA10117; Thu, 1 Oct 92 20:45:02 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA04717; Thu, 1 Oct 92 20:45:00 PDT Date: Thu, 1 Oct 92 20:44:58 PDT From: Chintan Upadhyay To: big-internet@munnari.oz.au Subject: SIP mailing list . Message-Id: This is an announcement of a new mailing group : sip@caldera.usc.edu. The postings in this group will be related to the Simple Internet Protocol ( SIP ), proposed by Steve Deering ( Xerox , PARC ). If you want to be added onto this group, please send mail to : sip-request@caldera.usc.edu From owner-big-internet@munnari.oz.au Fri Oct 2 15:18:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07169; Fri, 2 Oct 1992 15:19:09 +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 AA04542; Fri, 2 Oct 1992 14:08:10 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA18053 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 2 Oct 1992 14:08:23 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA02757; Fri, 2 Oct 92 14:08:05 EST Message-Id: <9210020408.AA02757@wanda.mel.dit.CSIRO.AU> To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: Routing architectures In-Reply-To: Your message of "Thu, 01 Oct 92 09:57:39 MST." <9210011657.AA19432@aland.bbn.com> Date: Fri, 02 Oct 92 14:08:04 +1000 From: Bob Smart >PS: OK, so you believe there are good technical arguments for deciding now. >Good! So let us know the correct answer to the following questions (formal >proofs encouraged): > > * How big should the TOS/flow field be? How should it be encoded? TOS for what? Policy based routing? TOS is simply the wrong way to do policy based routing. The only way to do policy-based routing is for the source to (approximately) specify the route. Suppose you have a TOS field that says "minimize delay". Does that mean that you are prepared to pay 10 times as much for a 1% reduction in delay? If not how do you define a TOS field that exactly describes how much extra you are prepared to pay for various amounts of reduced delay? What if that will only give you totally inadequate throughput? Toss TOS. Read the PIP Overview. I associate "flow" with attached resources. Any system that requires flows to be set up for all communications can't work. The number of flows through any given router is arbitrarily large, and uncorrelated with the size of the net or with any local restrictions. Making everything use flows puts arbitrary restrictions on the way the network works. Why shouldn't the gas company open a TCP connection to each of their meters and keep the data flowing on each of a million links at a steady 4 bytes/month? So flows will only be used where attached resources are required. And since each flow with attached resources will have a cost, then making it available without incremental charge will be open to abuse. So I think it will be an optional feature of any solution. The other flow-related proposal has been to use flows to improve the performance of routing, but the packet can still be correctly forwarded without looking at the flow-id. This proposal is simply irrelevant to the debate. However I would suggest that we wouldn't be even thinking about this problem if packet forwarding was done in a consistent way instead of gathering fields from all over the packet before deciding where to forward the packet to. I am certainly satisfied that the key target that we have to hit is, in the Internet tradition, stateless networking. > * How big should the address space be? As we've seen with IPv4 the need to use the address bits in a structured way means that a finite number of bits will be as strong as its weakest link (which was, in the case of IPv4, the class B space). The only answer that one can be comfortable with is: effectively infinite with no limit to the number of levels of hierarchy. > * how should this address space be structured? Prove it scales to a few > billion mobile end-systems and supports multicasting, while keeping > routing tables manageably small. The routing part should be separated from the identification part. This removes one of the main problems with mobility. The other aspects of mobility aren't too hard. Is multicasting that hard? I realise there are nasty questions about how the recipients of a multicast recover gracefully from lost packets, but that seems to be at a higher level. I'd certainly like to hear what the multicast requirements are at the network layer. Finally, by not limiting the number of levels of hierarchy we can always reduce the table sizes by increasing the number of levels [at the probable cost of making routing less optimal]. The key here is to be able to easily add extra levels to the hierarchy when needed without blowing everything to bits. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - PIP hits all these nails neatly on the head. However I agree with Noel and Craig on the value of keeping the IPv4 hosts working with full global connectivity as long as possible. By using IPv4 addresses as EIDs in PIP and doing some simple header conversion (not address translation), PIP can keep the IPv4 world humming along for the maximum possible time. Bob Smart From owner-Big-Internet@munnari.oz.au Fri Oct 2 15:28:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07634; Fri, 2 Oct 1992 15:28:59 +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 AA07631; Fri, 2 Oct 1992 15:28:48 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA08478; Thu, 1 Oct 92 23:28:40 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA13742; Thu, 1 Oct 92 23:28:39 MDT Message-Id: <9210020528.AA13742@goshawk.lanl.gov> To: Craig Partridge Cc: Noel Chiappa , yakov@watson.ibm.com, big-internet@munnari.oz.au Subject: Re: Routing architectures In-Reply-To: Your message of Thu, 01 Oct 92 09:57:39 -0700. <9210011657.AA19432@aland.bbn.com> Date: Thu, 01 Oct 92 23:28:39 MST From: peter@goshawk.lanl.gov Craig, Where does the following requirement come from? >>> we need an architecture good for at least 20 years. I wonder if this is the timeline set by people of our generation who hope to get by with one last transition before we retire ... (if so, you could shave a few years off of that estimate as my contribution towards the RISC approach to network design.) On a serious note, why have full byte NLPIDs or LLC if you aren't planning to demultiplex into multiple network layers? Yours in genetic diversity, and multiple N-PDU formats and functionality, peter From owner-Big-Internet@munnari.oz.au Fri Oct 2 16:29:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09908; Fri, 2 Oct 1992 16:29:23 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09904; Fri, 2 Oct 1992 16:29:13 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Thu, 1 Oct 92 23:28:58 -0700 Date: Thu, 1 Oct 92 23:28:58 -0700 From: Tony Li Message-Id: <9210020628.AA03173@lager.cisco.com> To: big-internet@munnari.oz.au In-Reply-To: Noel Chiappa's message of Thu, 1 Oct 92 10:59:01 -0400 <9210011459.AA18885@ginger.lcs.mit.edu> Subject: routing architectures [Another batched reply...] [Noel:] This is exactly the point of the local abstraction control mechanism in Nimrod, which Deborah will no doubt remember me inventing some years back under the name "blister model". I take it you are referring to the similar capability in SDR? Unfortuntely, I'm not familiar with the blister model. And I confess to not being caught up on Nimrod, but yes, this is what we have in mind for SDR. We await a NoelGram with baited breath. God, one person who *likes* (well, maybe that's too strong :-) the damn things. You, sir, get a gold star! Yes, we're really afraid that you might like it. ;-) This is only a surface distinction, which I am aware of and ignored since it's a mechanism question. (I was responding to a sweeping statement on your part that might have confused the less cognizant on the list.) Policy influences on routes are the net effect here, and whether they happen by distributing policy info widely and calculating locally (as in IDPR), or by distributed affect of policy on route calculation (as in IDRP) is of only engineering importance. Well, to this here engineer, your sweeping statement about BGP vs. IDPR which ignored these small engineering details might have confused the less cognizant on the list. Shall we just agree to be accurate, both in architectural and engineering specifics? [lot of stuff where we're agreeing in circles elided...] This is a fault of HBH forwarding, NOT the routing protocol. Note that a LS protocol which does HBH has the exact same problem. Please try doing policy routing within OSPF... Yes, but how do you do non-HBH routing in a Destination Vector system? What's the point of computing those routing tables if you aren't going to use them? By having a DV system _with_ a blister model. I would like to hear you argue that IGRP has better policy routing support than BGP. Pretty please? ;-) The only thing that I can think of is the non-functional TOS bits in IGRP. I think of TOS (and I speak here of real TOS, not the lobotomized stuff in the IP header) as a subset of policy routing; there's not really much difference between saying "I want my traffic to go on links with >1Mbit/sec" and saying "I want my traffic to go on links paid for by X". So the minimal TOS support in IGRP is sort of minimal policy routing; I know, I know, it's not really very strong TOS support even. So you're comparing functional r.e. based AS path filtering to non-functional TOS routing. And the TOS wins????? (I must say I am mildly amused by hearing someone from Cisco dump on IGRP! :-) That wasn't dump. As one of the maintainers of IGRP, I have no illusions about both the benefits and the shortcomings of IGRP. To call the bits non-functional is nothing but technically honest (some here claim it as a fault). Yes, but the fact that you can use PV's to do some limited policy routing is undoubtly a factor in chosing them, yes? I mean, wouldn't some of the SRI algorithms, etc, be a better way to do a DV (and by DV I *always* mean Destination Vector, which includes both Distance and Path Vector subtypes) architecture if you wanted DV, and didn't need the policy stuff? Well, I wasn't here, but at the time that BGP was designed, I don't believe that the SRI algorithms were available (or at least sufficiently well known). Given it to do over again, I would have to think very hard about the tradeoffs involed. From: "William Allen Simpson" I read a short version (no packet encapsulation format) in July. Perhaps there's a later version. Yes, there is. It's an ID. We welcome comments, both here and privately. I think that we'll probably need to allow hop-by-hop *and* source-routing to co-exist forever. But I would prefer that the hop-by-hop be *only* policy-less and anything else be pre-calculated. What is the point in calculating a hop-by-hop route that you can't use? The provider/exterior/interior split doesn't do it for me. I really *hate* the single level of administrative domains. I would prefer a dynamic multi-level structure. I claim that you don't hate administrative domains and that what you hate is a fundamental incompatibility between your local network and the domain borders. In fact, if you deploy BGP4, I believe that you can remedy this situation since you can now divide your class A into multiple ASs, each of which is announced separately. This is not to throw water on idea of increased levels of hierarchy. From: estrin@usc.edu (Deborah Estrin) SDRP version 1 is just the basics. Of course we dont want things done by hand and human configuration longer term. But those pieces can be, and are, being worked on in parallel with getting the skeleton in place. In fact, you may view SDRP v1 as simply the deployment of the forwarding mechanism and semi-static routing. The interesting protocols are yet to come. Tony From owner-Big-Internet@munnari.oz.au Fri Oct 2 17:24:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12001; Fri, 2 Oct 1992 17:24:46 +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 AA11995; Fri, 2 Oct 1992 17:24:32 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11521>; Fri, 2 Oct 1992 00:24:06 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Fri, 2 Oct 1992 00:24:00 -0700 To: Craig Partridge Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Routing architectures In-Reply-To: Your message of "Thu, 01 Oct 92 09:57:39 PDT." <9210011657.AA19432@aland.bbn.com> Date: Fri, 2 Oct 1992 00:23:47 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct2.002400pdt.10779@skylark.parc.xerox.com> Craig wrote: > Well, Noel, I can agree that I think the rush to a new packet format is a bit > premature. Me too. I wouldn't be flogging SIP right now if the IAB/IESF weren't threatening to pick *some* new packet format by the end of the year. Steve From owner-Big-Internet@munnari.oz.au Fri Oct 2 17:28:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12131; Fri, 2 Oct 1992 17:28:37 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210020728.12131@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12124; Fri, 2 Oct 1992 17:28:23 +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 ; Fri, 2 Oct 1992 08:27:24 +0100 To: David "R." Oran Cc: yakov@watson.ibm.com, jnc@ginger.lsc.mit.edu, big-internet@munnari.oz.au Subject: Re: Growth In-Reply-To: Your message of "Thu, 01 Oct 92 15:16:39 EDT." <921001151639.12546@sneezy.lkg.dec.com> Date: Fri, 02 Oct 92 08:27:21 +0100 From: Jon Crowcroft >While I am emotionally inclined to agree with you that scaling >of people is more important than scaling of memory or bandwidth, >where is the data to support the assertion that the number of staff >needed is growing faster than the network? David, well, we used to have static routing in the UK tables managed by a single NOC - without adding any hosts, we now have to go to dynamic IP access to over 45,000 hosts, but we also may have to have a routing person at each of ~100 sites (mainly as first point of call/responsibility when thigs go haywire, or for policy enforcement) (ok not full time, obviusly) - this represents quite serious growth... the same effect was observed when going from hosts.txt to DNS _ every site ended up with a DNS guru... obviosuly there is a benefit for this cost (resiliece, longer term scalability) but the cost is there...and i'm not sure our sites will relish it if the effort increases unless they get an obvious benefit what i'm saying is that the NEXT step of automation is not there (we manually mail about 3 different organsiations to add a net number to the NSF and other policy databases - we should have trust between NOCs, and puiblic key protectded crypto sealed policy distribution at the moment, this is not the case and with more and more sensitive places (hospticals etc) joingin g the net, we want good scalable, automated, distributed policy routing...it should also admit of local hacks (e.g. PIP tunnels) where really needed without central authority mechanism ruling against... remember, the original question was whether the current work was good enough... jon From owner-Big-Internet@munnari.oz.au Fri Oct 2 17:37:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12402; Fri, 2 Oct 1992 17:37:49 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210020737.12402@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12393; Fri, 2 Oct 1992 17:37:37 +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 ; Fri, 2 Oct 1992 08:36:36 +0100 To: yakov@watson.ibm.com Cc: oran@sneezy.lkg.dec.com, jnc@ginger.lsc.mit.edu, big-internet@munnari.oz.au Subject: Re: Growth In-Reply-To: Your message of "Thu, 01 Oct 92 16:10:51 EDT." Date: Fri, 02 Oct 92 08:36:34 +0100 From: Jon Crowcroft >>what convinces me is the number of staff employed >>to keep things working is growing faster than the network... >May be we should ask folks at MERIT about this assertion. >After all, they've been running the NSFNET Backbone for >the past 5 years. asking a signle organisation about the growth of staff required to run multi-admistration routing will tell you very little...unless merit can read minds! cheers jon From owner-big-internet@munnari.oz.au Fri Oct 2 18:25:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14076; Fri, 2 Oct 1992 18:25: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 AA12819; Fri, 2 Oct 1992 17:49:24 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11609>; Fri, 2 Oct 1992 00:49:08 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Fri, 2 Oct 1992 00:49:02 -0700 To: "Lyman Chapin" Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: size and alignment of Hop Limit field in SIP In-Reply-To: Your message of "Thu, 01 Oct 92 09:13:52 PDT." <92Oct1.105919pdt.11616@alpha.xerox.com> Date: Fri, 2 Oct 1992 00:48:56 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct2.004902pdt.10779@skylark.parc.xerox.com> Lyman wrote: > Experience tells me that > whenever someone insists that "clearly could *never* get any > bigger than X", and wires a hard limit of X into something as > fundamental to the Internet as [S]IP, we eventually regret it - That's not quite what I'm saying. I'm saying that it would be a Bad Thing for the diameter of the Internet to get anywhere near 255 hops. The more hops a packet has to take, the greater the delay and jitter it suffers, and the greater risk it is at for loss or damage. Also, bear in mind that the purpose of the Hop Limit field in SIP is to cause a packet to eventually be discarded if it gets caught in a routing loop -- if the Internet diameter is allowed to get so large that packets have to start off with very large Hop Limits, gigabit streams of packets that happen to end up in routing loops will waste significant resources. It ought to be possible to build a stupendously large internet with a maximum diameter that is far less than 255. Isn't the global phone system diameter something like 9 hops? Keeping the diameter down may well require that some actual engineering be applied to the topology, such as allocating a "maximum hop budget" to each layer in the routing hierarchy. Steve From owner-big-internet@munnari.oz.au Fri Oct 2 18:39:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14648; Fri, 2 Oct 1992 18:39:41 +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 AA11108; Fri, 2 Oct 1992 16:59:15 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11668>; Thu, 1 Oct 1992 23:58:54 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Thu, 1 Oct 1992 23:58:43 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: Re: SIP Date: Thu, 1 Oct 1992 23:58:36 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct1.235843pdt.10779@skylark.parc.xerox.com> I have seem to have alienated a number of people by my pugnacious response to Noel's message. It was a botched attempt to match Noel's hyperbolic style of argument. (Remember, he is the one who said that one of my sentences "scared the piss right out of" him, who compared me to the proverbial drunk looking for his keys under the streetlight, who accused me of "a substantial lack of formal attention to the real fundamentals of a routing architecture", and so on.) I have also been unduly influenced by the current U.S. political climate, where the current wisdom is that the best response to an "attack ad" is a swift counter-attack; I should have remembered that such "negative advertising" tends to turn off the voters. I apologize to Noel and to all who were offended, and I will try to be my normal, polite self from now on. Tony wrote: > The existing policy mechanisms, crude tho they may be, are there to > address the unforunate reality that this is a political world we live > in, complete with AUP's, fussy folks who want to route their packets > in certain directions and other folks who are not willing to use their > bandwidth to provide routing for neighbors. As such, there is no > "smooth operation" _ever_ possible in inter-domain routing. So I > would suggest that the real problem is to scale the Internet while > still being able to maintain contact with reality. While we will never see policy-free inter-domain routing, I think a lot of the kinds of policy concerns you mention will become much less important in the truly large-scale Internet of the future. I expect most transit service to be provided by competitive, commercial "carriers" who won't care what's inside of the packets they carry (i.e., no AUPs), and I expect there to be a much clearer distinction between who are the carriers and who are the end users (i.e., a lot less of this "routing through your neighbors" business). Subsidized research-and-education packet networks make about as much sense to me as subsidized research-and-education telephone networks. Still, the routers that attach users' domains to the transit services will no doubt have lots of knobs on them, like modern PBXs, to support policy actions such as selecting between different directly-attached providers depending on the time of day or on the quality-of-service requirements of the outbound traffic. SIP has a source routing facility, for those who think that source-directed routing will be an important capability, but I will certainly plead guilty to having no architecture, or even a clue, for how a source would get the information required to formulate a sensible source route -- that's "Deborah's problem". SIP will also have service-class identifiers and flow identifiers, either explicit or implicit (in the port fields), upon which routing and scheduling decisions might be made, but that too is an area of research about which I have no new insights (though I am spending occasional brain cycles on those topics). > BGP carries NO expensive policy baggage. In contrast, IDPR has the > wonderful property that it floods your policies througout the ENTIRE > world. I believe that you have your comparison _exactly_ backwards. Yeah, in the heat of the moment, I made an inept, apples-and-oranges comparison that was based on incomplete understanding. The BGP policy baggage I was thinking of is the path information -- if you don't have to constrain routing for policy reasons, a regular old distance-vector protocol ought to do, which would certainly have shorter update packets. I have no idea whether or not there is a lower-overhead way to achieve the protection from static loops that you say is the primary purpose of the path information, but I assumed there was. As for IDPR, I was thinking that, if you don't have to do policy, you'd probably rather run a link-state inter-domain protocol than a distance-vector one, for all the reasons that LS is often preferred over DV (e.g., faster convergence after topology changes and lower-overhead event-driven updates), and IDPR is an inter-domain link-state algorithm that might be used to build and maintain hop-by-hop routing tables, ignoring all of its policy machinery. But then, might as well just use OSPF, eh? Just forget I even made such a dumb comparison. Please? Noel wrote: > ...you seem, by implication of retaining BGP, OSPF, etc, to be retaining > the architectural split between EGP's and IGP's. Is this a deliberate > design decision, and if so, can you give me your reasoning as to why? I think that one of the strengths of hierarchical hop-by-hop routing is that two domains at the same hierarchical level may run different routing protocols, which themselves differ from the protocols run by the superdomain or any subdomains. Thus, I can run RIP in my domain, you can run OSPF in your domain, and the interdomain routing can be BGP. This allows new and better routing protocols to be tested and deployed piecemeal, which is Good Thing. So, to answer your question, yes I approve of the architectural split between EGPs and IGPs, in that it isolates the details of one domain's routing from another's, and from the inter-domain routing. On the other hand, I disapprove of the notion that there are only two levels of routing, intra-domain and inter-domain. The modern IGPs like OSPF and IS-IS are themselves multi-level, and there is no reason the intra-domain routing shouldn't also be multi-level. Further, there should be nothing to *prevent* running the same routing protocol at all levels, such as a 4-level version of OSPF. > Anyway, real demand for policy routing is just the way the world > works. People don't always want just the best route, but have funny little > reasons and desires having little to do with 'best' for making their traffic > go other places. If you really think otherwise, how would *you* react if you > were only allowed to take a single path from A to B when driving your car, > for all A and B? I'm not sure that car driving is the best analogy. When I make a phone call, I don't care what path the connection takes, as long as it meets my service demands: low enough delay, noise, and echo, high enough fidelity, and low probability of eavesdropping, at a price I am willing to pay. Yes, I may make some coarse-grain policy decisions, probably cost-based, such as choosing between MCI and Sprint or between the public phone system and the Xerox internal long-distance phone system, but I don't feel particularly deprived that I can't route my phone call via the Chiappa residence, or via Santa Cruz in the evening so the electrons can enjoy the sunset. > In other words, the SIP proposal has no individual vision for a routing > architecture, but you'll take whatever others decide on? up here...> The SIP proposal uses the routing architecture that has been developed for the Internet, which is continuing to evolve through the work of others more expert than me. It assumes that routing will be performed on topologically-significant, hierarchically-structured, globally-unique addresses, possibly augmented with service-class identifiers, and that forwarding will be done, hop-by-hop, by look-ups into tables of address prefixes that may be computed by any of a number of routing protocols. It also supports source routing. It has no "individual vision for a routing architecture" if by that you mean some radical departure from the way routing works today. In that respect, it is a low-risk proposal -- we already know how to do hop-by-hop hierarchical routing and we have a pretty good idea how to scale it up to support "billions and billions" of hosts. > There is a straightforward solution to the Internet scaling problems > that involves increasing the address size and, hence, changing the > packet format > > I disagree with the reasoning step there (i.e. I don't believe that the > conclusion follows necessarily from the premise), ... OK, delete the word "hence" from my sentence. > and in any case, the characterization of "straightforward" is wholly > inappropriate. Something that involves deploying a new packet format in > hosts is not "straightforward". It is straightforward in the same sense that a straightforward solution to the problem of an overcrowded building is to move to a bigger building. I didn't mean to imply that it was cheap or painless to do. > PS: Just out of interest, it would be useful to know what percentage of the > people on this list have read the IDPR specs, or even the IDPR architecture > document... if there some way to poll a subset of the list to get a > representative sample? I don't think I've read either one -- I haven't been particularly concerned with the problems of policy-based routing. If you tell me exactly which documents you are referring to, I will try to read them soon. Steve From owner-Big-Internet@munnari.oz.au Fri Oct 2 19:17:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15833; Fri, 2 Oct 1992 19:17:25 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210020917.15833@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15829; Fri, 2 Oct 1992 19:17:17 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 2 Oct 1992 10:17:02 +0100 To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: size and alignment of Hop Limit field in SIP In-Reply-To: Your message of "Fri, 02 Oct 92 00:48:56 PDT." <92Oct2.004902pdt.10779@skylark.parc.xerox.com> Date: Fri, 02 Oct 92 10:17:00 +0100 From: Zheng Wang >the purpose of the Hop Limit field in SIP is to cause a packet to eventually >be discarded if it gets caught in a routing loop -- if the Internet diameter >is allowed to get so large that packets have to start off with very large >Hop Limits, gigabit streams of packets that happen to end up in routing loops >will waste significant resources. Since the Hop count is used to loosely enforce the Maximum Segment Lifetime (MSL), increasing the maximum value of the Hop count may also have implications to TCP's operation (e.g. the sequence number wraparound time, TIME-WAIT or the timestamp resolution in the extended TCP). Cheers Zheng From owner-Big-Internet@munnari.oz.au Fri Oct 2 22:14:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21488; Fri, 2 Oct 1992 22:14:17 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210021214.21488@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21482; Fri, 2 Oct 1992 22:14:02 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1276; Fri, 02 Oct 92 08:13:52 EDT Date: Fri, 2 Oct 92 08:13:51 EDT From: yakov@watson.ibm.com To: kwe2@BBN.COM Cc: big-internet@munnari.oz.au Subject: You ask "Why a New Routing Architecture?" Ref: Your note of Thu, 1 Oct 92 17:58:58 EDT >If by "TOS" you mean within our current IP definition, how do you deal >with the routing table explosion/scaling problem of TOS routing ? >Are you counting on CIDR to conteract the TOS multiplier effect. Kent, The "proof" you presented for justifying a new routing architecture requires *only* 1 TOS, "R&E". In the *worst possible case* addition of one extra TOS will double the size of routing table, so the "multiplier effect" is equal to 2 (worst case). Are you concern with such "multiplier effect" ? Do you expect that "a new routing architecture" will have *less* routing overhead than the one that can be achieved with CIDR and 1 TOS ? Yakov From owner-Big-Internet@munnari.oz.au Fri Oct 2 22:27:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21888; Fri, 2 Oct 1992 22:27:39 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210021227.21888@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21885; Fri, 2 Oct 1992 22:27:31 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1511; Fri, 02 Oct 92 08:27:28 EDT Date: Fri, 2 Oct 92 08:27:27 EDT From: yakov@watson.ibm.com To: J.Crowcroft@cs.ucl.ac.uk Cc: oran@sneezy.lkg.dec.com, jnc@ginger.lsc.mit.edu, big-internet@munnari.oz.au Subject: Growth Ref: Your note of Fri, 02 Oct 92 08:36:34 +0100 >asking a single organization about the growth of staff required to run >multi-administration routing will tell you very little... unless >merit can read minds ! Jon, But in your original mail you mentioned that you are convinced that the Internet needs a brand new routing architecture based on "the number of staff employed to keep things working..." If the number of staff employed *in your organization* is "growing faster than the network", I failed to see how can you extrapolate from this that the *whole* Internet needs a new routing architecture. I picked up MERIT because they've been dealing with quite complex routing for the past 5 years. Certainly to get a more complete picture it would be useful to gather information from other organizations, including yours. Yakov Rekhter From owner-Big-Internet@munnari.oz.au Fri Oct 2 22:39:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22282; Fri, 2 Oct 1992 22:40:01 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210021240.22282@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22273; Fri, 2 Oct 1992 22:39:54 +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 ; Fri, 2 Oct 1992 13:39:36 +0100 To: yakov@watson.ibm.com Cc: kwe2@BBN.COM, big-internet@munnari.oz.au Subject: Re: You ask "Why a New Routing Architecture?" In-Reply-To: Your message of "Fri, 02 Oct 92 08:13:51 EDT." <9210021214.21488@munnari.oz.au> Date: Fri, 02 Oct 92 13:39:35 +0100 From: Jon Crowcroft >The "proof" you presented for justifying a new routing architecture >requires *only* 1 TOS, "R&E". In the *worst possible case* addition >of one extra TOS will double the size of routing table, so the >"multiplier effect" is equal to 2 (worst case). Are you concern yakov, right - agreed - almost all the time TOS/QOS will affect QUEUEING not ROUTEING - so it'll be based on qos or tos in packet, per packet, not per routing update/FIB entry... how many different routes are there (the richest organisation i know only has triple redundent routes..) jon From owner-Big-Internet@munnari.oz.au Fri Oct 2 23:03:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23160; Fri, 2 Oct 1992 23:07:57 +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 AA23017; Fri, 2 Oct 1992 23:03:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23472; Fri, 2 Oct 92 09:01:35 -0400 Date: Fri, 2 Oct 92 09:01:35 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210021301.AA23472@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: SIP Cc: jnc@ginger.lcs.mit.edu I have seem to have alienated a number of people by my pugnacious response to Noel's message. It was a botched attempt to match Noel's hyperbolic style of argument. Perhaps you typoed, and meant "hypergolic", not "hyperbolic"? :-) I apologize to Noel and to all who were offended, and I will try to be my normal, polite self from now on. I'm not offended, and no apology is necessary to me. (My reply to your message showed that, I hoped..) We are all dealing with stuff we care about a lot, and we can get very excited, and I make allowances. (I hope others can do the same for me, and everyone else, on occasion. :-) In fact, I'd be a little worried if people *didn't* get pretty hot under collar sometimes.... Noel PS: For those of you who aren't rocketeers and without a Webster's handy, they define "hypergolic" as "igniting spontaneously when mixed together"... From owner-Big-Internet@munnari.oz.au Fri Oct 2 23:11:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23224; Fri, 2 Oct 1992 23:11:10 +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 AA23219; Fri, 2 Oct 1992 23:11:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23569; Fri, 2 Oct 92 09:10:53 -0400 Date: Fri, 2 Oct 92 09:10:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210021310.AA23569@ginger.lcs.mit.edu> To: dee@ranger.enet.dec.com, jnc@ginger.lcs.mit.edu Subject: RE: TOS ( was Re: packet format v. routing architecture ) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I'd like to see why the TOS field is a wrong thing Oh, it's not absolutely useless (your file transfer example is a case in point), but the semantics are so limited (it *is* only an 8 bit field :-) it's just not adequate, really. I mean, you can't say "this application needs a minimum of 128 Kbit/sec to function" or anything like that in 8 bits... I like the current TOS field. It's lack of implementation just seems to be a symptom of the relative crudeness of the current routing stuff and the lack of multiple paths with different characteristics in the Internet There's also a major chicken/egg issue with routing protocols, routers and hosts; nobody ever specified it in packets because the routers ignored it, and nobody ever did in in routers because the hosts didn't set it, etc. Noel From owner-big-internet@munnari.oz.au Fri Oct 2 23:14:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23266; Fri, 2 Oct 1992 23:14:27 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210021314.23266@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22729; Fri, 2 Oct 1992 22:55:01 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1861; Fri, 02 Oct 92 08:54:56 EDT Date: Fri, 2 Oct 92 08:54:56 EDT From: yakov@watson.ibm.com To: deering@parc.xerox.com, big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: SIP Ref: Your note of Thu, 1 Oct 1992 23:58:36 PDT >I have no idea whether or not there is a lower-overhead way to achieve >the protection from static loops that you say is the primary purpose >of the path information, but I assume there was. Steve, The paper I published in the April's issue of ACM CCR shows that the overhead of carrying the path information is not that high. So, while conceptually you might save by not carrying the path information, from a practical point of view the saving is likely to be negligible. While other techniques for suppressing static loops in Distance Vector are available (e.g. extended Bellman-Ford by Cheng, Riley, Kumar and Garcia-Luna), the issue of information aggregation (e.g. forming confederations) with such techniques is not worked out. On the other hand, forming confederations with path vector algorithm is a well-developed issue (e.g. routing domain confederations in IDRP). It is also known that with path-vector there are practically no preconditions on how confederations can be formed. They may be nested or overlapped with arbitrary level of nesting. So, with path-vector we *already* developed suitable techniques to deal with information aggregation/abstraction which is crucial for scaling. >you'd probably rather run a link-state inter-domain protocol >rather than a distance-vector one, for all the reasons that LS is >often preferred over DV (e.g. faster convergence after topology >changes and lower-overhead event driven updates). I suggest that these "often preferred" reasons should be re-examined. Most of them are based on rather antiquated papers that compare vanilla Bellman-Ford with SPF. There are at least three papers I am aware of that suggest that these "reasons" may not apply any more. The papers are: (1) "Dynamics of Distributed Shortest-Path Routing Algorithm" by Zaumen and Garcia-Luna, SIGCOMM 1991 (2) "Performance Comparison of Routing Protocols using MaRS: Distance-Vector versus Link-State" by Shankar, Alaettinoglu, Matta, Dussa-Zieger (to appear in ACM SIGMETRICS/PERFORMANCE 92) (3) "Dynamics of Link-State and Loop-Free Distance-Vector Routing Algorithms" by Zaumen and Garcia-Luna I would also suggest to look at the paper Deborah Estrin, myself, and Steve Hotz published in this year SIGCOMM. It shows that using path-vector in a hop-by-hop routing would provide better scaling and more flexibility, as compared to Link-State. >>...it would be useful to know what percentage of the people >>on this list have read the IDPR specs, or even the IDPR architecture >>document.. >I don't think I've read either one... I would also suggest to read my comments on the IDPR architecture document and Martha's response to my comments. Both should be available on-line. Yakov. From owner-Big-Internet@munnari.oz.au Fri Oct 2 23:20:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23468; Fri, 2 Oct 1992 23:20:23 +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 AA23461; Fri, 2 Oct 1992 23:20:08 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23600; Fri, 2 Oct 92 09:20:01 -0400 Date: Fri, 2 Oct 92 09:20:01 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210021320.AA23600@ginger.lcs.mit.edu> To: dee@ranger.enet.dec.com, peter@goshawk.lanl.gov Subject: RE: New routing architecture Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I'm not convinced "we need policy". ... If you had both of those, the remaining "need" for policy routing seems pretty minimal to me. I wish it were that simple. In addition to all the Government nonsense, you will find that many large companies will wish their traffic to take their own global links, and there's always the boycotters (remember the people who got all manner of funds, including some large ones to divest all shares of companies doing business in X), etc, etc, etc, etc. Then there's always the quality/cost tradeoff, which can be hard to quantify, and usually requires human input..... You're right, better resource reservation and security would help a lot, but even doing these right really requires the ability of one agent to say something about the entire route the traffic takes, and that is also policy routing... Noel From owner-Big-Internet@munnari.oz.au Fri Oct 2 23:57:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24658; Fri, 2 Oct 1992 23:57:21 +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 AA24655; Fri, 2 Oct 1992 23:57:11 +1000 (from kasten@ftp.com) Received: by ftp.com id AA17357; Fri, 2 Oct 92 09:57:00 -0400 Date: Fri, 2 Oct 92 09:57:00 -0400 Message-Id: <9210021357.AA17357@ftp.com> To: jnc@ginger.lcs.mit.edu Subject: RE: TOS ( was Re: packet format v. routing architecture ) From: kasten@ftp.com (Frank Kastenholz) Cc: dee@ranger.enet.dec.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu > I'd like to see why the TOS field is a wrong thing > > Oh, it's not absolutely useless (your file transfer example is a case in > point), but the semantics are so limited (it *is* only an 8 bit field :-) > it's just not adequate, really. I mean, you can't say "this application needs > a minimum of 128 Kbit/sec to function" or anything like that in 8 bits... This is why the TOS should be a subset of the general issue of policy and the "TOS Field" should be a number that identifies which policy should be invoked when routing a packet. Policy setup would be some combination of manual policy distribution, standardized conventions (e.g. policy 0 always means "default") and some policy setup protocol. This allows the notions of policy can evolve, along with the protocols required to implement those notions, separate from the Internetwork Protocol. -- frank kastenholz From owner-big-internet@munnari.oz.au Sat Oct 3 00:12:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25557; Sat, 3 Oct 1992 00:12:30 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210021412.25557@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23637; Fri, 2 Oct 1992 23:26:30 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 2586; Fri, 02 Oct 92 09:26:18 EDT Date: Fri, 2 Oct 92 09:26:17 EDT From: yakov@watson.ibm.com To: smart@mel.dit.csiro.au, craig@aland.bbn.com Cc: big-internet@munnari.oz.au Subject: Routing architectures Ref: Your note of Fri, 02 Oct 92 14:08:04 +1000 >TOS is simply the wrong way to do policy based routing. >The only way to do policy-based routing is for the source to >specify the route. Bob, Shall the above be accepted as an axiom :-). And, by the way, what is *exactly* the term "policy-based routing" mean ? I suspect that I am not the only one who are quite interested in getting an answer to this question. May be we should poll the list to solicit people's opinion on what this term means ? As a side comment, let me mention that at the recent ANTF meeting there were about 8 participants in the room. While all 8 agreed that we need "policy-based routing", there were little or no agreement on what exactly "policy-based routing" means. >Suppose you have a TOS field that says "minimize delay". Does that >mean that you are prepared to pay 10 times as much for a 1% reduction >in delay. If not how do you define a TOS field that exactly describes >how much extra you are prepared to pay for various amounts of reduced >delay ? To begin with, rather than looking at bits and bytes in the TOS let's see whether we can come up with an algorithm that would let you perform a multidimensional optimization (e.g. I am willing to pay 5 times more for 50% reduction in delay, but only twice as much for 10% reduction in delay) and be fast enough. After all, if there is no such algorithm, discussion about bits and bytes in the TOS is moot. Yakov. From owner-Big-Internet@munnari.oz.au Sat Oct 3 00:16:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25694; Sat, 3 Oct 1992 00:16:52 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25682; Sat, 3 Oct 1992 00:16:38 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA56358 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Fri, 2 Oct 1992 10:15:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Fri, 2 Oct 1992 10:15:45 -0400 Message-Id: <199210021414.AA33540@home.ans.net> To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: SIP In-Reply-To: (Your message of Thu, 01 Oct 92 23:58:36 PDT.) <92Oct1.235843pdt.10779@skylark.parc.xerox.com> Date: Fri, 02 Oct 92 10:14:22 -0500 From: Phill Gross > : I have seem to have alienated a number of people by my pugnacious response to Noel's message. It was a botched attempt to match Noel's hyperbolic style of argument. ..... I apologize to Noel and to all who were offended, and I will try to be my normal, polite self from now on. Perhaps all of us, (including Noel) should try to apply Stewart's Postulate for Networked Interpersonal Communications -- Be liberal in accepting what you read; be conservative when you respond. Phill From owner-big-internet@munnari.oz.au Sat Oct 3 00:32:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26123; Sat, 3 Oct 1992 00:32:47 +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 AA24292; Fri, 2 Oct 1992 23:44:55 +1000 (from kasten@ftp.com) Received: by ftp.com id AA16909; Fri, 2 Oct 92 09:44:36 -0400 Date: Fri, 2 Oct 92 09:44:36 -0400 Message-Id: <9210021344.AA16909@ftp.com> To: peter@goshawk.lanl.gov Subject: Re: Routing architectures From: kasten@ftp.com (Frank Kastenholz) Cc: craig@aland.bbn.com, jnc@ginger.lcs.mit.edu, yakov@watson.ibm.com, big-internet@munnari.oz.au > Craig, > > Where does the following requirement come from? > > >>> we need an architecture good for at least 20 years. > > I wonder if this is the timeline set by people of our generation > who hope to get by with one last transition before we retire ... > (if so, you could shave a few years off of that estimate as my > contribution towards the RISC approach to network design.) Peter, It is a function of $$$$ and ulcers. It costs money to go to a new protocol. Vendors have to develop the protocol, customers have to upgrade their systems, network operators have to install it in their routers (and maybe rewire parts of the network that might be "illegal" with the new scheme), users have to learn new stuff. In short, it is a major upset. If you change protocols too often, eventually a significant number of people will tell you to get lost -- they'll wait for the Omnipotent Solution to Internetworking which will be along in two or three years and solve all their problems forever :-) -- frank kastenholz From owner-big-internet@munnari.oz.au Sat Oct 3 01:02:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26932; Sat, 3 Oct 1992 01:02:53 +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 AA25382; Sat, 3 Oct 1992 00:06:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23834; Fri, 2 Oct 92 10:06:37 -0400 Date: Fri, 2 Oct 92 10:06:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210021406.AA23834@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, bsimpson@angband.stanford.edu Subject: Re: SIP Cc: jnc@ginger.lcs.mit.edu Sticking to SIP, without all of the bickering Don't get me wrong, I'm not saying SIP is a bad design (it's not), I'm just questioning if this is where we ought to be putting our energy... Noel: - What fields do you need for Nimrod/IDPR? Well, the Nimrod routing architecture can be deployed with just about any packet format (including CLNP, although it might not work as well unless the address semantics are constrained). The current Nimrod deployment plan calls for no packet changes at all to begin with, although, again, any new routing architecture (including Unified, which also is currently a set of protocols) could be deployed in this way. What new fields would Nimrod need in the long run? Hmm, hard to say for sure. Make the source and destination EID's longer, and make provision for lots and long options, and you're probably OK. All the things Nimrod might need (source route, flow id's, etc) can be added as options. - Is the TOS cum Flow field appropriate (yes/no)? Darned if I know; I don't know enough about what the resource allocation guys want. Also, QOS in a larger semantic space has yet to be explored, so I don't know what's needed there either. Again, options are probablyh the way to go unless you are *certain* already that a) you know what you need, and b) it will be in a high enough percentage of the packets to warrant making it a mandatory field. Noel From owner-Big-Internet@munnari.oz.au Sat Oct 3 01:11:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27115; Sat, 3 Oct 1992 01:11: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 AA27111; Sat, 3 Oct 1992 01:11: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, 2 Oct 92 11:11:09 EDT Received: by chiya.bellcore.com (4.1/4.7) id for yakov@watson.ibm.com; Fri, 2 Oct 92 11:11:08 EDT Date: Fri, 2 Oct 92 11:11:08 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9210021511.AA16466@chiya.bellcore.com> To: big-internet@munnari.oz.au, deering@parc.xerox.com, yakov@watson.ibm.com Subject: Re: SIP > > >you'd probably rather run a link-state inter-domain protocol > >rather than a distance-vector one, for all the reasons that LS is > >often preferred over DV (e.g. faster convergence after topology > >changes and lower-overhead event driven updates). > > I suggest that these "often preferred" reasons should be re-examined. > Most of them are based on rather antiquated papers that compare > vanilla Bellman-Ford with SPF. There are at least three papers > I am aware of that suggest that these "reasons" may not apply any more. I want to support what Yakov says here. The popular notion that LS is *significantly* superior to DV in the convergence sense is old thinking and people need to re-assess that in their own minds. Second, it is *definately* true that DV deals with aggregation more easily. I think the best example of this fact is Landmark, which *doesn't work at all* with LS. PX From owner-big-internet@munnari.oz.au Sat Oct 3 01:23:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27313; Sat, 3 Oct 1992 01:23: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 AA26322; Sat, 3 Oct 1992 00:38:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24010; Fri, 2 Oct 92 10:38:09 -0400 Date: Fri, 2 Oct 92 10:38:09 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210021438.AA24010@ginger.lcs.mit.edu> To: kwe2@bbn.com, yakov@watson.ibm.com Subject: Re: You ask "Why a New Routing Architecture?" Cc: big-internet@munnari.oz.au, jnc@ginger.lsc.mit.edu people may use something like SDRP (published as an ID) to do it without any TOS. Again, *no new routing architecture required*. Yakov, just what *is* your definition of a routing architecture? I'm having a hard time figuring out what it must be from the way you characterize things as "new" or "not new". SDRP certainly doesn't look a bit like anything now deployed widely, e.g. BGP, EGP, OSPF, RIP, etc. (I am excepting IDPR, which isn't really in wide-spread service, but is a pretty close match to SDRP.) Noel From owner-big-internet@munnari.oz.au Sat Oct 3 01:39:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27801; Sat, 3 Oct 1992 01:39:34 +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 AA26159; Sat, 3 Oct 1992 00:34:19 +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, 2 Oct 92 10:33:43 EDT Received: by chiya.bellcore.com (4.1/4.7) id for deering@parc.xerox.com; Fri, 2 Oct 92 10:33:41 EDT Date: Fri, 2 Oct 92 10:33:41 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9210021433.AA16324@chiya.bellcore.com> To: craig@aland.bbn.com, deering@parc.xerox.com Subject: Re: Routing architectures Cc: big-internet@munnari.oz.au > > Craig wrote: > > > Well, Noel, I can agree that I think the rush to a new packet format is a bit > > premature. > > Me too. I wouldn't be flogging SIP right now if the IAB/IESF weren't > threatening to pick *some* new packet format by the end of the year. > > Steve > Me three. I think we can (must?) wait a while before committing to a new packet format. While I think Pip has some really good ideas, I would be more comfortable having a year to get it solid rather than a few months. But, much the same can be said for the other proposals, but for different reasons. Pip needs to prove that it is evolvable across multiple potential routing architectures. The other proposals need to prove that the routing architecture they are locking into (by not having as flexible a packet format (ie, a simpler packet format) than Pip) will last us..... I don't think any of us (IPAE, SIP, Pip, TUCAN) are going to be *really* ready to show by November, and I think the wide disparity demonstrated by this routing architecture discussion proves it. But, the November deadline is at least forcing us to work our buns off..... PX From owner-big-internet@munnari.oz.au Sat Oct 3 02:00:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28466; Sat, 3 Oct 1992 02:00:17 +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 AA25885; Sat, 3 Oct 1992 00:23:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23932; Fri, 2 Oct 92 10:23:51 -0400 Date: Fri, 2 Oct 92 10:23:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210021423.AA23932@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, bsimpson@angband.stanford.edu Subject: Re: routing architectures Cc: jnc@ginger.lcs.mit.edu I think that the thrust of "Unified" is heading in the right direction, when it says that the two architectural proposals aren't that far apart. There seems to be a similarity of goals, and differences in the details. By two proposals, I assume you mean IDRP and Nimrod/IDPR? They are very different, including in their goals. Tying a ribbon around the two of them, and labelling the result a design, is not going to change that. If it was felt that the goal set for one was inadequate/inappropriate, the next step should have been to change the goal set and see if the design could be modified organically to meet it. Instead, the goal sets were merged by merging the designs... The current confection reminds me an all all-terrain vehicle with wheels on one side and tracks on the other... But I would prefer that the hop-by-hop be *only* policy-less and anything else be pre-calculated. Actually, the notion of precomputing routing tables for a limited number of common classes of service is a good one. Until I got unhappy about hop-by-hop because of the near-global consistency issue, I rather liked it, and added a similar feature to Nimrod. Also, by "pre-calculated", I assume you mean source routed? The provider/exterior/interior split doesn't do it for me. I really *hate* the single level of administrative domains. I would prefer a dynamic multi-level structure. Yes, *yes*, ***YES***. As far as I can tell, BGP/IDRP/SDRP won't fix that mess, and Nimrod/IDPR claims that it will. I can't verify that Nimrod will do what you want since I didn't quite understand what it was you wanted to do. The Nimrod I read about 7 times over a year. Not light reading. ;-) Yah, yah, I know. I need to split it up into 3 document. I hope you eventually managed to make heads or tails of it; I admit it's pretty radical. If you think it's hard to read, try inventing it! :-) Noel From owner-big-internet@munnari.oz.au Sat Oct 3 02:22:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29074; Sat, 3 Oct 1992 02:22:30 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27999; Sat, 3 Oct 1992 01:45:18 +1000 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA00888; Fri, 2 Oct 92 08:36:00 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA05090; Fri, 2 Oct 1992 11:35:49 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: New routing architecture In-Reply-To: <9210011616.AA19404@ginger.lcs.mit.edu> References: <9210011616.AA19404@ginger.lcs.mit.edu> Cc: big-internet@munnari.oz.au, peter@goshawk.lanl.gov X-Mailer: Poste 2.0 From: David R. Oran Date: Fri, 2 Oct 92 11:35:48 -0400 Message-Id: <921002113548.12546@sneezy.lkg.dec.com> Encoding: 54 TEXT, 6 TEXT SIGNATURE > I would think the term "waste byproduct" would be more appropriate, > actually. What we have is a series of pieces (EGP, BGP, IDRP, RIP, IS-IS, > OSPF, etc) which were only loosly designed to work with each other, and which > require complex 'boxes' to interconnect, the design of which is only now > starting to be formalized (e.g. the BGP-OSPF interactions document). In > general, each router vendor has radically different mechanisms available to > interconnect these various protocols. I would assert that the interaction between ISIS and IDRP is actually quite clean, and would encourage you to read the document (only 6 pages) on the subject which was written by me, Yakov, and Sue Hares, and which is now an ISO working draft. Dave Katz has since made significant contributions which are reflected in the document. You can get it from pub/iso/isisidrp.ps on merit.edu. The approach also demonstrates that you can happily marry ISIS and IDRP without disturbing either protocol and without introducing a lot of extra state into the routers. I know Noel hates the IGP/EGP split, and will undoubtedly make condemning arguments against the techniques in our approach based on that philosophical stance. I'm prepared to defend our technical approach as practical, flexible, and well-specified, and also happy to consider any comments the big-internet community would like to make. > These all fit within a basic framework (the EGP/IGP split) which, > well, I'd better stop there. There is no unified view of the current Internet > routing architecture, and no document which expresses that view. I know Noel hates the IGP/EGP split, and will undoubtedly make condemning arguments against the techniques in our approach based on that philosophical stance. I'm prepared to defend our technical approach as practical, flexible, and well-specified, and also happy to consider any comments the big-internet community would like to make. I am also prepared to argue in favor of the classic IGP/EGP split, since I remain unconvinced that it is a *bad thing*. > The customers keep buying, and if you talk to the vendors they are not > hearing that they need to worry about a new routing architecture. > > The vendors?!?! Don't make me laugh. Their vision is too limited. > Absolutely do we have limited vision! We need to make things that: a) work b) can be delivered before we go bankrupt c) generate revenue d) are better than the guy down the street as opposed to wonderful from some abstract absolutist notion of beauty and truth. I know what I've always thought was the antidote to "limited vision". It's called RESEARCH, and I'm glad there is a lot of it going on in the Internet community. Am I ready to fly in the plane? No. Dave. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Sat Oct 3 02:27:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29179; Sat, 3 Oct 1992 02:28:06 +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 AA29173; Sat, 3 Oct 1992 02:27:39 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA00151; Fri, 2 Oct 92 12:25:49 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA26714; Fri, 2 Oct 92 09:24:43 PDT Message-Id: <9210021624.AA26714@aland.bbn.com> To: peter@goshawk.lanl.gov Cc: Noel Chiappa , yakov@watson.ibm.com, big-internet@munnari.oz.au Subject: re: Routing architectures From: Craig Partridge Date: Fri, 02 Oct 92 09:24:43 -0700 Sender: craig@aland.bbn.com >>>> we need an architecture good for at least 20 years. > > I wonder if this is the timeline set by people of our generation > who hope to get by with one last transition before we retire ... > (if so, you could shave a few years off of that estimate as my > contribution towards the RISC approach to network design.) Peter: Any technology we deploy now will likely still be in heavy use 20 years from now. rom a govt perspective, consider that it takes 20 years for the Navy just to deploy a technology on all its ships. NSA still runs the old ARPANET protocols (not TCP/IP). From a market perspective, it takes the telcos about 20 years to fully deploy new technology. They're in the communications business, so they're probably a good match to our situation. From the computing perspective, I think IBM supports software versions and computer models for about ten years. We're in the game of building infrastructures, so we can't quite change the infrastructure as fast as we can change the computers attached to it. I think 20 years is conservative in terms of required duration. Craig From owner-big-internet@munnari.oz.au Sat Oct 3 04:27:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01518; Sat, 3 Oct 1992 04:27:38 +1000 (from owner-big-internet) Return-Path: Received: from ucsd.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01016; Sat, 3 Oct 1992 03:57:02 +1000 (from tots!tots.Logicon.COM!tep@UCSD.EDU) Received: from tots.UUCP by ucsd.edu; id AA15760 sendmail 5.67/UCSD-2.2-sun via UUCP Fri, 2 Oct 92 10:44:22 -0700 From: tots!tots.Logicon.COM!tep@UCSD.EDU Received: from galt by tots.Logicon.COM (3.2/4.16) id AA13354; Fri, 2 Oct 92 10:04:49 PDT Received: by galt.tots.Logicon.COM (3.2/4.02-client) id AA00598; Fri, 2 Oct 92 10:04:47 PDT Date: Fri, 2 Oct 92 10:04:47 PDT Message-Id: <9210021704.AA00598@galt.tots.Logicon.COM> To: parc.xerox.com!deering@ucsd.EDU Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: Steve Deering's message of Fri, 2 Oct 1992 01:24:39 PDT <92Oct2.012441pdt.10779@skylark.parc.xerox.com> Subject: size and alignment of Hop Limit field in SIP Reply-To: tep@tots.Logicon.COM X-Organization: Logicon, Inc., San Diego, California Both Steve Deering and Thomas Maslen pointed out the fatal flaw in a biased TTL field: it cannot be decremented by 1, and some things *use* small (e.g. 1) TTLs. Oh well, back into lurk mode. Tom Perrine entors will ultimately tell us when we are done. However, having November as a tough deadline is a good way to focus our efforts. Phill From owner-Big-Internet@munnari.oz.au Sat Oct 3 04:42:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01816; Sat, 3 Oct 1992 04:42:56 +1000 (from owner-Big-Internet) Return-Path: Received: from dg-rtp.rtp.dg.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01813; Sat, 3 Oct 1992 04:42:44 +1000 (from throop@dg-rtp.dg.com) Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4.1/dg-rtp-proto) id AA00879; Fri, 2 Oct 1992 14:42:38 -0400 Received: by walrus (5.4.1/140.2) id AA03991; Fri, 2 Oct 1992 13:29:28 -0400 Date: Fri, 2 Oct 1992 13:29:28 -0400 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9210021729.AA03991@walrus> To: big-internet@munnari.oz.au Subject: Re: size and alignment of Hop Limit field in SIP > Subject: Re: size and alignment of Hop Limit field in SIP > In-Reply-To: Your message of "Thu, 01 Oct 92 09:13:52 PDT." > <92Oct1.105919pdt.11616@alpha.xerox.com> > From: Steve Deering > Message-Id: <92Oct2.004902pdt.10779@skylark.parc.xerox.com> > > > That's not quite what I'm saying. I'm saying that it would be a Bad Thing > for the diameter of the Internet to get anywhere near 255 hops. I agree with the desire to keep the diameter of the Internet small. However when policies are taken into effect, the effective diameter may become much larger. Some policies may eliminate large segments of the internet. In effect the packet would have to travel the perimeter because the policy prohibits using the diameter. Dean Throop throop@dg-rtp.dg.com From owner-Big-Internet@munnari.oz.au Sat Oct 3 04:47:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01899; Sat, 3 Oct 1992 04:47:24 +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 AA01895; Sat, 3 Oct 1992 04:47:16 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA29777; Fri, 2 Oct 92 12:46:54 -0600 Received: by goshawk.lanl.gov (4.1/5.17) id AA16538; Fri, 2 Oct 92 12:46:53 MDT Date: Fri, 2 Oct 92 12:46:53 MDT From: peter@goshawk.LANL.GOV (Peter S. Ford) Message-Id: <9210021846.AA16538@goshawk.lanl.gov> To: craig@aland.bbn.com, deering@parc.xerox.com, tsuchiya@thumper.bellcore.com Subject: Re: Routing architectures Cc: big-internet@munnari.oz.au This runs the risk of sounding like a love-in. I believe PIP, SIP, IPAE, Nimrod, Unified and any others should be given *all* the time they need to choose packet formats, get their routing architectures in order, and work on deployment. cheers, peter From owner-Big-Internet@munnari.oz.au Sat Oct 3 05:13:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02222; Sat, 3 Oct 1992 05:13:59 +1000 (from owner-Big-Internet) Return-Path: Received: from IETF.NRI.RESTON.VA.US by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02218; Sat, 3 Oct 1992 05:13:48 +1000 (from gvaudre@NRI.Reston.VA.US) Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa08248; 2 Oct 92 15:07 EDT Mime-Version: 1.0 Content-Type: text/plain; Charset="us-ascii" To: ietf-announce:; From: iesg-secretary@NRI.Reston.VA.US Cc: pip@thumper.bellcore.com, big-internet@munnari.oz.au Subject: WG ACTION: Pip Internet Protocol (pip) Date: Fri, 02 Oct 92 15:07:14 -0400 Sender: gvaudre@NRI.Reston.VA.US Message-Id: <9210021507.aa08248@IETF.NRI.Reston.VA.US> A new working group has been formed in the Internet Area. For more information please contact the working group chairman or the area director. Charter Chair(s): Paul Tsuchiya Internet Area Director(s) Philip Almquist Mailing lists: General Discussion:pip@thumper.bellcore.com To Subscribe: pip-request@thumper.bellcore.com Archive: thumber.bellcore.com:pub/tsuchiya/pip-archive Description of Working Group: The Pip Working Group is chartered to develop an IPv7 proposal using the basic ideas of Pip as described in the Pip overview I-D draft-tsuchiya-pip-overview-01.(ps/txt). Pip is designed on one hand to be very general, being able to handle many routing/addressing/flow paradigms, but on the other hand to allow for relatively fast forwarding. Pip has the potential to allow for better evolution of the internet. In particular, it is hoped that we will be able to advance routing, addressing, and flow techniques without necessarily having to change hosts (once hosts are running Pip). While the Pip overview demonstrates a number of powerful mechanisms, much work remains to be done to bring Pip to a full specification. This work includes, but is not limited to: specifying the header format; specifying a basic set of error messages (PCMP messages); specifying the Pip forwarding rules; specifying host interface messages (particularly the directory service query response); specifying rules for host Pip header construction; specifying modifications to existing protocols for use with Pip (BGP IV, OSPF, ARP, DNS, etc.); specifying Pip MAX MTU Discovery techniques; and specifying a transition strategy for Pip. Over the near term, the goal of the Pip WG will be to produce these specifications and supporting documentation. Over the long term, up to the point where Pip is definitively rejected as IPv7, it is expected that the Pip WG will oversee implementations and testing of the Pip specifications. Except to the extent that the Pip WG modifies existing protocols for operation with Pip, and to the extent that the Pip WG must be aware of routing/addressing/flow architectures to really make Pip general, the Pip WG will not work on routing/addresing/flow architectures. Goals and Milestones: Aug 92 Review and approval of the charter for the PIP Working Group. Sep 92 Post as an Internet Draft a description of the Pip Packet Format and Forwarding Engine, the Pip Control Message Protocol (PCMP), the Pip Host Interface Message Protocol, and the Pip MTU Discovery Protocol Oct 92 Post as an Internet Draft a description of the modifications to BGP IV for Pip, the Modifications to OSPF for Pip, the modifications to DNS for Pip, the modifications to ARP for Pip, the Address assignment in Pip, and the Pip transition strategy. Nov 92 Presentation and review of the PIP specs by the IESG. If acceptable, the first Working Group meeting will be held. From owner-big-internet@munnari.oz.au Sat Oct 3 05:11:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02211; Sat, 3 Oct 1992 05:12:39 +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 AA29686; Sat, 3 Oct 1992 02:43:15 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA29708; Fri, 2 Oct 92 09:42:43 -0700 Received: by us1rmc.bb.dec.com; id AA24235; Fri, 2 Oct 92 12:40:09 -0400 Message-Id: <9210021640.AA24235@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Fri, 2 Oct 92 12:40:10 EDT Date: Fri, 2 Oct 92 12:40:10 EDT From: Ross Callon To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Apparently-To: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: re: Hop Limit field in SIP > ... are you really certain that ten years from now there is no > conceivable way in which a TTL field could hold a value greater > than 255? > Exactly. There speaks an architect... > I would probably actually set the initial default value in the TTL > to be substantially smaller than 256. I just don't want to get > shafted 15 years down the road because the path from one hole > in the wall to another on the other side of the globe is longer > than 255 hops. How many RIP users out there got screwed because > infinity in RIP is fixed at 16? And that was just inside a single > AS... > > Noel One question: Do we think that the current Internet Protocol / Architecture would be able to work in an Internet requiring more than 255 hops? Would things like delays, packet losses, etc add up to enough to cause TCP to break? Ross From owner-big-internet@munnari.oz.au Sat Oct 3 05:45:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02784; Sat, 3 Oct 1992 05:47:39 +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 AA29548; Sat, 3 Oct 1992 02:40:00 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA01277; Fri, 2 Oct 92 12:39:48 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA26782; Fri, 2 Oct 92 09:38:43 PDT Message-Id: <9210021638.AA26782@aland.bbn.com> To: Jon Crowcroft Cc: big-internet@munnari.oz.au Subject: Re: You ask "Why a New Routing Architecture?" In-Reply-To: Your message of Fri, 02 Oct 92 13:39:35 +0100. <9210021240.22282@munnari.oz.au> From: Craig Partridge Date: Fri, 02 Oct 92 09:38:42 -0700 Sender: craig@aland.bbn.com > right - agreed - almost all the time TOS/QOS will affect QUEUEING not > ROUTEING - so it'll be based on qos or tos in packet, per packet, not > per routing update/FIB entry... Jon: But, we will have to pass around some TOS/QOS information in the routing system. One needs to know which way one can travel given that one's TOS/QOS is XXX. My guess is that what we'll do is pass around attributes of each hop (note, this is not blind guessing -- I'm doing some work with Isidro Castineyra that suggests this is possible). So what will happen is that info for each hop will have some additional attributes regarding its load and capabilities. (The particular scheme we're looking at will allow aggregation of attributes so you can advertise attributes for an entire AD as a single "hop"). The routing table doesn't balloon in this scheme. But if one isn't careful, the number of updates could, because a hop's status now changes every time a new flow shows up. (Note, we're working on this problem too -- I suppose the real moral is conservation of problem -- if it ain't a bigger routing table it is an added traffic load :-)). Craig From owner-big-internet@munnari.oz.au Sat Oct 3 06:12:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03136; Sat, 3 Oct 1992 06:13:00 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210022013.3136@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00117; Sat, 3 Oct 1992 03:03:25 +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 ; Fri, 2 Oct 1992 18:02:25 +0100 To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: You ask "Why a New Routing Architecture?" In-Reply-To: Your message of "Fri, 02 Oct 92 09:38:42 PDT." <9210021638.AA26782@aland.bbn.com> Date: Fri, 02 Oct 92 18:02:23 +0100 From: Jon Crowcroft > My guess is that what we'll do is pass around attributes of each >hop (note, this is not blind guessing -- I'm doing some work with Isidro >Castineyra that suggests this is possible). So what will happen is that >info for each hop will have some additional attributes regarding its load >and capabilities. (The particular scheme we're looking at will allow >aggregation of attributes so you can advertise attributes for an entire >AD as a single "hop"). agree - this scales better... > The routing table doesn't balloon in this scheme. But if one isn't >careful, the number of updates could, because a hop's status now changes >every time a new flow shows up. (Note, we're working on this problem too -- but you can do it event driven by new flow being rejected, rather than for each new flow...i.e. qos possible allows for flow admission, and then the "edge" routers need only count the flows per qos... >I suppose the real moral is conservation of problem -- if it ain't a bigger >routing table it is an added traffic load :-)). maybe... jon From owner-big-internet@munnari.oz.au Sat Oct 3 07:03:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04007; Sat, 3 Oct 1992 07:03:42 +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 AA01419; Sat, 3 Oct 1992 04:24:01 +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 5730; Fri, 02 Oct 92 14:23:02 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 0267; Fri, 02 Oct 92 14:23:02 EDT Date: Fri, 02 Oct 92 14:15:00 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: routing architecture To: Gary Scott Malkin , dab@asylum.sf.ca.us Cc: big-internet@munnari.oz.au In-Reply-To: <3027.199210020335@atlas.xylogics.com> Message-Id: <921002.141500.EDT.VALDIS@vtvm1.cc.vt.edu> On Thu, 1 Oct 1992 23:35:23 -0400 Gary Scott Malkin said: >> First, you're assuming a fairly dense use of the address space, denser >> that we've achieved to date. > >Just because we've made sparse use of the address space so far, doesn't >mean we have to do it in the future. It does however mean that we obviously don't know how to use it compactly *now*, and that it would be a Very Bad Idea to design something that depends on it without also having an address-assignment architecture in mind to guarantee compact distribution of bits. In my opinion, such an architecture would make life easier for *any* of the proposals so far. So - anybody want to be a net-hero and design one? (Though I suspect the proper writeup of such a saga would bear a resemblance to a Greek tragedy ;) Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-big-internet@munnari.oz.au Sat Oct 3 07:40:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04574; Sat, 3 Oct 1992 07:40: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 AA01691; Sat, 3 Oct 1992 04:37:24 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11779>; Fri, 2 Oct 1992 11:36:55 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Fri, 2 Oct 1992 11:36:49 -0700 To: Zheng Wang Cc: big-internet@munnari.oz.au, sip@caldera.usc.edu, deering@parc.xerox.com Subject: Re: size and alignment of Hop Limit field in SIP In-Reply-To: Your message of "Fri, 02 Oct 92 02:17:00 PDT." <92Oct2.021708pdt.11521@alpha.xerox.com> Date: Fri, 2 Oct 1992 11:36:35 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct2.113649pdt.10779@skylark.parc.xerox.com> [Note to big-internet readers: I'll continue to send my responses to SIP-related messages to the big-internet list for the next couple of days, with a cc to the sip list, to allow people time to get signed up on the new list (send join request to sip-request@caldera.usc.edu). I suggest that all SIP-specific traffic be confined to the sip list after this weekend.] Zheng wrote: > Since the Hop count is used to loosely enforce the Maximum > Segment Lifetime (MSL), increasing the maximum value of > the Hop count may also have implications to TCP's operation > (e.g. the sequence number wraparound time, TIME-WAIT or > the timestamp resolution in the extended TCP). In SIP, the Hop Limit field is *not* intended to serve any MSL enforcement function. The problem of dealing with long-lived packets is intentionally delegated to the transport layer. Since many routers in the current Internet do not do time-sensitive decrementing of the IP TTL, transport layers cannot currently trust the IP layer to bound packet lifetime. SIP is institutionalizing the current practice. It is much easier to deal with old packets in the transport layer than it is to make the internet layer guarantee a bound on packet lifetime, and it is consistent with the transport protocol's role as the layer that provides reliability over an unreliable datagram layer. Steve From owner-Big-Internet@munnari.oz.au Sat Oct 3 07:48:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04705; Sat, 3 Oct 1992 07:49:11 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210022149.4705@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04690; Sat, 3 Oct 1992 07:48:36 +1000 (from kwe2@BBN.COM) From: "Kent W. England" Subject: Re: You ask "Why a New Routing Architecture?" To: yakov@watson.ibm.com Cc: big-internet@munnari.oz.au In-Reply-To: <9210021214.21488@munnari.oz.au> Date: Fri, 2 Oct 92 17:47:51 EDT Mail-System-Version: >The "proof" you presented for justifying a new routing architecture >requires *only* 1 TOS, "R&E". In the *worst possible case* addition >of one extra TOS will double the size of routing table, so the >"multiplier effect" is equal to 2 (worst case). Use your imagination a little. Imagine, say, four commercial interexchange carriers and the NSFnet, and give the client the ability to select whichever IXC. Looks like a few more on the route multiplier to me. --Kent From owner-big-internet@munnari.oz.au Sat Oct 3 09:15:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06553; Sat, 3 Oct 1992 09:16:17 +1000 (from owner-big-internet) Return-Path: Received: from IETF.NRI.RESTON.VA.US by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02515; Sat, 3 Oct 1992 05:29:27 +1000 (from gvaudre@NRI.Reston.VA.US) Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa08549; 2 Oct 92 15:18 EDT To: Big-Internet@munnari.oz.au Cc: Internet Engineering Steering Group Subject: IESG Plan for Routing and Addressing Date: Fri, 02 Oct 92 15:18:42 -0400 From: Greg Vaudreuil Message-Id: <9210021518.aa08549@IETF.NRI.Reston.VA.US> -------- A New Internet Draft is available from the on-line Internet-Drafts directories. This document will be submitted to the RFC Editor as an Informational document in about one week. Please send any comments to the IESG@nri.reston.va.us or ietf@nri.reston.va.us mailing list. Title : IESG Deliberations on Routing and Addressing Author(s) : P. Gross, P. Almquist Filename : draft-iesg-roadplan-00.txt Pages : 25 This memo summarizes issues surrounding the routing and addressing scalling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the IETF. It also provides a preliminary report of IESG deliberations on how these routing and addressing issues should be pursued in the IAB/IETF. Internet-Drafts are available by anonymous FTP. Login with the username "anonymous" and password "guest". After logging in, Type "cd internet-drafts". "get draft-iesg-roadplan-00.txt". Internet-Drafts directories are located at: o East Coast (US) Address: nnsc.nsf.net (128.89.1.178) o West Coast (US) Address: ftp.nisc.sri.com (192.33.33.22) o Pacific Rim Address: munnari.oz.au (128.250.1.21) o Europe Address: nic.nordu.net (192.36.148.17) Internet-Drafts are also available by mail. Send a message to: mail-server@nisc.sri.com. In the body type: "SEND draft-iesg-roadplan-00.txt". For questions, please mail to internet-drafts@nri.reston.va.us. From owner-big-internet@munnari.oz.au Sat Oct 3 09:39:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07109; Sat, 3 Oct 1992 09:39:45 +1000 (from owner-big-internet) Return-Path: Received: from IETF.NRI.RESTON.VA.US by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02529; Sat, 3 Oct 1992 05:30:56 +1000 (from gvaudre@NRI.Reston.VA.US) Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa08578; 2 Oct 92 15:18 EDT Mime-Version: 1.0 Content-Type: text/plain; Charset="us-ascii" To: ietf-announce:; Cc: ip-encaps@sunroof.eng.sun.com Cc: big-internet@munnari.oz.au From: IESG-Secretary@NRI.Reston.VA.US Subject: WG ACTION: IP Address Encapsulation (ipae) Date: Fri, 02 Oct 92 15:18:53 -0400 Sender: gvaudre@NRI.Reston.VA.US Message-Id: <9210021518.aa08578@IETF.NRI.Reston.VA.US> A new working group has formed in the Internet area. For more information please contact the working group chairman or the area director. IP Address Encapsulation (ipae) Charter Chair(s): Dave Cocker Internet Area Director(s) Philip Almquist Mailing lists: General Discussion:ip-encaps@sunroof.eng.sun.com To Subscribe: ip-encaps-request@sunroof.eng.sun.com Archive: parcftp.xerox.com:/pub/ip-encaps/ Description of Working Group: The IPAE working group seeks to develop a capability for extending IP to support larger addresses while minimizing impact on the installed base of IP users. An enhancement to the current system is mandatory due to the limitations of the current 32 bit IP addresses. IPAE seeks to upgrade the current system, rather than to replace the Internet Protocol. The approach taken will be to sandwhich a small addressing layer, above IP but below TCP or UDP, with the new layer having its own IP Protocol-ID. This special layer will thereby encapsulate new, larger, globally-unique addresses for source and destination, as well as any other fields of information that are considered essential. The specificaton effort will attend to issues of transition and coexistance, among unmodified ``IP'' hosts and hosts which support ``IPAE'' hosts The IPAE approach will develop a framework to organize the Internet into areas called ``IP Addressing Commonwealths'' within which 32-bit IP addresses are unique and are part of a larger, globally-unique Internet addressing scheme. It is a goal of this effort to avoid requiring any router within a Commonwealth to be modified, but any host wishing full Internet connectivity will need to support IPAE eventually. Further, any system wishing to support full, IPAE addresses will need to be modified, including network management software. Goals and Milestones: Done Review and approve the charter at the first WG meeting. Aug 92 Post the initial IPAE specification as an Internet Draft. Aug 92 Post the initial "Addressing" specification as an Internet Draft. Sep 92 Post the "Implementation and Transition" specification as an Internet Draft. Oct 92 Post the report to the IESG as an Internet Draft. Nov 92 Present work of the IPAE working group to the IETF. From owner-big-internet@munnari.oz.au Sat Oct 3 09:52:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07433; Sat, 3 Oct 1992 09:52:34 +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 AA03081; Sat, 3 Oct 1992 06:11:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25872; Fri, 2 Oct 92 16:10:51 -0400 Date: Fri, 2 Oct 92 16:10:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210022010.AA25872@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, tsuchiya@thumper.bellcore.com Subject: Re: SIP Cc: jnc@ginger.lcs.mit.edu Second, it is *definately* true that DV deals with aggregation more easily. Can you explain your thinking behind this claim? I'm having a hard time constructinng it myself... I think the best example of this fact is Landmark, which *doesn't work at all* with LS. I must confess I've forgotten enough of Landmark to not be able to follow this. Can you elucidate? Noel From owner-Big-Internet@munnari.oz.au Sat Oct 3 10:33:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08729; Sat, 3 Oct 1992 10:33:14 +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 AA08723; Sat, 3 Oct 1992 10:33:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01096; Fri, 2 Oct 92 20:33:00 -0400 Date: Fri, 2 Oct 92 20:33:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210030033.AA01096@ginger.lcs.mit.edu> To: callon@bigfut.enet.dec.com, jnc@ginger.lcs.mit.edu Subject: re: Hop Limit field in SIP Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu [would] the current Internet Protocol/Architecture would be able to work in an Internet requiring more than 255 hops? Would things like delays, packet losses, etc add up to enough to cause TCP to break? Ross, answering this question involves making a guess about the future values of some numbers I don't have a clue about. For instance, delays: if we ignore speed of light delays (which are small; light in fiber in about 50% of vacuum, so round the world is maybe 1/3 of a second), it all depends on what switching delays are in future routers. A millisecond? Then that's only another 1/4 second. Packet losses are the same thing; with reasonable congestion control, etc, you shouldn't lose too many packets, but I have no idea what future loss rates will be. One thing I *do* know for sure; we're all gonna look damn stupid the first time a 256 hop path exists, if we make it 8 bits. Bandwidth is going to be dirt cheap; all fields should be *ridiculously* big. Noel From owner-big-internet@munnari.oz.au Sat Oct 3 10:35:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08839; Sat, 3 Oct 1992 10:35:33 +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 AA03691; Sat, 3 Oct 1992 06:48:48 +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, 2 Oct 92 16:46:51 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Fri, 2 Oct 92 16:46:49 EDT Date: Fri, 2 Oct 92 16:46:49 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9210022046.AA17489@chiya.bellcore.com> To: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, tsuchiya@thumper.bellcore.com Subject: Re: SIP > > Second, it is *definately* true that DV deals with aggregation more > easily. > > Can you explain your thinking behind this claim? I'm having a hard time > constructinng it myself... The basic reason is that with LS you have to construct an abstracted topology map. With DV, you just pass on an update but with a smaller mask. While doing topology map abstraction is doable, I think it involves a few tricky points. Like, how do you model a collection of autonomous systems? Do you model the border routers explicitly? If so, do you put N**2 links between them or a pseudo node thing? If not, then do you make the whole AS look like a node? What problems occur if not all the border routers of the AS get configured to represent the AS the same way? What do you do if you have only partial connectivity in your transit AS, and some border routers can't talk to some others? In this case, the pseudo-node model may break, where with DV the right thing happens automatically (some destinations simply are unreachable). > > I think the best example of this fact is Landmark, which *doesn't work at > all* with LS. > > I must confess I've forgotten enough of Landmark to not be able to follow > this. Can you elucidate? > With LM, you advertise individual nodes rather than clusters of things. Since you may advertise one node, but not nodes around it, there are gaps in the topology map, and it doesn't work. With LS, you just pass on distance to the landmark...... PX From owner-big-internet@munnari.oz.au Sat Oct 3 10:44:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09260; Sat, 3 Oct 1992 10:45:19 +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 AA04087; Sat, 3 Oct 1992 07:11:58 +1000 (from Bob.Hinden@eng.sun.com) Received: from Sun.COM by shark.mel.dit.csiro.au with SMTP id AA26798 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 3 Oct 1992 07:11:56 +1000 Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA15192; Fri, 2 Oct 92 14:11:25 PDT Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA00281; Fri, 2 Oct 92 14:11:25 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA01549; Fri, 2 Oct 92 14:07:05 PDT Date: Fri, 2 Oct 92 14:07:05 PDT From: Bob.Hinden@eng.sun.com (Bob Hinden) Message-Id: <9210022107.AA01549@bigriver.Eng.Sun.COM> To: peter@goshawk.LANL.GOV (Peter S. Ford) Cc: big-internet@munnari.oz.au In-Reply-To: <9210021846.AA16538@goshawk.lanl.gov> Subject: Re: Routing architectures Peter, > I believe PIP, SIP, IPAE, Nimrod, Unified and any others should be given > *all* the time they need to choose packet formats, get their routing > architectures in order, and work on deployment. You left CLNP out of your list :-) Bob From owner-big-internet@munnari.oz.au Sat Oct 3 11:03:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10100; Sat, 3 Oct 1992 11:03:15 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210030103.10100@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05005; Sat, 3 Oct 1992 08:02:37 +1000 (from kwe2@BBN.COM) From: "Kent W. England" Subject: IESG Deliberations on ROAD To: big-internet@munnari.oz.au Date: Fri, 2 Oct 92 18:02:07 EDT Mail-System-Version: Did all busy big-internetters see this ID announcement? --Kent -------- Beginning of Forwarded Message(s) --------- To: IETF-Announce: ; From: Internet-Drafts@NRI.Reston.VA.US Subject: ID ACTION:draft-iesg-roadplan-00.txt Date: Fri, 02 Oct 92 11:12:54 -0400 A New Internet Draft is available from the on-line Internet-Drafts directories. This document will be submitted to the RFC Editor as an Informational document in about one week. Please send any comments to the IESG@nri.reston.va.us or ietf@nri.reston.va.us mailing list. Title : IESG Deliberations on Routing and Addressing Author(s) : P. Gross, P. Almquist Filename : draft-iesg-roadplan-00.txt Pages : 25 This memo summarizes issues surrounding the routing and addressing scalling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the IETF. It also provides a preliminary report of IESG deliberations on how these routing and addressing issues should be pursued in the IAB/IETF. -------- End of Forwarded Message(s) --------- From owner-big-internet@munnari.oz.au Sat Oct 3 11:10:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10530; Sat, 3 Oct 1992 11:10:41 +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 AA05006; Sat, 3 Oct 1992 08:02:37 +1000 (from estrin@caldera.usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.1) id AA00199; Fri, 2 Oct 92 15:01:46 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA08549; Fri, 2 Oct 92 14:56:26 PDT Date: Fri, 2 Oct 92 14:56:26 PDT Message-Id: <9210022156.AA08549@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@caldera.usc.edu To: big-internet@munnari.oz.au Subject: sip, routing, etc. Reply-To: estrin@usc.edu 1. Lee Breslau reminded me that in my response re. SIP and Unified I could have also mentioned that longer term it would be nice to put SDRP domain-level source routes in the SIP source route and thereby avoid the encapsulation that we do with IP. But this should not be a problem since SIP handles source routing nicely with its own data type. 2. I think that Yakov was overstating things to say that we dont need anything new in terms of routing architecutre, and therby he implied that SDRP/UNIFIED dont represent anything new in the architecture. I think that they do, both in the basic case, and even more in the ways that they might evolve (flexibly, gracefully, and all the othr words Noel uses when describing this) over the years. I THINK/Hope that what he meant is that we have the basic ideas worked out and they basic parts are not that radical as to be very high risk... 3. I did not bother responding to several other notes because Tony did such a good job responding (i guess Tony speaks for Deborah and Deborah speaks for Yakov :}) 4. IF we are going to define and adopt a new packet format then I think it is worth including the TOS/ID field. I sort of think of it as a "minimalist PIP routing directive". It is important to build this process into the common action of the forwarding engine...which is a goal/idea that PIP embodies and I think SIP could too.. NOW THIS IS ALL too fuzzy to contribute anything new to the discussion. I regreat having no new ideas on this to contribute to progress in defining this aspect of SIP at this point in time. Of course we could mimic this today by peaking at the port IDs. But I agree with others who would like to do something cleaner IF we are going to bother defining a new packet format. From owner-big-internet@munnari.oz.au Sat Oct 3 11:15:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10649; Sat, 3 Oct 1992 11:15:23 +1000 (from owner-big-internet) Return-Path: Received: from asylum.sf.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05146; Sat, 3 Oct 1992 08:11:23 +1000 (from dab@asylum.sf.ca.us) Received: from dab.refuge.asylum.sf.ca.us by asylum.sf.ca.us via PCMAIL with DMSP id AA18080; Fri, 2 Oct 92 18:10:41 -0400 (EDT) Date: Fri, 2 Oct 92 18:10:41 -0400 (EDT) Message-Id: <9210022210.AA18080@asylum.sf.ca.us> To: Gary Scott Malkin Subject: Re: routing architecture From: dab@asylum.sf.ca.us (David Bridgham) Reply-To: dab@asylum.sf.ca.us Cc: big-internet@MUNNARI.OZ.AU Sender: dab@asylum.sf.ca.us Repository: asylum Originating-Client: refuge.asylum.sf.ca.us From: Gary Scott Malkin Subject: routing architecture > First, you're assuming a fairly dense use of the address space, denser > that we've achieved to date. Just because we've made sparse use of the address space so far, doesn't mean we have to do it in the future. You're right but you'd have to convince me why we'd do better this time around. I can believe in a relatively dense use of an end-point identifier space, but once you go to a heirarchical space I think it's going to be used sparsely. In order to reduce overall overhead throughout the system, I'd be willing to accept slightly suboptimal routing for some packets. Is there anything wrong with forcing packets to go up then down? Ah ha. We start from different assumptions and so get different answers. I don't think that the future global network topology is going to map any more closely to a tree than does the current net. In fact, I think it's going to get worse (better?). Therefore the non-optimal routes would be more common and more sub-optimal than I like. If anyone wants to build a backdoor path, or simply wants to know about more things than might otherwise be necessary, they can buy a bigger router which can handle the load. Just don't let them advertise that as a transit route to everyone else. I think calling them "backdoor paths" puts a slant on them that I consider wrong. Those links are just another part of the global network topology. Dave From owner-big-internet@munnari.oz.au Sat Oct 3 12:04:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12203; Sat, 3 Oct 1992 12:04:36 +1000 (from owner-big-internet) Return-Path: Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07199; Sat, 3 Oct 1992 09:42:34 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA04430; Fri, 2 Oct 92 19:43:16 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9210022343.AA04430@wizard.gsfc.nasa.gov> Subject: Re: Request for Bibliography of IPv7 / Big Internet Documents To: big-internet@munnari.oz.au Date: Fri, 2 Oct 92 19:43:15 EDT X-Mailer: ELM [version 2.3 PL11] I have revised my personal bibliography of documents relating to the Big Internet and IPv7 issues. I have included it here for anyone who might be interested. I still believe that something like this should be put in the internet-drafts directory with a name like ipv7.bibliography and that all other IDs relating to this subject should reference this bibliography. It would make finding all the appropriate documents a whole lot easier. -Bill IP Version 7 Bibliography 2 October 1992 Acronym Title/Archive Author(s) ------- ------------- --------- TTF RFC 1287 Clark, D. Towards the Future Internet Chapin, L. Architecture Cerf, V. Braden, R. Hobby, R. nic.ddn.mil:rfc/rfc1287.txt GROWTH RFC 1296 Lottor, M. Internet Growth (1981-1991) nic.ddn.mil:rfc/rfc1296.txt ROAD IESG Deliberations on Routing Gross, P. and Addressing Almquist, P. nnsc.nsf.net:internet-drafts/draft-iesg-roadplan-00.txt IPv7 IP Version 7 IAB nnsc.nsf.net:internet-drafts/draft-iab-ipversion7-00.txt Uv7 TCP/IP: Internet Version 7 Ullmann, R. nnsc.nsf.net:internet-drafts/draft-ullmann-ipv7-00.txt C# A Revision to IP Address Solensky, F. Classifications Kastenholz, F. nnsc.nsf.net:internet-drafts/draft-solensky-csharp-00.txt CIDR RFC 1338 Fuller, V. Supernetting: an Address Li, T. Assignment and Aggregation Yu, J. Strategy Varadhan, K. nic.ddn.mil:rfc/rfc1338.txt Guidelines for IP Address Rekhter, Y. Allocation Li, T. Gerich, E. nnsc.nsf.net:internet-drafts/draft-rekhter-ipaddress-guide-04.txt TUBA RFC 1347 Callon, R. TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing nic.ddn.mil:rfc/rfc1347.txt Use of ISO CLNP in TUBA Piscitello, D. Environments nnsc.nsf.net:internet-drafts/draft-piscitello-clnp-00.txt IPAE A Proposal for IP Address Hinden, R. Encapsulation (IPAE): A Crocker, D. Compatible Version of IP with Large Addresses nnsc.nsf.net:internet-drafts/draft-crocker-ip-encaps-00.txt EIP The Extended Internet Protocol Wang, Z. a long-term solution to Internet address exhaustion nnsc.nsf.net:internet-drafts/draft-wang-extended-ip-00.txt NAT The IP Network Address Tsuchiya, P. Translator (Nat): Preliminary Design nnsc.nsf.net:internet-drafts/draft-tsuchiya-addrtrans-00.txt 2TIER RFC 1335 Wang, Z. A Two-Tier Address Structure Crowcroft, J. for the Internet: A Solution to the Problem of Address Space Exhaustion nic.ddn.mil:rfc/rfc1335.txt PIP Pip: The `P' Internet Protocol Tsuchiya, P. nnsc.nsf.net:internet-drafts/draft-tsuchiya-pip-00.txt Pip Overview and Examples Tsuchiya, P. nnsc.nsf.net:internet-drafts/draft-tsuchiya-pip-overview-01.txt NIMROD The IP Addressing Issue Chiappa, N. nnsc.nsf.net:internet-drafts/draft-chiappa-ipaddressing-00.txt A New IP Routing and Chiappa, N. Addressing Architecture nnsc.nsf.net:internet-drafts/draft-chiappa-routing-00.txt UNIFIED RFC 1322 Estrin, D. A Unified Approach to Rekhter, Y. Inter-Domain Routing Hotz, S. nic.ddn.mil:rfc/rfc1322.txt SIP SIP: A Simple Internet Deering, S. Protocol parcftp.xerox.com:pub/net-research/sip-spec From owner-big-internet@munnari.oz.au Sat Oct 3 12:21:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12697; Sat, 3 Oct 1992 12:21:51 +1000 (from owner-big-internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09028; Sat, 3 Oct 1992 10:40:18 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA15840; Fri, 2 Oct 92 17:40:02 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA03005; Fri, 2 Oct 92 20:40:00 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA21386; Fri, 2 Oct 92 20:38:23 EDT Date: Fri, 2 Oct 92 20:38:23 EDT From: Frank T. Solensky Message-Id: <9210030038.AA21386@fenway.andr.UB.com> To: callon@bigfut.enet.dec.com, jnc@ginger.lcs.mit.edu Subject: re: Hop Limit field in SIP Cc: big-internet@munnari.oz.au >From: Ross Callon > >One question: Do we think that the current Internet Protocol / >Architecture would be able to work in an Internet requiring more >than 255 hops? Would things like delays, packet losses, etc add >up to enough to cause TCP to break? > Sure! The hop-count is be just that -- it's not a indicator of how much _time_ it takes to drop down to zero. In an ideal environment (data structures in cache, quiet lines, etc.), I'd guess it could easily pass through 255 routers in less than a second. -- Frank From owner-Big-Internet@munnari.oz.au Sat Oct 3 14:51:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17382; Sat, 3 Oct 1992 14:51:35 +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 AA17379; Sat, 3 Oct 1992 14:51:28 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA07067; Fri, 2 Oct 92 21:51:02 -0700 Date: Fri, 2 Oct 92 23:23:43 EDT From: "William Allen Simpson" Message-Id: <787.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: You ask "Why a New Routing Architecture?" > >The "proof" you presented for justifying a new routing architecture > >requires *only* 1 TOS, "R&E". In the *worst possible case* addition > >of one extra TOS will double the size of routing table, so the > >"multiplier effect" is equal to 2 (worst case). Are you concern > > yakov, > > right - agreed - almost all the time TOS/QOS will affect QUEUEING not > ROUTEING - so it'll be based on qos or tos in packet, per packet, not > per routing update/FIB entry... > > how many different routes are there (the richest organisation i know > only has triple redundent routes..) > > jon > I wouldn't agree at all. yakov is really using R&E as sort of a restrictor of routing, while jon is talking about queuing service levels (low delay versus throughput versus cost). I expect that there will be a need for much more intersection for routing than yakov expects. For example, even today research folks want their traffic to go over HEPnet or CICnet rather than Michnet to NSFnet, or vice versa, whether that's the most direct route or not, because they "own" it. So I would expect an (P!)*R effect, with P the number of regional providers serving the same region, and R the number of regions. That's a lot bigger table! Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Sat Oct 3 18:33:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24941; Sat, 3 Oct 1992 18:34:08 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210030834.24941@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24932; Sat, 3 Oct 1992 18:33:50 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <18512-0@datanet.tele.fi>; Sat, 3 Oct 1992 10:33:16 +0200 To: yakov@watson.ibm.com Cc: jnc@ginger.lsc.mit.edu, big-internet@munnari.oz.au In-Reply-To: <9210011323.28218@munnari.oz.au> "yakov@watson.ibm.com" Date: Sat, 3 Oct 1992 10:33:16 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi And, by the way, I think quite a few people on this list would really like to hear some good and solid *technical* arguments that will convince them that the Internet needs a brand new routing arcthitecture. Just a comment from an outsider to this discussion. One thing I don't like in the current model is that the interfaces, instead of boxes, are assigned addresses. This is a big mistake and should be corrected in the next version of IP architecture whatever that will be. -- Juha From owner-Big-Internet@munnari.oz.au Sat Oct 3 23:17:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04120; Sat, 3 Oct 1992 23:19:37 +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 AA04032; Sat, 3 Oct 1992 23:17:44 +1000 (from kre) To: Ross Callon Cc: big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of Fri, 02 Oct 92 12:40:10 -0400. <9210021640.AA24235@us1rmc.bb.dec.com> Date: Sat, 03 Oct 92 23:17:36 +1000 Message-Id: <9205.718118256@munnari.oz.au> From: Robert Elz Date: Fri, 2 Oct 92 12:40:10 EDT From: Ross Callon Message-ID: <9210021640.AA24235@us1rmc.bb.dec.com> Do we think that the current Internet Protocol / Architecture would be able to work in an Internet requiring more than 255 hops? Would things like delays, packet losses, etc add up to enough to cause TCP to break? Its intuitively obvious that more hops means more delay, more chance of packet loss, ... but like many intuitively obvious "facts" its not necessarily so. Sure, if you take an existing path, and add an extra hop then delay will increase, and there will be some extra chance of loss, but that's not what happens. Instead, in practice, its often the case that a longer path is an alternate to a shorter one that has worse characteristics (consider 5 ethernets against one 9600 slip link). On delay - if you were to assume 10ms queueing/transit delay (mush more than many common links today), then 255 hops is just 2.55 seconds, and while that's not good, plenty of paths today exist with delays of that magnitude. Its not nice by any means, but things do still work. Packet losses typically occur at the one congested spot on a path, the packet flow will adapt itself to that rate (we can assume that packet losses are usually due to congestion, packets lost due to other causes are rare). Adding an extra hop will only make a difference if that hop happened to be the point of congestion - the total number of hops isn't going to make any difference in practice, all but one (or perhaps two in unusual circumstances) don't matter. So, no, I don't think TCP will break however many hops are installed (if we stop assuming things about MSL anyway). kre From owner-Big-Internet@munnari.oz.au Sat Oct 3 23:23:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04237; Sat, 3 Oct 1992 23:23:48 +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 AA04231; Sat, 3 Oct 1992 23:23:27 +1000 (from kre) To: Juha Heinanen Cc: big-internet@munnari.oz.au In-Reply-To: Your message of Sat, 03 Oct 92 10:33:16 +0200. Date: Sat, 03 Oct 92 23:23:14 +1000 Message-Id: <9211.718118594@munnari.oz.au> From: Robert Elz Date: Sat, 3 Oct 1992 10:33:16 +0200 From: Juha Heinanen One thing I don't like in the current model is that the interfaces, instead of boxes, are assigned addresses. I think you'll find that once the distinction between EID's and addresses is clear, this won't be a problem. EID's belong to endpoints (loosely hosts) and certainly not interfaces. On the other hand, the address says where the host is located, and if a host is muylti-homed its reasonable to have the address select one of those interfaces - just like a building with two street frontages has two addresses (or can have), and while it might be identified as the X building, if you're going to meet someone there, you probably want to identify on which street you'll be waiting when you give the address - andthe route you use to get there will depend on at which address you want to finish. kre From owner-Big-Internet@munnari.oz.au Sun Oct 4 00:32:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08205; Sun, 4 Oct 1992 00:32:55 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210031432.8205@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08191; Sun, 4 Oct 1992 00:32:37 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <19769-0@datanet.tele.fi>; Sat, 3 Oct 1992 16:32:28 +0200 To: kre@munnari.oz.au Cc: big-internet@munnari.oz.au In-Reply-To: <9211.718118594@munnari.oz.au> "kre@munnari.oz.au" Date: Sat, 3 Oct 1992 16:32:28 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi Bob, Even if my house would have two doors to two different streets, I would in most cases want to wait inside and don't care which door the visitor uses. For example I don't want to identify an IBGP peer by any of its interface addresses, since I want to connection to come up even if all others, but one is down. So, I want to identify the box, not its interfaces. Also the current idea that boxes can send packets to each other only if they share a common IP (sub)network number has to be relaxed in the new IP. If my routing protocol has learned about a neighbor and the routes behind it, that should all that is needed for communciation. This is how the CLNP routing model works and even if it may have many deficiencies, this is not certainly one of them. -- Juha From owner-Big-Internet@munnari.oz.au Sun Oct 4 03:30:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14791; Sun, 4 Oct 1992 03:30:48 +1000 (from owner-Big-Internet) Return-Path: Received: from fciad3.bsd.uchicago.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14784; Sun, 4 Oct 1992 03:30:37 +1000 (from karl@ddsw1.mcs.com) Received: by fciad3.bsd.uchicago.edu (/\==/\ Smail3.1.26.7 #26.1) id ; Sat, 3 Oct 92 12:28 CDT Received: by ddsw1.mcs.com (/\==/\ Smail3.1.26.7 #26.5) id ; Sat, 3 Oct 92 11:08 CDT Message-Id: From: karl@ddsw1.mcs.com (Karl Denninger) Subject: re: Hop Limit field in SIP To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Sat, 3 Oct 92 11:08:13 CDT Cc: callon@bigfut.enet.dec.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au In-Reply-To: <9210030033.AA01096@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 2, 92 8:33 pm X-Mailer: ELM [version 2.3 PL11] > [would] the current Internet Protocol/Architecture would be able to work > in an Internet requiring more than 255 hops? Would things like delays, > packet losses, etc add up to enough to cause TCP to break? > > One thing I *do* know for sure; we're all gonna look damn stupid the > first time a 256 hop path exists, if we make it 8 bits. Bandwidth is going > to be dirt cheap; all fields should be *ridiculously* big. Correct. It is just good engineering practice to >overengineer< any value which must be static. Unless there are other variables which affect cost, of course. I don't think that applies here. (A lurker de-lurks!) :-) -- Karl Denninger (karl@ddsw1.MCS.COM, !ddsw1!karl) Data Line: [+1 312 248-0900] Anon. arch. (nuucp) 00:00-06:00 C[SD]T Request file: /u/public/sources/DIRECTORY/README for instructions From owner-Big-Internet@munnari.oz.au Sun Oct 4 09:10:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25477; Sun, 4 Oct 1992 09:10:29 +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 AA25474; Sun, 4 Oct 1992 09:10:26 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA06354 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sun, 4 Oct 1992 09:10:42 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA11029; Sun, 4 Oct 92 09:10:23 EST Message-Id: <9210032310.AA11029@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Splitting the network layer: take 2 Date: Sun, 04 Oct 92 09:10:22 +1000 From: Bob Smart The IESG's requirements give significant emphasis to preserving compatibility as we move forward and to choosing medium term solutions with an eye to long term solutions. In that context I am more convinced than ever of the value of splitting the network layer into a routing layer and an EID-layer. My last proposal on this subject included a concrete proposal (miniPIP), which made it look like it was a PIP-specific proposal. It isn't. So here's another, more general, description of the proposal. 0. Acknowledgements ------------------- I got the idea of preserving IPv4 by making it an EID layer (no routing significance in the addresses) from Noel Chiappa. He used to say we could do that without adding an explicit routing layer but I think I have a message from him retracting that. Anyway I'd certainly like to hear whether the following meets his approval. 1. Addresses and EIDs --------------------- Earlier in 1992 there was a discussion on the Big-Internet list which clearly established the value of separating Addresses (used for routing) from Endpoint Identifiers (EIDs). In PIP these are in separate fields. In TUBA a part of the NSAP is the EID, and each EID can have multiple prefixes. Once you've separated out the roles of Address and EID in your mind, a logical process leads you to ask: why don't these separate concepts correspond to separate layers in the protocol stack? I call these corresponding layers the routing layer and the EID layer. 2. The Routing Layer. --------------------- What goes here is only what is needed for routers to route the packet: i.e. determine what host or router to send it to on what interface and via what queue. But don't routers do lots of other things like: fragment, account, filter? The answer is no, because when they do those things they are not acting as routers but acting in some other capacity. It is a relevant fact that when routers filter or gather statistics they will look arbitrarily deeply into the protocol stack. Does that prove that tcp is at the network layer? Clearly not. 3. The EID Layer ---------------- While this is information of interest to the end-points it can generated by intermediate systems (e.g. fragmentation) and it can be used by intermediate systems in incidental ways (accounting, filtering). 4. IPv4 as an EID layer. ------------------------ If you ignore the fact that IPv4 addresses have structure which is used for routing, then we can regard the following: (transport) (transport) ^ ^ | | v [mechanism unspecified] v IPv4-packet-----------------------IPv4-packet as an EID-layer protocol. Why would we want to do this? We have a tremendous investment in end-system software that handles this format. We have machines that will still be chunking along in 8 years that will never understand anything newer. If we regard IPv4 as an EID layer protocol instead of a full network layer protocol then the 32 bit IPv4 "address" does not need to have the structure which it currently has which is used for routing. That removes the main reason why the address space is used sparsely, which is, in turn, the reason that parts of it are running out. There is an issue about administration of the space, basically due to the way the in-addr.arpa domain work, which prevents 100% use of the 32bit IPv4 EID space. A 50% use is easily achieved and that will mean that 32 bit EIDs will be sufficient for the Internet for the rest of this millennium/century/decade. 5. Routing Layer Fields ----------------------- The things that are required are a. Information to route to the destination b. Information to route error packets back to the source c. next layer protocol: What's the payload? d. loop avoidance (hop count) and/or time based expiration. PIP combines (a) and (b), but a simpler scheme with source and destination addresses is also possible. The next layer protocol field could have possible values: 1 RCMP (=Routing-layer Control Message Protocol) 2 Encapsulated routing layer packet - tunneling is trivial. 3 IPv4 4 CLNP 5 New EID layer for the Internet - to be specified We see in fact that the routing layer protocol can act effectively as a new virtual link layer for any existing connectionless protocol. One might also have routing layer options such as record route, though one could also argue that routers in very high speed networks don't have time for such frivolity. 6. Interfacing existing hosts to a split Network Layer ------------------------------------------------------ While the proposal will work best when end systems understand the Routing layer, one of the key aims is to keep existing IPv4 hosts going. Existing IPv4 hosts understand the meaning of the IPv4 address. How can existing IPv4 host software continue to work with a split network layer? The first thing that has to happen is for the local subnet router to do the route lookup on behalf of the host and encapsulate outgoing IPv4 packets in a Routing layer packet. This process can sometimes be optimized by very small changes in the host software. As Noel pointed out: just change "gethostbyname" or the DNS software to forward routing information derived as part of the DNS lookup to the local subnet router. The decapsulation process at the other end is trivial. But if the IPv4 space is not allocated with the network in mind then won't the host make the wrong decision about whether to ARP for the destination or send to the router? Maybe but it doesn't matter. If it ARPs when the destination is not on the line the router can respond on behalf of the destination (Proxy ARP). If it sends to the router when the destination is on the line then the packet will go an extra hop through the router: not a big deal. The latter inefficiency can be avoided by setting the netmask to 0.0.0.0 on the hosts. Since the router is going to respond to ARP for any IPv4 address it doesn't matter what IPv4 address you use when you configure a router address into a host, as long as it isn't some other host on the wire. And you only have to do that if the host can't be configured to have a netmask of 0.0.0.0. 7. Advantages of the Split -------------------------- a. Dense allocation allows IPv4 packet format to continue for a long time. b. Gives us time to define the new Internet EID layer or use CLNP. c. Can run CLNP with NSAPs with no routing significance as the original definition says. d. Decouple the routing from the stuff the end systems mostly work with so that if we get it wrong and have to change the routing layer it will be less traumatic. Though it will be better to get it right! e. One routing layer to administer allows transport of multiple EID layers. This advantage should not be overstated: if for example the EID layer is CLNP then fragmentation can only happen at intermediate systems which are CLNP-handling intermediate systems as well as routers. 8. Disadvantages of the Split ----------------------------- a. It breaks the 7 layer model :-). [Actually I think if we picked 7 layers today they'd be: Physical, Link, MAC, Routing, EID, Transport, Application.] b. ??? You tell me. Please. Bob Smart From owner-Big-Internet@munnari.oz.au Sun Oct 4 10:44:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29864; Sun, 4 Oct 1992 10:44:50 +1000 (from owner-Big-Internet) Return-Path: Received: from Valinor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29859; Sun, 4 Oct 1992 10:44:45 +1000 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA04377; Sat, 3 Oct 92 17:44:07 -0700 Date: Sat, 3 Oct 92 17:44:07 PDT From: Vince Fuller To: Bob Smart Cc: big-internet@munnari.oz.au Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: Splitting the network layer: take 2 In-Reply-To: Your message of Sun, 04 Oct 92 09:10:22 +1000 Message-Id: YES! I agree that any proposal worthy of serious consideration as IPv7 *must* separate the host-ID function and routing function out of what we now refer to as "addresses". As Noel is so fond of saying, *addresses* (the things that routing uses) are intimately tied to network topology. One thing that bothers me about some of the proposals (SIP, IPAE, TUBA/CLNP, to name a few names) on the table is that, in an effort to please everyone, they are trying to make these creatures called "addresses" be hierarchically (sp?) allocated both geographically and by service provider. This doesn't make sense - addresses (in the NIMROD sense) will always follow network topology, which probably means they will be provider based. This means that they will be dynamic - a given machine may change its address very frequently if the network topology in its immediate vicinity is changing a lot. This also means that any new architecture will either provide hosts with a means of discovering these dynamic addresses or will insure that the hosts don't *care* what they are (i.e. by only letting hosts see endpoint ID's). Again, the distinction between *addresses* and *endpoint-ids* is crucial and should be handled by any serious proposal for IPv7. As Bob Smart pointed-out, the current 32-bit IP numbering space would be quite adequate for quite some time to come if it were assigned solely as endpoint-ids, without regard to routing significance. Using 32-bit endpoint-ids and hiding the routing from hosts will also provide for a relatively painless migration for IPV4 hosts, since they aren't supposed to know much about routing anyway. Just some random ramblings... --Vince From owner-Big-Internet@munnari.oz.au Sun Oct 4 10:50:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00218; Sun, 4 Oct 1992 10:50:57 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210040050.218@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00212; Sun, 4 Oct 1992 10:50:52 +1000 (from jcurran@nic.near.net) To: Bob Smart Cc: big-internet@munnari.oz.au Subject: Re: Splitting the network layer: take 2 In-Reply-To: Your message of Sun, 04 Oct 92 09:10:22 +1000. <9210032310.AA11029@wanda.mel.dit.CSIRO.AU> Date: Sat, 03 Oct 92 20:50:37 -0400 From: John Curran -------- From: Bob Smart Subject: Splitting the network layer: take 2 Date: Sun, 04 Oct 92 09:10:22 +1000 The IESG's requirements give significant emphasis to preserving compatibility as we move forward and to choosing medium term solutions with an eye to long term solutions. In that context I am more convinced than ever of the value of splitting the network layer into a routing layer and an EID-layer. I think a lot of folks are thinking along these lines... PIP, TUBA, (and Nimrod?) have the potential for endpoint identifiers which are free of routing information. IPAE has the same potential if the one-to-one correspondence between the 32-bit address and lower 32 bits of full address was removed. ... The first thing that has to happen is for the local subnet router to do the route lookup on behalf of the host and encapsulate outgoing IPv4 packets in a Routing layer packet. This process can sometimes be optimized by very small changes in the host software. As Noel pointed out: just change "gethostbyname" or the DNS software to forward routing information derived as part of the DNS lookup to the local subnet router. The decapsulation process at the other end is trivial. Having the hosts perform the encapsulation has one major point in its favor: routers do not like to hang on to packets for any length of time. Queue management is sufficiently complicated now that the addition of packets queued for long-wait events (DNS) may create a problem larger than the one we're trying to solve with routing tables. Of course, if the routers have to do the lookup, then doing it at the local network router allows more routers to be involved, and at a lower throughput rate. Deferring the lookup and encapsulation until you're at the border router (where the aggregate throughput requires more memory) might be problematic. /John From owner-Big-Internet@munnari.oz.au Sun Oct 4 18:15:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01023; Sun, 4 Oct 1992 18:15:31 +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 AA00968; Sun, 4 Oct 1992 18:15:06 +1000 (from kre) To: Juha Heinanen Cc: big-internet@munnari.oz.au In-Reply-To: Your message of Sat, 03 Oct 92 16:32:28 +0200. Date: Sun, 04 Oct 92 18:14:56 +1000 Message-Id: <9421.718186496@munnari.oz.au> From: Robert Elz Date: Sat, 3 Oct 1992 16:32:28 +0200 From: Juha Heinanen Even if my house would have two doors to two different streets, I would in most cases want to wait inside and don't care which door the visitor uses. That's fine, but its a different case - you don't care, but your visitor might, and you might want to give directions to a specific street for all kinds of reasons (one of the streets might be a major street, easy to find, but with limited or no parking available, whereas the other may be s small one way thing, difficult to get into, but ideal to park in once located). Being able to actually specify one address or the other can sometimes make a difference - certainly in plenty of other cases they're equivalent and choosing one rather than another is of no special benefit, but if you assume that, and make addressing be independant of the precise final end-point you're losing the capability to handle the odd cases where it really does make a difference. For example I don't want to identify an IBGP peer by any of its interface addresses, since I want to connection to come up even if all others, but one is down. So, I want to identify the box, not its interfaces. Absolutely. The same goes for DNS queries, where the response has to come from the "address" to which the query was sent, and no other - in both of those cases its the EID that you want to identify your peer, not the address. Addresses should be used to get packets through the routers to their destination, and not for just about any other purpose whatever. Also the current idea that boxes can send packets to each other only if they share a common IP (sub)network number has to be relaxed in the new IP. If my routing protocol has learned about a neighbor and the routes behind it, that should all that is needed for communciation. This is how the CLNP routing model works and even if it may have many deficiencies, this is not certainly one of them. Are you intending to say that I could take an NSAP assigned to some box in Aust, and connect it in Finland, and that everything will continue to work, for connections to that box loccally on your net, for connections to the box from the net where the NSAP used to be located, and from random assorted other places? If so, then I don't think such a scheme has a hope of succeeding in a large net (like the internet), while those kinds of odd cases might occur so infrequently initially that the extra routing load to identify them would be negligible (though multiplied zillions of times in every router round the globe), after time, the number of them will grow to an extent where the whole thing just collapses. On the other hand, if you're just saying that an NSAP that is intended to be topologically near your net can be moved into it, and that you can handle that case, or that you can give one cable the NSAP equivalent of two IP sub-net addresses taken from the same net number then I don't think its terribly useful. Its just one more special case with some limited usefulness that is better handled by making it trivially easy for a node to change its address, so the inertia that currently compells you to want to put multiple numbers on one cable evaporates. Making addresses be used only to route packets, and also easy to change (which probably means making them be dynamically allocated by a server, never assigned by a human) are certainly needed to make all this work, that's what I think we should be aiming at. kre From owner-Big-Internet@munnari.oz.au Sun Oct 4 22:41:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21067; Sun, 4 Oct 1992 22:42:05 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210041242.21067@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21060; Sun, 4 Oct 1992 22:41:59 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 8951; Sun, 04 Oct 92 08:41:55 EDT Date: Sun, 4 Oct 92 08:41:54 EDT From: yakov@watson.ibm.com To: kwe2@BBN.COM Cc: big-internet@munnari.oz.au Subject: You ask "Why a New Routing Architecture?" Ref: Your note of Fri, 2 Oct 92 17:47:51 EDT >Use your imagination a little. Imagine, say, four commercial >interexchange carrier and the NSFNet and give the client the >ability to select whichever IXC... Kent, This is quite different from the original problem (discriminating between R&E vs commercial) that you used as a justification for a new architecture. So, what is the problem that you can use as a justification for the new routing architecture ? I can certainly use my imagination. I can imagine even more fancier scenarios, than you described. But the question that needs to be asked is what our imagination has to do with reality. If the problems we used as a justification for a new routing architecture are a product of *our imagination*, then the new routing architecture may only be needed *in our imagination*. Yakov. From owner-Big-Internet@munnari.oz.au Sun Oct 4 22:49:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21745; Sun, 4 Oct 1992 22:49:33 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210041249.21745@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21738; Sun, 4 Oct 1992 22:49:28 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 8961; Sun, 04 Oct 92 08:49:26 EDT Date: Sun, 4 Oct 92 08:49:26 EDT From: yakov@watson.ibm.com To: estrin@usc.edu, big-internet@munnari.oz.au Subject: sip, routing, etc. Ref: Your note of Fri, 2 Oct 92 14:56:26 PDT >Deborah speaks for Yakov.... Yes... Yakov. From owner-Big-Internet@munnari.oz.au Sun Oct 4 23:08:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23271; Sun, 4 Oct 1992 23:08:28 +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 AA23243; Sun, 4 Oct 1992 23:08:08 +1000 (from kre) To: yakov@watson.ibm.com Cc: kwe2@BBN.COM, big-internet@munnari.oz.au Subject: Re: You ask "Why a New Routing Architecture?" In-Reply-To: Your message of Sun, 04 Oct 92 08:41:54 -0400. Date: Sun, 04 Oct 92 23:08:00 +1000 Message-Id: <9530.718204080@munnari.oz.au> From: Robert Elz Date: Sun, 4 Oct 92 08:41:54 EDT From: yakov@watson.ibm.com But the question that needs to be asked is what our imagination has to do with reality. One thing is probably that there are things we'd like to do (call that imagination if you like) that the current architecture prohibits - or more correctly, simply doesn't support. While there's no support, we live without, which you can take as lack of demand if you want, but which isn't really that. Its much like simple TOS routing, which doesn't exist, supposeldy ecause no-one wants it, but really just because it doesn't exist (I'd love to be able to support TOS routing, and get a low(ish) bandwidth terrestrial link to the world for telnet (etc) to supplement the high(ish) bandwidth satellite link). The same goes for extended routing - I would like to be able to direct packets over the CIX, or deliberately to avoid the CIX, or to reach the UK via Amsterdam rather than the normal route, or ... At the minute it just can't be done. kre From owner-Big-Internet@munnari.oz.au Sun Oct 4 23:14:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23792; Sun, 4 Oct 1992 23:14:25 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210041314.23792@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23778; Sun, 4 Oct 1992 23:14:15 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 9011; Sun, 04 Oct 92 09:14:10 EDT Date: Sun, 4 Oct 92 09:14:10 EDT From: yakov@watson.ibm.com To: kre@munnari.oz.au Cc: kwe2@BBN.COM, big-internet@munnari.oz.au Subject: You ask "Why a New Routing Architecture?" Ref: Your note of Sun, 04 Oct 92 23:08:00 +1000 >there are things we'd like to do.... When considering these *things* we also need to look at the following factors: (a) who are "we" that *like to do" (b) how much it is going to cost "to do" (c) who is going to pay the cost (d) given (b) and (c) what is the benefit of "the thing we'd like to do". The above are just some of the factors that would certainly help to correllate our imagination with reality. Yakov From owner-Big-Internet@munnari.oz.au Mon Oct 5 04:27:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02082; Mon, 5 Oct 1992 04:27:58 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02077; Mon, 5 Oct 1992 04:27:54 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA105843 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Sun, 4 Oct 1992 14:27:22 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 4 Oct 1992 14:27:22 -0400 Message-Id: <199210041825.AA04670@home.ans.net> To: bill@wizard.gsfc.nasa.gov (Bill Fink) Cc: big-internet@munnari.oz.au Subject: Re: Request for Bibliography of IPv7 / Big Internet Documents In-Reply-To: (Your message of Fri, 02 Oct 92 19:43:15 EDT.) <9210022343.AA04430@wizard.gsfc.nasa.gov> Date: Sun, 04 Oct 92 14:25:57 -0500 From: Phill Gross I have revised my personal bibliography of documents relating to the Big Internet and IPv7 issues. I have included it here for anyone who might be interested. I still believe that something like this should be put in the internet-drafts directory with a name like ipv7.bibliography and that all other IDs relating to this subject should reference this bibliography. It would make finding all the appropriate documents a whole lot easier. Bill, Why don't you put out a separate I-D containing your bibliography? Alternatively, with your permission, we could merge your bibliography (with credit) into the bibliography given in the recent "IETG Deliberations..." I-D. I think the "IESG Deliberations..." I-D has a pretty good bibliography (since we snatched parts of it already from other sources) but I haven't checked it for completeness against yours. Phill From owner-Big-Internet@munnari.oz.au Mon Oct 5 06:47:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05030; Mon, 5 Oct 1992 06: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 AA05025; Mon, 5 Oct 1992 06:47:09 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06140; Sun, 4 Oct 92 16:47:02 -0400 Date: Sun, 4 Oct 92 16:47:02 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210042047.AA06140@ginger.lcs.mit.edu> To: kwe2@bbn.com, yakov@watson.ibm.com Subject: Re: You ask "Why a New Routing Architecture?" Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu If the problems we used as a justification for a new routing architecture are a product of *our imagination*, then the new routing architecture may only be needed *in our imagination*. Yakov, this may be a good point, but I'm having a hard time deciding one way or the other because you won't provide your definition of what a "routing architecture" is. You clearly have one, since you characterize various things as containing a new one or not. Also, your definition clearly isn't the same one as the one I'm using, since your categorizations make no sense under the definition I am using. Without common terminology, any debate is sort of useless.... Noel From owner-Big-Internet@munnari.oz.au Mon Oct 5 10:53:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12312; Mon, 5 Oct 1992 10:53:36 +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 AA12291; Mon, 5 Oct 1992 10:53:19 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA01930 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 5 Oct 1992 10:53:34 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA16322; Mon, 5 Oct 92 10:53:15 EST Message-Id: <9210050053.AA16322@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: Routing architectures In-Reply-To: Your message of "Fri, 02 Oct 92 09:26:17 EDT." <199210021326.AA24474@shark.mel.dit.csiro.au> Date: Mon, 05 Oct 92 10:53:14 +1000 From: Bob Smart > And, by the way, what > is *exactly* the term "policy-based routing" mean ? I suspect that > I am not the only one who are quite interested in getting an answer to this > question. May be we should poll the list to solicit people's > opinion on what this term means ? I think of it from a mechanical point of view. Elements of a route have characteristics (name-value pairs) and for each characteristic name there is an algorithm for combining the values along the route to give a value for the route. Policy based routing is selecting a route based on these characteristics. Do we need to have a high level definition of policy based routing? An important case is AUP. A "value" for AUP is a set of AUP-names. An AUP-name is associated with some particular written AUP document. There is a partial order among these AUP-names: one may be strictly more restrictive than another. There is a least restrictive AUP-name "NONE". When combining AUP-names to make an AUP you discard AUP-names that are less restrictive than any already in the set. The partial order on AUP-names defines a partial order on AUPs in an obvious way: AUP1 is less (or equal) restrictive than AUP2 if for every name in AUP1 there is a name in AUP2 that is a more restrictive AUP-name. To combine AUPs along a route to get the AUP for a route you do a set union and discard AUP-names that are less restrictive than some other name. Of course NONE always gets thrown out if there is anything else. You can't just do AUP by defining one R&E bit. There are different R&E AUPs. The AARNet AUP is strictly more restrictive than the NSFnet one, for example. > let's see whether we can come up with an algorithm that would > let you perform a multidimensional optimization (e.g. I am willing to > pay 5 times more for 50% reduction in delay, but only twice as much > for 10% reduction in delay) and be fast enough. After all, if there > is no such algorithm, discussion about bits and bytes in the TOS > is moot. Well there are only a finite number of routes from A to B so simple linear search will work. And in fact thinning/abstraction means that the source can only see a small number of approximate routes so it never occurred to me that this was a problem. Of course where you have approximate parts of the route you presumably have a best and a worst value of a characteristic for that approximate part of the route. You can only assume the worst. It would be nice (at some time in the future) if the source could say "I need to get more information about that approximate route to try to improve a characteristic, so I'll connect to the appropriate server, get more information, and build a more detailed route". Before anybody else points it out let me say that a set of AUPs (being the AUPs for all actual routes through an approximate route) does not necessarily have a best and worst case within the set. It does however have a worst AUP that is better than all the AUPs in the set, and a best AUP that is worse than all the AUPs in the set. So the source can't assume that the best and worst values of a characteristic for an approximate route are actually achieved by some actual path in the approximate route. Bob Smart From owner-Big-Internet@munnari.oz.au Mon Oct 5 10:59:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12624; Mon, 5 Oct 1992 10:59:56 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210050059.12624@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12619; Mon, 5 Oct 1992 10:59:48 +1000 (from jcurran@nic.near.net) To: big-internet@munnari.oz.au Cc: iesg@nri.reston.va.us Subject: Re: IESG Deliberations on ROAD Date: Sun, 04 Oct 92 20:59:42 -0400 From: John Curran -------- To: IETF-Announce: ; From: Internet-Drafts@NRI.Reston.VA.US Subject: ID ACTION:draft-iesg-roadplan-00.txt Date: Fri, 02 Oct 92 11:12:54 -0400 A New Internet Draft is available from the on-line Internet-Drafts directories. This document will be submitted to the RFC Editor as an Informational document in about one week. Please send any comments to the IESG@nri.reston.va.us or ietf@nri.reston.va.us mailing list. Title : IESG Deliberations on Routing and Addressing Author(s) : P. Gross, P. Almquist Filename : draft-iesg-roadplan-00.txt Pages : 25 This memo summarizes issues surrounding the routing and addressing scalling problems in the IP architecture, and it provides a brief background of the ROAD group and related activities in the IETF. It also provides a preliminary report of IESG deliberations on how these routing and addressing issues should be pursued in the IAB/IETF. The "roadplan" document contains several generalizations with respect to problems that network operators either currently face or might face during an architecture change. Since I did not see any discussion on the ORAD list, I am curious as to representation of network operators on the IESG. We have to begin to involve vendors, operators, and user groups in the process as soon as possible, or we risk having the results dismissed as non- representative. As this next change to the Internet may not be "optional", we cannot afford to have any communities walk away from the final plan. /John From owner-big-internet@munnari.oz.au Mon Oct 5 12:15:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15180; Mon, 5 Oct 1992 12:15:50 +1000 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14424; Mon, 5 Oct 1992 11:54:07 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 4 Oct 92 18:53:50 -0700 Date: Sun, 4 Oct 92 18:53:50 -0700 From: Tony Li Message-Id: <9210050153.AA22338@lager.cisco.com> To: big-internet@munnari.oz.au Subject: Re: Routing architectures I think of it from a mechanical point of view. Elements of a route have characteristics (name-value pairs) and for each characteristic name there is an algorithm for combining the values along the route to give a value for the route. Policy based routing is selecting a route based on these characteristics. Do we need to have a high level definition of policy based routing? Yes, we do. At the very least, we need to agree on the problem that we're trying to solve, solve it, and then know when we're done. An important case is AUP. A "value" for AUP is a set of AUP-names. An AUP-name is associated with some particular written AUP document. There is a partial order among these AUP-names: one may be strictly more restrictive than another. There is a least restrictive AUP-name "NONE". I don't see the need to create a separate naming problem here. There is simply a set of policies. Unfortunately, each policy is multidimensional, so I don't believe that there is a single global metric for "restrictive", and thus there is no global partial order. On the bright side, each source CAN have such a partial order, but it is entirely local. Well there are only a finite number of routes from A to B so simple linear search will work. There are only a finite number of moves in a chess game. While linear search will work there as well, do you want to wait for it? A policy routing decision (at present) appears to be an arbitrary graph search. Given a graph of outdegree d(G), that makes it something like O(d(G)**n). I would speculate that this is NP-complete. [If anyone has on hand the book that is a catalog of NP-complete problems (Garey & Johnson?), could you please look it up? -- Thanks.] And in fact thinning/abstraction means that the source can only see a small number of approximate routes so it never occurred to me that this was a problem. The point of some of our prior discussion is that you cannot do proper policy routing in the face of thinning/abstraction. Thus you need some way to peer inside the abstraction to see what other routes can be computed. Example: an abstraction for North America might publish the NSFnet AUP as the abstract policy. However, if you can look inside this abstraction, you may find that you may also be permitted to use CIX routes. Of course where you have approximate parts of the route you presumably have a best and a worst value of a characteristic for that approximate part of the route. You can only assume the worst. It would be nice (at some time in the future) if the source could say "I need to get more information about that approximate route to try to improve a characteristic, so I'll connect to the appropriate server, get more information, and build a more detailed route". Exactly. Tony From owner-Big-Internet@munnari.oz.au Mon Oct 5 13:02:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16868; Mon, 5 Oct 1992 13:02:37 +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 AA16863; Mon, 5 Oct 1992 13:02:24 +1000 (from kre) To: Tony Li Cc: big-internet@munnari.oz.au Subject: Re: Routing architectures In-Reply-To: Your message of Sun, 04 Oct 92 18:53:50 -0700. <9210050153.AA22338@lager.cisco.com> Date: Mon, 05 Oct 92 13:02:16 +1000 Message-Id: <9701.718254136@munnari.oz.au> From: Robert Elz Date: Sun, 4 Oct 92 18:53:50 -0700 From: Tony Li Message-ID: <9210050153.AA22338@lager.cisco.com> There are only a finite number of moves in a chess game. While linear search will work there as well, do you want to wait for it? Probably not - but I would like to be able to decide for myself how long I want to wait to fulfill my particular policy requirements. If I have no policy, then I get a simple graph traversal that we know how to do, as I add policy constraints things get harder, and still harder if I make the constraints more binding (ie: "prefer a low delay route" isn't too hard to find, but "must find lowest delay route" is substantially harder). In order to give myself the opportunity to decide how much effort I will take to satisfy my particular policy (and hence in most cases whether perhaps I should change my policies a bit) I need to know all the policy information there is out there. That is, we shouldn't do any thinning at all. Fortunately, policies tend to be fairly large scale things, which change infrequently - that is, there aren't that many (maybe hundreds) and they change on a frequency of weeks to months max - which means the burden of distributing the policy type information everywhere need not be great. I don't need to know the status of every link inside NEARnet to know the NEARnet AUP for example (I don't even need to know the existance of all the routes - path thinning can still be done). Where there is some particular fine grained policy that pertains to information (paths) that needs to be thinned away, an indication of the type of policy information that's been lost can be provided, and those who need to know it to successfully route can ask for the details, others can avoid it. kre From owner-Big-Internet@munnari.oz.au Mon Oct 5 13:26:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17779; Mon, 5 Oct 1992 13:26:48 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17770; Mon, 5 Oct 1992 13:26:39 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA14938 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Sun, 4 Oct 1992 23:26:12 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 4 Oct 1992 23:26:12 -0400 Message-Id: <199210050324.AA20155@home.ans.net> To: John Curran Cc: big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: Re: IESG Deliberations on ROAD In-Reply-To: (Your message of Sun, 04 Oct 92 20:59:42 D.) <9210050059.12624@munnari.oz.au> Date: Sun, 04 Oct 92 23:24:47 -0500 From: Phill Gross We have to begin to involve vendors, operators, and user groups in the process as soon as possible, or we risk having the results dismissed as non representative. John, I certainly agree, wholeheartedly. Would you be willing to help us organize better input from operators? Phill From owner-Big-Internet@munnari.oz.au Mon Oct 5 14:42:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21672; Mon, 5 Oct 1992 14:43:02 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21669; Mon, 5 Oct 1992 14:42:51 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 4 Oct 92 21:42:47 -0700 Date: Sun, 4 Oct 92 21:42:47 -0700 From: Tony Li Message-Id: <9210050442.AA23659@lager.cisco.com> To: kre@munnari.oz.au Cc: big-internet@munnari.oz.au In-Reply-To: Robert Elz's message of Mon, 05 Oct 92 13:02:16 +1000 <9701.718254136@munnari.oz.au> Subject: Routing architectures Probably not - but I would like to be able to decide for myself how long I want to wait to fulfill my particular policy requirements. This is a non-problem as the route computation is done entirely by your local policy routing box. You can, conceptually, have it spend very little or lots of time picking a perfect route. You (or your vendor) get to "program" whatever knobs you want. In order to give myself the opportunity to decide how much effort I will take to satisfy my particular policy (and hence in most cases whether perhaps I should change my policies a bit) I need to know all the policy information there is out there. That is, we shouldn't do any thinning at all. Fortunately, policies tend to be fairly large scale things, which change infrequently - that is, there aren't that many (maybe hundreds) and they change on a frequency of weeks to months max - which means the burden of distributing the policy type information everywhere need not be great. It is true that it is possible to distribute a large (non-thinned) policy database in a semi-static fashion. [Yakov wants to cut a CD. I can see it now: "The Internet's greatest policy hits" only $19.95 from Ronco. ;-)] For this to scale, however, it does need to be backed by a hierarchical system for discovering if a policy route works, and if it fails (either due to a policy change or due to topology change), why it failed. In any case, whether or not you have a perfect map, you will still want to precompute certain policy routes that you are likely to use frequently and have the ability to compute new routes on-demand in something less than geological time. Where there is some particular fine grained policy that pertains to information (paths) that needs to be thinned away, an indication of the type of policy information that's been lost can be provided, and those who need to know it to successfully route can ask for the details, others can avoid it. Exactly. Tony From owner-Big-Internet@munnari.oz.au Mon Oct 5 16:19:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24676; Mon, 5 Oct 1992 16:19:39 +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 AA24673; Mon, 5 Oct 1992 16:19:36 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA07106 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 5 Oct 1992 16:19:53 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA17673; Mon, 5 Oct 92 16:19:33 EST Message-Id: <9210050619.AA17673@wanda.mel.dit.CSIRO.AU> To: Tony Li Cc: big-internet@munnari.oz.au Subject: Re: Routing architectures In-Reply-To: Your message of "Sun, 04 Oct 92 18:53:50 MST." <9210050153.AA22338@lager.cisco.com> Date: Mon, 05 Oct 92 16:19:31 +1000 From: Bob Smart > Unfortunately, each policy is >multidimensional, so I don't believe that there is a single global >metric for "restrictive", and thus there is no global partial order. A partial order on a set doesn't require that any two members of the set be comparable: that's a total order. I deliberately said "partial order" to make the point that 2 AUPs may be such that neither can be characterized as more restrictive than the other. >The point of some of our prior discussion is that you cannot do proper >policy routing in the face of thinning/abstraction. Unless your abstraction parallels policy, which it is likely to do. In fact setting it up to parallel policy is likely to be a design goal when setting up the hierarchical routing. In PIP for example each backbone is likely to have exactly one AUP. Yes backbones which include paths with different AUPs will not be handled well by source based policy routing: is that likely to be a problem in real life? Bob Smart From owner-Big-Internet@munnari.oz.au Mon Oct 5 16:36:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25265; Mon, 5 Oct 1992 16:36:49 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25260; Mon, 5 Oct 1992 16:36:43 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 4 Oct 92 23:36:31 -0700 Date: Sun, 4 Oct 92 23:36:31 -0700 From: Tony Li Message-Id: <9210050636.AA25267@lager.cisco.com> To: smart@mel.dit.csiro.au Cc: big-internet@munnari.oz.au In-Reply-To: Bob Smart's message of Mon, 05 Oct 92 16:19:31 +1000 <9210050619.AA17673@wanda.mel.dit.CSIRO.AU> Subject: Routing architectures A partial order on a set doesn't require that any two members of the set be comparable: that's a total order. I deliberately said "partial order" to make the point that 2 AUPs may be such that neither can be characterized as more restrictive than the other. I understand this. I'm trying to make a different distinction: any partial order that you impose on policies may not match my partial order. The net result is that you can't effectively do any abstraction of policy in the general case. Unless your abstraction parallels policy, which it is likely to do. In fact setting it up to parallel policy is likely to be a design goal when setting up the hierarchical routing. In PIP for example each backbone is likely to have exactly one AUP. Yes backbones which include paths with different AUPs will not be handled well by source based policy routing: is that likely to be a problem in real life? An excellent question. Should policy routing allow for more granularity than a domain? Those who object to the IGP/EGP split must say yes.... Tony From owner-Big-Internet@munnari.oz.au Mon Oct 5 18:06:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27948; Mon, 5 Oct 1992 18:06:39 +1000 (from owner-Big-Internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27943; Mon, 5 Oct 1992 18:06:32 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA04333); Mon, 5 Oct 92 03:06:24 CDT Received: by san-miguel.is.rice.edu (AA20227); Mon, 5 Oct 92 03:06:22 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9210050806.AA20227@san-miguel.is.rice.edu> Subject: Re: IESG Deliberations on ROAD To: pgross@ans.net (Phill Gross) Date: Mon, 5 Oct 92 3:06:21 CDT Cc: big-internet@munnari.oz.au, iseg@nri.reston.va.us In-Reply-To: <199210050324.AA20155@home.ans.net>; from "Phill Gross" at Oct 4, 92 11:24 pm X-Mailer: ELM [version 2.3 PL11] Of course, you might want to ask the ORAD group directly. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-Big-Internet@munnari.oz.au Mon Oct 5 20:06:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01459; Mon, 5 Oct 1992 20:06:31 +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 AA01454; Mon, 5 Oct 1992 20:06:13 +1000 (from kre) To: Tony Li Cc: smart@mel.dit.csiro.au, big-internet@munnari.oz.au Subject: Re: Routing architectures In-Reply-To: Your message of Sun, 04 Oct 92 23:36:31 -0700. <9210050636.AA25267@lager.cisco.com> Date: Mon, 05 Oct 92 20:06:05 +1000 Message-Id: <9798.718279565@munnari.oz.au> From: Robert Elz Date: Sun, 4 Oct 92 23:36:31 -0700 From: Tony Li Message-ID: <9210050636.AA25267@lager.cisco.com> An excellent question. Should policy routing allow for more granularity than a domain? Those who object to the IGP/EGP split must say yes.... I'm not going to answer the question, as at the minute I have no good handle on that, however.... The IGP/EGP split is a nonsense, I think that some people hang onto it through inertia, or perhaps fear of what might happen if it were removed. In this part of the world we're part of one AS that takes in the entirety of 5 countries, plus a non-trivial part of the US. There's no EGP (in the conceptual sense, not just the protocol of the same name), and everything works just fine. Now this doesn't mean that there is no policy, or no policy differences, it certainly doesn't mean that we all trust any old garbage we hear from one another (either between countries, or internally), nor does it mean that we're all running one IGP protocol, there are at least 3. All that's missing is the absurd administrative barrier constructed at a fixed place, with the requirement of a magic special protocol to get through - instead we put in barriers wherever needed, move them about as necessary, and use whatever protocol we like to get through. kre From owner-Big-Internet@munnari.oz.au Mon Oct 5 21:02:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03074; Mon, 5 Oct 1992 21:02:51 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210051102.3074@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03071; Mon, 5 Oct 1992 21:02:46 +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 ; Mon, 5 Oct 1992 12:02:27 +0100 To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: size and alignment of Hop Limit field in SIP In-Reply-To: Your message of "Fri, 02 Oct 92 11:36:35 PDT." <92Oct2.113649pdt.10779@skylark.parc.xerox.com> Date: Mon, 05 Oct 92 12:02:25 +0100 From: Zheng Wang >> Since the Hop count is used to loosely enforce the Maximum >> Segment Lifetime (MSL), increasing the maximum value of >> the Hop count may also have implications to TCP's operation >> (e.g. the sequence number wraparound time, TIME-WAIT or >> the timestamp resolution in the extended TCP). > >In SIP, the Hop Limit field is *not* intended to serve any MSL enforcement >function. The problem of dealing with long-lived packets is intentionally >delegated to the transport layer. I agree - this is why I used "loosely" in the above sentence. But without the help of the Hop count or Hop limit field, it would be very difficult for transport layer to make any assumption about the possible lifetime of a packet. It is the Hop limit field which eliminates the packets dragged into loop within a reasonable time. Cheers Zheng From owner-Big-Internet@munnari.oz.au Mon Oct 5 22:31:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05818; Mon, 5 Oct 1992 22:31:36 +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 AA05805; Mon, 5 Oct 1992 22:31:15 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA17006; Mon, 5 Oct 1992 13:32:06 +0100 Message-Id: <199210051232.AA17006@mitsou.inria.fr> To: Robert Elz Cc: Ross Callon , big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of "Sat, 03 Oct 92 23:17:36 +1000." <9205.718118256@munnari.oz.au> Date: Mon, 05 Oct 92 13:32:05 -0500 From: Christian Huitema X-Mts: smtp >On delay - if you were to assume 10ms queueing/transit delay >mush more than many common links today), then 255 hops is >just 2.55 seconds, and while that's not good, plenty of paths >today exist with delays of that magnitude. Its not nice by >any means, but things do still work. Besides, that is by no mean worse than sending a packet to Mars and back. And controlling transmission between spacecrafts and Earth should certainly be doable with TCP. Or TCP++. However, it seems that you miss Steve's strongest argument. Suppose the "diameter" of the Internet becomes so large that you need, say, 50000 hops. Then, what is exactly the rationale for counting the hops in the packets? The hop count, as it stands now, serves one purpose: eliminating loopers. Obviously, if the only way to eliminate loopers is to let them make 50000 hops, we have a serious problem. Maybe we should stop and think seriously here. What is a hop? What do we control? Maybe we should use a hierarchy of counters, e.g. nb of hops within AS + nb of AS crossed -- which would mean listing the "current AS ID" within the header. Or maybe we should use encapsulation for long paths, e.g. check that you get to in less than 36 hops, then use new header to get to in less than 254 hops... Just thinking. But not quite ready to swallow a 16 bits "hop count". Christian Huitema From owner-Big-Internet@munnari.oz.au Mon Oct 5 22:31:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05822; Mon, 5 Oct 1992 22:31:37 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210051231.5822@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05812; Mon, 5 Oct 1992 22:31:31 +1000 (from jcurran@nic.near.net) To: Phill Gross Cc: big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: Re: IESG Deliberations on ROAD In-Reply-To: Your message of Sun, 04 Oct 92 23:24:47 -0500. <199210050324.AA20155@home.ans.net> Date: Mon, 05 Oct 92 08:31:11 -0400 From: John Curran -------- ] From: Phill Gross ] Subject: Re: IESG Deliberations on ROAD ] Date: Sun, 04 Oct 92 23:24:47 -0500 ] ] We have to begin to involve vendors, operators, and user groups in the ] process as soon as possible, or we risk having the results dismissed as ] non-representative. ] ] John, ] ] I certainly agree, wholeheartedly. ] ] Would you be willing to help us organize better input from operators? Sure, but let me restate the point to make sure we're in sync: The difficulty is not with getting input from the network operators, vendors, or end-users per se, but with how to handle such input. It's important (when documents such as the IESG deliberations or the IAB IPv7 come out) to recognize that they do not represent "The" decision criteria unless they represent the communities that must deploy the change. Now it's quite possible that the IESG deliberations have incorporated such input and the document is the ultimate criteria for the selection of the next generation architecture. I wasn't sure where the operational input came from, hence my previous query on the representation. I think that there will be plenty of forums for getting such input (the recent regional tech's meeting at Ann Arbor, ORAD and FARnet all come to mind) but the input either has to be incoporated into the relevant documents, or we have to accept multiple criteria (and potentially multiple decisions) for the future. /John From owner-Big-Internet@munnari.oz.au Mon Oct 5 22:40:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06074; Mon, 5 Oct 1992 22:40:47 +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 AA06069; Mon, 5 Oct 1992 22:40:36 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA12105; Mon, 5 Oct 92 06:40:32 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA27477; Mon, 5 Oct 92 06:40:29 MDT Message-Id: <9210051240.AA27477@goshawk.lanl.gov> To: Bob.Hinden@eng.sun.com (Bob Hinden) Cc: big-internet@munnari.oz.au Subject: Re: Routing architectures In-Reply-To: Your message of Fri, 02 Oct 92 14:07:05 -0700. <9210022107.AA01549@bigriver.Eng.Sun.COM> Date: Mon, 05 Oct 92 06:40:28 MST From: peter@goshawk.lanl.gov >>> You left CLNP out of your list :-) >>> Bob Bob, I just didn't want to trivialize other efforts since for CLNP: The packet format is an international, voluntary standard and has been for quite a while. The routing architecture exists. The Internet is actively deploying CLNP. The IETF has an active group working on CLNP operational issues. Given all this, one might wonder what the IESG is going to deliberate on wrt TUBA. cheers, peter From owner-Big-Internet@munnari.oz.au Mon Oct 5 22:55:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06587; Mon, 5 Oct 1992 22:55:22 +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 AA06576; Mon, 5 Oct 1992 22:55:11 +1000 (from milan@mjm.xyplex.com) Received: from mjm.xyplex.com by xap.xyplex.com id ; Mon, 5 Oct 92 08:53:03 -0500 Received: by mjm.xyplex.com (4.1/SMI-4.1) id AA04505; Mon, 5 Oct 92 08:55:46 EDT Date: Mon, 5 Oct 92 08:55:46 EDT From: milan@mjm.xyplex.com (Milan Merhar) Message-Id: <9210051255.AA04505@mjm.xyplex.com> To: pgross@ans.net Cc: deering@parc.xerox.com, big-internet@munnari.oz.au In-Reply-To: Phill Gross's message of Fri, 02 Oct 92 10:14:22 -0500 <199210021414.AA33540@home.ans.net> Subject: SIP Another citation for your scrapbook..... -------------------------------- Return-Path: To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: SIP In-Reply-To: (Your message of Thu, 01 Oct 92 23:58:36 PDT.) <92Oct1.235843pdt.10779@skylark.parc.xerox.com> Date: Fri, 02 Oct 92 10:14:22 -0500 From: Phill Gross > : I have seem to have alienated a number of people by my pugnacious response to Noel's message. It was a botched attempt to match Noel's hyperbolic style of argument. ..... I apologize to Noel and to all who were offended, and I will try to be my normal, polite self from now on. Perhaps all of us, (including Noel) should try to apply Stewart's Postulate for Networked Interpersonal Communications -- Be liberal in accepting what you read; be conservative when you respond. Phill From owner-Big-Internet@munnari.oz.au Mon Oct 5 23:02:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06851; Mon, 5 Oct 1992 23:02:50 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210051302.6851@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06846; Mon, 5 Oct 1992 23:02:39 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5101; Mon, 05 Oct 92 09:02:32 EDT Date: Mon, 5 Oct 92 09:02:32 EDT From: yakov@watson.ibm.com To: smart@mel.dit.csiro.au, big-internet@munnari.oz.au Subject: Routing architectures Ref: Your note of Mon, 05 Oct 92 10:53:14 +1000 >Well there are only a finite number of routes from A to B so >simple linear search will work. Bob, I guess you are suggesting an exhaustive search as an *appropriate* technique for an optimization problem. Is that correct ? Yakov From owner-Big-Internet@munnari.oz.au Mon Oct 5 23:21:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07405; Mon, 5 Oct 1992 23:21:27 +1000 (from owner-Big-Internet) Received: from thor.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07402; Mon, 5 Oct 1992 23:21:17 +1000 (from henryc@oar.net) Return-Path: Received: by thor.oar.net (5.64+IDA+kva/901023.16) id AA26886; Mon, 5 Oct 92 09:21:06 -0400 Date: Mon, 5 Oct 92 09:21:06 -0400 From: henryc@oar.net Message-Id: <9210051321.AA26886@thor.oar.net> To: peter@goshawk.lanl.gov Subject: Re: Routing architectures Cc: big-internet@munnari.oz.au >Bob, I just didn't want to trivialize other efforts since for CLNP: > > The packet format is an international, voluntary standard and > has been for quite a while. > > The routing architecture exists. > > The Internet is actively deploying CLNP. > > The IETF has an active group working on CLNP operational issues. > >Given all this, one might wonder what the IESG is going to deliberate on >wrt TUBA. Hold on, Peter. Just who is deploying CLNP? How many regionals are actually pushing CLNP traffic? I'd be willing to bet a fair sized greenback that I can count on less than one hand the number of regionals actually routing CLNP traffic. Can we have a show of hands of the networks actually running CLNP traffic across their backbone on a daily basis in a "production" mode? Henry From owner-Big-Internet@munnari.oz.au Mon Oct 5 23:56:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08582; Mon, 5 Oct 1992 23:56:33 +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 AA08575; Mon, 5 Oct 1992 23:56:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08521; Mon, 5 Oct 92 09:55:55 -0400 Date: Mon, 5 Oct 92 09:55:55 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210051355.AA08521@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, kre@munnari.oz.au Subject: Re: Hop Limit field in SIP Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Then, what is exactly the rationale for counting the hops in the packets? The hop count, as it stands now, serves one purpose: eliminating loopers. A most excellent point. What's important is the goal (eliminating looping packets), *not* the mechanism (hop count). This is the kind of analysis we need! Musing on this brings a thought; in a pure datagram system, we seem to have traded off state in the routers (bad?) for state in the packets (good?). It seems like you have to have a certain amount of state; the only question is whether it is per packet or in the routers. As the system gets larger and more complex, you probably need more complex state, which means that either a) the packets get more complex (i.e. more expensive to process), or b) you put more state in the routers. Hmmm.... Right at the moment, though, I'm sort of stumped as to another simple way to do what the hop count does, though. The heirarchy of counters, while workable, seems too complex; the overhead of updating each packet would be considerable. The virtue of the hop count is that it is very simple and efficient to implement. Perhaps we could be really radical, and in a flow/source-route based system, just drop loop detection altogether, on the grounds that they 'cannot' happen? (I know, I know, famous last words... :-) Noel From owner-Big-Internet@munnari.oz.au Mon Oct 5 23:58:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08655; Mon, 5 Oct 1992 23:58:10 +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 AA08649; Mon, 5 Oct 1992 23:58:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08545; Mon, 5 Oct 92 09:57:53 -0400 Date: Mon, 5 Oct 92 09:57:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210051357.AA08545@ginger.lcs.mit.edu> To: Bob.Hinden@eng.sun.com, peter@goshawk.lanl.gov Subject: Re: Routing architectures Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Given all this, one might wonder what the IESG is going to deliberate on wrt TUBA. The fact that full deployment of this solution implies major changes to every item of the infrastructure, including all the hosts, to get us a system with capabilities only marginally greater than the one we have now. Noel From owner-Big-Internet@munnari.oz.au Tue Oct 6 00:20:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09840; Tue, 6 Oct 1992 00:20:22 +1000 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09833; Tue, 6 Oct 1992 00:20:09 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA25120; Mon, 5 Oct 92 07:20:01 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA03855; Mon, 5 Oct 92 10:20:00 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA23564; Mon, 5 Oct 92 10:18:17 EDT Date: Mon, 5 Oct 92 10:18:17 EDT From: Frank T. Solensky Message-Id: <9210051418.AA23564@fenway.andr.UB.com> To: henryc@oar.net, peter@goshawk.lanl.gov Subject: Re: Routing architectures Cc: big-internet@munnari.oz.au >From: henryc@oar.net > >Hold on, Peter. Just who is deploying CLNP? How many regionals are actually >pushing CLNP traffic? ... Can we have a show of hands of the networks >actually running CLNP traffic across their backbone on a daily basis in a >"production" mode? > More specifically, how _much_ traffic? Describing it as a percentage of the total would probably make it appear to be less significant that it should be while simply saying "we have it" may overemphasize it if noone's using it.. -- Frank From owner-Big-Internet@munnari.oz.au Tue Oct 6 00:41:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10527; Tue, 6 Oct 1992 00:42:04 +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 AA10522; Tue, 6 Oct 1992 00:41:58 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA17115; Mon, 5 Oct 92 07:41:48 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA08292; Mon, 5 Oct 1992 10:41:41 -0400 Subject: Re: Routing architectures To: big-internet@munnari.oz.au X-Mailer: Poste 2.0 From: David R. Oran Date: Mon, 5 Oct 92 10:41:29 -0400 Message-Id: <921005104129.12546@sneezy.lkg.dec.com> Encoding: 12 TEXT, 6 TEXT SIGNATURE Sometimes it helps to have an example or two of something you want to define. I would offer ISO/TR9575 - the OSI Routeing Framework as an example of a "routing architecture". By saying this I am not necessarily defending it as a great routing architecture. I just trying to move the discussion off the meta plane and onto something more productive than sniping at each other about whether or not some proposal constitutes a routing architecture or not. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Tue Oct 6 01:11:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11476; Tue, 6 Oct 1992 01:11:34 +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 AA11473; Tue, 6 Oct 1992 01:11:27 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA16486; Mon, 5 Oct 92 09:11:21 -0600 Received: by goshawk.lanl.gov (4.1/5.17) id AA28479; Mon, 5 Oct 92 09:11:18 MDT Date: Mon, 5 Oct 92 09:11:18 MDT From: peter@goshawk.LANL.GOV (Peter S. Ford) Message-Id: <9210051511.AA28479@goshawk.lanl.gov> To: jnc@ginger.lcs.mit.edu Subject: Re: Routing architectures Cc: big-internet@munnari.oz.au Noel, Who is the IESG to decide if people on the Internet (who can and are running CLNP by the way, lest the IESG and others forget this) should use TUBA to intercommunicate? Does the IESG deliberate as to whether or not people should tunnel appletalk? Note: My question was intended to determine the scope of the IESG's deliberation. I hope that if there are any major changes to the Internet architecture that those changes are widely considered, critically examined, and experimented with in the Internet tradition. >>> to get us a system with >>> capabilities only marginally greater than the one we have now. If scaling the Internet to the design requirement has been determined to be marginal then what is the big deal? cheers, peter From owner-big-internet@munnari.oz.au Tue Oct 6 01:12:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11492; Tue, 6 Oct 1992 01:12:52 +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 AA07295; Mon, 5 Oct 1992 23:18:02 +1000 (from kre) To: Christian Huitema Cc: big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of Mon, 05 Oct 92 13:32:05 -0500. <199210051232.AA17006@mitsou.inria.fr> Date: Mon, 05 Oct 92 23:17:52 +1000 Message-Id: <9889.718291072@munnari.oz.au> From: Robert Elz Date: Mon, 05 Oct 92 13:32:05 -0500 From: Christian Huitema Message-ID: <199210051232.AA17006@mitsou.inria.fr> However, it seems that you miss Steve's strongest argument. Suppose the "diameter" of the Internet becomes so large that you need, say, 50000 hops. Then, what is exactly the rationale for counting the hops in the packets? The hop count, as it stands now, serves one purpose: eliminating loopers. This, of course, is one of the trade offs that we have to make. The question is whether we want to outlaw a (possibly) reasonable configuration, or do we want more effecient recognition of the error case. Somewhere there's a line to draw, we just have to decide where. I think I agree with you that a diameter of 50000, whatever that is measuring, is absurd. Apart from anything else, that would be a 5 second delay if the transit+queueing delays could be reduced to 100 us, which is getting down into the close to impossible range (except where the path is confined to an area where you couldn't possibly want that number of hops). However, I'm not prepared to say that 300 hops is too many. That is, I don't think 8 bits is enough, I don't know how many we need, but it should be more than 8, and probably more than 9. I doubt I'd object to 10 (for path length considerations anyway), but by the time we have done that, we may just as well provide a 16 bit space, and just not use a lot of it, initially at least - unless perhaps someone can think of something useful to do with a few bits in the header. At the minute I think I'd set the initial hop count to something around 64, maybe 80, I doubt any more - and we could even have routers reject packets with a hop count > 255 because of the possibility that some broken site may inject a packet with a huge ttl, and that packet may just happen to loop. It may seem odd to design a large field, and then deliberately not use it - but eliminating a restriction on the use of a field is a whole lot easier than re-designing the header if its later discoverd the field isn't big enough. The "hierarchy of counters" idea is fine - it will have the same effect, though I'm not sure its implementable, especially as I doubt that the "AS" concept will survive long term, meaning that the points where the different levels of hop count are adjusted may be practically impossible to locate. Encapsulation might be a workable idea too, though this adds a whole extra level of complexity. Whatever, something to allow > 255 hops is needed - just how many more we need isn't clear, and because of that we should make it enough more that its obviously "too many", even "absurdly many" because anything less is not enough. kre From owner-Big-Internet@munnari.oz.au Tue Oct 6 01:41:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12411; Tue, 6 Oct 1992 01:41:35 +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 AA12400; Tue, 6 Oct 1992 01:41:27 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA17443; Mon, 5 Oct 92 09:41:18 -0600 Received: by goshawk.lanl.gov (4.1/5.17) id AA28628; Mon, 5 Oct 92 09:41:15 MDT Date: Mon, 5 Oct 92 09:41:15 MDT From: peter@goshawk.LANL.GOV (Peter S. Ford) Message-Id: <9210051541.AA28628@goshawk.lanl.gov> To: henryc@oar.net, peter@goshawk.LANL.GOV, solensky@andr.UB.com Subject: Re: Routing architectures Cc: big-internet@munnari.oz.au Frank, May I suggest if we were to start looking at traffic statistics we might want to change the discussion of scaling the Internet to: 1) Deciding what traffic statistics are relevent and why 2) examining the scaling problems of Appletalk, IPX and SNA. Henry, CLNP is running in the Internet, for some definition of the Internet. I will agree that not all networks out there are running CLNP, but they could be in the very near future. The IETF has an active working group to sort out the interoperability problems and to plan for the future. I hope all network providers will choose to participate. The mailing list can be subscribed to by mailing to: noop-request@merit.edu. cheers, peter From owner-Big-Internet@munnari.oz.au Tue Oct 6 01:43:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12493; Tue, 6 Oct 1992 01:43:38 +1000 (from owner-Big-Internet) Return-Path: Received: from aotearoa.sura.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12478; Tue, 6 Oct 1992 01:43:30 +1000 (from sherk@sura.net) Received: by aotearoa.sura.net with SMTP (5.65b/($Id: sendmail.cf,v 1.17 1991/02/11 14:07:23 jmalcolm Exp $)) id AA08487; Mon, 5 Oct 92 11:43:21 -0400 Message-Id: <9210051543.AA08487@aotearoa.sura.net> To: henryc@oar.net Cc: big-internet@munnari.oz.au Subject: Re: Routing architectures In-Reply-To: Your message of "Mon, 05 Oct 92 09:21:06 EDT." <9210051321.AA26886@thor.oar.net> Date: Mon, 05 Oct 92 11:43:20 -0400 From: Erik Sherk Henry, SURAnet is running CLNP on our backbone. While this service is still immature, it has passed the point of being "experimental". We are still working on issues like monitoring tools, staff training and applications that actually use the connectivity. (osi_ping doesn't count :-) Erik Sherk sherk@sura.net > >Bob, I just didn't want to trivialize other efforts since for CLNP: > > > > The packet format is an international, voluntary standard and > > has been for quite a while. > > > > The routing architecture exists. > > > > The Internet is actively deploying CLNP. > > > > The IETF has an active group working on CLNP operational issues. > > > >Given all this, one might wonder what the IESG is going to deliberate on > >wrt TUBA. > > > > Hold on, Peter. Just who is deploying CLNP? How many regionals are actually > pushing CLNP traffic? I'd be willing to bet a fair sized greenback that I can > count on less than one hand the number of regionals actually routing CLNP > traffic. Can we have a show of hands of the networks actually running CLNP > traffic across their backbone on a daily basis in a "production" mode? > > Henry From owner-Big-Internet@munnari.oz.au Tue Oct 6 01:53:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12754; Tue, 6 Oct 1992 01:53:16 +1000 (from owner-Big-Internet) Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12749; Tue, 6 Oct 1992 01:53:06 +1000 (from mak@merit.edu) Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA18260; Mon, 5 Oct 92 11:52:55 -0400 Received: by home.merit.edu (4.1/client-0.9) id AA25814; Mon, 5 Oct 92 11:52:53 EDT From: mak@merit.edu Message-Id: <9210051552.AA25814@home.merit.edu> To: Frank T. Solensky Cc: henryc@oar.net, peter@goshawk.lanl.gov, big-internet@munnari.oz.au Subject: Re: Routing architectures In-Reply-To: Your message of "Mon, 05 Oct 92 10:18:17 EDT." <9210051418.AA23564@fenway.andr.UB.com> Date: Mon, 05 Oct 92 11:52:51 -0400 There are 7 NSS gateways on the T1 NSFNET backbone configured for CLNP. These are: 14 NorthWestNet 12 NCSA MSCnet Argonne 10 EASInet 9 FIX-E ICM ESnet 17 Merit/UMnet CONCERT 15 Westnet SLC 13 FIX-W ESnet I don't have a percentage of traffic figure but it is quite low (around 1% of total NSFNET traffic). --Mark > From: Frank T. Solensky > To: henryc@oar.net, peter@goshawk.lanl.gov > CC: big-internet@munnari.oz.au > >From: henryc@oar.net > > > >Hold on, Peter. Just who is deploying CLNP? How many regionals are actuall y > >pushing CLNP traffic? ... Can we have a show of hands of the networks > >actually running CLNP traffic across their backbone on a daily basis in a > >"production" mode? > > > > More specifically, how _much_ traffic? Describing it as a percentage of the > total would probably make it appear to be less significant that it should be > while simply saying "we have it" may overemphasize it if noone's using it.. > -- Frank From owner-Big-Internet@munnari.oz.au Tue Oct 6 02:12:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13257; Tue, 6 Oct 1992 02:12:39 +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 AA13242; Tue, 6 Oct 1992 02:12:22 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA23974; Mon, 5 Oct 92 12:12:06 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA11435; Mon, 5 Oct 92 09:10:57 PDT Message-Id: <9210051610.AA11435@aland.bbn.com> To: "Peter S. Ford" Cc: jnc@ginger.lcs.mit.edu Subject: Re: Routing architectures Cc: big-internet@munnari.oz.au From: Craig Partridge Date: Mon, 05 Oct 92 09:10:56 -0700 Sender: craig@aland.bbn.com > Who is the IESG to decide if people on the Internet (who can and are > running CLNP by the way, lest the IESG and others forget this) should use TUBA > to intercommunicate? Does the IESG deliberate as to whether or not > people should tunnel appletalk? > > Note: My question was intended to determine the scope of the > IESG's deliberation. I hope that if there are any major changes to the > Internet architecture that those changes are widely considered, > critically examined, and experimented with in the Internet tradition. Peter: This question doesn't quite fit into my world view. The IESG has a two-fold job -- help maintain the Internet and do what standardization work is required for the continued health of the TCP/IP protocol suite. (When I was on the IESG, convergence with OSI was not a goal, but the expected advent of OSI-ish applications led to the creation of an OSI Area). The IESG has to assume its decisions have weight and will influence what people do on the Internet. However, the IESG is in no position to force folks not to do things, even if those things are considered stupid. So, yes the IESG may debate whether folks should tunnel appletalk, on the grounds that the IESG may be able to make a recommendation about how to tunnel appletalk to ensure the health of the Internet. And the IESG could decide that TUBA is a poor idea, and determine not to say anything that would encourage it. Obviously, in the case of the future of IP, both roles of the IESG come together -- it wants to keep TCP/IP (in some form) going and needs to worry about the future of the Internet. Craig From owner-Big-Internet@munnari.oz.au Tue Oct 6 02:25:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13714; Tue, 6 Oct 1992 02:26:01 +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 AA13711; Tue, 6 Oct 1992 02:25:41 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA25000; Mon, 5 Oct 92 09:25:18 -0700 Received: by us1rmc.bb.dec.com; id AA02466; Mon, 5 Oct 92 12:22:46 -0400 Message-Id: <9210051622.AA02466@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Mon, 5 Oct 92 12:22:46 EDT Date: Mon, 5 Oct 92 12:22:46 EDT From: Ross Callon To: solensky@andr.ub.com Cc: big-internet@munnari.oz.au Apparently-To: solensky@andr.ub.com, big-internet@munnari.oz.au Subject: re: re: Hop Limit field in SIP > > One question: Do we think that the current Internet Protocol / > > Architecture would be able to work in an Internet requiring more > > than 255 hops? Would things like delays, packet losses, etc add > > up to enough to cause TCP to break? > > Sure! The hop-count is be just that -- it's not a indicator of > how much _time_ it takes to drop down to zero. In an ideal > environment (data structures in cache, quiet lines, etc.), I'd guess > it could easily pass through 255 routers in less than a second. I am not *just* worried about delay. It seems to me that our current way of doing networking is not so robust that we would want to stretch it so far. If the delay doesn't get us, then link flapping might, or routes might be unstable, or packet loss rates might add up, or someone would have mis-configured some policy routing entry, or .... I admit that this is just a "lack of confidence" rather than anything more definite. It just seems that if you go through 80 Ethernet hops to get to your local regional, then 20 more T3 hops to get to the backbone, then 20 more T3 hops across the backbone to the International Backbone then 20 more hops to the destination country, and so on, then if it all adds up to even remotely close to 256 hops then someone has designed something wrong, and something somewhere will probably break. Quite likely in an ideal world we could indeed make a 300 hop path work well. However, in an ideal world would we *want* to do so? Ross From owner-Big-Internet@munnari.oz.au Tue Oct 6 03:33:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15475; Tue, 6 Oct 1992 03:33:33 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210051733.15475@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15470; Tue, 6 Oct 1992 03:33:21 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <05344-0@datanet.tele.fi>; Mon, 5 Oct 1992 19:32:43 +0200 To: sherk@sura.net Cc: henryc@oar.net, big-internet@munnari.oz.au In-Reply-To: <9210051543.AA08487@aotearoa.sura.net> "sherk@sura.net" Subject: Routing architectures Date: Mon, 5 Oct 1992 19:32:43 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi we are also running CLNS in production in our DataNet service. the main application is currently X.400, but we expect DecNet Phase V to increase the traffic quite a lot. we just got a new order of a 16 site customer that wants to run CLNS. based on my experience in debugging router code, once a new protocol is first time implemened in a router, it takes a mimimum of 2 years before the code becomes real production quality. based on the convergence of the discussion on this list, it will take at least 2 years, before a spec of the new protocol is agreed (if ever). then one must count at least 2 years to implement all the required changes in host and routers and dns. then the 2 years i mentioned for debugging the code. taken the above rather optimistic projection into account, CLNS starts to make alot of sense as the next generation IP. -- juha From owner-big-internet@munnari.oz.au Tue Oct 6 04:05:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16397; Tue, 6 Oct 1992 04:05:37 +1000 (from owner-big-internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13594; Tue, 6 Oct 1992 02:23:21 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA25405 (5.65c/UK-2.1-921001); Mon, 5 Oct 1992 12:23:30 -0400 From: Gary Scott Malkin Date: Mon, 5 Oct 1992 12:23:30 -0400 Message-Id: <25405.199210051623@atlas.xylogics.com> To: dab@asylum.sf.ca.us Cc: big-internet@munnari.oz.au In-Reply-To: (David Bridgham's message of Fri, 2 Oct 92 18:10:41 -0400 (EDT) <9210022210.AA18080@asylum.sf.ca.us> Subject: routing architecture > You're right but you'd have to convince me why we'd do better this > time around. I can believe in a relatively dense use of an end-point > identifier space, but once you go to a heirarchical space I think it's > going to be used sparsely. The reason the address space is so sparsely used now, is that the class structure imposed on the address is an evolution, not a design. Also, the blocks which are allocated are sized for human readability (nice byte bounderies), not for efficient use of the space. There is no reason why the address we design needs to be in any way memorable for humans; that's what name servers are for. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-big-internet@munnari.oz.au Tue Oct 6 04:15:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16652; Tue, 6 Oct 1992 04:15:30 +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 AA14731; Tue, 6 Oct 1992 03:03:15 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA28501; Mon, 5 Oct 92 13:02:37 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA11687; Mon, 5 Oct 92 10:00:56 PDT Message-Id: <9210051700.AA11687@aland.bbn.com> To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of Mon, 05 Oct 92 12:22:46 -0400. <9210051622.AA02466@us1rmc.bb.dec.com> From: Craig Partridge Date: Mon, 05 Oct 92 10:00:56 -0700 Sender: craig@aland.bbn.com Noel: You asked what we could do instead of a hop count. How about a real expiration timestamp (e.g. NTP format)? Craig From owner-Big-Internet@munnari.oz.au Tue Oct 6 04:18:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16770; Tue, 6 Oct 1992 04:18:18 +1000 (from owner-Big-Internet) Return-Path: Received: from dg-rtp.rtp.dg.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16760; Tue, 6 Oct 1992 04:18:09 +1000 (from throop@dg-rtp.dg.com) Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4.1/dg-rtp-proto) id AA25417; Mon, 5 Oct 1992 14:17:56 -0400 Received: by walrus (5.4.1/140.2) id AA05150; Mon, 5 Oct 1992 14:15:27 -0400 Date: Mon, 5 Oct 1992 14:15:27 -0400 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9210051815.AA05150@walrus> To: big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > To: Christian.Huitema@sophia.inria.fr, kre@munnari.oz.au > Subject: Re: Hop Limit field in SIP > ... > > Musing on this brings a thought; in a pure datagram system, we seem to have > traded off state in the routers (bad?) for state in the packets (good?). It > seems like you have to have a certain amount of state; the only question is > whether it is per packet or in the routers. As the system gets larger and > more complex, you probably need more complex state, which means that either > a) the packets get more complex (i.e. more expensive to process), or b) you > put more state in the routers. Hmmm.... > > Right at the moment, though, I'm sort of stumped as to another simple way to do > what the hop count does, though. The heirarchy of counters, while workable, > seems too complex; the overhead of updating each packet would be considerable. > The virtue of the hop count is that it is very simple and efficient to > implement. > One way that occured to me was to replace the hop count with an expiration time. This would require that all routers know the current time. Back in the early days before NTP this wasn't possible. However now that NTP exists, maybe we should use it. A host preparing a packet for transmission would put an expiration time in the packet. This time time would be the current time plus some delta. The delta would depend on the destination host. When a router received the packet, it would compare the expiration time with the current time and discard the packet if it was too old. This solves the higher layer requirement for discarding old packets and also eliminates rewriting the packet to change the hop count. The packet becomes read only (expect for source record options). The next question is how does a new host/router on the network get the time if it must have the time before sending a packet? We could say that an expiration time of zero can't be forwarded but can be accepted. This would allow the host/router to communicate with local peers to learn the current time. Dean Throop throop@dg-rtp.dg.com From owner-big-internet@munnari.oz.au Tue Oct 6 04:28:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17093; Tue, 6 Oct 1992 04:28:39 +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 AA15645; Tue, 6 Oct 1992 03:39:18 +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 AA08514; Mon, 5 Oct 92 10:39:11 PDT Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA13566; Mon, 5 Oct 92 10:39:12 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA09734; Mon, 5 Oct 92 10:34:56 PDT Date: Mon, 5 Oct 92 10:34:56 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9210051734.AA09734@bigriver.Eng.Sun.COM> To: peter@goshawk.LANL.GOV (Peter S. Ford) Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au In-Reply-To: <9210051511.AA28479@goshawk.lanl.gov> Subject: Re: Routing architectures Peter, > Who is the IESG to decide if people on the Internet (who can and are > running CLNP by the way, lest the IESG and others forget this) should use TUBA > to intercommunicate? Does the IESG deliberate as to whether or not > people should tunnel appletalk? Like wise, who is the IESG to require people to use CLNP. The decision needs to be made by the IETF community. The IESG can help the community by providing criteria to help the IETF come to a consensus. The IESG should only ratify that consensus. Bob From owner-big-internet@munnari.oz.au Tue Oct 6 04:49:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17718; Tue, 6 Oct 1992 04:49:10 +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 AA15676; Tue, 6 Oct 1992 03:40:46 +1000 (from kasten@ftp.com) Received: by ftp.com id AA06327; Mon, 5 Oct 92 13:28:37 -0400 Date: Mon, 5 Oct 92 13:28:37 -0400 Message-Id: <9210051728.AA06327@ftp.com> To: Christian.Huitema@sophia.inria.fr Subject: Re: Hop Limit field in SIP From: kasten@ftp.com (Frank Kastenholz) Cc: kre@munnari.oz.au, callon@bigfut.enet.dec.com, big-internet@munnari.oz.au > Maybe we should stop and think seriously here. What is a hop? What do we > control? Maybe we should use a hierarchy of counters, e.g. nb of hops within > AS + nb of AS crossed -- which would mean listing the "current AS ID" within > the header. Or maybe we should use encapsulation for long paths, e.g. check > that you get to in less than 36 hops, then use new header to get to > in less than 254 hops... One of the ideas that have been discussed on and off has been the notion of using a route servers to either tell routers how to get from here to there or to tell the originating host so that it can put a "source route" into the packet. In either case, this route server "knows" the full path and can tell exactly how many hops it _should_ take. The originating node could get this information and use it as the base for what value to place in the max hops field. The originator could add several hops to take changes in the routing into account and so on. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Tue Oct 6 04:55:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17876; Tue, 6 Oct 1992 04:56:05 +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 AA17856; Tue, 6 Oct 1992 04:55:47 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA24646; Mon, 5 Oct 92 12:55:42 -0600 Received: by goshawk.lanl.gov (4.1/5.17) id AA29712; Mon, 5 Oct 92 12:55:39 MDT Date: Mon, 5 Oct 92 12:55:39 MDT From: peter@goshawk.LANL.GOV (Peter S. Ford) Message-Id: <9210051855.AA29712@goshawk.lanl.gov> To: Bob.Hinden@Eng.Sun.COM, peter@goshawk.LANL.GOV Subject: Re: Routing architectures Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu >>> Like wise, who is the IESG to require people to use CLNP. The decision >>> needs to be made by the IETF community. The IESG can help the community >>> by providing criteria to help the IETF come to a consensus. The IESG >>> should only ratify that consensus. >>> Bob Bob, I would agree that the IETF would be a good forum to discuss the technical viability of running CLNP in the Internet. In fact, the IETF already has such a group, the Network Operations OSI group. CLNP is already running in the Internet so I don't think the IETF or the IESG has much to discuss viz. whether or not CLNP should be running there. Wouldn't you agree that the vendors, users and network operators should be the ones to decide what products they use to solve their interconnectivity problems? I whole-heartedly concur that the IESG can help *any* community by providing criteria, PROVIDING THAT CRITERIA REFLECTS THE CONSENSUS OF THE IETF COMMUNITY. May I assume the IESG will form a WG to build the criteria needed for their deliberations? I suspect you already have a pretty good start on them so hopefully a working group could convene using the current IESG work as a strawman and reach consensus in short order. regards, peter From owner-big-internet@munnari.oz.au Tue Oct 6 05:14:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18521; Tue, 6 Oct 1992 05:14:43 +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 AA16698; Tue, 6 Oct 1992 04:16:49 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA03141; Mon, 5 Oct 92 11:16:11 -0700 Received: by us1rmc.bb.dec.com; id AA06852; Mon, 5 Oct 92 14:13:38 -0400 Message-Id: <9210051813.AA06852@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Mon, 5 Oct 92 14:13:39 EDT Date: Mon, 5 Oct 92 14:13:39 EDT From: Ross Callon To: craig@aland.bbn.com Cc: big-internet@munnari.oz.au Apparently-To: craig@aland.bbn.com, big-internet@munnari.oz.au Subject: re: Role of the IESG (was Routing architectures) > > (Peter Ford) > > Who is the IESG to decide if people on the Internet (who can and are > > running CLNP by the way, lest the IESG and others forget this) should use > > TUBA to intercommunicate? Does the IESG deliberate as to whether or not > > people should tunnel appletalk? > > > > Note: My question was intended to determine the scope of the > > IESG's deliberation. I hope that if there are any major changes to the > > Internet architecture that those changes are widely considered, > > critically examined, and experimented with in the Internet tradition. > > (Craig Partridge) > This question doesn't quite fit into my world view. > > The IESG has a two-fold job -- help maintain the Internet and do what > standardization work is required for the continued health of the TCP/IP > protocol suite. (When I was on the IESG, convergence with OSI was not a goal, > but the expected advent of OSI-ish applications led to the creation of an > OSI Area). > > The IESG has to assume its decisions have weight and will influence > what people do on the Internet.... Gee Craig, it seems that back when we were both on the IESG we must have had slightly different views about what the IESG was trying to do. I don't see the IESG as having the authority to decide anymore than the IAB has this authority. I don't even see the IESG as having any more influence than any other bunch of folks of similar seniority that get together for beers on a Friday afternoon and produce an opinion paper. The Internet works better than other ways of producing standards for two reasons: One is that we have an operational Internet which we must keep working; the other reason is that we don't use central authority to try to force or even influence decisions, instead we use deployment and working code to decide. Thus the IESG can be very effective by putting people on the spot ("You are going to get to present your proposal at the next IETF, I hope you are ready..."). The IESG can also be very effective by bringing up issues and facilitating formation of BOFs and working groups. However, I don't see more "pronouncement" oriented activities as having much effect. Some people have privately expressed concern that the Internet does not have a decision method to figure out what to do about the Internet scaling problem. This is sometimes seen as a problem. However, I think that the lack of a centralized decision authority is actually a good thing. The Internet *will* decide which approach to use, but not by virtual of a central committee deciding. Rather, folks will work on several proposals (IPAE, TUBA, SIP, PIP, NIMROD, etc), and sooner or later it will be obvious which one has already succeeded and been deployed. Most likely it will be whichever solution makes the most sense from the perspective of vendors, network service providers, and customers. Ross From owner-big-internet@munnari.oz.au Tue Oct 6 05:25:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18930; Tue, 6 Oct 1992 05:25:36 +1000 (from owner-big-internet) Return-Path: Received: from timbuk.cray.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16849; Tue, 6 Oct 1992 04:20:54 +1000 (from dab@berserkly.cray.com) Received: from handel.cray.com.cray.com by cray.com (4.1/CRI-MX 2.2) id AA18742; Mon, 5 Oct 92 13:20:45 CDT Received: by handel.cray.com.cray.com id AA07651; 5.65/CRI-5.5; Mon, 5 Oct 1992 13:20:09 -0500 Date: Mon, 5 Oct 1992 13:20:09 -0500 From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9210051820.AA07651@handel.cray.com.cray.com> To: Christian.Huitema@sophia.inria.fr, jnc@ginger.lcs.mit.edu, kre@munnari.oz.au Subject: Re: Hop Limit field in SIP Cc: big-internet@munnari.oz.au > Then, what is exactly the rationale for counting the hops in the packets? > The hop count, as it stands now, serves one purpose: eliminating loopers. > > A most excellent point. What's important is the goal (eliminating looping > packets), *not* the mechanism (hop count). This is the kind of analysis we > need! > Right at the moment, though, I'm sort of stumped as to another simple way to do > what the hop count does, though. The heirarchy of counters, while workable, > seems too complex; the overhead of updating each packet would be considerable. > The virtue of the hop count is that it is very simple and efficient to > implement. Well, here's an analysis, and I disagree that a heirarchy of counters would be too comples. With the correct definitions, a multi-level hop count scheme can be implemented with almost no extra overhead, and the more I think about it, the better I like the idea because of its simplicity. The goal is to detect routing loops. When keeping the state in the packet, we do that by counting how many times the packet has been forwarded. With 8 bits, the maximum hop count is 255. We are theorizing that in the future we will want to detect routing loops in some small number of hops (less than 255), and still allow for packet paths that may go thousands or more hops. Well, it seems to me that these long paths will consist of a sequence of shorter paths through multiple areas, and that the distance across each area will be short (less than 255). So, keep the hop count at 8 bits and rename it the interior hop count, and then add an exterior hop count for the maximum number of areas through which the packet may pass. While the packet is within an area, only the interior hop count is used. When it passes through a border gateway, the external hop count is used, and the interior hop count gets reset upon forwarding. The extra overhead is minimal: Host/end-node: One extra line of code to initialize the exterior hop count. Border Gateway: Check/decrement the exterior hop count instead of the interior hop count, and reset the interior hopcount when forwarding. Hosts and interior routers only look at and decrement the interior hop count. When it goes to zero, the ICMP unreachable message is generated. No change in overhead from today. Border gateways look at and decrement the exterior hop count, which is no change in overhead; the only extra overhead is that they also have to re-initialize the interior hop count when forwarding the packet. The big disadvantage is that if a packet is looping between or through areas, and the paths through each of the areas is long, the packet can bounce around a lot before being dropped. However, my gut feel is that most routing loops are within a single area, and loops between areas probably wouldn't go very deep within those areas. Hence, you get the looping detection quickly, and allow for very long packet paths. The only anomaly is that if a packet arrived at a border gateway with an interior hop count that would cause it to be discarded, it would still be forwarded if the exterior hop count was ok. Also, if you have a border gateway that is forwarding between multiple networks within an area in addition to being the border gateway, it would have to defer the hop count checking until it had decided if the packet was going to be routed internally or externally, or else check both fields by checking the interior hop count on input, and the exterior hop count when forwarding to another area. It would also be real easy to extend this scheme to more than two levels of hop counts if that was needed, with no additional overhead, just extra bits in the header. If two levels isn't enough, then I'd suggest 4 contiguous 8-bit fields. That ought to hold us until well beyond the life of IPv7... There's also another advantage to this scheme. If the host sets the exterior hop count to one, the packet will be limited to within the area, without having to have any policy/packet filtering put into the border gateway. This might be a real nice feature for multi-cast. Another feature/disadvantage is that you wouldn't be able to use the expanding hop count scheme in programs like traceroute to get the paths through other areas, because you wouldn't have any control over what the border gateways would reset the internal hop counts to. You'd only be able to get the path through your own area, and from then on just the path through the border routers. Also, if border gateways have some knowledge of how big the area is that they are forwarding the packet into, they can reset the interior hop count to a reasonable value for packets going through that area, helping to detect interior routing loops more quickly. -David Borman, dab@cray.com From owner-Big-Internet@munnari.oz.au Tue Oct 6 05:32:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19091; Tue, 6 Oct 1992 05:32:10 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19084; Tue, 6 Oct 1992 05:32:02 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA100865 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Mon, 5 Oct 1992 15:31:31 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Oct 1992 15:31:31 -0400 Message-Id: <199210051930.AA40560@home.ans.net> To: John Curran Cc: big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: Re: IESG Deliberations on ROAD In-Reply-To: (Your message of Mon, 05 Oct 92 08:31:11 D.) <199210051230.AA08158@interlock.ans.net> Date: Mon, 05 Oct 92 15:30:04 -0500 From: Phill Gross ...It's important (when documents such as the IESG deliberations or the IAB IPv7 come out) to recognize that they do not represent "The" decision criteria unless they represent the communities that must deploy the change. Now it's quite possible that the IESG deliberations have incorporated suc input and the document is the ultimate criteria for the selection of the next generation architecture. John, I do not consider the current criteria to be The Ultimate Criteria.... at least, not until the community has had a chance to provide imput. From section 4.5 "Milestones...": August-November 1992 -- .....Public review, discussion, and modification as appropriate of the "selection criteria" in Appendix B. From Appendix B "INFORMATION AND SELECTION CRITERIA ..." This section describes the information and criteria which the IESG felt that any new routing and addressing proposal should supply. As the community has a chance to comment on these criteria, and as the IESG gets a better understanding of the issues relating to selection of a new routing and addressing architecture, this section may be revised and published in a separate document. The intent is for the community to be the final judge of what the correct criteria are. Phill From owner-Big-Internet@munnari.oz.au Tue Oct 6 05:37:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19257; Tue, 6 Oct 1992 05:37:44 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA19254; Tue, 6 Oct 1992 05:37:39 +1000 (from asp@uunet.uu.net) Received: by rodan.UU.NET (5.61/UUNET-mail-drop) id AA20007; Mon, 5 Oct 92 15:33:33 -0400 From: asp@uunet.uu.net (Andrew Partan) Message-Id: <9210051933.AA20007@rodan.UU.NET> Subject: Re: Routing architectures To: mak@merit.edu Date: Mon, 5 Oct 92 15:33:32 EDT Cc: solensky@andr.UB.com, henryc@oar.net, peter@goshawk.lanl.gov, big-internet@munnari.oz.au In-Reply-To: <9210051552.AA25814@home.merit.edu>; from "mak@merit.edu" at Oct 5, 92 11:52 am X-Mailer: ELM [version 2.3 PL10] You forgot AlterNet - we do CLNP with the NSFNET at NSS 9 as well (we have been running operational OSI traffic on AlterNet since at least April '91). --asp@uunet.uu.net (Andrew Partan) From owner-Big-Internet@munnari.oz.au Tue Oct 6 05:35:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19317; Tue, 6 Oct 1992 05:40:02 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19202; Tue, 6 Oct 1992 05:35:48 +1000 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA02658; Mon, 5 Oct 92 12:32:49 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA09200; Mon, 5 Oct 1992 15:32:30 -0400 To: Ross Callon Subject: re: re: Hop Limit field in SIP In-Reply-To: <9210051622.AA02466@us1rmc.bb.dec.com> References: <9210051622.AA02466@us1rmc.bb.dec.com> Cc: solensky@andr.ub.com, big-internet@munnari.oz.au X-Mailer: Poste 2.0 From: David R. Oran Date: Mon, 5 Oct 92 15:32:26 -0400 Message-Id: <921005153226.12546@sneezy.lkg.dec.com> Encoding: 37 TEXT, 6 TEXT SIGNATURE >> Quite likely in an ideal world we could indeed make a 300 hop > path work well. However, in an ideal world would we *want* to > do so? > I think Ross is right, as long as one's mind set has hops being Hopppppppp....pppps, i.e. are long, pass through significant switching equipment at each switching point, iow: are what we think of as network/internet hops today. I would be surprised if someone could make a credible case for Internet paths that are longer than 255 "traditional" hops. As someone already pointed out, the International phone system is only 12 hops in diameter, and even the most optimistic predictions get it to 15 hops in the next 50 years. The graph-theoretical rule of thumb has worked quite well in many problem domains: the diameter grows as the loglog of the number of nodes. Some folks, however, have posited that future switching architectures might have hippities that need to be dealt with in the architecture as hops. If that is the case then the paths might indeed get considerably longer. This connundrum is a fundamental limitation of using hops rather than some quantity which is normalized to either time or resource consumption. The problem with TTL or resource budgets is the difficulty of processing them in the forwarding path of a switch. Perhaps there might be a compromise here, which is to define a bigger field, like 16 bits, but to have two sorts of decrements, a decrement by 1 for a "hippity", and a decrement by 16 for a "hop". You define a hippity as a link traversal either inside a switch, or between private, low latency links (i.e. not internet hops) between a pair of switches, as might be the case with ATM. That way packets eating large amounts of multiple-organizational resources get damped quickly without preventing the micro-level switching infrastructure from eating the whole dynamic range of the hop count. Just a thought..., -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Tue Oct 6 05:37:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19476; Tue, 6 Oct 1992 05:44:39 +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 AA19250; Tue, 6 Oct 1992 05:37:31 +1000 (from kasten@ftp.com) Received: by ftp.com id AA05612; Mon, 5 Oct 92 13:13:52 -0400 Date: Mon, 5 Oct 92 13:13:52 -0400 Message-Id: <9210051713.AA05612@ftp.com> To: henryc@oar.net Subject: Re: Routing architectures From: kasten@ftp.com (Frank Kastenholz) Cc: peter@goshawk.lanl.gov, big-internet@munnari.oz.au > Hold on, Peter. Just who is deploying CLNP? How many regionals are actually > pushing CLNP traffic? I'd be willing to bet a fair sized greenback that I can > count on less than one hand the number of regionals actually routing CLNP > traffic. Can we have a show of hands of the networks actually running CLNP > traffic across their backbone on a daily basis in a "production" mode? it would also be interesting to know how many end-nodes are running clnp in a "production mode". i imagine that it would not take many end nodes talking with each other to put clnp traffic pver every regional and backbone. of course, there are still more nodes talking clnp than are talking pip, sip, ipae, etc, put together :-) -- frank kastenholz From owner-Big-Internet@munnari.oz.au Tue Oct 6 06:21:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20699; Tue, 6 Oct 1992 06:22:40 +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 AA20681; Tue, 6 Oct 1992 06:21:56 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA16694; Mon, 5 Oct 92 16:21:42 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA13416; Mon, 5 Oct 92 13:20:31 PDT Message-Id: <9210052020.AA13416@aland.bbn.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of Mon, 05 Oct 92 16:11:44 -0400. <9210052011.AA16162@ginger.lcs.mit.edu> From: Craig Partridge Date: Mon, 05 Oct 92 13:20:31 -0700 Sender: craig@aland.bbn.com Noel: My understanding is that the cost of running NTP is largely a function of the precision in clocks that you want and the speed at which a clock must converge. If you only want to bound packet lifetimes to the 100s of ms, I don't believe the load is very much. There is the tricky question of getting the clock synched so one can send packets (which someone mentioned). On multicast media, I suspect this problem can be solved by simply having the primary timeserver multicast the current time at regular intervals -- one uses that value to start and then runs NTP to converge. Craig From owner-Big-Internet@munnari.oz.au Tue Oct 6 06:26:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20772; Tue, 6 Oct 1992 06:26:17 +1000 (from owner-Big-Internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20769; Tue, 6 Oct 1992 06:26:06 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA14673); Mon, 5 Oct 92 15:25:57 CDT Received: by san-miguel.is.rice.edu (AA20364); Mon, 5 Oct 92 15:25:56 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9210052025.AA20364@san-miguel.is.rice.edu> Subject: Re: Routing architectures To: mak@merit.edu Date: Mon, 5 Oct 92 15:25:55 CDT Cc: henryc@oar.net, peter@goshawk.lanl.gov, big-internet@munnari.oz.au In-Reply-To: <9210051552.AA25814@home.merit.edu>; from "mak@merit.edu" at Oct 5, 92 11:52 am X-Mailer: ELM [version 2.3 PL11] Hold on. What happened to NSS-11? We were routing for a while there. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-Big-Internet@munnari.oz.au Tue Oct 6 07:16:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22420; Tue, 6 Oct 1992 07:16:32 +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 AA22408; Tue, 6 Oct 1992 07:16:14 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11635>; Mon, 5 Oct 1992 14:15:48 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 5 Oct 1992 14:15:40 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of "Fri, 02 Oct 92 17:33:00 PDT." <9210030033.AA01096@ginger.lcs.mit.edu> Date: Mon, 5 Oct 1992 14:15:34 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct5.141540pdt.10779@skylark.parc.xerox.com> Noel wrote: > ... Bandwidth is going to be dirt cheap; all fields should be > *ridiculously* big. That sounds like a *ridiculous* generalization to me. I can think of a number of reasons why we might care not to waste a *lot* of bits in those fields that ride in every packet: - Even though the median link bandwidth may be large, we might still want to support relatively low speed links in the Internet, especially metropolitan and long-haul wireless links for which bandwidth may never become "dirt cheap", due to bounded spectrum availability. (Maybe header compression is the answer, but can we be confident that future traffic patterns over such links will have sufficient coherence to allow significant compression? Though I suppose if you fill up the header with lots of content-free bits, it should be easy enough to compress them out.) - Many packets carry very small payloads, such as acks, and the percentage of small packets may increase significantly with the growth of real-time traffic, such as voice, that tends to send only tens or hundreds of bytes per packet. The smaller you can keep the header, the more such packets you can accommodate in your network, and the lower the queuing delays they suffer. The suitability of datagrams for carrying real-time traffic is made worse than it already is if those datagrams have *ridiculously* big fields in their headers. - The bigger the fields, the more memory accesses might be required by hosts and routers to process the packet headers. None of these reasons is especially compelling, but they suggest that there might be *some* benefit in not, say, making the Hop Limit field 64 bits wide. The penalty paid by connectionless protocols is having to carry around and process bigger packet headers than connection-oriented protocols; I think it's worthwhile to try to keep that penalty no larger than necessary. Steve From owner-Big-Internet@munnari.oz.au Tue Oct 6 07:17:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22486; Tue, 6 Oct 1992 07:17:48 +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 AA22475; Tue, 6 Oct 1992 07:17:37 +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 AA04437; Mon, 5 Oct 92 14:17:25 PDT Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA01496; Mon, 5 Oct 92 14:17:27 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA11643; Mon, 5 Oct 92 14:13:09 PDT Date: Mon, 5 Oct 92 14:13:09 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9210052113.AA11643@bigriver.Eng.Sun.COM> To: peter@goshawk.LANL.GOV (Peter S. Ford) Cc: Bob.Hinden@Eng.Sun.COM, peter@goshawk.LANL.GOV, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9210051855.AA29712@goshawk.lanl.gov> Subject: Re: Routing architectures Peter, > I would agree that the IETF would be a good forum to discuss the > technical viability of running CLNP in the Internet. In fact, > the IETF already has such a group, the Network Operations OSI group. > CLNP is already running in the Internet so I don't think the IETF or the > IESG has much to discuss viz. whether or not CLNP should be > running there. The issue in this forum is not whether CLNP should be running on the internet. It is now, will continue to, etc. If I can use your example, it is just like Appletalk in this sense. The key issue is should CLNP be the replacement for IPv4. > Wouldn't you agree that the vendors, users and network operators > should be the ones to decide what products they use to solve their > interconnectivity problems? I whole-heartedly concur that the IESG > can help *any* community by providing criteria, PROVIDING THAT > CRITERIA REFLECTS THE CONSENSUS OF THE IETF COMMUNITY. May I assume > the IESG will form a WG to build the criteria needed for their > deliberations? I suspect you already have a pretty good start on them > so hopefully a working group could convene using the current IESG > work as a strawman and reach consensus in short order. I am sure that a w.g. could be formed. In the mean time, I would encourage you and everyone else to read and comment on the IESG criteria. Suggestions as to how they could be improved, changed, clarified, etc. are all welcome. There is no need to wait for a working group. Bob From owner-Big-Internet@munnari.oz.au Tue Oct 6 07:31:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22977; Tue, 6 Oct 1992 07:32:00 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22974; Tue, 6 Oct 1992 07:31:54 +1000 (from pgross@ans.net) Received: by interlock.ans.net id (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Mon, 5 Oct 1992 17:31:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Oct 1992 17:31:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-0); Mon, 5 Oct 1992 17:31:27 -0400 Message-Id: <199210052055.AA20308@home.ans.net> To: yakov@watson.ibm.com Cc: jcurran@nic.near.net, big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: Re: IESG Deliberations on ROAD In-Reply-To: (Your message of Mon, 05 Oct 92 16:40:08 EDT.) <199210052039.AA32693@interlock.ans.net> Date: Mon, 05 Oct 92 16:55:51 -0500 From: Phill Gross To smooth the process I would suggest to form an open IETF working group that will consider and evaluate the criteria. The procedures for this working group may be the same as for any other IETF working group. Can do. Can we illicit volunteers to chair the WG? John, would you be able to do it? In the meantime, I still think we should discuss them by email. Phill From owner-Big-Internet@munnari.oz.au Tue Oct 6 07:40:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23265; Tue, 6 Oct 1992 07:40:51 +1000 (from owner-Big-Internet) Return-Path: Received: from dreggs.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23262; Tue, 6 Oct 1992 07:40:44 +1000 (from pfortin@cisco.com) Received: by dreggs.cisco.com; Mon, 5 Oct 92 14:40:03 -0700 From: Pierre Fortin Message-Id: <9210052140.AA24275@dreggs.cisco.com> Subject: Re: Hop Limit field in SIP To: throop@dg-rtp.dg.com (Dean D. Throop) Date: Mon, 5 Oct 92 14:40:02 MDT Cc: big-internet@munnari.oz.au In-Reply-To: <9210051815.AA05150@walrus>; from "Dean D. Throop" at Oct 5, 92 2:15 pm X-Mailer: ELM [version 2.3 PL11] > A host preparing a packet for transmission would put an expiration > time in the packet. This time time would be the current time plus > some delta. The delta would depend on the destination host. When a > router received the packet, it would compare the expiration time > with the current time and discard the packet if it was too old. Dean, Obvious questions: - universal time (GMT)? - if not, whoever puts in the delta time needs to know the dests time zone - what happens at Daylight Savings switchovers (in different areas of globe; they're not all the same) - etc.? > Dean Throop throop@dg-rtp.dg.com > Cheers, Pierre Fortin (pfortin@cisco.com) (613)782-2912 FAX (613)782-2377 cisco Systems, Inc., 200-440 Laurier Ave. W., Ottawa, ON K1R 7X6 From owner-big-internet@munnari.oz.au Tue Oct 6 08:03:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23819; Tue, 6 Oct 1992 08:03:41 +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 AA20316; Tue, 6 Oct 1992 06:11:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16162; Mon, 5 Oct 92 16:11:44 -0400 Date: Mon, 5 Oct 92 16:11:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210052011.AA16162@ginger.lcs.mit.edu> To: craig@aland.bbn.com, jnc@ginger.lcs.mit.edu Subject: Re: Hop Limit field in SIP Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu How about a real expiration timestamp (e.g. NTP format)? I thought about something like that, but had forgotten about NTP. Would a 32 bit timestamp have enough range (to last) and also be fine enough grain (to prevent a looped packet being around for quite a while before it was noticed? Let's see, at one tick per second, a 32 bit clock lasts about 135 years.. Hmm. Probably needs to be 64; I was thinking the check would be mildly expensive if it was a 64 bit timestamp, but it's at least as fast as updating the hop count and fixing the checksum... Wouldn't the overhead to run NTP be substantial, though? On the other hand, a universal timebase; you can do lots of nifty things with that.... Noel From owner-Big-Internet@munnari.oz.au Tue Oct 6 08:09:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24084; Tue, 6 Oct 1992 08:09:47 +1000 (from owner-Big-Internet) Return-Path: Received: from regal.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24073; Tue, 6 Oct 1992 08:09:36 +1000 (from dkatz@cisco.com) Received: by regal.cisco.com; Mon, 5 Oct 92 15:09:24 -0700 Date: Mon, 5 Oct 92 15:09:24 -0700 From: Dave Katz Message-Id: <9210052209.AA26111@regal.cisco.com> To: pfortin@cisco.com Cc: throop@dg-rtp.dg.com, big-internet@munnari.oz.au In-Reply-To: Pierre Fortin's message of Mon, 5 Oct 92 14:40:02 MDT <9210052140.AA24275@dreggs.cisco.com> Subject: Hop Limit field in SIP NTP timestamps are always UTC, so there's no timezone/DST problems. However, leap seconds would have to be very carefully implemented in order for such a scheme to work. Not to mention that routers would have to have a very high degree of certainty about the current time before joining the routing infrastructure (not unlike making sure your phase relationship is proper before bringing your power plant onto the grid, I suppose, though the results of failing to do so probably aren't nearly as spectacular). Doing all of this reliably is a difficult problem. Come to think of it, I believe there's a discontinuity in the NTP timescale at the point of the leap second--I think that the same NTP second is repeated when a leap second is added, if done properly (if done improperly, all of the slave clocks find themselves one second too far in the future and have to slow down until those higher up the chain catch up). This part of NTP always confused me. From: Pierre Fortin Date: Mon, 5 Oct 92 14:40:02 MDT X-Mailer: ELM [version 2.3 PL11] > A host preparing a packet for transmission would put an expiration > time in the packet. This time time would be the current time plus > some delta. The delta would depend on the destination host. When a > router received the packet, it would compare the expiration time > with the current time and discard the packet if it was too old. Dean, Obvious questions: - universal time (GMT)? - if not, whoever puts in the delta time needs to know the dests time zone - what happens at Daylight Savings switchovers (in different areas of globe; they're not all the same) - etc.? > Dean Throop throop@dg-rtp.dg.com > Cheers, Pierre Fortin (pfortin@cisco.com) (613)782-2912 FAX (613)782-2377 cisco Systems, Inc., 200-440 Laurier Ave. W., Ottawa, ON K1R 7X6 From owner-big-internet@munnari.oz.au Tue Oct 6 08:14:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24146; Tue, 6 Oct 1992 08:14:48 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210052214.24146@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21192; Tue, 6 Oct 1992 06:42:07 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0266; Mon, 05 Oct 92 16:40:09 EDT Date: Mon, 5 Oct 92 16:40:08 EDT From: yakov@watson.ibm.com To: pgross@ans.net, jcurran@nic.near.net Cc: big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: IESG Deliberations on ROAD Ref: Your note of Mon, 05 Oct 92 15:30:04 -0500 >I don't consider the current criteria to be the Ultimate >criteria... To smooth the process I would suggest to form an open IETF working group that will consider and evaluate the criteria. The procedures for this working group may be the same as for any other IETF working group. Yakov. From owner-big-internet@munnari.oz.au Tue Oct 6 08:46:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24850; Tue, 6 Oct 1992 08:47:05 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210052247.24850@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22102; Tue, 6 Oct 1992 07:07:26 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1081; Mon, 05 Oct 92 17:07:12 EDT Date: Mon, 5 Oct 92 17:07:12 EDT From: yakov@watson.ibm.com To: pgross@ans.net Cc: jcurran@nic.near.net, big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: IESG Deliberations on ROAD Ref: Your note of Mon, 05 Oct 92 16:55:51 -0500 >Can we illicit volunteers to chair the WG. Phill, I'll be more than glad to do this, either by myself, or co-chairing it with other person(s). Yakov. From owner-big-internet@munnari.oz.au Tue Oct 6 09:37:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26486; Tue, 6 Oct 1992 09:37:28 +1000 (from owner-big-internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21194; Tue, 6 Oct 1992 06:42:07 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA92328 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Mon, 5 Oct 1992 16:37:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 5 Oct 1992 16:37:45 -0400 Message-Id: <199210052036.AA18668@home.ans.net> To: peter@goshawk.LANL.GOV (Peter S. Ford) Cc: big-internet@munnari.oz.au Subject: Re: Routing architectures In-Reply-To: (Your message of Mon, 05 Oct 92 12:55:39 MST.) <9210051855.AA29712@goshawk.lanl.gov> Date: Mon, 05 Oct 92 16:36:19 -0500 From: Phill Gross .....May I assume the IESG will form a WG to build the criteria needed for their deliberations? Peter, We will certainly do that if the community calls for it. I confess, I'd hoped that we would have some discussion of the criteria on the Big-Internet list, before the Nov IETF. Below is an edited version of the criteria (the full text is in the I-D). What other criteria are important to consider? How could we better characterize and describe the criteria that are already there? Thank, Phill Appendix B INFORMATION AND SELECTION CRITERIA FOR "BIGGER INTERNET ADDRESSES" This section describes the information and criteria which the IESG felt that any new routing and addressing proposal should supply. As the community has a chance to comment on these criteria, and as the IESG gets a better understanding of the issues relating to selection of a new routing and addressing architecture, this section may be revised and published in a separate document. B.1 Description of the Proposed Scheme .... B.2 Changes Required .... This should include at least the following: - Protocol changes in hosts - Protocol changes in exterior router - Protocol changes in interior router - Security and Authentication Changes - Domain name system changes - Network management changes - Changes required to operations tools (e.g., ping, trace-route, etc) - Changes to operational and administration procedures The changes should also include if hosts and routers have their current IP addresses changed. The impact and changes to the existing set of TCP/IP protocols should be described. This should include at a minimum: - IP - ICMP - DNS - ARP/RARP - TCP - UDP - FTP - RPC - SNMP The impact on protocols which use IP addresses as data should be specifically addressed. B.3 Implementation Experience .... B.4 Large Internet Support The proposal should describe how it will scale to support a large internet of 10^^9 networks. ..... B.5 Performance Impact .... B.6 Support for TCP/IP hosts than do not support the new architecture .... B.7 Effect on User Community .... B.8 Deployment Plan Description The proposal should include a deployment plan. It should include the steps required to deploy it. ..... B.9 Future Evolution .... From owner-big-internet@munnari.oz.au Tue Oct 6 10:11:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27448; Tue, 6 Oct 1992 10:12:25 +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 AA21684; Tue, 6 Oct 1992 06:54:52 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from bridge2.NSD.3Com.COM by shark.mel.dit.csiro.au with SMTP id AA17315 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 6 Oct 1992 06:54:57 +1000 Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA24991 (5.65c/IDA-1.4.4nsd for ); Mon, 5 Oct 1992 13:44:35 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA19229 (5.65c/IDA-1.4.4-910725); Mon, 5 Oct 1992 13:44:34 -0700 Message-Id: <199210052044.AA19229@remmel.NSD.3Com.COM> To: Tony Li Cc: big-internet@munnari.oz.au Subject: Re: Routing architectures In-Reply-To: Your message of "Sun, 04 Oct 92 21:42:47 PDT." <9210050442.AA23659@lager.cisco.com> Date: Mon, 05 Oct 92 13:44:33 -0700 From: tracym@NSD.3Com.COM >This is a non-problem as the route computation is done entirely by >your local policy routing box. You can, conceptually, have it spend ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >very little or lots of time picking a perfect route. You (or your >vendor) get to "program" whatever knobs you want. I just picked up on this one phrase, which I've been thinking about for some time, and thought that it ought to get aired more fully. Please accept the following should's and ought's as a lazy way of arguing a point without fully justifying all of the details. I suggest that one of the critical issues for the future of both high performance and complex routing is that routing computations be extracted from the individual boxes and performed on the latest generation of high-performance workstation. You could, of course, dedicate a work-station per router, but a better approach would be to allow the routing, especially at the inter-domain level, be performed in much the same way as DNS and other directory services, in a set of hosts properly configured for the job. IDPR has essentially this feature. This is not to say that individual routers shouldn't run routing protocols. They should, at the very least, dynamically determine their local topology and be able to perform local routing. But beyond about 256 networks (and perhaps 25000 hosts) there ought to be routing services to take the memory and computational burdens off the packet switches. Tracy From owner-big-internet@munnari.oz.au Tue Oct 6 11:32:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29821; Tue, 6 Oct 1992 11:32:24 +1000 (from owner-big-internet) Return-Path: Received: from regal.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23546; Tue, 6 Oct 1992 07:53:14 +1000 (from dkatz@cisco.com) Received: by regal.cisco.com; Mon, 5 Oct 92 14:51:05 -0700 Date: Mon, 5 Oct 92 14:51:05 -0700 From: Dave Katz Message-Id: <9210052151.AA25324@regal.cisco.com> To: pgross@ans.net Cc: yakov@watson.ibm.com, jcurran@nic.near.net, big-internet@munnari.oz.au, iesg@nri.reston.va.us In-Reply-To: Phill Gross's message of Mon, 05 Oct 92 16:55:51 -0500 <199210052055.AA20308@home.ans.net> Subject: IESG Deliberations on ROAD Can we elicit licit volunteers? Illicit volunteers have accountability problems. :-) Date: Mon, 05 Oct 92 16:55:51 -0500 From: Phill Gross To smooth the process I would suggest to form an open IETF working group that will consider and evaluate the criteria. The procedures for this working group may be the same as for any other IETF working group. Can do. Can we illicit volunteers to chair the WG? John, would you be able to do it? In the meantime, I still think we should discuss them by email. Phill From owner-big-internet@munnari.oz.au Tue Oct 6 13:05:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02703; Tue, 6 Oct 1992 13:05:58 +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 AA24373; Tue, 6 Oct 1992 08:28:59 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA01811; Mon, 5 Oct 92 16:27:54 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA01239; Mon, 5 Oct 92 16:27:51 MDT Message-Id: <9210052227.AA01239@goshawk.lanl.gov> To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: Routing architectures In-Reply-To: Your message of Fri, 02 Oct 92 09:24:43 -0700. <9210021624.AA26714@aland.bbn.com> Date: Mon, 05 Oct 92 16:27:50 MST From: peter@goshawk.lanl.gov >>> We're in the game of building infrastructures, so we can't quite change >>> the infrastructure as fast as we can change the computers attached to it. >>> I think 20 years is conservative in terms of required duration. Craig, I believe you are correct, we must be very conservative in planning for the future Internet. The idea of planning for at least 20 years appeals to me. It is tempting to think that we may need a packet format which effectively has an infinite address space. Perhaps we will need NSAPs to go over 20 bytes? Or perhaps IPAE needs to plan for IPAEing IPAE. cheers, peter From owner-big-internet@munnari.oz.au Tue Oct 6 13:45:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04181; Tue, 6 Oct 1992 13:45:28 +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 AA26456; Tue, 6 Oct 1992 09:36:25 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16908; Mon, 5 Oct 92 19:35:36 -0400 Date: Mon, 5 Oct 92 19:35:36 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210052335.AA16908@ginger.lcs.mit.edu> To: pgross@ans.net, yakov@watson.ibm.com Subject: Re: IESG Deliberations on ROAD Cc: big-internet@munnari.oz.au, iesg@nri.reston.va.us, jnc@ginger.lcs.mit.edu I'd prefer someone without any connection to any proposal, so that we don't wind up 'sole-sourcing' the criteria. I don't know who would fit this criteria; of the people who've been active on the mailing list, Craig Partridge comes as close as anyone. Noel From owner-big-internet@munnari.oz.au Tue Oct 6 14:04:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05041; Tue, 6 Oct 1992 14:04:57 +1000 (from owner-big-internet) Return-Path: Received: from regal.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24387; Tue, 6 Oct 1992 08:30:34 +1000 (from dkatz@cisco.com) Received: by regal.cisco.com; Mon, 5 Oct 92 15:14:44 -0700 Date: Mon, 5 Oct 92 15:14:44 -0700 From: Dave Katz Message-Id: <9210052214.AA26313@regal.cisco.com> To: jnc@ginger.lcs.mit.edu Cc: craig@aland.bbn.com, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Mon, 5 Oct 92 16:11:44 -0400 <9210052011.AA16162@ginger.lcs.mit.edu> Subject: Hop Limit field in SIP The NTP timestamp rolls over in 2035, but unless a packet gets loose in the network for decades, there shouldn't be too much of a problem disambiguating the time. NTP is a pretty low overhead operation (if you can do it in an LSI-11...) I've been listening to Dave Mills too much, methinks. Date: Mon, 5 Oct 92 16:11:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) How about a real expiration timestamp (e.g. NTP format)? I thought about something like that, but had forgotten about NTP. Would a 32 bit timestamp have enough range (to last) and also be fine enough grain (to prevent a looped packet being around for quite a while before it was noticed? Let's see, at one tick per second, a 32 bit clock lasts about 135 years.. Hmm. Probably needs to be 64; I was thinking the check would be mildly expensive if it was a 64 bit timestamp, but it's at least as fast as updating the hop count and fixing the checksum... Wouldn't the overhead to run NTP be substantial, though? On the other hand, a universal timebase; you can do lots of nifty things with that.... Noel From owner-big-internet@munnari.oz.au Tue Oct 6 14:30:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05896; Tue, 6 Oct 1992 14:30:59 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210060430.5896@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27647; Tue, 6 Oct 1992 10:20:28 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 5851; Mon, 05 Oct 92 20:13:39 EDT Date: Mon, 5 Oct 92 20:13:39 EDT From: yakov@watson.ibm.com To: jnc@ginger.lcs.mit.edu Cc: pgross@ans.net, big-internet@munnari.oz.au Subject: IESG deliberation on ROAD >I don't know who would fit this criteria... Noel, I volunteered to chair or co-chair the WG. I hope I would come close to fitting the criteria. Yakov. From owner-Big-Internet@munnari.oz.au Tue Oct 6 14:59:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06720; Tue, 6 Oct 1992 14:59:44 +1000 (from owner-Big-Internet) Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06708; Tue, 6 Oct 1992 14:59:22 +1000 (from mak@merit.edu) Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA21330; Tue, 6 Oct 92 00:58:41 -0400 Received: by home.merit.edu (4.1/client-0.9) id AA16707; Tue, 6 Oct 92 00:58:39 EDT From: mak@merit.edu Message-Id: <9210060458.AA16707@home.merit.edu> To: David R. Oran Cc: Ross Callon , solensky@andr.ub.com, big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of "Mon, 05 Oct 92 15:32:26 EDT." <921005153226.12546@sneezy.lkg.dec.com> Date: Tue, 06 Oct 92 00:58:37 -0400 Dave, You make some good points, and we've considered some of these issues in the NSFNET and ANS backbone design. For example, the T1 network uses the NSS architecture which is actually multiple routers into one. In this system the TTL is not decremented except once as it moves through the NSS cluster. This design was changed on the T3 network, where there are multiple CNSS nodes at each POP (switching center) that may represent hops (hippities?) for transit packets, with ENSS nodes on tail circuits from a CNSS. The TTL is decremented by all CNSS's and ENSS's. The total hop count across the T3 backbone is 6, plus one for each transit city. We've also come to some conclusions about transit delay vs. hop count. It seems that with the current design of packet transfers directly between smart cards without involving the system kernel, the store and forward delay is minimal compared to the speed-of-light transmission time for long haul links. In future redesigns of the backbone ANS may consider increasing the diameter/hopcount for other gains such as reliability. I do think the total TTL is an issue for further study, since it is likely that the total diameter of the internet will grow. Given the possible architectures for IP (or CLNP) backbones there might be wildly different hopcounts when datagrams traverse multiple transit nets. An idea that we kicked around a while back was to have two levels of TTL fields in the header, one for number of transit nets traversed, and the other for hops within the routing domain. Call it hippities vs. hops? Mark > From: David R. Oran > To: Ross Callon > CC: solensky@andr.ub.com, big-internet@munnari.oz.au > > > >> Quite likely in an ideal world we could indeed make a 300 hop > > path work well. However, in an ideal world would we *want* to > > do so? > > > I think Ross is right, as long as one's mind set has hops being > Hopppppppp....pppps, i.e. are long, pass through significant switching > equipment at each switching point, iow: are what we think of as > network/internet hops today. > > I would be surprised if someone could make a credible case for Internet > paths that are longer than 255 "traditional" hops. As someone already > pointed out, the International phone system is only 12 hops in diameter, > and even the most optimistic predictions get it to 15 hops in the next 50 > years. The graph-theoretical rule of thumb has worked quite well in many > problem domains: the diameter grows as the loglog of the number of nodes. > > Some folks, however, have posited that future switching architectures might > have hippities that need to be dealt with in the architecture as hops. If > that is the case then the paths might indeed get considerably longer. > > This connundrum is a fundamental limitation of using hops rather > than some quantity which is normalized to either time or resource > consumption. The problem with TTL or resource budgets is the > difficulty of processing them in the forwarding path of a switch. > > Perhaps there might be a compromise here, which is to define a bigger > field, like 16 bits, but to have two sorts of decrements, a decrement by > 1 for a "hippity", and a decrement by 16 for a "hop". You define a hippity > as a link traversal either inside a switch, or between private, low latency > links (i.e. not internet hops) between a pair of switches, as might be the > case with ATM. > > That way packets eating large amounts of multiple-organizational resources > get damped quickly without preventing the micro-level switching > infrastructure from eating the whole dynamic range of the hop count. > > Just a thought..., > > -+-+-+-+-+-+-+ > David R. Oran Phone: + 1 508 486-7377 > Digital Equipment Corporation Fax: + 1 508 486-5279 > LKG 1-2/A19 Email: oran@lkg.dec.com > 550 King Street > Littleton, MA 01460 From owner-big-internet@munnari.oz.au Tue Oct 6 15:02:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06781; Tue, 6 Oct 1992 15:02:42 +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 AA27263; Tue, 6 Oct 1992 10:04:53 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11682>; Mon, 5 Oct 1992 17:04:28 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 5 Oct 1992 17:04:19 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of "Mon, 05 Oct 92 15:09:24 PDT." <9210052209.AA26111@regal.cisco.com> Date: Mon, 5 Oct 1992 17:04:11 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct5.170419pdt.10779@skylark.parc.xerox.com> I can't believe people are seriously considering replacing the simple mechanism of a hop counter with the infinitely more complex mechanism of expiration timestamps and synchronized clocks, for killing packets caught in loops. Sure, there might be all sorts of nice things you could do if all the hosts and routers in the Internet had synchronized clocks, but it seems silly to me to make the basic operation of the internet layer depend on it, if it doesn't have to. Besides, it doesn't solve the problem. Packets sent from the Earth to the Moon or Mars will need a long expiration time, but if they get caught in a loop before leaving the planet, they will probably consume more resources waiting for their expiration times to lapse than packets with a hop limit of 50,000 ever would. Steve From owner-big-internet@munnari.oz.au Tue Oct 6 15:05:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06905; Tue, 6 Oct 1992 15:06:02 +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 AA26945; Tue, 6 Oct 1992 09:54:24 +1000 (from deering@parc.xerox.com) Received: from alpha.Xerox.COM by shark.mel.dit.csiro.au with SMTP id AA18717 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 6 Oct 1992 08:54:32 +1000 Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11658>; Mon, 5 Oct 1992 15:41:23 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 5 Oct 1992 15:41:14 -0700 To: Juha Heinanen Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: Your message of "Sat, 03 Oct 92 01:33:16 PDT." <9210030834.24941@munnari.oz.au> Date: Mon, 5 Oct 1992 15:41:06 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct5.154114pdt.10779@skylark.parc.xerox.com> Juha wrote: > One thing I don't > like in the current model is that the interfaces, instead of boxes, are > assigned addresses. This is a big mistake and should be corrected in > the next version of IP architecture whatever that will be. I agree it's annoying sometimes, but I disagree that it's a big mistake. To support efficient routing on addresses, they must contain some topologically-significant structure. Given that a single box may be connected to the Internet at multiple, widely-separated points in the topology, you cannot always give it a single, topologically-significant address. If you want each box to have only one address, either you'll have to route on something other than addresses, or you'll have to be willing to propagate (or manually configure) "host routes" for some boxes throughout large numbers of routing domains. When I first read about NSAP addresses, and how they identified points inside of a box rather than interfaces, I thought, "That's nice; I wonder how that works?" Practically speaking, it doesn't work. Yes, a box with more than one interface in the same IS-IS Level 1 Area only needs one address, but apart from that special case (which is probably not even the most common case of multi-homing), boxes with multiple interfaces either get assigned multiple NSAP addresses, one for each interface, or they are supported by (the functional equivalent of) host-route leaking and/or manual configuration, neither of which scale. (Why do I have the feeling that I'm about to get severely corrected by some NSAP addressing experts...?) Steve From owner-big-internet@munnari.oz.au Tue Oct 6 15:40:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08083; Tue, 6 Oct 1992 15:40:41 +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 AA26951; Tue, 6 Oct 1992 09:54:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16940; Mon, 5 Oct 92 19:54:46 -0400 Date: Mon, 5 Oct 92 19:54:46 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210052354.AA16940@ginger.lcs.mit.edu> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: Hop Limit field in SIP Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu That sounds like a *ridiculous* generalization to me. Well, perhaps '*ridiculously*' was a bit too hyperbolic (sic :-)! Perhaps 'extremely generous' would have been more felicitous. - Even though the median link bandwidth may be large, we might still want to support relatively low speed links in the Internet, especially metropolitan and long-haul wireless links for which bandwidth may never become "dirt cheap", due to bounded spectrum availability. Good point, but the range of speeds is moving up in the Internet, not just the top end. Many of you use 300 baud modems any more? 1200's aren't long for this world either... Yes, spectrum is fixed, but just as we are getting better at shoving bits down a fixed bandwidth on a phone line, ingenuity will probably get more into a 5 pound sack in wireless too, through smaller cell sizes, etc. The smaller you can keep the header, the more such packets you can accommodate in your network, and the lower the queuing delays they suffer. Yeah, but the calculation is complicated. To the extent that total packet time through the network is transmission time, faster link speeds will help handle large packets without a big penalty in real time, and higher speed routers should cut the switching time *and* delay through routers. Still, a good point. - The bigger the fields, the more memory accesses might be required by hosts and routers to process the packet headers. I see future high-speed routers as having hardware support for forwarding 'normal' packets, so I don't think this is a big issue. Hosts, maybe... there might be *some* benefit in not, say, making the Hop Limit field 64 bits wide 64 bits would definitely be '*ridiculous*'! 16 bits, on the other hand, would be 'extremely generous'! People points about going around a loop 16K times, etc, are very valid. Even *I* have a hard time conceiving of a network with diameter 65K! The penalty paid by connectionless protocols is having to carry around and process bigger packet headers than connection-oriented protocols; I think it's worthwhile to try to keep that penalty no larger than necessary. This is basically the point I made about state tradeoff.. if we wind up with *soft* state (i.e. *not* critical state; we *have* to keep the fate sharing architectural principle) in the routers *anyway*, perhaps it's worth turning that knob a little harder to minimize the packet header size, for all the good reasons Steve mentioned. For example, say, leave out that long complex heirarchical address from most packets, (just like we leave out the DNS name) and leave just the source and destination EID's, and use these to tag a routing cache entry.... :-) "Subvert the dominant paradigm!" Think radically! Cast out (and down) all sacred cows, previous assumptions, and existing prejudices! "L'audace, l'audace, tous-jours l'audace!" Noel From owner-big-internet@munnari.oz.au Tue Oct 6 15:48:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08369; Tue, 6 Oct 1992 15:48:20 +1000 (from owner-big-internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29214; Tue, 6 Oct 1992 11:06:17 +1000 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA19548); Mon, 5 Oct 92 20:04:59 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9210060104.AA19548@is.rice.edu> Subject: Re: Hop Limit field in SIP To: pfortin@cisco.com (Pierre Fortin) Date: Mon, 5 Oct 92 20:04:59 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <9210052140.AA24275@dreggs.cisco.com>; from "Pierre Fortin" at Oct 5, 92 2:40 pm X-Mailer: ELM [version 2.3 PL11] Pierre Fortin > > > A host preparing a packet for transmission would put an expiration > > time in the packet. This time time would be the current time plus > > some delta. The delta would depend on the destination host. When a > > router received the packet, it would compare the expiration time > > with the current time and discard the packet if it was too old. > > Dean, > > Obvious questions: > > - universal time (GMT)? To parphrase... Of course! Is there any reason to NOT use UTC? -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-big-internet@munnari.oz.au Tue Oct 6 16:11:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09006; Tue, 6 Oct 1992 16:11:55 +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 AA29323; Tue, 6 Oct 1992 11:12:16 +1000 (from tli@cisco.com) Received: from lager.cisco.com by shark.mel.dit.csiro.au with SMTP id AA20440 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 6 Oct 1992 10:15:00 +1000 Received: by lager.cisco.com; Mon, 5 Oct 92 17:12:00 -0700 Date: Mon, 5 Oct 92 17:12:00 -0700 From: Tony Li Message-Id: <9210060012.AA10530@lager.cisco.com> To: tracym@NSD.3Com.COM Cc: big-internet@munnari.oz.au In-Reply-To: tracym@NSD.3Com.COM's message of Mon, 05 Oct 92 13:40:55 -0700 <199210052040.AA19222@remmel.NSD.3Com.COM> Subject: Routing architectures I just picked up on this one phrase, which I've been thinking about for some time, and thought that it ought to get aired more fully. Please accept the following should's and ought's as a lazy way of arguing a point without fully justifying all of the details. I'd suggest that one of the critical issues for the future of both high performance and complex routing is that routing computations be extracted from the individual boxes and performed on the latest generation of high-performance workstation. You could, of course, dedicate a work-station per router, but a better approach would be to allow the routing, especially at the inter-domain level, be performed in much the same way as DNS and other directory services, in a set of hosts properly configured for the job. IDPR has essentially this feature. I agree that this should be allowed. I don't believe that you MUST run it in this mode. I would think that one or two high end routers with lotsa guts could also work well. This has the advantage that there is one less point of failure in the system. Tony From owner-big-internet@munnari.oz.au Tue Oct 6 16:30:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09611; Tue, 6 Oct 1992 16:30:38 +1000 (from owner-big-internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00336; Tue, 6 Oct 1992 11:47:35 +1000 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA20208); Mon, 5 Oct 92 20:47:02 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9210060147.AA20208@is.rice.edu> Subject: Re: IESG Deliberations on ROAD To: pgross@ans.net (Phill Gross) Date: Mon, 5 Oct 92 20:47:01 CDT Cc: big-internet@munnari.oz.au, iesg@nri.reston.va.us In-Reply-To: <199210052055.AA20308@home.ans.net>; from "Phill Gross" at Oct 5, 92 4:55 pm X-Mailer: ELM [version 2.3 PL11] Phill Gross > > > To smooth the process I would suggest to form an open IETF working > group that will consider and evaluate the criteria. > The procedures for this working group may be the same as > for any other IETF working group. > > Can do. > > Can we illicit volunteers to chair the WG? John, would you be able > to do it? > I still think that this can be a topic that is discussed in the orad WG. Do we really NEED anonther group? -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-Big-Internet@munnari.oz.au Tue Oct 6 17:32:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11480; Tue, 6 Oct 1992 17:33:14 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11474; Tue, 6 Oct 1992 17:32:48 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Tue, 6 Oct 92 00:32:23 -0700 Date: Tue, 6 Oct 92 00:32:23 -0700 From: Tony Li Message-Id: <9210060732.AA22468@lager.cisco.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu - The bigger the fields, the more memory accesses might be required by hosts and routers to process the packet headers. I see future high-speed routers as having hardware support for forwarding 'normal' packets, so I don't think this is a big issue. Hosts, maybe... FYI: current high-speed routers _already_ have some hardware support for forwarding normal packets. Tony From owner-big-internet@munnari.oz.au Tue Oct 6 19:29:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15186; Tue, 6 Oct 1992 19:29:51 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210060929.15186@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11078; Tue, 6 Oct 1992 17:16:23 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <09742-0@datanet.tele.fi>; Tue, 6 Oct 1992 09:15:57 +0200 To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: <92Oct5.154114pdt.10779@skylark.parc.xerox.com> "deering@parc.xerox.com" Date: Tue, 6 Oct 1992 09:15:57 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi steve, i didn't say that a box can have only one address. it can have any number, but none of them should be an address of an interface. i repeat, any routing model that requires interfaces to have addresses is very bad for locigal reasons and totally unscalable for modern multiaccess subnetwork technologies, such as frame relay and atm, where there can exist hundreds of non-broadcast neighbors behind each physical interface. trying to route current IP with ospf or cisco igrp over such media is a management nightmare. so whatever the new architecture is, no addresses for interfaces is very high on my requirements list. -- juha From owner-Big-Internet@munnari.oz.au Tue Oct 6 20:28:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16852; Tue, 6 Oct 1992 20:28:21 +1000 (from owner-Big-Internet) Return-Path: Received: from is.rice.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16849; Tue, 6 Oct 1992 20:28:10 +1000 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA24888); Tue, 6 Oct 92 05:28:03 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9210061028.AA24888@is.rice.edu> Subject: Re: Hop Limit field in SIP To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 6 Oct 92 5:28:03 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <9210052354.AA16940@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 5, 92 7:54 pm X-Mailer: ELM [version 2.3 PL11] Noel Chiappa > > Good point, but the range of speeds is moving up in the Internet, not just the > top end. Many of you use 300 baud modems any more? 1200's aren't long for this > world either... > Now hold on there. Part of what will drive the "big-internet" will be new users. In our neck of the woods, this is turning out to be K12 and libraries. The libraries are getting big (T1) pipes, but the K12 folks are, for the most part, using -donated- equipment. Perhaps this is 1200 baud heaven. I also seem to remember something about the need to support the same functionality over a wide range of performance points. Ken Olson did it with the VAX architecture, can we do it with the big-internet? 1200baud through 200 Gbit. -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892 From owner-big-internet@munnari.oz.au Tue Oct 6 21:15:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18347; Tue, 6 Oct 1992 21:16:37 +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 AA08408; Tue, 6 Oct 1992 15:49:54 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11726>; Mon, 5 Oct 1992 22:49:28 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 5 Oct 1992 22:49:18 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of "Mon, 05 Oct 92 06:17:52 PDT." <9889.718291072@munnari.oz.au> Date: Mon, 5 Oct 1992 22:49:10 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct5.224918pdt.10779@skylark.parc.xerox.com> Robert Elz wrote: > At the minute I think I'd set the initial hop count to something > around 64, maybe 80 It's a major hassle to have to update all the hosts every n years to use a larger initial hop limit, but it sounds like that is what you are advocating. If, in the future, you expect that you might raise the initial hop limit to, say, 255, then at that point you will be implicitly accepting that a packet might go around a loop 127 times (a minimal loop of two routers, starting one hop beyond the sender). Why not just accept it now, and always use 255 (or whatever your favorite upper bound is) as the initial hop limit in all packets? Dave Borman wrote: > While the packet is within an area, only the interior hop count is > used. When it passes through a border gateway, the external hop > count is used, and the interior hop count gets reset upon forwarding. This implies that there are unambiguous boundaries between what is "internal" and what is "external", at least as far as hop count handling goes. Not necessarily a bad thing, in my opinion, but judging from recent messages, others may not approve. Dave Oran wrote: > Perhaps there might be a compromise here, which is to define a bigger > field, like 16 bits, but to have two sorts of decrements, a decrement by > 1 for a "hippity", and a decrement by 16 for a "hop". You define a hippity > as a link traversal either inside a switch, or between private, low latency > links (i.e. not internet hops) between a pair of switches, as might be the > case with ATM. This assumes that a forwarding entity can tell the difference between a hippity and a hop. If that's the case, I don't see the need for hippity decrementing -- either loops are impossible within the switch or "distributed router" by design (for example, if there is only a single, shared routing table, permanent inconsistencies that give rise to loops may be impossible, or if it's a mesh of ATM switches, the virtual circuit nature of ATM would prevent loops), or else local mechanisms can be applied to prevent loops, such as prepending a hippety limit field to the front of packets that enter the switch and stripping it off when they leave (similar to the technique used in some circulating ATM fabrics to maintain cell ordering). Thus, loop prevention within a switch or distributed router could be defined to be a local problem, and the hop limit field in the internet header could be specified as being used for "real hops" only. Steve From owner-Big-Internet@munnari.oz.au Tue Oct 6 21:31:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18907; Tue, 6 Oct 1992 21:32:03 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18903; Tue, 6 Oct 1992 21:31:54 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA78326 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Tue, 6 Oct 1992 07:31:27 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Oct 1992 07:31:27 -0400 Message-Id: <199210061130.AA30880@home.ans.net> To: Dave Katz Cc: big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: Re: IESG Deliberations on ROAD In-Reply-To: (Your message of Mon, 05 Oct 92 14:51:05 MST.) <9210052151.AA25324@regal.cisco.com> Date: Tue, 06 Oct 92 07:30:01 -0500 From: Phill Gross > : Can we elicit licit volunteers? Illicit volunteers have accountability problems. :-) Dave, Boy, I *hate* it when that happens! That's one of my principle pet peeves. And, to think, I used to get so many complements on my spelling and grammer. Phill From owner-Big-Internet@munnari.oz.au Tue Oct 6 22:14:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20410; Tue, 6 Oct 1992 22:14:11 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210061214.20410@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20403; Tue, 6 Oct 1992 22:14:00 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1316; Tue, 06 Oct 92 08:13:55 EDT Date: Tue, 6 Oct 92 08:13:54 EDT From: yakov@watson.ibm.com To: pgross@ans.net, peter@goshawk.LANL.GOV Cc: big-internet@munnari.oz.au Subject: Routing architectures Ref: Your note of Mon, 05 Oct 92 16:36:19 -0500 >>May I assume the IESG will form a WG to build the criteria for >>their deliberations ? >We will certainly do that if the community calls for it. Phill, I think that the decision is very important one, and therefore the IETF community should welcome the creation of such WG. Yakov From owner-Big-Internet@munnari.oz.au Tue Oct 6 22:42:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21356; Tue, 6 Oct 1992 22:42:18 +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 AA21349; Tue, 6 Oct 1992 22:42:09 +1000 (from kasten@ftp.com) Received: by ftp.com id AA22970; Tue, 6 Oct 92 08:40:59 -0400 Date: Tue, 6 Oct 92 08:40:59 -0400 Message-Id: <9210061240.AA22970@ftp.com> To: throop@dg-rtp.dg.com Subject: TIME to die (was Re: Hop Limit field in SIP) From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au Dean and Craig, This is an idea with merit. I imagine that the load on the routers will be much less than we have been supposing. Any estimated expiration time has to be sufficiently far in the future relative to the packet's creation in order to be able to ignore minor variations in forwarding time on the part of the routers, variability in the time required to acquire Ethernet-like media and so on. There is also the speed of light to be aware of -- if I remember right, the proagation delay for light to circle the earth is something in the order of 150ms. We have traditionally set TTL fields based on the maximum diameter of the network and not how far we want the packet to go (traceroute excepted). So, it seems that a packet would need to live for at least 150 (naturally the real time would be much larger since we would have to account of switching times, queueing delays, etc, etc). Without doing any rigorous analysis, I would guess that the timestamp could be in units of 50 to 100 ms. One problem -- what about traceroute :-) -- frank kastenholz From owner-big-internet@munnari.oz.au Wed Oct 7 02:08:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29155; Wed, 7 Oct 1992 02:08:55 +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 AA23630; Tue, 6 Oct 1992 23:49:57 +1000 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.57/Ultrix3.0-C) id AA14139; Tue, 6 Oct 92 09:49:43 -0400 Message-Id: <9210061349.AA14139@boa.gsfc.nasa.gov> Subject: Re: Hop Limit field in SIP To: bmanning@is.rice.edu (William Manning) Date: Tue, 6 Oct 92 9:49:42 EDT From: Dick desJardins Cc: big-internet@munnari.oz.au In-Reply-To: <9210061028.AA24888@is.rice.edu>; from "William Manning" at Oct 6, 92 5:28 am X-Mailer: ELM [version 2.3 PL11] > > Noel Chiappa > > > > Good point, but the range of speeds is moving up in the Internet, not just the > > top end. Many of you use 300 baud modems any more? 1200's aren't long for this > > world either... > > > > Now hold on there. Part of what will drive the "big-internet" will be new > users. In our neck of the woods, this is turning out to be K12 and > libraries. The libraries are getting big (T1) pipes, but the K12 folks > are, for the most part, using -donated- equipment. Perhaps this is 1200 > baud heaven. I also seem to remember something about the need to support > the same functionality over a wide range of performance points. Ken Olson > did it with the VAX architecture, can we do it with the big-internet? > 1200baud through 200 Gbit. > > -- > Regards, > Bill Manning bmanning@rice.edu PO Box 1892 > 713-285-5415 713-527-6099 Houston, Texas > R.U. (o-kome) 77251-1892 Bill, I agree with you. Here's an example: NASA and the world space agencies are planning to make most of the world's earth science data available to scientists and other researchers (e.g., planning and development regional agencies) on the Internet and high performance extensions thereof. At a meeting two weeks ago, the agencies identified three "levels" of network performance: Level 1: Access to catalogs (e.g., TELNET). Level 2: Access to online browse data, and fast data delivery of selected data. Level 3: On-demand videoconferencing with other scientists, scientific groupware (shared image manipulation, e.g.), fast data delivery of all data. The idea is that Level 1 would be the low-end technology that you have identified as "K-12", but it would be worldwide service. Level 2 would be equivalent to the better connected sites today, i.e., Ethernets and above, multiple T1s, etc. Level 3 would be NREN technologies. The point is that Level 1 isn't going to go away. I do expect there will be significant availability of 64 kbps and 128 kbps dialup service via ISDN at today's phone prices, however. So let's make sure SIP will support all levels of performance. Dick dJ (If SIP works, and we are able to incorporate into it the TOS/policy routing issues, I for one would vote to make it CLNPv2 and be done with it. That's assuming we get it right, of course. That's a personal opinion, of course.) > From owner-big-internet@munnari.oz.au Wed Oct 7 02:21:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29588; Wed, 7 Oct 1992 02:21:20 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210061621.29588@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24794; Wed, 7 Oct 1992 00:09:10 +1000 (from kwe2@BBN.COM) From: "Kent W. England" Subject: Re: IESG Deliberations [criteria] To: pgross@ans.net Cc: big-internet@munnari.oz.au In-Reply-To: <199210052036.AA18668@home.ans.net> Date: Tue, 6 Oct 92 10:07:22 EDT Mail-System-Version: >Below is an edited version of the criteria (the full text is in the I-D). > >What other criteria are important to consider? How could we better >characterize and describe the criteria that are already there? > >Thank, >Phill > >Appendix B INFORMATION AND SELECTION CRITERIA FOR "BIGGER INTERNET ADDRESSES" > I would suggest that we let those who wish to have their proposals considered start this process, adding additional criteria that they think are important and that their proposals address. --Kent PS: My own comments concern the importance of: - Syntax and semantics of names, identifiers and addresses which is not specifically included in Phill's edited outline. My proposed additions: "Proposals should address the manner in which data sources and sinks are identified and addressed, describe how current domain names and IP addresses would be used/translated/mapped in their scheme, how proposed new identifier and address fields and semantics are used, and should describe the issues involved in administration of these id and address spaces according to their proposal. The deployment plan should address how these new semantics would be introduced and backward compatibility maintained. Any overlays in the syntax of these protocol structures should be clearly identified and conflicts resulting from syntactic overlay of functionality should be clearly addressed in the discussion of the impact on administrative assignment." From owner-big-internet@munnari.oz.au Wed Oct 7 02:32:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00145; Wed, 7 Oct 1992 02:32:09 +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 AA25337; Wed, 7 Oct 1992 00:25:04 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA16248; Tue, 6 Oct 92 08:24:46 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA04352; Tue, 6 Oct 92 08:24:45 MDT Message-Id: <9210061424.AA04352@goshawk.lanl.gov> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: pgross@ans.net, yakov@watson.ibm.com, craig@aland.bbn.com, big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: Re: IESG Deliberations on ROAD In-Reply-To: Your message of Mon, 05 Oct 92 19:35:36 -0400. <9210052335.AA16908@ginger.lcs.mit.edu> Date: Tue, 06 Oct 92 08:24:44 MST From: peter@goshawk.lanl.gov Noel, This notion that we need to find unaffiliated chairs for WGs is one which on the surface sounds great but in fact is insidious. The IETF works on the basis of rough consensus which depends on bringing together a diversity of ideas in a manner which results in a good solution to a problem. In modern management parlance this is known as positive conflict resolution (win-win). In the IETF you want knowledgable people to manage this process. This will support candidates who are practitioners of the field and in many cases have done extensive work in the areas where positive conflict resolution is occuring. These chairs will have opinions and beliefs, but given that they subscribe to conflict resolution in the first place (why else would they participate in the IETF!!!) they are people of high character and are able to listen and understand other points of view, and will at the end subscribe to the consensus, or state exactly why there is no opportunity for consensus. My read on Yakov is that he would fit the bill. My read on Craig (even though he is affiliated with the IPAE effort :-)), is that he too fits the bill. Hence, On to the WG proposal: Name of WG: ROADBED Chairs: Yakov and Craig Area: Routing and Addressing (Bob Hinden, hinden@eng.sun.com ) Charter: Establish Criteria for ROAD deliberations Deliverables: Strawman, done RFC XXXX Dec 92 with regards, peter From owner-Big-Internet@munnari.oz.au Wed Oct 7 03:05:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01176; Wed, 7 Oct 1992 03:05:39 +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 AA01173; Wed, 7 Oct 1992 03:05:30 +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 3436; Tue, 06 Oct 92 13:04:27 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 5164; Tue, 06 Oct 92 13:04:26 EDT Date: Tue, 06 Oct 92 12:53:41 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Hop Limit field in SIP To: Craig Partridge , Noel Chiappa Cc: big-internet@munnari.oz.au In-Reply-To: <9210052020.AA13416@aland.bbn.com> Message-Id: <921006.125341.EDT.VALDIS@vtvm1.cc.vt.edu> On Mon, 05 Oct 92 13:20:31 -0700 you said: > My understanding is that the cost of running NTP is largely a function >of the precision in clocks that you want and the speed at which a clock >must converge. If you only want to bound packet lifetimes to the 100s of >ms, I don't believe the load is very much. The NTP version 3 protocol is *quite* net-friendly. In order to keep a machine with a reasonably well-behaved local clock withint 10ms of UTC, it only requires on the order of 8-10 packets every 1024 seconds. This is assuming that each router would peer with 2 or 3 adjacent routers for time synchronization. This would have the added advantage that all organizations connected to the Internet would get "free of charge" a good time service - which will almost certainly be an issue in the higher-level protocols as we attempt to design an ubiquitous security service (currently, Kerberos and DCE carry around a timestamp to prevent replay attacks, and I see no reason to expect this trend to cease). Having said this, I'm not sure if a timestamp wins over a hopcount - I *like* the idea of a timestamp, now if only somebody can figure out how to do a 'traceroute' using one. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Wed Oct 7 04:39:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03723; Wed, 7 Oct 1992 04:39:46 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03716; Wed, 7 Oct 1992 04:39:38 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA70334 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Tue, 6 Oct 1992 14:39:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 6 Oct 1992 14:39:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Oct 1992 14:39:09 -0400 Date: Tue, 6 Oct 1992 14:37:09 -0400 From: Dennis Ferguson Message-Id: <199210061837.AA29101@foo.ans.net> To: dkatz@cisco.com Subject: Re: Hop Limit field in SIP Cc: big-internet@munnari.oz.au > NTP timestamps are always UTC, so there's no timezone/DST problems. However, > leap seconds would have to be very carefully implemented in order for > such a scheme to work. Not to mention that routers would have to have a > very high degree of certainty about the current time before joining the > routing infrastructure (not unlike making sure your phase relationship is > proper before bringing your power plant onto the grid, I suppose, though > the results of failing to do so probably aren't nearly as spectacular). > > Doing all of this reliably is a difficult problem. Yes, this is true, but in addition to reliability there is a problem of chickens and eggs. If you need a synchronized clock to send datagrams, how are you going to send NTP datagrams to synchronize your clock? > Come to think of it, I believe there's a discontinuity in the NTP > timescale at the point of the leap second--I think that the same > NTP second is repeated when a leap second is added, if done properly > (if done improperly, all of the slave clocks find themselves one second > too far in the future and have to slow down until those higher up the > chain catch up). This part of NTP always confused me. When a leap second is added (leap seconds could need to be deleted too, when the earth starts in on its final approach to the sun, but I don't think even IPv7 will last long enough to see this) the NTP timescale jumps back and replays a second. There is a signaling mechanism in the protocol which is supposed to make everyone leap back at once, which would mean in principle you'd only cream packets in flight across the leap, but in practice the signalling mechanism is weak and the event itself is so infrequent (once a year or two) that implementors don't see it often enough to get the code which is supposed to do the leap working and you end up with 20 minutes of confusion instead. In any case while this is interesting, and while I certainly wouldn't mind seeing NTP relied upon by enough applications that it became required for Internet entities with clocks, I think the network layer is a little bit too fundamental to depend on this. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Wed Oct 7 04:56:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04110; Wed, 7 Oct 1992 04:56:49 +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 AA04107; Wed, 7 Oct 1992 04:56:43 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA22950; Tue, 6 Oct 92 11:56:20 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA10738; Tue, 6 Oct 1992 14:56:13 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: craig@aland.bbn.com, big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP In-Reply-To: <9210052011.AA16162@ginger.lcs.mit.edu> References: <9210052011.AA16162@ginger.lcs.mit.edu> X-Mailer: Poste 2.0 From: David R. Oran Date: Tue, 6 Oct 92 14:56:02 -0400 Message-Id: <921006145602.12546@sneezy.lkg.dec.com> Encoding: 22 TEXT, 6 TEXT SIGNATURE > How about a real expiration timestamp (e.g. NTP format)? > Using a real expiration time is quite attractive, but I have some questions. 1. What about a machine that puts out packets with outrageously long timeouts? Are the routers required to do sanity tests on the timestamp? 2. what about a router with a broken/insane clock? Is it ok to ignore this failure mode? 3. What about the dependency loops between NTP and IP? Are there wierd failure modes where the router's clock drifts out, but you can't use NTP to retrain it because the NTP packets aren't believed? 4. Can you use 32 bits and get global agreement on the "epoch" of the Internet, or do you have to use 64 bits? 5. Is this potentially an atom bomb to kill a flea? 6. Once you have this expiration, what other interesting things can you do with it? Smart discard, for example? -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Wed Oct 7 05:21:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04729; Wed, 7 Oct 1992 05:21:49 +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 AA04722; Wed, 7 Oct 1992 05:21:36 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA07444; Tue, 6 Oct 92 12:21:27 -0700 Received: by us1rmc.bb.dec.com; id AA15819; Tue, 6 Oct 92 15:18:55 -0400 Message-Id: <9210061918.AA15819@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Tue, 6 Oct 92 15:18:56 EDT Date: Tue, 6 Oct 92 15:18:56 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 06-Oct-1992 1521" To: big-internet@munnari.oz.au Cc: dee@ranger.enet.dec.com Apparently-To: big-internet@munnari.oz.au Subject: RE: Re: IESG Deliberations [criteria] A criteria that I was surprised not to see mentioned with what impact, if any, the proposal has on the development of ubiquitous security in the Internet. Donald From owner-Big-Internet@munnari.oz.au Wed Oct 7 05:40:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05179; Wed, 7 Oct 1992 05:40: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 AA05174; Wed, 7 Oct 1992 05:40:38 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21134; Tue, 6 Oct 92 15:40:30 -0400 Date: Tue, 6 Oct 92 15:40:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210061940.AA21134@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Hop Limit field in SIP Cc: jnc@ginger.lcs.mit.edu it seems silly to me to make the basic operation of the internet layer depend on it, if it doesn't have to. Good point. Horrible dependancy loop... There's also the issue of "will it work on a detached network with 3 wires and one router". It's a major hassle to have to update all the hosts every n years to use a larger initial hop limit, but it sounds like that is what you are advocating... Why not just accept it now, and always use 255 ... as the initial hop limit in all packets? True enough, but it's still better (at an architectural level) to have a configuration parameter one can update on a host by host basis (perhaps triggered by encountering the problem) than a fundamental constant wired into the packet format.... Hmm. I have a new fundamental law of the universe: As the network gets bigger, simple solutions that used to work just fine don't any more. Maybe we should look for a routing architecture in which packets *cannot* loop? Do X.25 networks have hop counts on packets? Do we have an X.25 internals expert in the house? Noel From owner-Big-Internet@munnari.oz.au Wed Oct 7 05:55:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05677; Wed, 7 Oct 1992 05:55:26 +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 AA05653; Wed, 7 Oct 1992 05:55:15 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21221; Tue, 6 Oct 92 15:54:58 -0400 Date: Tue, 6 Oct 92 15:54:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210061954.AA21221@ginger.lcs.mit.edu> To: Juha.Heinanen@datanet.tele.fi, deering@parc.xerox.com Subject: Multiple addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu i repeat, any routing model that requires interfaces to have addresses is very bad for locigal reasons If addresses don't name places in the network, places where hosts can connect to the network, i.e. network interfaces, what is it that they do name? modern multiaccess subnetwork technologies, such as frame relay and atm, where there can exist hundreds of non-broadcast neighbors behind each physical interface If there are lots of machine back there, there is either some physical or virtual communication system which connects them. That system is a 'network' all its own, deserves a 'network' address, and each machine has an 'interface' to that network which can be individually named with an address. E.g., if it's a multi-port ATM switch, each port should have its own address. trying to route current IP with ospf or cisco igrp over such media is a management nightmare. Why? Can't you indicate in the low level packets on the network outside the interface which machine connected to the interface the packet is for? If yes, then each host has a different address, even though there's only one interface to the network. If no, the switch need to have an IP router in it anyway, to demultiplex the packets.. Noel From owner-Big-Internet@munnari.oz.au Wed Oct 7 06:02:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05897; Wed, 7 Oct 1992 06:02:27 +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 AA05893; Wed, 7 Oct 1992 06:02:17 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21257; Tue, 6 Oct 92 16:02:11 -0400 Date: Tue, 6 Oct 92 16:02:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210062002.AA21257@ginger.lcs.mit.edu> To: bmanning@is.rice.edu, jnc@ginger.lcs.mit.edu Subject: Re: Hop Limit field in SIP Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Perhaps this is 1200 baud heaven. When I said "1200 baud isn't long for this world", I meant like a modest number of years. Think *long* term! I'm looking down a long perspective; it will take *at least* 5 years to get a new packet format really deployed, and it will probably be in service for at least 25 years, and maybe 40. 1200 *will* go the way of 110 and 300, but it'll take a while, yes. So, when thinking of that timeline, plan your design to be somewhat expensive, but practical, in 5 years (20 byte headers were outrageusly large in the late 70's when the current IP was being designed, and 300 baud was common :-), and plan it to still be useful in 30. A tall order, true, but not unreachable... Noel From owner-big-internet@munnari.oz.au Wed Oct 7 06:04:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05997; Wed, 7 Oct 1992 06:04:43 +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 AA04836; Wed, 7 Oct 1992 05:26:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21002; Tue, 6 Oct 92 15:25:54 -0400 Date: Tue, 6 Oct 92 15:25:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210061925.AA21002@ginger.lcs.mit.edu> To: VALDIS@vtvm1.cc.vt.edu, craig@aland.bbn.com Subject: Re: Hop Limit field in SIP Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu This would have the added advantage that all organizations connected to the Internet would get "free of charge" a good time service - which will almost certainly be an issue in the higher-level protocols as we attempt to design an ubiquitous security service I sympathize with Steve's nervousness about building a large pile here, but this is the kind of thing I was alluding to when I said a timebase would be very useful. now if only somebody can figure out how to do a 'traceroute' using one. Bzzzrraack! Here we go again, driving screws with a hammer. Dammit, if we want a traceroute function, design an ICMP message to do it! I am *SOOOOO* sick of kludges! Sure, sometime you have to kludge to get something done, but then we turn around and make it a fundamental architectural principle, when all it was was a quick, disgusting, hack, kludge (like the IGP/EGP split). Having said this, I'm not sure if a timestamp wins over a hopcount Me too. I'm not saying for sure a hop-count is the wrong way to go, but let's be original in our thinking. Noel From owner-Big-Internet@munnari.oz.au Wed Oct 7 06:12:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06185; Wed, 7 Oct 1992 06:12: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 AA06180; Wed, 7 Oct 1992 06:12:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21446; Tue, 6 Oct 92 16:11:51 -0400 Date: Tue, 6 Oct 92 16:11:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210062011.AA21446@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, oran@sneezy.lkg.dec.com Subject: Re: Hop Limit field in SIP Cc: big-internet@munnari.oz.au, craig@aland.bbn.com, jnc@ginger.lcs.mit.edu 1. What about a machine that puts out packets with outrageously long timeouts? Are the routers required to do sanity tests on the timestamp? 2. what about a router with a broken/insane clock? Is it ok to ignore this failure mode? Good points all. Remember, though, that nothing can *absolutely guarantee* that you don't ever get infinite packet loops; suppose that two routers don't decrement the TTL, either for speed resons, or software error; even the TTL won't fix that case. All you can do is add mechanisms which work *most of the time*.... 5. Is this potentially an atom bomb to kill a flea? Could be... Maybe we go back to TTL, but you have to set the TTL to a value based on somethign you hear from your router, not from a fixed constant? Noel From owner-Big-Internet@munnari.oz.au Wed Oct 7 06:13:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06225; Wed, 7 Oct 1992 06:13:53 +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 AA06216; Wed, 7 Oct 1992 06:13:40 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11804>; Tue, 6 Oct 1992 13:13:28 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 6 Oct 1992 13:13:23 -0700 To: Juha Heinanen Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: Your message of "Tue, 06 Oct 92 00:15:57 PDT." <92Oct6.001608pdt.11638@alpha.xerox.com> Date: Tue, 6 Oct 1992 13:13:14 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct6.131323pdt.10779@skylark.parc.xerox.com> > i didn't say that a box can have only one address. it can have any > number, but none of them should be an address of an interface. Juha, I'm sorry for misinterpreting your comments. It means that I don't understand the issue you are raising, and I would appreciate your tolerance of my ignorance and a more detailed explanation than: > i repeat, any routing model that requires interfaces to have addresses > is very bad for locigal reasons and totally unscalable for modern > multiaccess subnetwork technologies, such as frame relay and atm, where > there can exist hundreds of non-broadcast neighbors behind each physical > interface. In my response to you, I was thinking mainly of hosts (end systems) that are multihomed and that need different addresses that correspond to each of their interfaces (at least, those interfaces that connect to widely- separated parts of the internet), so that they may be reached over each of their interfaces. One can pretend that the addresses identify the box and not the interfaces, but if the interface over which a packet is delivered depends on the destination address in the packet, I will claim that, in effect, the address belongs to the interface rather than the box. However, from your comments above, it sounds like you are particularly concerned with routers, rather than hosts, and with some specific problem having to do with large non-broadcast subnetworks. What exactly is the management nightmare caused by per-interface addresses, that you refer to in the following? > trying to route current IP with ospf or cisco igrp over such > media is a management nightmare. Isn't there also a management problem in *not* having per-interface addresses? It means that you cannot force a packet to be delivered to a particular interface, for example a ping packet meant to diagnose whether or not an interface is working. This problem has arisen in the current Internet in domains that have relaxed the need for every interface to have its own address, e.g., when using so-called "unnumbered links". I consider unnumbered links to be an unfortunate development, that I assumed was mainly driven by inadequate support for variable-length subnets. Steve From owner-big-internet@munnari.oz.au Wed Oct 7 06:17:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06339; Wed, 7 Oct 1992 06:17:46 +1000 (from owner-big-internet) Return-Path: Received: from dg-rtp.rtp.dg.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05903; Wed, 7 Oct 1992 06:02:38 +1000 (from throop@dg-rtp.dg.com) Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4.1/dg-rtp-proto) id AA29887; Tue, 6 Oct 1992 16:01:46 -0400 Received: by walrus (5.4.1/140.2) id AA06168; Tue, 6 Oct 1992 15:59:18 -0400 Date: Tue, 6 Oct 1992 15:59:18 -0400 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9210061959.AA06168@walrus> To: big-internet@munnari.oz.au Subject: Re: TIME to die (was Re: Hop Limit field in SIP) Cc: kasten@ftp.com > From kasten@ftp.com Tue Oct 6 08:42:19 1992 > Subject: TIME to die (was Re: Hop Limit field in SIP) > From: kasten@ftp.com (Frank Kastenholz) > > Dean and Craig, > > This is an idea with merit. ... It certain is interesting to speculate about. I've been trying to determine some advantages and disadvantages of the approach. Here my current thoughts: Advantages: Provides a mechanism totally independent of the number of routers traversed. This is the principal advantage because we never have to worry about having a large enough field. Can potentially adapt to drastic changes in routing better then a fixed hop count. If a new cross country network is installed that gives equivalent service but at the cost of many little hops, this mechanism will continue to work. The header doesn't have to be updated on forwarding. The routers need only read and compare. Provides guarantee aging of packets for upper layer protocols. Provides additional information about packet livetimes. Each packet comes with a builtin time stamp. Disadvantages: Size We were complaining about having to use 16 bits for a hop count and a time stamp would probably require 32 bits. With a 32bit hop count we would never have to worry about running out. Debugging All the routers become real time entities. It isn't possible to set breakpoints, stop them to look around and then continue (well it would create a big transient until things synchronized again). Of course the really interesting problems only occurs under full load and at speed anyway. Requires NTP in all routers. I actually don't see this as a very big negative because it isn't that expensive and coordinated time would be very nice to have. Key question The biggest question: how easy would it be to pick expiration times? Too long an expiration time would delay detection of routing loops. Too short an expiration time would drop packets that are good. How will the fluctuation in network load impact a host that supplies very tight expiration times? Can we convince ourselves we can pick reasonable expirations times that really will limit packet congestion? As I think about it I believe with faster links and longer paths, things just don't scale. If a routing loop involves a large percentage of the traffic, packets will be dropped due to congestion before any header detection mechanism can take effect. For a routing loops that only involves a small percentage of the traffic, it probably doesn't make much difference so make the expiration times generous. > > One problem -- what about traceroute :-) > I would expect other tools to fill the gap. Since we're designing a new packet format, we should define a route record option and use it to implement traceroute. The new equivalent of an ICMP ECHO request with the route record option should generate a reply having the option in its body. This means one packet should do it all. Traceroute sends the ECHO request and reads the routes out of the reply message. The other mechanism would be to define more MIB objects. Traceroute was built before SNMP and works with boxes that don't have it. A new protocol will come with a new MIB and maybe we can require it. Just imagine an object with an instance being a destination and the return value defined as the address of the next hop as seen from that router. Thus traceroute works by doing a get of that object from it's local router to obtain the address of the second router. It then does a get from the second router to obtain the address of the third router. Traceroute could just iterate until it reached the destination. For all gets the instance will be the final destination. Come to think of it this might be useful in today environment as well. > -- > frank kastenholz > Dean Throop throop@dg-rtp.dg.com From owner-Big-Internet@munnari.oz.au Wed Oct 7 06:22:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06497; Wed, 7 Oct 1992 06:23:08 +1000 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06479; Wed, 7 Oct 1992 06:22:50 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA16398; Tue, 6 Oct 92 13:22:40 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA06257; Tue, 6 Oct 92 16:22:38 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA25372; Tue, 6 Oct 92 16:20:53 EDT Date: Tue, 6 Oct 92 16:20:53 EDT From: Frank T Solensky Message-Id: <9210062020.AA25372@fenway.andr.UB.com> To: jnc@ginger.lcs.mit.edu, oran@sneezy.lkg.dec.com Subject: Re: Hop Limit field in SIP Cc: big-internet@munnari.oz.au, craig@aland.bbn.com >> How about a real expiration timestamp (e.g. NTP format)? Since this idea does seem to be getting serious consideration, I reiterate Steve Deering's concerns: >[NTP timestamp] doesn't solve the problem. Packets sent from the Earth to the >Moon or Mars will need a long expiration time, but if they get caught in a >loop before leaving the planet, they will probably consume more resources >waiting for their expiration times to lapse than packets with a hop limit >of 50,000 ever would. Would we be using HELLO as an IGP (InterGlobal Protocol)? -- Frank From owner-Big-Internet@munnari.oz.au Wed Oct 7 06:27:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06617; Wed, 7 Oct 1992 06:27:30 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210062027.6617@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06614; Wed, 7 Oct 1992 06:27:24 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <17438-0@datanet.tele.fi>; Tue, 6 Oct 1992 22:26:40 +0200 To: jnc@ginger.lcs.mit.edu Cc: deering@parc.xerox.com, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9210061954.AA21221@ginger.lcs.mit.edu> "jnc@ginger.lcs.mit.edu" Subject: Multiple addresses Date: Tue, 6 Oct 1992 22:26:40 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi If addresses don't name places in the network, places where hosts can connect to the network, i.e. network interfaces, what is it that they do name? look at how NSAPs are used in IS-IS or IDRP. they just identify boxes, not their interfaces. and i can't see any need to identify an interface in normal routing. modern multiaccess subnetwork technologies, such as frame relay and atm, where there can exist hundreds of non-broadcast neighbors behind each physical interface If there are lots of machine back there, there is either some physical or virtual communication system which connects them. That system is a 'network' all its own, deserves a 'network' address, and each machine has an 'interface' to that network which can be individually named with an address. E.g., if it's a multi-port ATM switch, each port should have its own address. i repeat, it should be enough that each machine connected to the multiaccess network has one or more addresses. this works fine with IS-IS or IDRP. there is no need to address ports in a well designed routing architecture. trying to route current IP with ospf or cisco igrp over such media is a management nightmare. Why? because currently if I route IP and a box is connected over FR/ATM to 100 other boxes, i have to define for this FR/ATM interface 100 addresses so that it has one address common with all those other boxes it wants to talk to. note that i may want for many reasons to treat the FR/ATM network as prodiving me 100 virtual point-to-point lines. i'm really suprised if this is something new to you. or may be i have missed something big during these years in configuring my boxes for IP. or may be i'm the only one of the whole gang who has this kind of networks to play with. -- juha From owner-Big-Internet@munnari.oz.au Wed Oct 7 06:27:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06622; Wed, 7 Oct 1992 06:27:49 +1000 (from owner-Big-Internet) Return-Path: Received: from nigel.msen.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06619; Wed, 7 Oct 1992 06:27:41 +1000 (from emv@nigel.msen.com) Received: by nigel.msen.com (/\==/\ Smail3.1.25.1 #25.5) id ; Tue, 6 Oct 92 16:27 WET DST Message-Id: To: big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP Date: Tue, 06 Oct 92 16:27:15 EDT From: Edward Vielmetti From: David R. Oran Date: 5 Oct 92 21:24:49 GMT I would be surprised if someone could make a credible case for Internet paths that are longer than 255 "traditional" hops. As someone already pointed out, the International phone system is only 12 hops in diameter, and even the most optimistic predictions get it to 15 hops in the next 50 years. The graph-theoretical rule of thumb has worked quite well in many problem domains: the diameter grows as the loglog of the number of nodes. I would have been surprised at a credible case for a 255-hop internet, if I hadn't seen it take 17 hops through 6 states to go 6 blocks across town in Ann Arbor, or 35-odd hops to get from one part of the East Coast to another via California on the NSFnet. As a colleague across town told me, he was going to have to up the TTLs on his TCP if we moved a few more blocks north. My guess is that the diameter of the Internet is sufficiently ragged, chaotic, and ill-defined that it's not going to be unusual to have nets that for one political or economic reason are longer than they should be or too far away from peers that should be really close. --Ed amental to depend on this. It sounds like a good project for some eager graduate students. Let them build it and tell us how well it works. > > Dennis Ferguson Dean Throop throop@dg-rtp.dg.com From owner-Big-Internet@munnari.oz.au Wed Oct 7 07:36:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08743; Wed, 7 Oct 1992 07:36:59 +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 AA08731; Wed, 7 Oct 1992 07:36:45 +1000 (from kasten@ftp.com) Received: by ftp.com id AA11327; Tue, 6 Oct 92 17:19:46 -0400 Date: Tue, 6 Oct 92 17:19:46 -0400 Message-Id: <9210062119.AA11327@ftp.com> To: throop@dg-rtp.dg.com Subject: Re: Hop Limit field in SIP From: kasten@ftp.com (Frank Kastenholz) Cc: dennis@ans.net, big-internet@munnari.oz.au > > Yes, this is true, but in addition to reliability there is a problem > > of chickens and eggs. If you need a synchronized clock to send > > datagrams, how are you going to send NTP datagrams to synchronize > > your clock? > > The protocol could allow an expiration time of zero to be used in > packets that aren't forwarded. Thus a new router could talk with > its peers to get the time of day by using a zero expiration time. > Once the router knew the time, it could build packets that are > forwarded. There is a more insidious form of this problem. What happens when a large hunk of the Internet dies? This can and does happen. Imagine a large earthquake in California, another power failure in the northeast US like we had in 1965 or 1977(I think it was -- when it couldn't happen again). You wouldn't simply reboot your machine, get clock synch with your neighbor and off you go. Their would be this sort of "creeping synchronization" from the edges of the dead area inward. Furthermore, suppose that this dead area kills a major transit point and the Internet is partitioned. If the outage is long enough, the two areas could drift apart. What happens in NTP when two split areas are joined together -- does one area synchronize to the other area or do they both synchronize to some in-between value? I can imagine some wave of synchronization washing over big hunks of the Internet. I can also imagine that there would always be hunks of the net falling off and coming back. Is it possible that we will always be resynching? Talk about large, dynamic systems! Is father time out there? Can he enlighten us? -- frank kastenholz From owner-big-internet@munnari.oz.au Wed Oct 7 13:11:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19591; Wed, 7 Oct 1992 13:12:19 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210070312.19591@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06797; Wed, 7 Oct 1992 06:35:16 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <17465-0@datanet.tele.fi>; Tue, 6 Oct 1992 22:34:54 +0200 To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: <92Oct6.131323pdt.10779@skylark.parc.xerox.com> "deering@parc.xerox.com" Date: Tue, 6 Oct 1992 22:34:54 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi steve, i just tried to be more specific when replying to noel. if that is not enough i can go into more details and examples. i have discussed these problems with some router manufactures during the last year and all of them have so far acknowledged that my problems are real. so i'm really suprised if these now come as new things to routing experts on this list. in your message you raised the only reason why one would really want an interface to have an address: in order to be able to ping it. i, however, claim that even that is not necessary, since you can invent an SNMP ping that given the box'es address and an interface number, returns the status of the interface. you can also use SNMP to figure out via what interface a packet to a certain address will be routed if you want to know that for trouble shooting reasons. -- juha From owner-big-internet@munnari.oz.au Wed Oct 7 13:43:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20652; Wed, 7 Oct 1992 13:44:03 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210070344.20652@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07250; Wed, 7 Oct 1992 06:47:18 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <17528-0@datanet.tele.fi>; Tue, 6 Oct 1992 22:46:54 +0200 To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: <92Oct6.131323pdt.10779@skylark.parc.xerox.com> "deering@parc.xerox.com" Date: Tue, 6 Oct 1992 22:46:54 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi One can pretend that the addresses identify the box and not the interfaces, but if the interface over which a packet is delivered depends on the destination address in the packet, I will claim that, in effect, the address belongs to the interface rather than the box. steve, i don't think this is true. i can have a host that at the same time belongs to many routing domains (and thus has many addresses) and it can have only one, eg. Ethernet interface through which all packets arrive. also i can have a whole backbone of routers that all serve many customer routing domains and thus have many interfaces and many adresses, but you can't say which address is bound to which interface. the routers can receive any packets via any interface. -- juha From owner-big-internet@munnari.oz.au Wed Oct 7 14:19:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22513; Wed, 7 Oct 1992 14:19:42 +1000 (from owner-big-internet) Return-Path: Received: from fncent.fnal.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09583; Wed, 7 Oct 1992 08:07:22 +1000 (from crawdad@fncent.fnal.gov) Received: from localhost.fnal.gov by fncent.fnal.gov with SMTP id AA16328 (5.65c+/IDA-1.4.4 for big-internet@munnari.oz.au); Tue, 6 Oct 1992 17:03:24 -0500 Message-Id: <199210062203.AA16328@fncent.fnal.gov> To: Valdis Kletnieks Cc: big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of Tue, 06 Oct 92 12:53:41 EDT. <921006.125341.EDT.VALDIS@vtvm1.cc.vt.edu> Date: Tue, 06 Oct 92 17:03:23 -0500 From: Matt Crawford > Having said this, I'm not sure if a timestamp wins over a hopcount - I > *like* the idea of a timestamp, now if only somebody can figure out how > to do a 'traceroute' using one. Timestamp could be the standard field, and a decrementing hop count could be a new option. _________________________________________________________ Matt Crawford crawdad@fncent.fnal.gov Fermilab From owner-big-internet@munnari.oz.au Wed Oct 7 14:22:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22634; Wed, 7 Oct 1992 14:22:20 +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 AA09176; Wed, 7 Oct 1992 07:52:50 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11855>; Tue, 6 Oct 1992 14:52:23 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Tue, 6 Oct 1992 14:52:12 -0700 To: Juha Heinanen Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: per-interface addresses In-Reply-To: Your message of "Tue, 06 Oct 92 13:46:54 PDT." <92Oct6.134704pdt.11854@alpha.xerox.com> Date: Tue, 6 Oct 1992 14:51:57 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct6.145212pdt.10779@skylark.parc.xerox.com> > One can pretend that the addresses identify the box and not the > interfaces, but if the interface over which a packet is delivered > depends on the destination address in the packet, I will claim that, > in effect, the address belongs to the interface rather than the box. > > steve, > > i don't think this is true. i can have a host that at the same time > belongs to many routing domains (and thus has many addresses) and it can > have only one, eg. Ethernet interface through which all packets arrive. Juha, That doesn't contradict what I said. In that case, the host interface simply has multiple addresses. > also i can have a whole backbone of routers that all serve many customer > routing domains and thus have many interfaces and many adresses, but you > can't say which address is bound to which interface. the routers can > receive any packets via any interface. In my paragraph from which you quoted above, I was talking about multihomed *hosts*, not routers. For routers, you can sometimes get away without per- interface addresses, as shown by the fact that unnumbered links work and that IS-IS or IDRP routing works without per-interface addresses for routers. Thanks for explaining the problem with Frame Relay nets. It seems that the problem arises because that kind of subnetwork violates an architectural assumption of IP: that every subnetwork is fully connected internally. If you could treat it as a fully-connected subnetwork, you wouldn't need to use the virtual point-to-point link kludge. However, you are right that such subnetworks are becoming a fact of life, and it would be helpful to accommodate them in the IP routing architecture. Steve From owner-Big-Internet@munnari.oz.au Wed Oct 7 15:50:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26123; Wed, 7 Oct 1992 15:50:35 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210070550.26123@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26120; Wed, 7 Oct 1992 15:50:24 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <20746-0@datanet.tele.fi>; Wed, 7 Oct 1992 07:50:07 +0200 To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: <92Oct6.145212pdt.10779@skylark.parc.xerox.com> "deering@parc.xerox.com" Subject: per-interface addresses Date: Wed, 7 Oct 1992 07:50:07 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi steve, i can also have a host which belong to RD's, thus has two addressse, and has, two say ethernet, interfaces, and you can't tell which one belongs to which address, since it can receive packets with both destination addresses from both. i can very easily demonstrate this with the very host i'm using to send this message. the problem of partially connected subnets is not unique to FR. it applies also to X.25, SMDS, and most importantly the new ATM technology for which whatever the new routing architecture should definitely be a good match. -- juha From owner-big-internet@munnari.oz.au Wed Oct 7 15:59:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26430; Wed, 7 Oct 1992 15:59:11 +1000 (from owner-big-internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18227; Wed, 7 Oct 1992 12:14:33 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA03455 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Tue, 6 Oct 1992 22:13:50 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 6 Oct 1992 22:13:50 -0400 Message-Id: <199210070212.AA03375@home.ans.net> To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 06-Oct-1992 1521" Cc: big-internet@munnari.oz.au Subject: Re: IESG Deliberations [criteria] In-Reply-To: (Your message of Tue, 06 Oct 92 15:18:56 EDT.) <9210061918.AA15819@us1rmc.bb.dec.com> Date: Tue, 06 Oct 92 22:12:23 -0500 From: Phill Gross > : A criteria that I was surprised not to see mentioned with what impact, if a the proposal has on the development of ubiquitous security in the Internet. Donald, Thanks. Yes, this is a very important topic. Security is mentioned in several of the sections (eg, "changes" and "future evolution"), but I agree that security deserves more emphasis. In fact, during internal review, we drafted a short section on security (see below), but it appears I must have left it out of the final draft. Mea culpa. I will fix that in the next version. Our text was: Security Impact The impact on current and future security plans should be addressed. For example, do current security mechanisms such as address and protocol port filtering work in the same manner as they do today, and what is the effect on security and authentication schemes currently under development. Can anyone suggest additional text to strengthen that section? Thanks again, Phill From owner-big-internet@munnari.oz.au Wed Oct 7 16:27:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27456; Wed, 7 Oct 1992 16:27:25 +1000 (from owner-big-internet) Return-Path: Received: from spark.brl.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18957; Wed, 7 Oct 1992 12:44:05 +1000 (from reschly@BRL.MIL) Date: Tue, 6 Oct 92 22:40:07 EDT From: "Robert J. Reschly Jr." To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP Message-Id: <9210062240.aa12237@SPARK.BRL.MIL> Good evening, Steve Deering writes about packets destined for the Moon or Mars looping locally chewing up enormous amounts of resources.... Packets destined for my MILNET neighbors (yeah, MILNET is still out there -- supplying us with 1960's technology in perpetuity or something like that...) are likely to also want largish values for timers. In any case, any long timer is going to be deadly if the timer is the only extinction mechanism. Later, Bob From owner-big-internet@munnari.oz.au Wed Oct 7 17:34:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29724; Wed, 7 Oct 1992 17:34:45 +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 AA29257; Wed, 7 Oct 1992 17:22:06 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11899>; Wed, 7 Oct 1992 00:21:45 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Wed, 7 Oct 1992 00:21:34 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: EIDs Date: Wed, 7 Oct 1992 00:21:23 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct7.002134pdt.10779@skylark.parc.xerox.com> OK, I guess it's time to take on this one... Bob Smart wrote: > Earlier in 1992 there was a discussion on the Big-Internet list > which clearly established the value of separating Addresses (used > for routing) from Endpoint Identifiers (EIDs). I disagree that the value of EIDs was clearly established. I don't think EIDs were even clearly defined. A number of people speculated that topology-independent identifiers (other than host names) would help to solve certain perceived problems in the protocol suite. That may well be true, but it is not at all clear that each of the identified problems would be alleviated by the *same* sort of identifier, or that the EID approach is the best approach for solving any one of those problems, especially when the costs of maintaining yet another identifier space are taken into account. For instance: - I think Noel wants EIDs with a granularity finer than a host -- he has talked about EIDs as identifiers for processes that might migrate from one host to another, or as transport endpoint identifiers (one for each transport connection bound to a different resource reservation, possibly?). I don't see that that requirement is necessarily met by proposals to use a host's 802.2 address as its (only) EID. - It has been suggested that topology-independent EIDs would help in supporting mobile hosts. In particular, it has been observed that a packet to a mobile host might need to carry two destination identifiers -- a location and a host ID -- and the EID could serve as the host ID. However, the encapsulation approach for forwarding to mobile hosts (e.g., the Columbia scheme) is another way put two destinations in a packet (in the inner and outer IP headers), in which the destination serving as the host ID (in the inner header) is a lot more useful than a flat EID, because it can be used to identify a "home" location at which the location of the mobile can be registered and looked up. I think this is a much better approach than expecting the directory service to maintain EID->location mappings for zillions of roaming hosts, especially given that the need for dynamic updates of such mappings is in conflict with the large degree of replication required to make the directory scale and perform adequately. Furthermore, with the encapsulation approach, the overhead of carrying a second destination identifier is incurred only in those packets that actually need to carry it. - EIDs could be used in the computation of TCP & UDP pseudo-header checksums, so that the addresses may be changed on the fly (e.g., from one interface's address to another, for a multihomed host) without breaking connections or sessions. That would be nice, but it's not the only way to do it. As an off-the-wall suggestion, why not include the hosts' fully-qualified domain names, instead of their addresses, in the checksum, since they already serve as topology-independent host identifiers? The names would not have to be carried in the packets themselves, just included in the checksum computation, and the sum over the pair of names could be precomputed, so it would be as efficient as using the addresses. As a more serious suggestion, we really should be either encrypting or crypto-signing all of our transport PDUs, in which case, we could stop including IP addresses in the pseudo-header checksums because misdelivery would be prevented by decryption failure (only the legitimate peers would hold the right key). - Some have suggested that EIDs would be useful for identifying who should be charged for transmission of a packet. Would such an EID identify a host or an account to be billed? Wouldn't such an EID need to to be big enough to include a digital signature, to prevent fraud? - Some have suggested that EIDs would be useful for packet filtering in "security" gateways. Adminstration-independent identifiers such as 802.2 station addresses don't strike me as well-suited to that role -- all filtering would be host specific, since you can't do any useful agregation with 802.2 addresses. (Well, I suppose if you wanted to filter out all traffic from Sun workstations, you could at least do that :-) - The one use of EIDs that does appeal to me is the use of 802.2 addresses for auto-configuring the "host" part of a host's internet address, as has been proposed for CLNP. That provides a much more lightweight solution to (part of) the dynamic host configuration problem than the complex, server-based schemes that are being proposed for IP. However, several people on this list have objected to the use of 802.2 addresses as EIDs, for many reasons, and have suggested that EIDs will have to be (at least sometimes) manually administered. If that's the case, might as well just manually administer the topologically-significant addresses (or the servers that hand them out), as we do now, and do without the EIDs. I could go on, but I'll stop here. My point is that I have yet to hear a convincing reason for requiring identifiers other than topologically- significant addresses in the *internet* header of *all* packets (except, of course, for Noel's scheme, in which some packets don't carry any addresses at all). The job of the internet layer is to relay packets to destinations. It uses topologically significant addresses to accomplish that efficiently; it doesn't need EIDs to do its job. If you think that internet headers should carry EIDs, in addition to, or as a subfield of, addresses, please answer in detail: - what exactly do the EIDs identify? (a computer chassis? the contents of a boot disk? an abstract "host"? a process/thread? a transport protocol control block? a "security principal"? a billing account?) - how big do the EIDs have to be? how are they structured (if at all)? who are the allocating authorities? how are they administered? - what function or functions do the EIDs serve? - how do they serve those functions? Ross has already answered some, but not all, of these questions, with regard to his proposal to embed EIDs in NSAP addresses. Most of the other messages advocating EIDs have lacked this level of detail, which makes it difficult to judge their merits. Just saying "EIDs solve lots of problems" is not enough. Steve From owner-Big-Internet@munnari.oz.au Wed Oct 7 18:07:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00959; Wed, 7 Oct 1992 18:07:42 +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 AA00954; Wed, 7 Oct 1992 18:07:22 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11902>; Wed, 7 Oct 1992 01:06:59 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Wed, 7 Oct 1992 01:06:52 -0700 To: Vince Fuller Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Splitting the network layer: take 2 In-Reply-To: Your message of "Sat, 03 Oct 92 17:44:07 PDT." Date: Wed, 7 Oct 1992 01:06:39 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct7.010652pdt.10779@skylark.parc.xerox.com> Vince Fuller wrote: > One thing that bothers > me about some of the proposals (SIP, IPAE, TUBA/CLNP, to name a few names) on > the table is that, in an effort to please everyone, they are trying to make > these creatures called "addresses" be hierarchically (sp?) allocated both > geographically and by service provider. This doesn't make sense - addresses > (in the NIMROD sense) will always follow network topology, which probably > means they will be provider based. Both the provider-based addresses and the metro-based addresses proposed for SIP and IPAE follow network topology. They just represent two different ways of hierarchically partitioning the graph that is formed from all of the links in the Internet. > This means that they will be dynamic - a > given machine may change its address very frequently if the network topology > in its immediate vicinity is changing a lot. This also means that any new > architecture will either provide hosts with a means of discovering these > dynamic addresses or will insure that the hosts don't *care* what they are > (i.e. by only letting hosts see endpoint ID's). I agree with you that it would be desirable for systems to be able to painlessly change their addresses on the fly. Endpoint IDs may or may not be a part of the mechanism required to accomplish that. Do you have a concrete proposal for a complete solution to the problem? > Again, the distinction between *addresses* and *endpoint-ids* is crucial and > should be handled by any serious proposal for IPv7. SIP is a serious proposal for IPv7 that only has addresses. The case has not yet been made that endpoint IDs, whatever they are, are necessary. Steve From owner-big-internet@munnari.oz.au Wed Oct 7 19:17:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03439; Wed, 7 Oct 1992 19:17:38 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210070917.3439@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00219; Wed, 7 Oct 1992 17:44:08 +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, 7 Oct 1992 08:43:44 +0100 To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: You ask "Why a New Routing Architecture?" Date: Wed, 07 Oct 92 08:43:37 +0100 From: Jon Crowcroft >every time a new flow shows up. (Note, we're working on this problem too -- >I suppose the real moral is conservation of problem -- if it ain't a bigger >routing table it is an added traffic load :-)). of course, there is another mid-term solution (suggested by cheriton and deering) to the route/address crisis: use multicast address space, with groups of one - we have DVMRP and MOSPF for IGPs, CBT for inter-domain; we already have the technolog in place (e.g. Mbone - i.e. the clnp argument that it is the only one already here is incorrect) and using multicast groups of one buys you dynamic host config and mobile hosts at one swell foop too - you can think of it as sort of class D two tier jon not entirely un-serious:-) From owner-Big-Internet@munnari.oz.au Wed Oct 7 19:42:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04237; Wed, 7 Oct 1992 19:42:24 +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 AA04233; Wed, 7 Oct 1992 19:42:17 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA17819 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 7 Oct 1992 19:42:33 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA26735; Wed, 7 Oct 92 19:42:15 EST Message-Id: <9210070942.AA26735@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: EIDs In-Reply-To: Your message of "Wed, 07 Oct 92 00:21:23 PDT." <92Oct7.002134pdt.10779@skylark.parc.xerox.com> Date: Wed, 07 Oct 92 19:42:14 +1000 From: Bob Smart >> Earlier in 1992 there was a discussion on the Big-Internet list >> which clearly established the value of separating Addresses (used >> for routing) from Endpoint Identifiers (EIDs). > >I disagree that the value of EIDs was clearly established. I'm sorry if I misrepresented the way the conversation went. I don't remember the anti-EID case, but that may well be a reflection of my bias. > I don't think EIDs were even clearly defined. A human being is not defined by a set of atoms since they keep changing. He/she is defined by a rather delicate quality of continuity. That lets you have a conversation over a period of years and stay in sync. To me it was clear that an EID identified the same sort of "end point defined by continuity". The obvious case: you can have a TCP conversation with it. One could imagine 2 machines with one shadowing the other: when one goes down the second picks up existing TCP conversations and the other ends of the tcp links don't know. But for all normal purposes an EID identifies a host. Does that misrepresent anyone's view of it? The main argument for EIDs that I remember went like this: 1. Longer addresses give us smaller router tables because they have enough bits to be provider specific: CIDR taken to its logical conclusion. 2. What about people who want to change providers. If your link to a provider is ATM that might be a very quick change to save money. Should you have to renumber everything every time you change provider: the answer was "yes" because if you are allowed to keep your number and move it to another supplier you'll destroy the routing advantage very quickly [someone mentioned entropy]. 3. What about networks connected to multiple providers. Do they have multiple addresses. Answer "yes". Mightn't you want to switch provider in the middle of a session: e.g. from a fast provider for interactive stuff, then use a cheaper provider for a bulk transfer. You're right that just having the separation doesn't answer these problems by itself, but it gets you out of the dark to where you can see the light at the end of the tunnel. Even SIP doesn't always use exactly the same set of bits for routing as for identification. Having the EID as part of the address is not unreasonable, so we may only be arguing about: (1) degree; and (2) should an end-point have multiple EIDs (and if so when is it allowed to change the EID in the header). Bob Smart From owner-Big-Internet@munnari.oz.au Wed Oct 7 19:49:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04494; Wed, 7 Oct 1992 19:50:09 +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 AA04484; Wed, 7 Oct 1992 19:49:49 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA21990; Wed, 7 Oct 1992 10:49:37 +0100 Message-Id: <199210070949.AA21990@mitsou.inria.fr> To: throop@dg-rtp.dg.com (Dean D. Throop) Cc: big-internet@munnari.oz.au, kasten@ftp.com Subject: Re: TIME to die (was Re: Hop Limit field in SIP) In-Reply-To: Your message of "Tue, 06 Oct 92 15:59:18 -0400." <9210061959.AA06168@walrus> Date: Wed, 07 Oct 92 10:49:37 -0500 From: Christian Huitema X-Mts: smtp >Requires NTP in all routers. I actually don't see this as a very >big negative because it isn't that expensive and coordinated time >would be very nice to have. Just one tiny side effect. You can only achieve time synchronization between two objects if they are not mobile, or more precisely if their relative speed is constant. So said Einstein. Indeed, the effect is dependant of the relative speeds, or rather the relative acceleration. But anything that moves at large speeds (fractions of speed of light) under curved trajectories cannot be time synchronized, full point. This means that you cannot achieve high precision time synch between earth and a satellite, although you can do some predictions due to orbit periodicity. A spacecraft to the Moon, or to Mars, would have both a high speed curved trajectory and no periodic orbit. NTP would simply not work here without some very serious kludges. For this reason, I vote AGAINST requiring time synch at the IP level. Christian Huitema From owner-Big-Internet@munnari.oz.au Wed Oct 7 20:03:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05003; Wed, 7 Oct 1992 20:03:41 +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 AA04996; Wed, 7 Oct 1992 20:03:28 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA22041; Wed, 7 Oct 1992 11:04:12 +0100 Message-Id: <199210071004.AA22041@mitsou.inria.fr> To: Juha Heinanen Cc: big-internet@munnari.oz.au Subject: Re: Multiple addresses In-Reply-To: Your message of "Tue, 06 Oct 92 22:26:40 +0200." <9210062027.6617@munnari.oz.au> Date: Wed, 07 Oct 92 11:04:11 -0500 From: Christian Huitema X-Mts: smtp >Look at how NSAPs are used in IS-IS or IDRP. they just identify boxes, >not their interfaces. and i can't see any need to identify an interface >in normal routing. They dont. In a LS routing protocol like IS-IS, you have to identify "points in the graph", i.e. relays. A relay has one single identification. However, if you want to set up a host that has multiple connections for better reliability but that does not want to engage in relaying nor in running the routing protocol, then this host will need several addresses -- one per interface. Christian Huitema From owner-Big-Internet@munnari.oz.au Wed Oct 7 20:19:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05534; Wed, 7 Oct 1992 20:19:49 +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 AA05529; Wed, 7 Oct 1992 20:19:26 +1000 (from kre) To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: EIDs In-Reply-To: Your message of Wed, 07 Oct 92 00:21:23 -0700. <92Oct7.002134pdt.10779@skylark.parc.xerox.com> Date: Wed, 07 Oct 92 20:19:14 +1000 Message-Id: <10639.718453154@munnari.oz.au> From: Robert Elz Date: Wed, 7 Oct 1992 00:21:23 PDT From: Steve Deering Message-ID: <92Oct7.002134pdt.10779@skylark.parc.xerox.com> - I think Noel wants EIDs with a granularity finer than a host Yes, I think I read that too, and I think I agree, but this isn't saying much more than a "host" (whatever that is) can have more than one EID, and of course that the EIDs are unrelated to interfaces. There was some discussion of using EIDs to identify processes, or even transactions, but I don't think that really had much support. I don't see that that requirement is necessarily met by proposals to use a host's 802.2 address as its (only) EID. Nor do I. As a more serious suggestion, we really should be either encrypting or crypto-signing all of our transport PDUs, Isn't it true that if you're doing that you're going to have to supply some ID that the recipient can use to work out which key to use to decrypt the message (or signature)? I doubt that you'd want to use the address to do that, as the address should be something that can vary. My point is that I have yet to hear a convincing reason for requiring identifiers other than topologically- significant addresses in the *internet* header of *all* packets (except, of course, for Noel's scheme, in which some packets don't carry any addresses at all). Unless things have changed recently, PIP didn't carry addresses either, just routes (I'm sure someone will correct me if I'm wrong here) - and while the routes could possibly be used for identification purposes the way that addresses can, they'd be even less suited. The job of the internet layer is to relay packets to destinations. That's true, and I can certainly see an argument for putting EIDs at a higher layer - other than with Noel's use of the EID as a cache tag they' enot usually used for routing. I suppose the question must be asked whether this is all the internet layer should be doing? Certainly with IP it does much more, including identification of the two end-points. Maybe that's just a historical accident that should be fixed, but clearly identification is needed somewhere, and as addresses become more topologically significant, and hence more likely to vary short term, even for supposedly fixed hosts, I don't feel that they should be overloaded to perform the identification role. So, perhaps we should add an identification layer (John Curran, where are you?) - but then again, if the bits are going to be in every packet, it doesn't make any real difference what the region of the packet where they're carried is called. That is, but the routing header first, then the identification header, then the transport header, and then the payload - you can lump the first two parts together and call them the internet header, or separate them acd treat it as two layers, this seems to be a quibble. If you think that internet headers should carry EIDs, in addition to, or as a subfield of, addresses, please answer in detail: I will try. - what exactly do the EIDs identify? An abstract host. Generally a physical host as well, but certainly not tied to any particular part of its hardware. The user community of the host is probably the closest physical thing that can be found - hence multiple EID's for one host if it has multiple communities of users. - how big do the EIDs have to be? This one is not easy to answer, I'd say 6 bytes minimum, but if they include IEEE addresses, then 7 bytes minimum (effectively 8 bytes min for sanity). 6 bytes isn't big enough with IEEE addresses because we need to have extra, and 2 bits just isn't enough - they're also not amenable to directory lookups (eid -> whatever). If we break the assumption that a 48 bit EID should be filled with an IEEE address, then 6 bytes is probably big enough to cope. how are they structured (if at all)? The same general way as domain addresses, except fixed length. That is, some authority assigns top level segments to lower authorities, which break up their segment as they see fit and assign sub-parts to even lower authorities. How many levels there will be will depend on the authorities and what they decide makes sense, but I'd assume about 4 would typically be about right (country or other significant body, one for organisations, one for departments, and one to distinguish indivual hosts) but that's certainly not cast in stone. who are the allocating authorities? Almost anyone could be, just as almost anyone can be an allocating authority of domain names. Who should be the top level authority - the ultimate authority? That one I won't answer, the IANA is certainly a candidate however. how are they administered? Do you mean the authorities or the EIDs? The authorities would be administered much the same way as domain name authorities are - the EIDs would be administered however the authorities desire, just as they do domain names. If its not obvious I see the EID as reasonably equivalent to a fixed length, reasonably short, equivalent of the domain name (though certainly not implying any direct mapping), something that can reasonably be carried in all packets. - what function or functions do the EIDs serve? Any and all roles that relate to identification. That includes the TCP/UDP pseudo-header checksums, and, along with the port numbers, identification of a TCP connection, the token passed up from the packet layer to the application identifying the client (and so logged as the source of a connection), packet identification for tools like tcpdump (as the common, and default alternative to the addresses), ... Perhaps even as a replacement for IP addresses in things like mail to user@[identifier] and perhaps in the FTP PORT command (if that isn't just replaced with the domain name, which is one place that using the number makes no real sense these days). - how do they serve those functions? I'm not sure how to answer this, or perhaps, what its possible to say that isn't obvious. For the pseudo-header, and TCP connection identification, they're just unique bit strings that can be added, compared, etc. For other identification purposes there must be a method to translate the EID into a domain name, which requires that they can be reasonably used as keys in a distributed directory (like the DNS). If EIDs can be used to provide a useful tool for handling mobile hosts, that's fine, but not the primary goal. The mechanism is more likely to be a greater decoupling of addresses from identification, with addresses not expected, in any circumstances, to remain constant for the lifetime of even relatively short conversations - a typical mail message would probably retain an address, but FTP might not, and TELNET would be very likely to span several address changes - distinguished purely by the average length of these types of connections of course. Extended by port numbers EIDs can identify processes, and extended by timestamps and whatever else is appropriate, they can identify transactions. I don't think EIDs should be pushed into either of those roles of themselves, that would be more than we would want to carry in every packet, useful or not. I don't see EIDs being useful in charging (personally I don't see packet charging being a very sensible model anyway, but never mind that) for the reasons you mention. Similarly, while occasionally they may have some limited use in filtering I don't see that as being something useful in general. Perhaps some nets may permit packets only when carrying their EIDs but that would be a very rare case. Addresses and signatures are still where filtering belongs. kre From owner-Big-Internet@munnari.oz.au Wed Oct 7 22:40:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10214; Wed, 7 Oct 1992 22:40: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 AA10209; Wed, 7 Oct 1992 22:40:16 +1000 (from kre) To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of Mon, 05 Oct 92 22:49:10 -0700. <92Oct5.224918pdt.10779@skylark.parc.xerox.com> Date: Wed, 07 Oct 92 22:40:06 +1000 Message-Id: <10759.718461606@munnari.oz.au> From: Robert Elz Date: Mon, 5 Oct 1992 22:49:10 PDT From: Steve Deering Message-ID: <92Oct5.224918pdt.10779@skylark.parc.xerox.com> It's a major hassle to have to update all the hosts every n years to use a larger initial hop limit, not really - this isn't a major update, just a knob to twist, and it only needs to be twisted at those places which are really at the edges of the internet, and only if they're communicating with the other edge (which they probably should assume). In any cases, hosts could be updated as they need to be, there's no mass conversion involved. Why not just accept it now, and always use 255 (or whatever your favorite upper bound is) as the initial hop limit in all packets? Precisely because I have absolutely no idea what the upper bound should be. Which is also why I don't think a small fixed size field is appropriate - because I don't know whether it will be big enough or not, and I really don't think we should be designing in another field that we already know might be too small. We will probably design something incorrectly through ignorance, that's OK, there's nothing we can do about that except watch for it as best we can, but to actually be aware that a limit might be too small, and ignore it, would make us appear extremely foolish should that limit actually become a problem in the future. Allocating more space than is ever needed would just make us look cautious. This [Dave Oran's idea] assumes that a forwarding entity can tell the difference between a hippity and a hop. I quite like Dave's idea, but without the hippity/hop distinction. That is, we could allocate a larger field, and simply have the routers decrement it by a large number. This solves your "update all the hosts" objection, or rather, converts it to an "update all the routers" problem, which is smaller, and probably really just "update routers on long paths", which is even smaller. That is, put the knob on the routers, and allow them to turn down the size of the decrement of the hop count field as needed. That way we get the benefits of a larger maximum hop count, don't have to suffer packet loops for more than the maximum path (plus a bit) really requires, and don't have to update hosts to allow for a longer maximum path if/when one appears. In any case, as long as the header field is big enough, whatever changes are necessary to accomodate a bigger internet than we can forsee are easier to make, as the change can be implemented host by host or router by router, with no mass changes involved - surely that should be a major aim? kre From owner-Big-Internet@munnari.oz.au Wed Oct 7 23:46:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12135; Wed, 7 Oct 1992 23:46:45 +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 AA12123; Wed, 7 Oct 1992 23:46:29 +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, 7 Oct 92 09:46:21 EDT Received: by chiya.bellcore.com (4.1/4.7) id for kre@munnari.oz.au; Wed, 7 Oct 92 09:46:20 EDT Date: Wed, 7 Oct 92 09:46:20 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9210071346.AA23387@chiya.bellcore.com> To: deering@parc.xerox.com, kre@munnari.oz.au Subject: Re: EIDs Cc: big-internet@munnari.oz.au > > Unless things have changed recently, PIP didn't carry addresses > either, just routes (I'm sure someone will correct me if I'm > wrong here) - and while the routes could possibly be used for > identification purposes the way that addresses can, they'd be > even less suited. > Depending on how you set it up, the Routing Directive can be *semantically identical* to a hierarchical address. (Even though the mechanism that a router uses to search the forwarding table is different.) Therefore, anything you can do with a hierarchical address you can also do with a Pip RD. PX be fooled; e.g. plug your ethernet interface into a 1' terminated test network. Nothing short of actually sending real packets to other hosts in and out the interface is as good. Noel From owner-Big-Internet@munnari.oz.au Wed Oct 7 23:59:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12544; Wed, 7 Oct 1992 23:59: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 AA12537; Wed, 7 Oct 1992 23:59:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25765; Wed, 7 Oct 92 09:59:38 -0400 Date: Wed, 7 Oct 92 09:59:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210071359.AA25765@ginger.lcs.mit.edu> To: dee@ranger.enet.dec.com, pgross@ans.net Subject: Re: IESG Deliberations [criteria] Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The impact on current and future security plans should be addressed. For example, do current security mechanisms such as address and protocol port filtering work in the same manner as they do today, and what is the effect on security and authentication schemes currently under development. Can anyone suggest additional text to strengthen that section? Yes. For one the routing architecture should be proof against Byzantine attack; i.e. it should be impossible to disrupt service by disrupting the routing. Radia Perlaman's PhD thesis (presented to the IETF plenary a while back) shows how to do this, so the architecture to do that exists. We need a *lot* more content here, in the form of a list of specific security goals such as the one I just gave. Noel From owner-Big-Internet@munnari.oz.au Thu Oct 8 00:19:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13842; Thu, 8 Oct 1992 00:19:51 +1000 (from owner-Big-Internet) Return-Path: Received: from coombs.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13797; Thu, 8 Oct 1992 00:19:22 +1000 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA12045; Thu, 8 Oct 92 00:17:59 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9210071417.AA12045@coombs.anu.edu.au> Subject: Re: Hop Limit field in SIP To: big-internet@munnari.oz.au Date: Thu, 8 Oct 92 0:17:59 EST In-Reply-To: <10759.718461606@munnari.oz.au>; from "Robert Elz" at Oct 7, 92 10:40 pm Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] Someone mentioned a little bit back about using 2 types of TTL values, but this seems to have been lost amongst the discussion of using a timestamp in the hop field. If you have a "cluster" of routers (such as those that make up T3 CNSS clusters) you decrement the hop-count as a packet either goes in to the cluster or out of the cluster and while the packet is being shifted between routers in the cluster, a different hop count is used to prevent internal loops. If the hopcount were to be restricted to 16 bits, would 8 bits be too few for each count ? Even a split of 4/12 of 16 bits (internal/external hop counts) may be useful ? Maybe include the 'internal' hop count to include going from one interface to another inside a router ? Darren. From owner-Big-Internet@munnari.oz.au Thu Oct 8 00:30:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14173; Thu, 8 Oct 1992 00:31: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 AA14166; Thu, 8 Oct 1992 00:30:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25982; Wed, 7 Oct 92 10:30:51 -0400 Date: Wed, 7 Oct 92 10:30:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210071430.AA25982@ginger.lcs.mit.edu> To: deering@parc.xerox.com, vaf@valinor.stanford.edu Subject: Re: Splitting the network layer: take 2 Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu They just represent two different ways of hierarchically partitioning the graph that is formed from all of the links in the Internet. Yes, yes, *yes*! This *one* of the key properties of a good addressing heirarchy Both the provider-based addresses and the metro-based addresses proposed for SIP and IPAE follow network topology. Do the metro-based addresses really follow network topology, though? Isn't the whole point of metro addresses that your address doesn't depend on which provider you are attached to, which surely *is* an important part of the topology? The case has not yet been made that endpoint IDs, whatever they are, are necessary. To you, maybe not. To me, it was done quite adequately in: Jerome H. Saltzer; "On the Naming and Binding of Network Destinations"; Local Computer Networks, North-Holland Publishing; 1982. and I cheerfully give Jerry most of the credit, with a tip of the hat to Dave Oran for pointing out that we should be naming end-end entities, not hosts. (I can't find my copy of Jerry's note in the mass of debris which calls itself by office, but I *think* he spoke in terms of hosts.) Noel From owner-Big-Internet@munnari.oz.au Thu Oct 8 00:40:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14442; Thu, 8 Oct 1992 00:40:33 +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 AA14438; Thu, 8 Oct 1992 00:40:11 +1000 (from jonson@server.af.mil) Received: by server.af.mil (5.59/25-eef) id AA14620; Wed, 7 Oct 92 09:38:41 CDT From: Matt Jonson Message-Id: <9210071438.AA14620@server.af.mil> Subject: Re: Hop Limit field in SIP To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 7 Oct 92 9:38:37 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <9210061940.AA21134@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 6, 92 3:40 pm X-Mailer: ELM [version 2.3 PL11] > Subject: Re: Hop Limit field in SIP > > Maybe we should look for a routing architecture in which packets *cannot* > loop? Do X.25 networks have hop counts on packets? Do we have an X.25 > internals expert in the house? > Don't forget that X.25 just defines the interface to the data network, all the internals are entirely up to the vendors supplying the network. The way BBN did it is different from Codex etc. I believe some models are very virtual circuit oriented (i.e. all packets on a vc traverse the same path after flow set-up) and some are datagram oriented (BBN & MILNET/ARPANET). In all cases they are proprietary. Be that as it may, it would be interesting to see the mechanisms used. Just bear in mind that one way doesn't represent "the way that X.25 does it." /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 Thu Oct 8 00:56:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15044; Thu, 8 Oct 1992 00:56:57 +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 AA15036; Thu, 8 Oct 1992 00:56:47 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA08198; Wed, 7 Oct 92 07:56:38 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA12008; Wed, 7 Oct 1992 10:56:31 -0400 To: throop@dg-rtp.dg.com (Dean D. Throop) Cc: dennis@ans.net, big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP In-Reply-To: <9210062025.AA06176@walrus> References: <9210062025.AA06176@walrus> X-Mailer: Poste 2.0 From: David R. Oran Date: Wed, 7 Oct 92 10:56:27 -0400 Message-Id: <921007105627.12546@sneezy.lkg.dec.com> Encoding: 41 TEXT, 6 TEXT SIGNATURE > > Yes, this is true, but in addition to reliability there is a problem > > of chickens and eggs. If you need a synchronized clock to send > > datagrams, how are you going to send NTP datagrams to synchronize > > your clock? > > The protocol could allow an expiration time of zero to be used in > packets that aren't forwarded. Thus a new router could talk with > its peers to get the time of day by using a zero expiration time. > Once the router knew the time, it could build packets that are > forwarded. > This requires that the topology of the time-providers be congruent with the topology of the routers, or that at least one router on each subnet have an external time source, Do we want to create this kind of topological dependency? > If we wanted, we could allow hosts to always put a time of zero > in their packets and the first router could fill in a reasonable > expiration time when forwarding the packet. This would free hosts > from have to run NTP and put all the burden on the routers. > ... This certainly makes sense. It would probably also result in all the host implementations just slapping zero in every packet. Then we're back to the routers having to change the header of every packet and recomputing the checksum. It still potentially wins since only the first-hop roueter has to do it. > > > > In any case while this is interesting, and while I certainly wouldn't > > mind seeing NTP relied upon by enough applications that it became > > required for Internet entities with clocks, I think the network layer > > is a little bit too fundamental to depend on this. > > It sounds like a good project for some eager graduate students. > Let them build it and tell us how well it works. > > > > Dennis Ferguson > You seem to have a lower opinion of graduate students than I do :-) Dave. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Thu Oct 8 01:31:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16222; Thu, 8 Oct 1992 01:36:10 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16064; Thu, 8 Oct 1992 01:31:58 +1000 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA03859; Wed, 7 Oct 92 08:28:42 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA12060; Wed, 7 Oct 1992 11:28:24 -0400 To: Christian Huitema Subject: Re: Multiple addresses In-Reply-To: <199210071004.AA22041@mitsou.inria.fr> References: <199210071004.AA22041@mitsou.inria.fr> Cc: Juha Heinanen , big-internet@munnari.oz.au X-Mailer: Poste 2.0 From: David R. Oran Date: Wed, 7 Oct 92 11:28:14 -0400 Message-Id: <921007112814.12546@sneezy.lkg.dec.com> Encoding: 26 TEXT, 6 TEXT SIGNATURE > >Look at how NSAPs are used in IS-IS or IDRP. they just identify boxes, > >not their interfaces. and i can't see any need to identify an interface > >in normal routing. > > They dont. In a LS routing protocol like IS-IS, you have to identify "points > in the graph", i.e. relays. A relay has one single identification. However, > if you want to set up a host that has multiple connections for better > reliability but that does not want to engage in relaying nor in running the > routing protocol, then this host will need several addresses -- one per > interface. > > Christian Huitema Gee, I hate to disagree with you Christian, but in ISIS a "relay" does not have one single identification. The protocol goes to great lengths to ensure that a relay is in fact represented by an equivalence class of identifiers, and in fact has distributed agreement algorithms to ensure that all the ISs know the equivalence class. The reason is that the identifiers are topologically sensitive and you need a way to gracefully change the set of identifiers that identify the relay in a way that maintains the map invariants of LS routing. We can take this offline if you want a more detailed explanation or you want to refine what, I think you mean by the term "relay". -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-big-internet@munnari.oz.au Thu Oct 8 01:50:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16639; Thu, 8 Oct 1992 01:50: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 AA12216; Wed, 7 Oct 1992 23:49:19 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25686; Wed, 7 Oct 92 09:49:06 -0400 Date: Wed, 7 Oct 92 09:49:06 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210071349.AA25686@ginger.lcs.mit.edu> To: Juha.Heinanen@datanet.tele.fi, deering@parc.xerox.com Subject: Addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu i can have a host that at the same time belongs to many routing domains (and thus has many addresses) and it can have only one, eg. Ethernet interface through which all packets arrive. So? It has one interface, which has many addresses. What's the problem? also i can have a whole backbone of routers that all serve many customer routing domains and thus have many interfaces and many adresses, but you can't say which address is bound to which interface. Sure you can. Each interface is named (i.e. addressed) by the place it is connected to the network. the routers can receive any packets via any interface. That's just because of the current confusion between interface names (existing adddresses) and host names (don't have one...). Noel From owner-big-internet@munnari.oz.au Thu Oct 8 02:10:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17201; Thu, 8 Oct 1992 02:10:40 +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 AA12398; Wed, 7 Oct 1992 23:55:56 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25748; Wed, 7 Oct 92 09:55:45 -0400 Date: Wed, 7 Oct 92 09:55:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210071355.AA25748@ginger.lcs.mit.edu> To: Juha.Heinanen@datanet.tele.fi, deering@parc.xerox.com Subject: Re: per-interface addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu i can also have a host which belong to RD's, thus has two addressse, and has, two say ethernet, interfaces, and you can't tell which one belongs to which address, since it can receive packets with both destination addresses from both. Again, this is just because one thing (the existing "address") is being used to do two thing - identify an interface (so routers can send the packet there), and name the host. We propose to eliminate the second usage, and provide a separate namespace (the EID) to do that. Noel From owner-big-internet@munnari.oz.au Thu Oct 8 02:51:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18495; Thu, 8 Oct 1992 02:52:50 +1000 (from owner-big-internet) Return-Path: Received: from enet-gw.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12414; Wed, 7 Oct 1992 23:56:59 +1000 (from huston@cfsctc.enet.dec.com) Received: by enet-gw.pa.dec.com; id AA16720; Wed, 7 Oct 92 06:31:03 -0700 Message-Id: <9210071331.AA16720@enet-gw.pa.dec.com> Received: from cfsctc.enet; by decwrl.enet; Wed, 7 Oct 92 06:38:59 PDT Date: Wed, 7 Oct 92 06:38:59 PDT From: "Steve Huston, ASD/SEE Engineering, 244-7117" To: juha.heinanen@datanet.tele.fi Cc: deering@parc.xerox.com, big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, deering@parc.xerox.com, juha.heinanen@datanet.tele.fi Subject: RE: per-interface addresses >i can also have a host which belong to RD's, thus has two addressse, and >has, two say ethernet, interfaces, and you can't tell which one belongs >to which address, since it can receive packets with both destination >addresses from both. i can very easily demonstrate this with the very >host i'm using to send this message. Yup, this is true, and common in real networks. I fought against this idea once while a little wet behind the ears but was finally brought to see it 'correctly' (Hi Rob ;-) >the problem of partially connected subnets is not unique to FR. it >applies also to X.25, SMDS, and most importantly the new ATM technology >for which whatever the new routing architecture should definitely be a >good match. Also a good point. This is common in enterprise networks where X.25 is used to link sites. In a previous job, the company had a world-wide part-public, part-private X.25 net - the 1:1 interface:address mapping didn't match reality at all. -Steve From owner-big-internet@munnari.oz.au Thu Oct 8 03:28:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19003; Thu, 8 Oct 1992 03:29:28 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12747; Thu, 8 Oct 1992 00:00:54 +1000 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA01707; Wed, 7 Oct 92 06:58:13 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA11925; Wed, 7 Oct 1992 09:57:57 -0400 To: John Curran Subject: Re: Penultimate TUBA Charter, IDs and names In-Reply-To: <9210061950.AA28031@p.lanl.gov> References: <9210061950.AA28031@p.lanl.gov> X-Mailer: Poste 2.0 From: David R. Oran Date: Wed, 7 Oct 92 09:54:10 -0400 Message-Id: <921007095410.12546@sneezy.lkg.dec.com> Resent-To: big-internet@munnari.oz.au Resent-From: David R. Oran Resent-Date: Wed, 7 Oct 92 09:57:51 -0400 Resent-Message-Id: <921007095751.12546@sneezy.lkg.dec.com> > I would claim that XYZ should *not* accept your EID, or use it, unless > it *has* talked (across the transatlantic links) briefly to the DEC-LKG > authority. Once that conversation has been made, then all traffic would > indeed remain local, relying on the cached information in the lcoal name > server. > Sigh. The fundamental flaw is using reverse translation for access control. DECnet Phase IV and Phase V do this and I can tell you it causes no end of pain. This is expecially true in phase V which uses a name service to do the reverse translation. The inaddr.arpa domain hack for the DNS is already stressed and will become even more stressed as the net grows and the topological hierarchy gets more divorced from the naming hierarchy. Once ei Can't we just de-certify this and tell peoplethat if they want to do access control on the bases of host names that you use kerberos or Sphinx or something that works. From owner-Big-Internet@munnari.oz.au Thu Oct 8 03:48:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19279; Thu, 8 Oct 1992 03:48:31 +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 AA19276; Thu, 8 Oct 1992 03:48:21 +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 6802; Wed, 07 Oct 92 13:47:19 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 0790; Wed, 07 Oct 92 13:47:19 EDT Date: Wed, 07 Oct 92 13:43:34 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Hop Limit field in SIP To: Noel Chiappa , craig@aland.bbn.com Cc: big-internet@munnari.oz.au In-Reply-To: <9210061925.AA21002@ginger.lcs.mit.edu> Message-Id: <921007.134334.EDT.VALDIS@vtvm1.cc.vt.edu> On Tue, 6 Oct 92 15:25:54 -0400 Noel Chiappa said: >Bzzzrraack! Here we go again, driving screws with a hammer. Dammit, if we want >a traceroute function, design an ICMP message to do it! I am *SOOOOO* sick of >kludges! Sure, sometime you have to kludge to get something done, but then we >turn around and make it a fundamental architectural principle, when all it was >was a quick, disgusting, hack, kludge (like the IGP/EGP split). I'll *happily* accept an ICMP ECHO with the RECORD ROUTE option, if we remove the restriction that only 5 (or whatever it is) addresses get recorded. In fact, I'd *prefer* that to the current 'traceroute' scheme of sending out packets with increasing TTLs and watching for TTL Expired ICMP's coming back. Toss one packet, and be done. If properly designed, a 'record route' would return with the *complete* path taken *both* ways (to detect asymmetric routes - not doable easily now), and the reason for turnaround (target host reached, net unreachable, TTL exceeded, etc). /Valdis From owner-Big-Internet@munnari.oz.au Thu Oct 8 03:48:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19321; Thu, 8 Oct 1992 03:50:23 +1000 (from owner-Big-Internet) Return-Path: Received: from daisy.ee.und.ac.za by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19275; Thu, 8 Oct 1992 03:48:19 +1000 (from barrett@daisy.ee.und.ac.za) Received: by daisy.ee.und.ac.za (smail3.1.22+apb920812#178) id m0mcdM4-0000Q0C; Wed, 7 Oct 1992 17:31:16 +0200 (SAST) Sender: Alan P Barrett Date: Wed, 7 Oct 1992 17:11:35 -0200 () From: Alan Barrett Subject: Re: EIDs To: big-internet@munnari.oz.au In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=us-ascii Newbie alert: I have just joined this mailing list. In <10639.718453154@munnari.oz.au>, kre said: > So, perhaps we should add an identification layer (John Curran, > where are you?) - but then again, if the bits are going to be > in every packet, it doesn't make any real difference what > the region of the packet where they're carried is called. Perhaps the session layer is the right place for this new "identification layer". An EID could live at the the session layer, and if the entity identified by an EID migrates to a different host, or the host moves to a different network-layer address, then the session layer would have to close the old transport-layer connection and open a new one. > If EIDs can be used to provide a useful tool for handling > mobile hosts, that's fine, but not the primary goal. The > mechanism is more likely to be a greater decoupling of addresses > from identification, with addresses not expected, in any > circumstances, to remain constant for the lifetime of even > relatively short conversations - a typical mail message would > probably retain an address, but FTP might not, and TELNET > would be very likely to span several address changes - > distinguished purely by the average length of these types of > connections of course. This is sounding more and more like a session-layer function to me. A single session spanning multiple transport connections. --apb Alan Barrett, Dept. of Electronic Eng., Univ. of Natal, Durban, South Africa RFC822: barrett@ee.und.ac.za Bang: m2xenix!undeed!barrett From owner-big-internet@munnari.oz.au Thu Oct 8 03:54:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19402; Thu, 8 Oct 1992 03:54:28 +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 AA11484; Wed, 7 Oct 1992 23:26:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA25463; Wed, 7 Oct 92 09:25:25 -0400 Date: Wed, 7 Oct 92 09:25:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210071325.AA25463@ginger.lcs.mit.edu> To: Juha.Heinanen@datanet.tele.fi, jnc@ginger.lcs.mit.edu Subject: Re: Multiple addresses Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu look at how NSAPs are used in IS-IS or IDRP. they just identify boxes, not their interfaces. and i can't see any need to identify an interface in normal routing. The problem is that a 'box' is not a particularly useful thing to name. It *is* useful to name one end of a reliable connection (i.e. and end/end or fate-sharing region, to be technical), for purposes of maintaining the connection, and it is useful to name a place in the network, so that you know where you are delivering packets too. The interface is simply the place that the system of routers delivers packets to; that's why you name interfaces. Let's try this another way. We have these things, which you call addresses, but you insist they not tbe the addresses of interfaces. OK, but let's not call them "addresses", because that seems to have too many meanings to different people; let's call them "fnortzes". :-) You said that a 'box' can have more than one 'fnortz', right? Can you please answer the following *informational* questions about exactly what a 'fnortz' does: 1) Does a box with more than one interface *have* to have more than one fnortz (at least, if you expect to get traffic to come in both interfaces). 1a) Can a box with only one interface have more than one fnortz? 2) When you pick a box up and permanently plug it in somewhere else in the network a long way away, does its fnortz change? The answers to these questions will help me tell exactly what the properties of a fnortz are, and then we can ask the question "is a thing with these properties *useful*". i repeat, it should be enough that each machine connected to the multiaccess network has one or more addresses. this works fine with IS-IS or IDRP. there is no need to address ports in a well designed routing architecture. We seem to be having terminology confusion here. When I talked about "ports", and "each port should have its own address", I meant hardware port, i.e. wire; i.e. place you plug in a machine. I am basically agreeing with you that "each machine connected to the multiaccess network has one or more ". because currently if I route IP and a box is connected over FR/ATM to 100 other boxes, i have to define for this FR/ATM interface 100 addresses so that it has one address common with all those other boxes it wants to talk to. note that i may want for many reasons to treat the FR/ATM network as prodiving me 100 virtual point-to-point lines. I think the problem you are referring to here is the desire of each small community which is attached to a common-carrier WAN to have its own IP (sub) network number for that community, yes? This couples with the tenet of the IP routing architecture (such as it is :-) which says "a machine on (sub)network X cannot communicate directly with a machine on (sub)network Y without going through a router" [which is a corollary of the tenet that "a phsyical network has *an* IP (sub)network number"] to produce all *sorts* of routing problems on such WAN's, including extra hops through routers when going from one machine on the WAN to another, and the problem you seem to be alluding to. These problems could be fixed by following the architecture, and giving all the machine attached to a WAN addresses from a single network number (e.g. class A), but nobody wants to do that; they all want to use a subnet of their previously allocated network number to refer to their hosts on the WAN, because the allocation issues are easier. Well, "there's no such thing as a free lunch". The allocation is easier, yeah, but the routing doesn't work any more. You can't just violate the tenets of the routing architecture and expect the routing to still work..... Noel From owner-big-internet@munnari.oz.au Thu Oct 8 04:20:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20012; Thu, 8 Oct 1992 04:20: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 AA12988; Thu, 8 Oct 1992 00:02:51 +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, 7 Oct 92 10:02:44 EDT Received: by chiya.bellcore.com (4.1/4.7) id for deering@parc.xerox.com; Wed, 7 Oct 92 10:02:44 EDT Date: Wed, 7 Oct 92 10:02:44 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9210071402.AA23426@chiya.bellcore.com> To: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: EIDs I sense that there is general agreement out there that more than a single hierarchical address alone is necessary. For mobility, you need *something* other than just the topologically current address. The columbia and sony schemes use a second IP address. These do have the advantage of both identifying the endpoint and providing an address that can be used to learn the current address. Pip needs *something* other than plain address, because the "address" thing can change from packet to packet (for various reasons, like policy changing, or because you are path splitting, or because you are "filling in" the address as the packet exits, or mobility, or whatever). I'm finding that taking all identifying semantics out of the address thing buys you a lot of flexibility (of course, at a cost......that of requiring a separate means of identifying.....) So, the question is not whether we need identifiers, but what they should look like, when they should be in the packet, whether we should try for a general purpose identifier or custom do it on a per application basis, etc. There are real engineering trade-offs to be made here, and we don't understand them all. Still, I think we can slice the problem up in such a way that we buy ourselves a lot of functionality with little risk....... First, take all identification out of the address (or, at least make it possible to identify without relying on the address). The router need never look at the id for forwarding purposes. Second, design the host part of the protocol so that it can treat the ID as a flat, unique number for plain identification purposes. Third, for special applications, allow the ID to contain hierarchical information in whatever form is appropriate. So, the ID *can* contain the address of the router that holds a mobile host's current address, or it *can* contain the info needed for a reverse DNS lookup, or it *can* contain information to allow billing, etc. Just because we don't have all the answers doesn't mean we shouldn't go ahead and define an ID for those things we do find useful..... PX From owner-big-internet@munnari.oz.au Thu Oct 8 04:36:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20344; Thu, 8 Oct 1992 04:36:34 +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 AA13908; Thu, 8 Oct 1992 00:21:40 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA06758; Wed, 7 Oct 92 07:21:11 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA11962; Wed, 7 Oct 1992 10:21:04 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: Hop Limit field in SIP In-Reply-To: <9210062011.AA21446@ginger.lcs.mit.edu> References: <9210062011.AA21446@ginger.lcs.mit.edu> X-Mailer: Poste 2.0 From: David R. Oran Date: Wed, 7 Oct 92 10:20:56 -0400 Message-Id: <921007102056.12546@sneezy.lkg.dec.com> Encoding: 24 TEXT, 6 TEXT SIGNATURE > Could be... Maybe we go back to TTL, but you have to set the TTL to a value > based on somethign you hear from your router, not from a fixed constant? > This is a good idea. ESIS has always had the mechanisms to have the ISs tell the ESs certain policy variables, like timers and such. For IP/SIP there are a couple of simple mechanisms that come to mind: a) use DHCP b) piggyback the information on ICMP redirects The latter has the advantage of the routers being able to set different TTLs for different destinations, but requires the hosts to cache and use per-destination TTL values. In general, I like the idea that tunable parameters that have potentially global effects be controlled in the routers and not the hosts. The same idea applies to the Timestamp methods being discussed. The routers could advise the hosts of the delta to use to construct the time-to-die. Dave. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-big-internet@munnari.oz.au Thu Oct 8 04:57:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20746; Thu, 8 Oct 1992 04:57:58 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210071857.20746@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13380; Thu, 8 Oct 1992 00:07:52 +1000 (from kwe2@BBN.COM) From: "Kent W. England" Subject: Re: Multiple addresses [partial mesh subnets] To: Juha.Heinanen@datanet.tele.fi Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: <9210062027.6617@munnari.oz.au> Date: Wed, 7 Oct 92 10:05:07 EDT Mail-System-Version: >... if I route IP and a box is connected over FR/ATM to >100 other boxes, i have to define for this FR/ATM interface 100 >addresses so that it has one address common with all those other boxes >it wants to talk to. note that i may want for many reasons to treat the >FR/ATM network as prodiving me 100 virtual point-to-point lines. > >i'm really suprised if this is something new to you. or may be i have >missed something big during these years in configuring my boxes for IP. >or may be i'm the only one of the whole gang who has this kind of >networks to play with. > >-- juha Well, you aren't the only one playing with frame relay, but there aren't many yet and the kludges we have to put up with today are onerous. The only reason I would want to put up with the burden of treating each virtual circuit as a separate IP subnet would be so that my desired routing would match the IP subnet paradigm, which is that an IP subnet is fully connected and that "direct" communication requires sharing a common subnet. I have no other reason to want to map IP to the VC level. I would much rather do it at the interface level and I would really rather expand the IP subnet paradigm than kludge routing. The biggest problem we face with making routing (both DV and LS) work properly over partially connected subnets is the fact that every one of the router implementations assumes that a subnet is fully connected. Split horizon assumes this. The OSPF NBMA designated router optimization relies on this. Both of these features defeat routing in partial mesh frame relay networks. Another problem is that the IP subnet paradigm assumes that two devices in direct communication share a common subnet. This causes problems with hosts/routers attached to Very Large Public Data Networks such as SMDS and ATM services and is the point of Paul Tsuchiya's shortcut routing proposal, where a small subset of router neighbors still permits direct (or shortcut) communication amongst a much larger set of fully connected devices which may not share common subnet addresses. I think we need to broaden the IP subnet paradigm. We need to make sure that new proposals for routing architectures don't lock in the old subnet paradigms so that new routing protocols in the new architecture can be flexible enough to work over large public data networks, both partially connected shared subnet and fully connected with no shared subnet. --Kent From owner-big-internet@munnari.oz.au Thu Oct 8 05:32:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21395; Thu, 8 Oct 1992 05:33:01 +1000 (from owner-big-internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14774; Thu, 8 Oct 1992 00:50:22 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA08055 (5.65c/UK-2.1-921001); Wed, 7 Oct 1992 10:50:43 -0400 From: Gary Scott Malkin Date: Wed, 7 Oct 1992 10:50:43 -0400 Message-Id: <8055.199210071450@atlas.xylogics.com> To: Christian.Huitema@sophia.inria.fr Cc: big-internet@munnari.oz.au In-Reply-To: Christian Huitema's message of Wed, 07 Oct 92 10:49:37 -0500 <199210070949.AA21990@mitsou.inria.fr> Subject: TIME to die (was Re: Hop Limit field in SIP) Christian, At this point, I'm still considering the timestamp issue. Certainly it has pluses and minuses. However, I really don't think we can use intrastellar arguments here. In the first place, the fastest object (not counting subatomic particles) ever created was Voyager 2. It's speed, relative to earth, is about 103,000mph. This is a very, very small fraction of 1% of lightspeed. Also, the Apollo series did not suffer from the time dilation effects (which were measurable, though only with atomic clocks). Finally, the dilation effect can be taken into account to correct any differences large enough to matter. Besides, when sending packets to the moon and beyond the propagation delay is so large that a millisecond distortion wouldn't matter. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-big-internet@munnari.oz.au Thu Oct 8 06:10:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22158; Thu, 8 Oct 1992 06:10:44 +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 AA14329; Thu, 8 Oct 1992 00:35:32 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA07336; Wed, 7 Oct 92 07:35:20 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA11978; Wed, 7 Oct 1992 10:35:10 -0400 To: Steve Deering Subject: Per-Interface vs. Per-"Network Entity" addresses In-Reply-To: <92Oct6.131323pdt.10779@skylark.parc.xerox.com> References: <92Oct6.131323pdt.10779@skylark.parc.xerox.com> Cc: Juha Heinanen , big-internet@munnari.oz.au X-Mailer: Poste 2.0 From: David R. Oran Date: Wed, 7 Oct 92 10:34:56 -0400 Message-Id: <921007103456.12546@sneezy.lkg.dec.com> Encoding: 47 TEXT, 6 TEXT SIGNATURE > Isn't there also a management problem in *not* having per-interface > addresses? It means that you cannot force a packet to be delivered to > a particular interface, for example a ping packet meant to diagnose > whether or not an interface is working. This problem has arisen in > the current Internet in domains that have relaxed the need for every > interface to have its own address, e.g., when using so-called "unnumbered > links". I consider unnumbered links to be an unfortunate development, > that I assumed was mainly driven by inadequate support for variable-length > subnets. > Sorry, Steve, I don't follow this argument. You don't need per-interface addresses to diagnose an interface. There are two cases: a) you can ping the box successfully b) you can't ping the box successfully If (b) you can't talk to *any* of the boxes intrerfaces, so the point is moot. If the box has multiple addresses you try all of them until you find one that works. Then you go on to case (a). Once you can talk to the box, you send SNMP requests to ask about the state and counters of each of the interfaces. You look at the numbers and diagnose which interfaces are working and which are not. This will give you a clue about intermittent failures which a simple ping will not. We see this all the time with flakey Ethernet interfaces that drop 20% of the packets sent to them due to buffer overruns and the like. If this information is not available through SNMP, then I'd claim there's a big hole in either SNMP or the MIB. I suspect there's no hole here since working/not working is so fundamental to any useful network management diagnosis system. Further, the idea of per-interface addresses breaks down in certain network interconnect schemes. Do you want separate IP addresses on each MAC of a dual-MAC FDDI? I'm not sure there's any way to "force a packet to be delivered to a particular interface" in this case anyway. You have to map the ring ad the datalink layer to get useful information about what's broken and where. Not being able to ping a particular station's particular MAC is probably misleading for fault diagnosis. Dave. P.S. This is not meant to necessarily take sides on whether interfaces ought to have addresses or not. It was simply meant to argue that diagnosis was not a good reason. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-big-internet@munnari.oz.au Thu Oct 8 07:37:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23824; Thu, 8 Oct 1992 07:37:51 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210072137.23824@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10772; Wed, 7 Oct 1992 23:02:51 +1000 (from jcurran@nic.near.net) To: Steve Deering Cc: Robert Elz , big-internet@munnari.oz.au Subject: Re: EIDs In-Reply-To: Your message of Wed, 07 Oct 92 20:19:14 +1000. <10639.718453154@munnari.oz.au> Date: Wed, 07 Oct 92 09:02:41 -0400 From: John Curran -------- From: Robert Elz Subject: Re: EIDs Date: Wed, 07 Oct 92 20:19:14 +1000 Date: Wed, 7 Oct 1992 00:21:23 PDT From: Steve Deering Message-ID: <92Oct7.002134pdt.10779@skylark.parc.xerox.com> ... I suppose the question must be asked whether this is all the internet layer should be doing? Certainly with IP it does much more, including identification of the two end-points. Maybe that's just a historical accident that should be fixed, but clearly identification is needed somewhere, and as addresses become more topologically significant, and hence more likely to vary short term, even for supposedly fixed hosts, I don't feel that they should be overloaded to perform the identification role. So, perhaps we should add an identification layer (John Curran, where are you?) - but then again, if the bits are going to be in every packet, it doesn't make any real difference what the region of the packet where they're carried is called. That is, but the routing header first, then the identification header, then the transport header, and then the payload - you can lump the first two parts together and call them the internet header, or separate them acd treat it as two layers, this seems to be a quibble. If you think that internet headers should carry EIDs, in addition to, or as a subfield of, addresses, please answer in detail: ... Attached is one possible approach. I had intended to release this later (as the transition section is not ready), but the current thread would probably be easier with this in circulation. Once the transition section is complete, I will send the entire document in as an I-D. For those of you who have seen an earlier draft, the version below has a new name and numerous editorial changes. Enjoy, /John --- Internet Draft J. Curran October 1992 BBN TCP & UDP with Network-independent Endpoints (TUNE) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or rendered obsolete by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet- drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. Abstract This memo proposes a strategy for providing TCP and UDP services over _multiple_ network services in a manner compatible with existing TCP/IP applications. By introducing network-independent endpoint identifiers for transport entities, TUNE makes it possible to change network addresses (and potentially network protocols) without impact to the application layer. While this paper describes the use of Connection-Less Network Protocol [1] as a possible long-term network service for the Internet, the overall approach differs from the "TCP & UDP with Bigger Addresses" [2] initiative due to the addition of network-independent endpoint identifiers. TUNE also provides network layer programming interfaces which are unchanged from those of the current Internet Protocol (IP) suite and hence alleviate the need for application code changes during initial deployment. Comments should be sent to the author (jcurran@bbn.com). Curran Expires April, 1993 [Page 1] Internet Draft TUNE Overview October 1992 Acknowledgments Sincere thanks to the members of the TUBA mailing list who had to endure these ideas at very early stage, and in particular, thanks to Ross Callon, Dave Piscitello, and Paul Tsuchiya for bearing with my endless questions. Table of Contents 1 Introduction 2 TUNE Architecture 2.1 Endpoint Identifiers (EIDs) 2.2 EID Resolution 2.3 TUNE Header Format 3 TUNE Administration 3.1 Autoconfiguration 3.3 Portability 3.3 Mobility 4 TUNE Transition Plan 4.1 Use of IP address space 4.2 IP/TUNE translation 5 Appendixes 6 Security Considerations 7 References 8 Author's Address 1.0 Introduction Recent growth in the Internet has revealed several significant scaling problems in the current Internet routing and addressing architecture. It is generally acknowledged that continued deployment Curran Expires April, 1993 [Page 2] Internet Draft TUNE Overview October 1992 of non-hierarchical addresses will result in unacceptable growth to transit routing tables in the Internet. While the "Classless Inter- Domain Routing" [3] approach to address assignment and route aggregation should minimize routing table explosion for the immediate future, it is not positioned as a long-term solution to the routing, addressing, and scaling problems. From a purely technical viewpoint, strict hierarchical addressing could be used to create a highly-scalable Internet routing architecture. Topologically-assigned addresses for network attachment points would minimize the need for routing information exchange. It would be necessary to use addresses of sufficient size to fully represent the network topology, but large hierarchical addressing plans have already been proposed for some protocol suites [4]. There are two minor administrative problems in using topologically- assigned addresses as a basis for long-term solution to the routing problem: Topologically-assigned addresses cannot provide organizations with geographic and service provider mobility. As a result, organizations using topologically-assigned addresses are forced into address migrations when relocating. While autoconfiguration and directory services may eventually minimize the use of network addresses in configurations, these services do not currently provide relief for network address changes. Furthermore, the existence of larger hierarchically-assigned addresses does not insure their usage by the thousands of applications which currently work over today's Internet. Several of the proposed routing and addressing solutions call for changing the programming interfaces for TCP and UDP services to support larger addresses. As a consequence, every existing network application will have be revised, and organizations will have to insure that they have the "upgraded" versions of all their network applications before moving to the new architecture. It will be necessary to phase in the usage of larger addresses in a controlled manner in order to bring about their acceptance by the Internet community. TCP & UDP with Network-independent Endpoints (TUNE) is one possible strategy for resolving the routing and addressing problems in the current Internet while accommodating existing applications. The TUNE architecture provides for the delivery of TCP and UDP messages in a manner similar to IP, but goes further by formally separating endpoint identification from network attachment information to improve mobility and scaling. By allowing the use of existing IP addresses as one class of endpoint identifiers, TUNE provides for an Curran Expires April, 1993 [Page 3] Internet Draft TUNE Overview October 1992 initial transition to TUNE services without application code changes. This document describes the overall TUNE architecture and a migration plan for transition to CLNP network services. While TUNE will function over almost any network service, CLNP's existing hierarchical network addressing will require minimal routing information exchange once TUNE is deployed. In addition, the availability of CLNP services in the current Internet will accelerate the deployment process and eliminate the risks associated with the development of a new network layer service. 2.0 TUNE Architecture TCP & UDP with Network-independent Endpoints (TUNE) details a convergence layer between the Internet transport and underlying network datagram delivery services. The purpose of this layer is to allow identification of transport endpoints independent of the underlying network addressing scheme. This is analogous to the role that the Address Resolution Protocol [5] plays in allowing network address selection unconstrained by physical interface address. TUNE's relationship to other network services can be depicted as follows: +---------------------------------------+ | (Applications) | + +------------------+ +====================+ DNS | Name Resolution | Transport Layer +__________________+ | TCP, UDP, etc. | + +------------------+ |====================+ TUNE | Endpoint Resolution | Network Layer +__________________+ | IP, CLNP, IPAE, SIP, etc. | | +------------------+ +====================+ ARP | Address Resolution | Data Link Layer +__________________+ | 802.3, DIX, SLIP, PPP, etc. | | | +---------------------------------------+ TUNE provides two functions: a mapping function from endpoint identifiers to network protocols and addresses, and the labeling of messages with transport endpoint identifiers. While TUNE is not required for successful implementation of TCP and UDP over new network protocols, the benefits of using TUNE include: Curran Expires April, 1993 [Page 4] Internet Draft TUNE Overview October 1992 o Globally unique endpoint identifiers which are independent of network attachment point. o Endpoint identifiers translated to network addresses in a manner transparent to the applications. o Underlying transport provided via multiple network services with diverse address formats. o Hiding of network layer information from higher layers. o Backward-compatible programming interfaces for TCP and UDP services, and application compatibility during transition. o Full utilization of the 32-bit Internet Protocol address space and its existing allocation infrastructure. o Interoperability between IP and TUNE hosts during transition. 2.1 Endpoint Identifiers (EIDs) Datagram-oriented transport protocols have traditionally used network layer addresses during the specification of communication endpoints. It is common for such network addresses to contain has some embedded information regarding the underlying network topology. IP addresses, for instance, implicitly identify the particular network which serves the end system. In the case of CLNP, addresses that are compatible with OSI Intra-domain IS-IS routing protocol [6] include explicit topological information in the "Area Address" (formed from the Initial Domain Part (IDP) and the High-order portion of the Domain Specific Part (HO-DSP) of a given NSAP.) Neither IP nor CLNP provide a endpoint identifier which is independent of network topology. As a result, topological information which is specific to the network must be made available to the applications for inclusion in their transport service requests. Likewise, applications using transport services become dependent upon the specific network attachment points at the time of configuration. TUNE transport services do not require specification of topology information (implied or otherwise) by applications. Communication is provided between globally unique "endpoint identifiers". These endpoint identifiers (EIDs) are assigned hierarchically (for administrative convenience and directory manageability) but do not embody any network topology information. A system with two interfaces (on the same or different networks) will use a single EID for normal communications. Additionally, when a system moves from one network to another, the endpoint identifier does not change. This provides TUNE Curran Expires April, 1993 [Page 5] Internet Draft TUNE Overview October 1992 with endpoint identifiers that are independent of network topology and inherently mobile. The success of a globally unique identification system depends ultimately upon the ease of obtaining identifiers. If the process for acquiring such an identifier is burdensome, then the probability of duplicate identifiers being used increases dramatically. For this reason, TUNE make use of existing allocation schemes for endpoint identifiers whenever possible. Appendix A contains a preliminary specification of the format and allocation process for EIDs. 2.2 EID Resolution In order to transport a TCP or UDP message to the appropriate endpoint, it will be necessary to determine the corresponding network service and address for any given EID. Given the current state of directory services in the Internet, the Domain Name System [7] is a likely choice for providing the EID to network address mapping function. One consequence of using DNS is that each TUNE system will require access to a DNS nameserver via a supported network protocol. Initially, it is anticipated that the existing IP nameservers will be used (with CLNP-only systems using transition services), but deployment of TUNE-supporting nameservers will occur as TUNE systems become more common. Appendix B specifies a DNS services plan for TUNE using the existing DNS software. This plan supports any NSAP format and provides flexibility in the selection of NSEL values for the TUNE service. Once the destination network service is determined, the TUNE message is passed to the appropriate network service along with the destination network address. Delivery of the message is handled as is normal for the particular network service selected; TUNE does not affect the datagram forwarding process in any manner. 2.3 TUNE Header Format Both TCP and UDP currently include a "pseudo-header" during checksum calculation. The pseudo-header includes the network-level source and destination along with the protocol identifier and transport message length. The purpose of this checksum is to insure that the message was delivered to the appropriate endpoint. Since an endpoint identifier is no longer related to the network layer addresses, the use of these pseudo-headers by TCP or UDP must be revised with new endpoint semantics. Under TUNE, the destination of TCP or UDP datagrams can be uniquely identified by the EID and the Curran Expires April, 1993 [Page 6] Internet Draft TUNE Overview October 1992 port number alone. It is not necessary for pseudo-headers to contain network addresses at all, since EIDs are globally unique. In addition, maintaining network addresses in these headers can actually prevent communications in some instances because the messages arrived via a different network protocol or interface than the sender intended. The elimination of network address information in these headers provides for consistent endpoint specification during mobility, and allows the use of multiple network services (with potentially different characteristics) by a single endpoint. The revised TCP and UDP pseudo-header for TUNE operations is: 0 7 8 15 16 23 24 31 +---------+---------+---------+---------+ | source endpoint id (octets 1-4) | +---------+---------+---------+---------+ | source endpoint id (octets 5-8) | +---------+---------+---------+---------+ | destination endpoint id (octets 1-4) | +---------+---------+---------+---------+ | destination endpoint id (octets 5-8) | +---------+---------+---------+---------+ | flags | protocol| data length | +---------+---------+---------+---------+ Since TUNE decouples the one-to-one relationship between network attachment points and transport endpoints, the specific destination EID must be available in the network or transport message so that messages for the destination system may recognized and processed. Source EIDs may also be desired in transport messages for logging, accounting, or authorization purposes. As part of the TUBA discussions, it has been suggested that these EIDs might be embedded in network addresses via various mappings. This restricts the choice of network addresses (to those conforming to the mapping algorithm), and such mapping may not be available over other network services. Another consequence of embedding EIDs into network addresses is that the resulting transport identifiers used by applications become dependent on network addressing structures and thus subject to change with network changes. TUNE maintains independence from network layer addresses by prepending TCP and UDP messages with the revised pseudo-header during delivery. This revised header (referred to as the "TUNE header") precedes the TCP or UDP data in a TUNE datagram and contains the protocol field needed for demultiplexing at the destination TUNE system. This is a significant departure from current IP Curran Expires April, 1993 [Page 7] Internet Draft TUNE Overview October 1992 architecture, and will result in larger network layer datagrams in most cases. While the addition of 24 octets to the average Internet datagram is considered heresy by many, the header will result in a minimal performance impact when used with large datagram sizes. The impact on low-speed circuits would be much greater, but may be alleviated through the use of header compression techniques in a manner similar to IP [8]. 3.0 TUNE Administration By introducing organizational endpoint identifiers, TUNE creates basic infrastructure for several administrative features which have been previously viewed as network-layer services. In particular, EID identification of transport messages can simplify the deployment of autoconfiguration, portability, and mobility for end-systems. 3.1 Autoconfiguration In order for a TUNE system to properly interact with other TUNE systems, it must: o Have an operational network service o Know its own EID o Have access to the EID resolution service Autoconfiguration of network layer services has been sucessfully deployed for IP [9, 10], and is under development for CLNP services. As TUNE operates on top of network services, it does not interfere with the operation of any network-layer mechanisms. TUNE does provide an additional key which autoconfiguration techniques could use to gain hardware independence. Rather than utilizing an IEEE identifier from one of its network interfaces as a key for system information, (such as name and bootfile selection) it becomes possible to index such information by the EID, and have systems store (in a non-volatile memory) their EID. Changing either the network level address or the hardware address (such as board swap) would not affect the boot process. In some environments, it may be useful to store a secret key in addition to the EID for use via ticket granting service authorizing use of the EID. TUNE operation will require either non-volatile storage of the EID resolution service configuration or use of the autoconfiguration process to obtain such information. BOOTP is already capable of Curran Expires April, 1993 [Page 8] Internet Draft TUNE Overview October 1992 returning the necessary DNS information, but any additional information (such as network service preference) will have to be added as BOOTP extension or stored locally. 3.2 Portability Portability, loosely defined as the ability to carry a system somewhere and have it operate at the destination, has been considered a desirable characteristic of the Internet's next architecture. This is particularly true if portability is going to be used to maintain topologically-assigned network addresses. Since EIDs are not dependent upon any particular physical network, TUNE systems which are moved to a new network attachment point only need to update the EID-to-network-address mapping in order to achieve portability. This works regardless of the cause of the address change (physical move, provider change, etc.) Such address changes are completely transparent to applications under TUNE, since applications use EIDs. Due to the use of DNS services for EID->address mapping, TUNE cannot provide "instant" portability during its initial deployment. This stems from the inability to perform distributed updates to the DNS database from remote systems. Organizations will enjoy portability for all of their TUNE systems, but will have to manually update the EID mapping when systems are moved. The addition of dynamic update facilities could be done via DNS extensions for dynamic database update, or could be done as a separate facility which interacts directly with the master nameserver as needed. The advantage of a separate facility is the ability to readily add site-defined validation for such updates, whereas a DNS- based solution can readily be found during autoconfiguration and would not require specific autoconfiguration support as a result. Additional work is needed before making a determination for this topic. 3.3 Mobility Mobility, defined here as the ability to operate a system continuously while changing network location, has been expressed by many as a desirable characteristic of the next Internet architecture. Several mobile technologies including wireless LAN's, microwave personal communications services, and digital celluar services will become generally available over the next few years and could make significant demands upon our routing architecture if pressed to Curran Expires April, 1993 [Page 9] Internet Draft TUNE Overview October 1992 provide mobility to systems. In the TUNE model, mobility is provided at the transport layer. The TUNE header allows direction of transport messages without affecting the endpoint identifiers. Given two systems, EID XXX with network address NX1, and EID YYY with network address NY1, it is possible for XXX to move to a new network address (NX2) while communicating over CLNP as follows: XXX YYY --- --- Disconects from NX1/ connects to NX2 Sends dynamic update to EID map (identical to portability case) Cached mapping for XXX incorrect/ messages timeout. Cached ES info expires at last IS router based on holding timer. (holding timer presumably low for mobile host) Cached mapping for XXX incorrect/ messages report Host Unreachable. Failure causes reacquisition of EID -> address mapping. Mapping returns new information/ Messages to XXX/NX2 succeed. For TCP connections, the reaction time to network address changes can be minimized by using a "refresh EID" flag in the TUNE header. When a system changes its network address, this flag should be set in the next datagram to each outstanding TCP connection. Appendix A: EID Allocation and Format TUNE Endpoint Identifiers are 64 bits in length, and may be represented in the familiar "dotted-decimal" notation used for IP addresses. The EIDs are allocated by the Internet Assigned Numbers Authority and its delegated authorities in accordance with the recommendations of the IETF. Curran Expires April, 1993 [Page 10] Internet Draft TUNE Overview October 1992 The IANA should allocate EIDs in contiguous blocks of EIDs to subordinate allocation authorities as necessary to insure an adequate supply of EIDs for TUNE-using organizations. It is recommended that the IANA make use of multiple channels for distribution of EIDs including network service providers, professional organizations, standards organizations, and others as necessary. In order to insure an plentiful supply of EID authorities, the first two octets of the EID are reserved for an allocation authority prefix. This allows for 64K allocation authorities. It is foreseeable that the IANA might supply multiple authority prefixes to some authorities so that further delegation of authority may occur. An example of this would be if the IANA were to allocate sufficient prefixes to ISO so that each country could have a unique prefix. Allocation authorities may allocate EIDs in any of the following sized blocks: 2**8, 2**16, 2**24, 2**32, 2**40, and 2**48. Authorities are required to maintain records of blocks assigned and provide support infrastructure (such as top-level directory servers) to allow successful EID resolution process for each block assigned. The requirements for directory services are intended to discourage small allocations by authorities, and it is expected that typical EID block allocations will consist of 2**16 or 2**24 EIDs per organization. In order to provide interoperability between IPv4 and TUNE systems, it is necessary to "map" existing IP addresses into TUNE EIDs. It is recommended that the following EIDs be reserved for this purpose: 128.0.x.y.z.0.0.n where 128.0 Authority Prefix x.y.z IP address (high 3 octets) 0.0.n IP address (low octet) Although this method of allocation does not provide a straightforward translation for existing IP addresess, it will allow existing network (and subnet allocations) be useful as EID namespaces prior to the establishment of multiple EID allocation authorities. Appendix B: DNS Support for EID Resolution TUNE requires a distributed mapping function from a given EID to the appropriate network service and address used to reach it. This function will be provided through existing DNS services in order to Curran Expires April, 1993 [Page 11] Internet Draft TUNE Overview October 1992 insure timely deployment in the Internet. It is necessary to represent the EID information in the DNS namespace in a manner which supports delegation from the IANA to each assignment authority, and from each assignment authority to each organization. DNS has two restrictions upon how delegation may be performed: delegation may only occur on token boundaries (where tokens are delimited by periods in the name string), and information is organized with the rightmost tokens being most significant. Considering these requirements, the following approach is recommend for EID to network information mapping via DNS: The IANA will establish DNS service for a new domain: IN-EID.ARPA. For each authority prefix assignment, the IANA will delegate a subdomain of IN-EID.ARPA for management by the assignment authority. The subdomain may be determined by representing the authority prefix in dotted-decimal notation and inverting the order of tokens (as is done for the IN-ADDR domain currently) Example: Authority ABC is assigned prefix 0.47. A matching domain of 47.0.IN-EID.ARPA would be operated by or on behalf of the authority. For each organization prefix assigned, the authority will delegate a subdomain of their domain for management by the organization. The subdomain may be determined by representing the organization prefix in dotted-decimal notation and inverting the order of tokens (as above). The IANA will delegate subdomains for any organizations using EIDs based upon their IP network address allocation. Example: Organization XYZ is assigned prefix 0.47.255.238.0. A matching domain of 0.238.255.47.0.IN-EID.ARPA would be operated by or on behalf of organization XYZ. Organizations are responsibility for providing a pointer (PTR) record for each EID in use. The location for the PTR record may be determined by representing the EID in dotted-decimal notation and inverting the order of tokens (as above). The PTR record will contain the name of the network service used to reach the EID, a slash ("/") character, and a network address in a Curran Expires April, 1993 [Page 12] Internet Draft TUNE Overview October 1992 format specific to the network service. The valid names and address formats will be determined by the IANA. The use of PTR resource records requires that all address formats end with a period ("."). A network address may include a network layer protocol selector when available (e.g. NSEL in NSAP addresses) as TUNE only requires a single dispatch point and performs transport protocol demultiplexing internally based upon the TUNE header. TUNE hosts should only process address records for supported network protocols and should ignore all others received. The method for selecting which network service and address to use in the presence of multiple valid records is a local configuration issue, and not addressed here. It is conceivable that address selection might take local policy into consideration to provide limited source-specified routing. Examples: A system with EID of 128.0.192.52.71.0.0.4 reachable via CLNP might require a PTR record of the following form: 4.0.0.71.52.192.0.128.IN-EID.ARPA. PTR CLNS/47000580FFEE00000000001100AA00040084AF10. A system with EID of 0.47.255.238.0.0.1.178 reachable via PIP might require a PTR record of the following form: 178.1.0.0.238.255.47.0.IN-EID.ARPA PTR PIP/7.66000.77.18.2. 6.0 Security Considerations Security considerations are not discussed in this memo, but should be thoroughly explored before any future Internet architecture is selected. Curran Expires April, 1993 [Page 13] Internet Draft TUNE Overview October 1992 7.0 References [1] "Protocol for Providing the Connectionless-Mode Network Service", ISO 8473, 1988. [2] Callon, R., "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing", RFC1347, 1992 June. [3] Fuller, V.; Li, T.; Yu, J.; Varadhan, K, "Supernetting: an Address Assignment and Aggregation Strategy", RFC1338, 1992 June. [4] Collela, R.; Gardner, E.P.; Callon, R.W., "Guidelines for OSI NSAP allocation in the internet", RFC1237, 1991 July. [5] Plummer, D.C., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", RFC826, 1982 November. [6] Oran, David, Ed., "OSI IS-IS Intra-domain Routing Protocol", RFC1142, February 1990. [7] Mockapetris, P., "Domain names - Concepts and Facilities", RFC1034, November 1987. [8] Jacobson, V., "Compressing TCP/IP headers for low-speed serial links", RFC1144, 1990 February. [9] Croft, W.J.; Gilmore, J., "Bootstrap Protocol", RFC951, 1985 September. [10] Reynolds, J.K., "BOOTP vendor information extensions", RFC1084, 1988 December. 8.0 Author's Address: John Curran Bolt Beranek and Newman, Inc. 10 Moulton Street Cambridge, MA 02138 (617) 873-4398 jcurran@bbn.com Curran Expires April, 1993 [Page 14] From owner-big-internet@munnari.oz.au Thu Oct 8 09:11:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26304; Thu, 8 Oct 1992 09:12:03 +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 AA17552; Thu, 8 Oct 1992 02:23:07 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA23279; Wed, 7 Oct 1992 17:23:28 +0100 Message-Id: <199210071623.AA23279@mitsou.inria.fr> To: David R. Oran Cc: Juha Heinanen , big-internet@munnari.oz.au Subject: Re: Multiple addresses In-Reply-To: Your message of "Wed, 07 Oct 92 11:28:14 -0400." <921007112814.12546@sneezy.lkg.dec.com> Date: Wed, 07 Oct 92 17:23:11 -0500 From: Christian Huitema X-Mts: smtp >Gee, I hate to disagree with you Christian, but in ISIS a "relay" does >not have one single identification. The protocol goes to great lengths >to ensure that a relay is in fact represented by an equivalence class >of identifiers, and in fact has distributed agreement algorithms to >ensure that all the ISs know the equivalence class. I stand corrected. In fact, I was cautious to use "identification", which is a very general term -- one has to make sure that the beast is one single point in the graph. That identification is in fact materialized by the "equivalence class". That even those "relays" end up with multiple addresses is one more evidence that even in IS-IS NSAPs are *not* just used to identify "boxes", as Juha mentioned initially. Christian Huitema From owner-Big-Internet@munnari.oz.au Thu Oct 8 09:26:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26754; Thu, 8 Oct 1992 09:26:30 +1000 (from owner-Big-Internet) Return-Path: Received: from zephyr.isi.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26736; Thu, 8 Oct 1992 09:26:17 +1000 (from braden@ISI.EDU) Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Wed, 7 Oct 1992 16:26:03 -0700 Date: Wed, 7 Oct 1992 16:26:03 -0700 From: braden@ISI.EDU (Bob Braden) Message-Id: <199210072326.AA22649@zephyr.isi.edu> To: big-internet@munnari.oz.au Subject: Hop count inverted? This discussion of the size of the hop count field reminds me of an idea that came up some years ago, concering TTL: regarded as a hop count, TTL goes the wrong way. A host sets TTL in a packet to some number K larger than the diameter of the Internet, and routers count the TTL down and discard at zero. When the Internet grows, the value of K has to change in all hosts. Bad idea. Mabe better idea: the hosts initialize the field to zero, and the routers count UP, and discard the packet when it reaches K. The assumptions here are that (1) it's easier to change K in the routers than in the hosts as the Internet grows, and (2) the additional overhead in the router code of testing against K instead of zero is negligible. Bob Braden From owner-big-internet@munnari.oz.au Thu Oct 8 09:55:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27927; Thu, 8 Oct 1992 09:55:12 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210072355.27927@munnari.oz.au> Received: from PIZZA.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23700; Thu, 8 Oct 1992 07:32:50 +1000 (from craig@BBN.COM) To: Noel Chiappa Cc: pgross@ans.net, yakov@watson.ibm.com, big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: Re: IESG Deliberations on ROAD In-Reply-To: Your message of Mon, 05 Oct 92 19:35:36 -0400. <9210052335.AA16908@ginger.lcs.mit.edu> Date: Wed, 07 Oct 92 17:24:50 -0400 From: Craig Partridge > I'd prefer someone without any connection to any proposal, so that > we don't wind up 'sole-sourcing' the criteria. I don't know who would fit > this criteria; of the people who've been active on the mailing list, Craig > Partridge comes as close as anyone. Noel: My "non-biased" participation probably simply reflects my limiting understanding of some of the issues. (I'm quite serious -- I'm *not* a routing guru). Craig From owner-big-internet@munnari.oz.au Thu Oct 8 10:30:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29771; Thu, 8 Oct 1992 10:32:09 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210080032.29771@munnari.oz.au> Received: from PIZZA.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24671; Thu, 8 Oct 1992 08:10:48 +1000 (from craig@BBN.COM) To: Steve Deering Cc: big-internet@munnari.oz.au Subject: Why think about timestamps vs. hop counts In-Reply-To: Your message of Tue, 06 Oct 92 22:40:07 -0400. <9210062240.aa12237@SPARK.BRL.MIL> Date: Wed, 07 Oct 92 18:04:16 -0400 From: Craig Partridge Hi Steve: Here's why I'm interested in timestamps. The hop count field currently serves two purposes: * to bound the amount of looping (e.g. bound lifetime bouncing between routers) * to bound the life of the packet (in real time) to save the transport protocols from having to keep track of possibly horribly out of date datagrams. Expiration timestamps serve the second purpose very well, and the first purpose reasonably well. Hop counts do the first well, and the second not at all. So timestamps looked like a possible win. The various messages about isolated 3 node networks, and bootstrapping point up some interesting problems which lead me to be less sanguine about timestamps but that doesn't mean I think hop counts are great. (Yes Mars to the US is one hop, you hope... but as several folks pointed out, a few blocks can be dozens of hops -- so hops don't correlate with distance at all well). Craig From owner-big-internet@munnari.oz.au Thu Oct 8 11:08:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01441; Thu, 8 Oct 1992 11:08:11 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16887; Thu, 8 Oct 1992 01:57:59 +1000 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA04274; Wed, 7 Oct 92 08:48:43 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA12149; Wed, 7 Oct 1992 11:48:25 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: Splitting the network layer: take 2 In-Reply-To: <9210071430.AA25982@ginger.lcs.mit.edu> References: <9210071430.AA25982@ginger.lcs.mit.edu> Cc: big-internet@munnari.oz.au, deering@parc.xerox.com X-Mailer: Poste 2.0 From: David R. Oran Date: Wed, 7 Oct 92 11:48:16 -0400 Message-Id: <921007114816.12546@sneezy.lkg.dec.com> Encoding: 45 TEXT, 6 TEXT SIGNATURE Sheesh. I'm going to kick myself for opening my mouth here. In order argue for EIDs, you have to make a case that they do something neither addresses nor names do. If an EID is topologically sensitive, or sensitive to an administrative authority who decides where and whether you can connect to the network, then they provide no value over a big-enough address. If an EID is a long as a name, then you might was well use the name, unless the EID provides a property that the name does not, for example temporal+spacial uniqueness as opposed to the purely spacial uniqueness of names. In order for an EID to be useful in the current architecture, it has to be: a) decoupled from both the topology and the administration of the routing infrastructure b) a lot shorter than a name c) cheap to do equality tests on d) at least as stable as a name I think the bottom line is that unless EIDs bring some new architectural semantics that are deemed important (like temporal uniqueness), then one can argue about them strictly in terms of engineering tradeoffs and hints/performance optimizations over always using just a name or just an address. As an aside, I would like to argue that the undercurrent that you don't use EIDs for routing is not necessarily valid. The only problem with using EIDs for routing is that they aren't topologically significant and hence can't be thinned/refined/aggregated by the routing protocols. That doesn't mean that for localized routing, such as is done by ISIS level 1 (which treats the addresses as flat anyway) they can't be economically used as "addressing information". I would like to argue in favor of exactly the model that ISIS and TUBA have with respect to EIDs and addresses, namely, that the identifier is embedded in the address both logically and physically. This has two very desirable properties: 1) it uses a single mechanism to get spacial uniqueness, thus providing superior autoconfiguration behavior, and 2) it allows a single mechansim for endpoint identification and local-region routing. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Thu Oct 8 11:13:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01643; Thu, 8 Oct 1992 11:13:18 +1000 (from owner-Big-Internet) Return-Path: Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01625; Thu, 8 Oct 1992 11:13:06 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA10724; Wed, 7 Oct 92 21:13:39 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9210080113.AA10724@wizard.gsfc.nasa.gov> Subject: Re: Hop count inverted? To: braden@ISI.EDU (Bob Braden) Date: Wed, 7 Oct 92 21:13:38 EDT Cc: big-internet@munnari.oz.au In-Reply-To: <199210072326.AA22649@zephyr.isi.edu>; from "Bob Braden" at Oct 7, 92 4:26 pm X-Mailer: ELM [version 2.3 PL11] > This discussion of the size of the hop count field reminds me of an > idea that came up some years ago, concering TTL: regarded as a hop > count, TTL goes the wrong way. > > A host sets TTL in a packet to some number K larger than the diameter > of the Internet, and routers count the TTL down and discard at zero. > When the Internet grows, the value of K has to change in all hosts. > Bad idea. Mabe better idea: the hosts initialize the field to zero, > and the routers count UP, and discard the packet when it reaches K. > The assumptions here are that (1) it's easier to change K in the > routers than in the hosts as the Internet grows, and (2) the additional > overhead in the router code of testing against K instead of zero is > negligible. > > Bob Braden DECnet does this and the reason I don't like it is it can cause weird failure cases when different routers choose different values of K. I'd much prefer to have a uniform hop-count processing policy, i.e. decrement and check for 0. This keeps the control about how far to try and send the packet in the hands of the end-points, or even better yet in the hands of the first-hop router which has been suggested, which is where I think it should be. -Bill From owner-Big-Internet@munnari.oz.au Thu Oct 8 11:16:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01754; Thu, 8 Oct 1992 11:17:07 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210080117.1754@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01744; Thu, 8 Oct 1992 11:16:50 +1000 (from jcurran@nic.near.net) To: Phill Gross Cc: yakov@watson.ibm.com, big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: Re: IESG Deliberations on ROAD In-Reply-To: Your message of Mon, 05 Oct 92 16:55:51 -0500. <199210052055.AA20308@home.ans.net> Date: Wed, 07 Oct 92 21:16:28 -0400 From: John Curran -------- From: Phill Gross Subject: Re: IESG Deliberations on ROAD Date: Mon, 05 Oct 92 16:55:51 -0500 [From: yakov@watson.ibm.com] To smooth the process I would suggest to form an open IETF working group that will consider and evaluate the criteria. The procedures for this working group may be the same as for any other IETF working group. Can do. Can we illicit volunteers to chair the WG? John, would you be able to do it? In the meantime, I still think we should discuss them by email. Yakov and/or Craig are fine choices for chair. I was not trying to create an entire WG to study the criteria; my main concern is that we either decide to incorporate additional input (vendors, providers, and users) and actively solict such input, or that we proceed without the input but prepared for the worst. /John From owner-big-internet@munnari.oz.au Thu Oct 8 11:36:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02542; Thu, 8 Oct 1992 11:37:05 +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 AA17870; Thu, 8 Oct 1992 02:30:36 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA22084; Wed, 7 Oct 92 09:29:54 -0700 Received: by us1rmc.bb.dec.com; id AA10274; Wed, 7 Oct 92 12:27:20 -0400 Message-Id: <9210071627.AA10274@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Wed, 7 Oct 92 12:27:21 EDT Date: Wed, 7 Oct 92 12:27:21 EDT From: Ross Callon To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au Apparently-To: deering@parc.xerox.com, big-internet@munnari.oz.au Subject: one small correction re: EIDs Steve; One small correction: > - It has been suggested that topology-independent EIDs would > help in supporting mobile hosts. In particular, it has been > observed that a packet to a mobile host might need to carry two > destination identifiers -- a location and a host ID -- and the > EID could serve as the host ID. However, the encapsulation > approach for forwarding to mobile hosts (e.g., the Columbia scheme) > is another way put two destinations in a packet (in the inner and > outer IP headers), in which the destination serving as the host ID > (in the inner header) is a lot more useful than a flat EID, > because it can be used to identify a "home" location at which > the location of the mobile can be registered and looked up. > I think this is a much better approach than expecting the > directory service to maintain EID->location mappings for > zillions of roaming hosts, I have proposed that separating the EID from the location part of the address could be used to slightly optimize mobile host behavior. However, I am *NOT* proposing that the directory service be used to maintain up to date EID to location mappings. I agree with you that we do not want to use a mobile host scheme (or any other scheme) which assumes that you can get DNS to change anything on a global scale rapidly. Now, you might use DNS to map from EID to name, and/or from name to normal "home" address location, plus use a mobile host server than can map addresses in packets destined to the normal home locations to the current location. All of the details of this have not been worked out, and seem to change whenever folks look at the problem very hard (I have recently been thinking about what to do about mobile hosts which have temporarily moved to a location which does not have full Internet connectivity, and which therefore cannot access the DNS records associated with the mobile host's normal home location -- This seems to strain the notion of no DNS changes in reaction to a host moving, although the required changes had better be locallized). All of this only emphasizes your main point, which I think is a good one: Separating unique end point IDs from the rest of the address *might* be a good idea, but we haven't clearly and unambiguously proved this point. Ross From owner-big-internet@munnari.oz.au Thu Oct 8 11:59:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03341; Thu, 8 Oct 1992 11:59:37 +1000 (from owner-big-internet) Return-Path: Received: from regal.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18597; Thu, 8 Oct 1992 03:02:08 +1000 (from dkatz@cisco.com) Received: by regal.cisco.com; Wed, 7 Oct 92 10:01:26 -0700 Date: Wed, 7 Oct 92 10:01:26 -0700 From: Dave Katz Message-Id: <9210071701.AA10622@regal.cisco.com> To: jonson@server.af.mil Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au In-Reply-To: Matt Jonson's message of Wed, 7 Oct 92 9:38:37 CDT <9210071438.AA14620@server.af.mil> Subject: Hop Limit field in SIP The two implementations I'm familiar with used connectionless networking internally, setting up a reliable end-to-end connection between the entry and exit point of the X.25 call. This has the usual obvious advantages. One of the two used a TTL, the other did not (and hardly ever melted down). I've heard of concatenated virtual circuits being used, in which case the only loop detection that has to be done is at call setup time (but this suffers from the usual disadvantages). From: Matt Jonson Date: Wed, 7 Oct 92 9:38:37 CDT X-Mailer: ELM [version 2.3 PL11] > Subject: Re: Hop Limit field in SIP > > Maybe we should look for a routing architecture in which packets *cannot* > loop? Do X.25 networks have hop counts on packets? Do we have an X.25 > internals expert in the house? > Don't forget that X.25 just defines the interface to the data network, all the internals are entirely up to the vendors supplying the network. The way BBN did it is different from Codex etc. I believe some models are very virtual circuit oriented (i.e. all packets on a vc traverse the same path after flow set-up) and some are datagram oriented (BBN & MILNET/ARPANET). In all cases they are proprietary. Be that as it may, it would be interesting to see the mechanisms used. Just bear in mind that one way doesn't represent "the way that X.25 does it." /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 Thu Oct 8 12:34:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04510; Thu, 8 Oct 1992 12:34:12 +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 AA19216; Thu, 8 Oct 1992 03:44:05 +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 6784; Wed, 07 Oct 92 13:42:49 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 0613; Wed, 07 Oct 92 13:42:49 EDT Date: Wed, 07 Oct 92 13:25:01 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: TIME to die (was Re: Hop Limit field in SIP) To: Christian Huitema , "Dean D. Throop" Cc: big-internet@munnari.oz.au, kasten@ftp.com In-Reply-To: <199210070949.AA21990@mitsou.inria.fr> Message-Id: <921007.132501.EDT.VALDIS@vtvm1.cc.vt.edu> On Wed, 07 Oct 92 10:49:37 -0500 Christian Huitema said: >Indeed, the effect is dependant of the relative speeds, or rather the >relative acceleration. But anything that moves at large speeds (fractions of >speed of light) under curved trajectories cannot be time synchronized, full >point. This means that you cannot achieve high precision time synch between >earth and a satellite, although you can do some predictions due to orbit >periodicity. A spacecraft to the Moon, or to Mars, would have both a high >speed curved trajectory and no periodic orbit. NTP would simply not work >here without some very serious kludges. In real life, the speeds achieved by satellites are *NOT* sufficient to cause a problem. Also, as you noted, orbit periodicity helps filter and smooth all this. Note that the currently deployed GPS system relies *specifically* on synched clocks on satellites so that they can measure the propogation delay and thus compute your location. The commercially available GPS receivers have to deal with the fact that the 8 low-order bits of timestamp coming from the satellites are DES-encrypted on order of the US military, to "de-res" accuracy to 100 meters - the military receivers with the DES descramblers can get to within 2-3 meters. Remember that the relativistic drift has a factor of v**2 / c**2 in it, which for a satellite in orbit at 18,000 miles per hour is (5**2) / (186000 ** 2) or 7.22E-10 damped by the fact the direction is changing. If I had my copy of Tipler's "Gravity" handy, I'd look up what the gravitational well effect is on the clock - that will offset it to some degree... I'd worry more about systems like certain Sun boxes, that tend to drift timewise due to broken kernel instrumentation, thus losing timer interrupts. Also, with a E-10 involved, I think the crystal accuracy will be an overwhelming factor - not everybody has hardware that has a crystal oven on board... /Valdis From owner-big-internet@munnari.oz.au Thu Oct 8 13:03:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05424; Thu, 8 Oct 1992 13:03:51 +1000 (from owner-big-internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22237; Thu, 8 Oct 1992 06:16:54 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA20589 (5.65c/UK-2.1-921001); Wed, 7 Oct 1992 16:17:38 -0400 From: Gary Scott Malkin Date: Wed, 7 Oct 1992 16:17:38 -0400 Message-Id: <20589.199210072017@atlas.xylogics.com> To: VALDIS@vtvm1.cc.vt.edu Cc: jnc@ginger.lcs.mit.edu, craig@aland.bbn.com, big-internet@munnari.oz.au In-Reply-To: Valdis Kletnieks's message of Wed, 07 Oct 92 13:43:34 EDT <921007.134334.EDT.VALDIS@vtvm1.cc.vt.edu> Subject: Hop Limit field in SIP > If properly designed, a 'record route' would return with the *complete* > path taken *both* ways (to detect asymmetric routes - not doable easily > now), and the reason for turnaround (target host reached, net unreachable, > TTL exceeded, etc). It's incredibly easy. Don't use IP record route, because it's so limited in size. Simply create an ICMP Record Route message. Each time the packet passes through a router, the address of the interface over which the packet was received is added to the end of the packet (PACKET, not HEADER). On the return path, the same thing is done. There's never any need for the routers to look into the packet, simply add to the end; no shifts needed. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-big-internet@munnari.oz.au Thu Oct 8 13:32:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06481; Thu, 8 Oct 1992 13:32:56 +1000 (from owner-big-internet) Return-Path: Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02187; Thu, 8 Oct 1992 11:29:02 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA10742; Wed, 7 Oct 92 21:29:47 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9210080129.AA10742@wizard.gsfc.nasa.gov> Subject: Re: lack of checksum field in SIP header To: deering@parc.xerox.com (Steve Deering) Date: Wed, 7 Oct 92 21:29:47 EDT Cc: big-internet@munnari.oz.au In-Reply-To: <92Sep29.155517pdt.10779@skylark.parc.xerox.com>; from "Steve Deering" at Sep 29, 92 3:55 pm X-Mailer: ELM [version 2.3 PL11] A late opinion on a SIP header checksum: I think it's important to remember Murphy's Law as it applies to networking. Since we are designing for a Very Big Internet (VBI), it's quite probable that even very low probability events are bound to happen to someone sometime, and none of us will be able to predict how much of an impact these events will have on the VBI or parts of the VBI when they do occur. It therefore behooves us to take appropriate precautions such as a header checksum, especially since the cost is minimal. It's also important to me, in the course of network troubleshooting, to properly disambiguate different error cases, and the header checksum again plays an important role in this function. So I'm obviously strongly in favor of including a header checksum in SIP or any other IPv7 contender. -Bill From owner-big-internet@munnari.oz.au Thu Oct 8 13:37:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06719; Thu, 8 Oct 1992 13:37:31 +1000 (from owner-big-internet) Return-Path: Received: from x400gate.bnr.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23485; Thu, 8 Oct 1992 07:22:19 +1000 (from jcobban@bnr.ca) X400-Received: by mta bcars520 in /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 7 Oct 1992 17:18:51 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 7 Oct 1992 17:18:27 -0400 X400-Received: by /PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/; Relayed; Wed, 7 Oct 1992 13:18:00 -0400 Date: Wed, 7 Oct 1992 17:18:00 +0000 X400-Originator: /DD.ID=1582804/G=Jim/I=J/S=Cobban/@bnr.ca X400-Mts-Identifier: [/PRMD=BNR/ADMD=TELECOM.CANADA/C=CA/;bcars520.b.810:07.09.92.21.18.27] Original-Encoded-Information-Types: ia5, undefined X400-Content-Type: P2-1984 (2) Content-Identifier: Re: Multiple ... From: "Jim (J.) Cobban" Message-Id: <"20824 Wed Oct 7 17:18:37 1992"@bnr.ca> To: jnc@ginger.lcs.mit.edu Cc: "Richard (R.J.) Thomas" , "Dwight (D.) Jamieson" , "Ross (R.M.) MacGillivray" , "Gary (G.P.) Mussar" , "Michelle (M.D.) Landriault" , Juha.Heinanen@datanet.tele.fi, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: Multiple addresses It is essential that the evolution of the IP routing architecture must support a host having fewer addresses than interfaces. If someone wants to have one to one network layer address to physical interface, that is fine, but there are real world problems that arise if you insist that everyone must have a one to one relationship. For example: The bandwidths which are supported by most common carriers for X.25 access are limited either by the capabilities of the equipment, or by tariff or implementation policies. There are carriers who WILL NOT lease an X.25 access line that is faster than, say, 9600 b/s. It is, of course, not unusual for the traffic requirements of a host to exceed any arbitrary limit. In that case multiple X.25 lines are required. This does not cause any problem for the users of the X.25 network, since they see a hunt group which sits in front of the multiple access lines. From the point of view of every other host attached to the X.25 network there is only one link layer address for this destination. However from the point of view of the host itself there are multiple attachments, and each of those attachments must have a different IP address. This causes enormous complications. Therefore, if IP is to successfully compete with protocols like CLNS the IP routing architecture must evolve to permit a single IP address even though there are multiple physical attachments. From owner-big-internet@munnari.oz.au Thu Oct 8 14:15:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08072; Thu, 8 Oct 1992 14:15:41 +1000 (from owner-big-internet) Return-Path: Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26130; Thu, 8 Oct 1992 09:02:04 +1000 (from news@sgi.com) Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA20778; Wed, 7 Oct 92 15:47:31 -0700 To: Big-Internet@munnari.OZ.AU Reply-To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: Hop Limit field in SIP Message-Id: Date: Wed, 7 Oct 1992 22:18:41 GMT Valdis Kletnieks writes: > On Tue, 6 Oct 92 15:25:54 -0400 Noel Chiappa said: > >Bzzzrraack! Here we go again, driving screws with a hammer. Dammit, if we want > >a traceroute function, design an ICMP message to do it! I am *SOOOOO* sick of > >kludges! Sure, sometime you have to kludge to get something done, but then we > >turn around and make it a fundamental architectural principle, when all it was > >was a quick, disgusting, hack, kludge (like the IGP/EGP split). > > I'll *happily* accept an ICMP ECHO with the RECORD ROUTE option, if we > remove the restriction that only 5 (or whatever it is) addresses get > recorded. In fact, I'd *prefer* that to the current 'traceroute' scheme > of sending out packets with increasing TTLs and watching for TTL Expired > ICMP's coming back. Toss one packet, and be done. > > If properly designed, a 'record route' would return with the *complete* > path taken *both* ways (to detect asymmetric routes - not doable easily > now), and the reason for turnaround (target host reached, net unreachable, > TTL exceeded, etc). Traceroute and record-route serve different purposes. Traceroute gives information when `ping -R` is completely silent and useless. As noted, traceroute gives little information about the return path. It would be nice if traceroute used something a little less violent than ordinary UDP packets to ordinary ports at the target. If the port just happens to be in use on the target, not only will traceroute not get the desired port unreachable answer, but some unsuspecting UDP application will get an extra packet. It shouldn't be too hard on many operating systems to fake TCP packets, and snoop for the TCP reset caused by a guaranteed mismatch among source and destination port and host numbers. Vernon Schryver, vjs@sgi.com From owner-big-internet@munnari.oz.au Thu Oct 8 17:20:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14633; Thu, 8 Oct 1992 17:20:14 +1000 (from owner-big-internet) Return-Path: Received: from dg-rtp.rtp.dg.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17384; Thu, 8 Oct 1992 02:16:03 +1000 (from throop@dg-rtp.dg.com) Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4.1/dg-rtp-proto) id AA09750; Wed, 7 Oct 1992 12:15:43 -0400 Received: by walrus (5.4.1/140.2) id AA06382; Wed, 7 Oct 1992 12:13:14 -0400 Date: Wed, 7 Oct 1992 12:13:14 -0400 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9210071613.AA06382@walrus> To: Christian.Huitema@sophia.inria.fr Subject: Re: TIME to die (was Re: Hop Limit field in SIP) Cc: big-internet@munnari.oz.au > To: throop@dg-rtp.dg.com (Dean D. Throop) > Subject: Re: TIME to die (was Re: Hop Limit field in SIP) > From: Christian Huitema > Message-Id: <199210070949.AA21990@mitsou.inria.fr> > > >Requires NTP in all routers. I actually don't see this as a very > >big negative because it isn't that expensive and coordinated time > >would be very nice to have. > > Just one tiny side effect. You can only achieve time synchronization between > two objects if they are not mobile, or more precisely if their relative > speed is constant. So said Einstein. > > Indeed, the effect is dependant of the relative speeds, or rather the > relative acceleration. But anything that moves at large speeds (fractions of > speed of light) under curved trajectories cannot be time synchronized, full > point. This means that you cannot achieve high precision time synch between > earth and a satellite, although you can do some predictions due to orbit > periodicity. A spacecraft to the Moon, or to Mars, would have both a high > speed curved trajectory and no periodic orbit. NTP would simply not work > here without some very serious kludges. > > For this reason, I vote AGAINST requiring time synch at the IP level. > > Christian Huitema My initial reaction would be to make the expiration times large enough that a little relativistic time lag wouldn't matter. However I can believe eventually this won't be acceptable. The next step would be to introduce a hippity/hop distinction. When the router on the Earth forwarded the packet to Mars, it would convert the expiration time from an absolute UTC time to a relative time. If the expiration time was say now + 0.25 seconds, the relative time would be 0.25 seconds. The router on Mars would convert the relative time back to a Mars absolute time; for example now + 0.25 seconds. The routers would know that time wasn't synchronized between the two domains and would adjust the packet expiration time. Most routers aren't required to modify the packet, however nothing prevents routers from doing so if needed. For this situation each router must know when its peer has a different time domain. Since different time domains will probably always require sophisticated signal transmission equipment, I don't see this as an unnecessary requirement compared with that they already must do. Since you have pointed out that times can't be synchronized between some hosts, what does this do to the security people? They are relying on time synchronization to protect against replay attacks. If the time on Mars can't be synchronized with Earth, how can anyone on Mars send a secure request to Earth? The time skew might make the packet unacceptable when it really should be ok. For this case having a packet arrive with an absolute time adjusted by the routers might help. The expiration time of the packet as adjusted by the routers could give the receiver an idea how large a clock skewed to accept. Of course this requires the routers to be part of the TCB but if the hosts rely on the time kept by the routers, they already are. Dean Throop throop@dg-rtp.dg.com From owner-big-internet@munnari.oz.au Thu Oct 8 17:50:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15837; Thu, 8 Oct 1992 17:50:48 +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 AA20424; Thu, 8 Oct 1992 04:40:56 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA28247; Wed, 7 Oct 92 14:39:26 -0400 Date: Wed, 7 Oct 92 14:39:26 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9210071839.AA28247@er.doe.gov> To: big-internet@munnari.oz.au Subject: Random thoughts Cc: q@oerv01.er.doe.gov There are several threads going on here recently: EID's vs addresses Hop counts, timestamps, loop detection... "routing architecture" "other things a new internet protocol should do" On EID's there are several issues. However, one of the important advantages they have is that they isolate users from changes in addressing/routing which makes it easier to change addressing plans in the future when its needed. Think how much easier our current task would be if we could change the way we use addresses without needing to change anyone's IP numberf that they love. This does assume that the binding of EID to "address" is done without too much human intervention. If you decide to have EID's then there is a further basic choice to be made... assign them from a flat space or a hierarchical one designed on some basis. The advantage to a flat space is dense assignment of ID's requiring fewer bits. The disadvantage is that searches to link ID to something else are not efficient. Also, from an organizational point of view the ID's for a given organizational entity would tend to not be contiguous which complicates a lot of simple aggregation techniques. Based on this it seems to me that some sort of hierarchical EID assignment scheme would be preferable. Now the poor site manager has to manage DNS entries, EID assignment, and perhaps address assignment. It might be useful to consider whether this administrative constraind suggests the use of some other hierarchically assigned number as EID even though it would now have NO ADDRESSING SIGNIFICANCE. IP and CLNP NSAP might be two candidates... At least then the site manager doesn't have to manage anything new. Routing Architectures... Two things may be missing from this discussion. First, the internet of the future will have significant commercial providers offering variousservices. Inn this context the concept of "suboptimal route" may not be well defined. A carrier who has extra bandwidth available on a path may not care whether it has 3 extra hops or 1500 extra miles in it. The user only cares if the path doesn't meet the expected service requirements in terms of delay, thruput etc. In addition, the carriers historically have been VERY UN- WILLING to allow visibility into their internal routing architecture. They may even be unwilling to let you know how many hops they have across their net. The user only cares how many hops when things don't work. Users will care which carrier transports their bits and will probably want to specify levels of service required. "Hops, time stamps, and loop detection" The fundamental issue is detectin and suppression of routing loops in the internet of the future different carriers and underlying technologies may evolve in radically different ways in this regard... perhaps the packet header only needs a loop_detected flag and all of the other choices need to be left to the individual network. I should point out that using hop count or time stamp for loop detection is like driving from Washington to New York and noting that once you have gone 3000 miles if you haven't arrived you're probably lost. "other things it would be nice to have" Improvements in policy based routing, security, accounting control... would all be nice to have in any new architecture. However, in the operational internet we face the challenge of beginning within 24-30 months a transition to a new netwwork protocol because of a combinatin of routing table growth and address space depletion. Therefore, our challenge is to come up with a deployable technology which at least maintains current services, can interoperate with the old technology, and doesn't make the network unuseable by the non guru users and or sites. I suggest that adding a lot of difficult issues which we also don't know how to handle very well to this brew does not improve our chances. Given these uncertainties; however, one thing which all the proposals probably should address is how easy they are to incrementally change and update after implementation so that new features can be added later. Dan Hitchcock From owner-Big-Internet@munnari.oz.au Thu Oct 8 18:13:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16689; Thu, 8 Oct 1992 18:14:01 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210080814.16689@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16686; Thu, 8 Oct 1992 18:13:53 +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, 8 Oct 1992 09:13:21 +0100 To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Cc: Big-Internet@munnari.OZ.AU Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of "Wed, 07 Oct 92 22:18:41 GMT." Date: Thu, 08 Oct 92 09:13:18 +0100 From: Jon Crowcroft >> >a traceroute function, design an ICMP message to do it! I am *SOOOOO* sick of >It would be nice if traceroute used something a little less violent >than ordinary UDP packets to ordinary ports at the target. If the port traceroute is useful PRECISELY becuase its packets look like ordinary packets - the number of times NICs and NOCs claim the net is fine coz their tools test the net with ~special~ packets that get prefential treatment while the plain old network innocents (poni) can't get a regular packet thru...is too many... jon From owner-big-internet@munnari.oz.au Thu Oct 8 18:16:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16779; Thu, 8 Oct 1992 18:16:22 +1000 (from owner-big-internet) Return-Path: Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00985; Thu, 8 Oct 1992 10:56:19 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA10690; Wed, 7 Oct 92 20:55:29 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9210080055.AA10690@wizard.gsfc.nasa.gov> Subject: Re: Per-Interface vs. Per-"Network Entity" addresses To: oran@sneezy.lkg.dec.com (David R. Oran) Date: Wed, 7 Oct 92 20:55:29 EDT Cc: deering@parc.xerox.com, Juha.Heinanen@datanet.tele.fi, big-internet@munnari.oz.au In-Reply-To: <921007103456.12546@sneezy.lkg.dec.com>; from "David R. Oran" at Oct 7, 92 10:34 am X-Mailer: ELM [version 2.3 PL11] > Sorry, Steve, I don't follow this argument. You don't need per-interface > addresses to diagnose an interface. There are two cases: > > a) you can ping the box successfully > b) you can't ping the box successfully > > If (b) you can't talk to *any* of the boxes intrerfaces, so the point > is moot. If the box has multiple addresses you try all of them > until you find one that works. Then you go on to case (a). > > Once you can talk to the box, you send SNMP requests to ask > about the state and counters of each of the interfaces. You look > at the numbers and diagnose which interfaces are working and which > are not. This will give you a clue about intermittent failures which > a simple ping will not. We see this all the time with flakey Ethernet > interfaces that drop 20% of the packets sent to them due to > buffer overruns and the like. As a practical matter, I don't see SNMP as a replacement for other tools such as ping, but rather as only one of many tools in a network troubleshooting toolbox. The most obvious reason I can think of why SNMP wouldn't be generally useful for this function is that there's a very good chance you don't know the community name for the entity you want to check on. ping and traceroute don't suffer from this restriction. I also strongly agree with an earlier comment that there's no substitute for actually sending a packet through the pipe to test out whether or not it's working properly, quite possibly in conjunction with SNMP to check on packet and error counters. > If this information is not available through SNMP, then I'd claim there's > a big hole in either SNMP or the MIB. I suspect there's no hole here > since working/not working is so fundamental to any useful network > management diagnosis system. > > Further, the idea of per-interface addresses breaks down in certain > network interconnect schemes. Do you want separate IP addresses > on each MAC of a dual-MAC FDDI? I'm not sure there's any > way to "force a packet to be delivered to a particular interface" > in this case anyway. You have to map the ring ad the datalink > layer to get useful information about what's broken and where. > Not being able to ping a particular station's particular MAC is > probably misleading for fault diagnosis. In the case of an FDDI concentrator, the address does map more naturally to the box rather than to a specific interface. However, just because an interface to address mapping doesn't make sense in this case doesn't mean it doesn't make sense in a lot of other common situations. We need the flexibility to handle either case. Also, if an address can't have an association with an interface, and if I have a host with both Ethernet and FDDI interfaces, how can I for example force NFS mounts to use the FDDI interface for performance reasons if that's what I desire? > Dave. > > P.S. This is not meant to necessarily take sides on whether interfaces > ought to have addresses or not. It was simply meant to argue that > diagnosis was not a good reason. And I think diagnosis should be a strong consideration in this debate, although not necessarily the predominant consideration. -Bill From owner-Big-Internet@munnari.oz.au Thu Oct 8 21:51:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24241; Thu, 8 Oct 1992 21:51:13 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210081151.24241@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24227; Thu, 8 Oct 1992 21:51:04 +1000 (from jcurran@nic.near.net) To: "David R. Oran" Cc: Noel Chiappa , big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Splitting the network layer: take 2 In-Reply-To: Your message of Wed, 07 Oct 92 11:48:16 -0400. <921007114816.12546@sneezy.lkg.dec.com> Date: Thu, 08 Oct 92 07:50:50 -0400 From: John Curran -------- From: "David R. Oran" Subject: Re: Splitting the network layer: take 2 Date: Wed, 7 Oct 92 11:48:16 -0400 Sheesh. I'm going to kick myself for opening my mouth here. In order argue for EIDs, you have to make a case that they do something neither addresses nor names do. Agreed, but EIDs are simply names in a useable form. The question is whether EIDs provide something that _current_ names cannot do. ... In order for an EID to be useful in the current architecture, it has to be: a) decoupled from both the topology and the administration of the routing infrastructure b) a lot shorter than a name c) cheap to do equality tests on d) at least as stable as a name I think the bottom line is that unless EIDs bring some new architectural semantics that are deemed important (like temporal uniqueness), then one can argue about them strictly in terms of engineering tradeoffs and hints/performance optimizations over always using just a name or just an address. Hmm. The idea of imbedded (for example) DNS names in packets as EIDs is not encouraging. These names are variable length (up to 63 characters) and any packet using them for both source and destination EIDs has just picked up a lot of overhead (definiton: "more than CLNP" :-) Hence, the TUNE work specified a much shorter, fixed-length EID more suitable for inclusion in datagrams. I would like to argue in favor of exactly the model that ISIS and TUBA have with respect to EIDs and addresses, namely, that the identifier is embedded in the address both logically and physically. This has two very desirable properties: 1) it uses a single mechanism to get spacial uniqueness, thus providing superior autoconfiguration behavior, and I am very interested in the "superior autoconfiguration behavoir"; can you elaborate? /John From owner-Big-Internet@munnari.oz.au Thu Oct 8 22:33:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25550; Thu, 8 Oct 1992 22:33:15 +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 AA25547; Thu, 8 Oct 1992 22:33:06 +1000 (from milan@mjm.xyplex.com) Received: from mjm.xyplex.com by xap.xyplex.com id ; Thu, 8 Oct 92 08:31:12 -0500 Received: by mjm.xyplex.com (4.1/SMI-4.1) id AA01733; Thu, 8 Oct 92 08:34:01 EDT Date: Thu, 8 Oct 92 08:34:01 EDT From: milan@mjm.xyplex.com (Milan Merhar) Message-Id: <9210081234.AA01733@mjm.xyplex.com> To: big-internet@munnari.oz.au Subject: Using NTP time value instead of a Hop Limit field in SIP A very, very dumb question.... If the network layer needs to put an expiration date into each message it sends, and it needs to have the current time to do this, how does it get the current time in the first place? Running NTP assumes that the node can send and receive messages. Does it guess at a reasonable time value in its first message, or does it need some kind of non-volatile clock to maintain a rough "real time" count even through power-cycles? (This is not to say I'm against this scheme - as a way of controlling resource usage it's much cleaner (IMHO) than an arbitrary decrement of a field. I'm just looking to see if its stable at the boundary conditions.) From owner-Big-Internet@munnari.oz.au Thu Oct 8 23:18:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27165; Thu, 8 Oct 1992 23:18:23 +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 AA27162; Thu, 8 Oct 1992 23:18:12 +1000 (from kasten@ftp.com) Received: by ftp.com id AA24503; Thu, 8 Oct 92 09:17:55 -0400 Date: Thu, 8 Oct 92 09:17:55 -0400 Message-Id: <9210081317.AA24503@ftp.com> To: deering@parc.xerox.com Subject: Re: EIDs From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au > > - EIDs could be used in the computation of TCP & UDP pseudo-header > checksums, so that the addresses may be changed on the fly (e.g., > from one interface's address to another, for a multihomed host) > without breaking connections or sessions. That would be nice, > but it's not the only way to do it. As an off-the-wall suggestion, > why not include the hosts' fully-qualified domain names, instead > of their addresses, in the checksum, since they already serve as what if i do not have the domain name? suppose that i ping 10.0.0.51? i might be trying to debug some network problem and not be able to do the in-addr.arpa lookup on the ip address. i might also have my own /etc/hosts file, giving my own name-address mappings and never deal with the fqdn. there is also the possibility of "which" domain name? there can be two entries in the dns for a particular host. each one is is as fully-qualified as the other. > topology-independent host identifiers? The names would not have > to be carried in the packets themselves, just included in the > checksum computation, and the sum over the pair of names could be > precomputed, so it would be as efficient as using the addresses. > As a more serious suggestion, we really should be either > encrypting or crypto-signing all of our transport PDUs, in which > case, we could stop including IP addresses in the pseudo-header > checksums because misdelivery would be prevented by decryption > failure (only the legitimate peers would hold the right key). I do not like the idea of introducing crypto-goop in the network layer as a REQUIRED element. First of all, there are export problems for the US. More importantly, crypto-goop is not always needed or even desired. Imagine some dynamic host config. How does the host learn the keys to process the packets which are telling that host who it is? I suppose that some human could type the stuff in -- but now we are getting away from humanless config -- which is what DHC is all about. Now, about EIDs specifically. I think that the idea has a lot of potential. This is a bit of an emotional argument. I think that a year or three after some network layer protocol that has EIDs is introduced som bright graduate student will look at them and say "Wow, we can do this...." One use of them would be in doing multi-casting. In effect, an EID identifies a logical entity with which I want to communicate. That entity could be on any physical machine, or perhaps many. Granted, there is a lot of directory and routing-technology work to be done to map a single EID onto many topological points of the network. Another possibility is to develop mobile processes (not mobile hosts). A process could be assigned EID 72 and then it could seek out lightly loaded machines on a network to run on. As it moved from machine to machine it would simply re-register itself with the EID-to-topology mapper. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Thu Oct 8 23:42:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27828; Thu, 8 Oct 1992 23:42:46 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27820; Thu, 8 Oct 1992 23:42:39 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA03370 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Thu, 8 Oct 1992 09:42:07 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Thu, 8 Oct 1992 09:42:07 -0400 Message-Id: <199210081340.AA17361@home.ans.net> To: John Curran Cc: big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: Re: IESG Deliberations on ROAD In-Reply-To: (Your message of Wed, 07 Oct 92 21:16:28 D.) <199210080116.AA48988@interlock.ans.net> Date: Thu, 08 Oct 92 09:40:39 -0500 From: Phill Gross ....I was not trying to create an entire WG to study the criteria; my main concern is that we either decid to incorporate additional input (vendors, providers, and users) and activel solict such input, John, The basic message is that we certainly do want input from vendors, providers, and users to be factored into the criteria. I too am not convinced we need to wait for the creation of a WG to begin discussing the criteria and incorporating their input. Please, everyone who has comments on the criteria, start your engines! Phill From owner-Big-Internet@munnari.oz.au Thu Oct 8 23:50:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28063; Thu, 8 Oct 1992 23:50: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 AA28055; Thu, 8 Oct 1992 23:50:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05463; Thu, 8 Oct 92 09:49:53 -0400 Date: Thu, 8 Oct 92 09:49:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210081349.AA05463@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: EIDs Cc: jnc@ginger.lcs.mit.edu To me it was clear that an EID identified the same sort of "end point defined by continuity". ... Does that misrepresent anyone's view of it? No, that's approximately my definition. My technical definition of *what* an EID *names* (i.e. an "endpoint") is an end-end/fate-sharing entity; i.e. an entity which can participate in an end-end transaction (such as a reliable stream), and/or an entity around which one would draw a fate-sharing boundary (so that all the critical state for a transaction is there, and "they all go together if they go"; i.e. crash). This decision on *what* to name is motivated by computer sciencey type thinking; you should name the fundamental things in your computational universe. Now, as for exactly what the *form* of the name of the entity *named* by the EID looks like, that's more of an engineering decision. I've always assumed a 'shortish' fixed length unique number, normally stored in packets as a fixed length binary string. It has these characteristics for ease of computing with (i.e. moving, comparing, etc), since I think it will go in nearly all packets, and the uniqueness means it's all you need to name an endpoint. Also, I think it should have no syntax/semantics that is directly useful to the network; it's just the unique name of an endpoint. I absolutely do not want it to have topological significance! I have no objection to placing some loose (i.e. you shouldn't depend on it to mean anything) syntax on the EID which allows allocating it in a way which is organizationally easy, such as the way IEEE numbers are allocated. So, in fact, there might be organizational heirarchy in the EID's, but it's not important or useful. Why not do more with it? The more things you do with one mechanism, the more likely you are to screw it up, or not do one of the things quite right, etc. Let's *just* uniquely and efficiently name endpoints with the EID, OK? But for all normal purposes an EID identifies a host. Yes, that would be the normal use with the kind of machines we have today. The main argument for EIDs that I remember went like this: Well, my main argument for having EID's (actually, having names for endpoints, technically; the form of the name is a different question) is not a practical one at all. (How unpractical of me, right? :-) It's the one I alluded to above; I think we ought to have namespaces for the fundamental object classes in our computational environment, and the endpoint sure looks like one to me. Now, the form of the name, well, that's more up for grabs. I think there are good reasons for making it 'shortish' (efficiency), fixed length (ease of processing; any variable length thing has to be parsed in real time), and unique (much, much more useful). The binary string (implied by shortish; this minimizes the length) is actually more of a *representation* question, in the same way that internet address A.B.C.D (written) is the same thing really as the 32 bit version thereof. Having the EID as part of the address is not unreasonable Bong! Tilt! No! The address names a *place* in the network; the EID names a producer/consumer of packets. These are fundamentally different things! Don't get me wrong, I imagine they will usually be passed around in a tuple of (address, EID), but that is not the same as making the EID *part* of the address. (I am ignoring there the trick where the "address" names a name-binding region in the network, and that allows the EID to be *locally* mapped into the complete, full, address; i.e. the way ARP works now.) Perhaps we are just have a problem with loose terminology, but the EID and the address name different things, and in a deep sense one *can't* be "part of" the other, any more than when I give my mailing address as: "J. Noel Chiappa, mumble, mumble, U.S.A" my name is 'part of' the address. My name and the address of my house are different things, even though the mail system needs the tuple. Noel From owner-Big-Internet@munnari.oz.au Fri Oct 9 00:24:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29620; Fri, 9 Oct 1992 00:24: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 AA29604; Fri, 9 Oct 1992 00:24:22 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA29807; Thu, 8 Oct 92 07:24:15 -0700 Received: by us1rmc.bb.dec.com; id AA07722; Thu, 8 Oct 92 10:21:40 -0400 Message-Id: <9210081421.AA07722@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Thu, 8 Oct 92 10:21:42 EDT Date: Thu, 8 Oct 92 10:21:42 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 08-Oct-1992 1024" To: jcobban@bnr.ca Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, jcobban@bnr.ca Subject: RE: Re: Multiple addresses Yes, it should be possible to address a logical host independent of particular physical interfaces but at some level some piece of hardware/software has to map that into the address of a physical interface. This might be, as in an X.25 hunt group, done outside of "IP". But for management purposes, each physical interface should also have it's own address. Even in telephone company hunt groups, it is normal to give each separate line it's own telephone number. (Of course in modern systems the phone company can also run tests at the telephone switch using "physical" line designations that have no relationship to phone numbers.) Donald -------------- From: US1RMC::"jcobban@bnr.ca" "Jim (J.) Cobban" 8-OCT-1992 01:21 To: jnc@ginger.lcs.mit.edu Subj: Re: Multiple addresses It is essential that the evolution of the IP routing architecture must support a host having fewer addresses than interfaces. If someone wants to have one to one network layer address to physical interface, that is fine, but there are real world problems that arise if you insist that everyone must have a one to one relationship. For example: The bandwidths which are supported by most common carriers for X.25 access are limited either by the capabilities of the equipment, or by tariff or implementation policies. There are carriers who WILL NOT lease an X.25 access line that is faster than, say, 9600 b/s. It is, of course, not unusual for the traffic requirements of a host to exceed any arbitrary limit. In that case multiple X.25 lines are required. This does not cause any problem for the users of the X.25 network, since they see a hunt group which sits in front of the multiple access lines. From the point of view of every other host attached to the X.25 network there is only one link layer address for this destination. However from the point of view of the host itself there are multiple attachments, and each of those attachments must have a different IP address. This causes enormous complications. From owner-Big-Internet@munnari.oz.au Fri Oct 9 00:33:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29810; Fri, 9 Oct 1992 00:33:57 +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 AA29805; Fri, 9 Oct 1992 00:33:33 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA00349; Thu, 8 Oct 92 07:33:21 -0700 Received: by us1rmc.bb.dec.com; id AA08012; Thu, 8 Oct 92 10:30:47 -0400 Message-Id: <9210081430.AA08012@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Thu, 8 Oct 92 10:30:48 EDT Date: Thu, 8 Oct 92 10:30:48 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 08-Oct-1992 1033" To: jcurran@nic.near.net Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, jcurran@nic.near.net Subject: RE: Re: Splitting the network layer: take 2 From: US1RMC::"jcurran@nic.near.net" "John Curran" 8-OCT-1992 08:59 To: "David R. Oran" Subj: Re: Splitting the network layer: take 2 -------- From: "David R. Oran" Date: Wed, 7 Oct 92 11:48:16 -0400 ... In order for an EID to be useful in the current architecture, it has to be: a) decoupled from both the topology and the administration of the routing infrastructure b) a lot shorter than a name c) cheap to do equality tests on d) at least as stable as a name Hmm. The idea of imbedded (for example) DNS names in packets as EIDs is not encouraging. These names are variable length (up to 63 characters) and any ^^ ===Nope. Each component is limited to 63 characters but the limit for an ===entire fully qualified domain name is 255 characters. Of course only ===65 different characters are allowed and it's case insensitive so you ===could further compact it, but it's still a LOT of bits. packet using them for both source and destination EIDs has just picked up a lot of overhead (definiton: "more than CLNP" :-) Hence, the TUNE work specified a much shorter, fixed-length EID more suitable for inclusion in datagrams. /John From owner-Big-Internet@munnari.oz.au Fri Oct 9 01:21:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01619; Fri, 9 Oct 1992 01:22:00 +1000 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01612; Fri, 9 Oct 1992 01:21:45 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA19807; Thu, 8 Oct 92 08:21:32 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA08411; Thu, 8 Oct 92 11:21:20 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA27556; Thu, 8 Oct 92 11:19:30 EDT Date: Thu, 8 Oct 92 11:19:30 EDT From: Frank T Solensky Message-Id: <9210081519.AA27556@fenway.andr.UB.com> To: VALDIS@vtvm1.cc.vt.edu, gmalkin@xylogics.com Subject: Record Route (was Re: Hop Limit field in SIP) Cc: big-internet@munnari.oz.au >From: Gary Scott Malkin >Date: Wed, 7 Oct 1992 16:17:38 -0400 >In-Reply-To: Valdis Kletnieks's message of Wed, 07 Oct 92 13:43:34 EDT <921007.134334.EDT.VALDIS@vtvm1.cc.vt.edu> > >> If properly designed, a 'record route' would return with the *complete* >> path taken *both* ways (to detect asymmetric routes - not doable easily >> now), and the reason for turnaround (target host reached, net unreachable, >> TTL exceeded, etc). > >It's incredibly easy. .. Simply create an ICMP Record Route message. Each >time the packet passes through a router, the address of the interface over >which the packet was received is added to the end of the packet (PACKET, >not HEADER). I hate to come off as a curmudgeon, but whenever I see/hear "incredibly easy" or "simply" these days, a red flag goes up in my head... What happens when you hit a local MTU? SIP doesn't include fragmentation, so some information may be lost. If this packet comes out onto a larger MTU media, then there are (undetectable?) gaps in the information. Trying this out in IPv4 would give you only the route that the last fragment took (though it probably won't differ significantly than any other). And when you say "add to end": I've already lost track -- does SIP include a packet length field? The first hop router might "add to end" by placing this information past the end of the filler space rather than the header. -- Frank From owner-Big-Internet@munnari.oz.au Fri Oct 9 01:31:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01911; Fri, 9 Oct 1992 01:31:20 +1000 (from owner-Big-Internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01904; Fri, 9 Oct 1992 01:31:07 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA21277 (5.65c/UK-2.1-921001); Thu, 8 Oct 1992 11:31:52 -0400 From: Gary Scott Malkin Date: Thu, 8 Oct 1992 11:31:52 -0400 Message-Id: <21277.199210081531@atlas.xylogics.com> To: solensky@andr.ub.com Cc: VALDIS@vtvm1.cc.vt.edu, big-internet@munnari.oz.au In-Reply-To: Frank T Solensky's message of Thu, 8 Oct 92 11:19:30 EDT <9210081519.AA27556@fenway.andr.UB.com> Subject: Record Route (was Re: Hop Limit field in SIP) Frank, The ICMP Record Route wasn't meant specifically for SIP. It would be useful now. > What happens when you hit a local MTU? SIP doesn't include fragmentation, > so some information may be lost. If this packet comes out onto a larger MTU > media, then there are (undetectable?) gaps in the information. Trying this > out in IPv4 would give you only the route that the last fragment took (though > it probably won't differ significantly than any other). Consider a path which was 30 hops long (which is pretty large by todays standards). That means you'd have to record 60 addresses at 4 bytes per address (so far :-) which comes to 240 bytes plus headers. The total is still under 300 bytes. Are there so many media with a smaller MTU that this is a problem? ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Fri Oct 9 01:35:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02064; Fri, 9 Oct 1992 01:36:03 +1000 (from owner-Big-Internet) Return-Path: Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02056; Fri, 9 Oct 1992 01:35:25 +1000 (from vjs@rhyolite.wpd.sgi.com) Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (920330.SGI/910110.SGI) for Big-Internet@munnari.OZ.AU id AA21156; Thu, 8 Oct 92 08:33:48 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:J.Crowcroft@cs.ucl.ac.uk id AA22888; Thu, 8 Oct 92 09:33:43 -0600 Date: Thu, 8 Oct 92 09:33:43 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9210081533.AA22888@rhyolite.wpd.sgi.com> To: Jon Crowcroft Subject: Re: Hop Limit field in SIP Cc: Big-Internet@munnari.OZ.AU > From: Jon Crowcroft > > >> >a traceroute function, design an ICMP message to do it! I am *SOOOOO* sick of > >It would be nice if traceroute used something a little less violent > >than ordinary UDP packets to ordinary ports at the target. If the port > > traceroute is useful PRECISELY becuase its packets look like ordinary > packets - the number of times NICs and NOCs claim the net is fine coz > their tools test the net with ~special~ packets that get prefential > treatment while the plain old network innocents (poni) can't get a > regular packet thru...is too many... Agreed. What I've long talked about (all talk and no action) is to open sockets on the local machine to allocate port numbers free of any MSL collision with existing traffic, and print up fake TCP/IP packets to loft toward the target. These TCP/IP packets would be more ordindary than the UDP/IP packets now used by traceroute, and they could not cause any grief at the target. The difficulty that I see with using TCP instead of UCP traceroute probes is in the systems I know about, it's more difficult for a user process to get the resulting TCP reset from the target than it is to get the ICMP port unreachable. On Suns you could use "nit". On 4.4BSD (I think) you could use the new Stanford packet filtering stuff. On my employers' machines, you could use a "snoop socket". It is not as portable. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.oz.au Fri Oct 9 01:54:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02726; Fri, 9 Oct 1992 01:55:36 +1000 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02669; Fri, 9 Oct 1992 01:54:36 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA20708; Thu, 8 Oct 92 08:54:19 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA08457; Thu, 8 Oct 92 11:54:18 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA27589; Thu, 8 Oct 92 11:52:28 EDT Date: Thu, 8 Oct 92 11:52:28 EDT From: Frank T Solensky Message-Id: <9210081552.AA27589@fenway.andr.UB.com> To: gmalkin@xylogics.com Subject: Re: Record Route (was Re: Hop Limit field in SIP) Cc: VALDIS@vtvm1.cc.vt.edu, big-internet@munnari.oz.au >Consider a path which was 30 hops long (which is pretty large by >todays standards). That means you'd have to record 60 addresses >at 4 bytes per address (so far :-) which comes to 240 bytes plus >headers. The total is still under 300 bytes. Are there so many >media with a smaller MTU that this is a problem? But you're using 8 byte addresses in SIP. A thirty-hop path then takes up 480 bytes in the packet, excluding SIP and whatever other headers. That's getting too close to 512 bytes to have that warm & fuzzy that it'll be highly dependable for much longer. And is thirty hops all _that_ long? A good portion of the discussion on SIP recently suggested that 255 wasn't large enough. -- Frank From owner-big-internet@munnari.oz.au Fri Oct 9 02:04:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03037; Fri, 9 Oct 1992 02:04:27 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210081604.3037@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24774; Thu, 8 Oct 1992 22:10:02 +1000 (from jcurran@nic.near.net) To: Ross Callon Cc: deering@parc.xerox.com, big-internet@munnari.oz.au Subject: Re: one small correction re: EIDs In-Reply-To: Your message of Wed, 07 Oct 92 12:27:21 -0400. <9210071627.AA10274@us1rmc.bb.dec.com> Date: Thu, 08 Oct 92 08:09:48 -0400 From: John Curran -------- From: Ross Callon Subject: one small correction re: EIDs Date: Wed, 7 Oct 92 12:27:21 EDT I am *NOT* proposing that the directory service be used to maintain up to date EID to location mappings. I agree with you that we do not want to use a mobile host scheme (or any other scheme) which assumes that you can get DNS to change anything on a global scale rapidly. Using DNS for EID->address mapping is not sufficient for rapid mobility, and a "mobility server" is definitly more useful. If we're considering 10 address changes/minute, DNS certainly will not serve. If we're talking 2 changes/hour, there is no reason why DNS cannot keep up. Nothing in TUNE prevents the use of mobility servers in the architecture, but the only widely available directory service is DNS. Any improvements that can behind behind the DNS interface can be done at any time, whether this means a more appropriate directory service or a facility based on world-wide multicast... /John From owner-big-internet@munnari.oz.au Fri Oct 9 02:33:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03938; Fri, 9 Oct 1992 02:33:33 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210081633.3938@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26007; Thu, 8 Oct 1992 22:45:27 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1066; Thu, 08 Oct 92 08:45:22 EDT Date: Thu, 8 Oct 92 08:45:22 EDT From: yakov@watson.ibm.com To: deering@parc.xerox.com, big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: EIDs Ref: Your note of Wed, 7 Oct 1992 00:21:23 PDT >It has been suggested that topology-independent EID would help >in supporting mobile hosts... >However, the encapsulation approach is another way to put two >destinations in a packet, in which the destination serving as the >host ID is a lot more useful than a flat ID. Steve, I fully agree with your comments. Just to add, there are three proposals on the table about supporting mobility with IP. At least two of then (Columbia and IBM) work *perfectly* fine without requiring topology-independent EIDs. I suspect that the third proposal (from Sony) shares this property as well. All that brings us to the basic question about topology-independent EIDs: do we have a problem that needs to be solved, or do we have a solution (called "topology-independent EIDs") looking for a problem ? Yakov Rekhter From owner-Big-Internet@munnari.oz.au Fri Oct 9 02:55:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04623; Fri, 9 Oct 1992 02:56:45 +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 AA04593; Fri, 9 Oct 1992 02:55:32 +1000 (from jdemarco@ftp.com) Received: by ftp.com id AA02920; Thu, 8 Oct 92 12:55:02 -0400 Date: Thu, 8 Oct 92 12:55:02 -0400 From: jdemarco@ftp.com (Jim DeMarco) Message-Id: <9210081655.AA02920@ftp.com> To: gmalkin@xylogics.com Cc: solensky@andr.ub.com, VALDIS@vtvm1.cc.vt.edu, big-internet@munnari.oz.au In-Reply-To: Gary Scott Malkin's message of Thu, 8 Oct 1992 11:31:52 -0400 <21277.199210081531@atlas.xylogics.com> Subject: Record Route (was Re: Hop Limit field in SIP) Reply-To: jdemarco@ftp.com >Consider a path which was 30 hops long (which is pretty large by >todays standards). That means you'd have to record 60 addresses >at 4 bytes per address (so far :-) which comes to 240 bytes plus >headers. The total is still under 300 bytes. Are there so many >media with a smaller MTU that this is a problem? Hmmmm. Your example, though reasonable, isn't really pathological (nor is it likely to be a problem). Right now, a maximum hopcount of 255 can record 510 addresses (2040 bytes for IP, 4080 for SIP). Allowing a TTL/hopcount larger than 8 bits means even nastier worst cases. Since one can argue that traceroute is most useful for these situations (that is, for those times you want to find out why you're running into such long delays), it might be worth ensuring that whatever mechanism you plan to use for route tracing will still work with the [possibly] new, larger TTLs. Let's plan ahead. Is a large TTL/hopcount likely to scale well with route tracing mechanisms we're currently using? My guess is no. --Jim From owner-big-internet@munnari.oz.au Fri Oct 9 03:14:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04878; Fri, 9 Oct 1992 03:14:14 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210081714.4878@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26718; Thu, 8 Oct 1992 23:04:28 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1576; Thu, 08 Oct 92 09:04:24 EDT Date: Thu, 8 Oct 92 09:04:24 EDT From: yakov@watson.ibm.com To: oran@sneezy.lkg.dec.com, Christian.Huitema@sophia.inria.fr Cc: Juha.Heinanen@datanet.tele.fi, big-internet@munnari.oz.au Subject: Multiple addresses Ref: Your note of Wed, 7 Oct 92 11:28:14 -0400 From Juha Heinanen: "Look at how NSAPs are used in IS-IS and IDRP. They identify boxes, not interfaces..." From Christian Huitema: "They don't..." Dave Oran covered IS-IS. So, let me cover IDRP. In IDRP NSAPs *certainly* identify boxes. However, in certain cases you may want to have granularity finer than a box. In IDRP this happen when you want to specify a particular interface of the box (router) to be used as the next hop. So, the NEXT_HOP attribute carries NSAP, but also allow to specify SNPA(s) of the next hop. That is the *only* case in IDRP where granularity is finer than a box. Reachability information has a box (NSAP) as its granularity (but may be aggregated into NSAP prefixes). Yakov From owner-big-internet@munnari.oz.au Fri Oct 9 03:53:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05642; Fri, 9 Oct 1992 03:53:29 +1000 (from owner-big-internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27706; Thu, 8 Oct 1992 23:38:29 +1000 (from @yonge.csri.toronto.edu:mark@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <5108>; Thu, 8 Oct 1992 09:38:05 -0400 Received: from dino.alias.com by porter.alias.com with SMTP id AA21149 (5.65a/IDA-1.4.2 for big-internet@munnari.oz.au); Thu, 8 Oct 92 09:12:21 -0400 Received: by dino.alias.com id AA07814 (5.65a/IDA-1.4.2 for jnc@ginger.lcs.mit.edu); Thu, 8 Oct 92 09:12:13 -0400 Date: Thu, 8 Oct 1992 09:12:13 -0400 From: mandrews@alias.com (Mark Andrews) Message-Id: <9210081312.AA07814@dino.alias.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: Addresses Cc: big-internet@munnari.oz.au > i can have a host that at the same time belongs to many routing domains > (and thus has many addresses) and it can have only one, eg. Ethernet > interface through which all packets arrive. > >So? It has one interface, which has many addresses. What's the problem? Since when can one interface have multiple addresses? Doesn't every interface have a have a unique address (for every (sub)network it belongs to) which uniquely identifies it to another host. In the system I work with which is 4.3BSD-derived, every interface must have a unique IP address. If that host wishes to act as a gateway, it must have multiple interfaces, each of which has a uniqe IP address. Mark From owner-Big-Internet@munnari.oz.au Fri Oct 9 04:00:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05764; Fri, 9 Oct 1992 04:01:23 +1000 (from owner-Big-Internet) Return-Path: Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05743; Fri, 9 Oct 1992 04:00:46 +1000 (from news@sgi.com) Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA05250; Thu, 8 Oct 92 10:47:32 -0700 To: Big-Internet@munnari.OZ.AU Reply-To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: Hop Limit field in SIP Message-Id: Date: Thu, 8 Oct 1992 17:44:54 GMT > From: Jon Crowcroft > > >> >a traceroute function, design an ICMP message to do it! I am *SOOOOO* sick of > >It would be nice if traceroute used something a little less violent > >than ordinary UDP packets to ordinary ports at the target. If the port > > traceroute is useful PRECISELY becuase its packets look like ordinary > packets - the number of times NICs and NOCs claim the net is fine coz > their tools test the net with ~special~ packets that get prefential > treatment while the plain old network innocents (poni) can't get a > regular packet thru...is too many... Agreed. What I've long talked about (all talk and no action) is to open sockets on the local machine to allocate port numbers free of any MSL collision with existing traffic, and print up fake TCP/IP packets to loft toward the target. These TCP/IP packets would be more ordindary than the UDP/IP packets now used by traceroute, and they could not cause any grief at the target. The difficulty that I see with using TCP instead of UCP traceroute probes is in the systems I know about, it's more difficult for a user process to get the resulting TCP reset from the target than it is to get the ICMP port unreachable. On Suns you could use "nit". On 4.4BSD (I think) you could use the new Stanford packet filtering stuff. On my employers' machines, you could use a "snoop socket". It is not as portable. Vernon Schryver, vjs@sgi.com From owner-big-internet@munnari.oz.au Fri Oct 9 04:44:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06566; Fri, 9 Oct 1992 04:44:27 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210081844.6566@munnari.oz.au> Received: from PIZZA.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29729; Fri, 9 Oct 1992 00:27:49 +1000 (from craig@BBN.COM) To: Milan Merhar Cc: big-internet@munnari.oz.au Subject: Using NTP time value instead of a Hop Limit field in SIP Date: Thu, 08 Oct 92 10:17:41 -0400 From: Craig Partridge > If the network layer needs to put an expiration date into > each message it sends, and it needs to have the current time to > do this, how does it get the current time in the first place? Milan: Not a dumb question at all. On a LAN it should be easy -- if you have a timeserver multicasting the time, then just listen briefly till you hear a time message, then set your clock to that value. The value will be imperfect, but given that we're looking at tolerances of 10s of ms, it will be accurate enough. What happens on a power hit to your site is an interesting question -- start up probably takes a while. For WANs, I'm less sure. I believe it is feasible, but requires more work. Craig From owner-big-internet@munnari.oz.au Fri Oct 9 05:01:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06891; Fri, 9 Oct 1992 05:01:41 +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 AA03293; Fri, 9 Oct 1992 02:15:34 +1000 (from kre) To: Big-Internet@munnari.oz.au Subject: Tracing paths Date: Fri, 09 Oct 92 02:15:18 +1000 Message-Id: <11186.718560918@munnari.oz.au> From: Robert Elz In the hop count discussions it has been suggested that either SNMP or a new kind of ICMP record route might be used as an alternative to traceroute (should traceroute not work any more as it currently does, or just to implement a "cleaner" way). Neither of these will work - SNMP is fine as far as it goes, but what you are doing there is asking a router to tell you how it would route a packet with a certain destination address, which you would hope would be the same as the way it actually would route it, but if what you're doing is debugging a problem, isn't necessarily what you want to assume - ideally what you want to do is compare what the router tells you it will do (using SNMP) with what you discover it is really doing using traceroute. Similarly, some kind of ICMP echo-and-record-route won't work either, as that requires that the final home of the packet (either the destination, or the point at which routing fails) be able to route the answer back to you - which may be the very problem that you're trying to find, simply getting no answer doesn't help at all. Its also not nearly as easy to do as has been suggested (though not impossible) as in general when a packet is sent to some remote destination the routers don't look at what kind of packet it is, so wouldn't see that this one is this special "record route wanted" icmp type - doing that would require them to look at the payload type of every packet passing through, and if its ICMP, to then look at the code to see if it happens to be this magic one. That or process this thing by setting the destination address to the next router in the path, and have the router know that when it receives this packet it has to figure out the next router address and send it there. Neither of these schemes will replace traceroute. To work out what might, we need to investigate just what traceroute does that makes it so useful and successful. Not the mechanism it uses to achieve that (TTL exceeded) but what it actually does. I think the answer here, is that traceroute elicits a response from each router along the path to the destination, as the packet is forwarded. That the packet in question isn't actually forwarded, but is dropped instead is the accident, and brilliance, of the implementation, rather than the idea. So, would it be useful if we just created an option (a "router" option for those protocols that will separate them) that causes an ICMP "trace" message to be returned to the originator of a packet each time the packet passes through a router. Recipient hosts could either do the same, or traceroute could work just by sending an ICMP echo and then watching for the echo response indicating the packet had arrived. kre From owner-Big-Internet@munnari.oz.au Fri Oct 9 06:24:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08220; Fri, 9 Oct 1992 06:25:01 +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 AA08211; Fri, 9 Oct 1992 06:24:42 +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 0740; Thu, 08 Oct 92 16:23:41 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 4568; Thu, 08 Oct 92 16:23:41 EDT Date: Thu, 08 Oct 92 16:15:57 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Hop Limit field in SIP To: Noel Chiappa , big-internet@munnari.oz.au In-Reply-To: <9210082005.AA10725@ginger.lcs.mit.edu> Message-Id: <921008.161557.EDT.VALDIS@vtvm1.cc.vt.edu> (Gaak - replying to my own messages. I think I need a TTL field on my brain ;) On Thu, 8 Oct 92 16:05:17 -0400 I said: > Toss one packet, and be done. If properly designed, a 'record route > would return with the *complete* path taken *both* ways ... and the > reason for turnaround On further thinking, this is a *really* nice and useful idea, and one that I think we need to architect in without undue ad-hackery. It also seems reasonably easy to deal with, modulo long paths creating reply mobygrams and one other problem. One problem that nobody's mentioned yet is that this is difficult to implement in a router that has an Ethernet interface, because the packets are inherently "fire-and-forget". The router trying to forward the packet records a "sucess" if it puts the bits ONTO the wire, not if the other end pulls them off. With most point-to-point media, it seems to work nicely, and you can't put bits out without the other end reading them (usually the other end will drop DTR or similar, causing you to flag YOUR end as "down"). I pondered using an 'ack' system on such media, but that has problems in that if the ACK is lost, then the router will return a failure-gram while the destination host is also returning a sucess... Anybody got any ideas? /Valdis From owner-Big-Internet@munnari.oz.au Fri Oct 9 08:05:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10095; Fri, 9 Oct 1992 08:06:55 +1000 (from owner-Big-Internet) Return-Path: Received: from cca.camb.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10028; Fri, 9 Oct 1992 08:05:04 +1000 (from padwad@atgs330.gs.com) Received: from gs.com by camb.com (PMDF #2344 ) id <01GPPR33AYVK934XBZ@camb.com>; Thu, 8 Oct 1992 18:03:55 EDT Received: from atgs330.gs.com (atgs330) by gs.com (PMDF #2348 ) id <01GPPR0VEKHS95N319@gs.com>; Thu, 8 Oct 1992 18:01:35 EDT Received: from fsdsparc6.gs.com by atgs330.gs.com (4.1/SMI-4.1) id AA24148; Thu, 8 Oct 92 17:59:55 EDT Received: by fsdsparc6.gs.com (4.1/SMI-4.1) id AA00872; Thu, 8 Oct 92 18:01:21 EDT Date: 08 Oct 1992 17:59:55 -0400 (EDT) From: padwad@atgs330.gs.com (Danny Padwa) Subject: Oops... To: big-internet@munnari.oz.au Message-Id: <9210082159.AA24148@atgs330.gs.com> Content-Transfer-Encoding: 7BIT Sorry 'bout that last mail....I mean to cancel the message. While I'm already talking, though... I've been a little surprised by the timeout vs hopcount discussion. I think it might be worth noting that we many people are referring to as the "hop count" field in IPv4 was really a timestamp, I believe. I don't have copies of the relevant specs handy, but memory tells me that the TTL field was designed to eliminate "old" packets, in the chronological sense of old (although I'm sure many people on the list know more of the original intent than I). Remember the old ARPAnet, where delay (in seconds) and hopcount (at least for IP) could sometimes be comparable numbers. Even now, a router that holds a packet for > 1 second is required to decrement the TTL to reflect that. Bottom line....we have been well served by a combination hop-count/delay field in the header. Modern routers don't have so much latency or congestion (in the normal case), but if we are worrying about inter-continental (or inter-planetary), perhaps if routers knew the latency of their links, we could cause certain links to "cost" >1 on TTL. Thus a hopcount (nice and wide 16-bits :-)), with many links costing >1 hops. I think this kind of reflects reality...resources consumed on relatively empty Ethernets around campus are much cheaper than those to the moon! Danny Padwa padwad@atgs330.gs.com From owner-Big-Internet@munnari.oz.au Fri Oct 9 08:19:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10346; Fri, 9 Oct 1992 08:20:17 +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 AA10331; Fri, 9 Oct 1992 08:19:54 +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 AA17639; Thu, 8 Oct 92 15:19:45 PDT Received: from bigriver.Eng.Sun.COM (bigriver-248) by Eng.Sun.COM (4.1/SMI-4.1) id AA15640; Thu, 8 Oct 92 15:19:49 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA29817; Thu, 8 Oct 92 15:15:17 PDT Date: Thu, 8 Oct 92 15:15:17 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9210082215.AA29817@bigriver.Eng.Sun.COM> To: Big-Internet@munnari.OZ.AU Cc: Bob.Hinden@Eng.Sun.COM In-Reply-To: <9210081533.AA22888@rhyolite.wpd.sgi.com> Subject: Re: Hop Limit field in SIP Folks, After reading all (well, many) of the messages on TTL in SIP my conclusion is that the 8-bit hop counter as originally specified is still fine. IMHO the only strong argument made against it was that someday we might have an internet which requires datagrams to traverse 1,000 hops. It seems to me that if our internet protocol has a 255 hop limit, we will engineer the internet topology to work around this limit. Even ignoring that major parts of the future internet may be only one IP hop (via SMDS, FR, ATM, etc), this does not seem like a burden assuming that there are always economies of scale when purchasing bandwidth. Also, in my opinion the philosophy behind SIP was to make it as simple as possible. I think it is unwise to try to make it deal with every possibility we can imagine, but which are unlikely to occur in practice. There is already another well known protocol which was designed for the general case. Bob From owner-big-internet@munnari.oz.au Fri Oct 9 09:30:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11781; Fri, 9 Oct 1992 09:30:55 +1000 (from owner-big-internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05034; Fri, 9 Oct 1992 03:21:44 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA00961 (5.65c/UK-2.1-921001); Thu, 8 Oct 1992 13:22:33 -0400 From: Gary Scott Malkin Date: Thu, 8 Oct 1992 13:22:33 -0400 Message-Id: <961.199210081722@atlas.xylogics.com> To: dab@berserkly.cray.com Cc: big-internet@munnari.oz.au In-Reply-To: David A. Borman's message of Thu, 8 Oct 1992 12:03:06 -0500 <9210081703.AA01026@handel.cray.com.cray.com> Subject: Hop Limit field in SIP OK. So we need a traceroute that doesn't grow the packet. We have that now, except that it takes 2n packets to trace the route. Suppose we create a type of packet (or just a packet option) which requires each router to send an ICMP back to the source indicating that the packet had passed through. The original packet would have a large TTL to insure it could get through (providing there is indeed a path). This method only generates n+1 packets and achieves the same result as the current traceroute (only faster). It also works regardless of the diameter of the Internet (providing that diameter is less than the max hop count). ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-big-internet@munnari.oz.au Fri Oct 9 11:53:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15197; Fri, 9 Oct 1992 11:53:06 +1000 (from owner-big-internet) Return-Path: Received: from timbuk.cray.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04706; Fri, 9 Oct 1992 03:04:36 +1000 (from dab@berserkly.cray.com) Received: from handel.cray.com.cray.com by cray.com (4.1/CRI-MX 2.2) id AA05350; Thu, 8 Oct 92 12:04:15 CDT Received: by handel.cray.com.cray.com id AA01026; 5.65/CRI-5.5; Thu, 8 Oct 1992 12:03:06 -0500 Date: Thu, 8 Oct 1992 12:03:06 -0500 From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9210081703.AA01026@handel.cray.com.cray.com> To: gmalkin@xylogics.com Subject: Re: Hop Limit field in SIP Cc: big-internet@munnari.oz.au, VALDIS@vtvm1.cc.vt.edu But what happens when the packet grows to a size where it has to be fragmented? With 64 bit SIP addresses, and going out and back, 32 hops will overflow 500 bytes. If you put in a 4 byte timestamp with each address, it only takes 21 hops to overflow the minimum 500 byte SIP length. These are not uncommon hop counts in the internet today. The issues can be solved, but it would have to be thought through. One random thought: Add an ICMP level fragmentation for ICMP Record Route. Add a MORE-FRAGMENTS flag and a Fragment-Order field, just like in IP today. When an ICMP-RR packet arrives, if the MORE-FRAGMENTS bit is set, just forward it without doing anything to the packet. If an ICMP-RR packet arrives without the MORE-FRAGMENTS bit, then you tack on your address and send it on its way. If there isn't enough room to add your info, then you duplicate the packet. The first one has the MORE-FRAGMENTS bit set and sent on its way. The second one has the Fragment-Order bit set, the list of addresses is cleared, the new address/timestamp information is added and the packet is sent on its way. And it would have to be an ICMP ECHO-RECORD-ROUTE and ICMP ECHO-REPLY-RECORD-ROUTE message so that it gets turned around properly. The destination swaps addresses, changes the type to ECHO-REPLY-RECORD-ROUTE, and adds its own address just as already stated, and sends it on its way back. -David Borman, dab@cray.com > From owner-big-internet@munnari.oz.au Thu Oct 8 01:11:51 1992 > From: Gary Scott Malkin > Date: Wed, 7 Oct 1992 16:17:38 -0400 > To: VALDIS@vtvm1.cc.vt.edu > Cc: jnc@ginger.lcs.mit.edu, craig@aland.bbn.com, big-internet@munnari.oz.au > Subject: Hop Limit field in SIP > > > If properly designed, a 'record route' would return with the *complete* > > path taken *both* ways (to detect asymmetric routes - not doable easily > > now), and the reason for turnaround (target host reached, net unreachable, > > TTL exceeded, etc). > > It's incredibly easy. Don't use IP record route, because it's so limited > in size. Simply create an ICMP Record Route message. Each time the packet > passes through a router, the address of the interface over which the packet > was received is added to the end of the packet (PACKET, not HEADER). On > the return path, the same thing is done. There's never any need for the > routers to look into the packet, simply add to the end; no shifts needed. > > ---------------------------------------------------------------------- > Gary Malkin Humankind asks: "Why are we here?" > (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-big-internet@munnari.oz.au Fri Oct 9 13:12:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17303; Fri, 9 Oct 1992 13:12:04 +1000 (from owner-big-internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06126; Fri, 9 Oct 1992 04:23:19 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA17654 (5.65c/UK-2.1-921001); Thu, 8 Oct 1992 14:24:15 -0400 From: Gary Scott Malkin Date: Thu, 8 Oct 1992 14:24:15 -0400 Message-Id: <17654.199210081824@atlas.xylogics.com> To: Big-Internet@munnari.oz.au Subject: time warps I don't know about everyone else, but I find it strangely disconcerting when I get people's responses to my messages before I get my own messages echoed back. How does that happen? ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-big-internet@munnari.oz.au Fri Oct 9 13:36:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18191; Fri, 9 Oct 1992 13:36:19 +1000 (from owner-big-internet) Return-Path: Received: from INFONET1.INFONET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05889; Fri, 9 Oct 1992 04:08:42 +1000 (from abe@infonet.com) Received: by infonet.com (4.1/SMI-4.1) id AA12301; Thu, 8 Oct 92 11:10:36 PDT Date: Thu, 8 Oct 92 11:10:36 PDT From: abe@infonet.com (George Abe) Message-Id: <9210081810.AA12301@infonet.com> To: jonson@server.af.mil, katz@cisco.com Subject: Hop Limit field in SIP Cc: big-internet@munnari.oz.au >> Subject: Re: Hop Limit field in SIP >> >> Maybe we should look for a routing architecture in which packets *cannot* >> loop? Do X.25 networks have hop counts on packets? Do we have an X.25 >> internals expert in the house? >> >Don't forget that X.25 just defines the interface to the data network, >all the internals are entirely up to the vendors supplying the network. >The way BBN did it is different from Codex etc. I believe some models >are very virtual circuit oriented (i.e. all packets on a vc traverse >the same path after flow set-up) and some are datagram oriented (BBN & >MILNET/ARPANET). In all cases they are proprietary. Be that as it >may, it would be interesting to see the mechanisms used. >/matt All that Matt said is true. Here is a mechanism. At Infonet we chose to be vc oriented. This has the advantage that during flow setup, we create what amounts to a source route. That is, we identify a sequence of transit nodes through which all packets will traverse during the duration of the session. If there is damage to the vc (line dies, switch dies) we reroute dynamically. Next hop information is distributed at call setup throughout the length of the vc. That is, each participating transit node has a little data structure that says, "for this vc, relay to that exit interface". One can visualize it as having PIP FTIFs spread out through the participating vc nodes rather than in the packet. The route is setup according to a least cost algorithm models time delay, not hops. A hop count (of 16) is used to limit the length of the source route and to kill packets which may be looping owing to reroutes. >The two implementations I'm familiar with used connectionless networking >internally, setting up a reliable end-to-end connection between the entry >and exit point of the X.25 call. This has the usual obvious advantages. >One of the two used a TTL, the other did not (and hardly ever melted down). Makes sense. We operate in 38 countries on 5 continents and it is VERY unusual for our hop count to reach 10. 16 bit hop count fields seems a bit much. George Abe Infonet Services Corp El Segundo, California 90245 310-335-2867 From owner-big-internet@munnari.oz.au Fri Oct 9 13:42:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18415; Fri, 9 Oct 1992 13:42:59 +1000 (from owner-big-internet) Return-Path: Received: from SGI.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05536; Fri, 9 Oct 1992 03:47:04 +1000 (from news@sgi.com) Received: by sgi.sgi.com (920330.SGI/910110.SGI) id AA04837; Thu, 8 Oct 92 10:43:37 -0700 To: Big-Internet@munnari.OZ.AU Reply-To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) X-Approved: newsmail@sgi.sgi.com From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: Per-Interface vs. Per-"Network Entity" addresses Message-Id: Date: Thu, 8 Oct 1992 17:35:33 GMT > ... > > Further, the idea of per-interface addresses breaks down in certain > > network interconnect schemes. Do you want separate IP addresses > > on each MAC of a dual-MAC FDDI? I'm not sure there's any > > way to "force a packet to be delivered to a particular interface" > > in this case anyway. You have to map the ring ad the datalink > > layer to get useful information about what's broken and where. > > Not being able to ping a particular station's particular MAC is > > probably misleading for fault diagnosis. > > In the case of an FDDI concentrator, the address does map more naturally > to the box rather than to a specific interface. However, just because > an interface to address mapping doesn't make sense in this case doesn't > mean it doesn't make sense in a lot of other common situations. We need > the flexibility to handle either case. There may be two or more FDDI ideas confounded there. The FDDI ring map should be entirely separate from any IP addressing issues. Current FDDI ring mappers do not involve IP. There are a lot of commercial FDDI ring mapping products. There is more than enough FDDI SMT and SNMP "problem domain isolation" and fault diagnosis stuff. An extra MAC here or there is not a concern. The FDDI fault diagnosis is done independently on each dual-ring. A host with multiple FDDI interfaces (each of which may be single or dual-MAC) must do SMT, CMT, PC-trace, and all of the rest independently on each dual ring. Some FDDI concentrators have more than one MAC, but I suspect they use only one of their MAC's for their little IP traffic (e.g. SNMP). At least one prototype commerical dual-MAC station (not concentrator) IP/FDDI implementation assigned independent IP network numbers to the primary and secondary rings. That scheme works fine for using both rings for data, but is too awkward, or at least not sufficiently automatic. Eventually, some kind of expension to ARP is required to allow participating dual-MAC stations to do load balancing between the rings, to get more than 12MByte/sec of TCP over FDDI. In the FDDI case, and perhaps only in the FDDI case, it is best to have one IP address both of the MACs on a dual ring. I was the vociferous proponent of 2 IP addresses, but even I eventually saw the light. Note that I am not saying that a host acting as two independent stations on two FDDI rings should have one IP address, but only that there should be at most one IP address corresponding to each FDDI station address. (A dual-MAC station in principle has 3 addresses, one for each MAC and a third for the station. Common practice is to pick one of your 48-bit MAC addresses to extend into your 64-bit station address.) There is little current interest in dual-MAC FDDI (e.g. the 3 vendors that I knew of who were talking about dual-MAC stations have been distracted, including my employer), but that may change with the advent of commercially available stations that can easily staturate the primary ring. > Also, if an address can't have an association with an interface, and if > I have a host with both Ethernet and FDDI interfaces, how can I for example > force NFS mounts to use the FDDI interface for performance reasons if > that's what I desire? I have found that advertising "host routes" from just such ethernet and FDDI multi-homed servers solves that efficency problem invisibly and cleanly (at least from the client machine owner's perspective). Years of telling people which IP address to use to get to which interface were a nightmare. Vernon Schryver, vjs@sgi.com From owner-big-internet@munnari.oz.au Fri Oct 9 14:06:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19223; Fri, 9 Oct 1992 14:06:23 +1000 (from owner-big-internet) Return-Path: Received: from CSEIC.SAIC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06704; Fri, 9 Oct 1992 04:52:01 +1000 (from carlberg@cseic.saic.com) Received: by cseic.saic.com (4.1/1.34) id AA25702; Thu, 8 Oct 92 14:50:58 EDT Date: Thu, 8 Oct 92 14:50:58 EDT From: carlberg@cseic.saic.com (Kenneth Carlberg) Message-Id: <9210081850.AA25702@cseic.saic.com> To: yakov@watson.ibm.com Subject: Re: EIDs Cc: big-internet@munnari.oz.au Yakov, > I fully agree with your comments. Just to add, there are three > proposals on the table about supporting mobility with IP. > At least two of then (Columbia and IBM) work *perfectly* fine > without requiring topology-independent EIDs. The three proposals work *fine* without EID because they were not designed with EID in mind. Also, Columbia and IBM were designed, I presume, to support movement given the *current* routing architecture. They do not rely on proposed ideas or suppositions. And if memory serves me correctly, Sony injects a virtual addressing layer that does require mods to routers (and I believe hosts). The beauty of their approach is that they do *not* need a server to accomplish their goals. -ken 10 address changes/minute, DNS certainly will not serve. If we're talking > 2 changes/hour, there is no reason why DNS cannot keep up. I like what Robert Elz said a couple of weeks ago that "there are different kinds of mobility - and the optimal solutions to deal with the different kinds are not going to be all the same" [sept 20]. I know this might not be popular, but I like the idea of having an EID help deal with portability. Once this stepping stone is dealt with, one can then address mobility with, perhaps, some type of server (be it mobility, DNS, etc...) -ken From owner-big-internet@munnari.oz.au Fri Oct 9 15:00:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21272; Fri, 9 Oct 1992 15:00:16 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210090500.21272@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06843; Fri, 9 Oct 1992 04:59:11 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <08286-0@datanet.tele.fi>; Thu, 8 Oct 1992 20:57:45 +0200 To: jnc@ginger.lcs.mit.edu Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9210071325.AA25463@ginger.lcs.mit.edu> "jnc@ginger.lcs.mit.edu" Subject: Multiple addresses Date: Thu, 8 Oct 1992 20:57:45 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi i have to give up the discussion on addressing boxes vs. interfaces, since too much time would go in to it. i don't care what the terms are, but just the net result: - my box (host or router) should be able to speak via its fr/atm interface with any number of other boxes to which it has a virtual circuit established without a need to give more than one address to this box/interface no matter what address or how many of them the other boxes/their interfaces have. this is currently not the case with IP, but it must be the case with its next version. -- juha From owner-big-internet@munnari.oz.au Fri Oct 9 15:19:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21803; Fri, 9 Oct 1992 15:19:33 +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 AA07237; Fri, 9 Oct 1992 05:21:16 +1000 (from kasten@ftp.com) Received: by ftp.com id AA09292; Thu, 8 Oct 92 15:21:02 -0400 Date: Thu, 8 Oct 92 15:21:02 -0400 Message-Id: <9210081921.AA09292@ftp.com> To: jdemarco@ftp.com Subject: Re: Record Route (was Re: Hop Limit field in SIP) From: kasten@ftp.com (Frank Kastenholz) Cc: gmalkin@xylogics.com, solensky@andr.ub.com, VALDIS@vtvm1.cc.vt.edu, big-internet@munnari.oz.au > Let's plan ahead. Is a large TTL/hopcount likely to scale well with > route tracing mechanisms we're currently using? My guess is no. we have a chance to re-engineer the route tracing mechanisms here. what we have are sort of after-market hacks. if we want route tracing, and i think that we do, we should engineer them properly and include them in the protocol. there is no reason we should carry offensive historical baggage with us into the 21'st century. -- frank kastenholz From owner-big-internet@munnari.oz.au Fri Oct 9 15:32:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22176; Fri, 9 Oct 1992 15:33:04 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210090533.22176@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07248; Fri, 9 Oct 1992 05:23:29 +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 ; Thu, 8 Oct 1992 20:22:59 +0100 To: mandrews@alias.com (Mark Andrews) Cc: big-internet@munnari.oz.au Subject: Re: Addresses In-Reply-To: Your message of "Thu, 08 Oct 92 09:12:13 EDT." <9210081312.AA07814@dino.alias.com> Date: Thu, 08 Oct 92 20:22:57 +0100 From: Zheng Wang >Since when can one interface have multiple addresses? Doesn't every interface >have a have a unique address (for every (sub)network it belongs to) which >uniquely identifies it to another host. In the system I work with which is >4.3BSD-derived, every interface must have a unique IP address. If that host >wishes to act as a gateway, it must have multiple interfaces, each of which >has a uniqe IP address. It is true that in most systems, each interface has one address. But nothing there presents you from having two or more addresses per interface. When we did the two-tier scheme (rfc1335), I looked into the changes we have to do for mapping two addresses onto one interface - it is not very difficult, actually. Cheers Zheng From owner-big-internet@munnari.oz.au Fri Oct 9 16:03:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23004; Fri, 9 Oct 1992 16:03:59 +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 AA07817; Fri, 9 Oct 1992 05:57:17 +1000 (from kasten@ftp.com) Received: by ftp.com id AA10785; Thu, 8 Oct 92 15:56:58 -0400 Date: Thu, 8 Oct 92 15:56:58 -0400 Message-Id: <9210081956.AA10785@ftp.com> To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Subject: Re: Hop Limit field in SIP From: kasten@ftp.com (Frank Kastenholz) Cc: Big-Internet@munnari.OZ.AU while this has extraordinarily little to do with big-internet goop, why not send the packets to the echo port? > What I've long talked about (all talk and no action) is to open > sockets on the local machine to allocate port numbers free of any MSL > collision with existing traffic, and print up fake TCP/IP packets to > loft toward the target. These TCP/IP packets would be more ordindary > than the UDP/IP packets now used by traceroute, and they could not > cause any grief at the target. > > The difficulty that I see with using TCP instead of UCP traceroute > probes is in the systems I know about, it's more difficult for a user > process to get the resulting TCP reset from the target than it is to > get the ICMP port unreachable. On Suns you could use "nit". On 4.4BSD > (I think) you could use the new Stanford packet filtering stuff. On my > employers' machines, you could use a "snoop socket". > It is not as portable. > > > Vernon Schryver, vjs@sgi.com > > > > > > -- frank kastenholz From owner-big-internet@munnari.oz.au Fri Oct 9 16:21:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23506; Fri, 9 Oct 1992 16:21:57 +1000 (from owner-big-internet) Return-Path: Received: from dg-rtp.rtp.dg.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07976; Fri, 9 Oct 1992 06:09:51 +1000 (from throop@dg-rtp.dg.com) Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4.1/dg-rtp-proto) id AA09072; Thu, 8 Oct 1992 16:09:30 -0400 Received: by walrus (5.4.1/140.2) id AA06785; Thu, 8 Oct 1992 16:06:57 -0400 Date: Thu, 8 Oct 1992 16:06:57 -0400 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9210082006.AA06785@walrus> To: jnc@ginger.lcs.mit.edu Subject: Re: EIDs Cc: big-internet@munnari.oz.au I don't disagree with what you say but I have some questions. > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Message-Id: <9210081349.AA05463@ginger.lcs.mit.edu> > To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au > Subject: Re: EIDs > > To me it was clear that an EID identified the same sort of "end point > defined by continuity". ... Does that misrepresent anyone's view of it? > > No, that's approximately my definition. My technical definition of > *what* an EID *names* (i.e. an "endpoint") is an end-end/fate-sharing entity; > i.e. an entity which can participate in an end-end transaction (such as a > reliable stream), and/or an entity around which one would draw a fate-sharing > boundary (so that all the critical state for a transaction is there, and > "they all go together if they go"; i.e. crash). Could you also say that EIDs are computer friendly names for things in the network that send/receive IPvN level packets? ... > > Having the EID as part of the address is not unreasonable > > Bong! Tilt! No! The address names a *place* in the network; the EID > names a producer/consumer of packets. These are fundamentally different > things! Since EIDs name things, would it be correct to expect addresses to consist of a sequence of EIDs? ... > Noel Dean Throop throop@dg-rtp.dg.com From owner-big-internet@munnari.oz.au Fri Oct 9 16:09:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23155; Fri, 9 Oct 1992 16:10: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 AA08037; Fri, 9 Oct 1992 06:15:18 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10773; Thu, 8 Oct 92 16:13:42 -0400 Date: Thu, 8 Oct 92 16:13:42 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210082013.AA10773@ginger.lcs.mit.edu> To: barrett@daisy.ee.und.ac.za, big-internet@munnari.oz.au Subject: Re: EIDs Cc: jnc@ginger.lcs.mit.edu Perhaps the session layer is the right place for this new "identification layer". An EID could live at the the session layer, and if the entity identified by an EID migrates to a different host, or the host moves to a different network-layer address, then the session layer would have to close the old transport-layer connection and open a new one. An interesting approach. I will refrain from asking "what session layer", since that's not an acceptable answer! I still happen to think that here in the future not all internetwork packets will carry the addresses of the endpoint, since addresses are likely to become long and complex things (like DNS names are now). (This will go well with flows, which a lot of the resource architecture types seem to like.) EID's are the obvious things to put in their place. Also, there are things the EID's do for you, like making multi-homing, and multiple parallel interfaces for throughput reasons work, and they wouldn't work anywhere near as well at this if they were at the session layer. Noel From owner-big-internet@munnari.oz.au Fri Oct 9 16:24:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23610; Fri, 9 Oct 1992 16:25:22 +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 AA08785; Fri, 9 Oct 1992 07:03:52 +1000 (from kasten@ftp.com) Received: by ftp.com id AA14119; Thu, 8 Oct 92 17:03:38 -0400 Date: Thu, 8 Oct 92 17:03:38 -0400 Message-Id: <9210082103.AA14119@ftp.com> To: kre@munnari.oz.au Subject: Re: Tracing paths From: kasten@ftp.com (Frank Kastenholz) Cc: Big-Internet@munnari.oz.au > Neither of these will work - SNMP is fine as far as it goes, > but what you are doing there is asking a router to tell you > how it would route a packet with a certain destination address, > which you would hope would be the same as the way it actually > would route it, but if what you're doing is debugging a > problem, isn't necessarily what you want to assume - ideally what > you want to do is compare what the router tells you it will do > (using SNMP) with what you discover it is really doing using > traceroute. The SNMP routing table is the router's forwarding table. If they are not the same then I contend that you have several problems and some temporary routing failure is the least of them. > So, would it be useful if we just created an option (a "router" > option for those protocols that will separate them) that causes > an ICMP "trace" message to be returned to the originator of > a packet each time the packet passes through a router. > Recipient hosts could either do the same, or traceroute could > work just by sending an ICMP echo and then watching for the > echo response indicating the packet had arrived. It should be a separate new-ICMP message. If it is an option in any packet then every packet has to be checked to see if the option is set and then the proper "saw it" message generated etc etc. -- frank kastenholz From owner-big-internet@munnari.oz.au Fri Oct 9 16:25:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23639; Fri, 9 Oct 1992 16:26: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 AA08554; Fri, 9 Oct 1992 06:45:14 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11056; Thu, 8 Oct 92 16:44:29 -0400 Date: Thu, 8 Oct 92 16:44:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210082044.AA11056@ginger.lcs.mit.edu> To: Juha.Heinanen@datanet.tele.fi, kwe2@bbn.com Subject: Re: Multiple addresses [partial mesh subnets] Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The first problem comes about when we try to use partially connected subnets (ie, a partial mesh frame relay). This is a pretty tricky problem to handle. The thing is that if you have a partially connected mesh, is there really any simpler way to model it than a set of links? I mean, giving each router a list of the other routers it can connect to is just the same information in an isomorphic form. TANSTAAFL. It would be convenient if we could assign one address to all virtual circuits on a single interface but relax the assumption that the subnet is fully connected so that routing will work more easily. The administration of numbers would be easier, sure, but you still have the problem of indicating the topology connectivity. One of the things you are doing by assigning a bunch of machine numbers on the same IP (sub)network is making a statement about their topological connectivity. OK, so we remove that overload mechanism from the addressing function, but that still doesn't mean we don't have to make statments about connectivity, only now it'll take a whole separate mechanism (which might be a dynamic discovery mechanism to minimze the amount of configuration in the system). The second problem comes about on very large public networks where there are literally thousands of hosts and routers to talk to, but you can only talk to a subset and not everyone shares a common subnet on this public network for some reason. Yes; I suggested (in the IPLPDN group) that we modify the Internet routing architecture to say that the hosts *always* leave it up to the routers to decide if the destination is local. Right now we have this "mask and match" algorithm, which the hosts use to make this decision; we should always let the routers decide. This doesn't make solving the problem you refer to (that becasue transitivity no longer applies, the graph for direct connection is really complex) any easier, but at least we solve it in the routers, not in the hosts too. But if we could relax these assumptions on subnet connectedness and "direct only over common subnet" in order to improve routing models Look, these assumptions buy you something. If you relax them, fine, then they don't bite you, but all of the sudden the things they bought you that you relied on aren't there any more. You still have the basic problem to solve, and things that used to work (because of the limits imposed by the assumptions) don't. E.g., how you you find which hosts can communicate directly with which other hosts? To *really* make these non-transitive connectivity networks work you have to update the basic routing model of the routing architecture to support this kind of network. It's not pretty or easy. One way to do this would be to have "source/sinks" use endpoint identifiers and not addresses and assume nothing about the connectedness or hierarchy of the address and routing from the structure of the EID. Yes, as I indicated, I agree with this. Then it might be easier to do routing over partial mesh frame relay networks and on very, very large public data networks like SMDS that *are* fully connected but where it is impossible to either exchange routing information with all nodes or to share common address space. Nope. There are certain unavoidable problems (like the fact that the minimal representations for general partial mesh networks are not trivial), and that's that. If you want to allow these capabilities in the routing, the routing model has to be more complex. I find this problem frustrating since, like Juha, there is little discussion of these kinds of subnet structural problems on big-internet or elsewhere. Well, this was the purpose of IPLPDN... But without some changes to the underlying architectural assumptions, routing will remain difficult to adapt to these new networks. Hmm, now that I think about your problems at an abstract level, they represent capabilities that the current routing architecture was not designed to provide. Thanks for pointing this out, we need to go away and think about these. Back to the drawing board.... Noel From owner-big-internet@munnari.oz.au Fri Oct 9 16:23:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23571; Fri, 9 Oct 1992 16:24:18 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210090624.23571@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05479; Fri, 9 Oct 1992 03:44:07 +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 ; Thu, 8 Oct 1992 18:43:51 +0100 To: big-internet@munnari.oz.au Subject: IP option test (long) Date: Thu, 08 Oct 92 18:43:43 +0100 From: Zheng Wang A number of recent proposals (e.g. EIP, IBM mobile IP and Sony mobile IP) make use of the IP options to add new features within the current IP header format. Some people have expressed following concerns as to: 1) whether the presence of IP option may have visible performance penalty, and 2) whether current IP routers and hosts in the Internet can deal with unknow IP options properly (i.e. ignoring unknown IP options silently as required by RFC-1122 and router requirement draft). First, we notice that IP multicast uses the source route option for tunnelling. IP multicast has been widely used for audio and video conferencing over the Internet, and no performance problems have been reported. In order to look into these issues further, we carried out a number of experiments over the use of IP option. We selected 35 hosts around *30 countries* across the Internet (just look at the domain names see if you can figure where they are!!) A TCP test program (based on ttcp.c) then transmitted data to the echo port (tcp port 7) of each of the hosts. Two tests were carried out for each host, one with an unknown option (type 0x8A, length 40 bytes) and the other without any options. It is difficult to ensure that the conditions under which the two tests run are identical but we tried to make them as close as possible. The two tests (test-opt and test-noopt) run on the same machine (a Sun4) in parallel, i.e. "test-opt& ; test-noopt&" and then again in the reverse order, i.e. "test-noopt& ; test-opt&", so each test pair actually run twice. Each host is ping'ed before the test so that the first test is not delayed by the domain name lookup. The experiments were carried out at three sites: UCL, Bellcore and Cambridge University. The tcp echo throughput (KB/Sec) results are listed below. The results show that the IP option was dealt with properly and there is no visible performance difference for the two tests. Cheers Zheng Througput Test from UCL (sartre.cs.ucl.ac.uk) Destination Host test-noopt test-opt ------------------- ---------- --------- oliver.cs.mcgill.ca 1.128756 1.285345 oliver.cs.mcgill.ca 1.063096 1.239709 bertha.cc.und.ac.za 0.094336 0.043917 bertha.cc.und.ac.za 0.075681 0.057120 vnet3.vub.ac.be 2.090622 2.228181 vnet3.vub.ac.be 1.781374 1.692740 itdsrv1.ul.ie 1.937596 2.062579 itdsrv1.ul.ie 1.928313 1.936784 sunic.sunet.se 11.064797 11.724055 sunic.sunet.se 10.861720 10.840306 pascal.acm.org 2.463790 0.810133 pascal.acm.org 1.619088 0.860198 iti.gov.sg 1.565320 1.983795 iti.gov.sg 1.564788 1.921803 rzusuntk.unizh.ch 9.903805 11.335920 rzusuntk.unizh.ch 9.597806 10.678098 funet.fi 9.897876 9.382925 funet.fi 10.487118 11.023745 odin.diku.dk 5.851407 5.482946 odin.diku.dk 5.992257 6.243283 cphkvx.cphk.hk 0.758044 0.844406 cphkvx.cphk.hk 0.784532 0.745606 bootes.cus.cam.ac.uk 28.341705 29.655824 bootes.cus.cam.ac.uk 24.804125 23.240990 pesach.jct.ac.il 1.045922 1.115802 pesach.jct.ac.il 1.330429 0.978184 sun1.sara.nl 10.546733 11.500778 sun1.sara.nl 9.624833 10.214136 cocos.fuw.edu.pl 1.747777 1.702324 cocos.fuw.edu.pl 1.676151 1.716435 apple.com 4.449559 4.145081 apple.com 6.431675 5.520443 gorgon.tf.tele.no 1.199810 1.374546 gorgon.tf.tele.no 0.508642 0.993261 kogwy.cc.keio.ac.jp 3.626448 3.249590 kogwy.cc.keio.ac.jp 3.913777 4.094849 exu.inf.puc-rio.br 1.913925 1.795235 exu.inf.puc-rio.br 1.154936 1.114775 inria.inria.fr 2.299561 0.599665 inria.inria.fr 1.219282 0.873672 kum.kaist.ac.kr 0.252704 0.254199 kum.kaist.ac.kr 0.236196 0.172367 sunipc1.labein.es 1.398777 1.243588 sunipc1.labein.es 0.876177 0.602964 wifosv.wsr.ac.at 0.531153 0.803387 wifosv.wsr.ac.at 0.773935 0.557798 uunet.uu.net 7.813556 6.764543 uunet.uu.net 7.969203 6.657325 infnsun.aquila.infn.it 2.321197 2.402477 infnsun.aquila.infn.it 2.400196 2.695016 muttley.fc.ul.pt 0.545775 0.434672 muttley.fc.ul.pt 0.284124 0.266017 dmssyd.syd.dms.csiro.au 2.734685 2.857545 dmssyd.syd.dms.csiro.au 1.168154 1.462789 hamlet.caltech.edu 2.552804 2.897286 hamlet.caltech.edu 3.839141 2.407945 sztaki.hu 0.294196 0.403697 sztaki.hu 0.236260 0.388755 menvax.restena.lu 0.465066 0.515361 menvax.restena.lu 0.358646 0.511985 nctu.edu.tw 0.484372 0.816722 nctu.edu.tw 0.705733 1.109228 xalapa.lania.mx 0.899529 0.822544 xalapa.lania.mx 1.150058 0.881713 truth.waikato.ac.nz 1.438481 1.993749 truth.waikato.ac.nz 1.325041 1.833999 Througput Test from Bellcore (latour.bellcore.com) Destination Host test-noopt test-opt ------------------- ---------- --------- oliver.cs.mcgill.ca 1.820014 2.128104 oliver.cs.mcgill.ca 1.979981 1.866815 bertha.cc.und.ac.za 0.099289 0.035877 bertha.cc.und.ac.za 0.118627 0.103763 vnet3.vub.ac.be 0.368476 0.694463 vnet3.vub.ac.be 0.443269 0.644050 itdsrv1.ul.ie 0.721444 0.960068 itdsrv1.ul.ie 0.713952 0.953275 sunic.sunet.se 2.989907 2.956766 sunic.sunet.se 2.100563 2.010292 pascal.acm.org 2.487185 3.896253 pascal.acm.org 1.944085 4.269323 iti.gov.sg 2.401733 2.735445 iti.gov.sg 2.950990 2.793121 rzusuntk.unizh.ch 4.094820 3.618023 rzusuntk.unizh.ch 2.952650 2.245001 funet.fi 6.703408 5.928008 funet.fi 7.389722 5.815122 odin.diku.dk 2.094152 2.450695 odin.diku.dk 5.362362 4.690722 cphkvx.cphk.hk 0.092698 0.106880 cphkvx.cphk.hk 0.496394 0.681994 bootes.cus.cam.ac.uk 2.632951 2.631322 bootes.cus.cam.ac.uk 3.717170 1.335914 pesach.jct.ac.il 0.684029 0.921621 pesach.jct.ac.il 0.390263 1.095265 sun1.sara.nl 3.186035 2.325166 sun1.sara.nl 3.053797 3.081236 cocos.fuw.edu.pl 0.154405 0.124795 cocos.fuw.edu.pl 0.120283 0.105825 apple.com 12.588979 12.957880 apple.com 13.861733 12.211125 gorgon.tf.tele.no 1.280217 1.112675 gorgon.tf.tele.no 0.243205 0.631096 kogwy.cc.keio.ac.jp 6.249789 5.075968 kogwy.cc.keio.ac.jp 3.387490 4.583511 exu.inf.puc-rio.br 2.089536 2.233711 exu.inf.puc-rio.br 2.476758 2.249439 inria.inria.fr 0.653974 0.866246 inria.inria.fr 0.739127 1.130521 kum.kaist.ac.kr 1.541682 1.312546 kum.kaist.ac.kr 0.906632 1.042793 sunipc1.labein.es 0.101496 0.091456 sunipc1.labein.es 0.054245 0.101585 wifosv.wsr.ac.at 1.044443 0.369528 wifosv.wsr.ac.at 0.596935 0.870377 uunet.uu.net 9.530348 8.999789 uunet.uu.net 8.941888 6.075660 infnsun.aquila.infn.it 1.619418 1.569645 infnsun.aquila.infn.it 1.156780 1.158000 muttley.fc.ul.pt 0.353632 0.416126 muttley.fc.ul.pt 0.221522 0.155505 dmssyd.syd.dms.csiro.au 3.433901 3.272839 dmssyd.syd.dms.csiro.au 3.408975 3.130188 hamlet.caltech.edu 5.367756 6.325031 hamlet.caltech.edu 4.828718 5.676571 sztaki.hu 0.301120 0.362481 sztaki.hu 0.253222 0.519892 menvax.restena.lu 0.364221 0.480789 menvax.restena.lu 0.456882 0.580778 nctu.edu.tw 0.246523 1.199412 nctu.edu.tw 0.423476 0.630833 xalapa.lania.mx 0.748642 0.607284 xalapa.lania.mx 0.716781 0.643030 truth.waikato.ac.nz 2.197595 2.072601 truth.waikato.ac.nz 2.489748 2.186684 Througput Test from Cam U (cus.cam.ac.uk) Destination Host test-noopt test-opt ------------------- ---------- --------- oliver.cs.mcgill.ca 1.128756 1.285345 oliver.cs.mcgill.ca 1.063096 1.239709 bertha.cc.und.ac.za 0.031218 0.031221 bertha.cc.und.ac.za 0.034405 0.034925 vnet3.vub.ac.be 0.568487 0.731320 vnet3.vub.ac.be 0.558238 0.581415 itdsrv1.ul.ie 1.064302 1.284707 itdsrv1.ul.ie 0.852089 1.025779 sunic.sunet.se 7.179942 6.270326 sunic.sunet.se 5.772485 6.689160 pascal.acm.org 1.661248 1.726725 pascal.acm.org 1.557839 1.428193 iti.gov.sg 0.600616 0.926690 iti.gov.sg 0.772887 0.956636 rzusuntk.unizh.ch 3.645913 4.504969 rzusuntk.unizh.ch 1.853503 2.671272 funet.fi 4.190147 3.421110 funet.fi 2.270988 3.789678 odin.diku.dk 1.361227 0.993901 odin.diku.dk 1.977774 2.415716 cphkvx.cphk.hk 1.173451 1.298421 cphkvx.cphk.hk 1.151376 1.184210 bootes.cus.cam.ac.uk 269.589141 238.920081 bootes.cus.cam.ac.uk 331.203020 293.556436 pesach.jct.ac.il 0.343598 0.492202 pesach.jct.ac.il 0.582809 0.930958 sun1.sara.nl 1.529277 1.470571 sun1.sara.nl 0.896041 0.894923 cocos.fuw.edu.pl 0.131180 0.142239 cocos.fuw.edu.pl 0.137697 0.148895 apple.com 1.330794 0.453590 apple.com 0.856476 0.714661 gorgon.tf.tele.no 0.094793 0.099981 gorgon.tf.tele.no 0.167257 0.151625 kogwy.cc.keio.ac.jp 0.154681 0.178868 kogwy.cc.keio.ac.jp 1.095814 0.871496 exu.inf.puc-rio.br 0.454272 0.384484 exu.inf.puc-rio.br 0.705198 0.690708 inria.inria.fr 0.149511 0.150021 inria.inria.fr 0.071125 0.077257 kum.kaist.ac.kr 0.721184 0.549511 kum.kaist.ac.kr 0.250285 0.296195 sunipc1.labein.es 0.519284 0.491745 sunipc1.labein.es 0.990174 1.009475 wifosv.wsr.ac.at 0.360751 0.418554 wifosv.wsr.ac.at 0.344268 0.326605 uunet.uu.net 4.247430 3.305592 uunet.uu.net 3.139251 2.945469 infnsun.aquila.infn.it 0.480731 0.782631 infnsun.aquila.infn.it 0.230471 0.292273 muttley.fc.ul.pt 0.239624 0.334286 muttley.fc.ul.pt 0.586156 0.419485 dmssyd.syd.dms.csiro.au 3.630623 3.607504 dmssyd.syd.dms.csiro.au 1.743162 2.994665 hamlet.caltech.edu 5.897946 4.650703 hamlet.caltech.edu 5.118200 5.622022 sztaki.hu 0.338358 0.225206 sztaki.hu 0.113328 0.112637 menvax.restena.lu 0.224967 0.359237 menvax.restena.lu 0.452945 0.472345 nctu.edu.tw 2.549709 2.037245 nctu.edu.tw 2.229093 2.469851 xalapa.lania.mx 0.713586 0.810107 xalapa.lania.mx 0.612278 0.731705 truth.waikato.ac.nz 1.438481 1.993749 truth.waikato.ac.nz 1.325041 1.833999 From owner-big-internet@munnari.oz.au Fri Oct 9 16:23:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23539; Fri, 9 Oct 1992 16:23: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 AA07828; Fri, 9 Oct 1992 05:59:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10661; Thu, 8 Oct 92 15:58:02 -0400 Date: Thu, 8 Oct 92 15:58:02 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210081958.AA10661@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, oran@sneezy.lkg.dec.com Subject: Re: Splitting the network layer: take 2 Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I'm going to kick myself for opening my mouth here. There's a line from an old movie (which one I forget) to the effect of "why don't you, everyone else has"! In order argue for EIDs, you have to make a case that they do something neither addresses nor names do. That's right. They do. If an EID is topologically sensitive Gads! Perish the thought.. If an EID is a long as a name It isn't. a) decoupled from both the topology and the administration of the routing infrastructure b) a lot shorter than a name c) cheap to do equality tests on d) at least as stable as a name This is definitely a partial list of the properties of what I call an EID. I think the bottom line is that unless EIDs bring some new architectural semantics that are deemed important (like temporal uniqueness), then one can argue about them strictly in terms of engineering tradeoffs and hints/performance optimizations over always using just a name or just an address. Well, it's not quite an engineering argument. I think you and I could agree that objects called endpoints (with the properties I have outlined) exist, yes? If not, lead on, MacDuff! If so, though, the only question is "do we need a namespace for them, and if so, does it already exist"? Addresses clearly don't name endpoints, they name places in the topology. DNS style names might name them, but I don't think so; DNS names seem to name more complex things with a lot of attributes. Also, DNS names might name services or something. The real issue is the mappings; if there is *always* a *one-one* mapping from DNS names to the thigns you and I call endpoint, then we don't need a separate namespace for them (leaving aside the engineering arguments about length, etc, you refer to). However, I think you would hesitate to make this case! So, if there isn't a one-one mapping, we *do* need a separate namespace for endpoints (the EID's), with the associated name-binding mechanisms. None of this is to deny the engineering arguments you put forward, which are significant and good points. However, they are really icing on the cake to me. The real key is Lampson's Law ("all problems in computer science can be solved with more level of indirection")! That doesn't mean that for localized routing, such as is done by ISIS level 1 (which treats the addresses as flat anyway) they can't be economically used as "addressing information". True. I would like ... that the identifier is embedded in the address both logically and physically. I don't agree. I think I explained why in a previous message. They are naming different kinds of things entirely (an endpoint and a place in the network), and one cannot be "part of" another, although they may be commonly seen and used in a tuple. 1) it uses a single mechanism to get spacial uniqueness, thus providing superior autoconfiguration behavior, and If the routers know the physical network's address, the complete interface address can be formed by concatenating that with either the local hardware address (e.g. the IEEE address), or the identifier; this requires no extra configuration on the host at all. 2) it allows a single mechansim for endpoint identification and local-region routing. If you take the ARP approach to life, where an EID plus a name-binding region is as good as an address, this is still true. Noel From owner-big-internet@munnari.oz.au Fri Oct 9 16:54:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24377; Fri, 9 Oct 1992 16:55:34 +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 AA13693; Fri, 9 Oct 1992 10:49:56 +1000 (from bill@wizard.gsfc.nasa.gov) Received: from wizard.gsfc.nasa.gov by shark.mel.dit.csiro.au with SMTP id AA15329 (5.65c/IDA-1.4.4/DIT-1.3); Fri, 9 Oct 1992 10:40:54 +1000 Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA12557; Thu, 8 Oct 92 20:38:58 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9210090038.AA12557@wizard.gsfc.nasa.gov> Subject: Re: Tracing paths To: kre@munnari.oz.au (Robert Elz) Date: Thu, 8 Oct 92 20:38:58 EDT Cc: Big-Internet@munnari.oz.au In-Reply-To: <11186.718560918@munnari.oz.au>; from "Robert Elz" at Oct 9, 92 2:15 am X-Mailer: ELM [version 2.3 PL11] > I think the answer here, is that traceroute elicits a response > from each router along the path to the destination, as the > packet is forwarded. That the packet in question isn't actually > forwarded, but is dropped instead is the accident, and > brilliance, of the implementation, rather than the idea. If I understand this right, even this might have problems. There's no guarantee that the trace packets would be returned to the source in the same order that the routers were traversed. I guess you could return the current TTL value and have the source sort the replies by the TTLs, but this could get messy. -Bill From owner-big-internet@munnari.oz.au Fri Oct 9 18:12:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26424; Fri, 9 Oct 1992 18:17:20 +1000 (from owner-big-internet) Return-Path: Received: from enet-gw.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10324; Fri, 9 Oct 1992 08:19:42 +1000 (from huston@cfsctc.enet.dec.com) Received: by enet-gw.pa.dec.com; id AA07556; Thu, 8 Oct 92 15:11:16 -0700 Message-Id: <9210082211.AA07556@enet-gw.pa.dec.com> Received: from cfsctc.enet; by decwrl.enet; Thu, 8 Oct 92 15:11:48 PDT Date: Thu, 8 Oct 92 15:11:48 PDT From: "Steve Huston, ASD/SEE Engineering, 244-7117 08-Oct-1992 1537" To: mandrews@alias.com Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, mandrews@alias.com Subject: Re: Addresses >>So? It has one interface, which has many addresses. What's the problem? > >Since when can one interface have multiple addresses? Since reality broke in ;-) It's common in non-trivial networks for this to be the case. >Doesn't every interface >have a have a unique address (for every (sub)network it belongs to) which >uniquely identifies it to another host. Sometimes this is true. Sometimes not. Hosts have some number of IP addresses and some number of interfaces. Sometimes they have different numbers of each. >In the system I work with which is >4.3BSD-derived, every interface must have a unique IP address. If that host >wishes to act as a gateway, it must have multiple interfaces, each of which >has a uniqe IP address. Yes, BSD-derived systems have this defect. Steve Huston Digital Equipment Corporation huston@cfsctc.enet.dec.com 100 Nagog Park, AKO1-3/H4 +1 508 264 7117 Acton, MA 01720 From owner-big-internet@munnari.oz.au Fri Oct 9 18:36:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26909; Fri, 9 Oct 1992 18:37:42 +1000 (from owner-big-internet) Return-Path: Received: from wizard.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09486; Fri, 9 Oct 1992 07:43:30 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA12332; Thu, 8 Oct 92 17:43:52 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9210082143.AA12332@wizard.gsfc.nasa.gov> Subject: Re: Hop Limit field in SIP To: big-internet@munnari.oz.au Date: Thu, 8 Oct 92 17:43:52 EDT In-Reply-To: <921007.134334.EDT.VALDIS@vtvm1.cc.vt.edu>; from "Valdis Kletnieks" at Oct 7, 92 1:43 pm X-Mailer: ELM [version 2.3 PL11] > If properly designed, a 'record route' would return with the *complete* > path taken *both* ways (to detect asymmetric routes - not doable easily > now), and the reason for turnaround (target host reached, net unreachable, > TTL exceeded, etc). The version of traceroute I use can do this easily via the "-g" option which utilizes LSRR source routing. To get a full path, both forward and return, you just do "traceroute -g dst src". For example, here's a traceroute from my machine, wizard.gsfc.nasa.gov, to munnari.oz.au and back. wizard% traceroute -g munnari.oz.au wizard traceroute to wizard.gsfc.nasa.gov (128.183.115.17), 30 hops max, 40 byte packets 1 rtr-115r.gsfc.nasa.gov (128.183.115.1) 3 ms 3 ms 3 ms 2 nsi-gw1.gsfc.nasa.gov (128.183.10.40) 4 ms 5 ms 4 ms 3 128.161.2.10 (128.161.2.10) 72 ms * 74 ms 4 ARC5.NSN.NASA.GOV (192.100.12.5) 72 ms 72 ms 72 ms 5 usa.gw.au (132.160.240.2) 670 ms 647 ms 644 ms 6 munnari.OZ.AU (128.250.1.21) 651 ms 653 ms 646 ms 7 usa.gw.au (139.130.4.5) 653 ms 900 ms 713 ms 8 132.160.240.1 (132.160.240.1) 649 ms 658 ms * 9 ARC1.NSN.NASA.GOV (192.100.12.1) 649 ms 652 ms 663 ms 10 128.161.2.3 (128.161.2.3) 657 ms 666 ms 659 ms 11 rtr-115.gsfc.nasa.gov (128.183.6.115) 649 ms 652 ms 670 ms 12 wizard.gsfc.nasa.gov (128.183.115.17) 648 ms 652 ms 663 ms -Bill From owner-big-internet@munnari.oz.au Fri Oct 9 18:36:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26862; Fri, 9 Oct 1992 18:37:18 +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 AA09789; Fri, 9 Oct 1992 07:54:45 +1000 (from kasten@ftp.com) Received: by ftp.com id AA15842; Thu, 8 Oct 92 17:54:31 -0400 Date: Thu, 8 Oct 92 17:54:31 -0400 Message-Id: <9210082154.AA15842@ftp.com> To: VALDIS@VTVM1.CC.VT.EDU Subject: Traceroute engineering -- was Re: Hop Limit field in SIP From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au > Anybody got any ideas? First, someone will have to convince me that SNMP is not a reasonable way to do it. Second, if we are designing, as a part of a new IP, a protocol to extract routes from the net then we can add whatever parts to it that we need. Some examples, we could have each router send an answer back to the originator saying "I got it on interface with IP Address X, I'm sending it to the router with IP Address Y and I'm sending it out my interface with IP Address Z" Anyway, my point is that this sort of thing is relatively easy to engineer. The most effort that we ought to invest in doing things like Traceroute++, ICMP++, etc, is to assure ourselves that these functions are doable in the various contenders. -- frank kastenholz From owner-big-internet@munnari.oz.au Fri Oct 9 18:50:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27183; Fri, 9 Oct 1992 18:53:22 +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 AA10250; Fri, 9 Oct 1992 08:16:43 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA17119; Thu, 8 Oct 92 13:57:32 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA14357; Thu, 8 Oct 1992 16:57:28 -0400 To: jdemarco@ftp.com Subject: Re: Record Route (was Re: Hop Limit field in SIP) In-Reply-To: <9210081655.AA02920@ftp.com> References: <9210081655.AA02920@ftp.com> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.0 From: David Oran Date: Thu, 8 Oct 92 16:57:28 -0400 Message-Id: <921008165728.13756@sneezy.lkg.dec.com> Encoding: 24 TEXT, 6 TEXT SIGNATURE > >Consider a path which was 30 hops long (which is pretty large by > >todays standards). That means you'd have to record 60 addresses > >at 4 bytes per address (so far :-) which comes to 240 bytes plus > >headers. The total is still under 300 bytes. Are there so many > >media with a smaller MTU that this is a problem? > I've always thought the traceroute function was better accomplished with "cerenkov" packets. In this scheme, you add an option to a regular IP packet, or set a bit, which says "report that the packet visited this router". The router, when it sees this trigger, forwards the orginal packet (if it can), and sends back a special control packet to the source containing the first "n" bytes of the original packet data plus the IP address of the next hop. The source accumulates the cerenkov packets until it gets one from the destination, it gets an ICMP unreachable, or it times out, whereupon it reports the entire path, no matter how long. The upper bound on the number of cerenkov packets generated is equal to the source hop count, and missing hops can be interpolated if a cerenkov packet is lost. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 hem rather than trying to insert extra space into an existing packet. If we went back to 24-byte headers (perhaps the one-byte checksum idea makes sense), then the overhead might be easier to swallow. Cheers, Tracy From owner-big-internet@munnari.oz.au Fri Oct 9 18:56:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27250; Fri, 9 Oct 1992 18:56:50 +1000 (from owner-big-internet) Return-Path: Received: from horse.ee.lbl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09272; Fri, 9 Oct 1992 07:30:17 +1000 (from vern@horse.ee.lbl.gov) Received: by horse.ee.lbl.gov for big-internet@munnari.oz.au (5.65/1.41) id AA20535; Thu, 8 Oct 92 14:30:02 -0700 Message-Id: <9210082130.AA20535@horse.ee.lbl.gov> To: big-internet@munnari.oz.au Subject: Re: Record Route (was Re: Hop Limit field in SIP) In-Reply-To: Your message of Thu, 08 Oct 92 11:52:28 EDT. Date: Thu, 08 Oct 92 14:30:02 PDT From: Vern Paxson > But you're using 8 byte addresses in SIP. A thirty-hop path then takes up > 480 bytes in the packet, excluding SIP and whatever other headers. That's > getting too close to 512 bytes to have that warm & fuzzy that it'll be highly > dependable for much longer. Here's an idea that should work regardless of the upper hop-count or whether TTL is dumped for timestamps. Suppose the Record Route packet had the following information in its header: a 32-bit "current hop" count, a 32-bit "begin recording at this hop" count, and 32-bit value indiciating how many hops have already been recorded in the packet's body. The semantics are that at each hop the "current hop" count is incremented, and if it exceeds the "begin recording at this hop" count then the hop is added to the end of the packet and the number of recorded hops bumped. If there is no room to add the hop then the packet is just forwarded as-is, with just the hop-count updated. The final hop to the destination is not treated specially except that the packet is then directed back to the source (and marked as such, so it doesn't loop). Tools like traceroute would then send out these packets and if they came back "short" (the final recorded hop is not to the originating host) would send out another packet with an adjusted "begin recording" count equal to the number of hops that the first packet took. (Probably actually you'd want to use a little lower value; if the beginning of the second packet's route trace didn't match the end of the first packet's then traceroute could detect that a different path was taken.) This gives traceroute enough information to display arbitrarily long, asymmetric paths and to gather the information more efficiently than with the present scheme. The two counters could be merged into one by using a "count-down" counter that is decremented at each hop until it hits zero, at which point recording begins. Finally, each router could if it wanted check the last recorded hop to see whether it's marked as coming from the router's peer. If not then the router's peer must not have understood the message, and the router can mark that there's a gap in the hops by recording a special "gap" address in the route. Vern From owner-big-internet@munnari.oz.au Fri Oct 9 19:38:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28032; Fri, 9 Oct 1992 19:41:27 +1000 (from owner-big-internet) Return-Path: Received: from dg-rtp.rtp.dg.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08210; Fri, 9 Oct 1992 06:24:42 +1000 (from throop@dg-rtp.dg.com) Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4.1/dg-rtp-proto) id AA10571; Thu, 8 Oct 1992 16:24:29 -0400 Received: by walrus (5.4.1/140.2) id AA06838; Thu, 8 Oct 1992 16:21:57 -0400 Date: Thu, 8 Oct 1992 16:21:57 -0400 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9210082021.AA06838@walrus> To: milan@mjm.xyplex.com Subject: Re: Using NTP time value instead of a Hop Limit field in SIP Cc: big-internet@munnari.oz.au > From: milan@mjm.xyplex.com (Milan Merhar) > Message-Id: <9210081234.AA01733@mjm.xyplex.com> > To: big-internet@munnari.oz.au > Subject: Using NTP time value instead of a Hop Limit field in SIP > > A very, very dumb question.... > > If the network layer needs to put an expiration date into > each message it sends, and it needs to have the current time to > do this, how does it get the current time in the first place? > > Running NTP assumes that the node can send and receive messages. > Does it guess at a reasonable time value in its first message, > or does it need some kind of non-volatile clock to maintain a > rough "real time" count even through power-cycles? > > (This is not to say I'm against this scheme - as a way of controlling > resource usage it's much cleaner (IMHO) than an arbitrary decrement of > a field. I'm just looking to see if its stable at the boundary > conditions.) We could define the protocol to way that an expiration time of zero can be used for sending packets that don't have to be forwarded on to other routers. This would allow a new node to communicate with local peers (where local means directly addressable via attached hardward) to learn the current time. This could would also allow hosts to send packets to routers with an expiration time of zero and the routers would fill in the appropriate time before sending the packet on. This means the first hop router has to know both the current time and the appropriate delay required to compute the packet expiration time. However all subsequent routers need not modify the header but only compare the time. Doing this means hosts don't have to know either the current time nor the delays. Hosts talk with other local hosts using a zero expiration time. If the router is the only hop, it still doesn't need an expiration time. Only if the router forwards the packet to another router does it need to compute an expiration time. Dean Throop throop@dg-rtp.dg.com From owner-Big-Internet@munnari.oz.au Fri Oct 9 19:55:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28454; Fri, 9 Oct 1992 19:55:32 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210090955.28454@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28424; Fri, 9 Oct 1992 19:55:17 +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 ; Fri, 9 Oct 1992 10:54:59 +0100 To: Zheng Wang Cc: big-internet@munnari.oz.au Subject: Re: IP option test (long) In-Reply-To: Your message of "Thu, 08 Oct 92 18:43:43 BST." <9210090624.23571@munnari.oz.au> Date: Fri, 09 Oct 92 10:54:58 +0100 From: Jon Crowcroft >First, we notice that IP multicast uses the source route option >for tunnelling. IP multicast has been widely used for audio and >video conferencing over the Internet, and no performance >problems have been reported. (except for known one in bbn t20 at ucl:-) >The results show that the IP option was dealt with properly and >there is no visible performance difference for the two tests. very good news - anyone care to run a traceroute from the 3 sources to the n destinations, then do an snmp get on the router systems and identify router vendor (and maybe interface types...) - shouldn't take more than a week... cheers j From owner-big-internet@munnari.oz.au Sat Oct 10 05:32:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09256; Sat, 10 Oct 1992 05:32: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 AA06445; Sat, 10 Oct 1992 02:47:04 +1000 (from kasten@ftp.com) Received: from ftp.com (babyoil.ftp.com) by shark.mel.dit.csiro.au with SMTP id AA26446 (5.65c/IDA-1.4.4/DIT-1.3); Sat, 10 Oct 1992 02:47:06 +1000 Received: by ftp.com id AA00892; Fri, 9 Oct 92 12:44:13 -0400 Date: Fri, 9 Oct 92 12:44:13 -0400 Message-Id: <9210091644.AA00892@ftp.com> To: trewitt@pa.dec.com Subject: Re: Tracing paths From: kasten@ftp.com (Frank Kastenholz) Cc: kre@munnari.oz.au, Big-Internet@munnari.oz.au, trewitt@Pa.dec.com one of the parts of the new-ip effort is to create the needed mibs. if the new ip has the "right" support for policy and tos then the mib will need to reflect that. ergo, in the new ip, one should be able to do traceroutes via looking at the routing mib. > The problem with tracing routes using SNMP (which I heartly support, > and have implemented with good success) is that the SNMP forwarding table > doesn't tell the whole story. There are lots of things that can > trigger a descrepency between what the routing table says, and what the > router does: > 1) Policy decisions. e.g. We don't pass type FOO packets from subnet X. > This can screw up a traceroute function, as well. > 2) TOS routing. The ipRouteTable doesn't contain any information about > TOS. Even if it did, I'm not sure that I could write the code > that emulates a router's decisions (or bugs) about the mapping > from packet type/TOS/whatever to "preferred" route. > 3) Multipath routing. The current ipRouteTable doesn't contain any > information about this. (MIB-II did, at one point, but it got > taken out in a decision that I still curse Marshall for.) > > I haven't looked closely at the new ipForwarding table to see what of > these problems might have been addressed, but that isn't my point. My > point is that you really need to see what will happen to a REAL PACKET. > > The ICMP "record route" packet is a really neat idea, especially > because it can record the entire round-trip. Attention should be paid > to making it faithfully behave like a real packet, to overcome some of > the above problems. > > An SNMP capability that I'd like to see is an SNMP table that is > indexed by destination IP address, that would return the answer to the > question "how would route to this address?" No get-next on this table, > though. > > - Glenn > -- frank kastenholz From owner-big-internet@munnari.oz.au Sat Oct 10 05:46:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09736; Sat, 10 Oct 1992 05:48:10 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210091948.9736@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11703; Fri, 9 Oct 1992 09:28:15 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1346; Thu, 08 Oct 92 19:27:58 EDT Date: Thu, 8 Oct 92 19:27:58 EDT From: yakov@watson.ibm.com To: carlberg@cseic.saic.com Cc: big-internet@munnari.oz.au Subject: EIDs Ref: Your note of Thu, 8 Oct 92 14:50:58 EDT >The three proposals work *fine* withtou EID because >they were not designed with EID in mind. Ken, That is absolutely correct. What I wonder, though, is how a proposal that would be designed *with* EID in mind would compare to these three proposals. Yakov Rekhter From owner-big-internet@munnari.oz.au Sat Oct 10 07:24:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12055; Sat, 10 Oct 1992 07:24:41 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210092124.12055@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11431; Fri, 9 Oct 1992 09:14:51 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 0926; Thu, 08 Oct 92 19:14:26 EDT Date: Thu, 8 Oct 92 19:14:25 EDT From: yakov@watson.ibm.com To: pgross@ans.net Cc: iesg@reston.va.us, Big-Internet@munnari.oz.au Subject: IESG deliberations on ROAD Phill, I fully agree with you that we should not wait for the formation of the WG to start discussing the criteria. However, at the same time, we should keep in mind that forming a WG takes some time. Thus, I would suggest to proceed in parallel. Namely, that we should start a process to form a new WG that will work on getting the IETF community consensus on the criteria, while at the same time using the IESG document as a base for the discussion and using e-mail for this discussion while waiting to pass through all the necessary formalities to form a new WG. As I said in one of my previous mail, the issue of criteria is too important for the Internet, and thus deserve a special attention. Using WG to deal with this is likely to be highly beneficial to the IETF community. To facilitate e-mail discussion I would suggest to form a separate mailing list (Big-Internet mailing list is obviously overloaded with quite a few subjects). One possible place to maintain this list would be CNRI. Peter Ford suggested that the WG be co-chaired by Craig Partridge and myself. I would be more than glad to work with Craig. Yakov Rekhter. From owner-Big-Internet@munnari.oz.au Sat Oct 10 07:54:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12891; Sat, 10 Oct 1992 07:55:16 +1000 (from owner-Big-Internet) Return-Path: Received: from timbuk.cray.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12867; Sat, 10 Oct 1992 07:54:49 +1000 (from dab@berserkly.cray.com) Received: from handel.cray.com.cray.com by cray.com (4.1/CRI-MX 2.2) id AA16322; Fri, 9 Oct 92 16:54:33 CDT Received: by handel.cray.com.cray.com id AA02122; 5.65/CRI-5.5; Fri, 9 Oct 1992 16:53:25 -0500 Date: Fri, 9 Oct 1992 16:53:25 -0500 From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9210092153.AA02122@handel.cray.com.cray.com> To: big-internet@munnari.oz.au Subject: Re: Record Route (was Re: Hop Limit field in SIP) Of course, with this line of discussion on how to do traceroute things in SIP, or in general, there is one point that seems to have been overlooked. Many of the schemes involved are implemented in a layer above IP. Routers don't normally look above the IP layer unless the packet's destination address is for the router. Hence, to make something like an ICMP-Record-Route message work would require that routers look at the upper-layer protocol as the packets go through. The current Record-Route option is at the IP layer, so it is part of what routers normally look at. Having each router be required to peek at the upper layer protocols on each packet doesn't seem very attractive to me. An alternative would be to have the ultimate destination in the ICMP-Record-Route message. At each hop, the next-hop would be calculated using the ultimate destination, but the IP destination field would be filled in with the next-hop address (a dynamically created source route???). When the packet arrives at a machine where both address match, then it has reached the destination. This is not to say that I think that this is a great idea, but it is the sort of thing that would have to be done. Not to mention that all the routers would have to play along for this to work. Trying to implement something like this today would be a real pain. Making it work with a new IP (like SIP) from the onset would be much easier, since every router would have to change anyway. -David Borman, dab@cray.com From owner-Big-Internet@munnari.oz.au Sat Oct 10 08:04:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13170; Sat, 10 Oct 1992 08:05:48 +1000 (from owner-Big-Internet) Return-Path: Received: from [160.104.1.1] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13137; Sat, 10 Oct 1992 08:04:50 +1000 (from jim@tadpole.com) Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA13825; Fri, 9 Oct 92 17:02:11 CDT Date: Fri, 9 Oct 92 17:02:11 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9210091702.ZM13823@tadpole> In-Reply-To: David Oran "Re: Record Route (was Re: Hop Limit field in SIP)" (Oct 8, 4:57pm) References: <9210081655.AA02920@ftp.com> <921008165728.13756@sneezy.lkg.dec.com> X-Mailer: Z-Mail (2.1b.27 9/21/92) To: David Oran , jdemarco@ftp.com Subject: Re: Record Route (was Re: Hop Limit field in SIP) Cc: big-internet@munnari.oz.au On Oct 8, 4:57pm, David Oran wrote: > The upper bound on the number of cerenkov packets generated is > equal to the source hop count, and missing hops can be interpolated > if a cerenkov packet is lost. I think the upper bound is actually the TTL. Consider a routing loop where the packet never makes it to its destination, but loops around some set of gateways which include some component of the path specified by the source routes, until the TTL expires. Jim From owner-big-internet@munnari.oz.au Sat Oct 10 08:45:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15284; Sat, 10 Oct 1992 08:45:10 +1000 (from owner-big-internet) Return-Path: Received: from aerospace.aero.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23015; Fri, 9 Oct 1992 16:04:14 +1000 (from obrien@aero.org) Received: from antares.aero.org by aerospace.aero.org with SMTP (5.65c/6.0.GT) id AA17365 for big-internet@munnari.oz.au; Thu, 8 Oct 1992 23:03:45 -0700 Posted-Date: Thu, 08 Oct 92 23:03:39 PDT Message-Id: <199210090603.AA17365@aerospace.aero.org> Received: from anpiel.aero.org by antares.aero.org (4.1/AMS-1.0) id AA23681 for gmalkin@xylogics.com; Thu, 8 Oct 92 23:03:42 PDT To: Gary Scott Malkin Cc: Big-Internet@munnari.oz.au Subject: Re: time warps In-Reply-To: Your message of "Thu, 08 Oct 92 14:24:15 CDT." <17654.199210081824@atlas.xylogics.com> Date: Thu, 08 Oct 92 23:03:39 PDT From: Mike O'Brien >I don't know about everyone else, but I find it strangely disconcerting >when I get people's responses to my messages before I get my own messages >echoed back. How does that happen? I don't know. It does seem strange, doesn't it? I've seen stranger things, as new messages fill in holes higher up in mailer queues. Chalk it up to sendmail. But I had another reason for this message. Is anyone here familiar with the work done on TimeWarps, started by Sowizral and Jefferson? It seems to me that in some sense the timestamps being discussed for messages are more like simulation time than real time, and the work on TimeWarps that I mentioned points out that it is not necessary in a distributed simulation to keep all the clocks in synch: synchronization is only necessary at certain points. Separate simulations can be run with separate clocks, and "rewound" as necessary. Some thought would be required, but there may at least be elements here which would relax the constraint that the entire Internet run with a common clock. Mike O'Brien From owner-big-internet@munnari.oz.au Sat Oct 10 08:45:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15306; Sat, 10 Oct 1992 08:45:45 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210092245.15306@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23453; Fri, 9 Oct 1992 16:19:32 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <11702-0@datanet.tele.fi>; Fri, 9 Oct 1992 08:18:50 +0200 To: jnc@ginger.lcs.mit.edu Cc: kwe2@bbn.com, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9210082044.AA11056@ginger.lcs.mit.edu> "jnc@ginger.lcs.mit.edu" Subject: Multiple addresses [partial mesh subnets] Date: Fri, 9 Oct 1992 08:18:50 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi This is a pretty tricky problem to handle. The thing is that if you have a partially connected mesh, is there really any simpler way to model it than a set of links? I mean, giving each router a list of the other routers it can connect to is just the same information in an isomorphic form. TANSTAAFL. in case of CLNS you don't have to give a list of addresseses of the other routers, since it is enough that you indicate that you want to run CLNS over a particular VC. then ES-IS takes care the rest, ie. finds the addresses. no time to read further to your message ... -- juha From owner-big-internet@munnari.oz.au Sat Oct 10 08:57:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15977; Sat, 10 Oct 1992 08:59:09 +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 AA23332; Fri, 9 Oct 1992 16:14:50 +1000 (from kre) To: abe@infonet.com (George Abe) Cc: jonson@server.af.mil, katz@cisco.com, big-internet@munnari.oz.au Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of Thu, 08 Oct 92 11:10:36 -0700. <9210081810.AA12301@infonet.com> Date: Fri, 09 Oct 92 16:14:36 +1000 Message-Id: <11340.718611276@munnari.oz.au> From: Robert Elz Date: Thu, 8 Oct 92 11:10:36 PDT From: abe@infonet.com (George Abe) Message-ID: <9210081810.AA12301@infonet.com> We operate in 38 countries on 5 continents and it is VERY unusual for our hop count to reach 10. 16 bit hop count fields seems a bit much. This is easy to do when you have a single body planning your links, with the ability to string new wires when things look like getting out of hand. The internet doesn't work like that, lots of organisations are installing links, and in general they're each optimising their own part, without a lot of regard to how that effects the internet as a whole - and where "optimisation" more often means "minimum cost" rather than "minimum hops" or even "best service". It can take me 5 hops to get to some other parts of my campus, without even considering parts of the University located at remote sites.... And that will get worse as more departments install their own little things and link them to each other in weird ways. kre From owner-big-internet@munnari.oz.au Sat Oct 10 09:13:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17331; Sat, 10 Oct 1992 09:13:19 +1000 (from owner-big-internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26954; Fri, 9 Oct 1992 18:39:48 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Fri, 9 Oct 92 01:37:54 -0700 Date: Fri, 9 Oct 92 01:37:54 -0700 From: Tony Li Message-Id: <9210090837.AA16715@lager.cisco.com> To: big-internet@munnari.oz.au Subject: IPv7 requirements While we're all having these wonderful technical discussions about routing architectures, EIDs, and how many hops we will take to get to Jupiter, I think that we are overlooking a key requirement which impacts the overall design: The network must autoconfigure One of the most significant problems with the Internet is that it takes the likes of you and me to run it. Can you scale this by an order of magnitude? Are you expecting every computer type in the world to become a network manager/desginer/programmer? We must work now to free ourselves later form the onerous task of maintaining the infrastructure that we're devloping. No more assigning addresses. No more configuration of routing protocols. In Tony's Ideal Protocol (TIP), there is one box that is initially configured. Everything that is then interconnected then magically "learns" and does The Right Thing. Obviously it can't quite do everything perfectly (self-installed firewalls?), but it must give a reasonable first approximation of providing connectivity. Human policies would still have to be configured in, but this would still alleviate much of the burdensome work that we now see. Tony "Forbin" Li ps. I have it on good authority that Nimrod already does this. ;-) ;-) From owner-big-internet@munnari.oz.au Sat Oct 10 09:46:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20164; Sat, 10 Oct 1992 09:46:54 +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 AA28587; Fri, 9 Oct 1992 20:00:23 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA27630; Fri, 9 Oct 1992 10:51:32 +0100 Message-Id: <199210090951.AA27630@mitsou.inria.fr> To: carlberg@cseic.saic.com (Kenneth Carlberg) Cc: yakov@watson.ibm.com, big-internet@munnari.oz.au Subject: Routing architecture (was Re: EIDs) In-Reply-To: Your message of "Thu, 08 Oct 92 14:50:58 EDT." <9210081850.AA25702@cseic.saic.com> Date: Fri, 09 Oct 92 10:51:25 -0500 From: Christian Huitema X-Mts: smtp >The three proposals work *fine* without EID because they were not >designed with EID in mind. Also, Columbia and IBM were designed, >I presume, to support movement given the *current* routing architecture. >They do not rely on proposed ideas or suppositions. So what? They work fine, full point. Means that support of mobile host is not a sufficient rationale for scrapping the current routing architecture. By the way, what do you perceive exactly as the current routing architecture? High now that Noel characterizes it a huge heap of scrap iron, but I personally use to summarize it as a 4 level hierarchy: Autonomous systems, Network, Subnet, Host With AS-gateways talking "an EGP" between themselves, Network and Subnet gateways talking "an IGP", and hosts talking an ARP + also a route discovery protocol. This vanilla hierarchical routing is complemented by two forms of source routing (loose and not so loose). This structure has proven quite successfull in the past -- we would not be talking of a "big internet" otherwise. What is wrong here? What do we want to change? Do we want to remove the concept of "AS boundary", and the associated idea that all nets within an AS share a single set of policies? Do we want to have the AS explicitely coded inside the addresses and do away with the "connected status" tables? Do we want to unify EGPs and IGPs? Do we want to remove the very idea of a "number of level" and replace it by "variable length masks"? If we do so, how do we implement broadcast addresses? Can we express "real loose" source routes, e.g. in terms of "transit through this net" instead of "transit through this host"? What is even more important: can we implement gradual changes, or do we need a revolution? Christian Huitema From owner-big-internet@munnari.oz.au Sat Oct 10 09:55:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20892; Sat, 10 Oct 1992 09:55:06 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210092355.20892@munnari.oz.au> Received: from vnet.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01924; Fri, 9 Oct 1992 23:02:11 +1000 (from rboivie@vnet.ibm.com) Received: from RHQVM21 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 1990; Fri, 09 Oct 92 09:04:02 EDT Date: Fri, 9 Oct 92 09:00:01 EDT From: rboivie@vnet.ibm.com To: big-internet@munnari.oz.au Subject: time to live This may be a dumb question but why would you want to use an absolute (universally coordinated) notion of time-of-day (with all the associated ntp and synchronous satellite stuff)? Why not just put in a value that indicates how long you would like the packet to live (in microseconds or nanoseconds or something) and have the routers along the way decrement that value based on their best estimate as to how long they held onto the packet and how much time was spent on the links in between? Or better yet, incorporate the notion of a count-up field (as has previously been suggested) so that you only have to change the routers when you decide to modify the age at which you decide to kill off packets. Rick Boivie rboivie at vnet.ibm.com ------------------------------------------------------------------------ Received: from munnari.oz.au by vnet.ibm.com (IBM VM SMTP V2R2) with TCP; Thu, 08 Oct 92 19:05:47 EDT Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06566; Fri, 9 Oct 1992 04:44:27 +1000 (from owner-big-internet) Message-Id: <9210081844.6566@munnari.oz.au> Received: from PIZZA.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29729; Fri, 9 Oct 1992 00:27:49 +1000 (from craig@BBN.COM) To: Milan Merhar Cc: big-internet@munnari.oz.au Subject: Using NTP time value instead of a Hop Limit field in SIP Date: Thu, 08 Oct 92 10:17:41 -0400 From: Craig Partridge > If the network layer needs to put an expiration date into > each message it sends, and it needs to have the current time to > do this, how does it get the current time in the first place? Milan: Not a dumb question at all. On a LAN it should be easy -- if you have a timeserver multicasting the time, then just listen briefly till you hear a time message, then set your clock to that value. The value will be imperfect, but given that we're looking at tolerances of 10s of ms, it will be accurate enough. What happens on a power hit to your site is an interesting question -- start up probably takes a while. For WANs, I'm less sure. I believe it is feasible, but requires more work. Craig From owner-big-internet@munnari.oz.au Sat Oct 10 10:08:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22543; Sat, 10 Oct 1992 10:08:22 +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 AA01996; Fri, 9 Oct 1992 23:08:08 +1000 (from jdemarco@ftp.com) Received: by ftp.com id AA24987; Fri, 9 Oct 92 09:05:50 -0400 Date: Fri, 9 Oct 92 09:05:50 -0400 From: jdemarco@ftp.com (Jim DeMarco) Message-Id: <9210091305.AA24987@ftp.com> To: gmalkin@xylogics.com Cc: Big-Internet@munnari.oz.au In-Reply-To: Gary Scott Malkin's message of Thu, 8 Oct 1992 14:24:15 -0400 <17654.199210081824@atlas.xylogics.com> Subject: time warps Reply-To: jdemarco@ftp.com >I don't know about everyone else, but I find it strangely disconcerting >when I get people's responses to my messages before I get my own messages >echoed back. How does that happen? I use Clairvoyant Software's ESP/IP mail package. Rather neat! Actually, it may have something to do with whether you are getting answers directly or via a mail exploder. I've seen the same symptoms myself. --Jim From owner-big-internet@munnari.oz.au Sat Oct 10 10:06:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22319; Sat, 10 Oct 1992 10:06:51 +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 AA01928; Fri, 9 Oct 1992 23:02:15 +1000 (from craig@BBN.COM) Received: from PIZZA.BBN.COM by shark.mel.dit.csiro.au with SMTP id AA25035 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 9 Oct 1992 23:02:17 +1000 Message-Id: <199210091302.AA25035@shark.mel.dit.csiro.au> To: Bob Hinden Cc: Big-Internet@munnari.oz.au Subject: Re: Hop Limit field in SIP Date: Fri, 09 Oct 92 08:51:09 -0400 From: Craig Partridge > Also, in my opinion the philosophy behind SIP was to make it as simple as > possible. I think it is unwise to try to make it deal with every > possibility we can imagine, but which are unlikely to occur in practice. > There is already another well known protocol which was designed for the > general case. Bob: I agreed with you until this paragraph. My view is that we ought to design SIP (and anything else) to work in all cases, but accept it may work poorly in some off-beat cases. I.e., I'd be unhappy if SIP prohibited us from implementing some functionality (like connectivity from the Moon), but I'm not bothered if we say, "you have to architect the network to have a max of 255 hops," even though this may inconvenience a few folks. Craig From owner-big-internet@munnari.oz.au Sat Oct 10 10:09:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22590; Sat, 10 Oct 1992 10:09:41 +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 AA02798; Fri, 9 Oct 1992 23:49:44 +1000 (from jdemarco@ftp.com) Received: by ftp.com id AA26238; Fri, 9 Oct 92 09:49:07 -0400 Date: Fri, 9 Oct 92 09:49:07 -0400 From: jdemarco@ftp.com (Jim DeMarco) Message-Id: <9210091349.AA26238@ftp.com> To: big-internet@munnari.oz.au Subject: Route Tracing and Hop Limit field in SIP Reply-To: jdemarco@ftp.com Well, having read all the tracing/hop limit mail I've gotten so far, I am pretty convinced that a large TTL/hopcount would have some pretty negative consequences. In no particular order, a large TTL/HC 1) will take up more header space This was probably the first and the most obvious point mentioned (but also the weakest). 2) may *encourage* rather long routes Some routing mechanisms might favor lots of fast hops across many routers over a slightly slower but more direct route. This puts a bigger burden on [many] fast routers and under-uses slower ones. A larger TTL/HC poses all sorts of problems (e.g. dealing with ridiculously long - though fast! - routes) A high TTL/HC is analogous to a computer chess program that can look more "moves" ahead: a lot of CPU time would get spent just to calculate the "best" (fastest?) route. I suspect that there is likely to be some debate over whether this is really a problem. 3) could result in ineffective route tracing A consequence of 2 is that current route tracing mechanisms don't seem to scale well. The traceroute strategy (send ICMP echo requests with ever-increasing TTL) would work, but slows down quite a bit after a few dozen hops (in my experience), especially if packets get lost. Other strategies (involving recording the route) result in ever-increasing packets which could be a lose at some point. I really think that if we want to allow more than 255 hops, we had better have a way of determining what those hops taken are (for network debugging and for network tuning). My experience is that route tracing is most useful in cases where the route happens to be *long* -- just the kind of case a large TTL/HC would encourage. --Jim From owner-big-internet@munnari.oz.au Sat Oct 10 10:23:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23262; Sat, 10 Oct 1992 10:23:26 +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 AA04529; Sat, 10 Oct 1992 00:49:19 +1000 (from kasten@ftp.com) Received: by ftp.com id AA28022; Fri, 9 Oct 92 10:48:58 -0400 Date: Fri, 9 Oct 92 10:48:58 -0400 Message-Id: <9210091448.AA28022@ftp.com> To: jnc@ginger.lcs.mit.edu Subject: Re: EIDs From: kasten@ftp.com (Frank Kastenholz) Cc: barrett@daisy.ee.und.ac.za, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu This discussion is sort of heading in the direction of splitting the network layer into 2 sub-layers. One would be the "routing" or "hop-by-hop" sub-layer which contains topological addressing information, perhaps policy info and the like. Information which is required to get packets through the network. The second is sort of an "end-to-end" sub-layer which identifies the originator and receiver of the packet, contains information that is really only of interest to those two places and so on (protocol field, etc). This dovetails rather neatly with the checksum discussion we had earlier. Perhaps the "routing sub-layer" would not be checksum protected, allowing routers to diddle packets rather efficiently. The "end-to-end sub-layer" would be protected since this is the stuff that we seemed to want protected (at least that is my recollection of the sense of the earlier discussion). Just some observations from a brain that was subjected to too many cheap Mai Tais last night :-) > Perhaps the session layer is the right place for this new "identification > layer". An EID could live at the the session layer, and if the entity > identified by an EID migrates to a different host, or the host moves to > a different network-layer address, then the session layer would have to > close the old transport-layer connection and open a new one. > > An interesting approach. I will refrain from asking "what session > layer", since that's not an acceptable answer! > I still happen to think that here in the future not all internetwork > packets will carry the addresses of the endpoint, since addresses are likely > to become long and complex things (like DNS names are now). (This will go well > with flows, which a lot of the resource architecture types seem to like.) > EID's are the obvious things to put in their place. > Also, there are things the EID's do for you, like making multi-homing, > and multiple parallel interfaces for throughput reasons work, and they > wouldn't work anywhere near as well at this if they were at the session layer. > > Noel -- frank kastenholz From owner-big-internet@munnari.oz.au Sat Oct 10 10:35:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23559; Sat, 10 Oct 1992 10:35:24 +1000 (from owner-big-internet) Return-Path: Received: from [160.104.1.1] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08921; Sat, 10 Oct 1992 05:21:49 +1000 (from jim@tadpole.com) Received: by tadpole.tadpole.com (4.1/SMI-4.1) id AA12916; Fri, 9 Oct 92 14:21:00 CDT Date: Fri, 9 Oct 92 14:21:00 CDT From: jim@tadpole.com (Jim Thompson) Message-Id: <9210091421.ZM12914@tadpole> In-Reply-To: Zheng Wang "IP option test (long)" (Oct 8, 6:43pm) References: <9210090624.23571@munnari.oz.au> X-Mailer: Z-Mail (2.1b.27 9/21/92) To: Zheng Wang , big-internet@munnari.oz.au Subject: Re: IP option test (long) Cc: ji@cs.columbia.edu Zheng, Source routing is *very* broken in today's Internet. John Ioannidis (ji@cs.columbia.edu) performed an experiment only a few months ago that shows just how badly source routing is broken. VMS, HP-UX, SunOS, BSD, they're all broken with regard to source routing, some worse than others. (Hint, try UDP port 7, instead of TCP port 7.) Note as well that there is movement afoot to use IP encapsulation instead of source routing for IP multicast 'tunnels'. Several reasons, including efficiency. Perhaps John will respond with the whole of his report. Jim From owner-big-internet@munnari.oz.au Sat Oct 10 10:47:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24189; Sat, 10 Oct 1992 10:48:03 +1000 (from owner-big-internet) Return-Path: Received: from [131.125.10.3] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05057; Sat, 10 Oct 1992 01:20:00 +1000 (from @TURBO.kean.edu:akc@akc.com) Received: from TURBO.Kean.EDU by squirt.kean.edu (4.1/SMI-4.1) id AA01968; Fri, 9 Oct 92 11:26:13 EDT Message-Id: <9210091526.AA01968@squirt.kean.edu> Received: from POOPS.Kean.EDU by TURBO.Kean.EDU; 09 Oct 92 11:21:16 EST To: big-internet@munnari.oz.au Subject: Muli IP addresses on one interface. From: Al@AKC.COM Reply-To: Al@AKC.COM Date: 09 Oct 92 11:21:16 EST -> i can have a host that at the same time belongs to many routing domains -> (and thus has many addresses) and it can have only one, eg. Ethernet -> interface through which all packets arrive. -> ->So? It has one interface, which has many addresses. What's the problem? - -Since when can one interface have multiple addresses? Doesn't every interface -have a have a unique address (for every (sub)network it belongs to) which -uniquely identifies it to another host. In the system I work with which is -4.3BSD-derived, every interface must have a unique IP address. If that host -wishes to act as a gateway, it must have multiple interfaces, each of which -has a uniqe IP address. - -Mark Come now people, Even a Cisco router may have more than one IP address on an interface. If an interface has more than one (on a cisco) it is called a secondary. I have hosts that have up to five addresses (one interface) the IP address is software based the (Ethernet HARDWARE address is interface based.... -al From owner-big-internet@munnari.oz.au Sat Oct 10 11:09:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25485; Sat, 10 Oct 1992 11:09:24 +1000 (from owner-big-internet) Return-Path: Received: from regal.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05039; Sat, 10 Oct 1992 01:18:12 +1000 (from dkatz@cisco.com) Received: by regal.cisco.com; Fri, 9 Oct 92 07:57:20 -0700 Date: Fri, 9 Oct 92 07:57:20 -0700 From: Dave Katz Message-Id: <9210091457.AA09961@regal.cisco.com> To: Z.Wang@cs.ucl.ac.uk Cc: big-internet@munnari.oz.au In-Reply-To: Zheng Wang's message of Thu, 08 Oct 92 18:43:43 +0100 <9210090624.23571@munnari.oz.au> Subject: IP option test (long) Date: Thu, 08 Oct 92 18:43:43 +0100 From: Zheng Wang A number of recent proposals (e.g. EIP, IBM mobile IP and Sony mobile IP) make use of the IP options to add new features within the current IP header format. Some people have expressed following concerns as to: 1) whether the presence of IP option may have visible performance penalty, and 2) whether current IP routers and hosts in the Internet can deal with unknow IP options properly (i.e. ignoring unknown IP options silently as required by RFC-1122 and router requirement draft). First, we notice that IP multicast uses the source route option for tunnelling. IP multicast has been widely used for audio and video conferencing over the Internet, and no performance problems have been reported. There is most decidedly a performance penalty for options, at least in cisco routers and in the NSFNET backbone (and most others, I'm sure). Significant performance problems were triggered in some places in the internet due to the audio/video multicasts during the last IETF meeting. The latency of a single ping packet would probably not be visibly changed (especially when compared to other latency factors) but the aggregate switching capacity is far lower (by some number of orders of magnitude >= 1) when options are present. From owner-big-internet@munnari.oz.au Sat Oct 10 11:26:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26543; Sat, 10 Oct 1992 11:26:40 +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 AA04926; Sat, 10 Oct 1992 01:10:51 +1000 (from kasten@ftp.com) Received: from ftp.com (babyoil.ftp.com) by shark.mel.dit.csiro.au with SMTP id AA25891 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 10 Oct 1992 01:09:37 +1000 Received: by ftp.com id AA28022; Fri, 9 Oct 92 10:48:58 -0400 Date: Fri, 9 Oct 92 10:48:58 -0400 Message-Id: <9210091448.AA28022@ftp.com> To: jnc@ginger.lcs.mit.edu Subject: Re: EIDs From: kasten@ftp.com (Frank Kastenholz) Cc: barrett@daisy.ee.und.ac.za, big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu This discussion is sort of heading in the direction of splitting the network layer into 2 sub-layers. One would be the "routing" or "hop-by-hop" sub-layer which contains topological addressing information, perhaps policy info and the like. Information which is required to get packets through the network. The second is sort of an "end-to-end" sub-layer which identifies the originator and receiver of the packet, contains information that is really only of interest to those two places and so on (protocol field, etc). This dovetails rather neatly with the checksum discussion we had earlier. Perhaps the "routing sub-layer" would not be checksum protected, allowing routers to diddle packets rather efficiently. The "end-to-end sub-layer" would be protected since this is the stuff that we seemed to want protected (at least that is my recollection of the sense of the earlier discussion). Just some observations from a brain that was subjected to too many cheap Mai Tais last night :-) > Perhaps the session layer is the right place for this new "identification > layer". An EID could live at the the session layer, and if the entity > identified by an EID migrates to a different host, or the host moves to > a different network-layer address, then the session layer would have to > close the old transport-layer connection and open a new one. > > An interesting approach. I will refrain from asking "what session > layer", since that's not an acceptable answer! > I still happen to think that here in the future not all internetwork > packets will carry the addresses of the endpoint, since addresses are likely > to become long and complex things (like DNS names are now). (This will go well > with flows, which a lot of the resource architecture types seem to like.) > EID's are the obvious things to put in their place. > Also, there are things the EID's do for you, like making multi-homing, > and multiple parallel interfaces for throughput reasons work, and they > wouldn't work anywhere near as well at this if they were at the session layer. > > Noel -- frank kastenholz From owner-big-internet@munnari.oz.au Sat Oct 10 11:39:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27911; Sat, 10 Oct 1992 11:39:28 +1000 (from owner-big-internet) Return-Path: Received: from [16.1.240.16] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05089; Sat, 10 Oct 1992 01:24:09 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA29542; Fri, 9 Oct 92 08:22:30 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA15342; Fri, 9 Oct 1992 11:22:23 -0400 To: Zheng Wang Cc: big-internet@munnari.oz.au Subject: Re: IP option test (long) In-Reply-To: <9210090624.23571@munnari.oz.au> References: <9210090624.23571@munnari.oz.au> X-Mailer: Poste 2.0 From: David Oran Date: Fri, 9 Oct 92 11:22:23 -0400 Message-Id: <921009112223.13756@sneezy.lkg.dec.com> Encoding: 35 TEXT, 6 TEXT SIGNATURE > > A number of recent proposals (e.g. EIP, IBM mobile IP and Sony mobile IP) > make use of the IP options to add new features within the current IP > header format. > > Some people have expressed following concerns as to: > > 1) whether the presence of IP option may have visible performance penalty, and > 2) whether current IP routers and hosts in the Internet can deal with > unknow IP options properly (i.e. ignoring unknown IP options > silently as required by RFC-1122 and router requirement draft). > By measuring single streams number, you beg the question of how much of the routers' resources are being eaten by the packets with options. As long as the net is primarily bandwidth-limited, you will see essentially no throughput differences due to the presence of IP options (except the second ordr effect of the extra bits in the header). I think most peoples concerns were predicated on a scheme in which the majority of the packets traversing backbone routers had options in them, causing the backbone to become switching rather than bandwidth limited. I certainly appreciate the numbers you've generated, since they do show the small magnitude of the second order effects, but unfortunately I don't think they generate a traffic matrix which could either prove or disprove the purported first-order effects. Dave. P.S. one question I have about your test is whether it uses a defined but potentially un-implemented IP option, or an undefined IP option. It is possible that this would elicit different behavior in the routers. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-big-internet@munnari.oz.au Sat Oct 10 11:51:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28839; Sat, 10 Oct 1992 11:51:41 +1000 (from owner-big-internet) Return-Path: Received: from gateway.sequent.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AB06447; Sat, 10 Oct 1992 02:47:06 +1000 (from mckenney@sequent.com) Received: from eng3.sequent.com by gateway.sequent.com (5.61/1.34) id AA21295; Fri, 9 Oct 92 09:44:38 -0700 Received: by eng3.sequent.com (5.65/1.34) id AA22848; Fri, 9 Oct 92 09:45:36 -0700 From: Paul E. McKenney Message-Id: <9210091645.AA22848@eng3.sequent.com> Subject: Re: IP option test (long) To: Z.Wang@cs.ucl.ac.uk (Zheng Wang) Date: Fri, 9 Oct 92 9:45:35 PDT Cc: big-internet@munnari.oz.au Priority: normal In-Reply-To: <9210090624.23571@munnari.oz.au>; from "Zheng Wang" at Oct 08, 92 6:43 pm X-Mailer: ELM [version 2.2 CRG PL14c] Zheng, Your latency results for IP options are indeed extensive and encouraging! However, isn't latency over WANs only part of the story here? Suppose that a given router has 80-microsecond latency for a non-option packet, but has a one-millisecond latency for optioned packets. The effect on latency will be imperceptible in your test results (you would need a -lot- of samples on the same path for the difference to be statistically significant), but the resulting drop in packet throughput (from 14,000 pps to 1,000 pps) might well render the router (and thus the IP option) useless for many relatively common LAN environments. Would it be possible for you to repeat your tests through a local router and to accurately measure the latency (e.g., by use of an two-port protocol analyzer, a logic analyzer, or an oscilloscope)? Thanx, Paul From owner-big-internet@munnari.oz.au Sat Oct 10 12:04:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00349; Sat, 10 Oct 1992 12:04:57 +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 AA06836; Sat, 10 Oct 1992 03:12:26 +1000 (from news@cherokee.advtech.uswest.com) Received: from cherokee.advtech.uswest.com by shark.mel.dit.csiro.au with SMTP id AA26607 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 10 Oct 1992 03:11:19 +1000 Received: by cherokee.advtech.uswest.com id AA09618 (5.65c/IDA-1.4.4 for big-internet@munnari.oz.au); Fri, 9 Oct 1992 11:08:25 -0600 Date: Fri, 9 Oct 1992 11:08:25 -0600 From: Radio Free Boulder Message-Id: <199210091708.AA09618@cherokee.advtech.uswest.com> To: big-internet@munnari.oz.au Newsgroups: info.big-internet Path: huntting From: huntting@advtech.uswest.com (Brad Huntting) Subject: Re: Addresses Message-ID: <1992Oct9.170822.9573@advtech.uswest.com> Sender: news@advtech.uswest.com (Radio Free Boulder) Nntp-Posting-Host: futureworld.advtech.uswest.com Organization: U S WEST Advanced Technologies References: <9210081312.AA07814@dino.alias.com> Date: Fri, 9 Oct 1992 17:08:22 GMT In article <9210081312.AA07814@dino.alias.com> mandrews@alias.com (Mark Andrews) writes: >Since when can one interface have multiple addresses? Doesn't every interface >have a have a unique address (for every (sub)network it belongs to) which >uniquely identifies it to another host. In the system I work with which is >4.3BSD-derived, every interface must have a unique IP address. If that host >wishes to act as a gateway, it must have multiple interfaces, each of which >has a uniqe IP address. 4.4BSD (including BSD386 from BSDi) allows you to have "alias" addresses on an interface. Here is a "netstat -in" from my BSD386 machine misc.glarp.com. I have two slip connections I regularly use, so when I dial up to one, I alias the other to the loopback interface. It works quite well. If for some reason a process on my machine tries to open it's own address and the ip number it tries is not the one being used for SLIP the connection will still work. Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll sl0 296 5674 0 6643 0 0 sl0 296 128.138 128.138.240.101 5674 0 6643 0 0 lo0 1536 356 0 356 0 0 lo0 1536 127 127.0.0.1 356 0 356 0 0 lo0 1536 (7)0.0.1.14.47.0.5.80.ff.ff.0.0.0.a.2.0.3.ab.ab.ab.ab.ab.ab.1 356 0 356 0 0 lo0 1536 130.13 130.13.16.111 356 0 356 0 0 brad From owner-big-internet@munnari.oz.au Sat Oct 10 12:46:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08019; Sat, 10 Oct 1992 12:46:36 +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 AA07859; Sat, 10 Oct 1992 04:29:56 +1000 (from kre@cs.mu.oz.au) Received: from mulga.cs.mu.OZ.AU by shark.mel.dit.csiro.au with SMTP id AA26528 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 10 Oct 1992 02:57:03 +1000 Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.64+1.3.1+0.50); id AA14456 Sat, 10 Oct 1992 02:53:41 +1000 (from kre) To: Gary Scott Malkin Cc: Big-Internet@munnari.oz.au From: Big-Internet-Request@munnari.OZ.AU Subject: Re: time warps In-Reply-To: Your message of Thu, 08 Oct 92 14:24:15 -0400. <17654.199210081824@atlas.xylogics.com> Date: Sat, 10 Oct 92 02:52:15 +1000 Message-Id: <11484.718649535@munnari.oz.au> Sender: kre@cs.mu.oz.au Date: Thu, 8 Oct 1992 14:24:15 -0400 From: Gary Scott Malkin Message-ID: <17654.199210081824@atlas.xylogics.com> I don't know about everyone else, but I find it strangely disconcerting when I get people's responses to my messages before I get my own messages echoed back. How does that happen? This is actually quite simple - the list is processed sequentially (single threaded) - when you send to it your article is sent to the list in rough order of when recipients were first added. It will take a while for some people to receive the message - when all is working well it typically takes a couple of hours (right at the minute it looks like its likely to take a couple of days ... no idea when you'll get this message via the list!) However, others get the message within a few minutes - and some of those like to reply very quickly - usually they will reply directly to you, as well as to the list, the direct reply to you should be delivered close to instantly, getting to you before the process sending your original message gets around to sending you your copy. While I'm here - its also worth saying that its probably a good idea for almost everyone to check the archives from time to time. Mail bounces occasionally from the most unusual places, for the most unusual reasons, I'm sure there are some people who have never missed a message (I hope I am one, but then if I miss it, I get to see the bounce message anyway...) but there are lots of you who occasionally miss one - don't assume your mailer is perfect, it probably isn't. kre From owner-big-internet@munnari.oz.au Sat Oct 10 13:08:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12757; Sat, 10 Oct 1992 13:08:38 +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 AA08179; Sat, 10 Oct 1992 04:48:10 +1000 (from dee@ranger.enet.dec.com) Received: from inet-gw-2.pa.dec.com by shark.mel.dit.csiro.au with SMTP id AA25180 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 9 Oct 1992 23:30:22 +1000 Received: by inet-gw-2.pa.dec.com; id AA18944; Fri, 9 Oct 92 06:27:29 -0700 Received: by us1rmc.bb.dec.com; id AA08412; Fri, 9 Oct 92 09:24:55 -0400 Message-Id: <9210091324.AA08412@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Fri, 9 Oct 92 09:24:56 EDT Date: Fri, 9 Oct 92 09:24:56 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 09-Oct-1992 0927" To: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au Subject: RE: Tracing paths -------------- From: US1RMC::"kre@munnari.oz.au" "Robert Elz" 8-OCT-1992 17:44 To: Big-Internet@munnari.oz.au CC: Subj: Tracing paths [stuff about SNMP or a special IMCP not doing quite the right thing which I agree with] I think the answer here, is that traceroute elicits a response from each router along the path to the destination, as the packet is forwarded. That the packet in question isn't actually forwarded, but is dropped instead is the accident, and brilliance, of the implementation, rather than the idea. So, would it be useful if we just created an option (a "router" option for those protocols that will separate them) that causes an ICMP "trace" message to be returned to the originator of a packet each time the packet passes through a router. Recipient hosts could either do the same, or traceroute could work just by sending an ICMP echo and then watching for the echo response indicating the packet had arrived. == But if every router generated a trace message, you could have trouble with == congestion due to the number of messages. Under bad conditions, the way the == current traceroute works seems just right. kre -------------- > So, would it be useful if we just created an option (a "router" > option for those protocols that will separate them) that causes > an ICMP "trace" message to be returned to the originator of > a packet each time the packet passes through a router. > Recipient hosts could either do the same, or traceroute could > work just by sending an ICMP echo and then watching for the > echo response indicating the packet had arrived. It should be a separate new-ICMP message. If it is an option in any packet then every packet has to be checked to see if the option is set and then the proper "saw it" message generated etc etc. == I don't understand this. Every packet always has to be checked by every == router to see if there are any router options present. If there are, then == the options have to be scanned to see if the router has to do anything == because of them. This would not be changed by adding an option, though I'm == not convinced that is the way to go. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Sat Oct 10 13:10:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12813; Sat, 10 Oct 1992 13:10:46 +1000 (from owner-Big-Internet) Return-Path: Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12806; Sat, 10 Oct 1992 13:10:38 +1000 (from news@ux3.cso.uiuc.edu) Received: from ux3.cso.uiuc.edu by ux1.cso.uiuc.edu with SMTP id AA07611 (5.67a8/IDA-1.5 for ); Fri, 9 Oct 1992 22:10:19 -0500 Received: by ux3.cso.uiuc.edu id AA27047 (5.67a/IDA-1.5 for info-big-internet@ux1.cso.uiuc.edu); Sat, 10 Oct 1992 03:10:37 GMT Newsgroups: info.big-internet Path: uxa.cso.uiuc.edu!msg7038 From: msg7038@uxa.cso.uiuc.edu (Michalis Syrimis) Subject: Re: time to live References: <9210092355.20892@munnari.oz.au> Message-Id: Sender: usenet@ux3.cso.uiuc.edu (Net Noise owner) Organization: University of Illinois at Urbana Date: Sat, 10 Oct 1992 03:10:32 GMT Lines: 58 Apparently-To: info-big-internet@ux1.cso.uiuc.edu rboivie@vnet.ibm.com writes: _Just keeding >This may be a dumb question but why would you want to use an absolute >(universally coordinated) notion of time-of-day (with all the associated >ntp and synchronous satellite stuff)? >Why not just put in a value that indicates how long you would like the packet >to live (in microseconds or nanoseconds or something) and have the routers >along the way decrement that value based on their best estimate as to how >long they held onto the packet and how much time was spent on the links >in between? >Or better yet, incorporate the notion of a count-up field (as has previously >been suggested) so that you only have to change the routers when you >decide to modify the age at which you decide to kill off packets. >Rick Boivie >rboivie at vnet.ibm.com >------------------------------------------------------------------------ >Received: from munnari.oz.au by vnet.ibm.com (IBM VM SMTP V2R2) with TCP; > Thu, 08 Oct 92 19:05:47 EDT >Received: by munnari.oz.au (5.83--+1.3.1+0.50) > id AA06566; Fri, 9 Oct 1992 04:44:27 +1000 (from owner-big-internet) >Message-Id: <9210081844.6566@munnari.oz.au> >Received: from PIZZA.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) > id AA29729; Fri, 9 Oct 1992 00:27:49 +1000 (from craig@BBN.COM) >To: Milan Merhar >Cc: big-internet@munnari.oz.au >Subject: Using NTP time value instead of a Hop Limit field in SIP >Date: Thu, 08 Oct 92 10:17:41 -0400 >From: Craig Partridge >> If the network layer needs to put an expiration date into >> each message it sends, and it needs to have the current time to >> do this, how does it get the current time in the first place? >Milan: > Not a dumb question at all. > On a LAN it should be easy -- if you have a timeserver multicasting >the time, then just listen briefly till you hear a time message, then >set your clock to that value. The value will be imperfect, but given that >we're looking at tolerances of 10s of ms, it will be accurate enough. > What happens on a power hit to your site is an interesting question -- >start up probably takes a while. > For WANs, I'm less sure. I believe it is feasible, but requires more >work. >Craig -- Michalis Syrimis University of Illinois Urbana-Champaign From owner-Big-Internet@munnari.oz.au Sat Oct 10 13:35:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17121; Sat, 10 Oct 1992 13:35:45 +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 AA17086; Sat, 10 Oct 1992 13:35:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20849; Fri, 9 Oct 92 23:35:25 -0400 Date: Fri, 9 Oct 92 23:35:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210100335.AA20849@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, tli@cisco.com Subject: Re: IPv7 requirements Cc: jnc@ginger.lcs.mit.edu I have it on good authority that Nimrod already does this. I wish! I agree with you 100% on the autoconfiguration front, though. I've been aware of the acute need for auto-configuration for some some now. If you look at the Area Plan for the Internet Area which was in the IESG "Internet Evolution Plan for the IETF" which came out as an I-D in July 91, one of the three main goals listed (along with a new addressing/routing architecture and a resource management architecture) was real autoconfiguration (in section 6.2.3, I think). In thinking about Nimrod, I did give some thought to autoconfiguration, but I must say it's a long way from complete. This is why there's so much emphasis on physical topology in the addressing aggregation (to make it easier to automate, if it's principally based on the real topology, and not administrative input), and also why some algorithms (like the aggregation algorithm) aren't part of the spec, but rather are outside the spec, to allow manual tuning of automatic algorithms, and to allow better automatic algorithms to be phased in, etc, etc. Noel From owner-big-internet@munnari.oz.au Sat Oct 10 13:39:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18059; Sat, 10 Oct 1992 13:39:51 +1000 (from owner-big-internet) Return-Path: Received: from [132.245.33.7] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14807; Sat, 10 Oct 1992 08:38:17 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA27682 (5.65c/UK-2.1-921001); Fri, 9 Oct 1992 18:39:27 -0400 From: Gary Scott Malkin Date: Fri, 9 Oct 1992 18:39:27 -0400 Message-Id: <27682.199210092239@atlas.xylogics.com> To: kasten@ftp.com Cc: Big-Internet@munnari.oz.au In-Reply-To: (Frank Kastenholz's message of Fri, 9 Oct 92 12:44:13 -0400 <9210091644.AA00892@ftp.com> Subject: Tracing paths > one of the parts of the new-ip effort is to create the needed mibs. I knew it wouldn't be too long before someone said MIB :-) ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Sat Oct 10 13:42:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18604; Sat, 10 Oct 1992 13:42:14 +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 AA18578; Sat, 10 Oct 1992 13:42:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA20924; Fri, 9 Oct 92 23:42:02 -0400 Date: Fri, 9 Oct 92 23:42:02 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210100342.AA20924@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: "The more things change" department.. Cc: info-explorer@ai.mit.edu "An important scientific innovation rarely makes its way by gradually winning over and converting its opponents; it rarely happens that Saul becomes Paul. What does happen is that its opponents gradually die out and that the growing generation is familiarized with the idea from the beginning." -- Max Planck From owner-big-internet@munnari.oz.au Sat Oct 10 14:30:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26492; Sat, 10 Oct 1992 14:30:31 +1000 (from owner-big-internet) Return-Path: Received: from SAFFRON.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17003; Sat, 10 Oct 1992 09:07:01 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA12655; Fri, 9 Oct 92 16:06:19 PDT Date: Fri, 9 Oct 92 16:06:19 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9210092306.AA12655@saffron.acc.com> To: trewitt@pa.dec.com Subject: Re: Tracing paths Cc: Big-Internet@munnari.oz.au, kasten@ftp.com, kre@munnari.oz.au >> 1) Policy decisions. e.g. We don't pass type FOO packets from subnet X. >> This can screw up a traceroute function, as well. >> 2) TOS routing. The ipRouteTable doesn't contain any information about >> TOS. Even if it did, I'm not sure that I could write the code >> that emulates a router's decisions (or bugs) about the mapping >> from packet type/TOS/whatever to "preferred" route. >> 3) Multipath routing. The current ipRouteTable doesn't contain any >> information about this. (MIB-II did, at one point, but it got >> taken out in a decision that I still curse Marshall for.) >> I haven't looked closely at the new ipForwarding table to see what of >> these problems might have been addressed, but that isn't my point. My >> point is that you really need to see what will happen to a REAL PACKET. You might take the time to do so; I think you will be pleasantly surprized. It keeps track of destination, policy (treating type of service as a special case of policy), routing protocol making the decision, and next hop. The last gives you multipath routing. Having said the which, I *also* agree that traceroute is a useful tool, and that in some cases there's nothing quite like a live test. The ICMP Record Route feature, if implemented, should replicate packets when multiple decisions could be made, and note in each copy the reasons it might choose that route as well as the address of its interface. In theory, if there are 20 ways to get from here to there, with varying policy and multipath considerations, you would want the originator to get 20 responses to his single "ping", each saying "and if it's TOS=foo, originator=bozo, and destination=clown, your traffic might go through routers (...)". >> An SNMP capability that I'd like to see is an SNMP table that is >> indexed by destination IP address, that would return the answer to the >> question "how would route to this address?" No get-next on this table, >> though. I would claim that the above can be implemented on the SNMP NMS workstation. It inquires of the ipForwardingTable of the first router in question, and iteratively dumps the ipForwardTables of the next hop routers until it has all the route information. This table may contain pointers to other MIB tables to say things like "BGP says policy 87 takes effect", which probably is something like "if it's from neighbor and going to next hop is "; these would want to be dumped and understood. Fred From owner-big-internet@munnari.oz.au Sat Oct 10 18:22:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04798; Sat, 10 Oct 1992 18:22:34 +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 AA04491; Sat, 10 Oct 1992 00:46:52 +1000 (from peter@goshawk.lanl.gov) Received: from p.lanl.gov by shark.mel.dit.csiro.au with SMTP id AA25678 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 10 Oct 1992 00:25:38 +1000 Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA11787; Fri, 9 Oct 92 08:22:46 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA09428; Fri, 9 Oct 92 08:22:45 MDT Message-Id: <9210091422.AA09428@goshawk.lanl.gov> To: big-internet@munnari.oz.au Subject: Re: IESG Deliberations [criteria] Date: Fri, 09 Oct 92 08:22:44 MST From: peter@goshawk.lanl.gov I apologize from stirring up this pot and then not tending to it (but if you had my travel schedule you would ...) Several people have written me privately asking me why I would want the formation of a working group to formulate criteria over and above the work the IESG has already done. I firmly subscribe to the notion that any criteria which is going to be attributed to "the Internet community" should come from the community. I find that the trade magazines, journalists, lay public and many people who are extremely interested in the future of the Internet do not understand the organization and interactions of the various organizations (IAB, IESG, IETF, etc.). Consequently they often incorrectly attribute things to one organization or the other, or out of exasperation simply label a statement or opinion as coming from the "Internet community". I believe the IETF is _the_ organized body which is best positioned to represent the interests of the Internet community, especially interests which are centered on technical issues. We have a formalism for generating outputs from the IETF community which is the IETF Working Group. If the criteria for the future of the Internet is to come from the community in general as many (Vint, Phill, Bob H., etc.) have stated, then this should be done within the formalism we have. It is hard to imagine something carrying more weight than a document coming out of an IETF working group. It is being argued that in the interest of time, or for the lack of need for such formality, we can not wait for an IETF WG. To the contrary, we have many people arguing that the IAB moved to quickly and without engaging the IETF community. We should learn from the last 6 months and not repeat the experience with a different body, the IESG. In closing, the criteria we establish for the future of the Internet will be widely discussed in communities other than the small group which actively participates on Big-Internet and in the more specialized working groups and mailing lists. These people deserve to be given a criteria list which is as representative as possible of the interests of the Internet community at large. I know of no better way to do that then to get an IETF working group formed and to report out. We have seen the results of other approaches, and we should go back to the formula which has carried the IETF this far. I apologize for not being clear in my previous comments and hope this identifies my position on this, very important, subject. With regards, peter From owner-big-internet@munnari.oz.au Sat Oct 10 18:47:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05744; Sat, 10 Oct 1992 18:47:11 +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 AA07888; Sat, 10 Oct 1992 04:33:48 +1000 (from solensky@andr.ub.com) Received: from ub-gate.UB.com by shark.mel.dit.csiro.au with SMTP id AA26263 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 10 Oct 1992 02:19:20 +1000 Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA28251; Fri, 9 Oct 92 08:47:37 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA09697; Fri, 9 Oct 92 11:47:36 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA28878; Fri, 9 Oct 92 11:45:43 EDT Date: Fri, 9 Oct 92 11:45:43 EDT From: Frank T. Solensky Message-Id: <9210091545.AA28878@fenway.andr.UB.com> To: Big-Internet@munnari.oz.au, gmalkin@xylogics.com Subject: Re: time warps >From owner-big-internet@munnari.oz.au Fri Oct 9 04:43:43 1992 >Return-Path: >Received: from sunny.andr.UB.com (sunny.andr.UB.com) by fenway.andr.UB.com >(4.1/SMI-4.1) > id AA28594; Fri, 9 Oct 92 04:43:42 EDT >Received: from ub-gate.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) > id AA09229; Fri, 9 Oct 92 04:45:31 EDT >Received: from munnari.oz.au by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) > id AA15531; Fri, 9 Oct 92 01:44:55 PDT >Received: by munnari.oz.au (5.83--+1.3.1+0.50) > id AA17303; Fri, 9 Oct 1992 13:12:04 +1000 (from owner-big-internet) >Received: from atlas.xylogics.com by munnari.oz.au with SMTP >(5.83--+1.3.1+0.50) > id AA06126; Fri, 9 Oct 1992 04:23:19 +1000 (from gmalkin@xylogics.com) >Received: by atlas.xylogics.com id AA17654 (5.65c/UK-2.1-921001); > Thu, 8 Oct 1992 14:24:15 -0400 >From: Gary Scott Malkin >Date: Thu, 8 Oct 1992 14:24:15 -0400 >To: Big-Internet@munnari.oz.au >Subject: time warps > >I don't know about everyone else, but I find it strangely disconcerting >when I get people's responses to my messages before I get my own messages >echoed back. How does that happen? Gary -- I've been wondering about this also.. My guess is that the mail exploder works by: while ((new_recip = getnext()) != EOF) { /usr/lib/sendmail new_recip Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05766; Sat, 10 Oct 1992 18:48:28 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Sat, 10 Oct 92 01:48:12 -0700 Date: Sat, 10 Oct 92 01:48:12 -0700 From: Tony Li Message-Id: <9210100848.AA08154@lager.cisco.com> To: Big-Internet@munnari.oz.au, kasten@ftp.com, kre@munnari.oz.au Cc: fbaker@acc.com (Fred Baker), trewitt@pa.dec.com Subject: Re: Tracing paths Gentlepeople, >> 1) Policy decisions. e.g. We don't pass type FOO packets from subnet X. >> This can screw up a traceroute function, as well. >> 2) TOS routing. The ipRouteTable doesn't contain any information about >> TOS. Even if it did, I'm not sure that I could write the code >> that emulates a router's decisions (or bugs) about the mapping >> from packet type/TOS/whatever to "preferred" route. >> 3) Multipath routing. The current ipRouteTable doesn't contain any >> information about this. (MIB-II did, at one point, but it got >> taken out in a decision that I still curse Marshall for.) >> I haven't looked closely at the new ipForwarding table to see what of >> these problems might have been addressed, but that isn't my point. My >> point is that you really need to see what will happen to a REAL PACKET. You might take the time to do so; I think you will be pleasantly surprized. It keeps track of destination, policy (treating type of service as a special case of policy), routing protocol making the decision, and next hop. The last gives you multipath routing. While I agree that looking at all of this data is all well and good, it is NOT sufficient to supplant traceroute. It does NOT tell you anything about the _algorithm_ that is used to make the routing decision. Without full and complete knowledge of the algorithm, all of the data in the world will not give you squat as compared to a real live experiment. And before you ask, yes, the routing algorithm IS somewhat complicated and yes, it does vary from vendor to vendor and from release to release. To prove the point, I will tell you here and now that I cannot tell you without looking at the source and without experimentation what a cisco router will do in _ALL_ cases (other than "The Right Thing" ;-). There are just too many odd corner cases. Experimentally yours, Tony From owner-Big-Internet@munnari.oz.au Sat Oct 10 18:54:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05982; Sat, 10 Oct 1992 18:54:57 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05979; Sat, 10 Oct 1992 18:54:47 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Sat, 10 Oct 92 01:54:42 -0700 Date: Sat, 10 Oct 92 01:54:42 -0700 From: Tony Li Message-Id: <9210100854.AA08210@lager.cisco.com> To: Z.Wang@cs.ucl.ac.uk (Zheng Wang), big-internet@munnari.oz.au Subject: IP options Some people have expressed following concerns as to: 1) whether the presence of IP option may have visible performance penalty, and 2) whether current IP routers and hosts in the Internet can deal with unknow IP options properly (i.e. ignoring unknown IP options silently as required by RFC-1122 and router requirement draft). The answer to #2 is known. There are certain routers and hosts (from a variety of vendors) that misbehave in different ways on different options. I will not point fingers. In any case, I would claim that this is irrelevant. If you create a demand for a feature, bad implementations of that feature will get corrected. If performance for that feature is poor, then it will become a marketing issue and performance will improve. This is simply a chicken and egg problem. If you force the issue it will go away. Consider the number of systems that did not properly implement ICMP Time Exceeded when traceroute first came out. Consider the number of these systems that you still see... Tony From owner-big-internet@munnari.oz.au Sat Oct 10 19:11:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06460; Sat, 10 Oct 1992 19:11:10 +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 AA08229; Sat, 10 Oct 1992 04:51:22 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from bells.cs.ucl.ac.uk by shark.mel.dit.csiro.au with SMTP id AA25121 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 9 Oct 1992 23:18:47 +1000 Message-Id: <199210091318.AA25121@shark.mel.dit.csiro.au> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 9 Oct 1992 14:15:49 +0100 To: Big-Internet@munnari.oz.au Subject: what is the diameter of current Internet Date: Fri, 09 Oct 92 14:15:47 +0100 From: Zheng Wang Following Jon's message, I did traceroute to all 32 hosts and found some interesting results: 1) The longest route is to South Africa (21 hops) and next to Brazil (20 hops). Maybe someone really at the edge of the Internet can produce even longer route? 2) The current Internet is largely hierarchical. Most routes follow LocalNet->NatinalNet->BackBoneNet->NationaaNet->LocalNet. Therefore, the number of hops decided by the hops in each of the networks. 3) LocalNet usually has fewer than 4 hops, and NationalNet usually has fewer than 6 hops. 4) BackBoneNet sometime takes quite a few hops, e.g, it takes 7 hops to cross t3.nsf.net (see traceroute to acm.org) and 5 hops to cross switch.ch (see traceroute to unizh.ch). This indicates that they do not have rich connections among the nodes!? Now - the controversial conclusions:-) 1) the number of hops depends on how many national and backbone nets we have to pass to reach other side. As the Internet expands, we may have to go through more nets to reach other side. But it is unlikely to be very large if we follow some hierarchical structure. 2) in the future, the BackBoneNets are likely to have richer connections so we may have less hops. We may also have better internatonal connections, e.g. UK may have direct connections to South Africa or Brazil instead of going through US. This os very likely to happen if large ATM and Public Data Networks become available. So my guess is: In the future any network is likely to be fewer than 10 nets away than another network, and within each net, any node is likely to be fewer than 10 hops away from another node. The maximum hops are likely to be fewer than 100 hops. Cheers Zheng -------- some longest routes are enclosed here: traceroute to bertha.cc.und.ac.za (146.230.128.3), 30 hops max, 40 byte packets 1 cisco (128.16.6.150) 10 ms 10 ms 0 ms 2 cisco-b.ucl.ac.uk (128.40.20.246) 20 ms 30 ms 10 ms 3 ULCC-gw.livenet.ac.uk (192.147.148.1) 90 ms 140 ms 130 ms 4 London-EBS1.Ebone.NET (128.86.1.6) 120 ms 20 ms 40 ms 5 London-EBS2.Ebone.NET (192.121.155.18) 130 ms 70 ms 80 ms 6 Stockholm-EBS1.Ebone.NET (192.121.154.33) 1460 ms 1720 ms 1380 ms 7 * * * 8 Washington.DC.Alter.Net (192.157.65.50) 1770 ms 2000 ms 1570 ms 9 San-Jose1.CA.ALTER.NET (137.39.43.2) 1520 ms * 360 ms 10 San-Jose2.CA.ALTER.NET (137.39.45.2) 300 ms 300 ms 310 ms 11 Portland.OR.ALTER.NET (137.39.8.2) 300 ms 290 ms 300 ms 12 PSG-gw.ALTER.NET (137.39.40.2) 310 ms 530 ms 740 ms 13 cisco1.psg.com (147.28.0.58) 580 ms 570 ms 530 ms 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * bertha.cc.und.ac.za (146.230.128.3) 4550 ms * traceroute to pascal.acm.org (192.135.174.1), 30 hops max, 40 byte packets 1 cisco (128.16.6.150) 0 ms 10 ms 0 ms 2 cisco-b.ucl.ac.uk (128.40.20.246) 20 ms 30 ms 20 ms 3 ULCC-gw.livenet.ac.uk (192.147.148.1) 50 ms 30 ms 40 ms 4 nsn-gw.ulcc.ac.uk (128.86.1.3) 30 ms 30 ms 30 ms 5 GSFC6.NSN.NASA.GOV (128.161.165.1) 620 ms 770 ms 830 ms 6 * SURA.NSN.NASA.GOV (128.161.40.38) 620 ms 570 ms 7 en-0.enss145.t3.nsf.net (192.80.214.246) 580 ms 660 ms 550 ms 8 t3-2.cnss58.t3.nsf.net (140.222.58.3) 620 ms 470 ms 570 ms 9 t3-3.cnss56.t3.nsf.net (140.222.56.4) 400 ms 490 ms 570 ms 10 t3-2.cnss72.t3.nsf.net (140.222.72.3) 580 ms 750 ms 810 ms 11 t3-0.cnss104.t3.nsf.net (140.222.104.1) 760 ms 770 ms 690 ms 12 t3-2.cnss64.t3.nsf.net (140.222.64.3) 640 ms 520 ms 790 ms 13 t3-0.cnss65.t3.nsf.net (140.222.65.1) 850 ms 650 ms 570 ms 14 t3-0.enss139.t3.nsf.net (140.222.139.1) 680 ms 740 ms 780 ms 15 RICE2-E1.sesqui.net (128.241.0.83) 840 ms 480 ms 550 ms 16 UT1-S1.sesqui.net (128.241.3.130) 470 ms 620 ms 750 ms 17 BU1-S1.sesqui.net (128.241.1.162) 910 ms 660 ms 550 ms 18 ANT-S0.sesqui.net (128.241.0.130) 610 ms 530 ms 490 ms 19 ACM.ORG (192.135.174.1) 540 ms 640 ms 730 ms traceroute to rzusuntk.unizh.ch (130.60.128.3), 30 hops max, 40 byte packets 1 cisco (128.16.6.150) 10 ms 10 ms 0 ms 2 cisco-b.ucl.ac.uk (128.40.20.246) 40 ms 20 ms 20 ms 3 ULCC-gw.livenet.ac.uk (192.147.148.1) 30 ms 70 ms 90 ms 4 London-EBS1.Ebone.NET (128.86.1.6) 20 ms 40 ms 20 ms 5 Montpellier-EBS1.Ebone.NET (192.121.155.241) 70 ms 50 ms 70 ms 6 Cern-EBS1.Ebone.NET (192.121.157.1) 460 ms 370 ms 440 ms 7 swice1.cern.ch (192.65.185.130) 430 ms 150 ms 340 ms 8 swiel1.switch.ch (130.59.92.1) 300 ms 380 ms 510 ms 9 swima1.switch.ch (130.59.153.2) 520 ms 620 ms 440 ms 10 swima2.switch.ch (130.59.158.2) 510 ms 510 ms 390 ms 11 swiez2.switch.ch (130.59.152.2) 290 ms 120 ms 210 ms 12 swizh1.switch.ch (130.59.2.205) 220 ms 220 ms 220 ms 13 rzusuntk.unizh.ch (130.60.128.3) 230 ms 220 ms 250 ms traceroute to funet.fi (130.230.1.1), 30 hops max, 40 byte packets 1 cisco (128.16.6.150) 10 ms 0 ms 10 ms 2 cisco-b.ucl.ac.uk (128.40.20.246) 20 ms 20 ms 20 ms 3 ULCC-gw.livenet.ac.uk (192.147.148.1) 70 ms 40 ms 40 ms 4 London-EBS1.Ebone.NET (128.86.1.6) 40 ms 20 ms 40 ms 5 London-EBS2.Ebone.NET (192.121.155.18) 50 ms 50 ms 50 ms 6 Stockholm-EBS1.Ebone.NET (192.121.154.33) 80 ms 80 ms 80 ms 7 Stockholm-EBS2.Ebone.NET (192.121.154.18) 110 ms 110 ms 90 ms 8 fi-gw.nordu.net (192.36.148.162) 130 ms 120 ms 150 ms 9 ananas-gw.funet.fi (128.214.6.207) 140 ms 130 ms 130 ms 10 taateli-gw.funet.fi (128.214.254.2) 170 ms 170 ms 160 ms 11 ariel-gw.cc.tut.fi (128.214.31.1) 140 ms 180 ms 180 ms 12 coral-gw.cc.tut.fi (130.230.102.2) 200 ms 290 ms 260 ms 13 funet.fi (130.230.1.1) 130 ms ariel-gw.cc.tut.fi (128.214.31.1) 540 ms * traceroute to cphkvx.cphk.hk (144.214.2.1), 30 hops max, 40 byte packets 1 cisco (128.16.6.150) 0 ms 0 ms 0 ms 2 cisco-b.ucl.ac.uk (128.40.20.246) 30 ms 20 ms 20 ms 3 ULCC-gw.livenet.ac.uk (192.147.148.1) 160 ms 100 ms 100 ms 4 nsn-gw.ulcc.ac.uk (128.86.1.3) 90 ms 30 ms 20 ms 5 GSFC6.NSN.NASA.GOV (128.161.165.1) 450 ms 340 ms 470 ms 6 ARC1.NSN.NASA.GOV (128.161.2.10) 530 ms 800 ms 780 ms 7 ARC2.NSN.NASA.GOV (192.52.195.11) 680 ms 650 ms 670 ms 8 * 132.160.248.2 (132.160.248.2) 2840 ms 2710 ms 9 137.189.195.4 (137.189.195.4) 2470 ms 1420 ms 1500 ms 10 cphkvx.cphk.hk (144.214.2.1) 1880 ms 2080 ms 2230 ms traceroute to kogwy.cc.keio.ac.jp (131.113.1.1), 30 hops max, 40 byte packets 1 cisco (128.16.6.150) 10 ms 0 ms 10 ms 2 cisco-b.ucl.ac.uk (128.40.20.246) 30 ms 30 ms 20 ms 3 ULCC-gw.livenet.ac.uk (192.147.148.1) 310 ms 230 ms 180 ms 4 nsn-gw.ulcc.ac.uk (128.86.1.3) 200 ms 30 ms 40 ms 5 * * GSFC6.NSN.NASA.GOV (128.161.165.1) 690 ms 6 ARC1.NSN.NASA.GOV (128.161.2.10) 790 ms 730 ms 650 ms 7 ARC2.NSN.NASA.GOV (192.52.195.11) 880 ms 870 ms 690 ms 8 imp.Hawaii.Net (132.160.249.1) 530 ms 960 ms 810 ms 9 menehune.Hawaii.Net (132.160.1.1) 780 ms 780 ms 650 ms 10 132.160.251.2 (132.160.251.2) 590 ms 1000 ms 940 ms 11 133.4.1.1 (133.4.1.1) 1040 ms 350 ms 340 ms 12 endo.wide.sfc.keio.ac.jp (133.4.11.2) 610 ms 380 ms 450 ms 13 r48-gw.sfc.keio.ac.jp (133.27.48.1) 350 ms 600 ms 600 ms 14 133.27.4.254 (133.27.4.254) 760 ms 1060 ms 1080 ms 15 hc-relay.hc.keio.ac.jp (131.113.224.1) 870 ms 1000 ms 950 ms 16 kobkf-relay.cm.phys.keio.ac.jp (131.113.224.3) 780 ms 920 ms 830 ms 17 newton.kw.phys.keio.ac.jp (131.113.44.1) 710 ms 540 ms 780 ms 18 kogwy.cc.keio.ac.jp (131.113.1.1) 530 ms 590 ms 850 ms traceroute to exu.inf.puc-rio.br (139.82.16.3), 30 hops max, 40 byte packets 1 cisco (128.16.6.150) 10 ms 0 ms 10 ms 2 cisco-b.ucl.ac.uk (128.40.20.246) 30 ms 20 ms 20 ms 3 ULCC-gw.livenet.ac.uk (192.147.148.1) 220 ms 280 ms 290 ms 4 nsn-gw.ulcc.ac.uk (128.86.1.3) 220 ms 30 ms 40 ms 5 GSFC6.NSN.NASA.GOV (128.161.165.1) 640 ms 670 ms 680 ms 6 SURA.NSN.NASA.GOV (128.161.40.38) 740 ms * * 7 en-0.enss145.t3.nsf.net (192.80.214.246) 750 ms 720 ms 850 ms 8 t3-2.cnss58.t3.nsf.net (140.222.58.3) 760 ms 710 ms 740 ms 9 t3-3.cnss56.t3.nsf.net (140.222.56.4) 670 ms 630 ms 680 ms 10 t3-2.cnss72.t3.nsf.net (140.222.72.3) 790 ms 810 ms 780 ms 11 t3-0.cnss104.t3.nsf.net (140.222.104.1) 640 ms 590 ms 620 ms 12 t3-2.cnss64.t3.nsf.net (140.222.64.3) 810 ms 910 ms 740 ms 13 t3-2.cnss16.t3.nsf.net (140.222.16.3) 780 ms 750 ms 900 ms 14 t3-0.cnss17.t3.nsf.net (140.222.17.1) 800 ms 690 ms 830 ms 15 t3-0.enss135.t3.nsf.net (140.222.135.1) 900 ms 750 ms 800 ms 16 132.249.32.13 (132.249.32.13) 800 ms 830 ms 730 ms 17 hang-sdsc.cerf.net (134.24.99.2) 910 ms 1150 ms * 18 * * * 19 192.80.209.22 (192.80.209.22) 1620 ms 1290 ms 1500 ms 20 exu.inf.puc-rio.br (139.82.16.3) 1530 ms 1420 ms 1410 ms traceroute to nctu.edu.tw (140.113.1.1), 30 hops max, 40 byte packets 1 cisco (128.16.6.150) 10 ms 10 ms 0 ms 2 cisco-b.ucl.ac.uk (128.40.20.246) 30 ms 10 ms 20 ms 3 ULCC-gw.livenet.ac.uk (192.147.148.1) 20 ms 20 ms 30 ms 4 nsn-gw.ulcc.ac.uk (128.86.1.3) 20 ms 20 ms 20 ms 5 GSFC6.NSN.NASA.GOV (128.161.165.1) 110 ms 110 ms 110 ms 6 SURA.NSN.NASA.GOV (128.161.40.38) 140 ms 130 ms 130 ms 7 en-0.enss145.t3.nsf.net (192.80.214.246) 180 ms 210 ms 140 ms 8 t3-2.cnss58.t3.nsf.net (140.222.58.3) 150 ms 160 ms * 9 t3-3.cnss56.t3.nsf.net (140.222.56.4) 120 ms * * 10 t3-0.cnss32.t3.nsf.net (140.222.32.1) 150 ms * 210 ms 11 t3-0.cnss33.t3.nsf.net (140.222.33.1) 260 ms 150 ms 140 ms 12 t3-0.enss137.t3.nsf.net (140.222.137.1) 160 ms 150 ms 170 ms 13 * * pax-gateway.jvnc.net (192.12.211.75) 140 ms 14 192.83.196.1 (192.83.196.1) 1610 ms 1280 ms 1410 ms 15 192.83.166.1 (192.83.166.1) 1800 ms 1840 ms * 16 * * * 17 * * 134.208.202.113 (134.208.202.113) 720 ms 18 * NCTU.edu.tw (140.113.1.1) 600 ms * traceroute to xalapa.lania.mx (192.100.158.254), 30 hops max, 40 byte packets 1 cisco (128.16.6.150) 0 ms 0 ms 10 ms 2 cisco-b.ucl.ac.uk (128.40.20.246) 30 ms 20 ms 20 ms 3 ULCC-gw.livenet.ac.uk (192.147.148.1) 30 ms 20 ms 20 ms 4 nsn-gw.ulcc.ac.uk (128.86.1.3) 30 ms 20 ms 30 ms 5 GSFC6.NSN.NASA.GOV (128.161.165.1) 120 ms 120 ms 130 ms 6 SURA.NSN.NASA.GOV (128.161.40.38) 140 ms 150 ms 200 ms 7 en-0.enss145.t3.nsf.net (192.80.214.246) 120 ms 130 ms 120 ms 8 t3-2.cnss58.t3.nsf.net (140.222.58.3) 140 ms 150 ms * 9 t3-3.cnss56.t3.nsf.net (140.222.56.4) 150 ms 220 ms 120 ms 10 t3-2.cnss72.t3.nsf.net (140.222.72.3) 140 ms 150 ms * 11 t3-0.cnss104.t3.nsf.net (140.222.104.1) 190 ms 160 ms 160 ms 12 t3-2.cnss64.t3.nsf.net (140.222.64.3) 210 ms 190 ms * 13 t3-0.cnss65.t3.nsf.net (140.222.65.1) 170 ms 180 ms 240 ms 14 t3-0.cnss67.t3.nsf.net (140.222.67.1) 240 ms 230 ms 280 ms 15 fcnss68.t3.nsf.net (192.103.67.6) 170 ms 210 ms 180 ms 16 fenss173.t3.nsf.net (192.103.67.10) 220 ms 590 ms 660 ms 17 gwcisco.mty.itesm.mx (131.178.1.2) 580 ms 510 ms 530 ms 18 131.178.41.2 (131.178.41.2) 550 ms 700 ms 820 ms 19 * * 192.100.158.254 (192.100.158.254) 340 ms From owner-Big-Internet@munnari.oz.au Sun Oct 11 01:28:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19563; Sun, 11 Oct 1992 01:28:58 +1000 (from owner-Big-Internet) Return-Path: Received: from wraith.internode.com.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19559; Sun, 11 Oct 1992 01:28:48 +1000 (from simon@internode.com.au) Received: by wraith.internode.com.au (5.64+1.3.1+0.50/UA-5.23) id AA06771; Sun, 11 Oct 1992 00:57:13 +0930 From: Simon Hackett Message-Id: <9210101527.AA06771@wraith.internode.com.au> Subject: re: what is the diameter of the current Internet To: big-internet@munnari.oz.au Date: Sun, 11 Oct 92 0:57:13 CST X-Mailer: ELM [version 2.4dev PL17] It's not hard to exceed Zheng's 21 hops by a factor of 50%, when one starts out 'here' in Australia... (see below): Additionally, I have a customer who is actively considering an Internet link down to the Australian facility in Antartica. Talk about global Internetworking... My view of the hopcount question is that even if 255 *is* enough, what if we're wrong? Let's blow another 8 bits anyway. There's a difference between making the fields stupidly big, and making them one "8 bits' worth" more than current expectations, to hedge our bets. I'm in favour of the former. Simon Hackett ---- $ multinet trace bertha.cc.und.ac.za/max=40 traceroute to BERTHA.CC.UND.AC.ZA (146.230.128.3), 40 hops max, 38 byte packets 1 mike (192.83.231.10) 10 ms 10 ms 10 ms 2 annex2.itd.adelaide.edu.au (129.127.40.103) 520 ms 230 ms 240 ms 3 pancho.itd.adelaide.edu.au (129.127.40.86) 270 ms 250 ms 240 ms 4 sa.gw.au (129.127.12.1) 240 ms 240 ms 240 ms 5 national.gw.au (139.130.40.1) 250 ms 250 ms 260 ms 6 usa.gw.au (139.130.4.5) 260 ms 250 ms 260 ms 7 arc2.nsn.nasa.gov (132.160.240.1) 830 ms 820 ms 830 ms 8 ARC2.NSN.NASA.GOV (192.100.12.2) 820 ms 830 ms 840 ms 9 t3-0.enss144.t3.nsf.net (192.52.195.253) 850 ms 820 ms 820 ms 10 t3-2.cnss9.t3.nsf.net (140.222.9.3) 830 ms 830 ms 830 ms 11 t3-3.cnss8.t3.nsf.net (140.222.8.4) 830 ms 830 ms 830 ms 12 t3-0.cnss24.t3.nsf.net (140.222.24.1) 870 ms 860 ms 880 ms 13 t3-0.cnss40.t3.nsf.net (140.222.40.1) 880 ms 870 ms 870 ms 14 t3-1.cnss32.t3.nsf.net (140.222.32.2) 890 ms 890 ms 880 ms 15 t3-1.cnss56.t3.nsf.net (140.222.56.2) 890 ms 920 ms 890 ms 16 t3-0.cnss58.t3.nsf.net (140.222.58.1) 910 ms 900 ms 900 ms 17 t3-0.enss136.t3.nsf.net (140.222.136.1) 890 ms 890 ms 890 ms 18 College-Park.MD.ALTER.NET (192.80.214.249) 900 ms 900 ms 910 ms 19 Washington.DC.ALTER.NET (137.39.28.1) 900 ms 900 ms 900 ms 20 San-Jose1.CA.ALTER.NET (137.39.43.2) 950 ms 950 ms 970 ms 21 San-Jose2.CA.ALTER.NET (137.39.44.2) 1020 ms 950 ms 950 ms 22 Portland.OR.ALTER.NET (137.39.8.2) 980 ms 980 ms 990 ms 23 PSG-gw.ALTER.NET (137.39.40.2) 1120 ms 1470 ms 1270 ms 24 cisco1.psg.com (147.28.0.58) 1250 ms 1210 ms 1240 ms 25 * * * 26 * * pcr1.rhodes.uni.net.za (155.232.248.2) 3410 ms 27 * * * 28 * * bertha.cc.und.ac.za (146.230.128.3) 3380 ms From owner-Big-Internet@munnari.oz.au Sun Oct 11 02:54:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22563; Sun, 11 Oct 1992 02:55:15 +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 AA22538; Sun, 11 Oct 1992 02:54:45 +1000 (from kre) To: Frank T. Solensky Cc: Big-Internet@munnari.oz.au From: Big-Internet=Request@munnari.oz.au Subject: Re: time warps In-Reply-To: Your message of Fri, 09 Oct 92 11:45:43 -0400. <9210091545.AA28878@fenway.andr.UB.com> Date: Sun, 11 Oct 92 02:54:34 +1000 Message-Id: <11869.718736074@munnari.oz.au> Sender: kre@munnari.oz.au Date: Fri, 9 Oct 92 11:45:43 EDT From: Frank T. Solensky Message-ID: <9210091545.AA28878@fenway.andr.UB.com> My guess is that the mail exploder works by: while ((new_recip = getnext()) != EOF) { /usr/lib/sendmail new_recip Received: from tosca.er.sintef.no by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01381; Sun, 11 Oct 1992 07:46:40 +1000 (from Steinar.Haug@delab.sintef.no) Received: from delab.sintef.no by tosca.er.sintef.no with SMTP (PP) id <14229-0@tosca.er.sintef.no>; Sat, 10 Oct 1992 22:46:19 +0100 Received: by tosca.er.sintef.no (4.1/DELAB-1.7.n) id AA14225; Sat, 10 Oct 92 22:46:17 +0100 Message-Id: <9210102146.AA14225@tosca.er.sintef.no> Date: Sat, 10 Oct 92 22:46:17 +0100 From: Steinar.Haug@delab.sintef.no To: Big-Internet@munnari.oz.au Subject: Re: what is the diameter of current Internet > Following Jon's message, I did traceroute to all 32 hosts > and found some interesting results: > > 1) The longest route is to South Africa (21 hops) and next > to Brazil (20 hops). Maybe someone really at the edge of the > Internet can produce even longer route? Easily. Here is my route to the Japanese host given. 28 hops :-) Steinar Haug, system/networks administrator SINTEF DELAB, University of Trondheim, NORWAY Email: Steinar.Haug@delab.sintef.no, sthaug@idt.unit.no, steinar@tosca.er.sintef.no ---------------------------------------------------------------------- traceroute to kogwy.cc.keio.ac.jp (131.113.1.1) from 129.241.150.6, 30 hops max, 18 byte packets 1 faust.er.sintef.no (129.241.150.1) 3 ms 3 ms 3 ms 2 unit-gw.unit.no (129.241.1.2) 20 ms 11 ms 15 ms 3 no-gw.nordu.net (128.39.9.1) 13 ms 10 ms 12 ms 4 Stockholm-EBS2.nordu.net (192.36.148.145) 48 ms 51 ms 34 ms 5 Stockholm-EBS1.Ebone.NET (192.121.154.17) 59 ms 51 ms 45 ms 6 Stockholm-Washington.Ebone.NET (192.121.154.242) 158 ms 172 ms 180 ms 7 icm-fix-e.icp.net (192.157.65.17) 204 ms 163 ms 161 ms 8 en-0.enss145.t3.nsf.net (192.80.214.246) 169 ms 169 ms 195 ms 9 t3-2.cnss58.t3.nsf.net (140.222.58.3) 176 ms 197 ms 198 ms 10 t3-3.cnss56.t3.nsf.net (140.222.56.4) 208 ms 204 ms 208 ms 11 t3-0.cnss32.t3.nsf.net (140.222.32.1) 196 ms 171 ms 207 ms 12 t3-1.cnss40.t3.nsf.net (140.222.40.2) 190 ms 188 ms 202 ms 13 t3-2.cnss24.t3.nsf.net (140.222.24.3) 254 ms 197 ms 225 ms 14 t3-1.cnss8.t3.nsf.net (140.222.8.2) 252 ms 250 ms 228 ms 15 t3-0.cnss9.t3.nsf.net (140.222.9.1) 249 ms 244 ms 276 ms 16 t3-0.enss144.t3.nsf.net (140.222.144.1) 285 ms 269 ms 268 ms 17 ARC2.NSN.NASA.GOV (192.52.195.11) 300 ms 295 ms 234 ms 18 imp.Hawaii.Net (132.160.249.1) 282 ms 301 ms 291 ms 19 menehune.Hawaii.Net (132.160.1.1) 350 ms 314 ms 288 ms 20 132.160.251.2 (132.160.251.2) 408 ms 421 ms 500 ms 21 jp-gate.wide.ad.jp (133.4.1.1) 449 ms 424 ms 400 ms 22 * endo.wide.sfc.keio.ac.jp (133.4.11.2) 549 ms 489 ms 23 r48-gw.sfc.keio.ac.jp (133.27.48.1) 425 ms 408 ms 436 ms 24 133.27.4.254 (133.27.4.254) 415 ms 412 ms 417 ms 25 hc-relay.hc.keio.ac.jp (131.113.224.1) 489 ms 412 ms 472 ms 26 kobkf-relay.cm.phys.keio.ac.jp (131.113.224.3) 563 ms 543 ms 427 ms 27 newton.kw.phys.keio.ac.jp (131.113.44.1) 588 ms 594 ms 671 ms 28 kogwy.cc.keio.ac.jp (131.113.1.1) 492 ms 664 ms 521 ms From owner-Big-Internet@munnari.oz.au Sun Oct 11 12:08:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09912; Sun, 11 Oct 1992 12:08:43 +1000 (from owner-Big-Internet) Return-Path: Received: from [132.245.33.7] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09908; Sun, 11 Oct 1992 12:08:32 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA29716 (5.65c/UK-2.1-921001); Sat, 10 Oct 1992 22:10:01 -0400 From: Gary Scott Malkin Date: Sat, 10 Oct 1992 22:10:01 -0400 Message-Id: <29716.199210110210@atlas.xylogics.com> To: dab@berserkly.cray.com Cc: big-internet@munnari.oz.au In-Reply-To: David A. Borman's message of Fri, 9 Oct 1992 16:53:25 -0500 <9210092153.AA02122@handel.cray.com.cray.com> Subject: Record Route (was Re: Hop Limit field in SIP) > Many of the schemes involved are implemented in a layer above > IP. Routers don't normally look above the IP layer unless the > packet's destination address is for the router. That's true. However, ICMP is very tightly coupled to the IP layer. I wouldn't consider it a layering violation for a router to look into an ICMP packet. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Sun Oct 11 16:00:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17517; Sun, 11 Oct 1992 16:00:16 +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 AA17514; Sun, 11 Oct 1992 16:00:08 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12523>; Sat, 10 Oct 1992 22:59:49 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sat, 10 Oct 1992 22:59:42 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Splitting the network layer: take 2 In-Reply-To: Your message of "Wed, 07 Oct 92 07:30:51 PDT." <9210071430.AA25982@ginger.lcs.mit.edu> Date: Sat, 10 Oct 1992 22:59:34 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct10.225942pdt.10779@skylark.parc.xerox.com> Quoting me, Noel wrote: > Both the provider-based addresses and the metro-based addresses proposed > for SIP and IPAE follow network topology. > > Do the metro-based addresses really follow network topology, though? Isn't > the whole point of metro addresses that your address doesn't depend on which > provider you are attached to, which surely *is* an important part of the > topology? The metro-based addressing scheme requires links to be present in the graph so that the metro-based addresses *can* follow the topology. In particular, it requires that a metro-area be fully connected, i.e., once a packet is delivered to any point in a metro area, it can reach any other point in the same metro without leaving the metro. This is just a specific case of the general requirement/assumption of any hierarchical routing scheme: that each region, sub-region, sub-sub-region, etc. be fully connected. There is an analogous case with provider-based addressing: a provider's facilities must be fully connected if they are to be identified by a single prefix. (Actually, it's not an absolute requirement -- you can use tricks like tunneling to link together the pieces of a partitioned region. IS-IS can do that to heal partitioned Level 1 Areas, and the various mobile IP schemes do something similar to allow members of a subnet to roam to arbitrary places in the graph.) Steve From owner-Big-Internet@munnari.oz.au Sun Oct 11 18:28:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22993; Sun, 11 Oct 1992 18:28:49 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22990; Sun, 11 Oct 1992 18:28:43 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Sun, 11 Oct 92 01:28:23 -0700 Date: Sun, 11 Oct 92 01:28:23 -0700 From: Tony Li Message-Id: <9210110828.AA00926@lager.cisco.com> To: gmalkin@xylogics.com (Gary Scott Malkin) Cc: dab@berserkly.cray.com, big-internet@munnari.oz.au Subject: Record Route (was Re: Hop Limit field in SIP) > Many of the schemes involved are implemented in a layer above > IP. Routers don't normally look above the IP layer unless the > packet's destination address is for the router. That's true. However, ICMP is very tightly coupled to the IP layer. I wouldn't consider it a layering violation for a router to look into an ICMP packet. Routers don't care about layering violations. Neither do router vendors. Routers do care about speed tho. Examining each and every packet through a router to see if it this special ICMP packet is a significant hit on throughput. Sorry, but this has NO chance of flying. Tony From owner-Big-Internet@munnari.oz.au Mon Oct 12 01:08:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06887; Mon, 12 Oct 1992 01:08:25 +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 AA06881; Mon, 12 Oct 1992 01:08:16 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00673; Sun, 11 Oct 92 11:08:06 -0400 Date: Sun, 11 Oct 92 11:08:06 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210111508.AA00673@ginger.lcs.mit.edu> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: Splitting the network layer: take 2 Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The metro-based addressing scheme requires links to be present in the graph so that the metro-based addresses *can* follow the topology. In particular, it requires that a metro-area be fully connected Let me see if I understand this. Each different carrier has a section of its topology which 'protrudes' into the area of the complete topology labelled as the metro. The metro area is a contiguous piece of the topology, as you indicate, not partitioned. (Visualize this first in 2-space, since it's easier there; real topologies will not be mappable in 2-space without crossing links, of course.) All users who connect inside the metro do so somewhere on the piece of the metro's topology that their carrier owns. Probably all the carriers in a metro are fully connected, so that traffic to others inside the metro flows directly to their carrier portions; alternatively, carriers could have intermediate carrier agreements. Traffic to places outside the metro will naturally (or won't it, hmm) flow out across the network links of the carrier to which the user is connected, and across that carrier to the destination metro. If that carrier doesn't serve the destination, another intermediate carrier agreement is needed. Here's that part I have a problem with. If I understand the properties of metro-based addressing right, your metro-based "address" (I put this in quotes since no two people seem to have the same definition, which is a major pain in the ass, and one I am pretty damn sick of) has the property that it does not depend on which carrier you connect to, and thus does not change when you change carrier? Doesn't this mean that all the individual customer entities (which may mean a corporation as an agglomerate) inside a metro have to be routed and tracked pretty much individually inside the metro (i.e. no aggregation)? I.e., addresses within the metro are "flat", right? How else do you have an "address" which doesn't change when the place where you connect to the topology changes? the general requirement/assumption of any hierarchical routing scheme: that each region, sub-region, sub-sub-region, etc. be fully connected As you note, this is not an absolute requirement of all such schemes. The exception mechanisms (i.e using the longest match to routing table entries) allows what appear from their addresses to be sub-regions of a region to be topologically discontiguous from that region. CIDR works this way. This is the usual trick people come up with when they want to be be able to move somewhere else in the network and not change their "address". The real point is the scope of the topology over which a destination has to be tracked as a separate entity; maximally effecient routing requires that no sub-region be topologically discontigous from the region, since this increases the scope over which that sub-region has to be tracked as a routing destination. Allowing *any* departures from this rule means that the route lookup algorithm becomes slightly more expensive; instead of looking for the first match, you have to look for the best match. The further you depart from this rule, the greater the cost to run the routing, since more destination information must be carried around in the routing. As you alluded to, this does not only happen when people want to pick up and move. It is closely related (in fact, exactly identical when you look at the effect on the routing) to ways of handling partitions. One way is to do what IS-IS does, and heal the partition with tunnels; the other is to do what OSPF does and simply advertise the subpieces. Noel PS: The analogy to the phone company doesn't work since when you change long-distance carriers, you are still connected to the same RBOC (and same wire, for that matter). Your carrier choice only affects outgoing long distance calls, and may be though of as a "default source route", with other carrier available through the "10xxx" escape, and other means, such as the "9501022" escape for MCI. From owner-Big-Internet@munnari.oz.au Mon Oct 12 01:39:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07873; Mon, 12 Oct 1992 01:40:10 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07866; Mon, 12 Oct 1992 01:39:55 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA13724 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Sun, 11 Oct 1992 11:39:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Sun, 11 Oct 1992 11:39:26 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 11 Oct 1992 11:39:26 -0400 Date: Sun, 11 Oct 1992 11:37:24 -0400 From: Dennis Ferguson Message-Id: <199210111537.AA95463@foo.ans.net> To: yakov@watson.ibm.com Subject: Re: EIDs Cc: big-internet@munnari.oz.au > Ref: Your note of Thu, 8 Oct 92 14:50:58 EDT > >>The three proposals work *fine* withtou EID because >>they were not designed with EID in mind. > Ken, > That is absolutely correct. What I wonder, though, is > how a proposal that would be designed *with* EID in mind > would compare to these three proposals. > Yakov Rekhter Yakov, I can't answer this in general, but I watched a presentation which dealt with how one might use the location+EID split to implement host mobility with CLNP (which is not to suggest I like CLNP better than anything else, I just happen to understand what was presented). It looked a lot like the Columbia scheme, except without encapsulation. (1) There is a forwarder at your home location with which you register your current mobile location. The forwarder sends packets destined to your home address on to you. (2) The forwarder, when it receives a packet addressed to your home location, simply rewrites the destination location information in the packet (leaving the destination EID and the source location+EID the same) and forwards it on to you. This replaces the encapsulation done by the Columbia scheme, and hence avoids the increase in the size of the packet which encapsulation necessitates and allows ICMP error messages to be sent directly back to the source in understandable form instead of having to be massaged by the forwarder on the way back. It makes life easier for the forwarder, I guess. (3) It was noted that, with location+EID, the source (non-mobile) host could transition from sending to the mobile through the forwarder to sending directly to the mobile (important if the source host and mobile are in Hawaii while the home location of the mobile is in Moscow) by simply noting that the return packets on the connection are coming from a different location, and replacing the destination location in use on the connection to match. With the Columbia scheme accomplishing the same thing would appear to require that the non-mobile host implement both the encapsulation protocol and a redirect protocol so it could transition to sending its own encapsulated packets directly (either this or that it pay careful attention to loose source routes in received packets). (4) With the Columbia scheme, if the mobile host does things using its temporary address, people won't be able to do address-to-name DNS lookups unless the DNS is dynamically updated as well. Using EID-to-name lookups instead removes any necessity to do dynamic DNS updates. (5) Location+EID simplifies dynamic address assignment at mobile locations. If the addresses are IP addresses you need some sort of server to assign temporary addresses to guarantee their uniqueness. With location+EID addresses the address you end up using is guaranteed to be unique, since the EID is unique no matter what the location, and you only need a way to inform mobile hosts of the appropriate location to use, something which any local router should know (in the case of CLNP, in particular, support for this exists already). I realize that the value of all of this for mobile hosts is debatable, since there are (obviously) other, more special purpose, ways to achieve the same ends. I think the reason this mobile host stuff keeps coming up is a general feeling that an architecture which supports host mobility naturally and well may also provide good support for the case where the hosts are fixed but the "location" information in the address has been changed due to changing network topology. The latter has important implications for scaling. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Mon Oct 12 03:34:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11424; Mon, 12 Oct 1992 03:34:13 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210111734.11424@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11414; Mon, 12 Oct 1992 03:34:00 +1000 (from yakov@watson.ibm.com) Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 6481; Sun, 11 Oct 92 13:33:52 EDT Date: Sun, 11 Oct 92 13:30:04 EDT From: yakov@watson.ibm.com To: dennis@ans.net Cc: big-internet@munnari.oz.au Subject: EIDs Ref: Your note of Sun, 11 Oct 1992 11:37:24 -0400 Dennis, What you described is quite similar to the way how IBM's proposal on mobility work. The role of EID is taken by the normal IP address. The actual location information (that is needed to correctly forward packets) is carried in the IP Loose Source Route option. IBM's proposal doesn't require encapsulation. A host tracks location of its peer by just reversing the LSR in the packet it receives from the peer. Yakov. P.S. IBM's proposal was presented at the last IETF. For those interested just drop me an e-mail and I'll send a copy. From owner-Big-Internet@munnari.oz.au Mon Oct 12 04:09:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12081; Mon, 12 Oct 1992 04:09:42 +1000 (from owner-Big-Internet) Return-Path: Received: from OPAL.ACC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12077; Mon, 12 Oct 1992 04:09:34 +1000 (from art@opal.acc.com) Received: by opal.acc.com (4.1/SMI-4.0) id AA03566; Sun, 11 Oct 92 11:10:42 PDT Date: Sun, 11 Oct 92 11:10:42 PDT From: art@opal.acc.com (Art Berggreen) Message-Id: <9210111810.AA03566@opal.acc.com> To: dab@berserkly.cray.com, gmalkin@xylogics.com Subject: Re: Record Route (was Re: Hop Limit field in SIP) Cc: big-internet@munnari.oz.au > >> Many of the schemes involved are implemented in a layer above >> IP. Routers don't normally look above the IP layer unless the >> packet's destination address is for the router. > >That's true. However, ICMP is very tightly coupled to the IP >layer. I wouldn't consider it a layering violation for a router >to look into an ICMP packet. The layering violation in itself is not a real problem. The thing I don't like is that it's another test in the main switching path. I much prefer the suggestion that was given to put the ultimate destination (or even a loose route) in the ICMP packet and set the IP destination, at each hop, to the next-hop as determined by routing. Art From owner-Big-Internet@munnari.oz.au Mon Oct 12 06:37:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16202; Mon, 12 Oct 1992 06:37:45 +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 AA16197; Mon, 12 Oct 1992 06:37:30 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12698>; Sun, 11 Oct 1992 13:36:50 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 11 Oct 1992 13:36:47 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Splitting the network layer: take 2 In-Reply-To: Your message of "Sun, 11 Oct 92 08:08:06 PDT." <9210111508.AA00673@ginger.lcs.mit.edu> Date: Sun, 11 Oct 1992 13:36:38 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct11.133647pdt.10779@skylark.parc.xerox.com> Noel wrote: > Let me see if I understand this. Each different carrier has a section > of its topology which 'protrudes' into the area of the complete topology > labelled as the metro. The metro area is a contiguous piece of the topology, > as you indicate, not partitioned. (Visualize this first in 2-space, since > it's easier there; real topologies will not be mappable in 2-space without > crossing links, of course.) > All users who connect inside the metro do so somewhere on the piece of > the metro's topology that their carrier owns. Probably all the carriers in a > metro are fully connected, so that traffic to others inside the metro flows > directly to their carrier portions; alternatively, carriers could have > intermediate carrier agreements. Traffic to places outside the metro will > naturally (or won't it, hmm) flow out across the network links of the carrier > to which the user is connected, and across that carrier to the destination > metro. If that carrier doesn't serve the destination, another intermediate > carrier agreement is needed. Yes, your understanding is correct -- nice description. Regarding your "(or won't it, hmm)" comment, in metro-based routing, packets are forwarded first towards the destination metro (staying within the initial provider's facilities as far as possible), and then towards the destination's provider. In provider-based addressing, the opposite happens: first towards the destination's provider, then towards the destination metro. > Here's that part I have a problem with. If I understand the properties > of metro-based addressing right, your metro-based "address" ... has the > property that it does not depend on which carrier you connect to, and thus > does not change when you change carrier? > Doesn't this mean that all the individual customer entities (which may > mean a corporation as an agglomerate) inside a metro have to be routed and > tracked pretty much individually inside the metro (i.e. no aggregation)? > I.e., addresses within the metro are "flat", right? Yes, site IDs are flat within a metro. That does not, however, necessarily mean that all provider routers within the metro have to individually "track" all sites (e.g., they can get by with only tracking their own subscribers, and knowing where to send packets for subscribers other than their own), or that the "tracking" has to occur with the same time granularity as current routers use to track, say, subnets. There are lots of alternatives for making the job of the metro router tractable -- maybe someday I'll finish my paper on metro-based addressing and routing that describes some of those alternatives. > (I put ["address"] in quotes since no two people seem to have the same > definition, which is a major pain in the ass, and one I am pretty damn > sick of) What have you done to remove that pain? I'm sorry if I missed your definition and your campaign to get everyone to agree with it. Let me give it a shot: An "address" is a unique label for a node or (in the case of multicast) set of nodes in the internet. (This definition intentionally does not say whether or not a "node" is a network interface, a box, or a "pseudo-node" representing a subnetwork; it may be any or all of those.) A "hierarchical address" is an address of the form L1, L2, ..., Ln, where: - L1 is a label for a connected region of the internet. - L2 is a label for a connected region of L1. - ... - Ln is a label for a node or set of nodes in region Ln-1. A label Li is required to be unique only with region Li-1. Reminder: a region is called "connected" if there is a intra-region path from any node to every other node within the region. Note that the definition of "address" does not prevent a node from keeping its address when it "moves" in the topology (thus, for example, an Ethernet device can keep its address when it is plugged into a different point on the same cable.) With "hierarchical addresses", a node or a group of nodes may keep their addresses when they move in the topology, as long as the "connectedness" requirement is not violated. > PS: The analogy to the phone company doesn't work since when you change > long-distance carriers, you are still connected to the same RBOC (and same > wire, for that matter). Your carrier choice only affects outgoing long > distance calls, and may be though of as a "default source route", with > other carrier available through the "10xxx" escape, and other means, such > as the "9501022" escape for MCI. The idea of metro-based addresses for internets grew out of thinking about what would be necessary in the phone system to allow subscribers to change *local* carriers and still keep the same phone number (where the change might even entail running a new wire from the subscriber to a different carrier's local office). One solution is to add another level of indirection, as you are so fond of suggesting: all carriers serving subscribers in the same area code could maintain a shared database that maps each of the 10,000,000 phone numbers in the area to a (carrier, local office) pair. A 10-million-entry database is small potatoes, these days; a copy might even be stored in RAM in every switch, updated once a day. Steve From owner-Big-Internet@munnari.oz.au Mon Oct 12 08:19:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19677; Mon, 12 Oct 1992 08:19:32 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210112219.19677@munnari.oz.au> Received: from avalon.mpce.mq.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19672; Mon, 12 Oct 1992 08:19:15 +1000 (from andrewm@avalon.mpce.mq.edu.au) Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA22568; Mon, 12 Oct 92 08:20:05 est From: Andrew Myles Subject: Re: EIDs To: dennis@ans.net Date: Mon, 12 Oct 92 8:20:03 EST Cc: big-internet@munnari.oz.au In-Reply-To: <199210111537.AA95463@foo.ans.net>; from "Dennis Ferguson" at Oct 11, 92 11:37 am Mailer: Elm [revision: 64.9] > I watched a presentation which dealt with how one might use the location+EID > split to implement host mobility with CLNP > It looked a lot like the Columbia scheme, except without encapsulation. The scheme you describe is actually much more like the Sony and IBM proposals. The Columbia proposal doesn't really have a location+EID spilt but just an EID. The packet is passed to a distributed router that then uses a private protocol to locate the mobile in a limited area. On the other hand both the IBM and Sony protocols have two separate addresses. In the Sony case the location addresses is allocated dynamically using a protocol like DHCP. In the IBM case the location address is that of the local BAS. For those interested I am in the middle of writing the "definitive" comparison between the three protocols based on the critiques that I previously posted to the mobile-ip mailing list. Andrew Myles -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: High Speed Networks Group, Electronics Discipline, School of Mathematics, Physics, Computing and Electronics, Macquarie University 2109, Sydney, Australia. Telephone: +61 2 8058439 (W), +61 2 8058983 (Fax), +61 2 8786060 (H). From owner-Big-Internet@munnari.oz.au Mon Oct 12 09:52:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23216; Mon, 12 Oct 1992 09:52:39 +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 AA23202; Mon, 12 Oct 1992 09:52:15 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12742>; Sun, 11 Oct 1992 16:52:01 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 11 Oct 1992 16:51:55 -0700 To: big-internet@munnari.oz.au Cc: deering@parc.xerox.com Subject: Re: EIDs Date: Sun, 11 Oct 1992 16:51:45 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct11.165155pdt.10779@skylark.parc.xerox.com> OK, now I think I understand what most of the contributors to the list mean when they refer to EIDs, and there does appear to be a rough consensus as to what they are and what they might be used for. Thank-you for the lengthy and detailed descriptions; I hope others found them as useful as I did. While I can see the architectural purity of creating a new namespace to identify "endpoints", I still don't know if it is worth the (major) cost of having to administer yet another name space, plus the (minor) bandwidth, storage, and processing overhead of carrying and operating on an EID in every packet. That "extra level of indirection" that solves any problem in Computer Science does *not* come for free. Most of the time, addresses serve just fine as endpoint identifiers, as evidenced by the fact that the current Internet works pretty well. Rather than burdening administrators with a new name space and burdening every packet with an EID, mightn't it be better to see if we can use existing capabilities to deal with those specific cases where addresses don't map one-to-one to endpoints? For example: - mobile hosts that don't stay long enough in one place to warrant a DNS update can be supported by the encapsulation or source routing schemes that have been proposed for mobile IP, which enable one address to be used as an endpoint ID and another to be used for routing whenever the mobile host is away from home. - a site that changes addresses when it changes providers might be supported by a similar (or identical) encapsulation/source-routing approach (by which packets delivered to the old provider can be "tunneled" to the new provider), only for as long as necessary to (1) get the DNS updated with the new addresses and (2) prevent breakage of connections/sessions that started with the old addresses. - the same encaps/src-route trick could be used to allow a transport connection initiated on one interface of a multi-homed host to switch to another interface in mid-connection (assuming we keep the model of addresses bound to interfaces, rather than boxes). Perhaps an "architected" tunneling scheme would be better engineering choice than an extra naming layer. Here are a few short responses to specific comments... Bob Smart wrote: > 3. What about networks connected to multiple providers. Do they have > multiple addresses. Answer "yes". That depends. With metro-based addresses, you can use the same addresses regardless of provider, as long as you are connected to each provider in the same metro area. > Mightn't you want to switch provider in the middle of a session: e.g. > from a fast provider for interactive stuff, then use a cheaper provider > for a bulk transfer. That can be handled by TOS mechanisms that direct interactive packets to one provider and bulk transfer packets to another. Quoting me, frank Kastenholz wrote: > > but it's not the only way to do it. As an off-the-wall suggestion, > > why not include the hosts' fully-qualified domain names, instead > > of their addresses, in the checksum, since they already serve as > > what if i do not have the domain name? suppose that i ping 10.0.0.51? If you don't have the domain name, what makes you think you'll have an EID? > i might also have my own /etc/hosts file, giving my own name-address > mappings and never deal with the fqdn. Do you want to be able to do that sort of thing with EIDs too? I assume not, due to the difficulty of ensuring uniqueness and correct current mapping of EID->address(es) if you allowed random hosts to keep /etc/eids files. If you are going to go to the directory for an EID, you can just as well go to the directory for a host name. > there is also the possibility of "which" domain name? there can be > two entries in the dns for a particular host. each one is is as > fully-qualified as the other. So, require that multiple names always be returned in the same order, and consider the first one to be the "primary" name. > I do not like the idea of introducing crypto-goop in the network > layer as a REQUIRED element. I was advocating the use of "crypto-goop" at the transport layer, not the network layer. > ... More importantly, crypto-goop is not always needed or > even desired. Imagine some dynamic host config. How does the host > learn the keys to process the packets which are telling that host who > it is? I suppose that some human could type the stuff in -- but now > we are getting away from humanless config -- which is what DHC is all > about. Yes, there are some interesting bootstrapping problems with auto-configuring a secure transport service, but I don't think they are intractable. I suspect that totally humanless configuration of generic boxes is fundamentally incompatible with secure communication -- a user may have to stick a smart card in a slot in a box before it can serve as a secure system. Dennis Ferguson wrote, as part of a description of an EID-based mobility scheme: > (2) The forwarder, when it receives a packet addressed to your home > location, simply rewrites the destination location information in > the packet (leaving the destination EID and the source location+EID > the same) and forwards it on to you. This replaces the encapsulation > done by the Columbia scheme, and hence avoids the increase in the size > of the packet which encapsulation necessitates ... Another way to look at it is that the encapsulation approach only adds the second destination identifier when it is really needed, whereas the described scheme makes *every* packet pay the cost of carrying two destination identifiers, whether they need them or not. > (3) It was noted that, with location+EID, the source (non-mobile) host > could transition from sending to the mobile through the forwarder to > sending directly to the mobile (important if the source host and mobile > are in Hawaii while the home location of the mobile is in Moscow) by > simply noting that the return packets on the connection are coming > from a different location, and replacing the destination location > in use on the connection to match. With the Columbia scheme > accomplishing the same thing would appear to require that the > non-mobile host implement both the encapsulation protocol and a > redirect protocol so it could transition to sending its own encapsulated > packets directly (either this or that it pay careful attention to > loose source routes in received packets). The need for the redirect can be considered a feature, rather than a drawback: either the mobile host or its forwarding agent at home can suppress the redirect (and force all traffic to flow via the home network) in order to conceal the location of the mobile host for privacy reasons. (Like, maybe I don't want anyone to know I'm using my laptop on the beach at Nice.) > (4) With the Columbia scheme, if the mobile host does things using its > temporary address, people won't be able to do address-to-name DNS > lookups unless the DNS is dynamically updated as well. Using > EID-to-name lookups instead removes any necessity to do dynamic DNS > updates. For what purposes are the address-to-name lookups being done? With the Columbia scheme, you can do a lookup on the encapsulated source address to get the mobile host's permanent name. A lookup on the encapsulating source address will probably yield an answer like tourist-57.beach.nice.fr. In no case, would a dynamic DNS update be necessary. Steve From owner-Big-Internet@munnari.oz.au Mon Oct 12 10:00:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23587; Mon, 12 Oct 1992 10:00:56 +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 AA23573; Mon, 12 Oct 1992 10:00:21 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12742>; Sun, 11 Oct 1992 17:00:02 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 11 Oct 1992 16:59:56 -0700 To: Andrew Myles Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: EIDs In-Reply-To: Your message of "Mon, 12 Oct 92 06:20:03 PDT." <9210112219.19677@munnari.oz.au> Date: Sun, 11 Oct 1992 16:59:43 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct11.165956pdt.10779@skylark.parc.xerox.com> Andrew Myles wrote: > The Columbia proposal doesn't really have a location+EID spilt but just an > EID. The packet is passed to a distributed router that then uses a private > protocol to locate the mobile in a limited area. > > On the other hand both the IBM and Sony protocols have two separate > addresses. The Columbia scheme *does* use a separate "location" identifier in most packets forwarded to mobile hosts -- it's the destination address in the encapsulating IP header. Steve From owner-Big-Internet@munnari.oz.au Mon Oct 12 10:08:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23938; Mon, 12 Oct 1992 10:09:02 +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 AA23924; Mon, 12 Oct 1992 10:08:40 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12743>; Sun, 11 Oct 1992 17:08:23 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 11 Oct 1992 17:08:14 -0700 To: oran@sneezy.lkg.dec.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Hop Limit field in SIP In-Reply-To: Your message of "Wed, 07 Oct 92 07:20:56 PDT." <921007102056.12546@sneezy.lkg.dec.com> Date: Sun, 11 Oct 1992 17:08:13 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct11.170814pdt.10779@skylark.parc.xerox.com> Dave Oran wrote: > > Could be... Maybe we go back to TTL, but you have to set the TTL to a value > > based on somethign you hear from your router, not from a fixed constant? > > > This is a good idea. ESIS has always had the mechanisms to have > the ISs tell the ESs certain policy variables, like timers and such. > > For IP/SIP there are a couple of simple mechanisms that come to mind: > > a) use DHCP > b) piggyback the information on ICMP redirects Or c) add it to the Router Advertisment messages (the IP sort-of-equivalent of IS Hellos). Steve From owner-Big-Internet@munnari.oz.au Mon Oct 12 10:15:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24304; Mon, 12 Oct 1992 10:17:00 +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 AA24229; Mon, 12 Oct 1992 10:15:42 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12749>; Sun, 11 Oct 1992 17:15:24 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 11 Oct 1992 17:15:15 -0700 To: yakov@watson.ibm.com Cc: deering@parc.xerox.com, big-internet@munnari.oz.au Subject: Re: EIDs In-Reply-To: Your message of "Thu, 08 Oct 92 05:45:22 PDT." <92Oct8.054523pdt.11564@alpha.xerox.com> Date: Sun, 11 Oct 1992 17:15:09 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct11.171515pdt.10779@skylark.parc.xerox.com> Yakov wrote: > ... Just to add, there are three > proposals on the table about supporting mobility with IP. > At least two of then (Columbia and IBM) work *perfectly* fine > without requiring topology-independent EIDs. I suspect that > the third proposal (from Sony) shares this property as well. Yes, all three proposals work with current IP addresses only, and benefit from using a topologically-significant address as a "host ID". I did not mean to slight the other proposals when using the Columbia scheme as an example. Steve From owner-big-internet@munnari.oz.au Mon Oct 12 11:14:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26529; Mon, 12 Oct 1992 11:15:11 +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 AA25207; Mon, 12 Oct 1992 10:41:24 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12756>; Sun, 11 Oct 1992 17:40:46 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 11 Oct 1992 17:40:37 -0700 To: Juha Heinanen Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Multiple addresses [partial mesh subnets] In-Reply-To: Your message of "Thu, 08 Oct 92 23:18:50 PDT." <9210092245.15306@munnari.oz.au> Date: Sun, 11 Oct 1992 17:40:30 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct11.174037pdt.10779@skylark.parc.xerox.com> Juha wrote: > in case of CLNS you don't have to give a list of addresseses of the > other routers, since it is enough that you indicate that you want to run > CLNS over a particular VC. then ES-IS takes care the rest, ie. finds > the addresses. I presume this only works in the case of permanent VCs? When running IP or CLNS over an X.25 subnetwork, aren't VCs typically established on demand as packets to new destinations arrive? One question about this magical ES-IS: in a subnetwork of the type you have been discussing, how does an IS know whether or not to send a Redirect to a neighboring ES who is trying to reach another ES on the same subnetwork, given that the two ESs may or may not be able to communicate directly with each other? Steve From owner-Big-Internet@munnari.oz.au Mon Oct 12 11:29:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27092; Mon, 12 Oct 1992 11:29:33 +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 AA27085; Mon, 12 Oct 1992 11:29:11 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA02775; Sun, 11 Oct 92 21:28:49 -0400 Date: Sun, 11 Oct 92 21:28:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210120128.AA02775@ginger.lcs.mit.edu> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: Splitting the network layer: take 2 Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu in metro-based routing, packets are forwarded first towards the destination metro (staying within the initial provider's facilities as far as possible), and then towards the destination's provider. It would be nice to see some details of how this is caused to happen (other than using a lot of hand-finagled tables, which I assume is not the scheme you have in mind). How are you going to ensure that a dynamic routing system does this? There are many ways to lose; e.g. if you try and do it just with simple metrics, you might find that the path from your metro S to metro D through carrier X, which is better organized internally, is a lot shorter than the path through your carrier C, and the traffic would take the wrong carrier. That does not, however, necessarily mean that all provider routers within the metro have to individually "track" all sites (e.g., they can get by with only tracking their own subscribers, and knowing where to send packets for subscribers other than their own) Well, as far as I can tell you've just swept the problem under the rug one level. If the routing doesn't keep track of where all the subscribers are, *some* system will have to (although I admit it could be a little less dynamic than the routing system), and that system is going to have to map the subscriber identifiers into something which says which provider the subscriber is connected to, i.e. something like what I call an "address". I'm sorry if I missed your definition ... An "address" is a unique label for a node or (in the case of multicast) set of nodes in the internet. (This definition intentionally does not say whether or not a "node" is a network interface, a box, or a "pseudo-node" representing a subnetwork; it may be any or all of those.) My definition (which I've given before) is that a fully qualified (i.e. not the name of a piece of the topology) address is the name of an attachment point to the network; i.e. a place when an endpoint can receive packets. Another way to look at it is the address is the name of the place in the network that the system of routers (and a VM system sorting packets out to the N virtual machines running on it is a router) delivers packets to. (I know I usually refer to this as an interface, but I've realized that can be a little confusing. In 98% of the cases, packets are delivered to an hardware interface (card or chips or whatever), but it's not always a perfect fit. I guess the appropriate term is 'hardware address on a physical network'; i.e. the finest grain a router can see and send packets too. If I understand ISOese, this is an SNPA, right?) Addresses are names which usually contain structure, and the structure is useful to the routing system in minimizing the costs of running the routing. In other words, it's perfectly feasible to have addresses be flat numbers with no structure at all, but then the routing system has to track each destination individually. The structure allows a reduction in the costs of running the routing by aggregating information about groups of destinations. Addresses can also, as referred to above, name regions of the topology, but this usage is much less common, and is usually only visible inside the routing system. Note that the definition of "address" does not prevent a node from keeping its address when it "moves" in the topology But if it does this, its address cease to be its 'real' (i.e. topologically significant) address, and becomes only a 'box name' "address". Somebody (or bodies), somewhere, must know what the real address of the box is, and do appropriate magic to relate the two. You've got the two different concepts of 'topology location' and 'box identifier', but you've mixed them together, and gotten the names out of the same namespace; i.e. the namespace really contains two different kinds of names. This, to me, is a certain recipe for problems and lack of flexibilty in the long run. One solution is to add another level of indirection In other words, your phone number has to get mapped to something which say where you *really* are in the phone topology. This latter thing sounds like what I call an address, in which case the former thing *isn't*. all carriers serving subscribers in the same area code could maintain a shared database that maps each of the 10,000,000 phone numbers in the area to a (carrier, local office) pair I see; this is the EID->address mapping database, right? Noel From owner-big-internet@munnari.oz.au Mon Oct 12 11:43:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27791; Mon, 12 Oct 1992 11:43:50 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210120143.27791@munnari.oz.au> Received: from avalon.mpce.mq.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25232; Mon, 12 Oct 1992 10:42:35 +1000 (from andrewm@avalon.mpce.mq.edu.au) Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA22669; Mon, 12 Oct 92 10:43:33 est From: Andrew Myles Subject: Re: EIDs To: deering@parc.xerox.com (Steve Deering) Date: Mon, 12 Oct 92 10:43:32 EST Cc: big-internet@munnari.oz.au In-Reply-To: <92Oct11.165956pdt.10779@skylark.parc.xerox.com>; from "Steve Deering" at Oct 11, 92 4:59 pm Mailer: Elm [revision: 64.9] G'day Steve, > > The Columbia proposal doesn't really have a location+EID spilt but just an > > EID. The packet is passed to a distributed router that then uses a private > > protocol to locate the mobile in a limited area. > > > > On the other hand both the IBM and Sony protocols have two separate > > addresses. > > The Columbia scheme *does* use a separate "location" identifier in most > packets forwarded to mobile hosts -- it's the destination address in the > encapsulating IP header. A mobile host never sees an encapsulated packet (except a popup - but that is an exception in the Columbia protocol) and thus never sees a location address. The address is hidden in the private protocol that a group of MSR's run to make up a distributed router. But then again it is all just a matter of semantics. I certainly don't care. Andrew -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: High Speed Networks Group, Electronics Discipline, School of Mathematics, Physics, Computing and Electronics, Macquarie University 2109, Sydney, Australia. Telephone: +61 2 8058439 (W), +61 2 8058983 (Fax), +61 2 8786060 (H). s that the primary death mode for big systems is in entropy; i.e. the accumulation of warts, usually added to solve specific problems, which eventually encumber the system from growing and changing cleanly to meet new demands. Far better, when new capabilities are needed, to think about the problem and come to a new paradigm which provides the things you need as a side effect of a complete redesign. Noel From owner-big-internet@munnari.oz.au Mon Oct 12 12:12:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28855; Mon, 12 Oct 1992 12:12:56 +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 AA26188; Mon, 12 Oct 1992 11:06:14 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12762>; Sun, 11 Oct 1992 18:05:48 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 11 Oct 1992 18:05:41 -0700 To: Andrew Myles Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: EIDs In-Reply-To: Your message of "Mon, 12 Oct 92 08:43:32 PDT." <92Oct11.174231pdt.12755@alpha.xerox.com> Date: Sun, 11 Oct 1992 18:05:27 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct11.180541pdt.10779@skylark.parc.xerox.com> > A mobile host never sees an encapsulated packet (except a popup - but that > is an exception in the Columbia protocol) Andrew, Not to drag this out too much further, but I think that is an inaccurate characterization of the Columbia scheme. Support for "pop-ups" is a fundamental part of the approach, which allows roaming beyond the home campus -- it not an "exception" (even if ji sometimes seems to describe it that way). By the way, the fact that a mobile host does not see any encapsulating headers when it is in its home campus is a positive feature that reinforces my point that it is not necessary to put both an host ID and a host location in *every* packet, to support mobility. Steve From owner-big-internet@munnari.oz.au Mon Oct 12 12:21:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29190; Mon, 12 Oct 1992 12:21:09 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210120221.29190@munnari.oz.au> Received: from avalon.mpce.mq.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24397; Mon, 12 Oct 1992 10:18:51 +1000 (from andrewm@avalon.mpce.mq.edu.au) Received: by avalon.mpce.mq.edu.au (15.11/15.6) id AA22635; Mon, 12 Oct 92 10:19:50 est From: Andrew Myles Subject: Re: IP option test (long) To: Z.Wang@cs.ucl.ac.uk Date: Mon, 12 Oct 92 10:19:48 EST Cc: Big-Internet@munnari.OZ.AU In-Reply-To: <9210090624.23571@munnari.oz.au>; from "Zheng Wang" at Oct 08, 92 6:43 pm Mailer: Elm [revision: 64.9] G'day Re: your IP option test. > A number of recent proposals (e.g. EIP, IBM mobile IP and Sony mobile IP) > make use of the IP options to add new features within the current IP > header format. > > Some people have expressed following concerns as to: > > 1) whether the presence of IP option may have visible performance penalty, and Despite your results I believ there is a significant performance loss. It has not shown up in your tests I suspect beacause the routers were not significantly loaded. I have seen real router code from a commercial router and there is a significantly longer path for any IP option compared to an optionless packet. The Sony protocol has an additional problme in not only does each router have to deal with an option must also must do significant processing at every Sonified router to look up and update AMT cache entries. > 2) whether current IP routers and hosts in the Internet can deal with > unknow IP options properly (i.e. ignoring unknown IP options > silently as required by RFC-1122 and router requirement draft). I have not found many problems but I when I did the same test as you (minus the timings) some time ago (published on the mobile-ip mailing list) I noted at least a couple of routers that did not handle undefined options correctly. Summary of problems found as follows (I did not do an exhaustive search): 1) su-a.barrnet.net (131.119.254.201) and su-b.barrnet.net (131.119.254.200) These routers (cisco CSC-3 ?) passed packets with options OK but seemed to drop them when the echo was directed at the router. 2) NCSA Telnet hosts Always drops packets with options. Possibly other PC based sw packages have the same problem; NCSA Telenet was the only one I tried. 3) sirius.llnl.gov (128.115.14.27) I don't know what this is except that it is a host and not a router. 4) HP27285A router Always drops packets with undefined options and sends an ICMP Problem Parameter packet. This is consistent with page 9 of RFC792. It is also better than the other hosts/routers I found that simply dropped the packet silently. There is however an error in the problem parameter packet produced in that the pointer fields points to the wrong place. Oh well, no one is perfect. Andrew PS What happened to the UCL proposal for mobile ip? -- -------------------------------------------------------------------------------- In-Real-Life: Andrew Myles E-Mail: andrewm@mpce.mq.edu.au Organisation: High Speed Networks Group, Electronics Discipline, School of Mathematics, Physics, Computing and Electronics, Macquarie University 2109, Sydney, Australia. Telephone: +61 2 8058439 (W), +61 2 8058983 (Fax), +61 2 8786060 (H). From owner-Big-Internet@munnari.oz.au Mon Oct 12 14:43:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04064; Mon, 12 Oct 1992 14:44:01 +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 AA04028; Mon, 12 Oct 1992 14:43:04 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12743>; Sun, 11 Oct 1992 21:42:31 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 11 Oct 1992 21:42:20 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Splitting the network layer: take 2 In-Reply-To: Your message of "Sun, 11 Oct 92 18:28:49 PDT." <9210120128.AA02775@ginger.lcs.mit.edu> Date: Sun, 11 Oct 1992 21:42:10 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct11.214220pdt.10779@skylark.parc.xerox.com> > It would be nice to see some details of how this is caused to happen (other > than using a lot of hand-finagled tables, which I assume is not the scheme > you have in mind). It would be nice to find the time to explain the details! Maybe if I stopped trying to match your posting rate, I could get on with the important stuff. :-) > Well, as far as I can tell you've just swept the problem under the rug one > level. If the routing doesn't keep track of where all the subscribers are, > *some* system will have to (although I admit it could be a little less > dynamic than the routing system), and that system is going to have to map > the subscriber identifiers into something which says which provider the > subscriber is connected to, i.e. something like what I call an "address". With the kind of "hierarchical addresses" that I defined, a router operating at level i must be able to map the flat space of subordinate level i+1 labels into "next hop" information (i.e., outgoing interface and, if not a point-to- point link, a next router identifier of some sort). That mapping may be done via a distributed, dynamic routing algorithm, by a "route server", by static tables, by indirection through a replicated database, by a broadcast search protocol such as ARP, by broadcasting packets within the region and having everyone except the right "next hops" ignore them, or by any number of other mechanisms. It may well be appropriate to use different mechanisms within different regions, and at different levels in the hierarchy. In the case of intra-metro routers, the mapping is not "into something which says which provider the subscriber is connected to", but rather to a next hop that happens to lead towards the destination's provider. Yes, I guess you are going to have to put up with the pain in the ass of different definitions for "address", since your definition seems to be different than mine. I think my definition is closer to the usage of "address" in most datagram technologies, such as IP, CLNP, AppleTalk, XNS, DECnet, Ethernet, etc. Shall we use the terms "Chiappa-address" and "Deering-address"? > Note that the definition of "address" does not prevent a node from > keeping its address when it "moves" in the topology > > But if it does this, its address cease to be its 'real' (i.e. > topologically significant) address, and becomes only a 'box name' "address". > Somebody (or bodies), somewhere, must know what the real address of the box > is, and do appropriate magic to relate the two. Which are the "real addresses" on an Ethernet? > all carriers serving subscribers in the same area code could maintain a > shared database that maps each of the 10,000,000 phone numbers in the > area to a (carrier, local office) pair > > I see; this is the EID->address mapping database, right? No, because you can't keep the same phone number if you switch to a carrier in a different area code. Steve From owner-Big-Internet@munnari.oz.au Mon Oct 12 17:43:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10035; Mon, 12 Oct 1992 17:43:49 +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 AA09997; Mon, 12 Oct 1992 17:43:11 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11553>; Mon, 12 Oct 1992 00:42:32 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Mon, 12 Oct 1992 00:42:28 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: EIDs In-Reply-To: Your message of "Sun, 11 Oct 92 18:43:54 PDT." <9210120143.AA02815@ginger.lcs.mit.edu> Date: Mon, 12 Oct 1992 00:42:19 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct12.004228pdt.10779@skylark.parc.xerox.com> Noel wrote: > So, rather than create a strong base on which to solve all these > problems (and others yet to come), by clearly distinguishing between boxes > (endpoints, actually) and network attachment points, let's just kludge our > way around the problems we see today? No, let's use the capabilities already present in our architecture (like source routing and the ability to encapsulate) to deal with problems perhaps unanticipated in the original design. Far from being a kludge, it shows how powerful the basic IP architecture really is. Steve From owner-big-internet@munnari.oz.au Mon Oct 12 18:10:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11011; Mon, 12 Oct 1992 18:10:08 +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 AA04774; Mon, 12 Oct 1992 15:11:15 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <12743>; Sun, 11 Oct 1992 22:10:33 PDT Received: from localhost by skylark.parc.xerox.com with SMTP id <10779>; Sun, 11 Oct 1992 22:10:22 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: EIDs In-Reply-To: Your message of "Sun, 11 Oct 92 18:43:54 PDT." <9210120143.AA02815@ginger.lcs.mit.edu> Date: Sun, 11 Oct 1992 22:10:14 PDT Sender: Steve Deering From: Steve Deering Message-Id: <92Oct11.221022pdt.10779@skylark.parc.xerox.com> Quoting me, Noel wrote: > plus the (minor) bandwidth, storage, and processing overhead of > carrying and operating on an EID in every packet > > You are making an assumption (actually 2 assumptions) here I don't > agree with. First, you assume that every packet will contain the EID *and* > the address. Second, and minor, you assume addresses are shortish, fixed > length jobs (as in SIP). Yes, that is correct; those are my assumptions. Sorry for not stating them explicitly. > Packets which are part of ongoing flows have no need to have the > address in each and every packet. That should reduce the cost of 'bandwidth, > storage and processing' substantially. Second, if the addresses are not > shortish and fixed length, then EID's are *cheaper*, since they should have > these attributes. I agree. However, my proposal is to retain the proven, address-in-every- packet datagram architecture upon which the current Internet is built, rather than switch to a primarily flow-based architecture. I have intentionally proposed shortish, fixed-length addresses to try to keep the costs of full addresses in every packet low (no more expensive than your EIDs, if you end up with 64-bit EIDs). Steve From owner-Big-Internet@munnari.oz.au Mon Oct 12 19:46:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15009; Mon, 12 Oct 1992 19:47:07 +1000 (from owner-Big-Internet) Return-Path: Received: from [131.176.23.25] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15004; Mon, 12 Oct 1992 19:46:51 +1000 (from root@estbc8.estec.esa.nl) Received: by estbc8.estec.esa.nl (AIX 3.2/UCB 5.64/4.03) id AA08760; Mon, 12 Oct 1992 10:45:24 +0200 Date: Mon, 12 Oct 1992 10:45:24 +0200 From: root@estbc8.estec.esa.nl Message-Id: <9210120845.AA08760@estbc8.estec.esa.nl> To: big-internet@munnari.oz.au Subject: Subscribe Please could you add me to the big-internet mailing list regards, Rob. From owner-Big-Internet@munnari.oz.au Mon Oct 12 20:47:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17408; Mon, 12 Oct 1992 20:47:25 +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 AA17392; Mon, 12 Oct 1992 20:47:03 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA01699; Mon, 12 Oct 1992 11:47:22 +0100 Message-Id: <199210121047.AA01699@mitsou.inria.fr> To: rboivie@vnet.ibm.com Cc: big-internet@munnari.oz.au Subject: Re: time to live In-Reply-To: Your message of "Fri, 09 Oct 92 09:00:01 EDT." <9210092355.20892@munnari.oz.au> Date: Mon, 12 Oct 92 11:47:20 -0500 From: Christian Huitema X-Mts: smtp >Why not just put in a value that indicates how long you would like the packet >to live (in microseconds or nanoseconds or something) and have the routers >along the way decrement that value based on their best estimate as to how >long they held onto the packet and how much time was spent on the links >in between? This is precisely what was specified in the original IP. Basically, one needs a time limit in order to guarantee the correctness of all protocols that use "periodic counters": these protocols cannot be proven safe if there is no way to distinguish betwen a new packet and a reincarnation of an old packet. Thus, the requirements contains phrases like "the counter shall not wrap in less than twice the maximum network transit time". Which mean that you should really have an estimate of the "maximum network transit time" lying somewhere in the network specs + actively enforce it in the network protocol. The problem with the algorithm you describe is that it cannot be properly implemented. The transit time in a host depends on one little parameter, the queuing time on the output link. This varies with the length of the local queues, that you may or may not be willing to estimate -- it requires some computation. Moreover, on some networks, e.g. Ethernets or token rings, the access time can vary considerably depending on the load of the other nodes in the network; this is very difficult to estimate. Microsecond precision would suppose that the TTL is decremented after computing the exact transit delay, i.e. just after getting the "token" or after sending the first bytes of the packets on the Ethernet. Think twice! In practice, it has been observed that the attempts to precisely compute a "TTL" were not conclusive. For this reason, SIP proposes to just count the number of hops, actually legislating the current practice. It means that the end to end protocols will have to realize that the famous "maximum network transit time" should be handled with great care, e.g. using something like . And a silly maximum is exactly that: I have seen statistics where packets had stayed several minutes in a hop, due to a malfunctioning hardware component. Christian Huitema From owner-Big-Internet@munnari.oz.au Mon Oct 12 22:57:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22520; Mon, 12 Oct 1992 22:57:44 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210121257.22520@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22517; Mon, 12 Oct 1992 22:57:30 +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 ; Mon, 12 Oct 1992 13:56:29 +0100 To: David Oran Cc: big-internet@munnari.oz.au Subject: Re: IP option test (long) In-Reply-To: Your message of "Fri, 09 Oct 92 11:22:23 EDT." <921009112223.13756@sneezy.lkg.dec.com> Date: Mon, 12 Oct 92 13:56:25 +0100 From: Zheng Wang >P.S. one question I have about your test is whether it uses a defined >but potentially un-implemented IP option, or an undefined IP >option. It is possible that this would elicit different behavior in the >routers. I used an IP option that is not defined anywhere. Cheers Zheng From owner-Big-Internet@munnari.oz.au Mon Oct 12 22:54:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22406; Mon, 12 Oct 1992 22:55:16 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210121255.22406@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22343; Mon, 12 Oct 1992 22:54:50 +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 ; Mon, 12 Oct 1992 13:54:09 +0100 To: Dave Katz Cc: big-internet@munnari.oz.au Subject: Re: IP option test (long) In-Reply-To: Your message of "Fri, 09 Oct 92 07:57:20 PDT." <9210091457.AA09961@regal.cisco.com> Date: Mon, 12 Oct 92 13:54:04 +0100 From: Zheng Wang >The latency of a single ping packet would probably not be visibly changed >(especially when compared to other latency factors) but the aggregate switching >capacity is far lower (by some number of orders of magnitude >= 1) when >options are present. Using "ping" is NOT reliable. I have seen several seconds when "ping" a local router with source route option. I was told some routers give ICMP lower priority when processing IP packets. If you using TCP/UDP with options, I would be surprised if you can produce noticable results. Cheers Zheng From owner-Big-Internet@munnari.oz.au Mon Oct 12 23:14:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23011; Mon, 12 Oct 1992 23:15:00 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210121315.23011@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23008; Mon, 12 Oct 1992 23:14:52 +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 ; Mon, 12 Oct 1992 14:14:23 +0100 To: jim@tadpole.com (Jim Thompson) Cc: big-internet@munnari.oz.au, ji@cs.columbia.edu Subject: Re: IP option test (long) In-Reply-To: Your message of "Fri, 09 Oct 92 14:21:00 CDT." <9210091421.ZM12914@tadpole> Date: Mon, 12 Oct 92 14:14:21 +0100 From: Zheng Wang >John Ioannidis (ji@cs.columbia.edu) performed an experiment only >a few months ago that shows just how badly source routing is broken. >VMS, HP-UX, SunOS, BSD, they're all broken with regard to source >routing, some worse than others. I have seen the report on mobile-ip list. >(Hint, try UDP port 7, instead of TCP port 7.) I was mainly testing IP level handling for undefined options. So UDP makes no difference. >Note as well that there is movement afoot to use IP encapsulation instead >of source routing for IP multicast 'tunnels'. Several reasons, including >efficiency. Are you suggesting that source routing is inherently slower than encapsulation? (By inherently, I mean it is not caused by bad implementation). Looking at the code, I find it very hard to believe! Cheers Zheng From owner-Big-Internet@munnari.oz.au Mon Oct 12 23:22:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23328; Mon, 12 Oct 1992 23:22:21 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210121322.23328@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23325; Mon, 12 Oct 1992 23:22:05 +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 ; Mon, 12 Oct 1992 14:21:34 +0100 To: Tony Li Cc: big-internet@munnari.oz.au Subject: Re: IP options In-Reply-To: Your message of "Sat, 10 Oct 92 01:54:42 PDT." <9210100854.AA08210@lager.cisco.com> Date: Mon, 12 Oct 92 14:21:32 +0100 From: Zheng Wang >The answer to #2 is known. There are certain routers and hosts (from >a variety of vendors) that misbehave in different ways on different >options. I will not point fingers. It is true that not all implementations handle options correctly. But I would say the majority are more or less meet the standard requirements. >In any case, I would claim that this is irrelevant. If you create a >demand for a feature, bad implementations of that feature will get >corrected. If performance for that feature is poor, then it will >become a marketing issue and performance will improve. This is simply >a chicken and egg problem. If you force the issue it will go away. I agree. Some of the poor performance seen is probably caused by bad implemetations. Cheers Zheng From owner-Big-Internet@munnari.oz.au Tue Oct 13 00:08:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25540; Tue, 13 Oct 1992 00:09:37 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210121409.25540@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25525; Tue, 13 Oct 1992 00:08:37 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <06114-0@datanet.tele.fi>; Mon, 12 Oct 1992 16:07:31 +0200 To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, deering@parc.xerox.com In-Reply-To: <92Oct11.174037pdt.10779@skylark.parc.xerox.com> "deering@parc.xerox.com" Subject: Multiple addresses [partial mesh subnets] Date: Mon, 12 Oct 1992 16:07:31 +0200 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi I presume this only works in the case of permanent VCs? When running IP or CLNS over an X.25 subnetwork, aren't VCs typically established on demand as packets to new destinations arrive? ES-IS is not usually run over SVCs, since when doing so, the router would establish the connection each time an ES-IS hello is sent which in practice would mean that the SVC is always up. One question about this magical ES-IS: in a subnetwork of the type you have been discussing, how does an IS know whether or not to send a Redirect to a neighboring ES who is trying to reach another ES on the same subnetwork, given that the two ESs may or may not be able to communicate directly with each other? it is usuallly a configuration option. if the multi-access interface is used in point-to-point fashion, then the redirects are turned off. Steve From owner-big-internet@munnari.oz.au Tue Oct 13 01:19:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28329; Tue, 13 Oct 1992 01:19:40 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210121519.28329@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23877; Mon, 12 Oct 1992 23:35:57 +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 ; Mon, 12 Oct 1992 14:35:36 +0100 To: Dave Katz Cc: big-internet@munnari.oz.au Subject: Re: IP option test (long) In-Reply-To: Your message of "Fri, 09 Oct 92 07:57:20 PDT." <9210091457.AA09961@regal.cisco.com> Date: Mon, 12 Oct 92 14:35:31 +0100 From: Zheng Wang >performance problems were triggered in some places in the internet due to >the audio/video multicasts during the last IETF meeting. Is there any evidence indicating that the problem is caused by the source route? Many places were having problems during the aduio/video multicast because they dont have sufficient bandwidth. Cheers Zheng From owner-big-internet@munnari.oz.au Tue Oct 13 01:33:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28838; Tue, 13 Oct 1992 01:33:50 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210121533.28838@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23708; Mon, 12 Oct 1992 23:32:12 +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 ; Mon, 12 Oct 1992 14:31:46 +0100 To: Andrew Myles Cc: Big-Internet@munnari.OZ.AU Subject: Re: IP option test (long) In-Reply-To: Your message of "Mon, 12 Oct 92 10:19:48 EST." Date: Mon, 12 Oct 92 14:31:43 +0100 From: Zheng Wang >I have seen real router code from a commercial router and there is a >significantly longer path for any IP option compared to an optionless packet. I only looked at the BSD code. It seems to be fair simple really, especially when the router does not have to process anything to the option. >I have not found many problems but I when I did the same test as you (minus >the timings) some time ago (published on the mobile-ip mailing list) I noted >at least a couple of routers that did not handle undefined options correctly. I have seen you message to the mobile-ip. But as I said in a previous message, using "ping" is not reliable for testing. Try testing with TCP/UDP with option. Cheers Zheng From owner-Big-Internet@munnari.oz.au Tue Oct 13 01:58:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29762; Tue, 13 Oct 1992 01:58:22 +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 AA29755; Tue, 13 Oct 1992 01:58:12 +1000 (from lixia@parc.xerox.com) Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <11706>; Mon, 12 Oct 1992 08:57:54 PDT Received: by redwing.parc.xerox.com id <57160>; Mon, 12 Oct 1992 08:57:49 -0700 Date: Mon, 12 Oct 1992 08:57:33 PDT Sender: Lixia Zhang From: Lixia Zhang Reply-To: lixia@parc.xerox.com To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: EIDs In-Reply-To: Your message of Sun, 11 Oct 1992 18:43:54 -0700 Message-Id: > Packets which are part of ongoing flows have no need to have the > address in each and every packet. That should reduce the cost of 'bandwidth, > storage and processing' substantially. Second, if the addresses are not > shortish and fixed length, then EID's are *cheaper*, since they should have > these attributes. Noel, As much as I support a "flow-oriented" architecture, I still cannot convince myself to remove addresses from pkt header. - There will always be datagrams (if we dont want to fool ourselvies by calling a single datagram a "fast connection"). - In their recent paper on experience with ST-II implementation (in some issue of Journal of Internetworking this year), Craig and Steve (Pink) clearly pointed out the shortcomings of carrying only connection-ID in each pkt (that are part of ongoing flows). Lixia From owner-Big-Internet@munnari.oz.au Tue Oct 13 02:38:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01442; Tue, 13 Oct 1992 02:38:53 +1000 (from owner-Big-Internet) Return-Path: Received: from dg-rtp.rtp.dg.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01438; Tue, 13 Oct 1992 02:38:43 +1000 (from throop@dg-rtp.dg.com) Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4.1/dg-rtp-proto) id AA09650; Mon, 12 Oct 1992 12:38:37 -0400 Received: by walrus (5.4.1/140.2) id AA17579; Mon, 12 Oct 1992 12:36:05 -0400 Date: Mon, 12 Oct 1992 12:36:05 -0400 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9210121636.AA17579@walrus> To: Big-Internet@munnari.oz.au Subject: Re: what is the diameter of current Internet > 1) The longest route is to South Africa (21 hops) and next > to Brazil (20 hops). Maybe someone really at the edge of the > Internet can produce even longer route? My tracetroute to Japan exceeded the 30 hop limit traceroute had build in. 1 polaris (128.222.8.30) 10 ms 10 ms 0 ms 2 /cisco (128.222.1.204) 10 ms 20 ms 20 ms 3 dgrtpgw3-1 (128.222.250.8) 10 ms 10 ms 20 ms 4 apex-cisco-alt4.us.dg.com (128.222.123.4) 30 ms 20 ms 20 ms 5 img-cisco-2-alt3.webo.dg.com (128.221.123.1) 70 ms 30 ms 30 ms 6 psi-cisco.webo.dg.com (128.221.137.29) 40 ms 30 ms 30 ms 7 dg.boston.pop.psi.net (38.145.227.1) 240 ms 60 ms 50 ms 8 38.1.8.1 (38.1.8.1) 80 ms 90 ms 80 ms 9 38.1.2.1 (38.1.2.1) 140 ms 140 ms 130 ms 10 syr.cornell.site.psi.net (38.145.10.2) 140 ms 340 ms 150 ms 11 ENSS.TN.CORNELL.EDU (192.35.82.101) 140 ms 140 ms 130 ms 12 t3-1.cnss49.t3.nsf.net (140.222.49.2) 150 ms 400 ms 170 ms 13 t3-3.cnss48.t3.nsf.net (140.222.48.4) 120 ms 160 ms * 14 t3-2.cnss32.t3.nsf.net (140.222.32.3) 150 ms 140 ms 170 ms 15 t3-1.cnss40.t3.nsf.net (140.222.40.2) 170 ms 150 ms 160 ms 16 t3-2.cnss24.t3.nsf.net (140.222.24.3) 220 ms * 180 ms 17 * t3-1.cnss8.t3.nsf.net (140.222.8.2) 420 ms 1240 ms 18 t3-0.cnss9.t3.nsf.net (140.222.9.1) 220 ms 220 ms 190 ms 19 * t3-0.enss144.t3.nsf.net (140.222.144.1) 200 ms 400 ms 20 ARC2.NSN.NASA.GOV (192.52.195.11) 200 ms 210 ms * 21 imp.Hawaii.Net (132.160.249.1) 250 ms 250 ms 260 ms 22 menehune.Hawaii.Net (132.160.1.1) 250 ms 280 ms 270 ms 23 132.160.251.2 (132.160.251.2) 360 ms 390 ms 370 ms 24 jp-gate.wide.ad.jp (133.4.1.1) 400 ms 370 ms 370 ms 25 endo.wide.sfc.keio.ac.jp (133.4.11.2) 390 ms 380 ms 400 ms 26 r48-gw.sfc.keio.ac.jp (133.27.48.1) 360 ms 420 ms 390 ms 27 133.27.4.254 (133.27.4.254) 410 ms 380 ms 580 ms 28 hc-relay.hc.keio.ac.jp (131.113.224.1) 420 ms 390 ms 440 ms 29 kobkf-relay.cm.phys.keio.ac.jp (131.113.224.3) 430 ms 450 ms 400 ms 30 * newton.kw.phys.keio.ac.jp (131.113.44.1) 390 ms 390 ms Dean Throop throop@dg-rtp.dg.com From owner-Big-Internet@munnari.oz.au Tue Oct 13 02:47:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01863; Tue, 13 Oct 1992 02:47:59 +1000 (from owner-Big-Internet) Return-Path: Received: from regal.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01859; Tue, 13 Oct 1992 02:47:51 +1000 (from dkatz@cisco.com) Received: by regal.cisco.com; Mon, 12 Oct 92 09:47:37 -0700 Date: Mon, 12 Oct 92 09:47:37 -0700 From: Dave Katz Message-Id: <9210121647.AA27076@regal.cisco.com> To: Z.Wang@cs.ucl.ac.uk Cc: big-internet@munnari.oz.au In-Reply-To: Zheng Wang's message of Mon, 12 Oct 92 14:35:31 +0100 <9210121335.AA13060@wolf.cisco.com> Subject: IP option test (long) Let me rephrase. I know how the cisco and NSFNET implementations are done, and I can guarantee that adding source route options (or any others) will degrade aggregate throughput. Of course, if such options were used often, it is likely that most vendors would optimize this code path as well, but today's implementations will suffer badly. I suspect this to be the case in almost all implementations. Date: Mon, 12 Oct 92 13:54:04 +0100 From: Zheng Wang >The latency of a single ping packet would probably not be visibly changed >(especially when compared to other latency factors) but the aggregate switching >capacity is far lower (by some number of orders of magnitude >= 1) when >options are present. Using "ping" is NOT reliable. I have seen several seconds when "ping" a local router with source route option. I was told some routers give ICMP lower priority when processing IP packets. If you using TCP/UDP with options, I would be surprised if you can produce noticable results. Cheers Zheng Date: Mon, 12 Oct 92 14:35:31 +0100 From: Zheng Wang >performance problems were triggered in some places in the internet due to >the audio/video multicasts during the last IETF meeting. Is there any evidence indicating that the problem is caused by the source route? Many places were having problems during the aduio/video multicast because they dont have sufficient bandwidth. Cheers Zheng From owner-Big-Internet@munnari.oz.au Tue Oct 13 02:50:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01989; Tue, 13 Oct 1992 02:50:45 +1000 (from owner-Big-Internet) Return-Path: Received: from regal.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01982; Tue, 13 Oct 1992 02:50:34 +1000 (from dkatz@cisco.com) Received: by regal.cisco.com; Mon, 12 Oct 92 09:50:20 -0700 Date: Mon, 12 Oct 92 09:50:20 -0700 From: Dave Katz Message-Id: <9210121650.AA27254@regal.cisco.com> To: Z.Wang@cs.ucl.ac.uk Cc: tli@cisco.com, big-internet@munnari.oz.au In-Reply-To: Zheng Wang's message of Mon, 12 Oct 92 14:21:32 +0100 <9210121322.23328@munnari.oz.au> Subject: IP options Date: Mon, 12 Oct 92 14:21:32 +0100 From: Zheng Wang I agree. Some of the poor performance seen is probably caused by bad implemetations. Cheers Zheng Perhaps a less pejorative term would be "engineering tradeoffs." From owner-Big-Internet@munnari.oz.au Tue Oct 13 02:51:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02021; Tue, 13 Oct 1992 02:51:10 +1000 (from owner-Big-Internet) Return-Path: Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02018; Tue, 13 Oct 1992 02:51:05 +1000 (from derich@netcom.com) Received: from netcom.netcom.com by ux1.cso.uiuc.edu with SMTP id AA17084 (5.67a8/IDA-1.5 for ); Mon, 12 Oct 1992 11:50:51 -0500 Received: by netcom.netcom.com (5.65/SMI-4.1/Netcom) id AA11012; Mon, 12 Oct 92 09:50:19 -0700 Newsgroups: alt.bbs.internet,info.big-internet,alt.best.of.internet,netcom.internet Path: derich From: derich@netcom.com (Scott A. Steinbrink) Subject: Italy telnet address? Message-Id: <1992Oct12.165012.10943@netcom.com> Followup-To: ODposter Organization: Netcom - Online Communication Services (408 241-9760 guest) Date: Mon, 12 Oct 1992 16:50:12 GMT Apparently-To: info-big-internet@ux1.cso.uiuc.edu Help --- Is there a telnet address at IRMCNR -- the internet address is .ced.rm.cnr.it - Scott -- Scott Allen Steinbrink NetCom: Derich@netcom.com CompuServe: 76106.2055@CompuServe.Com America Online: Derichman Bitnet: 11sstein%gallua.bitnet@cunyvm.cuny.edu InterCon: tissue@intercon.com All opinions and remarks are not my responsbility - it's my own mind's full responsbility. I just speak what it commands me to say. "Deaf people can do anything except hear" - I. King Jordan From owner-Big-Internet@munnari.oz.au Tue Oct 13 03:41:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03024; Tue, 13 Oct 1992 03:42:06 +1000 (from owner-Big-Internet) Return-Path: Received: from LOBSTER.WELLFLEET.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03017; Tue, 13 Oct 1992 03:41:50 +1000 (from jkrawczy@wellfleet.com) Received: from hobbes.wellfleet ([192.32.1.254]) by lobster.wellfleet.com (4.1/SMI-4.1) id AA26590; Mon, 12 Oct 92 13:38:50 EDT Received: by hobbes.wellfleet (4.1/SMI-4.1) id AA02498; Mon, 12 Oct 92 13:42:06 EDT Date: Mon, 12 Oct 92 13:42:06 EDT From: jkrawczy@wellfleet.com (John Krawczyk) Message-Id: <9210121742.AA02498@hobbes.wellfleet> To: Z.Wang@cs.ucl.ac.uk Cc: andrewm@avalon.mpce.mq.edu.au, Big-Internet@munnari.OZ.AU In-Reply-To: Zheng Wang's message of Mon, 12 Oct 92 14:31:43 +0100 <9210121533.28838@munnari.oz.au> Subject: IP option test (long) Date: Mon, 12 Oct 92 14:31:43 +0100 From: Zheng Wang >I have seen real router code from a commercial router and there is a >significantly longer path for any IP option compared to an optionless packet. I only looked at the BSD code. It seems to be fair simple really, especially when the router does not have to process anything to the option. I don't think the BSD code is a good example of what you might see in a router vendor's product. I see real router code from a commercial router every day (;-) and, believe me, IP packets with good-ol' 20 byte headers are given preferential treatment. Cheers Zheng -jj From owner-Big-Internet@munnari.oz.au Tue Oct 13 06:08:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08152; Tue, 13 Oct 1992 06:08:57 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210122008.8152@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08147; Tue, 13 Oct 1992 06:08:49 +1000 (from perk@watson.ibm.com) Received: from YKTVMH by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3806; Mon, 12 Oct 92 16:08:47 EDT Date: Mon, 12 Oct 92 15:54:02 EDT From: perk@watson.ibm.com To: big-internet@munnari.oz.au Cc: jim@tadpole.com, ji@cs.columbia.edu, BHAGWAT@YKTVMH.watson.ibm.com Subject: Re: IP option test (long) >John Ioannidis (ji@cs.columbia.edu) performed an experiment only >a few months ago that shows just how badly source routing is broken. >VMS, HP-UX, SunOS, BSD, they're all broken with regard to source >routing, some worse than others. Clearly, this report points out the severe deficiency of many existing implementations. But on the other hand, routers usually do just fine with source routing. Moreover, there are nice Unix systems that also do just fine with source routing. I suspect that, if the code were nearly free, and the motivation were there, many vendors would be able to clean up their future releases with little difficulty. Especially if their customers were asking for the improvements. Source routing is great when it works, and I think it's about time it started working on more systems. Our project which uses source routing shows its advantages; we like it. We are "compatible" with non-source-routing systems, and hope to offer "upgrade paths". Is it really beyond hope that we can make this progress? Should we never expect networking vendors to conform to specifications? Charlie P. PS. As was pointed out on this list some months ago, which I need to study, loose source routing also can be used to implement an arbitrarily large IP address space. Will conformance with old, broken implementations also kill this opportunity to expand the address space while remaining compatible with conforming implementations? From owner-Big-Internet@munnari.oz.au Tue Oct 13 07:39:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12000; Tue, 13 Oct 1992 07:39:33 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11995; Tue, 13 Oct 1992 07:39:27 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Mon, 12 Oct 92 14:39:06 -0700 Date: Mon, 12 Oct 92 14:39:06 -0700 From: Tony Li Message-Id: <9210122139.AA22550@lager.cisco.com> To: Z.Wang@cs.ucl.ac.uk Cc: big-internet@munnari.oz.au In-Reply-To: Zheng Wang's message of Mon, 12 Oct 92 14:21:32 +0100 <9210121321.AA12987@wolf.cisco.com> Subject: IP options >The answer to #2 is known. There are certain routers and hosts (from >a variety of vendors) that misbehave in different ways on different >options. I will not point fingers. It is true that not all implementations handle options correctly. But I would say the majority are more or less meet the standard requirements. I would very strongly disagree with this, but I have NO means of convincing you without pointing fingers. I agree. Some of the poor performance seen is probably caused by bad implemetations. See Dave Katz' comment. It is not worthwhile optimizing every possible case. Tony From owner-Big-Internet@munnari.oz.au Tue Oct 13 08:58:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15343; Tue, 13 Oct 1992 08:58:44 +1000 (from owner-Big-Internet) Return-Path: Received: from cs.columbia.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15338; Tue, 13 Oct 1992 08:58:34 +1000 (from ji@close.cs.columbia.edu) Received: from close.cs.columbia.edu by cs.columbia.edu (5.65c/0.6/jba+ad) with SMTP id AA23493; Mon, 12 Oct 1992 18:57:58 -0400 Message-Id: <199210122257.AA23493@cs.columbia.edu> Received: by close.cs.columbia.edu (15.11/15.6) id AA20787; Mon, 12 Oct 92 18:57:00 edt Date: Mon, 12 Oct 92 18:57:00 edt From: John Ioannidis To: big-internet@munnari.oz.au Cc: jim@tadpole.com, ji@cs.columbia.edu, BHAGWAT@yktvmh.watson.ibm.com, perk@watson.ibm.com Subject: Re: IP option test (long) Sender: John "Heldenprogrammer" Ioannidis Reply-To: ji@cs.columbia.edu Organization: Columbia University Department of Computer Science X-Date: 21 Vendemiaire An CCI [[ Well, since my name was explicitely included, I might as well reply. I've been conspicuously absent from this discussion, but I *am* trying to graduate some time before the millenium... ]] > >John Ioannidis (ji@cs.columbia.edu) performed an experiment only > >a few months ago that shows just how badly source routing is broken. > >VMS, HP-UX, SunOS, BSD, they're all broken with regard to source > >routing, some worse than others. > In brief, the results showed that most of the aforementioned implementations do not use the recorded route for the return path, but rather either just return the recorded route, following normal routing mechanisms, or drop the recorded route altogether. Furthermore, it showed that source routing does not work with UDP-based applications, not just because of an implementation problem but also because of a conceptual problem (more about it later). I would call them broken, only in so far as they don't obey RFC791/RFC1122. Personally, I'm very happy that my BSD boxes don't reverse the recorded route. We have enough security problems as it stands. Consider J-random bored freshman cracker who discovers source routing, then cracks his local router to install host routes, and proceeds to convince machines half a continent apart which still use the source IP address for authentication that he is really in the next room. I know, people shouldn't be using .rhosts, but they are. (And if you think that random bored freshmen aren't that creative, you're wrong. They've already discovered ICMP host redirect, port unreachable and message-too-big messages to cause denial-of-service attacks). > Clearly, this report points out the severe deficiency of > many existing implementations. But on the other hand, > routers usually do just fine with source routing. Moreover, > there are nice Unix systems that also do just fine with > source routing. Oh? Which ones? Not even 4.4BSD works when the source route changes during a TCP connection, and *NONE* ever returned even the recorded route in the case of UDP applications, ranging from echo (port 7), to NFS. > > I suspect that, if the code were nearly free, and the > motivation were there, many vendors would be able to BSD4.4 code is free. It's about as free as Un*x code is ever going to get. It still doesn't conform to RFC1122. > clean up their future releases with little difficulty. > Especially if their customers were asking for the > improvements. THe point is that it's probably easier to get vendors to accept *new* features, than try to fix old ones, especially when those old features can open up entire cans of security worms (pun intentional!). > > Source routing is great when it works, and I think it's Source routing is *not* great. It forces you to carry *routing* traffic in every *data* packet. Hosts should not have to worry about routing -- routers should do that for them. It creates security problems that are not easily addressable, and slows down routers. It demands otherwise stateless protocols to keep state. Besides, the decision to use source routing should not be a unilateral decision (one end decides t o use it, and expects the other end to conform), the way it is done in the IP spec. And it doesn't work at all in cases where it is not clear what constitutes a "request" and what a "reply" (RFC1122 says that UDP applications should use the recorded route in replying to requests). ANother point here is that this requirement violates layering -- it requires transport protocols, abnd probably applications, to know about (source) routing -- not something we want. > about time it started working on more systems. Our project > which uses source routing shows its advantages; we like it. > We are "compatible" with non-source-routing systems, and > hope to offer "upgrade paths". Is it really beyond I would say that it was your project that made us exhume all the problems with source-routing. But let's not discuss this here -- bring it to the mobile-ip list. > hope that we can make this progress? Should we never > expect networking vendors to conform to specifications? For the record, the latest release of AIX (3.2) does not support source routing. I'm curious why (may I suggest that you ask the folks in Austin?), but I suspect it's because they consider it a security problem and a performance hit. > > Charlie P. > > PS. As was pointed out on this list some months ago, which > I need to study, loose source routing also can be > used to implement an arbitrarily large IP address > space. Will conformance with old, broken implementations > also kill this opportunity to expand the address space > while remaining compatible with conforming implementations? > It was suggested as a form of encapsulation in order to do tunneling, and it didn't solve the address exhaustion problem. Source routing *is* a weak form of encapsulation, used before anyone had defined encapsulation protocols. As not only I, but also the Multicast people will tell you, tunneling is better done using an encapsulation protocol rather than source routing. Besides, we really need a new IP protocol, not just hacks to make the old one work. BTW, anyone care to co-author a "Source Routing Considered Harmful" paper? ===================== Anyway, this is big-internet, so we should really be discussing issues related to big-internets. The relevance I see is whether IPv7, whatever it turns out to be, should support IPv4-style source routing. I would say NO. I would probably say NO to the idea of even having source routing at all. We have to think carefully *why* we want source-routing -- arguments along the line "we'll put it there just to have it around in case someone needs it" just don't fly. /ji In-Real-Life: John "Heldenprogrammer" Ioannidis E-Mail-To: ji@cs.columbia.edu V-Mail-To: +1 212 939 7029 or 7038 P-Mail-To: 450 Computer Science \n Columbia University \n New York, NY 10027 From owner-Big-Internet@munnari.oz.au Tue Oct 13 09:58:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17722; Tue, 13 Oct 1992 09:58:35 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210122358.17722@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17717; Tue, 13 Oct 1992 09:58:28 +1000 (from jcurran@nic.near.net) To: Steve Deering Cc: Noel Chiappa , big-internet@munnari.oz.au Subject: Re: EIDs In-Reply-To: Your message of Mon, 12 Oct 92 00:42:19 -0700. <92Oct12.004228pdt.10779@skylark.parc.xerox.com> Date: Mon, 12 Oct 92 19:58:19 -0400 From: John Curran ] From: Steve Deering ] Subject: Re: EIDs ] Date: Mon, 12 Oct 1992 00:42:19 PDT ] ] Noel wrote: ] ] > So, rather than create a strong base on which to solve all these ] > problems (and others yet to come), by clearly distinguishing between boxes ] > (endpoints, actually) and network attachment points, let's just kludge our ] > way around the problems we see today? ] ] No, let's use the capabilities already present in our architecture (like ] source routing and the ability to encapsulate) to deal with problems ] perhaps unanticipated in the original design. Far from being a kludge, ] it shows how powerful the basic IP architecture really is. Building a bigger swiss army knife may not be the best choice. Using IP's strengths to overcome unanticipated situations is a great idea, and has been occurring for some time. On the other hand, it might not be such a great idea to propagate these same workarounds to a new network architecture since relying on a capability for specific function can prevent reuse of the capability for other problems (e.g. if source routing is used extensively for mobility, how well does source routing for policy work?) /John From owner-Big-Internet@munnari.oz.au Tue Oct 13 11:18:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21552; Tue, 13 Oct 1992 11:18:44 +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 AA21549; Tue, 13 Oct 1992 11:18:36 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06451; Mon, 12 Oct 92 21:18:27 -0400 Date: Mon, 12 Oct 92 21:18:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210130118.AA06451@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, ji@cs.columbia.edu Subject: Re: IP option test (long) Cc: jnc@ginger.lcs.mit.edu A great flame! Yes, user source routing has several problems. I would probably say NO to the idea of even having source routing at all. Do you mean no user visible source routing, or no source routing at all, anywhere, period? (I.e. do you not want the routers to use a route selected by the source?) Noel From owner-Big-Internet@munnari.oz.au Tue Oct 13 11:27:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22024; Tue, 13 Oct 1992 11:28:10 +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 AA22004; Tue, 13 Oct 1992 11:27:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06370; Mon, 12 Oct 92 21:10:27 -0400 Date: Mon, 12 Oct 92 21:10:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210130110.AA06370@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, lixia@parc.xerox.com Subject: Re: EIDs Cc: jnc@ginger.lcs.mit.edu As much as I support a "flow-oriented" architecture, I still cannot convince myself to remove addresses from pkt header. Oh, I wasn't meaning to say we *never* have addresses in the packet, just not in *every* packet. It would probably be something optional, the way source routes are, but maybe using a fixed format (like fragmentation in CLNP). - There will always be datagrams (if we dont want to fool ourselvies by calling a single datagram a "fast connection"). Yes, some services (name lookup, etc) will not need or want the overhead of a flow. - In their recent paper on experience with ST-II implementation (in some issue of Journal of Internetworking this year), Craig and Steve (Pink) clearly pointed out the shortcomings of carrying only connection-ID in each pkt (that are part of ongoing flows). For those of us who don't get this, can you summarize to the list what the problems are? Noel From owner-Big-Internet@munnari.oz.au Tue Oct 13 18:02:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10219; Tue, 13 Oct 1992 18:02:16 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210130802.10219@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10216; Tue, 13 Oct 1992 18:02:10 +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 ; Tue, 13 Oct 1992 09:01:34 +0100 To: ji@cs.columbia.edu Cc: big-internet@munnari.oz.au, jim@tadpole.com, BHAGWAT@yktvmh.watson.ibm.com, perk@watson.ibm.com Subject: Re: IP option test (long) In-Reply-To: Your message of "Mon, 12 Oct 92 18:57:00 EDT." <199210122257.AA23493@cs.columbia.edu> Date: Tue, 13 Oct 92 09:01:20 +0100 From: Jon Crowcroft >Anyway, this is big-internet, so we should really be discussing issues >related to big-internets. The relevance I see is whether IPv7, >whatever it turns out to be, should support IPv4-style source routing. cannot agree here - big-internet must include backwards compatibility and migration, surely? what zheng measured was real world, not blue sky... jon From owner-Big-Internet@munnari.oz.au Tue Oct 13 21:36:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17829; Tue, 13 Oct 1992 21:36:30 +1000 (from owner-Big-Internet) Return-Path: Received: from rx7.ee.lbl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17825; Tue, 13 Oct 1992 21:36:25 +1000 (from van@ee.lbl.gov) Received: by rx7.ee.lbl.gov for big-internet@munnari.oz.au (5.65/1.44r) id AA12717; Tue, 13 Oct 92 04:37:23 -0700 Message-Id: <9210131137.AA12717@rx7.ee.lbl.gov> To: Zheng Wang Cc: big-internet@munnari.oz.au Subject: Re: IP option test (long) In-Reply-To: Your message of Mon, 12 Oct 92 14:14:21 BST. Date: Tue, 13 Oct 92 04:37:23 PDT From: Van Jacobson > Are you suggesting that source routing is inherently slower than > encapsulation? (By inherently, I mean it is not caused by bad > implementation). Yes, that is what people are saying. They are probably saying it because it's true. IPv4-style source routing is a very bad design. It is easy to show, both from a theoretical, 'computational cost of information' argument and from a practical inspection of high-quality implementations (which the 4BSD implementation is not) that forwarding an IP datagram containing a source route option is inherently *substantially* slower than forwarding a datagram with no options. For example, the performance difference is much more than an order of magnitude on a cisco (though some of that has to do with their particular multiprocessor implementation architecture) and, in the `new BSD' implementation I've done (where I tried very hard to do an efficient uniprocessor implementation) a source route increases the forwarding cost by at least a factor of 3 (29 instructions to 81 for the best case of an LSRR with the current gateway not the target) and more typically a factor of 5 (from 29 to 115 instructions if the current gateway is the target). I won't claim my code is optimal but it should be obvious from inspection that the computational cost of parsing & validating the option, doing the 2nd forwarding lookup, then updating the option and the checksum will be at least as great as the total processing cost of a minimal length IP header. Since encapsulation uses normal, no-option datagrams it sees best-case forwarding performance. I.e., an encapsulated source route has *no* performance cost if a router is not the target of the route. [Which should be a design goal since proposed uses of source routing, like the sony or ibm mobile host proposals, use LSRR with one additional hop beyond the original host & final destination. Thus all routers along the path (18-25 hops average these days) have to do substantial extra processing for no purpose, simply to accomodate an option that will only be meaningful at one place in the path.] Thus, even if processing an encapsulated source route at the target were as costly as processing an IP source route (which it isn't), the cost to the *network* is much less since the cost of encapsulation scales per-target while the cost of IP source routing scales per-hop. In the last paragraph I claimed that even at source route target(s), encapsulation processing is cheaper than IP option processing. This is not theory -- I've carefully implemented both & done a detailed analysis of the resulting code. Encapsulation was cheaper for two reasons: the actual source route processing was cheaper and the path used to get to the source route processing code was more efficient. The source route processing was cheaper for encapsulation mostly because a fixed length header and fixed location for the source route information made parsing and validation much simpler: With IP options you have to parse & validate the variable length source route option, the route pointer, the (probably unaligned) next hop, the variable length option list padding & termination and a variable length datagram. With encapsulation you validate a fixed length datagram and, depending on the style of encapsulation, a fixed or variable length address list located at a fixed (and aligned) place in the datagram. The processing path was cheaper because encapsulation gets into a router via the front door rather than chipping a hole through the basement wall: Normally when you talk to a router you send a datagram to one of its addresses with the IP protocol field set in a way that identifies the content of the rest of the packet (ICMP, UDP, etc.). This path into the router can be implemented very efficiently: the local-or-forward? decision can easily be made part of the fundamental which-interface-to- forward-on? lookup (which must be fast for the router to be competitive) and, because this part of IP was done well, demuxing on the protocol field is very cheap (a jump or call through a 256 entry branch table). But, because of the horrible IP design botch of allowing options, there's this other path into the router that's a bag hung on the side of the forwarding path: early in the path, completely separate from the where-to-forward decision that's intrinsic, there has to be additional code that says "are there options?" and, if so, "is there anything in the option list that I have to deal with?". This path is functionally redundent (there is already a good, efficient way to talk to, as opposed to through, a router) and greatly complicates the forwarding code. Fortunately, IP options are so ugly that they have been little used to date and router vendors have (rightly) treated this path with the contempt it deserves. If we do a new protocol (a step that I still don't feel is necessary) we should try to jettison IP's obvious mistakes, not preserve and build on them. - Van From owner-Big-Internet@munnari.oz.au Tue Oct 13 21:51:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18250; Tue, 13 Oct 1992 21:51:46 +1000 (from owner-Big-Internet) Return-Path: Received: from rx7.ee.lbl.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18247; Tue, 13 Oct 1992 21:51:41 +1000 (from van@ee.lbl.gov) Received: by rx7.ee.lbl.gov for Big-Internet@munnari.oz.au (5.65/1.44r) id AA12739; Tue, 13 Oct 92 04:53:07 -0700 Message-Id: <9210131153.AA12739@rx7.ee.lbl.gov> To: throop@dg-rtp.dg.com (Dean D. Throop) Cc: Big-Internet@munnari.oz.au Subject: Re: what is the diameter of current Internet In-Reply-To: Your message of Mon, 12 Oct 92 12:36:05 EDT. Date: Tue, 13 Oct 92 04:53:07 PDT From: Van Jacobson > My tracetroute to Japan exceeded the 30 hop limit traceroute had > build in. I would have been very remiss to build such a low limit into traceroute. Its hop limit is actually 255 (and that limit is in IP, not traceroute). There is a *default* cutoff at 30 hops that can be changed with the -m flag. (The number 30 was chosen because it was the recommended TCP TTL at the time the program was written.) - Van From owner-Big-Internet@munnari.oz.au Tue Oct 13 23:07:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20815; Tue, 13 Oct 1992 23:07:46 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210131307.20815@munnari.oz.au> Received: from watson.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20809; Tue, 13 Oct 1992 23:07:41 +1000 (from perk@watson.ibm.com) Received: from YKTVMH by watson.ibm.com (IBM VM SMTP V2R2) with BSMTP id 3706; Tue, 13 Oct 92 09:07:38 EDT Date: Tue, 13 Oct 92 07:54:25 EDT From: perk@watson.ibm.com To: big-internet@munnari.oz.au Cc: BHAGWAT@YKTVMH.watson.ibm.com, ji@cs.columbia.edu I'll send to mobile-ip the bulk of an answer to JI's rather fierce attack. For the record, though, I think it is clear that one can create an arbitrarily large IP address space, break it into "commonwealths" of 32 bit address space, and have routers between the commonwealths using either source routing or encapsulation. It is also clear that neither approach FULLY solves the problem of what to do with existing systems. I tried to stay within existing protocol specification instead of creating new ones, and I guess I done been told. But being slightly stubborn I'll stay the course to see if it leads anywhere. Security is an issue -- more elsewhere -- but source routing is a drop in the bucket. AIX does support source routing. Repairing most existing systems is nearly trivial. Routers do support it. We haven't noticed any performance problems. It seems to me that anything that can be done with source routing can be done with encapsulation, and almost vice-versa but not quite. In fact, almost anything can be done with encapsulation -- I think you could operate the entire Unix system call interface at the IP layer. The question that should be answered (I guess there's no way to avoid flaming) is: Should we clean up existing implementation (and system administration), or specify new protocols? My professional training as a programmer (and wannabe mathematician) leads me to prefer the former. JI clearly disagrees, almost to the point of hysteria. I'm keeping an open mind. I'll conform to whatever specification the future holds. Thanks for your attention. Charlie P. From owner-Big-Internet@munnari.oz.au Tue Oct 13 23:49:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22395; Tue, 13 Oct 1992 23:49:26 +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 AA22389; Tue, 13 Oct 1992 23:49:10 +1000 (from kasten@ftp.com) Received: by ftp.com id AA08518; Tue, 13 Oct 92 09:48:47 -0400 Date: Tue, 13 Oct 92 09:48:47 -0400 Message-Id: <9210131348.AA08518@ftp.com> To: tli@cisco.com Subject: Re: Tracing paths From: kasten@ftp.com (Frank Kastenholz) Cc: Big-Internet@munnari.oz.au, kasten@ftp.com, kre@munnari.oz.au, fbaker@acc.com, trewitt@pa.dec.com > While I agree that looking at all of this data is all well and good, > it is NOT sufficient to supplant traceroute. It does NOT tell you > anything about the _algorithm_ that is used to make the routing > decision. Without full and complete knowledge of the algorithm, all > of the data in the world will not give you squat as compared to a real > live experiment. Tony, What appears in the SNMP routing table should accurately reflect the decisions that the routing algorithm would make at the time that the SNMP query is made. If the table says that to send a packet to destination net , the packet goes out interface , then that is, in fact, what the routing algorithm should be doing. If the MIB's routing table is not in sync with the real routing decisions that get made then the MIB's value is greatly diminished -- perhaps to the point of having 0 value. The SNMP routing table in MIB-2 is deficient in that it does not reflect some things like policy and TOS very well. However part of the IPv7 effort is to develop the PROPER MIBs in to manage the protocol. This is the chance to do the right thing with regard to the mibs. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Tue Oct 13 23:48:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22369; Tue, 13 Oct 1992 23:49:05 +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 AA22366; Tue, 13 Oct 1992 23:48:55 +1000 (from kasten@ftp.com) Received: by ftp.com id AA08510; Tue, 13 Oct 92 09:48:43 -0400 Date: Tue, 13 Oct 92 09:48:43 -0400 Message-Id: <9210131348.AA08510@ftp.com> To: dab@berserkly.cray.com Subject: Re: Record Route (was Re: Hop Limit field in SIP) From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au sort of like the 802.5 explorer packets? > An alternative would be to have the ultimate destination in the > ICMP-Record-Route message. At each hop, the next-hop would be > calculated using the ultimate destination, but the IP destination > field would be filled in with the next-hop address (a dynamically > created source route???). When the packet arrives at a machine > where both address match, then it has reached the destination. > This is not to say that I think that this is a great idea, but > it is the sort of thing that would have to be done. Not to > mention that all the routers would have to play along for this > to work. Trying to implement something like this today would be > a real pain. Making it work with a new IP (like SIP) from the > onset would be much easier, since every router would have to > change anyway. > > -David Borman, dab@cray.com > -- frank kastenholz From owner-Big-Internet@munnari.oz.au Wed Oct 14 00:27:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24382; Wed, 14 Oct 1992 00:27:43 +1000 (from owner-Big-Internet) Return-Path: Received: from dg-rtp.rtp.dg.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24376; Wed, 14 Oct 1992 00:27:19 +1000 (from throop@dg-rtp.dg.com) Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4.1/dg-rtp-proto) id AA01648; Tue, 13 Oct 1992 10:27:08 -0400 Received: by walrus (5.4.1/140.2) id AA17963; Tue, 13 Oct 1992 10:24:36 -0400 Date: Tue, 13 Oct 1992 10:24:36 -0400 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9210131424.AA17963@walrus> To: van@ee.lbl.gov Subject: Re: what is the diameter of current Internet Cc: Big-Internet@munnari.oz.au > To: throop@dg-rtp.dg.com (Dean D. Throop) > Subject: Re: what is the diameter of current Internet > Date: Tue, 13 Oct 92 04:53:07 PDT > From: Van Jacobson > > > My tracetroute to Japan exceeded the 30 hop limit traceroute had > > build in. > > I would have been very remiss to build such a low limit into > traceroute. Its hop limit is actually 255 (and that limit is in > IP, not traceroute). There is a *default* cutoff at 30 hops > that can be changed with the -m flag. (The number 30 was chosen > because it was the recommended TCP TTL at the time the program > was written.) > > - Van Yes indeed the -m switch did increase the hop limit in traceroute. I rather curt message was trying to illustrate that the internet was already larger than some people expected. I'm 12 hops from the NSF backbone and the NSF backbone takes 8 hops. If other continents develop in a similar fashion, I expect inter-continental traffic to double this distance. This would give us: 12 hops from my machine to a continental backbone + 8 hops across my continent + 8 hops across another continental backbone + 12 hops to some other distant host. ----- 40 hops If it doesn't exist now, it probably will soon. Maybe the recommended number of 30 is already too low. Dean Throop throop@dg-rtp.dg.com From owner-Big-Internet@munnari.oz.au Wed Oct 14 01:42:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26900; Wed, 14 Oct 1992 01:42:51 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210131542.26900@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26880; Wed, 14 Oct 1992 01:42:37 +1000 (from day@BBN.COM) From: "John Day" Subject: [ Day: Re: re: Re: Penultimate TUBA Charter, IDs and names ] To: big-internet@munnari.oz.au Date: Tue, 13 Oct 92 11:37:54 EDT Mail-System-Version: People, It is with great trepidation that I offer the following note that was sent out on the TUBA list. Please bear with much of the OSI-ese in the note. It seemed appropriate for the TUBA discussion. I have been watching this discussion of EIDs with some interest. (Now that I have written most of this, It is probably advisable to read the attachment first.) It appears that what you are looking for are Application Titles which are location-independent. Back in the ancient history of the Internet/ARPANet, there was some talk that eventually some day they would be needed. Well-known sockets were done initially as a quick and dirty solution for finding applications in a very small network. (We thought it was huge at the time.) But it was apparent that something more general with some sort of DNS would be required for a "real network." It would appear that the idea has been lost. Are we really looking for a location-independent name between network and transport, or a location-independent name for applications? The EIDs give me the feeling of trying to solve an application layer problem in the network layer. It is another name space to manage, but much of the confusion arises from trying to use one name space for both functions. The phone companies have this confusion in spades. It keeps screwing them up and complicating their solutions because they don't keep the distinction straight. In most cases, the Application Title is only used once when a connection is established, or some shared state is agreed on; so it is not necessary to carry it in every packet. If there is a proliferation applications (and there better be), a separate name space (hierarchical in some form) is probably a whole lot easier to manage than everyone getting their own well-known socket. As to the role of the DNS, and as alluded to in the note below, the DNS or the Directory (X.500 style, groan) does the mapping from application titles to network addresses. This is assumed to be very large and changes very slowly, but does change. Mobility and portability are supposed to be handled by a "different directory" that keeps up with changes in the mapping of network addresses to what OSI calls SNPA-address. This directory (also called a routing table in some cases) has more limited scope and can be much more responsive to the changes required by mobility and portabiltity. Once in a while, a system is moved "far enough" to cause its network address to change. In which case the DNS must be updated. (It would, of course, behoove the DNS to accommodate temporary changes ("I'm on the West Coast this week") vs more long term changes ("I just moved to the West Coast"). This is basically how cellular phone systems work both for mobility (driving around) and what they call roaming (getting on a plane and showing up in some other routing domain). As to the definition of address, it is defined below as the name of the binding between two protocol machines. This avoids saying that a node can be an interface, a system, etc. And as much as such definitions are tempting, someone always has a very good reason for having multiple addresses for a system, interface or what have you. Network addresses distinctly do not want to name points of attachment. As argued below, if you do that then you can solve multi-homing issues. SNPA-addresses do name points of attachment. Unfortunately, very early on the ARPANET did just what the phone company did and made network addresses points of attachment. It tooks us quite a while to figure out what it should be. Actually no it didn't, as soon as the multi-homing came up we realized what the mistake was, but changing it is a bear. Remember Dr. Seuss' poor old Mrs. McCave and her naming problems. She learned her lesson, ("But she didn't do it and now its too late.") Naming is a bear of problem and exceedingly subtle. Worse fixing problems in a naming scheme are often very painful and expensive and the longer it takes to discover the problem the more painful and expensive is the fix. It behooves us to err on the side of generality on this problem and get it right. (Or keep doing lots of quick and dirty solution so no one is all that expensive. Trouble is I think this latter approach leads to chaos and disaster.) Hope it wasn't too far off the mark for this discussion. Take care, John -------- Beginning of Forwarded Message(s) --------- From: "John Day" Subject: Re: re: Re: Penultimate TUBA Charter, IDs and names To: callon@bigfut.enet.dec.com Cc: colella@emu.ncsl.nist.gov, Day, tuba@lanl.gov In-Reply-To: <9210061807.AA13582@us1rmc.bb.dec.com> Date: Wed, 7 Oct 92 09:48:40 EDT Mail-System-Version: >Subject: re: Re: Penultimate TUBA Charter, IDs and names > I have been debating for sometime whether to offer my two cents on this topic. I have been watching the mail fly back and forth about whether address should have embedded semantics and what addresses represent, etc. This example seems to be a good place to start. As a bit of preamble, let me describe what I think the three important forms of names are for this problem and what they are trying to do: 1) Application titles - location independent, global scope, identifies types or instances of applications. One form of this might be a system title. 2) NSAP Address - location dependent. global scope, identifies the binding between a network and transport entity. (In general, SAPs are the binding between (N)-entities and (N+1)-entities.) As I believe Ross pointed out NSAP addresses are topology-specific, but route independent. Topology is meant here in the mathematical sense. You want a "distance" function defined over the space of addresses that provides an indication of "nearness". In most of the cases being considered these days, this means "in the same routing domain." 3) SNPA-address - route-specific, perhaps not global in scope. identifies the point of attachment of a system to the network. The only strict requirement is that these be unambiguous within a subnet. In the direction of generality, there is some evidence "one man's route independence is another man's route dependent," i.e. an (N-1)-address is route specific relative to the (N)-layer. To the network layer, the choice of route is an SNPA or Data Link address whether these addresses were chosen to be route specific or not. (The fact that SNPA is not necessarily Data Link has to do with the absolute, rather than relative, choice of layers, but that is a whole other story.) Part of the problem in this discussion seems to be to try solving everything in the Network Layer. When the solution should be solve the Network Layer addressing issues in the Network Layer and let the Application Layer sort out its own problems. Don't try to solve Application Layer naming problems in the Network Layer. The decoupling of NSAP-address and SNPA-address is necessary for solving the problem of multi-homed hosts. Part of the problem with phone numbers and the original ARPANET addresses is that they are SNPA-addresses, i.e. route specific. (I once suggested that this mistake was made because the original designers were from Boston where there is only one way to get anywhere so it is easy to confuse addresses and routes. If they had been from the midwest where everything is on a grid and consequently there is more than one way to get anywhere, they would have realized that routes and addresses are two different things. Just a joke.) The routing protocols need the decoupling provided by NSAP-addresses to be able to handle multi-homed hosts. > >I have been thinking some more about mapping from IDs to names, >and have thought of the following problem: Lets suppose that >IDs are assigned by local administrations, and include some >administrative information. Thus, the laptop that I get from work >is assigned an ID from the DEC-LKG ID space. Now, suppose I go on >a business trip to XYZ corporation in Scotland. I plug my portable >into the local network, and want to do some work using my own >original ID (so that folks that I am talking with can tell that it >is still me). Thus I will assume that when attached to the local >network at XYZ corporation I have the same ID that I got from DEC >(since that is still where I am employed, and who owns the laptop), >but an address related to XYZ corporation (where I am currently >plugged into). > >Lets suppose that I want to talk to someone else at XYZ Corporation. >Then I claim that this conversation should be capable of taking >place without *ANY* traffic having to go outside of the local >networks within XYZ corporation. For example, the cost of the >trans-atlantic links might be high, or the security gateway >between the XYZ networks and the public networks might not let my >traffic through, or the links between XYZ and the public networks >might be temporarily down. Thus a system that I am talking to >within XYZ needs to be able to look up my name (based on either my >address, or based on my ID) without going outside of the local nets >within XYZ corporation). > >Now, this would seem to require that when I plug my laptop into the >networks at XYZ then something goes off to the local name service >and tells it to keep a mapping from my (address or ID) to my name. >Also, to me this seem to imply that the manner in which the lookup >information is stored in the DNS should be based on something which >changes when I move (i.e., an address) rather than something which >stays the same when I move (i.e., an ID). > The theory goes that each of these levels of addressing provides a decoupling and that the rate of change of the addresses assigned (while seldom often) decreases as one moves from SNPA to Application Title. Thus, for mobility and portability Application Titles never change, but NSAP-addresses and SNPA-addresses do. SNPA would change as the point of attachment within a subnet changed; NSAP-address would only change if you moved outside your routing domain (or the measure of "nearness" got too great). If you look at how roaming works in cellular networks, you will see that while not as clearly set out as this, this is basically what they are doing. In your home domain, your cellular phone number is both an NSAP-address and an Application Title. As you move around locally, there are hand-off algorithms that changes the SNPA, but leave the NSAP-address fixed. If you get on a plane and fly to a new domain (wha they call roaming), you are assigned a new temporary phone number (NSAP-address in that domain), but the phone company remembers your "real" phone number for billing purposes. In the current US system, others actually have to call a different number when you roam, but in the new GSM stuff I believe that you keep your number and they really separate the SNPA and NSAP. (The phone company has trouble noticing when phone numbers are SNPAs and when they are Application Titles.) Basically, this is the kind of model for mobility and portability that I believe that we want. The other issue that has been coming up is the relation between Network Entity Titles and NSAP-addresses. NETs are supposed to be more "internal to the layer" to be used by network and layer managment protocols. It was intended that NETs would be independently assigned from NSAP-addresses, so that there was some flexibility in configuration. If the system experienced failures or needed to shift things around for resource allocation purposes, NSAPs could be detached from one network-entity and re-assigned to another and external users would not see the addressing they used change. Similarly, the identification of a higher layer protocol in an NSAP address was discouraged to allow for more than one (N+1)-entity of the same type to use the same (N)-address. Several people were thinking about silicon implementations of protocols where you might have multiple chips of the same protocol (say transport) mapping to the same NSAP address. (Recent discussions indicate that some are still planning this sort of configuration.) Using the NSEL byte to designate protocol would prevent this or any other configuration that had a requirement for more than one occurrence of the same protocol on the same NSAP-address. >Thus, I think that Richard is right, and long term we should be >mapping from entire NSAPs to names, and not from IDs or embedded IP >addresses to names. Naturally, we could *in addition* also allow >other temporary mappings as migration aids. > >Ross Entirely too much rambling on this subject, but if we can keep the algebra of Appl Titles, NSAP-address, and SNPA-address straight, the arithmetic of coming up with an address assignment scheme might be easier. Take care, John -------- End of Forwarded Message(s) --------- From owner-Big-Internet@munnari.oz.au Wed Oct 14 02:17:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28157; Wed, 14 Oct 1992 02:17:38 +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 AA28129; Wed, 14 Oct 1992 02:17:15 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA29508; Tue, 13 Oct 92 09:17:07 -0700 Received: by us1rmc.bb.dec.com; id AA07642; Tue, 13 Oct 92 12:14:32 -0400 Message-Id: <9210131614.AA07642@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Tue, 13 Oct 92 12:14:34 EDT Date: Tue, 13 Oct 92 12:14:34 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358" To: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au Subject: RE: Re: what is the diameter of current Internet Some months ago I sent out a message saying that my impression was that most people were setting the limit to around 64 and the diameter of the Internet was not more than 35. That's for 10**6 hosts. Squaring the number of hosts would tend to double the number of host so a limit of 128 should be fine for the targer 10**12 host internet. I have not seen anything to change my opinion of either the current or prospective diameter of the Internet. Donald -------------- From: US1RMC::"throop@dg-rtp.dg.com" "Dean D. Throop" 13-OCT-1992 11:10 Yes indeed the -m switch did increase the hop limit in traceroute. I rather curt message was trying to illustrate that the internet was already larger than some people expected. I'm 12 hops from the NSF backbone and the NSF backbone takes 8 hops. If other continents develop in a similar fashion, I expect inter-continental traffic to double this distance. This would give us: 12 hops from my machine to a continental backbone + 8 hops across my continent + 8 hops across another continental backbone + 12 hops to some other distant host. ----- 40 hops If it doesn't exist now, it probably will soon. Maybe the recommended number of 30 is already too low. Dean Throop throop@dg-rtp.dg.com From owner-Big-Internet@munnari.oz.au Wed Oct 14 03:16:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00270; Wed, 14 Oct 1992 03:17:03 +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 AA00265; Wed, 14 Oct 1992 03:16:52 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10197; Tue, 13 Oct 92 13:15:53 -0400 Date: Tue, 13 Oct 92 13:15:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210131715.AA10197@ginger.lcs.mit.edu> To: Day@bbn.com, big-internet@munnari.oz.au Subject: Re: [ Day: Re: re: Re: Penultimate TUBA Charter, IDs and names ] Cc: jnc@ginger.lcs.mit.edu Look, I think everyone in this discussion needs to throw out (or be willing to throw out at the drop of a hat) everything they *think* they already know about networks. Some of it is bound to be wrong, and unless you start with that premise, and the obvious conclusion, you'll *never* get rid of the mistakes. People seem to have pretty fixed ideas about what functions belong in which layers, and where the layer boundaries ought to be, how many layers there are, etc, etc. I know you need jargon before you can discuss something complex, but let's try and keep a totally fresh mind on this, OK? It appears that what you are looking for are Application Titles which are location-independent. ... Are we really looking for a location-independent name between network and transport, or a location-independent name for applications? Unless I much misunderstand what Application Titles are, this is most distinctly *not* what I mean by an "endpoint", and I certainly don't agree that it belongs *anywhere* but at the network layer. Look, the notion that the job of the network layer is to deliver the packets (unreliably) from the producer to the consumer seems, on examination, to be a reasonable one to me. An "endpoint" *is* the producer and consumer of packets. The *only* alternative, it seems to me, is to split this definition of the network layer into two levels, the lower one being "address->address" (in my definition, where the addresses are the things that the system of routers deliver packets to), and the higher being "endpoint->endpoint". However, I don't see any benefit to making this split formal, and prefer just to leave both functions in one layer. The EIDs give me the feeling of trying to solve an application layer problem in the network layer. What do you think the job of these two layers should be? It's clearly different from mine, since in mine, there's no way this makes sense. How does, e.g. handling hosts with several interfaces need to be inflicted on the application? much of the confusion arises from trying to use one name space for both functions. The phone companies have this confusion in spades. It keeps screwing them up and complicating their solutions because they don't keep the distinction straight Yes.... but this is a general truth, not just about these two naming spaces. the Directory (X.500 style, groan) does the mapping from application title to network addresses. ... Mobility and portability are supposed to be handled by a "different directory" that keeps up with changes in the mapping of network addresses to what OSI calls SNPA-address. This directory (also called a routing table in some cases) has more limited scope ... Once in a while, a system is moved "far enough" to cause its network address to change. I claim this is all a case of muddy decisions about where to put the boundaries between functions. NSAP's (what you are referring to as 'network address', right?) are topologically significant, except when they aren't. So, sometimes all you do with an NSAP is route on it, except when you also have to map it to an SNPA to actually get the packet where it's going. This mapping provides mobility, except when it doesn't. I know, I know, I'm being a little unfair; mechanisms that work at one level of scale don't always work at another, and that's where some of this may come from. Still, the impression one gets is that some functions (e.g. naming the place in the topology the router has to deliver packets to) gets split across several naming spaces, and others (e.g. providing flexible binding to handle mobility) get split across several binding stages. Is this really the way to go? As to the definition of address, it is defined below as the name of the binding between two protocol machines. I think we should take the term "address" out and shoot it. Perhaps we should install a filter on the Big-I mailing list to discard any mail item with the term "address" in it? As my personal part of this, I hereby pledge to not use the term again, and substitute the term "topology location indicator" (TLI) for the general term, and "router delivery point" (RDP) for what I have been calling a "fully qualified address". I.e. the former can refer to a network or other topological grouping, the latter only to what I have been losely calling an "interface". Network addresses distinctly do not want to name points of attachment. As argued below, if you do that then you can solve multi-homing issues. SNPA-addresses do name points of attachment. Here's a golden example of why. The thing you call an "SNPA-address" is very close to the meaning of what I call an "address" (i.e. RDP). The thing you call a "network address" I don't believe I have a name for at all (not finding it useful), unless it's sort of a topology-sensitive EID! Part of the problem with phone numbers and the original ARPANET addresses is that they are SNPA-addresses, i.e. route specific. Unless you have a bizarre definition of "route", I'm not sure I agree with this. Yes, ARPANet addresses specified which host port on which IMP (i.e. interface cable) packets had to leave the network over, but in no way did they control the path packets took through the network fabric, which is what I think "route" means. Noel From owner-Big-Internet@munnari.oz.au Wed Oct 14 03:19:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00304; Wed, 14 Oct 1992 03:19:13 +1000 (from owner-Big-Internet) Return-Path: Received: from timbuk.cray.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00288; Wed, 14 Oct 1992 03:19:02 +1000 (from dab@berserkly.cray.com) Received: from handel.cray.com.cray.com by cray.com (4.1/CRI-MX 2.2) id AA24276; Tue, 13 Oct 92 12:18:47 CDT Received: by handel.cray.com.cray.com id AA04795; 5.65/CRI-5.5; Tue, 13 Oct 1992 12:17:29 -0500 Date: Tue, 13 Oct 1992 12:17:29 -0500 From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9210131717.AA04795@handel.cray.com.cray.com> To: throop@dg-rtp.dg.com Subject: Re: what is the diameter of current Internet Cc: Big-Internet@munnari.oz.au With regards to the recommended default IP TTL value, the current recommended default TTL is 64, see page 32, RFC 1340, Assigned Numbers. (The previous Assigned Numbers, RFC 1060, had the default IP TTL at 32). -David Borman, dab@cray.com From owner-Big-Internet@munnari.oz.au Wed Oct 14 03:33:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00679; Wed, 14 Oct 1992 03:34:07 +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 AA00651; Wed, 14 Oct 1992 03:33:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10332; Tue, 13 Oct 92 13:33:36 -0400 Date: Tue, 13 Oct 92 13:33:36 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210131733.AA10332@ginger.lcs.mit.edu> To: Z.Wang@cs.ucl.ac.uk, van@ee.lbl.gov Subject: Re: IP option test (long) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Are you suggesting that source routing is inherently slower than encapsulation? Terminology alert; can we please distinguish between source routing the concept, where one entity (perhaps the source, perhaps not) picks the entire route, and source routing the implementation, where a (perhaps complete) list of intermediate locations is put into each packet? I don't know what we can use for terms, but we shold distinguish which one we are talking about (or attacking :-). Noel From owner-Big-Internet@munnari.oz.au Wed Oct 14 03:44:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01212; Wed, 14 Oct 1992 03:44:29 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01207; Wed, 14 Oct 1992 03:44:21 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Tue, 13 Oct 92 10:42:25 -0700 Date: Tue, 13 Oct 92 10:42:25 -0700 From: Tony Li Message-Id: <9210131742.AA08974@lager.cisco.com> To: kasten@ftp.com Cc: Big-Internet@munnari.oz.au, kasten@ftp.com, kre@munnari.oz.au, fbaker@acc.com, trewitt@pa.dec.com In-Reply-To: (Frank Kastenholz's message of Tue, 13 Oct 92 09:48:47 -0400 <9210131348.AA08518@ftp.com> Subject: Tracing paths Frank, What appears in the SNMP routing table should accurately reflect the decisions that the routing algorithm would make at the time that the SNMP query is made. If the table says that to send a packet to destination net , the packet goes out interface , then that is, in fact, what the routing algorithm should be doing. If the MIB's routing table is not in sync with the real routing decisions that get made then the MIB's value is greatly diminished -- perhaps to the point of having 0 value. The SNMP routing table does indeed reflect what is in the routing table. It does not tell you about interesting cases. What happens in the case of default routes that are not 0.0.0.0? What happens in the case of recursive routing lookups? What happens in the case of a default subnet? The SNMP routing table in MIB-2 is deficient in that it does not reflect some things like policy and TOS very well. However part of the IPv7 effort is to develop the PROPER MIBs in to manage the protocol. This is the chance to do the right thing with regard to the mibs. This is jousting at windmills. No matter what you do, I can always add some odd vendor extension to the routing table which is not covered by the standard MIB. A better alternative would be to implement a request that would accept a destination address and return next hop and outbound interface. This would allow you to run the routing algorithm and test it. Tony From owner-Big-Internet@munnari.oz.au Wed Oct 14 04:07:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02264; Wed, 14 Oct 1992 04:07:38 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210131807.2264@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02248; Wed, 14 Oct 1992 04:07:28 +1000 (from day@BBN.COM) From: "John Day" Subject: Re: [ Day: Re: re: Re: Penultimate TUBA Charter, IDs and names ] To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au, Day@munnari.oz.au In-Reply-To: <9210131715.AA10197@ginger.lcs.mit.edu> Date: Tue, 13 Oct 92 14:00:01 EDT Mail-System-Version: >Subject: Re: [ Day: Re: re: Re: Penultimate TUBA Charter, IDs and names ] >Cc: jnc@ginger.lcs.mit.edu > > Look, I think everyone in this discussion needs to throw out (or be >willing to throw out at the drop of a hat) everything they *think* they >already know about networks. Some of it is bound to be wrong, and unless you >start with that premise, and the obvious conclusion, you'll *never* get rid of >the mistakes. Good, then I don't feel so dumb. > Look, the notion that the job of the network layer is to deliver the >packets (unreliably) from the producer to the consumer seems, on examination, >to be a reasonable one to me. An "endpoint" *is* the producer and consumer of >packets. The *only* alternative, it seems to me, is to split this definition of >the network layer into two levels, the lower one being "address->address" (in >my definition, where the addresses are the things that the system of routers >deliver packets to), and the higher being "endpoint->endpoint". However, I >don't see any benefit to making this split formal, and prefer just to leave >both functions in one layer. Actually I view the job of the network layer to managing the resource allocation of the transfer. The two levels you refer to here I would distinguish as the mappings between Network Address and SNPA-address. NSAP-address (Network Address) is Topology Location Dependent and identifies the binding to which the a Transport Protocol Machine is attached. The SNPA-address is one layer down (whether ISO calls it a layer or not) and is route specific. A router receives a packet (IP or CLNP) with the destination NSAP-address, consults its routing tables (lower layer directory if you will) and chooses an SNPA-address to send it along its way, encapsulating the network layer packet whatever protocol is one layer down. When it arrives at the host, the same thing happens only finding the NSAP-address is local, it routes it up instead of down. I guess the big difference I see is between addresses being routing independent but location dependent, i.e. topology specific. This is a subtle difference but critical. In most cases we have considered, this means a topology that is a hierarchy of routing domains and the topology specific nature of the addresses allows us to keep table size under control and improves performance. Otherwise, every router has to keep an entry for every possible destination, not good. > > The EIDs give me the feeling of trying to solve an application layer > problem in the network layer. > >What do you think the job of these two layers should be? It's clearly different >from mine, since in mine, there's no way this makes sense. How does, e.g. >handling hosts with several interfaces need to be inflicted on the application? Absolutely not. This is precisely what I am trying to avoid. > > much of the confusion arises from trying to use one name space for both > functions. The phone companies have this confusion in spades. It keeps > screwing them up and complicating their solutions because they don't keep > the distinction straight > >Yes.... but this is a general truth, not just about these two naming spaces. > For such a general truth, I have seen an awful lot of people who haven't noticed that 911, 411, and 800 numbers don't name the same kinds of things as a regular phone number. If you don't keep them straight, you will screw up how you deal with them. > the Directory (X.500 style, groan) does the mapping from application title > to network addresses. ... Mobility and portability are supposed to be > handled by a "different directory" that keeps up with changes in the > mapping of network addresses to what OSI calls SNPA-address. This > directory (also called a routing table in some cases) has more limited > scope ... Once in a while, a system is moved "far enough" to cause > its network address to change. > > I claim this is all a case of muddy decisions about where to put the >boundaries between functions. NSAP's (what you are referring to as 'network >address', right?) Yes. are topologically significant, except when they aren't. So, >sometimes all you do with an NSAP is route on it, except when you also have to >map it to an SNPA to actually get the packet where it's going. This mapping >provides mobility, except when it doesn't. I believe the point here is that the "directories or routing tables" mapping NSAPs to SNPAs are sized, scoped and engineered to change much more frequently than DNSs or X.500 directories. As I indicated the cellular phone systems do it this way with some very crude protocols that are handling a very large number of calls. Actually these guys could learn a lot from the techniques for routing that we have developed. Most of them came from telephony backgrounds and the techniques belie that approach. They could probably pick up considerable performance and handle even more mobile phones if they adapted some of the adaptive routing techniques used in datagram networks. > I know, I know, I'm being a little unfair; mechanisms that work at one >level of scale don't always work at another, and that's where some of this may >come from. Still, the impression one gets is that some functions (e.g. naming >the place in the topology the router has to deliver packets to) gets split >across several naming spaces, and others (e.g. providing flexible binding to >handle mobility) get split across several binding stages. Is this really the >way to go? > I dont quite understand your point here. > As to the definition of address, it is defined below as the name of the > binding between two protocol machines. > >I think we should take the term "address" out and shoot it. Perhaps we should >install a filter on the Big-I mailing list to discard any mail item with the >term "address" in it? This isnt the first time it has been suggested. >As my personal part of this, I hereby pledge to not use the term again, and >substitute the term "topology location indicator" (TLI) for the general term, >and "router delivery point" (RDP) for what I have been calling a "fully >qualified address". I.e. the former can refer to a network or other topological >grouping, the latter only to what I have been losely calling an "interface". > > Network addresses distinctly do not want to name points of attachment. > As argued below, if you do that then you can solve multi-homing issues. > SNPA-addresses do name points of attachment. > >Here's a golden example of why. The thing you call an "SNPA-address" is very >close to the meaning of what I call an "address" (i.e. RDP). The thing you call >a "network address" I don't believe I have a name for at all (not finding it >useful), unless it's sort of a topology-sensitive EID! I believe you are correct about the definitions and see above for my reasons for believing that NSAPs are and should be topology-sensitive addresses. > > Part of the problem with phone numbers and the original ARPANET addresses > is that they are SNPA-addresses, i.e. route specific. > >Unless you have a bizarre definition of "route", I'm not sure I agree with >this. Yes, ARPANet addresses specified which host port on which IMP (i.e. >interface cable) packets had to leave the network over, but in no way did they >control the path packets took through the network fabric, which is what I think >"route" means. But that is precisely what you end up doing, if addresses are attachment points. Consider you are sending stuff TO a multi-homed host. You want to send it to one address and let the routing algorithms decide which of the two or more attachments the host has to the network to deliver the packets over. You certainly do not want to make that decision. But if addresses identify IMP host ports you have to choose one and at least part of the route. The only way you don't if there is only one way to get any where. (You aren't from Boston, are you? Sorry that wasn't fair, but I couldn' resist.) Basically, I believe that the first place you want location independent name is with the applications. You want applications to be able to move from system to system without changing their names, although their addresses change. Actually, it is probably the case that while they are location independent, you don't even want these to totally arbitrary. Their probably constructed in some meaningful way. It just doesn't have anything to do with where they are, probably more what they are. > > Noel > Any clearer? Take care, John From owner-Big-Internet@munnari.oz.au Wed Oct 14 04:10:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02360; Wed, 14 Oct 1992 04:10:49 +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 AA02357; Wed, 14 Oct 1992 04:10:38 +1000 (from trewitt@pa.dec.com) Received: by inet-gw-2.pa.dec.com; id AA04948; Tue, 13 Oct 92 11:10:33 -0700 Received: by miasma.pa.dec.com; id AA04671; Tue, 13 Oct 92 11:10:31 -0700 Message-Id: <9210131810.AA04671@miasma.pa.dec.com> To: Tony Li Cc: kasten@ftp.com, Big-Internet@munnari.oz.au, kre@munnari.oz.au, fbaker@acc.com, Glenn Trewitt Subject: Re: Tracing paths In-Reply-To: Your message of Tue, 13 Oct 92 10:42:25 -0700. <9210131742.AA08974@lager.cisco.com> Organization: DEC Network Systems Laboratory (Palo Alto, CA / UCH) Phones: H:408-773-9239, W:415-688-1324, DTN:543-1324, Fax:415-324-2797 Date: Tue, 13 Oct 92 11:10:30 -0700 From: Glenn Trewitt X-Mts: smtp Tony Li says: A better alternative would be to implement a request that would accept a destination address and return next hop and outbound interface. This would allow you to run the routing algorithm and test it. Absolutely. Make it look like a table that can't use get-next (i.e., get-next would skip over the table). Then, I could ask for: newRoute.askRoute.nextHop.19.20.21.22 newRoute.askRoute.ifIndex.19.20.21.22 I'm not sure if there's anything else I would need to get from such a query. Metrics and such don't much matter, but perhaps: rtProto metrics(?) - Glenn From owner-Big-Internet@munnari.oz.au Wed Oct 14 04:18:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02646; Wed, 14 Oct 1992 04:18:30 +1000 (from owner-Big-Internet) Return-Path: Received: from lager.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02641; Wed, 14 Oct 1992 04:18:19 +1000 (from tli@cisco.com) Received: by lager.cisco.com; Tue, 13 Oct 92 11:16:57 -0700 Date: Tue, 13 Oct 92 11:16:57 -0700 From: Tony Li Message-Id: <9210131816.AA11568@lager.cisco.com> To: trewitt@pa.dec.com Cc: kasten@ftp.com, Big-Internet@munnari.oz.au, kre@munnari.oz.au, fbaker@acc.com, trewitt@Pa.dec.com In-Reply-To: Glenn Trewitt's message of Tue, 13 Oct 92 11:10:30 -0700 <9210131810.AA04671@miasma.pa.dec.com> Subject: Tracing paths I'm not sure if there's anything else I would need to get from such a query. Metrics and such don't much matter, but perhaps: rtProto metrics(?) I agree with the value. I don't see how you can do this in any vendor-independent way. Tony From owner-Big-Internet@munnari.oz.au Wed Oct 14 04:18:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02662; Wed, 14 Oct 1992 04:18:47 +1000 (from owner-Big-Internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02649; Wed, 14 Oct 1992 04:18:39 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA10552 (5.65c/UK-2.1-921001); Tue, 13 Oct 1992 14:19:33 -0400 From: Gary Scott Malkin Date: Tue, 13 Oct 1992 14:19:33 -0400 Message-Id: <10552.199210131819@atlas.xylogics.com> To: throop@dg-rtp.dg.com Cc: Big-Internet@munnari.oz.au In-Reply-To: Dean D. Throop's message of Tue, 13 Oct 1992 10:24:36 -0400 <9210131424.AA17963@walrus> Subject: what is the diameter of current Internet The suggested default TTL is given in the "Assigned Numbers" RFC. The most recent (RFC 1340) suggests 64 as a default value. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Wed Oct 14 04:24:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02853; Wed, 14 Oct 1992 04:24:59 +1000 (from owner-Big-Internet) Return-Path: Received: from MITCHELL.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02847; Wed, 14 Oct 1992 04:24:44 +1000 (from swb@nr-tech.cit.cornell.edu) Received: from FALCON.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA11889; Tue, 13 Oct 92 14:24:12 EDT Message-Id: <9210131824.AA11889@mitchell.cit.cornell.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Z.Wang@cs.ucl.ac.uk, van@ee.lbl.gov, big-internet@munnari.oz.au From: Scott_Brim@cornell.edu Subject: Re: IP option test (long) In-Reply-To: Noel Chiappa's message of Tue, 13 Oct 92 13:33:36 -0500. <9210131733.AA10332@ginger.lcs.mit.edu> Date: Tue, 13 Oct 92 14:24:06 -0400 Sender: swb@nr-tech.cit.cornell.edu Noel, I thought SDR = "source-demand routing" or "source-determined routing" was a good name for the first case (even if the source doesn't pick the *entire* route). > Are you suggesting that source routing is inherently slower than > encapsulation? > >Terminology alert; can we please distinguish between source routing the >concept, where one entity (perhaps the source, perhaps not) picks the entire >route, and source routing the implementation, where a (perhaps complete) list >of intermediate locations is put into each packet? I don't know what we can >use for terms, but we shold distinguish which one we are talking about (or >attacking :-). > > Noel From owner-Big-Internet@munnari.oz.au Wed Oct 14 04:50:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03805; Wed, 14 Oct 1992 04:50:53 +1000 (from owner-Big-Internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03793; Wed, 14 Oct 1992 04:50:38 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA13806 (5.65c/UK-2.1-921001); Tue, 13 Oct 1992 14:52:47 -0400 From: Gary Scott Malkin Date: Tue, 13 Oct 1992 14:52:47 -0400 Message-Id: <13806.199210131852@atlas.xylogics.com> To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au In-Reply-To: Noel Chiappa's message of Tue, 13 Oct 92 13:33:36 -0400 <9210131733.AA10332@ginger.lcs.mit.edu> Subject: IP option test (long) > Terminology alert; can we please distinguish between source routing the > concept, where one entity (perhaps the source, perhaps not) picks the entire > route, and source routing the implementation, where a (perhaps complete) list > of intermediate locations is put into each packet? I don't know what we can > use for terms, but we shold distinguish which one we are talking about (or > attacking :-). Doesn't the former require the latter? ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Wed Oct 14 05:58:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06083; Wed, 14 Oct 1992 05:58:26 +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 AA06078; Wed, 14 Oct 1992 05:58:11 +1000 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.57/Ultrix3.0-C) id AA16294; Tue, 13 Oct 92 15:57:48 -0400 Message-Id: <9210131957.AA16294@boa.gsfc.nasa.gov> Subject: Re: Day vs Chiappa re EID To: jnc@ginger.lcs.mit.edu Date: Tue, 13 Oct 92 15:57:47 EDT From: Dick desJardins Cc: big-internet@munnari.oz.au, day@bbn.com X-Mailer: ELM [version 2.3 PL11] Noel, For what it's worth, I agree with you re meaning and intent of the EID. The EID is the logical producer and consumer of packets. In OSIspeak, it's a specific transport entity located in a logical box on the internet. The producer transport entity has to identify the consumer transport entity in order to get the packet there, so that the transport entity can do its end-to-end functionality (flow control, error control, etc). The EIN is a globally unique identifier used for that purpose. The network entities have to find the EIN in the topology. That's the purpose of network addressing and routing. The application entities have to bind to the transport identifiers (sockets) that identify all the end-to-end logical flows. That's the purpose of application titles and the directory binding to socket addresses (or in OSI, to presentation addresses, but the principle is the same). Identifying the EIN as the logical identifier of the producer or consumer of packets is exactly right, in my view, and in the OSI and Internet architectures, that is the transport entity (generally TP4 or CLTP in OSI, TCP and UDP in Internet). It's a logical rather than an instance identifier to allow for different implementations, bindings, reconfigurations, etc. Let's not make this any finer a distinction than it absolutely has to be. We already have the notion of transport entities in both architectures, why not use them? Dick From owner-Big-Internet@munnari.oz.au Wed Oct 14 07:05:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08450; Wed, 14 Oct 1992 07:05:51 +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 AA08426; Wed, 14 Oct 1992 07:05:11 +1000 (from kre) To: Glenn Trewitt , Tony Li Cc: kasten@ftp.com, Big-Internet@munnari.oz.au, fbaker@acc.com Subject: Re: Tracing paths In-Reply-To: Your message of Tue, 13 Oct 92 11:10:30 -0700. <9210131810.AA04671@miasma.pa.dec.com> Date: Wed, 14 Oct 92 07:04:59 +1000 Message-Id: <12649.719010299@munnari.oz.au> From: Robert Elz All this stuff about what should be added to SNMP is great, and worthwhile, and yes, we should make sure that we have a good MIB for IPv7 (whatever that is). But none of this has anything to do with traceroute replacements which SNMP will never be - quite apart from the need to be able to verify the route that a router claims it will use (and the only way to do that is to use the route with real traffic and then look see where the packets really went - it may be true that the router is badly broken if its telling you that its sending packets one way, but actually sending them another, but that's one of the things that we need to be able to discover) But more importantly, as has been said here before, random lusers from around the universe will never be able to get a traceroute using SNMP to work through routers I control, or most others I'd guess, as my routers simply won't respond to random SNMP requests from the universe - the major attractiveness of traceroute, apart from that it sends real packets which are really routed just like other real packets, is that its universal, anyone can check the route to anywhere without pre-arrangement with router owners along the way. kre From owner-Big-Internet@munnari.oz.au Wed Oct 14 07:16:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08832; Wed, 14 Oct 1992 07:16:35 +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 AA08816; Wed, 14 Oct 1992 07:16:03 +1000 (from kre) To: Gary Scott Malkin Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: Re: IP option test (long) In-Reply-To: Your message of Tue, 13 Oct 92 14:52:47 -0400. <13806.199210131852@atlas.xylogics.com> Date: Wed, 14 Oct 92 07:15:52 +1000 Message-Id: <12655.719010952@munnari.oz.au> From: Robert Elz Date: Tue, 13 Oct 1992 14:52:47 -0400 From: Gary Scott Malkin Message-ID: <13806.199210131852@atlas.xylogics.com> > [Quoting Noel] > Terminology alert; can we please distinguish between source routing the > concept, where one entity (perhaps the source, perhaps not) picks the entire > route, and source routing the implementation, where a (perhaps complete) list > of intermediate locations is put into each packet? I don't know what we can > use for terms, but we shold distinguish which one we are talking about (or > attacking :-). Doesn't the former require the latter? No, it doesn't. But there are actually two different things to distinguish when deciding whether or not you want source routing, not just the one Noel points out ... First is the difference between the source picking the route and the route being in the packet, (as Noel indicates). and the second is whether, if the route is in the packet, its there as an add on option (which I believe is what Van was criticising) or as an inherant (and sole) method of forwarding, ala PIP. I too have implemented a router, including source routing, and too, source routed packets are very much second class citizens, though you'd have to work hard to tell that by measuring transit delay of individual packets - measuring the router cpu usage dealing with a source routed packet will tell a whole different story, and that translates into packets per second that can be routed. We should also probably be careful when claiming "source routing works" or "source routing doesn't work" - apart from obviously totally broken implementations (eg: crash when they see a source route) of which there are few today fortunately, there is a whole spectrum of what "works" means. I suspect that while almost nothing implements source routing correctly, according to the letter of the law (reversing the route and all that stuff) it does in practice "work well enough" that it is possible to source route a packet to get from one place to another, and the packets do arrive - which can also be said to be "working". kre From owner-Big-Internet@munnari.oz.au Wed Oct 14 07:44:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10035; Wed, 14 Oct 1992 07:44:50 +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 AA10028; Wed, 14 Oct 1992 07:44:46 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA16537 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 14 Oct 1992 07:45:01 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA03680; Wed, 14 Oct 92 07:44:43 EST Message-Id: <9210132144.AA03680@wanda.mel.dit.CSIRO.AU> To: Van Jacobson Cc: big-internet@munnari.oz.au Subject: Re: IP option test (long) In-Reply-To: Your message of "Tue, 13 Oct 92 04:37:23 PDT." <9210131137.AA12717@rx7.ee.lbl.gov> Date: Wed, 14 Oct 92 07:44:42 +1000 From: Bob Smart > If we do a new protocol (a step that I >still don't feel is necessary) I don't think you mean that IPv4 will last for ever. Do you mean "CIDR/etc gives us a lot of time to design a new protocol". Or do you favour Noel's scheme where the IPv4 packet format would be be retained but the addresses would lose routing significance: presumably by having the IPv4 packets encapsulated in some way which is perhaps only known to the routers? Bob Smart From owner-Big-Internet@munnari.oz.au Wed Oct 14 09:27:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14158; Wed, 14 Oct 1992 09:27: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 AA14147; Wed, 14 Oct 1992 09:27:31 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11726; Tue, 13 Oct 92 19:27:21 -0400 Date: Tue, 13 Oct 92 19:27:21 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210132327.AA11726@ginger.lcs.mit.edu> To: smart@mel.dit.csiro.au, van@ee.lbl.gov Subject: Re: IP option test (long) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu do you favour Noel's scheme where the IPv4 packet format would be be retained but the addresses would lose routing significance Just being picky, but, please note that although I advocate this in the medium term (0-7 years), I don't claim this is the right thing in the long run. I advocate it now so we don't have to change both the packet format and the routing architecture *at the same time* in our very large, operational, system. In the medium-long term (i.e. 7-10 years out) I *do* favor replacing the IPv4 packet format... Noel From owner-Big-Internet@munnari.oz.au Wed Oct 14 10:34:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17125; Wed, 14 Oct 1992 10:34:39 +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 AA17121; Wed, 14 Oct 1992 10:34:27 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA20773 (5.65c/IDA-1.4.4nsd for ); Tue, 13 Oct 1992 17:34:19 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA03224 (5.65c/IDA-1.4.4-910725); Tue, 13 Oct 1992 17:34:16 -0700 Message-Id: <199210140034.AA03224@remmel.NSD.3Com.COM> To: Tony Li Cc: Big-Internet@munnari.oz.au Subject: Re: Tracing paths In-Reply-To: Your message of "Tue, 13 Oct 92 10:42:25 PDT." <9210131742.AA08974@lager.cisco.com> Date: Tue, 13 Oct 92 17:34:15 -0700 From: tracym@NSD.3Com.COM > > The SNMP routing table in MIB-2 is deficient in that it does not > reflect some things like policy and TOS very well. However part of > the IPv7 effort is to develop the PROPER MIBs in to manage the > protocol. This is the chance to do the right thing with regard to the > mibs. > > This is jousting at windmills. No matter what you do, I can always > add some odd vendor extension to the routing table which is not > covered by the standard MIB. Yes!! An important piece of the problem is context. Most routers today don't look up each packet's destination address in The Routing Table. Instead, they check a cache used for optimized forwarding and, if it doesn't have the answer, then go perform some more complex routing function. The context of the lookup (argument list to the function) is the part which is difficult to cover, since in addition to TOS and protocol id, it might include source address, input port, time-of-day, packet size, etc. The notion of a static table is misleading and may more and more often be inaccurate. The routing function is likely to remain a moving target that will often not be representable by any previous best shot at a MIB definition. > A better alternative would be to implement a request that would accept > a destination address and return next hop and outbound interface. > This would allow you to run the routing algorithm and test it. > Yes! This is a very powerful approach, but I'd take it a step further and suggest that, in the extreme, the request includes a full IP (or other appropriate internet-layer) header of interest plus at least the input interface number. Tracy Mallory 3Com Corp. From owner-Big-Internet@munnari.oz.au Wed Oct 14 19:32:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07107; Wed, 14 Oct 1992 19:32:59 +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 AA07104; Wed, 14 Oct 1992 19:32:48 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA04688; Wed, 14 Oct 1992 10:32:41 +0100 Message-Id: <199210140932.AA04688@mitsou.inria.fr> To: Van Jacobson Cc: Zheng Wang , big-internet@munnari.oz.au Subject: Re: IP option test (long) In-Reply-To: Your message of "Tue, 13 Oct 92 04:37:23 PDT." <9210131137.AA12717@rx7.ee.lbl.gov> Date: Wed, 14 Oct 92 10:32:40 -0500 From: Christian Huitema X-Mts: smtp Van, Your instruction count is obviously correct, and has one very clear implication. Setting IP options currently requires *every* router in the path to look at *all* options in order to see if some deviant handling is required for the packet. This cost could be easily optimized out if the option was frequently used, e.g: if (length == 5 words){ Process without option }else if (length == 7 words && header[5] == one-source-route) { Process with one source route }else{ Ugly general case } I dont believe this would "double the cost". This, however, is clearly a kludge. We clearly need a more efficient specification in the next version. The difference between encapsultaion and source routing is that encapsulation is only processed by the "decapsulating" node, not by the intermediate relay; I pretend that for these nodes, encapsulation is not any moe efficient than LSR. What we need is to provide LSR in a way that does not overload intermediate routers -- those not quoted in the LSR. I believe that both PIP and SIP pay some attention to the problem. What I do not agree, from a philosophical point of view, is that we should not do something, e.g. source route or flow identification, because it might "increase the instruction count per packet". Packet routers are there to provide services. Switching packets as fast as possible is indeed a valuable service; switching packets intelligently is also a valuable service. Christian Huitema From owner-Big-Internet@munnari.oz.au Thu Oct 15 03:14:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20685; Thu, 15 Oct 1992 03:14:40 +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 AA20676; Thu, 15 Oct 1992 03:14:24 +1000 (from trewitt@pa.dec.com) Received: by inet-gw-2.pa.dec.com; id AA02913; Wed, 14 Oct 92 10:14:15 -0700 Received: by miasma.pa.dec.com; id AA06192; Wed, 14 Oct 92 10:14:14 -0700 Message-Id: <9210141714.AA06192@miasma.pa.dec.com> To: Robert Elz Cc: Glenn Trewitt , Tony Li , kasten@ftp.com, Big-Internet@munnari.oz.au, fbaker@acc.com Subject: Re: Tracing paths In-Reply-To: Your message of Wed, 14 Oct 92 07:04:59 +1000. <12649.719010299@munnari.oz.au> Organization: DEC Network Systems Laboratory (Palo Alto, CA / UCH) Phones: H:408-773-9239, W:415-688-1324, DTN:543-1324, Fax:415-324-2797 Date: Wed, 14 Oct 92 10:14:13 -0700 From: Glenn Trewitt X-Mts: smtp "Traceroute" packets are *not necessarily* routed "like all other packets". SNMP might or might not give you the right answer, either. If one implemented an SNMP "tell me how you'd route this packet", it would (in the best case) be able to take into account protocol, src/dest port#, TOS, src/dest addr, etc. All of these things may be used as filtering/routing criteria by policy routing/filtering. You may scoff at policy routing, but policy filtering is here today. Just look at most any firewall gateway in the Internet. SNMP *might* be able to give you the right answer, but because traceroute (current technology) relies on a fixed protocol, specific port, etc, it will not be able to track the path that a TCP/ftp/TOS=bandwidth packet will take. None of these solutions will give the perfect answers, but both have their place. - Glenn From owner-Big-Internet@munnari.oz.au Thu Oct 15 04:26:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23373; Thu, 15 Oct 1992 04:26:38 +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 AA23365; Thu, 15 Oct 1992 04:26:24 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA07592; Wed, 14 Oct 92 11:25:18 -0700 Received: by us1rmc.bb.dec.com; id AA15295; Wed, 14 Oct 92 14:21:27 -0400 Message-Id: <9210141821.AA15295@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Wed, 14 Oct 92 14:22:44 EDT Date: Wed, 14 Oct 92 14:22:44 EDT From: Ross Callon To: carlberg@cseic.saic.com, jcurran@nic.near.net Cc: big-internet@munnari.oz.au Apparently-To: carlberg@cseic.saic.com, jcurran@nic.near.net, big-internet@munnari.oz.au Subject: re: Re: one small correction re: EIDs > > Using DNS for EID->address mapping is not sufficient for rapid mobility, > > and a "mobility server" is definitely more useful. > > Perhaps I missed something (here on the other lists), but I don't believe > a "mobility server" has been defined yet. I know that Ross has used this > term before, but it could mean several things to several people. And once > a definition has been found, my question becomes, how close does it > resemble DNS ? Mind you, I'm not advocating using the DNS on a per-move > basis, but I'm just curious as to how close is the functionality of both > servers. And if it is close, would it be prudent to evolve the DNS into a > new iteration with added functionality ? My intention is that the "mobility server" function is really just a forwarding and updating address function that most likely takes place in a router. Thus, when a mobile host hooks up to the network, it contacts the "mobility server" in it's home location, and tells it where it currently is. Subsequent packets destined for this host are at first sent to the home location, where the mobility server intercepts the packets and forwards them to the current location. My understanding is that this is very similar to the operation of current mobile IP host proposals, except that a different address scheme (such as separating the unique ID from the location part of the address) may allow some some optimizations (such as not needing to use encapsulation). With this model, the record of any particular host moving only needs to be maintained at that host's home location. The amount of coordination necessary between "mobile host servers" is strikly limited. This makes the operation of such servers quite different from the operation of DNS. Also, if we have to update all hosts anyway to deal with larger addresses, while we are at it we might as well update them to accept redirects (either implicit or explicit) so that subsequent packets destined from a source host (either mobile or not) to a mobile host can be sent directly to the new location, rather than indirectly via the original "home" location. Here my original thought was that the redirect would be implicit (automatically derived from the return packets from the correspondant mobile host). However, the redirects could be explicit ICMP messages. Ross From owner-Big-Internet@munnari.oz.au Thu Oct 15 06:46:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27989; Thu, 15 Oct 1992 06:46:13 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210142046.27989@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27986; Thu, 15 Oct 1992 06:46:07 +1000 (from day@BBN.COM) From: "John Day" Subject: Re: Day vs Chiappa re EID To: desjardi@boa.gsfc.nasa.gov Cc: big-internet@munnari.oz.au, day@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9210131957.AA16294@boa.gsfc.nasa.gov> Date: Wed, 14 Oct 92 16:44:41 EDT Mail-System-Version: >From: Dick desJardins >For what it's worth, I agree with you re meaning and >intent of the EID. > >The EID is the logical producer and consumer of packets. >In OSIspeak, it's a specific transport entity located >in a logical box on the internet. The producer transport >entity has to identify the consumer transport entity in order >to get the packet there, so that the transport entity can do >its end-to-end functionality (flow control, error control, etc). >The EIN is a globally unique identifier used for that purpose. The EID is a fully qualified Transport address. In OSI-ese this is considered to be the pair (NSAP-address, T-sel). In the internet, the equivalent thing would be the pair (IP-address, port/socket). The reason we defined it as a pair was so the Transport protocol would not have to carry (and duplicate) the Network address portion of the pair (which is the lion's share of it). The only difference between T-sel and socket is that T-sel is unambiguous over all transport protocol machines on the same system and socket is only unambiguous over a single transport machine. (The larger scope was done so that different transport implementations could be substituted without changing the address mappings as seen from outside.) Basically, EIDs are defined to be globally unambiguous for all transport connections over all systems. This has to be much larger than just a little ole T-sel. And it turns out you almost never need to refer to it. If you do form the pair. You certainly don't need to be carrying another really long identifier around in protocol. >The application entities have to bind to the transport >identifiers (sockets) that identify all the end-to-end >logical flows. That's the purpose of application titles >and the directory binding to socket addresses (or in OSI, >to presentation addresses, but the principle is the same). > The point here, Dick, is that the Internet doesn't have an application title concept and they need it. Application titles and addresses are sort of like logical and physical addressing in Operating Systems. We all know why we use logical addressing and naming in an OS for processes. Well-known sockets were a quick solution in 71 or 72 for an immediate need for something to stand in for a directory. Well-known sockets are analogous to physical addresses (acutally they ARE physical addresses) As the number of applications increases you really want to go to logical addressing and use of directory, i.e. application titles. > >Let's not make this any finer a distinction than it absolutely >has to be. We already have the notion of transport entities >in both architectures, why not use them? > We already have the concept of Transport addresses in both architectures why not use them? Take care, John From owner-Big-Internet@munnari.oz.au Thu Oct 15 08:56:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02803; Thu, 15 Oct 1992 08:56:54 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02800; Thu, 15 Oct 1992 08:56:48 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA60992 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Wed, 14 Oct 1992 18:56:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Wed, 14 Oct 1992 18:56:16 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Wed, 14 Oct 1992 18:56:16 -0400 Date: Wed, 14 Oct 1992 18:54:14 -0400 From: Dennis Ferguson Message-Id: <199210142254.AA49640@foo.ans.net> To: Day@BBN.COM Subject: Re: Day vs Chiappa re EID Cc: big-internet@munnari.oz.au, desjardi@boa.gsfc.nasa.gov, jnc@ginger.lcs.mit.edu John, > The EID is a fully qualified Transport address. In OSI-ese this is > considered to be the pair (NSAP-address, T-sel). You might wish this to be the definition of an EID, but I'm quite sure that this is not the definition most others have been using. I am also pretty sure that the OSI network protocol does not have an EID either. In OSI numerology the nearest functional equivalent of an EID would be the thing described as an "ID" in section 7.1.1 of ISO 10589, iff the "ID" were defined as being a globally-unique identifier (rather than just unique within an area vis. section 7.1.4 in the same document). This is the part of the address which is independent of the location, with respect to network topology, of the entity which is addressed. If the OSI network protocol carried an EID the OSI-ese "fully qualified Transport address" could simply be (EID+Nsel, Tsel), rather than what you have above. The (debatable) advantage of this is that you avoid identifying the entity with something as irrelevant and potentially changeable as its location in the network. > The point here, Dick, is that the Internet doesn't have an application > title concept and they need it. [...] > As the number of applications increases you really want to > go to logical addressing and use of directory, i.e. application titles. Personally I am exceedingly happy to be able to find the server end of applications without looking in a directory, and consider this a feature. Running out of TCP ports in particular shouldn't ever be a problem since schemes to replace "well-known port" with "well-known service name" (like TCPMUX) should allow the application name space to be extended indefinitely. While you may disagree with this, it would be much less confusing if you didn't call your alternative an "EID" since people who like "EID"s that others are talking about might not like the "EID"s you are talking about (since they aren't the same thing). Dennis Ferguson From owner-Big-Internet@munnari.oz.au Thu Oct 15 09:12:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03300; Thu, 15 Oct 1992 09:12:20 +1000 (from owner-Big-Internet) Return-Path: Received: from mentor.cc.purdue.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03297; Thu, 15 Oct 1992 09:12:13 +1000 (from kodak@mentor.cc.purdue.edu) Received: by mentor.cc.purdue.edu (5.61/Purdue_CC) id AA22873; Wed, 14 Oct 92 18:12:08 -0500 From: kodak@mentor.cc.purdue.edu (Jason Balicki (KodaK)) Message-Id: <9210142312.AA22873@mentor.cc.purdue.edu> Subject: To: big-internet@munnari.oz.au Date: Wed, 14 Oct 92 18:12:07 EST UNSUBSCRIBE Not what I thought it'd be. I did like the discussions though, but too much volume. --Jason Balicki kodak@mentor.cc.purdue.edu From owner-big-internet@munnari.oz.au Fri Oct 16 00:13:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09570; Fri, 16 Oct 1992 00:13:14 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210151413.9570@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07713; Thu, 15 Oct 1992 23:36:27 +1000 (from day@BBN.COM) From: "John Day" Subject: Re: Day vs Chiappa re EID To: dennis@ans.net Cc: big-internet@munnari.oz.au, Day@munnari.oz.au, desjardi@boa.gsfc.nasa.gov, jnc@ginger.lcs.mit.edu In-Reply-To: <199210142254.AA49640@foo.ans.net> Date: Thu, 15 Oct 92 09:33:16 EDT Mail-System-Version: People, >> The EID is a fully qualified Transport address. In OSI-ese this is >> considered to be the pair (NSAP-address, T-sel). > >You might wish this to be the definition of an EID, but I'm quite sure >that this is not the definition most others have been using. I am also >pretty sure that the OSI network protocol does not have an EID either. > >In OSI numerology the nearest functional equivalent of an EID would be >the thing described as an "ID" in section 7.1.1 of ISO 10589, iff the >"ID" were defined as being a globally-unique identifier (rather than >just unique within an area vis. section 7.1.4 in the same document). >This is the part of the address which is independent of the location, with >respect to network topology, of the entity which is addressed. > >If the OSI network protocol carried an EID the OSI-ese "fully >qualified Transport address" could simply be (EID+Nsel, Tsel), rather >than what you have above. The (debatable) advantage of this is that >you avoid identifying the entity with something as irrelevant and >potentially changeable as its location in the network. > You are right I had mis-understood what it was you were looking for. I believe the positioning between network and transport is what through me. What you are describing as EID is what OSI would call a "system-title". This is considered a globally unambiguous identifier taken from a name space independent of any for addresses or titles. I have never found a reason for carrying it in lower layer protocol or making it part of a lower layer address. (Primarily the reasons here were the topology-specific, but not routing specific, nature of addresses to aid routing protocols in keeping table sizes down.) I realize there are a lot of people who believe that addresses (transport or network) should be location independent. However, I believe that this is unworkable in reality, especially in a network of the size we are considering. The resulting tables to handle any address that comes along are not feasible or the impact on performance is not acceptable. It is important to separate the Application to network address mapping as one directory problem that has one kind of scope and performance attributes from the other "directory" which does the internet address to network address (or NSAP to SNPA) mapping which has a different scope and different performance characteristics. The former needs to be able to consider all applications in a location independent manner, but response to change can be slower than the latter. The latter "directory" needs to have much quicker response time, and somewhat smaller scope. However, there does seem to be some use for it by network management and for constructing application names, primarily those that one did not expect to migrate from system to system. >> The point here, Dick, is that the Internet doesn't have an application >> title concept and they need it. >[...] >> As the number of applications increases you really want to >> go to logical addressing and use of directory, i.e. application titles. > >Personally I am exceedingly happy to be able to find the server end of >applications without looking in a directory, and consider this a feature. >Running out of TCP ports in particular shouldn't ever be a problem since >schemes to replace "well-known port" with "well-known service name" >(like TCPMUX) should allow the application name space to be extended >indefinitely. While you may disagree with this, it would be much less >confusing if you didn't call your alternative an "EID" since people >who like "EID"s that others are talking about might not like the "EID"s >you are talking about (since they aren't the same thing). > Now you have caught my ignorance in my years out of touch with the Internet. I was not aware that anyone had actually proposed "service-names". Common service names with a system title can give you part of what you want. So you can say things like set up a connection to "system-name.ftp". This of course works as long as the ftp on a system can access all of the file systems. Once that is not the case or the file system is distributed over several systems, things get more complicated. Having these recorded in a directory with the mapping to the local network/transport address where it could be found would do much to lighten the overhead of administering applications and create the flexibility required to foster development in the upper layers. This would be a great benefit to the development of the upper layers in the Internet. Especially, if it were combined with a common protocol for setting up connections to applications, like telnet, ftp, etc. would be a great boon to the development of applications in the internet environment. Take care, John From owner-Big-Internet@munnari.oz.au Fri Oct 16 01:12:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12098; Fri, 16 Oct 1992 01:16:45 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11973; Fri, 16 Oct 1992 01:12:32 +1000 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA13279; Thu, 15 Oct 92 08:03:16 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA21256; Thu, 15 Oct 1992 09:01:35 -0400 To: "John Day" Subject: Re: Day vs Chiappa re EID In-Reply-To: <9210142046.27989@munnari.oz.au> References: <9210142046.27989@munnari.oz.au> Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu X-Mailer: Poste 2.0 From: David Oran Date: Thu, 15 Oct 92 09:01:28 -0400 Message-Id: <921015090128.15554@sneezy.lkg.dec.com> Encoding: 44 TEXT, 6 TEXT SIGNATURE > We already have the concept of Transport addresses in both architectures > why not use them? > Because transport addresses are not what people want for EIDs. A transport address changes when the network address changes and that's considered an undesirable property. If I could jump in with more OSI mumbo-jumbo, what I believe corresponds to an EID in the OSI architecture is a Transport Entity Title, not a TSAP address. This is, of course easy to say, since Transport Entity titles have never been fully defined by OSI, in the sense that there is no concrete representation of them as anything other than a local construct - i.e. they are carried in no protocols and stored in no databases. Boiling down all the discussion, an EID has the following very simple properties: 1) It names all of the communication endpoints that terminate in a single "host" (in internet terminology), or "open system" in OSI teminology. 2) If has spacial uniqueness over the entire set of hosts in the known universe, but does not necessarily have temporal uniqueness. 3) It contains many fewer bits compared to a human-sensible name for a host. 4) It need not change when either the name of the host, nor any of its network addresses changes. 5) It has no discernable internal structure from the point of view of either the protocols or host networking algorithms, but it may have structure which aids administration and assignment. 6) If a set of bits arrives at a host, and the set of bits contains an EID equal to the host's EID, then the host may assume that the bits were in fact intended for it (security issues aside). 7) If a set of bits arrives at a host, and the set of bits contains an EID not equal to the host's EID, the host must assume that the bits were not intended for it. I don't think any existing Internet or OSI protocol or host algorithm has a construct which precisely matches these properties. The ID as used in DECnet Phase V has all these properties except (6), but as a number of people have argued, its concrete encoding (IEEE 48-bit id), allocation method, and relationship to hardware instantiations may not have the desired properties for an Internet EID. Ever hopeful of consensus on technical issues... -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Fri Oct 16 02:30:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15325; Fri, 16 Oct 1992 02:30:31 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210151630.15325@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15321; Fri, 16 Oct 1992 02:30:25 +1000 (from jcurran@nic.near.net) To: David Oran Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subject: Re: Day vs Chiappa re EID In-Reply-To: Your message of Thu, 15 Oct 92 09:01:28 -0400. <921015090128.15554@sneezy.lkg.dec.com> Date: Thu, 15 Oct 92 12:30:00 -0400 From: John Curran From: David Oran Subject: Re: Day vs Chiappa re EID Date: Thu, 15 Oct 92 09:01:28 -0400 ... Boiling down all the discussion, an EID has the following very simple properties: 1) It names all of the communication endpoints that terminate in a single "host" (in internet terminology), or "open system" in OSI teminology. 2) If has spacial uniqueness over the entire set of hosts in the known universe, but does not necessarily have temporal uniqueness. 3) It contains many fewer bits compared to a human-sensible name for a host. 4) It need not change when either the name of the host, nor any of its network addresses changes. 5) It has no discernable internal structure from the point of view of either the protocols or host networking algorithms, but it may have structure which aids administration and assignment. 6) If a set of bits arrives at a host, and the set of bits contains an EID equal to the host's EID, then the host may assume that the bits were in fact intended for it (security issues aside). 7) If a set of bits arrives at a host, and the set of bits contains an EID not equal to the host's EID, the host must assume that the bits were not intended for it. This condensed list of EID properties matches my usage of the term "EID". I don't think any existing Internet or OSI protocol or host algorithm has a construct which precisely matches these properties. The ID as used in DECnet Phase V has all these properties except (6), but as a number of people have argued, its concrete encoding (IEEE 48-bit id), allocation method, and relationship to hardware instantiations may not have the desired properties for an Internet EID. Ever hopeful of consensus on technical issues... Also hopeful. We need to see if the PIP and Nimrod usage is the same. /John From owner-Big-Internet@munnari.oz.au Fri Oct 16 21:08:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01636; Fri, 16 Oct 1992 21:09:24 +1000 (from owner-Big-Internet) Return-Path: Received: from kauai.mcl.unisys.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01630; Fri, 16 Oct 1992 21:08:48 +1000 (from perry@MCL.Unisys.COM) Received: by kauai.MCL.Unisys.COM (4.1/mls/3.2) id AA04151; Fri, 16 Oct 92 07:05:18 EDT Date: Fri, 16 Oct 92 07:05:18 EDT From: perry@MCL.Unisys.COM (Dennis Perry) Message-Id: <9210161105.AA04151@kauai.MCL.Unisys.COM> To: big-internet@munnari.oz.au, deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: EIDs Cc: perry@mcl.unisys.com Noel suggests something we all too often ignore - system engineering. If we don't start looking at this complex network as a system, we will end up fixing pieces and at the same time breaking others pieces. Systems engineering is not something everyone understands, nor is it even taught in most universities. Even industry has lost some of the concepts as the work force the developed this engineering discipline get older and leave the workforce. dennis ------------------------- So, rather than create a strong base on which to solve all these problems (and others yet to come), by clearly distinguishing between boxes (endpoints, actually) and network attachment points, let's just kludge our way around the problems we see today? My impression is that the primary death mode for big systems is in entropy; i.e. the accumulation of warts, usually added to solve specific problems, which eventually encumber the system from growing and changing cleanly to meet new demands. Far better, when new capabilities are needed, to think about the problem and come to a new paradigm which provides the things you need as a side effect of a complete redesign. Noel From owner-Big-Internet@munnari.oz.au Fri Oct 16 22:48:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05354; Fri, 16 Oct 1992 22:48:36 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210161248.5354@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05351; Fri, 16 Oct 1992 22:48:26 +1000 (from day@BBN.COM) From: "John Day" Subject: Re: Day vs Chiappa re EID To: jcurran@nic.near.net Cc: big-internet@munnari.oz.au, day@munnari.oz.au, jnc@ginger.lcs.mit.edu, oran@sneezy.lkg.dec.com In-Reply-To: <9210151630.15325@munnari.oz.au> Date: Fri, 16 Oct 92 08:47:18 EDT Mail-System-Version: People, >This condensed list of EID properties matches my usage of the term "EID". > > I don't think any existing Internet or OSI protocol or host algorithm > has a construct which precisely matches these properties. The ID as > used in DECnet Phase V has all these properties except (6), but as a > number of people have argued, its concrete encoding (IEEE 48-bit id), > allocation method, and relationship to hardware instantiations may not > have the desired properties for an Internet EID. > The Transport Entity Title like all of the entity-titles derives from the reference model defining (N)-entity-title. No one ever assumed it would be needed in all layers, but was available if necessary. However, as I indicated in a previous note. It seems that what EID wants to be is what the Naming and Addressing work called System-title. Which appears to be useful primarily in forming other sorts of names and in network management. But there does not seem to be any good reason to use for "addressing", i.e. finding where to deliver things. John From owner-Big-Internet@munnari.oz.au Fri Oct 16 23:06:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06023; Fri, 16 Oct 1992 23:09:20 +1000 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05885; Fri, 16 Oct 1992 23:06:11 +1000 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA21251; Fri, 16 Oct 92 06:03:15 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA22102; Fri, 16 Oct 1992 09:03:03 -0400 To: "John Day" Subject: Re: Day vs Chiappa re EID In-Reply-To: <9210161248.AA20736@inet-gw-1.pa.dec.com> References: <9210161248.AA20736@inet-gw-1.pa.dec.com> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.0 From: David Oran Date: Fri, 16 Oct 92 09:03:01 -0400 Message-Id: <921016090301.15554@sneezy.lkg.dec.com> > But there does not seem to be any good reason to > use [an system title, EID, whatever] for "addressing", > i.e. finding where to deliver things. > I agree with your words, but perhaps not with the implication behind them. EIDs do not have good properties to use "naked" as the input function to a route computation. Everyone seems in violent agreement on that. What seems to be the sticking point is our differing technical judgements about the usefulness of EIDs as a way to ensure that things are delivered to the right place. These are related but not the same. From owner-big-internet@munnari.oz.au Sat Oct 17 01:05:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10764; Sat, 17 Oct 1992 01:06:03 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210161506.10764@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07518; Fri, 16 Oct 1992 23:55:35 +1000 (from day@BBN.COM) From: "John Day" Subject: Re: Day vs Chiappa re EID To: oran@sneezy.lkg.dec.com Cc: big-internet@munnari.oz.au, Day@munnari.oz.au In-Reply-To: <921016090301.15554@sneezy.lkg.dec.com> Date: Fri, 16 Oct 92 09:54:46 EDT Mail-System-Version: John Day wrote: >> But there does not seem to be any good reason to >> use [an system title, EID, whatever] for "addressing", >> i.e. finding where to deliver things. >> Dave Oran replied: >I agree with your words, but perhaps not with the implication behind them. >EIDs do not have good properties to use "naked" as the input function >to a route computation. Everyone seems in violent agreement on that. >What seems to be the sticking point is our differing technical judgements >about the usefulness of EIDs as a way to ensure that things are delivered >to the right place. These are related but not the same. John Day responded: So far so good. Where do you want to go with this line of discussion? From owner-Big-Internet@munnari.oz.au Sat Oct 17 01:52:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12627; Sat, 17 Oct 1992 01:52:08 +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 AA12624; Sat, 17 Oct 1992 01:52:03 +1000 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.57/Ultrix3.0-C) id AA29128; Fri, 16 Oct 92 11:51:51 -0400 Message-Id: <9210161551.AA29128@boa.gsfc.nasa.gov> Subject: Re: Day vs Chiappa re EID To: day@bbn.com Date: Fri, 16 Oct 92 11:51:51 EDT From: Dick desJardins Cc: big-internet@munnari.oz.au X-Mailer: ELM [version 2.3 PL11] After hearing privately from some of you folks, I am still coming down on the side of Dave Oran and Noel on this topic: the EID is architecturally the logical producer and consumer of packets within a box on the internet. In TCP/IP, this is whatever is "at" the IP address. As Frank Kastenholz has pointed out to me, this is not necessarily a TCP or UDP entity, but may be an ICMP, IGMP, GGP, OSPF, IGRP, IP, or ETHERNET "entity". In OSI, the EID uniquely identifies a Transport entity, therefore is a Transport entity title in OSI RM speak. To my good friend John Day: The EID is not trying to be anything related to applications at all, not application service, not application entity title, not fully qualified transport address. The EID has to be related to the destination of an IP or CLNP, *not* related to the content of the IP or CLNP user data. Noel is also right that the EID is not related to the specific interface by which the packet arrives in the box. "All roads lead to Rome." Several distinct interfaces may be used to reach a single EID. There may be several EIDs in one box, but they identify logically distinct entities. I believe all the above is consistent with Dave Oran's and Noel's thinking. (Note that I have not used the politically incorrect term "address" in describing my view of EIDs.) Dick From owner-Big-Internet@munnari.oz.au Sat Oct 17 02:25:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13547; Sat, 17 Oct 1992 02:25: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 AA13543; Sat, 17 Oct 1992 02:25:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00739; Fri, 16 Oct 92 12:25:43 -0400 Date: Fri, 16 Oct 92 12:25:43 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210161625.AA00739@ginger.lcs.mit.edu> To: Day@bbn.com, jcurran@nic.near.net Subject: Re: Day vs Chiappa re EID Cc: big-internet@munnari.oz.au, day@ginger.lcs.mit.edu, jnc@ginger.lcs.mit.edu, oran@sneezy.lkg.dec.com But there does not seem to be any good reason to use for "addressing", i.e. finding where to deliver things. Who said there was? I want to name the endpoints of connections with them. Noel From owner-Big-Internet@munnari.oz.au Mon Oct 19 11:43:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04592; Mon, 19 Oct 1992 11:43:44 +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 AA04589; Mon, 19 Oct 1992 11:43:39 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA21549 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 19 Oct 1992 11:43:50 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA23388; Mon, 19 Oct 92 11:43:30 EST Message-Id: <9210190143.AA23388@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Cc: smart@mel.dit.csiro.au Subject: EID compromise Date: Mon, 19 Oct 92 11:43:24 +1000 From: Bob Smart There are 2 separate issues with regard to EIDs: (1) whether we need them at all; (2) whether they should be in the packets. The arguments against EIDs sometimes seem to be of the form "(2) is not necessary since we can deduce the EID from the address, therefore we don't need EIDs at all". This doesn't follow. Firstly let me assert that EIDs are in 1-1 correspondence with a subset of the domain names in the DNS. As such domain names will work fine as EIDs, and the argument against using them is simply that they are unsuitable for inclusion in every packet. Given that backward compatibility is a significant issue we can't just say that all security issues should be handled without trusting other hosts based on identity. So we need to be able to work out the identity of an end-point from its address (or check that an address goes with a given end-point identity which is likely to be the same job). Given that we need to be able to do that sometimes, why not do it always. That way: (1) we can use the domain name as the EID avoiding creating a new namespace; (2) we save space in every packet. [This argument has nothing to do with the argument that we should use a complete address/nsap as the effective EID (e.g. in the TCP pseudo-header). That option seems certain to be overtaken by elephants in an increasingly dynamic addressing/routing environment. In TUBA it doesn't even gain packet space since the debate there is whether a 6/8 byte field that is certain to be there should be made globally unique. The reason for not doing so is to allow existing CLNP NSAPs to participate in TUBA. Such existing use of CLNP is insignificant, and I wonder if the real objective is to keep change control with ISO. Just because I'm paranoid doesn't mean they're not out to get me.] The argument for having an EID in every packet is that a lot of communication doesn't require any trust at all. Why make the receiver of a packet go to the trouble of working out who the sender is if it doesn't care? And indeed why go through a database search process which might fail due to temporary communication problems when the information isn't necessary? Perhaps we can compromise. We add a bit for EID-based trust. 1. If it is trusted communication then the EID (used to determine continuity for transport connections) is always deduced from the address. The EID is never in the packet. 2. If it is untrusted communication and there is no need to worry about address changes (e.g. in a UDP exchange) then the address is used as an EID. Again there is no separate EID in the packets. 3. If it is untrusted communication with address change possible then the EID (presumably a domain name) is sent initially and at least whenever the address changes. It can be sent in a host-only option. Untrusted communication in this sense also includes communication which uses some better mechanism for its trust (such as encryption). We would hope that case (1) would die out. I have this vague feeling that I must have forgotten something... Bob Smart From owner-Big-Internet@munnari.oz.au Mon Oct 19 12:50:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07282; Mon, 19 Oct 1992 12:50: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 AA07274; Mon, 19 Oct 1992 12:50:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12132; Sun, 18 Oct 92 22:50:26 -0400 Date: Sun, 18 Oct 92 22:50:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210190250.AA12132@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: EID compromise Cc: jnc@ginger.lcs.mit.edu There are 2 separate issues with regard to EIDs: (1) whether we need them at all; (2) whether they should be in the packets. Exactly. Firstly let me assert that EIDs are in 1-1 correspondence with a subset of the domain names in the DNS. As such domain names will work fine as EIDs Sorry, I don't believe this assertion will always be true, even though it is pretty much true in practise now. The best *example* I can think of at the moment is mobile computations, which will probably not be named in the DNS namespace. Note that this is just *an* example, not the only probable use in the future, or a complete logical case why this assertion is true! I will mention again that I hoped that in the future the EID would be *the* identification in the internet layer of the source and destination of the packet, and the topological location of the endpoint (i.e. the address) would not mandatorily be in every packet. I wonder if the real objective is to keep change control with ISO. Just because I'm paranoid doesn't mean they're not out to get me. "This is the IETF, and we don't speculate about motives. Right!?" Noel From owner-Big-Internet@munnari.oz.au Mon Oct 19 13:30:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09137; Mon, 19 Oct 1992 13:30:17 +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 AA09133; Mon, 19 Oct 1992 13:30:13 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA23100 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 19 Oct 1992 13:30:26 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA23840; Mon, 19 Oct 92 13:30:08 EST Message-Id: <9210190330.AA23840@wanda.mel.dit.CSIRO.AU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: EID compromise In-Reply-To: Your message of "Sun, 18 Oct 92 22:50:26 -0400." <9210190250.AA12132@ginger.lcs.mit.edu> Date: Mon, 19 Oct 92 13:30:06 +1000 From: Bob Smart >Sorry, I don't believe this assertion will always be true, even though it is >pretty much true in practise now. The best *example* I can think of at the >moment is mobile computations, which will probably not be named in the DNS >namespace. Let me see, the reason for having EIDs separate to domain names is not that we'll have domain names with multiple EIDs or EIDs with multiple domain names, but because we'll have EIDs with no domain names at all!! And we need something guaranteed unique for this no-name to use as a handle for transport continuity. Why is it easier to give it (and indeed everything) an EID number than to put the mobile host in the DNS (with a NULL RR if it doesn't need any others)? I didn't mean to suggest that domain name <--> address mappings would always (or even ever) be done through the DNS. The DNS is probably not suitable for a relationship that changes quite quickly. The DNS could have pointers to where to ask for address information for hosts and where to ask for inverse information for groups (e.g. subnets) of addresses. >"This is the IETF, and we don't speculate about motives. Right!?" I agree that my speculation was unhelpful. Particularly as the rest of my note effectively concedes that the argument against not creating another namespace (which is the only argument that applies to TUBA) has some merit! Bob Smart From owner-Big-Internet@munnari.oz.au Mon Oct 19 15:15:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12971; Mon, 19 Oct 1992 15:15:25 +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 AA12954; Mon, 19 Oct 1992 15:15:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12621; Mon, 19 Oct 92 01:14:59 -0400 Date: Mon, 19 Oct 92 01:14:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210190514.AA12621@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, smart@mel.dit.csiro.au Subject: Re: EID compromise Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Let me see, the reason for having EIDs separate to domain names is not that we'll have domain names with multiple EIDs or EIDs with multiple domain names, but because we'll have EIDs with no domain names at all!! I never meant to leave out the first two possibilities; just picked an example that's a little trickier to do with address and source routes! Why is it easier to give it (and indeed everything) an EID number than to put the mobile host in the DNS (with a NULL RR if it doesn't need any others)? Making EID's be a strict subset of DNS names has some attractions, such as the principal one you mentioned, which is not needing another namespace. However, on balance I don't feel comfortable with it. Endpoints (i.e. the entity on each end of a reliable connection) are pretty fundamental objects in networking, and having a "second-hand" namespace for them makes me uncomfortable. If they are as critical as I think they are, they deserve a namespace optimized for computer use. Here's an *example* of the kind of thing that happens. Suppose we decide to make the TCP checksum be in terms of endpoints. Probably the right thing, right? We could use the DNS name for this; it doesn't *have* to be in each packet, just available at each end where you calculate the checksum. Ooops, what about client-server interactions, where the server does not usually know the hostname, unless it does a reverse lookup in DNS... and since EID's aren't in the packet, the only thing it can use is the address. Sure, you could fix this one, with some work, and other similar ones for a while, but fall across a few of these, and you start to think maybe EID's will make your life a lot simpler. The great thing about EID's is once you put them in for *one* function (and they aren't *that* expensive), they start to do all sorts of other things at basically no cost at all.. the rest of my note effectively concedes that the argument against not creating another namespace (which is the only argument that applies to TUBA) has some merit That's the spirit! Technical arguments only, and may the best design win! Noel From owner-Big-Internet@munnari.oz.au Mon Oct 19 15:38:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13908; Mon, 19 Oct 1992 15:38:09 +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 AA13905; Mon, 19 Oct 1992 15:38:05 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA25148 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 19 Oct 1992 15:38:22 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA24442; Mon, 19 Oct 92 15:38:02 EST Message-Id: <9210190538.AA24442@wanda.mel.dit.CSIRO.AU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: EID compromise In-Reply-To: Your message of "Mon, 19 Oct 92 01:14:59 -0400." <9210190514.AA12621@ginger.lcs.mit.edu> Date: Mon, 19 Oct 92 15:38:01 +1000 From: Bob Smart > Let me see, the reason for having EIDs separate to domain names is not > that we'll have domain names with multiple EIDs or EIDs with multiple > domain names, but because we'll have EIDs with no domain names at all!! > >I never meant to leave out the first two possibilities Why would a domain name have 2 EIDs? How/when would you decide to use one and not the other? Why would one EID be the EID of 2 domain names? I'm not talking aliasing here but a situation where an entry under in-eid.arpa has 2 PTR records. Bob Smart From owner-Big-Internet@munnari.oz.au Mon Oct 19 18:16:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20298; Mon, 19 Oct 1992 18:16:15 +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 AA20295; Mon, 19 Oct 1992 18:16:07 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA12267; Mon, 19 Oct 1992 09:17:08 +0100 Message-Id: <199210190817.AA12267@mitsou.inria.fr> To: Bob Smart Cc: big-internet@munnari.oz.au Subject: Re: EID compromise In-Reply-To: Your message of "Mon, 19 Oct 92 13:30:06 +1000." <9210190330.AA23840@wanda.mel.dit.CSIRO.AU> Date: Mon, 19 Oct 92 09:17:08 -0500 From: Christian Huitema X-Mts: smtp Bob, I have read the discussion on EIDs, and still fail to be convinced. The only "agreement" I can read here is that EIDs are used for naming, not routing. From which I draw two conclusions: 1) If EIDs are not used for routing, there is no point in specifying them as part of an internetworking protocol. The best you can do is to provide a field that is embedded in the internetworking headers and only has an end-to-end meaning. Call it the way you want, hidden communication channel, bloated up interface specification, poor attempt to use chunks of a mega-iso mistake; my personal opinion on such designs is just "poor engineering". 2) If EIDs are used for naming, we should be very careful on what they name, what is their structure, how easy they can be used by applications. I assert that we dont know yet what the need of the next generation of application will be. I have read a lot of iso-ese about transport layer end point identifiers -- that looks like building for the 21st century by looking at the architecture of the 70's. Just explain me how EIDs relate to integrated layer processing, or how they can be used to identify processes that migrate from network interface to network interface, or how they relate to a certification structure if you want to use them for security. If EIDs are used end-to-end, they should be specified by an end-to-end protocol, which may or may not decide to carry them in each and every packet. If we dont know yet what the names will be used for, we should avoid designing a new name space for the thin argument that DNS names, which seem to satisfy most of the requirements I heard, dont fit in the last bits of an OSI-NSAP. Christian Huitema From owner-Big-Internet@munnari.oz.au Mon Oct 19 21:44:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27663; Mon, 19 Oct 1992 21:44:36 +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 AA27587; Mon, 19 Oct 1992 21:44:12 +1000 (from kre) To: Christian Huitema Cc: big-internet@munnari.oz.au Subject: Re: EID compromise In-Reply-To: Your message of Mon, 19 Oct 92 09:17:08 -0500. <199210190817.AA12267@mitsou.inria.fr> Date: Mon, 19 Oct 92 21:44:00 +1000 Message-Id: <14141.719495040@munnari.oz.au> From: Robert Elz Date: Mon, 19 Oct 92 09:17:08 -0500 From: Christian Huitema Message-ID: <199210190817.AA12267@mitsou.inria.fr> 1) If EIDs are not used for routing, there is no point in specifying them as part of an internetworking protocol. There is a certain attractiveness to this argument. I wonder at the almost total lack of comment on John Curran's TUNE proposal, which addresses exactly this point. True, it has not yet appeared as an I-D, and while it did appear on the B-I list in preliminary form, it was under the somewhat uninspiring Subject: of "Re: EIDs" somwehat into (yet another) lengthy debate on the issue... You'll find it in this month's archives of the list, its message number 242 in the archive file, was posted from munnari on Thurs Oct 8 at 07:37 (that means it will have arrived in most of your mailboxes sometime on Weds Oct 7 local time), its Message-ID was (is) <9210072137.23824@munnari.oz.au> (from which I infer incidentally that John's mailer didn't supply one - Tsk Tsk...) and carries a Date: line of "Wed, 07 Oct 92 09:02:41 -0400". (And yes, it was processed during the lead in to that big processing backlog, when there were LOTS of B-I messages floating around, and ended up "pausing" at munnari for just over 11 hours between first arriving here, and starting to be delivered). Now having given all that meaningless info, I will also say that I have extracted the draft I-D (if it really makes sense to have a draft draft) from the message and installed it in the B-I archives as a separate item, you'll find it on munnari.OZ.AU in big-internet/TUNE (that file is 32439 bytes long). John's proposal is given in the context of TUBA, but applies equally wwell to other proposals, in fact probably better to SIP, PIP, etc, than it does to TUBA (in my opinion anyway). The best you can do is to provide a field that is embedded in the internetworking headers and only has an end-to-end meaning. The obvious exception to this, of course, is Nimrod, where the field is used as a cache tag - the assumptions being that most packets traversing a particular path to a particular endpoint will all be going to the same destination address, and that the EID is shorter than the address (or no longer than it anyway), so that it might make sense to carry the EID in the packet (for forwarding purposes, not routing) rather than the destination address (and conversly the source for ICMP type packets to use). 2) If EIDs are used for naming, we should be very careful on what they name, what is their structure, how easy they can be used by applications. I assert that we dont know yet what the need of the next generation of application will be. I am not at all concerned with the needs of any applications, and don't see the EID as being of any primary interest to applications at all, it is NOT intended to be a name at that level. The point of the EID is to identify a transport endpoint in a location independant manner, and in a form that's reasonable to use. Its true that DNS names are similar in purpose, but those have all kinds of human related connotations, as they're human visible. I can imagine where a personal system may change its DNS name at the whim of its owner (bored with Elvis, time to name my host after the Grateful Dead instead...). I don't see that we should by that automaticaly terminate all transport level connections into the host (nor do I see that we should do that if the host's location, and hence its "location dependant identifier" (aka address) changes). By being both location and human independant I see the EID as having a useful role. Exactly where the bits should be put in the packet is a matter for each potential protocol to decide (if TUBA wants to bury them inside the NSAP, that's OK, if SIP were to carry them in a higher level TUNE layer, that's fine too). The attractiveness of the decisions taken will be one factor to weigh when we're finally deciding which of the candidates will be supported for IPv7. Personally, I'd consider omitting an EID from a proposal to be enough reason to reject a candidate outright. kre From owner-Big-Internet@munnari.oz.au Mon Oct 19 23:40:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02374; Mon, 19 Oct 1992 23:41:05 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210191341.2374@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02360; Mon, 19 Oct 1992 23:40:56 +1000 (from day@BBN.COM) From: "John Day" Subject: Re: Day vs Chiappa re EID To: desjardi@boa.gsfc.nasa.gov Cc: big-internet@munnari.oz.au, day@munnari.oz.au In-Reply-To: <9210161551.AA29128@boa.gsfc.nasa.gov> Date: Mon, 19 Oct 92 09:39:41 EDT Mail-System-Version: After some local discussing around here, I believe this issue of what an EID is is becoming clearer: DesJardins writes: > >the EID is architecturally the logical producer and >consumer of packets within a box on the internet. Well, no. As you indicate below the EID names a transport entity which is the producer and consumer of packets. This is a nit. But I have found that in things related to naming care in being precise is critical or things get very confused. > >In TCP/IP, this is whatever is "at" the IP address. >As Frank Kastenholz has pointed out to me, this is >not necessarily a TCP or UDP entity, but may be an >ICMP, IGMP, GGP, OSPF, IGRP, IP, or ETHERNET "entity". > Are you implying that EIDs should be involved in the resolution of the destination of ICMP, IGMP, GGP, etc.? If so, then things get a lot more confused. >In OSI, the EID uniquely identifies a Transport entity, >therefore is a Transport entity title in OSI RM speak. > From discussions with John Curran, it appears that what John is seeking is somewhere he can get a globally unambiguous name space. Now most of us felt that the best place for this to occur would be at the Network Layer. A global location-dependent, but routing independent name space between network and transport is what is required. The IP name space is route dependent in that it names the network attachment point. This is an accident of history. The name space defined for use with CLNP (being done aftwards) solves this problem. John seems to feels that we have lost (or about to lose) that opportunity that different name spaces at the network layer are a done deal and we will never be able to get everyone using the same global name space. Therefore, he feels that we should fall back and re-group at the transport layer. (Clearly, I am putting words in John's mouth so speak up John if I am misrepresenting your view.) Frankly, I am not ready to admit that all is lost, just yet. There are real advantages to doing this at the network layer that are not possible at the Transport Layer. Also I am not convinced that we won't see the same thing happen at the Transport Layer. Then do we retreat to the applications? >To my good friend John Day: The EID is not trying to >be anything related to applications at all, not >application service, not application entity title, >not fully qualified transport address. The EID has >to be related to the destination of an IP or CLNP, >*not* related to the content of the IP or CLNP user data. My only point with respect to applications, is that I believe that applications are the first place where it makes any sense to have location independent names for any thing. > >Noel is also right that the EID is not related to the >specific interface by which the packet arrives in the box. >"All roads lead to Rome." Several distinct interfaces >may be used to reach a single EID. There may be several >EIDs in one box, but they identify logically distinct >entities. > The property of the EID not relating to a specific interface is the property that is desired. However, the property that it is location independent creates probably my biggest objection. By not being location dependent, this will require considerably larger routing tables since you will not be able to derive any "nearness" from the name to aid routing. (Analogous to a postman seeing a letter for Nimes France. He doesn't have to know where in France Nimes is just that the letter would be better going east than west.) The other way is to in essence have the Transport Layer get involved in routing by picking the mapping to destination network address, i.e. the interface to deliver the packet to, before it sends it. This is would have to be done on each packet sent, since the routing may change during the lifetime of the connection. In fact, there is no guarantee that by the time the packet gets there that route will work anyway. And much of the advantage of the connectionless approach is lost. I still believe that a globally unambiguous location dependent but route independent name is required between network and transport. The name is used by routing in the network layer to deliver data to transport protocols independent of the point of attachment. To do otherwise will greatly increase the complexity of the system. It would be a great disservice to the claim of technical correctness over political expediency that this group aspires to to throw in the towel just because a bunch of religious fanatics (on either side) can't agree on how to get to a globally unambiguous name space. From owner-Big-Internet@munnari.oz.au Mon Oct 19 23:49:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02711; Mon, 19 Oct 1992 23:49:43 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210191349.2711@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02708; Mon, 19 Oct 1992 23:49:35 +1000 (from day@BBN.COM) From: "John Day" Subject: Re: Day vs Chiappa re EID To: desjardi@boa.gsfc.nasa.gov Cc: big-internet@munnari.oz.au, day@munnari.oz.au In-Reply-To: <9210161551.AA29128@boa.gsfc.nasa.gov> Date: Mon, 19 Oct 92 09:41:18 EDT Mail-System-Version: After some local discussing around here, I believe this issue of what an EID is is becoming clearer: DesJardins writes: > >the EID is architecturally the logical producer and >consumer of packets within a box on the internet. Well, no. As you indicate below the EID names a transport entity which is the producer and consumer of packets. This is a nit. But I have found that in things related to naming care in being precise is critical or things get very confused. > >In TCP/IP, this is whatever is "at" the IP address. >As Frank Kastenholz has pointed out to me, this is >not necessarily a TCP or UDP entity, but may be an >ICMP, IGMP, GGP, OSPF, IGRP, IP, or ETHERNET "entity". > Are you implying that EIDs should be involved in the resolution of the destination of ICMP, IGMP, GGP, etc.? If so, then things get a lot more confused. >In OSI, the EID uniquely identifies a Transport entity, >therefore is a Transport entity title in OSI RM speak. > From discussions with John Curran, it appears that what John is seeking is somewhere he can get a globally unambiguous name space. Now most of us felt that the best place for this to occur would be at the Network Layer. A global location-dependent, but routing independent name space between network and transport is what is required. The IP name space is route dependent in that it names the network attachment point. This is an accident of history. The name space defined for use with CLNP (being done aftwards) solves this problem. John seems to feels that we have lost (or about to lose) that opportunity that different name spaces at the network layer are a done deal and we will never be able to get everyone using the same global name space. Therefore, he feels that we should fall back and re-group at the transport layer. (Clearly, I am putting words in John's mouth so speak up John if I am misrepresenting your view.) Frankly, I am not ready to admit that all is lost, just yet. There are real advantages to doing this at the network layer that are not possible at the Transport Layer. Also I am not convinced that we won't see the same thing happen at the Transport Layer. Then do we retreat to the applications? >To my good friend John Day: The EID is not trying to >be anything related to applications at all, not >application service, not application entity title, >not fully qualified transport address. The EID has >to be related to the destination of an IP or CLNP, >*not* related to the content of the IP or CLNP user data. My only point with respect to applications, is that I believe that applications are the first place where it makes any sense to have location independent names for any thing. > >Noel is also right that the EID is not related to the >specific interface by which the packet arrives in the box. >"All roads lead to Rome." Several distinct interfaces >may be used to reach a single EID. There may be several >EIDs in one box, but they identify logically distinct >entities. > The property of the EID not relating to a specific interface is the property that is desired. However, the property that it is location independent creates probably my biggest objection. By not being location dependent, this will require considerably larger routing tables since you will not be able to derive any "nearness" from the name to aid routing. (Analogous to a postman seeing a letter for Nimes France. He doesn't have to know where in France Nimes is just that the letter would be better going east than west.) The other way is to in essence have the Transport Layer get involved in routing by picking the mapping to destination network address, i.e. the interface to deliver the packet to, before it sends it. This is would have to be done on each packet sent, since the routing may change during the lifetime of the connection. In fact, there is no guarantee that by the time the packet gets there that route will work anyway. And much of the advantage of the connectionless approach is lost. I still believe that a globally unambiguous location dependent but route independent name is required between network and transport. The name is used by routing in the network layer to deliver data to transport protocols independent of the point of attachment. To do otherwise will greatly increase the complexity of the system. It would be a great disservice to the claim of technical correctness over political expediency that this group aspires to to throw in the towel just because a bunch of religious fanatics (on either side) can't agree on how to get to a globally unambiguous name space. From owner-Big-Internet@munnari.oz.au Mon Oct 19 23:49:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02719; Mon, 19 Oct 1992 23:50:02 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210191350.2719@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02715; Mon, 19 Oct 1992 23:49:54 +1000 (from day@BBN.COM) From: "John Day" Subject: Re: Day vs Chiappa re EID To: desjardi@boa.gsfc.nasa.gov Cc: big-internet@munnari.oz.au, day@munnari.oz.au In-Reply-To: <9210161551.AA29128@boa.gsfc.nasa.gov> Date: Mon, 19 Oct 92 09:46:09 EDT Mail-System-Version: After some local discussing around here, I believe this issue of what an EID is is becoming clearer: DesJardins writes: > >the EID is architecturally the logical producer and >consumer of packets within a box on the internet. Well, no. As you indicate below the EID names a transport entity which is the producer and consumer of packets. This is a nit. But I have found that in things related to naming care in being precise is critical or things get very confused. > >In TCP/IP, this is whatever is "at" the IP address. >As Frank Kastenholz has pointed out to me, this is >not necessarily a TCP or UDP entity, but may be an >ICMP, IGMP, GGP, OSPF, IGRP, IP, or ETHERNET "entity". > Are you implying that EIDs should be involved in the resolution of the destination of ICMP, IGMP, GGP, etc.? If so, then things get a lot more confused. >In OSI, the EID uniquely identifies a Transport entity, >therefore is a Transport entity title in OSI RM speak. > From discussions with John Curran, it appears that what John is seeking is somewhere he can get a globally unambiguous name space. Now most of us felt that the best place for this to occur would be at the Network Layer. A global location-dependent, but routing independent name space between network and transport is what is required. The IP name space is route dependent in that it names the network attachment point. This is an accident of history. The name space defined for use with CLNP (being done aftwards) solves this problem. John seems to feels that we have lost (or about to lose) that opportunity that different name spaces at the network layer are a done deal and we will never be able to get everyone using the same global name space. Therefore, he feels that we should fall back and re-group at the transport layer. (Clearly, I am putting words in John's mouth so speak up John if I am misrepresenting your view.) Frankly, I am not ready to admit that all is lost, just yet. There are real advantages to doing this at the network layer that are not possible at the Transport Layer. Also I am not convinced that we won't see the same thing happen at the Transport Layer. Then do we retreat to the applications? >To my good friend John Day: The EID is not trying to >be anything related to applications at all, not >application service, not application entity title, >not fully qualified transport address. The EID has >to be related to the destination of an IP or CLNP, >*not* related to the content of the IP or CLNP user data. My only point with respect to applications, is that I believe that applications are the first place where it makes any sense to have location independent names for any thing. > >Noel is also right that the EID is not related to the >specific interface by which the packet arrives in the box. >"All roads lead to Rome." Several distinct interfaces >may be used to reach a single EID. There may be several >EIDs in one box, but they identify logically distinct >entities. > The property of the EID not relating to a specific interface is the property that is desired. However, the property that it is location independent creates probably my biggest objection. By not being location dependent, this will require considerably larger routing tables since you will not be able to derive any "nearness" from the name to aid routing. (Analogous to a postman seeing a letter for Nimes France. He doesn't have to know where in France Nimes is just that the letter would be better going east than west.) The other way is to in essence have the Transport Layer get involved in routing by picking the mapping to destination network address, i.e. the interface to deliver the packet to, before it sends it. This is would have to be done on each packet sent, since the routing may change during the lifetime of the connection. In fact, there is no guarantee that by the time the packet gets there that route will work anyway. And much of the advantage of the connectionless approach is lost. I still believe that a globally unambiguous location dependent but route independent name is required between network and transport. The name is used by routing in the network layer to deliver data to transport protocols independent of the point of attachment. To do otherwise will greatly increase the complexity of the system. It would be a great disservice to the claim of technical correctness over political expediency that this group aspires to to throw in the towel just because a bunch of religious fanatics (on either side) can't agree on how to get to a globally unambiguous name space. From owner-Big-Internet@munnari.oz.au Mon Oct 19 23:57:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03140; Mon, 19 Oct 1992 23:57:55 +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 AA03130; Mon, 19 Oct 1992 23:57:40 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA26707; Mon, 19 Oct 92 06:56:25 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA24000; Mon, 19 Oct 1992 09:56:23 -0400 To: Bob Smart Subject: Re: EID compromise In-Reply-To: <9210190143.AA23388@wanda.mel.dit.CSIRO.AU> References: <9210190143.AA23388@wanda.mel.dit.CSIRO.AU> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.0 From: David Oran Date: Mon, 19 Oct 92 09:56:17 -0400 Message-Id: <921019095617.15554@sneezy.lkg.dec.com> Encoding: 39 TEXT, 6 TEXT SIGNATURE > The argument for having an EID in every packet is that a lot of > communication doesn't require any trust at all. Why make the receiver > of a packet go to the trouble of working out who the sender is if it > doesn't care? And indeed why go through a database search process > which might fail due to temporary communication problems when the > information isn't necessary? > As a general supporter of EIDs, I have all of a sudden become VERY SCARED about what direction Bob is taking this in. If the intention is to use EIDs in any way as a method to decide whether you believe the sender/receiver of a packet is who you think it is, I get off the boat immediately. Thwere are serious dangers in using an EID in this way: 1) It provides no real security, since EIDs can be trivially spoofed. 2) Real people don't have trust relationships with EIDs, they have trust in the binding of a secret (shared or not depending on the scheme) to a name. If the EID is simply a proxy for the name this only introduces an avenue of attack where the binding between the name and EID can be compromised. 3) Making access/authentication decisions based on an EID would require backmapping the EID to a name. Requiring that such backmaps be feasible (and trustworthy) in a large Internet scares the bejezuz out of me. (I can spoof today's inaddr.arpa so easily it isn't even a challenge). I was very careful in my description of the properties of an EID to say that upon receipt of a packet with an EID that the host *may* conclude that the packet is for it. Not *must* but, *may*. Conversely it is ok for a host receiving a packet with an EID not its own to conclude that it *must* discard the packet. Similarly, receiving a packet with the EID of a source only relates that packet to other packets seen with that EID, not with packets from the same actual source. Bottom line: if you have ambitions to use EIDs for security purposes I hereby reverse by position in favor. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Tue Oct 20 00:26:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04901; Tue, 20 Oct 1992 00:27:12 +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 AA04878; Tue, 20 Oct 1992 00:26:47 +1000 (from kre) To: "John Day" Cc: big-internet@munnari.oz.au Subject: Re: Day vs Chiappa re EID In-Reply-To: Your message of Mon, 19 Oct 92 09:46:09 -0400. Date: Tue, 20 Oct 92 00:26:35 +1000 Message-Id: <14245.719504795@munnari.oz.au> From: Robert Elz Date: Mon, 19 Oct 92 09:46:09 EDT From: "John Day" First, you can stop resending copies of this to B-I, if you're getting bounces its because you're also sending to day@munnari.oz.au who doesn't exist (which may indicate a fault in your mailer, but this isn't the right place to talk about that). But I have found that in things related to naming care in being precise is critical or things get very confused. Absolutely. Are you implying that EIDs should be involved in the resolution of the destination of ICMP, IGMP, GGP, etc.? ICMP, probably not in the sense you're meaning I think, but yse, in the sense, that an error type ICMP message should include the EID's from the packet that failed so that the recipient can use those to identify the packet that failed. I don't know enough about IGMP or GGP to really comment, but I'd tend to assume that EIDs may have a role in those. From discussions with John Curran, it appears that what John is seeking is somewhere he can get a globally unambiguous name space. yes. Now most of us felt that the best place for this to occur would be at the Network Layer. Which layer things occur in has some relationship with the purity of the design, but relatively little to do with the practicalities. A global location-dependent, but routing independent name space between network and transport is what is required. Absolutely not, it must be location independant. Frankly, I am not ready to admit that all is lost, Nor am I, EIDs clearly belong, though which layer you shove them into has little impact in my thinking. My argument against defining them at the transport layer is that they belong in every transport layer, having them available at a lower level avoide duplication of effort (of definition of the things) and regularises their location in packets. Whether lower than transport implies network, or means another intermediate layer between transport and network doesn't matter much to me. The property of the EID not relating to a specific interface is the property that is desired. Not entirely, it should be totally unrelated to the topology of the network. However, the property that it is location independent creates probably my biggest objection. By not being location dependent, this will require considerably larger routing tables since you will not be able to derive any "nearness" from the name to aid routing. But you're assuming that the EID is used for routing, which I dispute, it has nothing to do with routing at all (or no more than a DNS name does). The other way is to in essence have the Transport Layer get involved in routing by picking the mapping to destination network address, Just as it does if EIDs were not to exist at all, yes, exactly. i.e. the interface to deliver the packet to, This depends on your definition of just what is a destination address, that is, whether it necessarily names a particular interface (which I believe it probably should, but which others definitely disagree with). This is would have to be done on each packet sent, since the routing may change during the lifetime of the connection. In theory yes, in practice, no - this is where some engineering needs to be applied, allow the sender to be given a hint as to when it might want to alter the address it has been using. See John Curran's TUNE draft for one idea. In fact, there is no guarantee that by the time the packet gets there that route will work anyway. This is true whatever we're using, its part of the nature of connectionless networks (the host may have crashed, there may be no route that will work). Again, in practice its not a big problem. I still believe that a globally unambiguous location dependent but route independent name is required between network and transport. The name is used by routing in the network layer to deliver data to transport protocols independent of the point of attachment. To do otherwise will greatly increase the complexity of the system. This sounds like yet another level of naming, and encompasses what some have called network addresses, but is certainly not what any of the discussions of EIDs have been related to. Whether there should be two levels of address, one which points to the location of an end-point, but not a particular interface, and another which includes the latter is (or should be) the subject of a different discussion, please, lets avoid confusing this with EIDs. kre From owner-Big-Internet@munnari.oz.au Tue Oct 20 00:35:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05260; Tue, 20 Oct 1992 00:36: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 AA05241; Tue, 20 Oct 1992 00:35:50 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14193; Mon, 19 Oct 92 10:35:30 -0400 Date: Mon, 19 Oct 92 10:35:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210191435.AA14193@ginger.lcs.mit.edu> To: Day@bbn.com, desjardi@boa.gsfc.nasa.gov Subject: Re: Day vs Chiappa re EID Cc: big-internet@munnari.oz.au, day@munnari.oz.au, jnc@ginger.lcs.mit.edu As you indicate below the EID names a transport entity which is the producer and consumer of packets. Well, when I originally defined the term "endpoint" I defined it as an end-end/fate-sharing entity, which would be one end of a end-end (reliable transport) connection, so I guess your definition is pretty much isomorphic. The EID is simply a particular form of a name for an endpoint. in things related to naming care in being precise is critical or things get very confused. Absolutely! Are you implying that EIDs should be involved in the resolution of the destination of ICMP, IGMP, GGP, etc.? No, I think he was just saying that EID's would be used by more than just TCP and UDP; i.e. all packets would be from one endpoint to another. A global location-dependent, but routing independent name space between network and transport is what is required. It was never intended that EID's should be location dependant; in fact, it was *explicitly* intended that they not be. Now, you may have a use for a name for endpoints with those characteristics, but please don't call it an EID! The IP name space is route dependent in that it names the network attachment point. It is with great difficultly that I refrain from a rude, arrogant MIT-type remark in response to this! :-) I conclude that there must be some terminology conflict to produce a remark which seems to me so utterly confused. A "route", to me, is a path through the network substrate of routers and networks from a source address (attachment point) to a destination. I believe we share the definition of network attachment point. What can the problem be? I believe you must be making some unstated assumptions about the routing... let me make a guess as to what they are. There is no *a priori* connection between the name of network attachment point and the route taken from it to another NAP. The routing system is free, given two NAP's, to create any route between then it feels like! There may be a connection in practise, due to the design of the routing, particularly in a heirarchical routing system, but this is the results of the goals of the routing system, and design tradeoffs therein, not a fundamental necessity. To see this, let's define what I call "optimal" routing. A simple example is a system in which each router/network is named from a flat namespace, all links/routers have a single metric, and a distributed "best-path" routing system such LS/SPF is used to calculate routes. Packets from any source to any destination will take the optimal path (i.e. lowest sum of metrics) in the actual topology. Hierarchical routing systems are basically not optimal, in this technical definition. Heirarchical routing trades off one cost (routing overhead) for another (non-optimal routes); non-optimal routes are, in one sense, the *whole point* of heirarchical routing systems. This is intuitively obvious; the optimal routing system, with effectively flat addresses, was what was needed to produce optimal routes, and a system with less information (i.e. less routing overhead) must be cutting corners somewhere; TANSTAAFL. Thus, in some sense, in heirarchical routing the route *is* affected by what address you give it. However, if your system is not a pure heirarchy (e.g. OSPF), and you have a knob you can turn to allow lower level information to leak out, by turning this knob to produce more and more leaked information you get a system which is closer and closer to the flat system, and in which the routes have less and less to do with the distortions caused by the heirarchy abstraction process, and approach the optimal closer and closer. There is thus, in practise, *NO* set connection between an IP address and the route through the network, from any source IP address, taken to reach that address! Theoretically, a group of IP addresses on the same IP (sub)-network are fully connected, but that is about it, and since the advent of host routes, not even that is true! *Everything* else about the path is up to the IP routing system to decide.. There are real advantages to doing this at the network layer that are not possible at the Transport Layer. You got it! I believe that applications are the first place where it makes any sense to have location independent names for any thing. No. For example, this puts the complexity of knowing that a host may have more than one interface into the applications, which is surely a trickier thing (and has to be replicated over all applications) than having it at the internetworking layer. By not being location dependent, this will require considerably larger routing tables since you will not be able to derive any "nearness" from the name to aid routing. YOU DON'T ROUTE ON EID'S! You route on addresses, which are the topologically significant names of the interface where the endpoint can currently be reached. Noel From owner-Big-Internet@munnari.oz.au Tue Oct 20 00:47:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05825; Tue, 20 Oct 1992 00:47:28 +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 AA05803; Tue, 20 Oct 1992 00:47:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14309; Mon, 19 Oct 92 10:46:28 -0400 Date: Mon, 19 Oct 92 10:46:28 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210191446.AA14309@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, kre@munnari.oz.au Subject: Re: EID compromise Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The obvious exception to this, of course, is Nimrod, where the field is used as a [forwarding] cache tag True, but remember again, this is an example of what you can use the EID for, not the *argument* for EID's. Personally, I'd consider omitting an EID from a proposal to be enough reason to reject a candidate outright. I concur completely. It's for this reason that I was absolutely unhappy with proposals to use vanilla CLNP, and look upon TUBA-with-EID's with much more favor (although I still think a new packet format is not the best Step A in solving the Internet's problems :-). Noel From owner-Big-Internet@munnari.oz.au Tue Oct 20 00:49:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05897; Tue, 20 Oct 1992 00:49: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 AA05893; Tue, 20 Oct 1992 00:49:11 +1000 (from kre) To: big-internet@munnari.oz.au Subject: Re: Day vs Chiappa re EID In-Reply-To: Your message of Tue, 20 Oct 92 00:26:35 +1000. <14245.719504795@munnari.oz.au> Date: Tue, 20 Oct 92 00:48:58 +1000 Message-Id: <14267.719506138@munnari.oz.au> From: Robert Elz Date: Tue, 20 Oct 92 00:26:35 +1000 From: Robert Elz Message-ID: <14245.719504795@munnari.oz.au> I see that something I wrote here (after quoting John Day) may be mis-interpreted, so I thought I'd clear it up in advance... This is would have to be done on each packet sent, since the routing may change during the lifetime of the connection. In theory yes, in practice, no ... My "theory" and "practice" there apply to "done on each packet" not "may change during the lifetime..." kre From owner-Big-Internet@munnari.oz.au Tue Oct 20 00:53:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06022; Tue, 20 Oct 1992 00:53:34 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210191453.6022@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06019; Tue, 20 Oct 1992 00:53:28 +1000 (from jcurran@nic.near.net) To: Noel Chiappa Cc: smart@mel.dit.csiro.au, big-internet@munnari.oz.au Subject: Re: EID compromise In-Reply-To: Your message of Mon, 19 Oct 92 01:14:59 -0400. <9210190514.AA12621@ginger.lcs.mit.edu> Date: Mon, 19 Oct 92 10:52:53 -0400 From: John Curran -------- ] From: Noel Chiappa ] Subject: Re: EID compromise ] Date: Mon, 19 Oct 92 01:14:59 -0400 ] ... ] Sure, you could fix this one, with some work, and other similar ones ] for a while, but fall across a few of these, and you start to think maybe ] EID's will make your life a lot simpler. The great thing about EID's is ] once you put them in for *one* function (and they aren't *that* expensive), ] they start to do all sorts of other things at basically no cost at all.. I agree, but have a concern about the location (read: layer) that EID's occupy in the architecture. While I think that EID's will be useful for many functions (see TUNE for specifics), these functions can be performed at either the network or transport layers. As Christian Huitema noted: > If EIDs are used end-to-end, they should be specified by an end-to-end > protocol, which may or may not decide to carry them in each and every > packet. If EID's are placed within the network layer, then their functionality will be conceptully "higher" within the network layer than the network addresses. (i.e. the majority of the time of the EID will not be used for datagram forwarding, and when used, EID's will probably be used to obtain new network layer addresses at a transition gateway) On the other hand, the use of EID's by the transport layer appears very attractive; providing independence from network addresses (hence location) for endpoint identification. Use in checksums is one result; ability for connections to survive a network-layer address change is another. Noel, can you characterize the need for having EID's at the network layer rather then transport? From Saltzer's "On the Naming and Binding of Network Destinations", I would say that EID's would be characterized as (his terminology) "names" for "nodes", and think minimizing the number of binding services per layer is good engineering. The network layer already has to handle "network-attachment-point"->"route" binding, must it also perform "node"->"network-attachment-point" binding? If we exile EID's to the transport layer, then each network layer proposal can proceed unencumbered; EID's would remain a transport encapsulation issue. /John From owner-Big-Internet@munnari.oz.au Tue Oct 20 01:04:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06497; Tue, 20 Oct 1992 01:04:15 +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 AA06484; Tue, 20 Oct 1992 01:04:08 +1000 (from kasten@ftp.com) Received: by ftp.com id AA21504; Mon, 19 Oct 92 11:01:38 -0400 Date: Mon, 19 Oct 92 11:01:38 -0400 Message-Id: <9210191501.AA21504@ftp.com> To: oran@sneezy.lkg.dec.com Subject: Re: EID compromise From: kasten@ftp.com (Frank Kastenholz) Cc: smart@mel.dit.csiro.au, big-internet@munnari.oz.au > Bottom line: if you have ambitions to use EIDs for security purposes > I hereby reverse by position in favor. ditto. security is best provided by a security protocol. this hypothetical security protocol would, no doubt, need to include EIDS, or whatevers, as a part of the information it secures. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Tue Oct 20 01:07:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06690; Tue, 20 Oct 1992 01:07:37 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210191507.6690@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06653; Tue, 20 Oct 1992 01:07:21 +1000 (from jcurran@nic.near.net) To: David Oran Cc: Bob Smart , big-internet@munnari.oz.au Subject: Re: EID compromise In-Reply-To: Your message of Mon, 19 Oct 92 09:56:17 -0400. <921019095617.15554@sneezy.lkg.dec.com> Date: Mon, 19 Oct 92 11:06:41 -0400 From: John Curran -------- From: David Oran Subject: Re: EID compromise Date: Mon, 19 Oct 92 09:56:17 -0400 ... Bottom line: if you have ambitions to use EIDs for security purposes I hereby reverse by position in favor. Using EID's for authentication is actually worse than using IP addresses, since an IP imposter must at least establish routing back to his actual address. Until we believe we have a secure (and fast) directory service, EID's can't be trusted. /John From owner-Big-Internet@munnari.oz.au Tue Oct 20 01:08:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06793; Tue, 20 Oct 1992 01:08:56 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210191508.6793@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06790; Tue, 20 Oct 1992 01:08:47 +1000 (from day@BBN.COM) From: "John Day" Subject: Re: Day vs Chiappa re EID To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au, Day@munnari.oz.au In-Reply-To: <9210191435.AA14193@ginger.lcs.mit.edu> Date: Mon, 19 Oct 92 11:07:32 EDT Mail-System-Version: Noel, > > The IP name space is route dependent in that it names the network > attachment point. > > It is with great difficultly that I refrain from a rude, arrogant >MIT-type remark in response to this! :-) I conclude that there must be some >terminology conflict to produce a remark which seems to me so utterly >confused. > A "route", to me, is a path through the network substrate of routers >and networks from a source address (attachment point) to a destination. I >believe we share the definition of network attachment point. What can the >problem be? I believe you must be making some unstated assumptions about >the routing... let me make a guess as to what they are. As far as I am concerned, an address is route specific if in choosing it I have limited the choices I may make before the packet is actually delivered to its ultimate destination. In this sense, IP addresses are route specific. I must deliver to the point of attachment identified by the IP address even if there are other IP addresses that would get me to the same TCP. Interfaces can fail without the host failing. The whole intent of connectionless was to be able to route around these sorts of things dynamically. Unfortunately, it currently works everywhere except the last (and some might say) most important step. > There is thus, in practise, *NO* set connection between an IP address >and the route through the network, from any source IP address, taken to reach >that address! Unfortunately, this is not correct. The IP address specifies the point of attachment and therefore a small piece of the route. The whole reason for network addresses is to achieve the complete independence of routes which IP addresses do not support. > > >YOU DON'T ROUTE ON EID'S! You route on addresses, which are the topologically >significant names of the interface where the endpoint can currently be reached. But you are routing on EIDs, Noel. You are forcing the source to pick the point of attachment to which the packet must be delivered rather than leaving it to the routing protocols to figure out which one is going to be the best one to deliver it to when it gets there. Have I made this clear yet, or am I still missing something. Take care John > Noel From owner-Big-Internet@munnari.oz.au Tue Oct 20 01:14:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06881; Tue, 20 Oct 1992 01:14:19 +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 AA06875; Tue, 20 Oct 1992 01:14:04 +1000 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.57/Ultrix3.0-C) id AA10788; Mon, 19 Oct 92 11:09:58 -0400 Message-Id: <9210191509.AA10788@boa.gsfc.nasa.gov> Subject: Re: EID compromise To: big-internet@munnari.oz.au Date: Mon, 19 Oct 92 11:09:57 EDT From: Dick desJardins X-Mailer: ELM [version 2.3 PL11] Robert Elz wrote: The point of the EID is to identify a transport endpoint in a location independant manner, and in a form that's reasonable to use. ---- If by "transport endpoint" you mean a TCP socket, I don't agree. Seems to me we've all been talking about the EID naming the entity that will consume the internet packet, i.e., the TCP entity, not the particular socket. Or to be more specific, if you would rewrite the above sentence in Internet-ese as "The point of the EID is to identify an Internet endpoint (i.e., logical entity at an Internet address) in a location independent manner, and in a form that's efficient to use in protocol," then I would agree. Given the EID+NPROTO, you identify the consumer of the packet and form of the packet (NPROTO acts like an N-selector, but its significance is only local to the entity identified by the EID). Or I missed something. Dick From owner-Big-Internet@munnari.oz.au Tue Oct 20 01:39:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07679; Tue, 20 Oct 1992 01:39:36 +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 AA07665; Tue, 20 Oct 1992 01:39:13 +1000 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.57/Ultrix3.0-C) id AA10908; Mon, 19 Oct 92 11:38:43 -0400 Message-Id: <9210191538.AA10908@boa.gsfc.nasa.gov> Subject: Correction noted! To: day@bbn.com, jnc@ginger.lcs.mit.edu Date: Mon, 19 Oct 92 11:38:42 EDT From: Dick desJardins Cc: desjardi@boa.gsfc.nasa.gov (Dick desJardins), big-internet@munnari.oz.au X-Mailer: ELM [version 2.3 PL11] John, you are right of course about the correction to my terminology: ---- > DesJardins writes: >> >>the EID is architecturally the logical producer and >>consumer of packets within a box on the internet. > >Well, no. As you indicate below the EID names a transport entity which >is the producer and consumer of packets. This is a nit. But I have >found that in things related to naming care in being precise is critical >or things get very confused. > >> >>In TCP/IP, this is whatever is "at" the IP address. >>As Frank Kastenholz has pointed out to me, this is >>not necessarily a TCP or UDP entity, but may be an >>ICMP, IGMP, GGP, OSPF, IGRP, IP, or ETHERNET "entity". >> >Are you implying that EIDs should be involved in the resolution of the >destination of ICMP, IGMP, GGP, etc.? If so, then things get a lot more >confused. ---- Actually, John, you are right about this still being a little confused, and my writing was a little imprecise. As I understand it, the combination EID+NPROTO (or EID+Nsel) identifies the entity instance that the packet is destination-addressed "to". But the point is (as I understand) that all packets with the same EID have the following "fate" (in Noel's terminology): 1. The arrival host either recognizes the EID as "its own" and accepts the packet, or as not its own and discards the packet. 2. The NPROTO or Nsel field further identifies the entity within that host (end-system) which will handle the contents of the packet. This is the sense in which I understand Noel's use of the term "endpoint". Noel, would you enlighten John and me if I have misunderstood you? Dick From owner-Big-Internet@munnari.oz.au Tue Oct 20 01:53:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08166; Tue, 20 Oct 1992 01:53:53 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210191553.8166@munnari.oz.au> Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08140; Tue, 20 Oct 1992 01:53:21 +1000 (from kre) Date: Tue, 20 Oct 1992 01:53:21 +1000 From: Robert Elz To: big-internet@munnari.oz.au, desjardi@boa.gsfc.nasa.gov Subject: Re: EID compromise Date: Mon, 19 Oct 92 11:09:57 EDT From: Dick desJardins If by "transport endpoint" you mean a TCP socket, No, I didn't mean that, I think I mean the same as you do. That is, the identity of the transport provider, not the client of the transport layer. kre From owner-big-internet@munnari.oz.au Tue Oct 20 05:43:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12042; Tue, 20 Oct 1992 05:44:10 +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 AA07791; Tue, 20 Oct 1992 01:41:46 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14899; Mon, 19 Oct 92 11:41:33 -0400 Date: Mon, 19 Oct 92 11:41:33 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210191541.AA14899@ginger.lcs.mit.edu> To: Day@bbn.com, jnc@ginger.lcs.mit.edu Subject: Re: Day vs Chiappa re EID Cc: big-internet@munnari.oz.au Ah, now I understand what you meant. Thanks, things are much clearer now, even if I don't completely agree! an address is route specific if in choosing it I have limited the choices I may make before the packet is actually delivered to its ultimate destination ... I must deliver to the point of attachment identified by the IP address even if there are other IP addresses that would get me to the same TCP ... [connectionless] currently works everywhere except the last .. step Yes, in this limited sense. I would say that this is an *unavoidable* artifact of the fact that *practical* large scale routing wants to track abstractable topologically oriented things, i.e. not EID's directly. One way to solve the problem you refer to is track EID's (but we ruled that out); another is to make endpoint names that have topological significance (but a lot of us claim that has bad effects); another is to build a specific mechanism (using EID's and addresses which are topologically significant names of interfaces) to handle this. I can imagine several such off the top of my head... I prefer the latter course (specific mechanisms) over introducing what I see as painful and contorted distortions in the natural definitions of fundamental objects, just to handle one special case. The whole reason for network addresses is to achieve the complete independence of routes which IP addresses do not support. Yes, but there are other ways to fix the particular problem. The issue as I see it is that you *can* fix the problem by changing the definition of fundamental objects in an unnatural way, but the fact that the fundamental objects are no longer the most natural ones is going to impose costs throughout the system (e.g. in routing overhead to track things which aren't broken) which are larger than the cost to simply fix the problem explicitly with some mechanism designed to do that. (I claim this is a general system design principle, btw.) You are forcing the source to pick the point of attachment to which the packet must be delivered rather than leaving it to the routing protocols to figure out which one is going to be the best one to deliver it to when it gets there. You are making several unwarranted assumtions here. First, you are assuming the distant routers will *always* have a better idea which interface is "best" (which is really a concept that exists only in the minds of the source, and to some degree the destination). Second, if the interfaces are sufficiently far apart in the topology, the choice will haev to made a long way away from the destination. To be frank, multi-homing, and particularly how to handle broken interfaces, is not a subject I have given a lot of thought to. Even after giving it some thought, though, I remain convinced that an explicit mechanism in terms of the fundamental objects already given (EID's and interface addresses) is the way to go. Have I made this clear yet, or am I still missing something. Yes, I understand your point 100%, but now, of course, I still don't agree! Noel From owner-big-internet@munnari.oz.au Tue Oct 20 05:20:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11538; Tue, 20 Oct 1992 05:21: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 AA08529; Tue, 20 Oct 1992 02:08:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15363; Mon, 19 Oct 92 12:08:15 -0400 Date: Mon, 19 Oct 92 12:08:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210191608.AA15363@ginger.lcs.mit.edu> To: day@bbn.com, desjardi@boa.gsfc.nasa.gov, jnc@ginger.lcs.mit.edu Subject: Re: Correction noted! Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Arrgh. Mailbox meltdown... all packets with the same EID have the following "fate" (in Noel's terminology) Well, I had a more limited term, "fate-sharing", which meant that the application and the reliable transport mechanisms/state are co-located, with the result that "they all go together when they go". I.e., you can't have the application still OK with the connection in a failed (or atomized; this was a US DoD protocol a long time ago :-) machine, and vice-versa. This is a *key* concept of TCP, but it doesn't seem to be widely written up. (It's not in Radia's book, or Doug Comer's, e.g.) I stole it from an old slide set of Dave Clark's. Noel, would you enlighten John and me if I have misunderstood you? Well, I don't fully understand this NPROTO or NSel suff, but your rules for how to handle an incoming packet seem reasonable. Noel From owner-big-internet@munnari.oz.au Tue Oct 20 05:18:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11475; Tue, 20 Oct 1992 05:19:15 +1000 (from owner-big-internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07378; Tue, 20 Oct 1992 01:29:18 +1000 (from dave@sword.bellcore.com) Return-Path: Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA14909; Mon, 19 Oct 92 11:31:53 EDT Received: by sword.bellcore.com;id 9210191526.AA04934 Message-Id: <9210191526.AA04934@sword.bellcore.com> Date: Mon, 19 Oct 92 11:26:39 EDT From: dave@sword.bellcore.com (Dave Piscitello) To: jnc@ginger.lcs.mit.edu, mandrews@alias.com Subject: Re: Addresses Cc: big-internet@munnari.oz.au >So? It has one interface, which has many addresses. What's the problem? Since when can one interface have multiple addresses? Doesn't every interface have a have a unique address (for every (sub)network it belongs to) which Mark, in SMDS, you can assign multiple addresses to a single interface (actually, up to 16); now this was originally thought to accommodate multipel routers attached to a single interface to the network, but several folks suggested that since SMDS is a public "fabric", it might be useful to allow a single piece of equipment use one address on the interface for public connectivity, and one for private connectivity. From owner-big-internet@munnari.oz.au Tue Oct 20 06:02:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12353; Tue, 20 Oct 1992 06:03: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 AA08236; Tue, 20 Oct 1992 01:56:33 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15036; Mon, 19 Oct 92 11:56:07 -0400 Date: Mon, 19 Oct 92 11:56:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210191556.AA15036@ginger.lcs.mit.edu> To: jcurran@nic.near.net, jnc@ginger.lcs.mit.edu Subject: Re: EID compromise Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, smart@mel.dit.csiro.au If EID's are placed within the network layer, then their functionality will be conceptully "higher" within the network layer than the network addresses Yes, exactly. This was the point of some of my previous comments about how the internetwork layer could really be viewed as two sublayers, the first being interface-interface, and the second endpoint-endpoint. I make them a single layer since I am not a strict layerist, and don't see any benefit to separating them. Noel, can you characterize the need for having EID's at the network layer rather then transport? First, so that multiple transport layers can share a single mechanism, rather than duplicating it over and over again. (This is a problem the TCP/IP stack has a lot, something we discovered in doing the HRRFC's. E.g. lack of a reliable query-reponsse layer means every TCP based server has to do timeouts all over again by hand..) Second, and more important, there are a number of internetworking layer issues, *for example* handling mobile hosts, multi-homed hosts, etc, which can be more easily tackled if the idenfication of the endpoint is available at the internetworking layer. From Saltzer's "On the Naming and Binding of Network Destinations" My God, you read this! You get a gold star! that EID's would be characterized as (his terminology) "names" for "nodes" Right, except (under Dave Oran's influence :-) I've substituted 'endpoint' for 'node' (which I took to be more closely tied to a physical machine). think minimizing the number of binding services per layer is good engineering You bet. No disagreement here! ("Perfections has been attained... when there is nothing left to take away.") The network layer already has to handle "network-attachment-point" ->"route" binding, must it also perform "node"->"network-attachment-point" binding? The first is currently true, but it is only sort of half-true in things like Nimrod. As for the second, I imagine you would not do this mapping often; what you would *usually* do would be a mapping from "DNS name" -> the tuple ("node", "network-attachment-point"). There may be cases where an EID wouldn't have a DNS name, but I just don't see many instances in which you'd be given a bare EID *without* the address and told to contact it... Noel From owner-big-internet@munnari.oz.au Tue Oct 20 08:37:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14545; Tue, 20 Oct 1992 08:38:16 +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 AA09711; Tue, 20 Oct 1992 02:54:43 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16875; Mon, 19 Oct 92 12:54:10 -0400 Date: Mon, 19 Oct 92 12:54:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210191654.AA16875@ginger.lcs.mit.edu> To: oran@sneezy.lkg.dec.com, smart@mel.dit.csiro.au Subject: Re: EID compromise Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu If the intention is to use EIDs in any way as a method to decide whether you believe the sender/receiver of a packet is who you think it is, I get off the boat immediately. I think everyone realizes that EID's in and of themselves cannot do this, but only in concert with other security mechanisms such as an authentication system, etc. They may be *helpful* in so doing, of course, but that's a different thing! if you have ambitions to use EIDs for security purposes I hereby reverse by position in favor. I assume you aren't against a use such as I mentioned? Noel From owner-big-internet@munnari.oz.au Tue Oct 20 08:40:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14665; Tue, 20 Oct 1992 08:41:14 +1000 (from owner-big-internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10012; Tue, 20 Oct 1992 03:24:53 +1000 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA13081; Mon, 19 Oct 92 10:21:37 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA24333; Mon, 19 Oct 1992 13:21:19 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: EID compromise In-Reply-To: <9210191654.AA16875@ginger.lcs.mit.edu> References: <9210191654.AA16875@ginger.lcs.mit.edu> X-Mailer: Poste 2.0 From: David Oran Date: Mon, 19 Oct 92 13:21:10 -0400 Message-Id: <921019132110.15554@sneezy.lkg.dec.com> Encoding: 35 TEXT, 6 TEXT SIGNATURE > I think everyone realizes that EID's in and of themselves cannot do this, > but only in concert with other security mechanisms such as an authentication > system, etc. They may be *helpful* in so doing, of course, but that's a > different thing! > > if you have ambitions to use EIDs for security purposes > I hereby reverse by position in favor. > > I assume you aren't against a use such as I mentioned? > Actually, I *am* against it. An important design issue in both network protocol AND security is what names are bound to and what you can infer from the assertion of a particular name. Therefore, in order to argue for the use of EIDs in a security-related operation, such as privacy or authentication, you have to show that it is desirable (and meaningful from a protection standpoint) for a secret to be associated with an EID. (By "associated" it means that by compromising the secret you have less trust in an EID than you would if you believed the secret still in force.) You also have to show that by being able to trust an EID you gain something from a security standpoint that you would not gain by placing your trust elsewhere. I challenge you to show this. I'd love to have a long and fascinating discussion of secrets, names, secure channels, binding of secrets to secure channels, what identifies a secure channel, what granularity of communication should be protected by a single secret, how that granularity is related to names as seen by the network mechanisms (especiallyEIDs, how it also relates to the elements the user puts his trust in, etc. I'm also happy to have this discussion on big internet too, but perhaps it would be tangential to the thrust of the discussion. :-) Perhaps it would be better to just note that one person (at least) questions the utility of EIDs for security purposes, and in fact believes that using them in such a manner might actually be inadvisable. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-big-internet@munnari.oz.au Tue Oct 20 08:36:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14512; Tue, 20 Oct 1992 08:36:42 +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 AA09651; Tue, 20 Oct 1992 02:46:01 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16754; Mon, 19 Oct 92 12:45:10 -0400 Date: Mon, 19 Oct 92 12:45:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210191645.AA16754@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, smart@mel.dit.csiro.au Subject: Re: EID compromise Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Why would a domain name have 2 EIDs? Urr, for example (probably not a good one, anyone got a better one?) if it's the name of a service, you might have two different places to get it. How/when would you decide to use one and not the other? I cheerfully admit to not having given this any detailed thought! Doesn't feel like an insoluble problem, though; one that can be put off. Why would one EID be the EID of 2 domain names? I'm not talking aliasing Hmm, that would have been my example. a situation where an entry under in-eid.arpa has 2 PTR records. I've forgotten enough DNS bits that I didn't grok this; are you talking about a situation where two of the kind of objects that can have HINFO attributes map to the same EID? If so, once again, no idea at the moment, but I'll bet a Lotus someone figures out a use for it. Noel From owner-big-internet@munnari.oz.au Tue Oct 20 09:10:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15173; Tue, 20 Oct 1992 09:10:13 +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 AA11159; Tue, 20 Oct 1992 05:00:26 +1000 (from kre) To: Big-Internet@munnari.OZ.AU Subject: Mobility without EIDs Date: Tue, 20 Oct 92 05:00:05 +1000 Message-Id: <14390.719521205@munnari.oz.au> From: Robert Elz It has been said here in the past, that there are various schemes around to handle mobility with IP, and that these could carry over to IPv7 (in style if not in detail perhaps) and as such, EIDs are not needed to support mobility, it can be done other ways. I'm not sure if I said this in an earlier message, or if I trashed that before sending it - but it might be a good idea to post pointers to the various mobility proposals here, so that those of us (we, for me at least) who haven't been following the mobile host work very closely (or at all) can find the right materials to read. In the meantime, could the advocates of the various proposals, if they're here, explain briefly how their proposal handles the following situation (which is one I think is realistic). First, imagine I have an open TCP connection to a host in the US (say a Telnet connection to berkeley or something). The host at Berkeley has no idea whatever that my host is "mobile" in any sense. My host here (in Aust) may know that is notionally a "mobile" host, but it would be nicer if we could avoid that assumption. Now assume that I pick up my host, and fly it to Berkeley, just how is the Berkeley host I have my open Telnet connection with supposed to get packets to my (portable) workstation? If the answer is "send the packets to Australia, where a server picks off the packet, and knows where to forward it to back in Berkeley" then explain how this works should Australia have laws by which it is not permitted for the country to act as a transit network for packets from another country to itself? (No such laws exist here that I know of, but they could). Or, if you like, replace Berkeley above by Toronto (everywhere) and use the (I believe once, if not still current) Canadian law that prohibits packets from one place inside Canada to another being forwarded via some other country. How is all this stuff supposed to work - regardless of whether you're using encapsulation or source routing? Remember that the host communicating with my mobile host has no idea that my host is mobile, and so will just be sending a "normal" packet, and that the TCP connection has to stay alive, which means that the source/dest addr/port quadruple must remain. If the various docs explain all this, please do point me at them. kre From owner-big-internet@munnari.oz.au Tue Oct 20 11:08:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17868; Tue, 20 Oct 1992 11:18:30 +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 AA12038; Tue, 20 Oct 1992 05:43:27 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA02223 (5.65/6.02); Mon, 19 Oct 92 15:41:28 -0400 Date: Mon, 19 Oct 92 15:41:28 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9210191941.AA02223@sadye.emba.uvm.edu> To: "John Day" Cc: big-internet@munnari.oz.au, day@munnari.oz.au, desjardi@boa.gsfc.nasa.gov Subject: Re: Day vs Chiappa re EID In-Reply-To: <9210191341.2374@munnari.oz.au> References: <9210161551.AA29128@boa.gsfc.nasa.gov> <9210191341.2374@munnari.oz.au> < said: > Mail-System-Version: > The property of the EID not relating to a specific interface is the > property that is desired. However, the property that it is location > independent creates probably my biggest objection. By not being > location dependent, this will require considerably larger routing > tables since you will not be able to derive any "nearness" from the > name to aid routing. No, no, no, no, NO! EID's have no relation whatsoever to any routing entity, whether it be the current ``route tables'' or something really strange that Noel has dreamed up. That is indeed the entire point of having them! > (Analogous to a postman seeing a letter for Nimes France. He > doesn't have to know where in France Nimes is just that the letter > would be better going east than west.) The US postman looking at a letter going to Nimes is looking at the address. The EID doesn't come in until the letter arrives in the mailroom at its destination address and some poor clear must figure out who it goes to. (And note that even at this level in this rather strained analogy, the letter might have an *address* (``Section B-32'') rather than an identifier (``Constance Cyr'').) > The other way is to in essence have the Transport Layer get involved > in routing by picking the mapping to destination network address, > i.e. the interface to deliver the packet to, before it sends it. No. The transport layer hands down a packet intended for a specific EID. The network layer must, among other things, look in some internal data collection or external service to find what the address of that particular EID is! The model that I have been thinking of is this: You want to send a packet to my machine, tsornin.emba.uvm.edu. You look up in the DNS to find out that his EID is 2.1376.4.5. You can then form a transport-layer packet addressed to that entity. Your network layer then consults some data source which can look up the address of that EID. (In my system, you would do an inverse mapping of 5.4.1376.2.in-eid.arpa. and that would either give you a hierarchical address, or tell you the address of a machine that could, using a yet-to-be-defined protocol. My current idea for an implementation of this is actually to have a callout from the kernel to an external route server process, which would allow system administrators to more easily adjust routing policy to meet their constraints.) -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-big-internet@munnari.oz.au Tue Oct 20 11:08:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17759; Tue, 20 Oct 1992 11:08:26 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210200108.17759@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12157; Tue, 20 Oct 1992 05:53:49 +1000 (from day@BBN.COM) From: "John Day" Subject: Re: Day vs Chiappa re EID To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au, Day@munnari.oz.au In-Reply-To: <9210191541.AA14899@ginger.lcs.mit.edu> Date: Mon, 19 Oct 92 15:36:12 EDT Mail-System-Version: Noel, > >I prefer the latter course (specific mechanisms) over introducing what I see >as painful and contorted distortions in the natural definitions of fundamental >objects, just to handle one special case. > > The whole reason for network addresses is to achieve the complete > independence of routes which IP addresses do not support. > >Yes, but there are other ways to fix the particular problem. The issue as I >see it is that you *can* fix the problem by changing the definition of >fundamental objects in an unnatural way, but the fact that the fundamental >objects are no longer the most natural ones is going to impose costs >throughout the system (e.g. in routing overhead to track things which aren't >broken) which are larger than the cost to simply fix the problem explicitly >with some mechanism designed to do that. (I claim this is a general system >design principle, btw.) > Now here is where we really differ. I do not see it as an unnatural act to define a network address as purely location dependent. In fact, I find it to be much nearer to what was actually intended. I don't believe that route specific is an inherent part of the concept of an address. For people who live on a grid, there are always multiple routes to the same place, but their address is the same. When we talk about location dependent and topology specific, but route independent, the topology is not necessarily the network topology, but more in the general math sense. The topology by which the addresses are assigned could be based on the network topology, geography, routing domains, or any other topology you can come up with or some combination of the them. This route independent definition is much more natural than the "phone company" centric view of naming things realtive to how it connects to me. The original host address, the current IP address and phone numbers were defined to be both location dependent and route specific (in my sense). Once one realizes that it creates trouble. It seems much more natural to move back one degree of dependence rather than removing all degrees of independence and thereby loosing some the efficiencies that one had. In fact, there seems to be a rather nice progression here from application names which are location independent (and fairly permenant) to network addresses which are location dependent (an applications binding to an address may change but slowly or infrequently) to SNPAs which are route specific (in my sense and may change much more often). > >You are making several unwarranted assumtions here. First, you are assuming >the distant routers will *always* have a better idea which interface is >"best" (which is really a concept that exists only in the minds of the source, >and to some degree the destination). Second, if the interfaces are sufficiently >far apart in the topology, the choice will haev to made a long way away from >the destination. Yes, but the intervening routers still should have a better idea of which direction is a better choice regardless of how far along the trip to the destination the choice has to be made. I disagree that "best" only exists in the minds of the source. The source may have some preferences about policy in routing, but I would hope the routers in route have a better idea of the most probable routing choices that are liable to get the packet delivered to the other end. Optimizing "best" tain't worth nuthin if the packet don't get delivered, and optimizing best is about all the source can contribute to. Actually, I believe that rather than making the problem more complicated. This actually simplifies the problem. By only giving up one degree of dependence we can still treat the existing case (a system with only one attachment) as a degenerate case, not a special case. I prefer solutions where the cases drop out as degenerate not special. By keeping addresses location dependent but route specific. We solve the multi-homing and mobility problems without giving up the embedded aid to routing. EIDs solve the problem by making routers do more work. Take care, John From owner-big-internet@munnari.oz.au Tue Oct 20 11:00:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17684; Tue, 20 Oct 1992 11:05: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 AA10785; Tue, 20 Oct 1992 04:33:26 +1000 (from kre) To: "John Day" Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au Subject: Re: Day vs Chiappa re EID In-Reply-To: Your message of Mon, 19 Oct 92 11:07:32 -0400. Date: Tue, 20 Oct 92 04:33:11 +1000 Message-Id: <14374.719519591@munnari.oz.au> From: Robert Elz Date: Mon, 19 Oct 92 11:07:32 EDT From: "John Day" Unfortunately, this is not correct. The IP address specifies the point of attachment and therefore a small piece of the route. The whole reason for network addresses is to achieve the complete independence of routes which IP addresses do not support. This is not something I agree with - or rather contains two somethings, with neither of which I agree. First, IP addresses of themselves don't really imply that which you say, if I have a host with two IP addresses (eg: munnari.oz.au - 128.250.1.21 and 192.43.207.1) I can, if I want to, have it advertise its 192.43.207.1 address on its 128.250.1.21 interface, allowing routers to send packets to it ising its class C address via the interface on the class B net. That this isn't often done is more related to the way we coalesce routing information than the properties of IP addresses themselves. Next, I dispute that the reason we want network addresses is to (somehow) achieve independance of routes, we don't want them to tie down a route, but nor do we want them to be independant of routing. Quite the contrary, we want network topology bound into the addresses - if of those two addresses for munnari, one was in a net logically in the US (using a geographic example just because its easier to visualise) and the other is in Australia, then knowledge of the US address would be (more) visible there, and the Aust one here - sending to munnari's US address from Aust might (and should) involve sending the data into the US, so it could find that address (which does not necessarily mean that munnari has 2 interfaces, or that the addresses are bound to interfaces). But you are routing on EIDs, Noel. You are forcing the source to pick the point of attachment to which the packet must be delivered rather than leaving it to the routing protocols to figure out which one is going to be the best one to deliver it to when it gets there. I don't see how this has anything whatever to do with EID's. My model of how EIDs would work (not necessarily the only model, but a reasonable one I think), is that a host starts with the DNS name (OK, it may have to go hunt in a directory to find this, so it may not really "start" there, but this is close enough). From the DNS name, it looks up the DNS, and obtains both the EID for the remote host, and its (one or more) address(es). Using whatever technique it chooses it picke one of the addresses, inserts that, and the EID, into the packet, plus its own EID and (one of) its address(es), and sends the packet. I fail to see how you can possibly conclude that the host has "routed on the EID" - all its done with the EID has been to treat it as a piece of random binary trash that its obliged to poke into the packet. Whether the address it also put in the packet contains any "routing information" in your sense, or not, and if so, how the host chose one address in particular from several is immaterial, in no sense has it done anything with the EID to derive that information. kre From owner-big-internet@munnari.oz.au Tue Oct 20 22:55:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05137; Tue, 20 Oct 1992 22:55:08 +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 AA19347; Tue, 20 Oct 1992 12:24:43 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA08869 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 20 Oct 1992 12:24:28 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA27094; Tue, 20 Oct 92 12:24:10 EST Message-Id: <9210200224.AA27094@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Security and EIDs Date: Tue, 20 Oct 92 12:24:09 +1000 From: Bob Smart You folks can't have it both ways on security. On the one hand we have people saying that separating EIDs from addresses makes it easier for impersonation attacks (a point Robert Elz made earlier in the year). On the other hand people are saying that no security mechanisms should be based on trusting the addresses and/or EIDs in packets. Well if we don't use the address/EID information in the packet for trust, the ability to do impersonation is irrelevant. The fact of the matter is that a LOT of the operation of TCP/IP networks depends on trusting the address information in the packets. Suppose our network is 192.9.200. Suppose I get a packet from 192.9.200.123. I know my router won't allow a packet with a source address of 192.9.200.x in from outside. I have physical security on my network. I trust the security and management of the hosts on my network. So I know that the packet did come from 192.9.200.123. Like it or not that delicate chain of logic is used in the day-to-day operation of most LANs on the Internet. Given the IETF requirement that we support existing modes of operation, I believe we must support this mode of operation for things like NFS, BOOTP, LPD and many other protocols. We must do this in a way that is not *less* secure than the existing mechanisms. I believe I have been careful to keep that in mind in my proposals. People who think we should introduce IPv7 in the context of a complete security architecture are in fantasy land. If you want to consider the technical difficulties you could start with the recent Internet draft draft-ietf-osids-plan-directory-00.txt (look at the security options for directory use alone), then get the osisec documentation from cs.ucl.ac.uk:/osisec. The operational difficulties are even harder. The politicial difficulties are currently impossible: we can't deploy this stuff if we can't distribute the software. I would love to hear if the people planning for a secure Internet have requirements or preferences for IPv7. I think this request has been made before with no response. I personally think that security is an end-to-end matter, and things will work out better if we split the routing part of the network layer from the end-to-end part and keep the latter flexible. I hope I'm in tune with John Curran. Bob Smart From owner-Big-Internet@munnari.oz.au Tue Oct 20 23:56:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07283; Tue, 20 Oct 1992 23:56: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 AA07275; Tue, 20 Oct 1992 23:56:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA21546; Tue, 20 Oct 92 09:55:49 -0400 Date: Tue, 20 Oct 92 09:55:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210201355.AA21546@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, oran@sneezy.lkg.dec.com Subject: Re: EID compromise Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Actually, I *am* against it. An important design issue in both network protocol AND security is what names are bound to and what you can infer from the assertion of a particular name. Therefore, in order to argue for the use of EIDs in a security-related operation, such as privacy or authentication, you have to show that it is desirable (and meaningful from a protection standpoint) for a secret to be associated with an EID. (By "associated" it means that by compromising the secret you have less trust in an EID than you would if you believed the secret still in force.) You also have to show that by being able to trust an EID you gain something from a security standpoint that you would not gain by placing your trust elsewhere. I must confess I didn't follow this completely, but I think I get the drift (although I could be wrong). Is what you are saying that the EID in itself is useless for security, and that any binding between a secret and an EID simply represents another point of attack? I.e., the best "EID" for a secure connection would be the public key of a public-private key pair, and forget associating any security with the EID, since it itself is so insecure? I challenge you to show this. I'd love to have a long and fascinating discussion of secrets, names, secure channels, binding of secrets to secure channels, what identifies a secure channel, what granularity of communication should be protected by a single secret, how that granularity is related to names as seen by the network mechanisms (especiallyEIDs, how it also relates to the elements the user puts his trust in, etc. I'm also happy to have this discussion on big internet too, but perhaps it would be tangential to the thrust of the discussion. :-) Well, I must confess, security is not my specialty. I've just heard real seecurity wizards (e.g. Steve Kent) say a globally unique ID makes their job a lot easier, and I was taking him on faith. You're right, it's a long discussion, and perhaps we should leave it for the moment, but I would like to find out if a global ID makes their job easier. Perhaps it would be better to just note that one person (at least) questions the utility of EIDs for security purposes, and in fact believes that using them in such a manner might actually be inadvisable. Hmm, OK, but I'd like to hear you and Steve K go around on this one! Noel From owner-Big-Internet@munnari.oz.au Wed Oct 21 00:11:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08517; Wed, 21 Oct 1992 00:11:55 +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 AA08509; Wed, 21 Oct 1992 00:11:39 +1000 (from kasten@ftp.com) Received: by ftp.com id AA19953; Tue, 20 Oct 92 10:11:12 -0400 Date: Tue, 20 Oct 92 10:11:12 -0400 Message-Id: <9210201411.AA19953@ftp.com> To: smart@mel.dit.csiro.au Subject: Re: Security and EIDs From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: big-internet@munnari.oz.au Bob You should be able to trust EIDs and IPv7-Addresses about as much as you can trust IPv4 Addresses. That is to say, from a strict security point of view, they are easily spoofed so you can not trust them, but on our nets, this spoofing occurs very rarely so we end up trusting them and it is hardly ever a problem. (How's that for a "both ways" sort of answer :-) Since the Source EID uniquely and unambiguously identifies the source of packets, the Source EID is the quantity that you want to trust when building a secure IPv7. If your IPv7 router can filter "incoming" IPv7 packets and drop the ones that have Source EIDs that are known to already be on your network then you will be able to trust EIDs just as you do IP addresses today. However, this is not as simple as building a list of EIDs and filtering accordingly... One of the properties of EIDs is that they can identify things that roam through the network. Something of yours could validly roam out of your network and, if you have the simple EID filter that I've described, that something would not be able to communicate with anything inside of your network (the source EID of these packets is something that your IPv7 router thinks is "inside" your network so it would filter those packets out). There is also the possibility that a bad guy will develop something that roams into your network... it then looks like something "local" so it is treated with the trust that you treat everything that is local. If and when a real security scheme is deployed for IPv7 (or IPv4 for that matter) a part of it, no doubt, will include some form of authentication, i.e. that the claimed sender of the packet (i.e. the "source EID" or source IP Address) really did send it and that the bits that the sender sent are the ones that you received. This authentication algorithm would necessarily have to protect the source information in the packet. Part of authentication is a secret, known to both sides of the communication (and presumably not known to the bad guys). When you receive a packet that claims to be from source S, you would look up S's secret and run the packet and the secret through your authentication algorithm to see if the packet rings true. -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Wed Oct 21 01:06:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10758; Wed, 21 Oct 1992 01:07:58 +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 AA10664; Wed, 21 Oct 1992 01:06:59 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA15462; Tue, 20 Oct 1992 16:07:35 +0100 Message-Id: <199210201507.AA15462@mitsou.inria.fr> To: Bob Smart Cc: big-internet@munnari.oz.au Subject: Re: Security and EIDs In-Reply-To: Your message of "Tue, 20 Oct 92 12:24:09 +1000." <9210200224.AA27094@wanda.mel.dit.CSIRO.AU> Date: Tue, 20 Oct 92 16:07:34 -0500 From: Christian Huitema X-Mts: smtp >The fact of the matter is that a LOT of the operation of TCP/IP networks >depends on trusting the address information in the packets. Suppose >our network is 192.9.200. Suppose I get a packet from 192.9.200.123. >I know my router won't allow a packet with a source address of 192.9.200.x >in from outside. I have physical security on my network. I trust the >security and management of the hosts on my network. So I know that the >packet did come from 192.9.200.123. Like it or not that delicate chain >of logic is used in the day-to-day operation of most LANs on the >Internet. In fact, you have an even stronger protection due to the "bilateral" part of the protocol: you use as destination of your responses the source address of the queries. It is very easy for an imposter to send out a packet with a forged source address; but it requires a full scale attack on the routing tables to receive the replies sent to another destination. OK, that full scale attack is not impossible to do. One could for example tamper with an access line, analyse some packets and forwards others, so that the attack remains concealed. But it requires more resources and determination than merely playing games with a PC. Now, if the EIDs are NOT used for routing... then forging them becomes as easy as playing games with a PC. Security is a very important feature, and the chase to the fourth elephant should already have started. But designing an EID scheme "because it could perhaps help security" is just silly. We should first ask a couple of basic questions, e.g. what kind of security do we want to achieve, what technologies are we ready to use, what are the requirements. To just quote a couple of ideas: * The most important feature now is to architect some for of firewalling. Or is it something else? * Firewalling is exercised by some intermediate router, at some boundary. How do boundaries relate with the architecture? Do we have cascades of firewalls? * Firewalling today is exercised by listing autorized partners (source, destinations), and also authorized applications. * We are not really sure that this listing should be based on "hosts". Maybe we would really like to autorize users, but we cant, so resort to authorizing "the PC of John Smith". * What happens when said John Smith tarvels to another institution? * Real firewalling may well require a "proof of identity" in the packet, e.g. a digital signature. * Using RSA for that looks somewhat of an overkill. What about MD5, as in secure SNMP? * Should this firewalling be strictly stateless? Or could we imagine that we use a coupling between a flow-id and some key, obtained during an initial dialogue. I guess that we should really address this subject first, then obtain a clear spec, and only later discuss the format and usefullness of EIDs. Christian Huitema From owner-big-internet@munnari.oz.au Wed Oct 21 01:30:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11639; Wed, 21 Oct 1992 01:30:45 +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 AA08391; Wed, 21 Oct 1992 00:09:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22339; Tue, 20 Oct 92 10:09:12 -0400 Date: Tue, 20 Oct 92 10:09:12 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210201409.AA22339@ginger.lcs.mit.edu> To: jcurran@nic.near.net, jnc@ginger.lcs.mit.edu Subject: Re: EID compromise Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, smart@mel.dit.csiro.au One reason that you might seperate them is to allow for multiple subnetwork layers (interface-interface) such as existing IP, CLNP, Nimrod, PIP, etc... This might be useful if we ever had to change networks layers... Maybe, but you have to ask 'how likely is it', and 'what does it cost'. None of the existing protocol stacks is likely to be modified to include this layer, so we'd only be talking about an new internetwork layer other than IPv7, and I think that's a slim bet in any future I'll see. Another issue is that the functioning of the two layers is fairly tightly bound together to handle such things as mobile hosts, multi-homed hosts with failed interfaces, etc. I know I'm being inconsistent here about leaving flexibility in some cases and not others, but it's a question of either a) providing a mechanism I need *now* to do something (e.g. local abstraction control in Nimrod), and doing it in a way that leaves a lot of reserve, or b) putting in a mechanism just on the offchance we might need it some day (a whole separate endpoint-endpoint layer). None of which means to say that it's a bad idea, just that it will take some thinking about. Multiple transport layers sharing the same mechanism does not _imply_ that the functionality has to part of the network layer (or network datagrams), it only implies that they use a common layer (providing this function) to access the network services. I might as well assert that these are more easily tackled by EIDs _above_ the internetwork layer. True, it doesn't *have* to be in the internetwork layer. But you do seem to indicate it does belong below the transport layer, so either it goes in as the top part of internetwork, or we have to put a new layer in there. As I mentioned in a previous message, I didn't see that the cost/benefit of making a separate layer out of it was worth it. I think that we need to get down to more specific mechanisms (as others on this list have recommended for some time ;-) for these features before the benefits of EIDs within the network layer vs. above the network layer can be determined. Yes, we need to stop discussing the design and go build some and try them. Debate has gotten us about as far as I can, I think. Noel From owner-big-internet@munnari.oz.au Wed Oct 21 01:42:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11962; Wed, 21 Oct 1992 01:42: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 AA10252; Wed, 21 Oct 1992 00:57:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22579; Tue, 20 Oct 92 10:56:21 -0400 Date: Tue, 20 Oct 92 10:56:21 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210201456.AA22579@ginger.lcs.mit.edu> To: Day@bbn.com, jnc@ginger.lcs.mit.edu Subject: Re: Day vs Chiappa re EID Cc: Day@ginger.lcs.mit.edu, big-internet@munnari.oz.au I do not see it as an unnatural act to define a network address as purely location dependent. In fact, I find it to be much nearer to what was actually intended. Me too. Damned if I know why people keep saying things like "I want my address to stay the same when I move". For people who live on a grid, there are always multiple routes to the same place, but their address is the same This is not a great analogy; I could say that those multiple routes are equivalent to the multiple routes in the average internetwork. A much better analogy would be someone who lived on the corner and had two front doors, and thus had two addresses. If the sidewalk on one street was torn up for street work, and made that door inaccessible, that's the analogy to a multi-homed host with a dead interface. (A human coming on this situation would deal with it by noticing the house had two doors, and going around the corner to the other one, of course. We need to do the computer equivalent.) When we talk about location dependent and topology specific, but route independent, the topology is not necessarily the network topology, but more in the general math sense. The topology by which the addresses are assigned could be based on the network topology, geography, routing domains, or any other topology you can come up with or some combination of the them. True, and I've thought of such things. The problem is that these non-network topology based addressing schemes aren't much use to the routing. (We had a big debate about all the things addresses do for you on B-I at the time of the Boston IETF which touched on this.) To be of use to the routing, an addressing scheme must be abstratable; i.e. you must be able to name (non-strictly) nested areas of the physical topology with it, if the abstraction which is *critical* to the workability of a large scale routing scheme is to be doable. If you have an addressing scheme in which this *not* true, you're simply going to have to map those addresses into *another* address hierarchy which *does* have those properties, which is the one the routing is going to use. Dunno 'bout you, but I don't see a use for that extra mapping (although I can see a utility to providing each physical asset of the network a globally unique name, but that's a whole different thing). Yes, but the intervening routers still should have a better idea of which direction is a better choice regardless of how far along the trip to the destination the choice has to be made. Absolutely not. If the source has a policy constraint which cannot be expressed in the packet (and this is going to be pretty common), there's *no way* the intervening router has a *clue* which direction is better. I would hope the routers in route have a better idea of the most probable routing choices that are liable to get the packet delivered to the other end. Counter-examples to this are trivial to find. It only requires the packet to be on the way to a resource that the source knows it is allowed to use, and which the router doesn't know about. Heck, that resource may be the *only* way to get to the destination, and the intermediate router may not be allowed to know about it. I prefer solutions where the cases drop out as degenerate not special. I don't think it's this simple. (I can hear Yakov smirking in the background! See, I'm on your design style side sometimes, Yakov! :-) You have to consider what the costs of each approach are, and what the percentage will be of each. For example, if 1% of the cases are 'special', and system A costs 1 unit for normal cases, and 10 for special cases, and system B costs 2 units for degenerate cases, and 5 for full cases, A (99*1 + 1*10) is better than B (99*2 + 1*5). This is a simplistic example of course; you also have to ask 'is the mix going to stay the same', 'are we going to find better ways of doing things', 'are we going to need more capabilities in the future that B can provide better than A', etc. By keeping addresses location dependent but route specific. We solve the multi-homing and mobility problems without giving up the embedded aid to routing. I thought about this for a while yesterday after sending off my mail, and I have a clearer version of my argument. We can route to one of 3 things: interface (addresses), topologically significant endpoint names (TSEN's), or non-topologically significant EID's. The latter implies that the routing has to track EID's, and we get no scaling, so this clearly will not work. The former has the problem that if you have a multi-homed host, you need to pick which interface to send to. However, picking the middle option doesn't work either, for the general case. If a host has two widely separated interfaces, *by definition* it can't be referred to by a single TSEN, since they *include* topology information which *cannot* be the same in both cases. Yes, it can work in some *limited* cases, but this is simply a case of defining a limited domain in which you route to EID's. There was a debate a while back on Big-I which was the same debate, actually. The outcome of that was that I thought about an architecture in which you routed on an (address, EID) tuple, where the address named an area of the topology in which the EID would be "lookup up" or "tracked" by some means; perhaps routing, perhaps by something like ARP. (The current use of ARP is a degenerate case of this model..) This is a more explicit version of the approach which you expound, and which IS-IS/etc use. However, to use your own argument on you, wouldn't we be better with a system which handled all cases of dual homed hosts the same, and hosts where the two interfaces happen to be fairly close would be degenerate? Right now, in the TSEN approach, a host with two widely separated interfaces has to be handled by a special mechanism. Why not have one thing for both cases? I actually *prefer* to route to an interface, since I'm in favour of putting control in the hands of the source to the largest degree possible, and it may matter to the source which interface the packet comes in over. This ties in very neatly with interface addresses and EID's being the fundemental naming objects, and also a single mechanism to handle mobile hosts, multiple interfaces, etc, etc, no matter what the scope. EIDs solve the problem by making routers do more work. How? From owner-Big-Internet@munnari.oz.au Wed Oct 21 02:35:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13993; Wed, 21 Oct 1992 02:35:54 +1000 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13988; Wed, 21 Oct 1992 02:35:48 +1000 (from dennis@ans.net) Received: by interlock.ans.net id AA105932 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Tue, 20 Oct 1992 12:35:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-2); Tue, 20 Oct 1992 12:35:09 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Tue, 20 Oct 1992 12:35:09 -0400 Date: Tue, 20 Oct 1992 12:33:06 -0400 From: Dennis Ferguson Message-Id: <199210201633.AA102700@foo.ans.net> To: Christian.Huitema@sophia.inria.fr Subject: Re: Security and EIDs Cc: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Christian, >>The fact of the matter is that a LOT of the operation of TCP/IP networks >>depends on trusting the address information in the packets. Suppose >>our network is 192.9.200. Suppose I get a packet from 192.9.200.123. >>I know my router won't allow a packet with a source address of 192.9.200.x >>in from outside. I have physical security on my network. I trust the >>security and management of the hosts on my network. So I know that the >>packet did come from 192.9.200.123. Like it or not that delicate chain >>of logic is used in the day-to-day operation of most LANs on the >>Internet. > > In fact, you have an even stronger protection due to the "bilateral" part of > the protocol: you use as destination of your responses the source address of > the queries. It is very easy for an imposter to send out a packet with a > forged source address; but it requires a full scale attack on the routing > tables to receive the replies sent to another destination. > > OK, that full scale attack is not impossible to do. One could for example > tamper with an access line, analyse some packets and forwards others, so > that the attack remains concealed. But it requires more resources and > determination than merely playing games with a PC. Now, if the EIDs are NOT > used for routing... then forging them becomes as easy as playing games > with a PC. If you can find a host which inverts source routes properly (this is a MUST in rfc1122) there is no need to attack routing at all to have responses to packets with any random source address returned to your doorstep. Simply adding an appropriate LSSR will do it. There is even an outstanding proposal for host mobility which depends somewhat on hosts with the ability to invert source routes, in conformance with rfc1122, being common. There is nothing about EIDs which creates a bigger security hazard than exists with the current network. There is nothing about EIDs which lessens the hazards (that I can see). If you want to associate EIDs with a particular route, and only believe packets which arrived by that route, you are free to do so just as you are free to run hosts which discard source routes. Of course, doing this will inhibit some potential valid uses for EIDs, just as discarding source routes inhibits potential valid uses of LSSRs. I think we really need to come to a situation where we depend less on the routing system for security (such security is often illusory at best anyway, and this is even worse than knowing you are exposed) and depend more on external authentication methods. The more things depend on hosts having particular addresses (i.e. the routing portion of the address), the more difficult it becomes to have people change those addresses as appropriate for changing network topology. The more difficult you make it for people to change their addresses, the less likely it is that they'll be willing to do it, which leaves the routing system to pick up the load instead. If the latter happens often enough the routing system will break sooner as the network grows, no matter which IPv7 proposal you care to choose. I think minimizing the dependence on topology for host identification is a feature for any practical IPv7 proposal. If EIDs do this then I'm for them. Whether EIDs are included or not, I do think that a proposal which hasn't explicitly dealt with the procedures by which the topology portion of addresses for groups of hosts can be changed quickly, painlessly and often should be viewed with suspicion, since otherwise we'll just be perpetuating the routing problems we have now. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Wed Oct 21 05:50:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19076; Wed, 21 Oct 1992 05:50: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 AA19070; Wed, 21 Oct 1992 05:50:03 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA26069; Tue, 20 Oct 92 15:47:57 -0400 Date: Tue, 20 Oct 92 15:47:57 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9210201947.AA26069@er.doe.gov> To: jcurran@nic.near.net, jnc@ginger.lcs.mit.edu Subject: Re: EID compromise Cc: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Whyare EID's useful? 1) They isolate endpoints from changes in addresses. 2) They give a common identifier for multiple interfaces or interface addresses on a single endpoint. 3) They may help with mobile hosts (or maybe not). What is undesireable about them. 1) another entity to assign and manage. 2) extra bits in every packet. 3) how do routers usethem, routers cannot wait for DNS queriesto forward packets.. 4) Some applications want to do reverse lookup address->eid which is hard to do efficiently. Now the current domain name is a sort of eid although it suffers from difficulty 2 and4 badly. It doesn't seem necessary for the EID to be in the packet necesarily... Once you have used theEID to get an address then what info. does it add. Is anyone thinking that intermediate routeswould look up the adress themselves so if one interfaceat the last hop were dead the packet could find a live one? Perhaps in the case of mobile hosts the EId in each packetbuys somethingbecause of dynamic address binding? Dan Hitchcock P.S. I am not suggesting domain name as an EID. From owner-big-internet@munnari.oz.au Wed Oct 21 06:18:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20080; Wed, 21 Oct 1992 06:18:23 +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 AA17253; Wed, 21 Oct 1992 04:43:42 +1000 (from jonson@server.af.mil) Received: by server.af.mil (5.59/25-eef) id AA17537; Tue, 20 Oct 92 13:41:40 CDT From: Matt Jonson Message-Id: <9210201841.AA17537@server.af.mil> Subject: Re: Day vs Chiappa re EID To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Tue, 20 Oct 92 13:41:37 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <9210201456.AA22579@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 20, 92 10:56 am X-Mailer: ELM [version 2.3 PL11] > This is not a great analogy; I could say that those multiple routes are > equivalent to the multiple routes in the average internetwork. A much better > analogy would be someone who lived on the corner and had two front doors, and > thus had two addresses. If the sidewalk on one street was torn up for street > work, and made that door inaccessible, that's the analogy to a multi-homed > host with a dead interface. (A human coming on this situation would deal with > it by noticing the house had two doors, and going around the corner to the > other one, of course. We need to do the computer equivalent.) The computer equivalent may be impossible, since in this analogy the human is equivalent to the packet but the human also has all the processing power on board. Since packets must always be stupid and rely on outside entities to direct them, the outside entity (router) at the point where the path potentially diverges would have to be capable of making different destination interface decisions. (that would be an optimum case, but clearly some router in the chain would have to be capable of making the decision to route to the best interface) Is this a solvable problem? Is it worth solving? It seems to require the use of an EID and routers performing route look-up on that EID on the fly. This would seem to impose a good bit more routing overhead on a packet. How would this be solved under NIMROD? The difficult case would be an end-system whose interfaces were in different routing areas... The rest of your mail implied that it wasn't solvable and that interface addresses were the way to go. thoughts? > By keeping addresses location dependent but route specific. We solve the > multi-homing and mobility problems without giving up the embedded aid to > routing. > > I thought about this for a while yesterday after sending off my mail, > and I have a clearer version of my argument. We can route to one of 3 things: > interface (addresses), topologically significant endpoint names (TSEN's), or > non-topologically significant EID's. The latter implies that the routing has > to track EID's, and we get no scaling, so this clearly will not work. The > former has the problem that if you have a multi-homed host, you need to pick > which interface to send to. What about a case where n-tsEs (from above ;-)) are hierarchically managed and a router doesn't make a choice unless it is in the same management area as the end-system. Wouldn't that scale? You still end up with the problem of routers tracking EIDs. /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 Any opinions expressed above are personal and don't represent the U.S Government From owner-Big-Internet@munnari.oz.au Wed Oct 21 06:29:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20654; Wed, 21 Oct 1992 06:30:17 +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 AA20595; Wed, 21 Oct 1992 06:29:46 +1000 (from kre) To: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Cc: big-internet@munnari.oz.au Subject: Re: EID compromise In-Reply-To: Your message of Tue, 20 Oct 92 15:47:57 -0400. <9210201947.AA26069@er.doe.gov> Date: Wed, 21 Oct 92 06:29:32 +1000 Message-Id: <14916.719612972@munnari.oz.au> From: Robert Elz Date: Tue, 20 Oct 92 15:47:57 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-ID: <9210201947.AA26069@er.doe.gov> Whyare EID's useful? 1) They isolate endpoints from changes in addresses. 2) They give a common identifier for multiple interfaces or interface addresses on a single endpoint. 3) They may help with mobile hosts (or maybe not). All of those, yes, and probably more that we don't know yet. What is undesireable about them. 1) another entity to assign and manage. 2) extra bits in every packet. Nothing comes without some costs. I don't see (1) as much of a problem, as the lack of any real semantics for the EID meansthere are no real constraints on how an organisation can assign them from a block it receives, automating this will be easy. For (2) - well, bits are bits, we don't want to waste them, but where there's a good purpose, that's what the bits are there to do. 3) how do routers usethem, routers cannot wait for DNS queriesto forward packets.. Routers (other than Nimrod) don't use them. 4) Some applications want to do reverse lookup address->eid which is hard to do efficiently. Why? This would be the one lookup I wouldn't expect anyone to want to do (unless perhaps EIDs weren't carried in all packets, and the host needed to reconstruct the EID from the sender address in order to use it in checksum calculations or the like, which I don't think ist the way to go). Once you have used theEID to get an address then what info. does it add I wouldn't actually use the EID to get the address normally I don't think (perhaps sometimes, the ability to do it would need to exist). What it adds is a fixed reference (name) of the endpoint of the conversation, independant of the address that's used. Eg: currently when I send a DNS query, the DNS server has to reply from the same address as I send to, even if that makes little sense from its point of view - because the address it uses is one of the ways I disambiguate multiple replies coming back from different servers. With EIDs I would send to a particular EID instead of a particular address, and the reply would come from the same EID, regardless of what addresses happened to be used in the packets. Is anyone thinking that intermediate routeswould look up the adress themselves so if one interfaceat the last hop were dead the packet could find a live one? I don't think so, this is certainly not the idea. Perhaps in the case of mobile hosts the EId in each packetbuys somethingbecause of dynamic address binding? This is one possibility (I think, still knowing little about the mobility proposals, but thanks to Jim Thompson for sending me one of them (Columbia)). kre From owner-Big-Internet@munnari.oz.au Wed Oct 21 07:00:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22025; Wed, 21 Oct 1992 07:00:56 +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 AA22022; Wed, 21 Oct 1992 07:00:48 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA15602 (5.65/6.02); Tue, 20 Oct 92 17:00:31 -0400 Date: Tue, 20 Oct 92 17:00:31 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9210202100.AA15602@sadye.emba.uvm.edu> To: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Cc: big-internet@munnari.oz.au Subject: Re: EID compromise In-Reply-To: <9210201947.AA26069@er.doe.gov> References: <9210201947.AA26069@er.doe.gov> (I trimmed the CC list a bit..) < 4) Some applications want to do reverse lookup address->eid which is hard > to do efficiently. Dead easy. Define an EID meaning roughly ``broadcast''. Send a *CMP ECHO packet to (address, broadcast). Get a *CMP ECHO REPLY back from (address, real EID). I think that Paul T.'s EID scheme provides for the necessary inverse mapping from EID to anything in an efficient manner. -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-Big-Internet@munnari.oz.au Wed Oct 21 07:18:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22668; Wed, 21 Oct 1992 07:18:11 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210202118.22668@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22662; Wed, 21 Oct 1992 07:18:03 +1000 (from jcurran@nic.near.net) To: Dan Hitchcock Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: EID compromise In-Reply-To: Your message of Tue, 20 Oct 92 15:47:57 -0400. <9210201947.AA26069@er.doe.gov> Date: Tue, 20 Oct 92 17:17:29 -0400 From: John Curran -------- From: Dan Hitchcock Subject: Re: EID compromise Date: Tue, 20 Oct 92 15:47:57 -0400 What is undesireable about them. 1) another entity to assign and manage. 2) extra bits in every packet. 3) how do routers usethem, routers cannot wait for DNS queries to forward packets.. 4) Some applications want to do reverse lookup address->eid which is hard to do efficiently. Undesirables: 1) another entity to assign and manage. True. The best way to fix this is to use a network layer with autoconfiguration (such as CLNS) and then you've traded administering network addresses for administering EIDs which at least reflect the admin. entity rather than network attachment point. 2) extra bits in every packet. Yep. On point-to-point slow speed links, high locality and compression should make these effectively disappear. 3) how do routers use them, routers cannot wait for DNS queries to forward packets.. Routers shouldn't examine EIDs. A large number of other gateways (transition, "firewall", mobility, accounting) may have an interest in EIDS... With respect to "waiting for DNS queries to forward packets", I believe that does occur under some other big-internet proposals. 4) Some applications want to do reverse lookup address->eid which is hard to do efficiently. Agreed. If datagrams carry EIDs, there should not be many occasions to have an address without the EID. And it would still be possible to go "the long way around" by doing address->name->eid. Now the current domain name is a sort of eid although it suffers from difficulty 2 and 4 badly. It doesn't seem necessary for the EID to be in the packet necesarily... Once you have used the EID to get an address then what info. does it add. Is anyone thinking that intermediate routes would look up the adress themselves so if one interface at the last hop were dead the packet could find a live one? Perhaps in the case of mobile hosts the EId in each packet buys something because of dynamic address binding? EIDs are transport-layer identifiers which aren't tied up in our current (and future) network layer addressing. Noel may have other opinions on the above... :-) /John From owner-Big-Internet@munnari.oz.au Wed Oct 21 07:53:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23991; Wed, 21 Oct 1992 07:53:57 +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 AA23988; Wed, 21 Oct 1992 07:53:51 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA16290 (5.65/6.02); Tue, 20 Oct 92 17:53:27 -0400 Date: Tue, 20 Oct 92 17:53:27 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9210202153.AA16290@sadye.emba.uvm.edu> To: Matt Jonson Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: Day vs Chiappa re EID In-Reply-To: <9210201841.AA17537@server.af.mil> References: <9210201456.AA22579@ginger.lcs.mit.edu> <9210201841.AA17537@server.af.mil> < said: > Since packets must always be stupid and rely on outside > entities to direct them, the outside entity (router) at the point where > the path potentially diverges would have to be capable of making > different destination interface decisions. (that would be an optimum > case, but clearly some router in the chain would have to be capable > of making the decision to route to the best interface) > Is this a solvable problem? Is it worth solving? It seems to require > the use of an EID and routers performing route look-up on that EID on > the fly. > thoughts? Well, one of the ideas that I have had is that, if a host's interface goes dead, *AND* the router has some way of knowing it (e.g., some sort of active communication that's not happing but should be), then it can send back a *CMP ``Dest EID not available at this address'', which would cause the *sending* host to re-compute the address. (The router doesn't actually have to keep track of EIDs, only addresses, but the The Best of All Worlds, I would have the ``route server'' and packet-forwarding functions co-located, so it would have to know about local EIDs anyway. CLNP routers can do this already, no?) The scheme which I talked about earlier is an attempt to isolate this from the application layer. To give a concrete example, the mail transfer agent should *not* have to keep a list of addresses to try for a particular host; it should be able to simply say ``connect to the host with this EID'' and let the ``system'' take care of trying various computed JNC-addresses/routes until it finds one that works. I think this fits in well with the idea than an EID would name a specific TCP... -GAWollman -- Garrett A. Wollman | Shashish is simple, it's discreet, it's brief. ... wollman@emba.uvm.edu | Shashish is the bonding of hearts in spite of distance. uvm-gen!wollman | It is a bond more powerful than absence. We like people UVM disagrees. | who like Shashish. - Claude McKenzie + Florent Vollant From owner-Big-Internet@munnari.oz.au Wed Oct 21 09:54:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29179; Wed, 21 Oct 1992 09:54:42 +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 AA29172; Wed, 21 Oct 1992 09:54:32 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA02171; Tue, 20 Oct 92 19:54:24 EDT Date: Tue, 20 Oct 92 19:54:24 EDT From: atkinson@itd.nrl.navy.mil (Randall Atkinson) Message-Id: <9210202354.AA02171@itd.nrl.navy.mil> To: Big-Internet@munnari.oz.au Subject: Security & Headers Frank Kastenholz's comments on this generally sound right to me. I personally think that the way to ensure that the address in the headers hasn't been tampered with or spoofed is to have a "digital signature option" in whatever replaces IPv4. That way the folks who want to authenticate header (or header+data) on a packet by packet basis can reasonably do so while those who don't need to (or think they don't need to :-) can just ignore that particular option on received packets and omit it on sent packets. This implies that the current restriction on total number of header bytes per IP frame has to be removed. Instead either a Very Large number should be used for the new option size limit or (better yet) the option size limit should be removed entirely. There would also probably need to be something equivalent to an ICMP message that meant "received packet not authentic" or "received packet did not include authentication option" or maybe both. MD5 could be used with shared secrets to create a digital signature or one could encrypt a checksum using your favourite algorithm. Note that something based on MD5 might not have export restrictions since it would only be useful for authentication and not for any kind of confidentiality. If some kind of asymmetric digital signature algorithm were used, then adding a DNS record named "HAK" for Host Authentication Keys would be useful and would make key distribution easier. I've thought about the network layer authentication problem in some detail and am fairly confident that a "digital signature option" is the way to go. I'm not entirely sure how well it fits in with PIP, mainly because I don't really understand PIP well enough. Folks wishing to discuss this in more detail than might be appropriate for this list should feel free to drop me an email. Regards, Ran atkinson@itd.nrl.navy.mil From owner-big-internet@munnari.oz.au Thu Oct 22 00:06:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04558; Thu, 22 Oct 1992 00:07: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 AA02997; Wed, 21 Oct 1992 23:38:40 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA12720; Wed, 21 Oct 92 06:38:31 -0700 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA27880; Wed, 21 Oct 1992 09:38:28 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: EID compromise In-Reply-To: <9210201355.AA21546@ginger.lcs.mit.edu> References: <9210201355.AA21546@ginger.lcs.mit.edu> X-Mailer: Poste 2.0 From: David Oran Date: Wed, 21 Oct 92 09:38:16 -0400 Message-Id: <921021093816.15554@sneezy.lkg.dec.com> Encoding: 26 TEXT, 6 TEXT SIGNATURE > I must confess I didn't follow this completely, but I think I get the drift > (although I could be wrong). Is what you are saying that the EID in itself is > useless for security, and that any binding between a secret and an EID simply > represents another point of attack? I.e., the best "EID" for a secure > connection would be the public key of a public-private key pair, and forget > associating any security with the EID, since it itself is so insecure? > Yes. That's what I'm saying, more or less. You may have overstated my case somewhat, since there isn't any reason in principle NOT to use the EID as *part* of the bits which represent the identity associated with the secret. > Well, I must confess, security is not my specialty. I've just heard real > seecurity wizards (e.g. Steve Kent) say a globally unique ID makes their job a > lot easier, and I was taking him on faith. You're right, it's a long > discussion, and perhaps we should leave it for the moment, but I would like to > find out if a global ID makes their job easier. You should ask Steve and others whether the IDs they posit as useful have temporal as well as spacial uniqueness. If they can be re-assigned they may not have the properties you want. Further, it is important to nail down just WHAT the security-relevant id's are associated with. I continue to claim it isn't useful from a security standpoint to use id's that are bound to communication endpoints, since these are not interesting to authenticate. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Thu Oct 22 01:40:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07849; Thu, 22 Oct 1992 01:41:07 +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 AA07835; Thu, 22 Oct 1992 01:40:57 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27885; Wed, 21 Oct 92 11:40:53 -0400 Date: Wed, 21 Oct 92 11:40:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210211540.AA27885@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, kre@munnari.oz.au Subject: Re: Day vs Chiappa re EID Cc: jnc@ginger.lcs.mit.edu That this isn't often done is more related to the way we coalesce routing information than the properties of IP addresses themselves. Yes, thanks for pointing this out; I missed it. Quite the contrary, we want network topology bound into the addresses This is the soul of heirarchical routing and addressing! Using whatever technique it chooses it picke one of the addresses, inserts that, and the EID, into the packet, plus its own EID and (one of) its address(es), and sends the packet. I would, of course, say that if the packet is part of a long transaction (e.g. a file retrieval, or a packet teleconference) a flow would be set up using the addresses, and the packets would simply contain the EID's... Noel From owner-big-internet@munnari.oz.au Thu Oct 22 02:07:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08671; Thu, 22 Oct 1992 02:07: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 AA07667; Thu, 22 Oct 1992 01:36:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27848; Wed, 21 Oct 92 11:35:25 -0400 Date: Wed, 21 Oct 92 11:35:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210211535.AA27848@ginger.lcs.mit.edu> To: Day@bbn.com, Garrett.Wollman@uvm.edu Subject: Re: Day vs Chiappa re EID Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu You want to send a packet to my machine, tsornin.emba.uvm.edu. You look up in the DNS to find out that his EID is 2.1376.4.5. You can then form a transport-layer packet addressed to that entity. Your network layer then consults some data source which can look up the address of that EID. Why not have the DNS lookup of tsornin.emba.uvm.edu return both the address and the EID? The internetwork layer on the host would be passed the tuple and enter it in a cache which can turn EID's into addresses for outgoing packets (if needed, i.e. no flows :-). I have spoken of having Nimrod do EID->address mappings but only as a *temporary* interoperable deployment hack! Noel From owner-big-internet@munnari.oz.au Thu Oct 22 02:13:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08917; Thu, 22 Oct 1992 02:13: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 AA08145; Thu, 22 Oct 1992 01:50:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA27943; Wed, 21 Oct 92 11:49:58 -0400 Date: Wed, 21 Oct 92 11:49:58 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210211549.AA27943@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: Security and EIDs Cc: jnc@ginger.lcs.mit.edu People who think we should introduce IPv7 in the context of a complete security architecture are in fantasy land. If you want to consider the technical difficulties.... I would love to hear if the people planning for a secure Internet have requirements or preferences for IPv7. I think this request has been made before with no response. Sigh, yes, I know, a security architecture is a long way from done. The current incredibly tortuous attempts at securing bits and pieces of the system are indeed a long way from one. Hopefully we will learn from our mistakes here and be able to do something better after the lessons have been assimilated. I just don't know what those lessons will be, or how (if at all) they would affect the design of a new IP layer to correctly make it secure. *That's* why I want to put off a new internet layer as long as possible.... I personally think that security is an end-to-end matter, and things will work out better if we split the routing part of the network layer from the end-to-end part and keep the latter flexible. Yes, but it would be nice if we had a system which was secure from denial of service and other such attacks on getting packets from interface A to interface B, and that *is* most definitely the province of the internetwork layer. Still, you've both made good points about remembering that the endpoint- endpoint function might usefully be separated (even if only conceptually) from the interface-interface function. Noel From owner-Big-Internet@munnari.oz.au Thu Oct 22 02:15:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08992; Thu, 22 Oct 1992 02:15:45 +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 AA08986; Thu, 22 Oct 1992 02:15:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28118; Wed, 21 Oct 92 12:15:27 -0400 Date: Wed, 21 Oct 92 12:15:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210211615.AA28118@ginger.lcs.mit.edu> To: dennis@ans.net Subject: Re: Security and EIDs Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu If you can find a host which inverts source routes properly (this is a MUST in rfc1122) there is no need to attack routing at all to have responses to packets with any random source address returned to your doorstep. Sigh, we'd been kind of keeping this one under our hats.. oh well. There is even an outstanding proposal for host mobility which depends somewhat on hosts with the ability to invert source routes, in conformance with rfc1122, being common. I pointed out to them the volatile interaction between their proposal and things like .rhosts, which are of course an utter kludge, but widely deployed nonetheless. I'm not sure what ther reaction was after they thought about it.. I think we really need to come to a situation where we depend less on the routing system for security and depend more on external authentication methods. Yes, but this step is a trickier one than you think. Anyone attempting to break security will look for the weakest link. Your bank vault has a big steel door? Dig through the wall instead. The network analogy is simple. TCP connections "totally" secure? How about SNMP? Can you reach in through SNMP and diddle the TCP security? Remember the Morris worm? If preferred some wide open doors (mailer, fingerd) to hard ones. I sent a message to Big-I a while back in which I compared network security to operating system security. On the typical workstation (without *real* multi-level security inside), you effectively have a security perimeter around the workstation, and every packet transaction that can change state inside the perimeter must be equally secure, otherwise the smart attacker will concentrate on the weakest one. You don't get that equality if each and every protocol has its own security mechanism. The OS guys learned this the hard way; you can't let each system call include code to check its arguments for validity, since sooner or later some human screws up. We need a similar *overall* security architeture for the network. No, I *don't* know what it looks like, unfortunately... The more things depend on hosts having particular addresses (i.e. the routing portion of the address), the more difficult it becomes to have people change those addresses as appropriate for changing network topology. The more difficult you make it for people to change their addresses, the less likely it is that they'll be willing to do it, which leaves the routing system to pick up the load instead. If the latter happens often enough the routing system will break sooner as the network grows, no matter which IPv7 proposal you care to choose. Cazart! Excellent summary! I think minimizing the dependence on topology for host identification is a feature for any practical IPv7 proposal. ... I do think that a proposal which hasn't explicitly dealt with the procedures by which the topology portion of addresses for groups of hosts can be changed quickly, painlessly and often should be viewed with suspicion, since otherwise we'll just be perpetuating the routing problems we have now. Yes, I hadn't realized this originally, but the penny dropped a few months ago for me too. I've been looking over Nimrod in the light of this realization, to make sure it provides the right hooks to make this easy. We have to be able to do this to make CIDR work *well*, even, so perhaps we can start on these tools now, hmm? Noel From owner-Big-Internet@munnari.oz.au Thu Oct 22 02:28:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09596; Thu, 22 Oct 1992 02:29:06 +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 AA09569; Thu, 22 Oct 1992 02:28:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28232; Wed, 21 Oct 92 12:28:50 -0400 Date: Wed, 21 Oct 92 12:28:50 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210211628.AA28232@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, jonson@server.af.mil Subject: Re: Day vs Chiappa re EID Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The computer equivalent may be impossible, since in this analogy the human is equivalent to the packet but the human also has all the processing power on board. Oh, I know, that's why I was slightly humorous in characterizing that as the human reaction. Like I said, it's not a *great* analogy. It seems to require the use of an EID and routers performing route look-up on that EID on the fly. No, the right thing is probably to have someone (the last-hop router) notice the packet didn't get to the host and notify the source. Speaking of which, that's one of my pet peeves about network interfaces. All the cretinous designs give us a hardware checksum (which we *don't* need, because if your net's BER is low enough the end-end checksum, which you *must* have, is good enough), but very few give us half-way decent "packet not received" information (which we *do* need). Rings do, unless they are bridged (another reason bridges suck). There's thus usually no way for a host and a router to find out each other are OK without doing pings back and forth, and as Van J has pointed out, this can become expensive. Grrrr. (I note proudly that the V2LNI, done at MIT around 1980, had both of these; no useless hardware checksum, and a 'packet not accepted' bit! :-) The difficult case would be an end-system whose interfaces were in different routing areas... The rest of your mail implied that it wasn't solvable and that interface addresses were the way to go. Exactly. It's not *generally* solvable if you try and make the routing solve it under the sheets. Instead, you pull it out into the daylight and kill it with a direct blow (i.e. explicit info back to the source that this address for that EID no longer works). If anyone doesn't believe that, consider: the *expensive* part of the problem is for the last hop router to find out that the host is not responding, not the rest of the mechanism. This part is the same no matter how you solve it... What about a case where n-tsEs (from above ;-)) are hierarchically managed and a router doesn't make a choice unless it is in the same management area as the end-system. Wouldn't that scale? You still end up with the problem of routers tracking EIDs. I couldn't grasp this? Noel From owner-Big-Internet@munnari.oz.au Thu Oct 22 02:48:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10150; Thu, 22 Oct 1992 02:48:30 +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 AA10138; Thu, 22 Oct 1992 02:48:20 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA04423; Wed, 21 Oct 92 10:48:15 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA14541; Wed, 21 Oct 92 10:48:07 MDT Message-Id: <9210211648.AA14541@goshawk.lanl.gov> To: big-internet@munnari.oz.au Subject: EID structure? In-Reply-To: Your message of Wed, 21 Oct 92 11:40:53 -0400. <9210211540.AA27885@ginger.lcs.mit.edu> Date: Wed, 21 Oct 92 10:48:06 MST From: peter@goshawk.lanl.gov >>> I would, of course, say that if the packet is part of a long transaction (e.g. >>> a file retrieval, or a packet teleconference) a flow would be set up using the >>> addresses, and the packets would simply contain the EID's... >>> Noel Is there any evidence this will scale in a large Internet without adding some kind of structure in the EIDs? The atm folk have chosen the VPI/VCI structure. Is this sufficient? I would be interested in pointers to articles on this topic. thanks, peter From owner-Big-Internet@munnari.oz.au Thu Oct 22 05:09:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13516; Thu, 22 Oct 1992 05:09:44 +1000 (from owner-Big-Internet) Return-Path: Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13511; Thu, 22 Oct 1992 05:09:32 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA04461; Wed, 21 Oct 92 12:09:44 PDT Date: Wed, 21 Oct 92 12:09:44 PDT From: Eric Fleischman Message-Id: <9210211909.AA04461@atc.boeing.com> To: Big-Internet@munnari.OZ.AU, tuba@lanl.gov Subject: IETF at Crossroads IPv7 may be the IETF's Rubicon I believe that the IETF is currently at a crossroads in its strategic, long-term IPv7 decision which will determine whether it will remain in the center of the open systems movement (i.e., a CLNP-based solution) or whether it will start becoming superfluous to the community it presently guides (i.e., a solution based upon Yet Another networking Protocol (YAP)). Is this a crazy thought? Well, maybe not. Please consider the following. 1) WHERE I AM COMING FROM I am a network architect for a company which has seventeen major data communications protocol families in widespread deployment. TCP/IP is one of our larger deployments with, say, 60,000 TCP/IP hosts. Our networks generally are multi- protocol in nature. We are a manufacturing company, so our networks solely exist as a means to an end. My job therefore is to obtain the largest connectivity gain for the smallest networking expense. 2) MIGRATIONS PAINFUL Despite the commendable efforts of computer vendors, migrations (e.g. to the new IPv7) are generally painful, time consuming, and expensive for users, especially if the populations to be migrated are large or their key applications inflexible in the support of such a migration. Numerous local technical reasons often compel users, who would prefer to migrate to the latest technologies, to be simply unable to pursue such a migration. Migrations also may be unfeasible for internal corporate business reasons. Consequently, installed bases (for example) using BTAM (i.e. "Baker-TAM" which requires BSC communications) and DECnet Phase III are much more common in the United States than one might think -- probably much more extensive than the vendors who originally defined those protocols may imagine. Installed bases using now-obsoleted equipment, software, and/or protocols are frequently referred to as "legacy systems". Legacy systems are very undesirable from a user's perspective because they have very high maintenance costs and suffer from a "hardening of the arteries" which make them unable to support new and desirable technologies and approaches. 3) OPEN SYSTEMS One of the "drivers" for the "Open Systems Movement" from a User's perspective is the belief that "open products" which are deployed in a "standard fashion" will not become legacy systems. Users hope that "open products" have become commodities so that a user is not totally dependent upon a single vendor to meet its needs. Users anticipate lower long term expenses with open systems due to competition and increased availability of "shrink wrapped" interchangeable solutions. Also, because "open systems" generally define interfaces, open systems are generally not obsoleted by underlying changes in operating systems, hardware, or other computer components with short life cycles. Thus, it is widely believed that because Open Systems are industry standards, they have a very long "shelf life". Most importantly, Open Systems are seen as a mechanism to permit users to be in control of their own installed base so that they are not totally subject to outside forces which can quickly convert their very expensive infrastructure into "legacy systems". Currently TCP/IP protocols are considered "de facto" standards and an important part of the Open Systems movement. Consequently, many users would greatly prefer to deploy TCP/IP solutions over a proprietary option. This partially explains the explosive growth of TCP/IP deployments in recent years. (Other major reasons, of course, are the Internet itself and cost.) In any case, please note the implication that "open protocols" such as TCP/IP are different from "proprietary protocols" simply because if vendor X tries to compel a corporation to do something it prefers not to do then that corporation may very well meet its needs (with a minimum of cost) through vendor Y's services. I believe that this possibility is not unknown to the vendors. 4) MARKET FOR CLNP From the above, one can see that inertia is a powerful force which tends to resist change and "forced migrations". For this reason, a certain percentage of a global installed base will never migrate to a new solution no matter how compelling the reason. However, users as a whole are much more likely to try to support a migration if they feel that the migration is in their best interest (i.e., that there is a compelling *business reason* to justify the expense). Of course, a compelling business reason to one corporation may not impress another corporation. However, I believe that genuine business reasons generally exist for corporations to support a CLNP- based IPv7 solution. While I am not at liberty to discuss what I feel these compelling business reasons are for my employer, I wish to identify the following issues as seen from my "knot hole": * We have working experience with CLNP and OSI routing. We are comfortable with a CLNP-based solution because we have some feel for the problem/solution "domain" of such an approach and CLNP deployments correspond to our corporate networking strategic direction. * We perceive both IP and CLNP to be desirable "open systems protocols". I personally doubt whether YAP will be similarly viewed. * We have *significant* problems with the number of protocols currently supported in our networks. We are actively trying to reduce the number of protocols we have deployed to achieve significant bandwidth, maintenance, support, and infrastructural cost savings. Thus, we favor proposals which reduce our number of networking protocols and generally oppose proposals which will increase our number of networking protocols (e.g., YAP). * We face growing market pressure to implement OSI solutions. I perceive that this pressure comes from governments (note the plural), our industry as a whole (e.g., ATN, AOP, ARINC, etc.), internal processes within our own company, and our customers. * The adoption of a CLNP-based solution will hopefully permit the bottom three layers of both the OSI and TCP/IP stacks to eventually become common. Should this occur, this may translate into increased network simplification for our installed base which would directly translate into significant long-term maintenance and support savings for us. * Since most vendors already have both OSI and TCP/IP products, I anticipate that a CLNP-based solution would be easier for the vendors to develop and therefore cheaper for us users to buy. * Currently I feel "pressure" from the competing TCP/IP and OSI camps. This "war" is *NOT* in the users' best interest. I feel that a CLNP-based solution will go a long way towards uniting these two important communities. * I hope that a CLNP-based solution will permit me to ultimately choose "the best" from both the TCP/IP and OSI worlds over a single stack without the extra overhead of RFC 1006. I personally hope that such a "unified stack" will eventually support FTP, TELNET, X.500, OSI Transaction Processing, X windows, NFS, and both SMTP and MOTIS (X.400). * Network service providers are increasingly being expected to support both TCP/IP and OSI. I imagine that these service providers would prefer to support only two network protocols (IP and CLNP) with a unified routing solution rather than three network protocols (IP, CLNP, YAP) and potentially multiple routing protocols. 5) NO MARKET FOR YAP Should the IETF choose Yet Another Protocol (YAP) to be its strategic IPv7 solution then I believe that it would have made a serious miscalculation for the following reasons: * Nobody has any experience with YAP. This implies deployment risks. * YAP is not a de facto standard nor is it an Open System standard. YAP, in fact, is targeted to directly compete with bona fide Open System standards. It does this without any installed base or user allegiance. * YAP would ask my company to deploy yet another network layer protocol. This possibility is directly opposed to our corporate networking policy. * YAP does not help users with their strategic business needs (other than the obvious IPv7 scaleability "fix"). Because of an absence of "business drivers" to support YAP, I suspect that unless the Internet community "mandates" YAP's use, it will generally be ignored. Should YAP be mandated, many corporations will probably "dual-stack" the hosts which regularly communicate over the Internet (e.g., make them into gateway devices between the large TCP/IP deployment and the IPv7-based Internet) leaving the vast majority of their TCP/IP deployment unchanged. In this way, the Internet's requirements could be accommodated with a minimum of expense. (Note: YAP would also be another factor to push users to migrate to OSI.) Vendors, when they scope the expenses of supporting a long- term IPv7 product solution, must take into account whether the benefit to them (i.e., sales volume) will compensate for their expenses. Vendors have been very badly burned in the past through inaccurate "sales vs. expense" calculations for product support. Thus, they will question whether there will be a wide-spread migration to a permanent IPv7 solution or whether a permanent IPv7 solution will be solely a "niche market". If I were such a vendor, I would ask "why would it be in the business interest of my customers to go IPv7?" If there is no such prevalent "real business interest" then you have a "niche market" at best. If a long-term IPv7 solution is a niche market, then I as a user have even less incentive to deploy "IPv7" and we as the Internet community have more incentive to continue to *INDEFINITELY* support TCP/IP as it currently exists, regardless of what we would have preferred to do. Thus, a YAP solution may well prove to not be any solution at all. 6) CONCLUSION: Several powerful forces are slowly forming an OSI community which is distinct from the much larger TCP/IP community. Vendors and network service providers are increasingly being expected to meet the needs of both communities. The IETF now has the option of partially "uniting" both of these communities through the adoption of CLNP as its IPv7 solution. Should this occur, the dynamics, expertise, and installed base of the TCP/IP community would drive the resulting common protocols anywhere they need to go. On the other hand, the IETF may opt to create a competing technology which is at odds with major market trends. Such a "solution" would not be in anybody's best interests. Eric Fleischman Network Architect Boeing Computer Services From owner-Big-Internet@munnari.oz.au Thu Oct 22 05:37:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14314; Thu, 22 Oct 1992 05:37:17 +1000 (from owner-Big-Internet) Return-Path: Received: from relay.hp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14308; Thu, 22 Oct 1992 05:37:04 +1000 (from eva@hpindda.cup.hp.com) Received: from hpindda.cup.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA02204; Wed, 21 Oct 92 12:36:58 -0700 Received: by hpindda.cup.hp.com (15.11/15.5+IOS 3.20+cup+OMrelay) id AA20634; Wed, 21 Oct 92 12:37:36 pdt From: Eva Kuiper Message-Id: <9210211937.AA20634@hpindda.cup.hp.com> Subject: Re: IETF at Crossroads To: ericf@atc.boeing.com Date: Wed, 21 Oct 92 12:37:33 PDT Cc: Big-Internet@munnari.OZ.AU, tuba@lanl.gov, eva@hpindda.cup.hp.com In-Reply-To: <9210211909.AA04461@atc.boeing.com>; from "Eric Fleischman" at Oct 21, 92 12:09 (noon) Mailer: Elm [revision: 64.9] Eric, Thank you for sharing your experience with us. I think you have provided some good insights which pull together all that the TUBA folks feel but had not expressed. CLNP in TUBA makes good business sense for the user community in a world of converging protocol stacks. Eva From owner-big-internet@munnari.oz.au Thu Oct 22 08:22:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20621; Thu, 22 Oct 1992 08:22:57 +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 AA17133; Thu, 22 Oct 1992 06:53:44 +1000 (from craig@aland.bbn.com) Received: from port36.sc.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA08016; Wed, 21 Oct 92 16:53:10 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA21254; Wed, 21 Oct 92 13:51:35 PDT Message-Id: <9210212051.AA21254@aland.bbn.com> To: Eric Fleischman Cc: Big-Internet@munnari.oz.au, tuba@lanl.gov Subject: re: IETF at Crossroads From: Craig Partridge Date: Wed, 21 Oct 92 13:51:34 -0700 Sender: craig@aland.bbn.com Eric: I certainly don't disagree that the IPv7 is a major decision (as was Caesar's in deciding to cross the Rubicon). And I am sympathetic with several of the points you make, but I think the suggestion that CLNP is the answer is flawed. Summarizing, in brief, the argument you made, it sits on four points: (1) migrations hurt, and some folks never migrate; (2) users want open systems that work for them and free them from vendor dependence; (3) there exist some CLNP implementations already deployed; (4) people don't want yet another protocol (YAP); >From these points, one can argue (as I believe you do) that migrating to an existing open protocol is best, as it may smooth migration and avoids YAP, and since CLNP is here, let's take it. I have two problems with this line of thinking: First, I can replace point (3) with other protocols. How about AppleTalk? IPX? They're far more widely used than CLNP and well-enough documented that there are third-party vendors. They have nice features that IP doesn't and a big installation base (far bigger than CLNP). So why don't we avoid the YAP problem by migrating to AppleTalk or IPX? Well, the reason is that they don't work on the scale of the Internet. They're designed to connect up an office or a campus, not a world. So before we choose an existing protocol to migrate to, we'd better be confident it works for the ever-larger and changing Internet. There are some good technical folks who believe CLNP won't adapt to the future Internet much better than IPv4 and perhaps worse. Note the Kobe announcement proposed using a *modified* CLNP, which may or may not interoperate with existing CLNP (YAP-CLNP anyone?). Second, I think the list is has to be prioritized if we are to make a clear decision. Do we prefer to be sure that the migration is painless? that the protocol works? that it be called CLNP? Personally, if I take the list, I'd rank priorities in the following way: (1) users want open systems that work for them and free them from vendor dependence; (2) migrations hurt, and some folks never migrate; (3) people don't want yet another protocol (YAP); (4) there exist some CLNP implementations already deployed; In short, a protocol that is open and we're sure works for the Internet is more important than making the migration easy or avoiding YAP. Avoiding a migration or going to YAP or an existing protocol *isn't worth it* if the result is something that doesn't work. Given that we find something that works, we then get to work hard on migration paths, and worry about whether we've got YAP or can pick CLNP. Craig From owner-Big-Internet@munnari.oz.au Thu Oct 22 09:57:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25030; Thu, 22 Oct 1992 09:57:55 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210212357.25030@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25022; Thu, 22 Oct 1992 09:57:38 +1000 (from jcurran@nic.near.net) To: Craig Partridge Cc: Eric Fleischman , Big-Internet@munnari.oz.au, tuba@lanl.gov Subject: Re: IETF at Crossroads In-Reply-To: Your message of Wed, 21 Oct 92 13:51:34 -0700. <9210212051.AA21254@aland.bbn.com> Date: Wed, 21 Oct 92 19:55:16 -0400 From: John Curran -------- ] From: Craig Partridge ] Subject: re: IETF at Crossroads ] Date: Wed, 21 Oct 92 13:51:34 -0700 ] ... ] ] So before we choose an existing protocol to migrate to, we'd better be ] confident it works for the ever-larger and changing Internet. There are ] some good technical folks who believe CLNP won't adapt to the future ] Internet much better than IPv4 and perhaps worse. ... I would interested in any technical arguments regarding why CLNP won't handle the ever-larger and changing Internet. Perhaps these could be posted to the tuba@lanl.gov mailing list so as to spare the majority of the big-internet folks? Thanks! /John From owner-Big-Internet@munnari.oz.au Thu Oct 22 10:17:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25889; Thu, 22 Oct 1992 10:17:58 +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 AA25886; Thu, 22 Oct 1992 10:17:52 +1000 (from atkinson@itd.nrl.navy.mil) Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA05744; Wed, 21 Oct 92 20:17:42 EDT Date: Wed, 21 Oct 92 20:17:42 EDT From: atkinson@itd.nrl.navy.mil (Randall Atkinson) Message-Id: <9210220017.AA05744@itd.nrl.navy.mil> To: big-internet@munnari.oz.au Subject: Re: YAP comments My fundamental problem with the CLNP approach is really quite simple. I cannot purchase a system implementing a TP4/CLNP stack off the shelf today and have reasonable confidence that it will successfully interoperate with an independent implementation. The ones that do interoperate that I have found have turned out to be repackagings of the same implementation. The widely advertised "OSI Conformance Tests" don't seem to help much -- if a system fails a conformance test I know that it is bad, but if it passes the conformance test I still don't know if it will talk with other implementations that have also passed the conformance test. Most other government folks I know that have tried to network heterogeneous systems have reached the same conclusions. The most successful user of ISO stacks within the US Government appears to me to be NASA and they are still very very heavily into TCP/IP and DECnet Phase IV for their networks. The machine sitting on my desk (like all standard Navy workstations) is dual-stack with both Internet and US GOSIP protocols. However if I want to talk to another system over the net, I have to use TCP/IP at present. I really wish this weren't the case and I'm not religously opposed to TP4/CLNP, but at this moment TP4/CLNP aren't going to solve my networking needs. Now maybe TUBA or a long transition towards TUBA will lead to changes in this reality, but I wouldn't bet my neck or job on that. Now I fear starting an Inet/OSI religious war, so let me note now that other folks on this list strongly disagree with my conclusions about TP4/CLNP interoperability with current commercial products. Religious flames should be sent to me (or better to /dev/null) rather than polluting this normally high signal / low noise list. Ran atkinson@itd.nrl.navy.mil employed by, but not speaking for the Naval Research Laboratory From owner-Big-Internet@munnari.oz.au Thu Oct 22 12:05:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00445; Thu, 22 Oct 1992 12:05:37 +1000 (from owner-Big-Internet) Return-Path: Received: from Osprey.Telcom.Arizona.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00437; Thu, 22 Oct 1992 12:05:30 +1000 (from LEONARD@Arizona.edu) Received: from Arizona.edu by Arizona.edu (PMDF #2381 ) id <01GQ7YN3UUWS8ZGDKR@Arizona.edu>; Wed, 21 Oct 1992 18:53:49 MST Date: 21 Oct 1992 18:53:49 -0700 (MST) From: Aaron Leonard Subject: Re: IETF at Crossroads To: jcurran@nic.near.net Cc: big-internet@munnari.oz.au, craig@aland.bbn.com Message-Id: <01GQ7YN3UUWU8ZGDKR@Arizona.edu> X-Vms-To: IN%"jcurran@nic.near.net" X-Vms-Cc: IN%"big-internet@munnari.oz.au",in%"" Mime-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT | I would interested in any technical arguments regarding why CLNP won't | handle the ever-larger and changing Internet. Perhaps these could be | posted to the tuba@lanl.gov mailing list so as to spare the majority | of the big-internet folks? Speaking as a big-internet lurker, I figure that if I can wade thru dozens of messages grappling with NTP-based routing, I'd be glad to see a cogent (or even otherwise) argument on why CLNP "won't work". Aaron Aaron Leonard (AL104), University of Arizona Network Operations, Tucson AZ 85721 |> If it ain't broke, break it. From owner-Big-Internet@munnari.oz.au Thu Oct 22 19:56:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19971; Thu, 22 Oct 1992 19:56:32 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210220956.19971@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19957; Thu, 22 Oct 1992 19:56:17 +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, 22 Oct 1992 10:29:59 +0100 To: Big-Internet@munnari.oz.au Subject: buying time by reconfiguration In-Reply-To: Your message of "Fri, 09 Oct 92 14:15:47 BST." <199210091318.AA25121@shark.mel.dit.csiro.au> Date: Thu, 22 Oct 92 10:29:44 +0100 From: Jon Crowcroft Just how hard would it be to get some CIDR aggregation in some existing places? I'm gonna ask the UK IP Network managers if it is possible to reallocate all IP addresses in the UK in way that would allow a single UK classless net announcement - there's only 50,000 odd machines registered in DNS, and most are unix boxes - it oughta be relatively simple to provide some xscripts that do DNS and NIS and SNP to all the ciscocs and other routers to do this in a weekend ... given it only took a round a year to install them all from nothing... before embarking on this unpopular path, can someone remind me how much we would gain (in addr space + router table exhaustion) if all regionals did similar (i regard the JIPS net as roughly equiv. to a regional.)? cheers j From owner-Big-Internet@munnari.oz.au Thu Oct 22 19:56:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19981; Thu, 22 Oct 1992 19:56:42 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210220956.19981@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19974; Thu, 22 Oct 1992 19:56:35 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Thu, 22 Oct 1992 10:47:25 +0100 To: Eva Kuiper Cc: ericf@atc.boeing.com, Big-Internet@munnari.OZ.AU Subject: Re: IETF at Crossroads In-Reply-To: Your message of "Wed, 21 Oct 92 12:37:33 PDT." <9210211937.AA20634@hpindda.cup.hp.com> Date: Thu, 22 Oct 92 10:47:19 +0100 From: Jon Crowcroft >had not expressed. CLNP in TUBA makes good business sense for the user >community in a world of converging protocol stacks. Eva okay fine - who is going to bundle CLNP free for my 250 departmental machinews, 4000 college machines ,and 5000 JIPS machines? they better or i'll sue for restraint of trade:-) anyhow, the last UK rare networking meeting ,it was clear to me at least that the world is becoming religuiously multi-protocol, NOT converging at any one time, you have the last decades technology, this decades technology, and the next's - next one is SIP or PIP or somethign over AAL5 on ATM, this one is still IP, last one is [IP|x.25, US|Europe] but whatever we move to it better accomodate USER REQUIREMENTS - the sw3itch to IP in the UK was achieveed becuase uers wanted NFS and X, not becuase they wanted IP instead of X.25 the switch to anything furtyher is gonna be predicated on getting low dropout audio and video multicast, not on the format of the loss-o-gram... in my opinion... cheers jon From owner-big-internet@munnari.oz.au Thu Oct 22 21:09:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23075; Thu, 22 Oct 1992 21:09:45 +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 AA19950; Thu, 22 Oct 1992 19:56:04 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA19377; Thu, 22 Oct 1992 10:53:14 +0100 Message-Id: <199210220953.AA19377@mitsou.inria.fr> To: Aaron Leonard Cc: jcurran@nic.near.net, big-internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: IETF at Crossroads In-Reply-To: Your message of "21 Oct 92 18:53:49 MST." <01GQ7YN3UUWU8ZGDKR@Arizona.edu> Date: Thu, 22 Oct 92 10:53:14 -0500 From: Christian Huitema X-Mts: smtp The discussion of the Kobe draft outlined a number of deficiencies in CLNP, that can summed up in five points: 1) the mapping of the fields in the CLNP header is software hostile, as it pays no attention whatsoever to word boundaries. 2) the CLNP checksum algorithm is unnecessarily hard to compute. 3) the very large address format used by CLNP produce broad headers, which are transmission inefficient. 4) The very large address size limits the use of source routing to a small number of steps. 5) CLNP does not provide any service that IP doesn't. In particular, it has no provision for multipoint routing and resource reservations per flow, which are both needed for multimedia conferences -- the most promising new application in the Internet. Points 1 and 2 means that CLNP is ill fitted for the high speed portion of the Internet. Point 3 means that CLNP is inefficient over low speed fringes of the Internet, e.g. the people which are running IP/SLIP/9600 kbps modems. Point 4 means that it will be difficult to support mobile hosts and policy routing "simply with source routing" -- one will have to invent a new protocol on top of CLNP. Point 5 means that there is in fact no "service" incentive for transitioning to CLNP. Craig was right to mention that the Kobe draft did not mention "adopting CLNP", but rather adopting the CLNP format as a basis for evolution. Several options could have been envisaged, e.g. changing the checksum algorithm, or adding new fields, or focusing on a 64 bits address format. However, the IAB quickly realized that the mid-road "lets get together and work on a single proposal" approach was a bad move. The OSI camp jumped on the proposal and started a PR campaign on the tune of "IAB adopts CLNP", using citations of Lyman's introductory statement. The other camp started an intensive mail storm on the tune of "the IAB has got insane, lets remove it". I am an optimist by nature. I believe that the post-Kobe discussion had at least one good consequence: it clarified the matter a lot. On one hand, it became very clear that nobody is interested by the "modified-CLNP" concept: it will have to be vanilla CLNP or something radically different. On the other hand, the stirring of the pot brought the CLNP proposal in full line, and triggered a large number of critical reviews. As a consequence, a number of researchers realized that they will have either to set up and produce a real good proposal, or to swallow the CLNP monster. We are seing these proposals emerging now, and we are even seing some convergence between some groups. I believe this will lead to a better, larger, more powerful Internet, and that CLNP will probably not play a big role in it. Christian Huitema From owner-Big-Internet@munnari.oz.au Thu Oct 22 23:52:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28694; Thu, 22 Oct 1992 23:52:32 +1000 (from owner-Big-Internet) Return-Path: Received: from cheviot.ncl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28690; Thu, 22 Oct 1992 23:52:17 +1000 (from Denis.Russell@ncl.ac.uk) Received: from [128.240.2.201] (pudding.ncl.ac.uk) by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Thu, 22 Oct 1992 14:52:06 +0100 Date: Thu, 22 Oct 1992 14:52:06 +0100 Message-Id: <199210221352.AA11287@cheviot.ncl.ac.uk> To: Big-Internet@munnari.oz.au, Jon Crowcroft From: Denis.Russell@ncl.ac.uk X-Sender: ndmr@eata.ncl.ac.uk Subject: Re: buying time by reconfiguration At 10:29 am 22/10/92 +0100, Jon Crowcroft wrote: ... >I'm gonna ask the UK IP Network managers if it is possible to ^^^^^^^^ Of course it is possible - a better question is how much it would cost. However, given a cost, how would you evaluate the cost? >reallocate all IP addresses in the UK in way that would allow a single >UK classless net announcement - there's only 50,000 odd machines >registered in DNS, and most are unix boxes - it oughta be relatively I've disagreed with Jon about this before. Most DNS machines are NOT Unix machines. Our site has maybe 3 times as many connected PCs and Macs as Unix workstations. Maybe UCL is richer than us. :-) >simple to provide some xscripts that do DNS and NIS and SNP to all the >ciscocs and other routers to do this in a weekend ... given it only >took a round a year to install them all from nothing... Updating the routers is peanuts. Who is going to trudge round campus and all the remote sites and update all our hosts (i.e. PCs)? Who is going to handle the phone-calls from the real-users-who-don't-give-a-damn-about-protocols, but whose PC/Mac stopped working on Sunday afternoon when they were trying to submit that late paper to the journal, and who sit on senate, and will remember this when the computing service budget comes up next month? What this really points to is that the maintenance tools for managing IP addresses on a LAN are inadequate for such an exercise, and too few of us use them anway. I would like to move to using appropriate tools asap since I anticipate at least one such address reallocation before IPv7. A BOOTP service might give us some of what we need, but I'm not sure it gives all. Such address management services for IPv7 are vital, I think. Denis From owner-Big-Internet@munnari.oz.au Thu Oct 22 23:58:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28902; Thu, 22 Oct 1992 23:58:30 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210221358.28902@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28892; Thu, 22 Oct 1992 23:58:22 +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, 22 Oct 1992 14:58:05 +0100 To: Denis.Russell@newcastle.ac.uk Cc: Big-Internet@munnari.oz.au Subject: Re: buying time by reconfiguration In-Reply-To: Your message of "Thu, 22 Oct 92 14:52:06 BST." <199210221352.AA11287@cheviot.ncl.ac.uk> Date: Thu, 22 Oct 92 14:58:03 +0100 From: Jon Crowcroft >>I'm gonna ask the UK IP Network managers if it is possible to >Of course it is possible - a better question is how much it would cost. >However, given a cost, how would you evaluate the cost? well - i meant "consider-worthy":-) >>reallocate all IP addresses in the UK in way that would allow a single >>UK classless net announcement - there's only 50,000 odd machines >>registered in DNS, and most are unix boxes - it oughta be relatively >I've disagreed with Jon about this before. Most DNS machines are NOT Unix >machines. Our site has maybe 3 times as many connected PCs and Macs as Unix >workstations. Maybe UCL is richer than us. :-) sure, but our PCs are still (in fact more often_) rarp and DNS based... >Updating the routers is peanuts. Who is going to trudge round campus and >all the remote sites and update all our hosts (i.e. PCs)? Who is going to >handle the phone-calls from the >real-users-who-don't-give-a-damn-about-protocols, but whose PC/Mac stopped >working on Sunday afternoon when they were trying to submit that late paper >to the journal, and who sit on senate, and will remember this when the >computing service budget comes up next month? give them an answer phone message anyhow, let me point peopel at an article in the (UK) IEE Review - the whol;e of the UK phone numbering system is gonna change in 1995 - its do-able! >What this really points to is that the maintenance tools for managing IP >addresses on a LAN are inadequate for such an exercise, and too few of us >use them anway. I would like to move to using appropriate tools asap since >I anticipate at least one such address reallocation before IPv7. A BOOTP >service might give us some of what we need, but I'm not sure it gives all. >Such address management services for IPv7 are vital, I think. that is really waht i spose i should have bneen getrting at Who is gonna FUND the production of GOOD migration tools? thanks for teasing that out! jon From owner-Big-Internet@munnari.oz.au Fri Oct 23 00:54:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01913; Fri, 23 Oct 1992 00:54:19 +1000 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01906; Fri, 23 Oct 1992 00:54:08 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA16857; Thu, 22 Oct 92 07:54:01 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA22785; Thu, 22 Oct 92 10:54:00 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA10418; Thu, 22 Oct 92 10:51:39 EDT Date: Thu, 22 Oct 92 10:51:39 EDT From: Frank T Solensky Message-Id: <9210221451.AA10418@fenway.andr.UB.com> To: Big-Internet@munnari.oz.au, Denis.Russell@ncl.ac.uk, J.Crowcroft@cs.ucl.ac.uk Subject: Re: buying time by reconfiguration >What this really points to is that the maintenance tools for managing IP >addresses on a LAN are inadequate for such an exercise, and too few of us >use them anway. I would like to move to using appropriate tools asap since >I anticipate at least one such address reallocation before IPv7. A BOOTP >service might give us some of what we need, but I'm not sure it gives all. >Such address management services for IPv7 are vital, I think. One ma^H^Hperson's maintenance tool is another person's security hole... I'd prefer IPAE's approach of allowing some degree of co-existance of IPv4 and IPv7 addresses so that one can make transitions at a locally determined time. -- Frank Solensky From owner-Big-Internet@munnari.oz.au Fri Oct 23 01:10:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02503; Fri, 23 Oct 1992 01:10:37 +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 AA02500; Fri, 23 Oct 1992 01:10:23 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA13490; Thu, 22 Oct 92 08:10:17 -0700 Received: by us1rmc.bb.dec.com; id AA06300; Thu, 22 Oct 92 11:07:45 -0400 Message-Id: <9210221507.AA06300@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Thu, 22 Oct 92 11:07:46 EDT Date: Thu, 22 Oct 92 11:07:46 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 22-Oct-1992 1110" To: ericf@atc.boeing.com Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, ericf@atc.boeing.com Subject: RE: IETF at Crossroads Eric, Yeah, life's a bitch and it would be nice if there were trivial solutions to its problems. But it's more complicated than that. There is really almost no point in "adopting CLNP" unless it is vanilla CLNP under the control of OSI/ISO. So far OSI/ISO has show itself (despite being composed on many very competant people) to be an inferior and enormously slow and cumbersome standards developer. The IETF has show itself to be the best currently existing system for producing real working open network standards in a reasonable length of time. Vanilla CLNP is a six year old clone (with bigger addresses) of IP4, a few improvements, and a larger number of added deficiencies (see my message commenting on the IAB Kobe draft). It doesn't do a thing to help with security, flow reservations, etc., etc. I just see no gain from trying to go to the overall inferior CLNP to gain bigger addresses and lose the enormous benefits of IETF change control. On the other hand, if you go with modified CLNP under the IETF, it is not at all clear that you gain much interoperability. Once you are disconnected from vanilla CLNP, you obviously want to modify it to be closly compatibly with IP4, the widely deployed world open networking standard. If you wanted to be compatible with the small amount of CLNP out there, you wouldn't have changed from vanilla CLNP in the first place. From the logic in your message, no new low level protocols would ever have been designed or adopted. Yet it sure seems to me that AppleTalk, for example, has added a lot of good new ideas to the networking arena and is very widely deployed. I certainly think IP7 can be a real improvement over all existing protocols in providing support for real new features, as well as being reasonably compatible with IP4 (the current world standard), and being maintained and developed in an expeditious manner by being under IETF control. Donald From owner-big-internet@munnari.oz.au Fri Oct 23 01:35:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03592; Fri, 23 Oct 1992 01:36:00 +1000 (from owner-big-internet) Return-Path: Received: from cheviot.ncl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27530; Thu, 22 Oct 1992 23:18:22 +1000 (from Denis.Russell@ncl.ac.uk) Received: from [128.240.2.201] (pudding.ncl.ac.uk) by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Thu, 22 Oct 1992 14:18:13 +0100 Date: Thu, 22 Oct 1992 14:18:13 +0100 Message-Id: <199210221318.AA09126@cheviot.ncl.ac.uk> To: Big-Internet@munnari.OZ.AU From: Denis.Russell@ncl.ac.uk X-Sender: ndmr@eata.ncl.ac.uk Subject: Re: IETF at Crossroads At 10:47 am 22/10/92 +0100, Jon Crowcroft wrote: >okay fine - who is going to bundle CLNP free for my 250 departmental >machinews, 4000 college machines ,and 5000 JIPS machines? Cost was a major factor that pushed UK universities on their LANS towards TCP/IP and away (or not towards) ISO. Closely related was the availability of TCP/IP. Use of TCP/IP on LANS was, later, a major factor in the push for the Internet. >anyhow, the last UK rare networking meeting ,it was clear to me at >least that the world is becoming religuiously multi-protocol, NOT >converging Yes! >but whatever we move to it better accomodate USER REQUIREMENTS - the >sw3itch to IP in the UK was achieveed becuase uers wanted NFS and X, >not becuase they wanted IP instead of X.25 ... >in my opinion... I agree completely that it was and is user requirements that has driven the UK Academic and research Community to using IP. I disagree with Jon about the actual protocols, but that is not the point. The real point is that the USERS want SERVICES. They don't know, and don't want to know anything about protocols. What my users see is that they can now roam the Internet freely from their desks, whereas previously they needed an exit visa to visit foreign lands. In this we are not really different from Boeing - both Academics and Businessmen want services of the maximum functionality and minimum cost. As an esteemed colleague put it recently "Bugger the protocols, my users want services!" We loose sight of this at our peril. (NB I am wearing my Computing Service hat and ignoring the small number of Computing Science Academics - including myself with another hat on - who are interested in the protocols themselves.) However, the question that has arisen is whether this means we must move to CLNP. Despite seeing endless messages about this recently, I still don't know (Typical for an "academic", I guess :-) The main argument for CLNP rather than one of the other more conservative candidate protocols seems to be that "there is an existing installed base of CLNP hardware and experience". That sounds really impressive. However, within the UK JANET-IP community, we thought that a pilot CLNP project would be a pretty neat and foresightful thing to do. We looked at our routers, and decided that, yes, the manual had a section on routing CLNP, etc, etc. Looks good! They we wondered what we could use for end-systems. Er, um. Well, some sites said they had a few, but I guess at my installation, they could be counted on the fingers of one hand (well, thumb, actually). We seem to have lost a bit of steam since then. (We have several tens of machines with "ISO CONS" - but that's another story. :-) So, I'm not yet convinced by this installed base argument. A host implementation of any of the contending network protocols that is not completely brain-damaged, that was freely available (i.e. source code, no cost), installable and installed in Unix, PCs, Macs, was comparable to IP in terms of all the usual measures (performance, size, etc) would presumably be reasonably easy, and would completely erase any advantage that CLNP has. Bet the router folks wouldn't ignore such an event. Denis. (Of course, if that implementation was of CLNP itself...) From owner-Big-Internet@munnari.oz.au Fri Oct 23 01:41:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03787; Fri, 23 Oct 1992 01:41:36 +1000 (from owner-Big-Internet) Return-Path: Received: from atc.boeing.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03784; Fri, 23 Oct 1992 01:41:28 +1000 (from ericf@atc.boeing.com) Received: by atc.boeing.com (5.57) id AA07731; Thu, 22 Oct 92 08:41:35 PDT Date: Thu, 22 Oct 92 08:41:35 PDT From: Eric Fleischman Message-Id: <9210221541.AA07731@atc.boeing.com> To: Big-Internet@munnari.oz.au, tuba@lanl.gov Subject: re: re: Crossroads I would like to respond to three points from two different replies to my "IPv7 may be the IETF's Rubicon" note: > Well, we can do without your company quite well, thank you. And > you'll come around soon enough if all your vendors start charging you > more for IPv4 products and connectivity... We are interested in obtaining a viable long term IPv7 solution for the Internet community. Since we are part of the Internet's problem, we would also like to be a part of the Internet's solution. Therefore, please choose a solution which we will be able to support. This is not a question of desire, it is a question of ability. > Not a chance. Read the IETF and Big-I archives about the reasons why > ``straight CLNP'' is an unacceptable solution to the ROAD problem. My personal opinion is that some of the points which were made are valid. I see no option to be easy or without its risks. In fact, because "Murphy was an optimist", I suspect that all of the problems probably have not yet been identified. Having said this, however, I wish to state that a certain percentage of those points are false and represent misunderstandings on the part of the authors. Also, many of those comments are in a domain I classify as "religious". > Personally, if I take > the list, I'd rank priorities in the following way: > (1) users want open systems that work for them and free them from > vendor dependence; > (2) migrations hurt, and some folks never migrate; > (3) people don't want yet another protocol (YAP); > (4) there exist some CLNP implementations already deployed; This list may very well represent the priorities of important segments of the Internet community. However, the points which I was trying to make are the following: 1) A long-term IPv7 solution implies yet another migration motivated by outside forces which we are being asked to bankroll or else face the conversion of our extensive TCP/IP installed base into "legacy systems". 2) I believe that because of the size of the world-wide TCP/IP deployment (i.e., a huge inertia), unless IPv7 will partially satisfy the internal business needs of the TCP/IP installed base in addition to the external needs of the Internet, it will be largely ignored by the community. 3) A Yet Another Protocol (YAP) solution is contrary to (powerful) major market forces which Industry dare not ignore. A YAP solution is also contrary to our corporate network policy. 4) A CLNP-based solution is consistent with major market forces and harmonious with our corporate networking policy. It also offers alternatives which satisfy real internal business needs. 5) Of the proposed long-term IPv7 solutions, only the CLNP-based alternative is viable from a business perspective. This is because it is the only identifed option which meets both internal and external business needs. --Eric Fleischman From owner-big-internet@munnari.oz.au Fri Oct 23 01:48:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04069; Fri, 23 Oct 1992 01:48:27 +1000 (from owner-big-internet) Return-Path: Received: from v6.ph.ox.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28322; Thu, 22 Oct 1992 23:40:53 +1000 (from macallstr@v6.ph.ox.ac.uk) Received: by v6.ph.ox.ac.uk (MX V3.1) id 173; Thu, 22 Oct 1992 14:41:26 BST Sender: Date: Thu, 22 Oct 1992 14:41:19 BST From: John Macallister To: internet"Big-Internet@munnari.OZ.AU"@v6.ph.ox.ac.uk Cc: macallstr@v6.ph.ox.ac.uk Message-Id: <009627A0.7FC3FE00.173@v6.ph.ox.ac.uk> Subject: Address Space and number of nodes. Before planning any changes to the current address allocations some thought must be given to the number of nodes/addressable entities which will exist in the future. In the short to medium term it's very likely that every professional working person will have a workstation of some description. Extended this to the population at large (home computers, electricty companies, banking, home shopping, commercial home entertainment,etc). While some networks may be closed systems it would be very short-sighted indeed not to allow for the possibility of intercommunication. Allow, too, for the many shared facilities which will exist at places of work, in public areas, etc. Services will not be uniformly distributed: if addresses are allocated in blocks there will of necessity be many unused addresses, partly to allow for expansion of course. From this it is clear that the MINIMUM sensible estimate of the number of addresses required for, say, the UK will be n x 60million. n should at least be 10 ( and probably much larger ) to avoid a massive renumbering scheme. If anyone has any doubts about this, consider the public telephone network in the UK which has 9-10 digit numbers i.e. a total of 10billion numbers in a population of 60million i.e. n = 167 for this network and already there is a need to extend the address range because numbers are not uniformly distributed around the country. I think the message is clear: BBBBIIIIIIIGGGGGG address spaces are necessary. Any scheme which suggests allocating a few tens of thousands of addresses for the country is lacking in foresight. In Internet terms, we need Class F now. But the real solution is to move to OSI addressing - without losing the functionality of the Internet protocols. John +-------------------+ | ( ) ( ) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Name : John B. Macallister | | Postal address : Nuclear Physics Laboratory, Keble Road, Oxford OX1 3RH, UK.| | Telephone : +44-865-273388 (direct) +44-865-273333 (tel reception) | | Telex/Fax : Telex: 83295 NUCLOX G Fax: +44-865-273418 | | UK JANET : MACALLSTR @ UK.AC.OX.PH (DTE:000050250060,IXI:204334505211)| | UUCP/USENET : MACALLSTR @ oxphv1 | | HEPNET/SPAN : MACALLSTR @ OXPHV1 (Node 19.151) ! | INTERNET : macallstr @ v1.ph.ox.ac.uk ( 129.67.1.100 ) ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ From owner-Big-Internet@munnari.oz.au Fri Oct 23 02:16:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05013; Fri, 23 Oct 1992 02:16: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 AA05006; Fri, 23 Oct 1992 02:16:10 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08308; Thu, 22 Oct 92 12:16:00 -0400 Date: Thu, 22 Oct 92 12:16:00 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210221616.AA08308@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au, J.Crowcroft@cs.ucl.ac.uk Subject: Re: buying time by reconfiguration Cc: jnc@ginger.lcs.mit.edu it oughta be relatively simple to provide some xscripts that do DNS and NIS and SNP to all the ciscocs and other routers to do this in a weekend Jon, why do we have to do it in a weekend? Why not do it in stages, like this: i) allocate new addresses to all networks, etc ii) update routers to have their new addresses as extra addresses on all their intefaces (all major router vendors support this, as far as I know) iii) get the routing working to all the new addresses iv) slowly, incrementally, change all the hosts to their new addresses; this can be spread out since unconverted hosts will still talk to converted ones via the routers, albeit at a slight performance penalty v) remove old addresses from routers, stop advertising them to the routing vi) if you're sure they will never return, turn old addresses back in to the NIC This avoids a massive flag day, which we all know is a Bad Thing. Noel From owner-big-internet@munnari.oz.au Fri Oct 23 03:07:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06485; Fri, 23 Oct 1992 03:07:43 +1000 (from owner-big-internet) Return-Path: Message-Id: <9210221707.6485@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05853; Fri, 23 Oct 1992 02:41:51 +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, 22 Oct 1992 17:41:14 +0100 To: Frank T Solensky Cc: Big-Internet@munnari.oz.au Subject: Re: buying time by reconfiguration In-Reply-To: Your message of "Thu, 22 Oct 92 10:51:39 EDT." <9210221451.AA10418@fenway.andr.UB.com> Date: Thu, 22 Oct 92 17:41:07 +0100 From: Jon Crowcroft >>Such address management services for IPv7 are vital, I think. >One ma^H^Hperson's maintenance tool is another person's security hole... that is a very good point - thanks for the check&balance! jon From owner-big-internet@munnari.oz.au Fri Oct 23 03:21:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06825; Fri, 23 Oct 1992 03:21:16 +1000 (from owner-big-internet) Return-Path: Received: from ns0.ja.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05865; Fri, 23 Oct 1992 02:43:05 +1000 (from T.Bates@nosc.ja.net) Received: from nosc.ja.net by nosc.ja.net with Internet SMTP id ; Thu, 22 Oct 1992 17:44:55 +0100 Received: by nosc.ja.net (4.1/TB-1.0) id AA00854; Thu, 22 Oct 92 17:42:08 BST From: tony@nosc.ja.net (Tony Bates) Message-Id: <9210221642.AA00854@nosc.ja.net> Subject: Re: buying time by reconfiguration To: J.Crowcroft@cs.ucl.ac.uk Date: Thu, 22 Oct 1992 17:42:07 +0100 (BST) Cc: Big-Internet@munnari.oz.au X-Organisation: University of London Computer Centre, Networks Group X-Phone: +44 71 405 8400 X-Fax: +44 71 242 1845 Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Length: 1641 > Just how hard would it be to get some CIDR aggregation in some > existing places? > > I'm gonna ask the UK IP Network managers if it is possible to > reallocate all IP addresses in the UK in way that would allow a single > UK classless net announcement - there's only 50,000 odd machines > registered in DNS, and most are unix boxes - it oughta be relatively > simple to provide some xscripts that do DNS and NIS and SNP to all the > ciscocs and other routers to do this in a weekend ... given it only > took a round a year to install them all from nothing... > Well as the man at the routing sharp end (so to speak) on all this I would also like to see this although I very much doubt it will actually happen. Although it only took a year for us to get this done some of us have had local stuff for years of course. We of course allocate all new UK addresses in a CIDR scheme so we are already starting to sort this out. How's about UCL-CS (128.16.0.0) re-numbering over a weekend as a start. I've got a nice block ready if you want to ? > before embarking on this unpopular path, can someone remind me how > much we would gain (in addr space + router table exhaustion) > if all regionals did similar (i regard the JIPS net > as roughly equiv. to a regional.)? > ANS/Merit have already done some work on how much aggregation regionals would give today and I believe it is quite a lot in some places (not very helpful I know but I don't have any figures). However, if we look at the UK JIPS regional it would be a very small amount of aggregation indeed as almost all Universities had Class B's way before JIPS. > cheers > j > From owner-Big-Internet@munnari.oz.au Fri Oct 23 04:24:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08327; Fri, 23 Oct 1992 04: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 AA08320; Fri, 23 Oct 1992 04:24:42 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10345; Thu, 22 Oct 92 14:24:37 -0400 Date: Thu, 22 Oct 92 14:24:37 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210221824.AA10345@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au Subject: Re: Address Space and number of nodes. Cc: jnc@ginger.lcs.mit.edu, macallstr@v6.ph.ox.ac.uk But the real solution is to move to OSI addressing I agreed with everything you said until I got to this statement. Can you fill in the chain of reasoning which leads you to conclude that OSI addressing (by which I take it you mean NSAP's and AFI's and all that) is the best solution to the problems you outlined? Noel From owner-Big-Internet@munnari.oz.au Fri Oct 23 04:43:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08957; Fri, 23 Oct 1992 04:43:26 +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 AA08954; Fri, 23 Oct 1992 04:43:09 +1000 (from tracym@bridge2.NSD.3Com.COM) Received: from remmel.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA03375 (5.65c/IDA-1.4.4nsd for ); Thu, 22 Oct 1992 11:42:54 -0700 Received: from localhost.NSD.3Com.COM by remmel.NSD.3Com.COM with SMTP id AA04328 (5.65c/IDA-1.4.4-910725); Thu, 22 Oct 1992 11:42:53 -0700 Message-Id: <199210221842.AA04328@remmel.NSD.3Com.COM> To: Eric Fleischman Cc: Big-Internet@munnari.OZ.AU, tuba@lanl.gov Subject: Re: IETF at Crossroads In-Reply-To: Your message of "Wed, 21 Oct 92 12:09:44 PDT." <9210211909.AA04461@atc.boeing.com> Date: Thu, 22 Oct 92 11:42:52 -0700 From: tracym@NSD.3Com.COM [I wrote this yesterday. I rewrote it yesterday. I've rewritten it again after an hour of reading. The basic content remains the same, with only a small flame still burning.] Eric, It's very hard to argue with your message, and even likely that your point that any IPv7 different from CLNP will probably help to drive the commercial networking community faster toward vanilla OSI. I am pretty much resigned to it. However,.. If for no other reason, I am interested in other-than-OSI solutions to assuage the implicit guilt associated with accepting CLNP/TP4. "We put up a good, but much too late, fight" may be heard from many of today's authors of tomorrow's networking textbooks. I will try to add a tiny bit more technical detail. The main point: CLNP is not well suited to high speed performance use except by fairly special hardware. From a purely performance point-of-view, it cannot be as cost-effective as solutions designed to make better use of cpu and other resources. The proponents of non-CLNP IPv7's are, in part, concerned with trying to achieve exceptional performance from off-the-shelf hardware and/or software. The folks designing CLNP/TP4/etc. apparently had no inkling of the shape of things to come (especially cpu/memory hardware), or were too caught up with "we don't specify how you implement it, only what" to care. (Main flame off :-) The Fletcher Checksum: It takes special dedicated hardware to handle a Fletcher checksum more than a byte at a time, which, for instance, you might want to do when approaching 1Gbps (622Mbps ATM UNI, 800Mbps HPPI, etc.). You just CAN't do it more than a byte at a time in software. The Fletcher checksum also makes TP4 performance somewhat problematic. It's been pointed out that it can be optionally not used, but ?!?! (I've just been told that it is generally not used in TP4.) Word Alignment: CLNP (if word alignment was ever considered) was designed for an odd length LLC header without serious regard for coexistence with other protocols. But more importantly, CLNP was designed for byte-oriented processing. [In this regard, it is already 10-years old and should be headed for retirement rather than just now being widely deployed.] Variable Length and Long Addresses I don't have as much problem with variable length addresses, per se, except for the alignment issues. I suggested months ago that optimized header layouts could be used in many cases to help improve performance without excessive hardware investment. But given a pair of arbitrary source/destination addresses, it is not possible to guarantee alignment of the segmentation option in a CLNP header. Since the current implementor's agreements require the presence of the segmentation option, this bit of code will always require some special casing. The other options can be aligned through the use of nop's. I'm somewhat pessimistic about the performance of the next-generation Internet if we are constrained by CLNP's deficiencies. I feel that the requirement for special, expensive (at least to design), hardware solutions to basic packet forwarding violates the KISS principle. Tracy Mallory 3Com Corporation The opinions expressed above are personal. From owner-Big-Internet@munnari.oz.au Fri Oct 23 05:19:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09917; Fri, 23 Oct 1992 05:20:08 +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 AA09898; Fri, 23 Oct 1992 05:19:39 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA08419; Thu, 22 Oct 92 15:19:24 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA13690; Thu, 22 Oct 92 12:17:59 PDT Message-Id: <9210221917.AA13690@aland.bbn.com> To: tracym@nsd.3com.com Cc: Eric Fleischman Cc: Big-Internet@munnari.oz.au, tuba@lanl.gov Subject: Fletcher checksum From: Craig Partridge Date: Thu, 22 Oct 92 12:17:58 -0700 Sender: craig@aland.bbn.com > It takes special dedicated hardware to handle a Fletcher checksum more > than a byte at a time. Hi Tracy: I used to think this was true too but it isn't. You can do the Fletcher sum in 16-bit chunks (see Keith Sklower's paper in CCR, Oct '89). There are also tricks for selectively updating individual bytes ala the way one selectively updates the checksum in the IP header (Tassos Nakassis has a paper on this in Fall '88 CCR). Craig From owner-Big-Internet@munnari.oz.au Fri Oct 23 05:59:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11142; Fri, 23 Oct 1992 06:00:09 +1000 (from owner-Big-Internet) Return-Path: Received: from dg-rtp.rtp.dg.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11121; Fri, 23 Oct 1992 05:59:50 +1000 (from throop@dg-rtp.dg.com) Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4.1/dg-rtp-proto) id AA01952; Thu, 22 Oct 1992 15:59:06 -0400 Received: by walrus (5.4.1/140.2) id AA22207; Thu, 22 Oct 1992 15:56:28 -0400 Date: Thu, 22 Oct 1992 15:56:28 -0400 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9210221956.AA22207@walrus> To: jnc@ginger.lcs.mit.edu, Big-Internet@munnari.oz.au Subject: Re: buying time by reconfiguration Changing IP addresses while maintaining service would be almost impossible. The routers are the easy part. The have all sorts of capabilities to handle strange things and they are only configured by the network people. The hard part is your point iv) changing the addresses of the end hosts. How do you change the address of an end node on the network? Most end node machines don't support multiple IP addresses from different networks on a single interface. This means the hosts have to jump from old address to new address. Changing the address of an interface is the easy part. Most hosts have small /etc/hosts files which they use to boot themselves up to where then can use YP or DNS. So include changing all these files in the process. Next there are configuration files all over the place that allow access based on IP address. X windows allows access based on source host. NFS uses the IP address to validate mounts. You can't just change the IP address of a machine you have to change all the servers that give it service. For NFS the exports file will have to be changed to allow mounts from the new address. Different people configure X differently. Some workstations would have to change a configuration file, other people use shell scripts to dynamically add hosts to the trusted list. While most entries in these configuration files use names, they could just as easily contain IP address. Even magically getting all the above won't handle everying. I've seen personal shell scripts with IP addresses hard coded into them (yes some of them I wrote myself :-). Changing IP addresses would be seen as a big impact by the users and they wouldn't see any benefit. They see a working system right now. Why should they spend a couple of week finding all the places where IP addresses are stored and change them? They don't deal with routing table sizes. That not an issue they understand. > From owner-Big-Internet@munnari.oz.au Thu Oct 22 14:18:13 1992 > Date: Thu, 22 Oct 92 12:16:00 -0400 > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Message-Id: <9210221616.AA08308@ginger.lcs.mit.edu> > To: Big-Internet@munnari.oz.au, J.Crowcroft@cs.ucl.ac.uk > Subject: Re: buying time by reconfiguration > Cc: jnc@ginger.lcs.mit.edu > > it oughta be relatively simple to provide some xscripts that do DNS and > NIS and SNP to all the ciscocs and other routers to do this in a weekend > > Jon, why do we have to do it in a weekend? Why not do it in stages, like > this: > > i) allocate new addresses to all networks, etc > > ii) update routers to have their new addresses as extra addresses on all > their intefaces (all major router vendors support this, as far as I know) > > iii) get the routing working to all the new addresses > > iv) slowly, incrementally, change all the hosts to their new addresses; this > can be spread out since unconverted hosts will still talk to converted ones > via the routers, albeit at a slight performance penalty > > v) remove old addresses from routers, stop advertising them to the routing > > vi) if you're sure they will never return, turn old addresses back in to the > NIC > > This avoids a massive flag day, which we all know is a Bad Thing. > > Noel Dean Throop throop@dg-rtp.dg.com From owner-Big-Internet@munnari.oz.au Fri Oct 23 08:14:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17350; Fri, 23 Oct 1992 08:14:14 +1000 (from owner-Big-Internet) Return-Path: Received: from timbuk.cray.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17347; Fri, 23 Oct 1992 08:14:04 +1000 (from dab@berserkly.cray.com) Received: from handel.cray.com.cray.com by cray.com (4.1/CRI-MX 2.2) id AA02200; Thu, 22 Oct 92 17:13:57 CDT Received: by handel.cray.com.cray.com id AA11833; 5.65/CRI-5.5; Thu, 22 Oct 1992 17:12:28 -0500 Date: Thu, 22 Oct 1992 17:12:28 -0500 From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9210222212.AA11833@handel.cray.com.cray.com> To: ericf@atc.boeing.com, tracym@NSD.3Com.COM Subject: Re: IETF at Crossroads Cc: Big-Internet@munnari.OZ.AU, tuba@lanl.gov Tracy Mallory writes: > It takes special dedicated hardware to handle a Fletcher checksum more > than a byte at a time, which, for instance, you might want to do when > approaching 1Gbps (622Mbps ATM UNI, 800Mbps HPPI, etc.). You just > CAN't do it more than a byte at a time in software. The Fletcher > checksum also makes TP4 performance somewhat problematic. It's been > pointed out that it can be optionally not used, but ?!?! (I've just > been told that it is generally not used in TP4.) Sorry, I can't resist. At Cray Research we have a word oriented, vectorized version of the Fletch checksum in our ISO code (the BSD ISO code). I've been told that the vectorized version is substantially faster than the word oriented version, and the word oriented version is faster than the byte oriented version in BSD. I've also been told that the person who did it modified the Fletcher algorithm to allow a faster implementation, yet still produce the same results. I can get specific numbers and details if people are interested... But don't get me wrong, our vectorized IP/TCP checksum will always be faster! ;-). -David Borman, dab@cray.com From owner-Big-Internet@munnari.oz.au Fri Oct 23 10:55:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24746; Fri, 23 Oct 1992 10:56:05 +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 AA24728; Fri, 23 Oct 1992 10:55:27 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA12221; Thu, 22 Oct 92 20:54:52 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA08439; Thu, 22 Oct 92 17:53:14 PDT Message-Id: <9210230053.AA08439@aland.bbn.com> To: big-internet@munnari.oz.au Subject: Criteria for selecting IPv7 Reply-To: Craig Partridge From: Craig Partridge Date: Thu, 22 Oct 92 17:53:13 -0700 Sender: craig@aland.bbn.com Hi folks: After some discussion with folks on the TUBA list and a re-reading of the IESG Deliberations on Routing and Addressing, I think we're going to have problems setting the IPv7 debate unless we get much more concrete about the criteria for deciding on a protocol. I was struck a few years ago by Dave Clark's paper at SIGCOMM '88 where he pointed out that the design of TCP/IP was guided, in large part, by an *ordered* list of requirements. I think we might benefit from a similar ordered list. The IESG report doesn't contain such a list, so here I'm proposing a draft of one. For each point, I've noted in brackets [] why the point matters, and why I've placed it below/above its neighbors. I'll suggest that the quality of a solution might be measured by how low on the list it gets before it has to skip or kludge through a point... Comments welcome (including ones that say this is a dumb idea). Craig =============================================================================== 1. The protocol must allow a straightforward transition plan from the current IPv4. [If we can't transition to the new protocol, then no matter how wonderful it is, we'll never get to it.] 2. The protocol must scale to allow the addressing of billions of end-systems. [If we cannot address all hosts in some fashion, presumably we cannot connect them all to the network, and we cannot hope to route data to them.] 3. The protocol must permit the use of routing schemes which allow routing tables to grow at a rate much less than linearly with the number of constituent networks. [If we can't route then connecting all those hosts is worthless, but without connected hosts, there's no point in routing. Thus this is third.] (As a rough sanity check for any scheme, assume that an inexpensive router [costing $5K 1992 USD] in the year 2000 will have around 1 gigabyte of router table memory and at that time there will be about 2 million networks and 75 million end-systems). 4. The protocol must work across an internetwork with individual link speeds ranging from a few kilobits per second to hundreds of gigabits per second. By work, we mean we have hopes that it can come close to filling the link at high speeds, but scales gracefully to deal with low speeds. [The joy of IP is that it works over just about anything. That ease of adding new technologies must be maintained. I believe this range of speed is right for the next twenty years, though it may be we should say terabits at the high-end]. 5. The protocol must support an unreliable datagram delivery service. [We like IP's datagram service and it seems to work very well. So let's keep it. But clearly it matters less than being able to get the data from here to there, which points 1-4 cover]. 6. The protocol must allow for both unicast and multicast addressing. [So far, we've done well with unicast and broadcast but broadcast scales far less well than multicast. We can fight about whether we should say "local" multicast, i.e. just on the local subnet here, and make wide-area multicast a lesser priority. Certainly the ability to send to more than one peer in a message has proved important. This is an enhancement to the datagram delivery service so it pre-supposes 5]. 7. The protocol must support some means for cost recovery. NOTE: this doesn't say billing. Just that commercial providers need to be able to puzzle out some way to charge for services. Charging based on leased-line rates, etc., as we do today, is OK. [If we don't have the right services, billing for them isn't useful, so this goes below the previous 6 points]. ****************************************************************************** I think there's an important break here. We go from essential points to strongly desired items. ****************************************************************************** 8. The protocol should support guaranteed flows. [Multimedia is on our desk top. The IETF multicast shows we can do it over internetworks, with some hitches. We must accept that multimedia is part of the networking future. If we better understood the problem, I'd put this about the starred line. Most folks believe that multicast delivery of flows is important, so it falls below multicast.] 9. The protocol should support mobile hosts. [Again, mobility is becoming increasingly important. Look at the portables that everyone is carrying. Note the strength of the Apple commercial showing someone automatically connecting up her Powerbook to her computer back in the office. I think conferencing and multimedia support from your regular office computer is more important than mobility, thus this falls after 8]. 10. The protocol should permit the use of security in the network. [This is not just for the military, but for banks, etc. And note all the folks who want to put security in for their local installations. Right now, I think the market values security slightly less than functionality, which is why it lands here]. 11. The protocol should permit easy and largely distribution configuration and operation. [People complain that IP is hard to manage. We cannot plug and play. It would be nice to fix that problem. But I think people care more about the previous 10 items] 12. The protocol should permit policy routing. [I'm most concerned with policy routing in the form of choosing carriers. We'd like to do it, and it would benefit the commercial community. But in the scheme of things, making life easier for local installations is probably more important than making life easy for carriers.] ************************************************************************** ************************************************************************** I quit at 12 because I felt the list was already getting too long. Thus, for example, I didn't include weak QOS. We haven't needed it (yes it would be nice, but we haven't suffered grievously without it, so let's not encumber ourselves with it as a requirement). Some comparison with the original list may be useful too. The original list had as first priority, continued function "despite loss of networks or gateways." We've actually historically made ourselves dependent on backbones and the like, so I didn't include this item. The second point was multiple types of service -- I think we've refined that idea, thus points 5,6,8, and 9. The third goal was accomodating a variety of networks (see point 4, and arguably 5, since datagrams seem to accomdate variety well). Fourth point was distributed management of its resources (see point 11). Fifth point was cost-effectiveness (I haven't included this). Sixth point was low cost attachment (see point 5 -- datagrams arguably make attachement easy). Seventh (and last point) was it must be accountable (see point 7). From owner-Big-Internet@munnari.oz.au Fri Oct 23 14:20:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04123; Fri, 23 Oct 1992 14:21:05 +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 AA04118; Fri, 23 Oct 1992 14:20:57 +1000 (from bill.simpson@um.cc.umich.edu) Received: from via.oak1.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA02800; Thu, 22 Oct 92 21:20:43 -0700 Date: Thu, 22 Oct 92 23:47:16 EDT From: "William Allen Simpson" Message-Id: <843.bill.simpson@um.cc.umich.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Security features There has been some mention that IP7 must have better security support, but no real discussion of requirements. This is a thread to get that started. There was a mini-BOF at the San Diego IETF, where it was suggested that IP security would be another rotocol number, which merely have an encrypted header section containing such sensitive information as the real protocol, port, TCP header, etc, plus all of the data. (I first heard this scheme from Phil Karn, who was attending.) This technique of encapsulation would fit well with IPAE and SIP, but might limit the security to machine to machine (end-point to end-point), rather than user to user or connection to connection. Might it not be better to include the port numbers in the IP7 header, to facilitate maintaining encryption by connection? Bill.Simpson@um.cc.umich.edu From owner-Big-Internet@munnari.oz.au Fri Oct 23 14:32:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04771; Fri, 23 Oct 1992 14:32:39 +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 AA04743; Fri, 23 Oct 1992 14:32:28 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA25280; Thu, 22 Oct 92 22:32:13 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA25616; Thu, 22 Oct 92 22:32:11 MDT Message-Id: <9210230432.AA25616@goshawk.lanl.gov> To: Big-Internet@munnari.OZ.AU, tuba@LANL.GOV Subject: Re: IETF at Crossroads In-Reply-To: Your message of Thu, 22 Oct 92 11:42:52 -0700. <199210221842.AA04328@remmel.NSD.3Com.COM> Date: Thu, 22 Oct 92 22:32:11 MST From: peter@goshawk.lanl.gov The discussions of CLNP performance remind me of discussions in prior decades such as: TCP/IP, too heavyweight for the LAN environment. TCP can not run at gigabit speeds. TCP is too heavyweight, so let's use UDP for NFS. The TCP checksum is too slow, it requires outboard protocol processing. The UDP checksum is too slow, so turn it off. [bad idea] A wide area network distributed database can't be used for something as important as hostname to address translation. I am not saying that CLNP is hunky dory. I am saying we do not have enough hard data to use the opinions currently being expressed on the B-I list to dismiss the use of CLNP in the Internet. TUBONs will have to provide data to the affirmative. This will take much more experience. I do think Tracy brings up several important points. For starters, in terms of using Fletcher over TP4 payloads, why not use TCP over CLNP as in the TUBA proposal? In terms of changing from Fletcher to the IP/TCP checksum, it seems to me that it might be worthwhile to feed this change back into the ISO standard, using the implementation experience of the Internet community to support the change. If some of these objections were made with some member of the Internet protocol suite, people would start talking about fixing the standard. Perhaps this attitude and style should be carried over to the ISO world. Successful strategies are often expansionist. cheers, peter From owner-Big-Internet@munnari.oz.au Fri Oct 23 16:58:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11185; Fri, 23 Oct 1992 16:58:30 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA11182; Fri, 23 Oct 1992 16:58:25 +1000 (from practic!brunner@uunet.uu.net) Received: from uunet.uu.net (via LOCALHOST.UU.NET) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA28814; Fri, 23 Oct 92 02:49:41 -0400 Received: from practic.UUCP by uunet.uu.net with UUCP/RMAIL (queueing-rmail) id 024319.529; Fri, 23 Oct 1992 02:43:19 EDT Received: from localhost by practic.practic.com (5.61/smail2.5/04-23-91) id AA08178; Thu, 22 Oct 92 13:56:23 -0700 Message-Id: <9210222056.AA08178@practic.practic.com> To: tracym@NSD.3Com.COM Cc: Eric Fleischman , Big-Internet@munnari.OZ.AU, tuba@lanl.gov, brunner@uunet.UU.NET Subject: Re: IETF at Crossroads In-Reply-To: Your message of "Thu, 22 Oct 92 11:42:52 PDT." <199210221842.AA04328@remmel.NSD.3Com.COM> Date: Thu, 22 Oct 92 13:56:20 PDT From: "practic!brunner@uunet.uu.net" Tracy, I doubt that the difference being discussed, or the accompaning issues of inter-organizational interaction, is a stronger driving factor for the commercial networking vendors than their installed base and other factors not "driven" by "standards". Rather than resulting in a "faster (drift) towards vanilly OSI", I suspect that defacto Balkenization will be the norm, leaving the non-ipv4-and-indigenous-successor(s) communities to do as they see fit, whether regionally or by vertical market segment. As a host/router implementor/vendor, I must make my choices with an open eye towards the P&L statement of the next quarter(s), and I believe that I (or rather, my clients), can easily accomidate a market comprised of several incompatible addressing schemes and services where little or no actual "interoperation" exists between nominally convergent technologies. Some part of the market for my products span the obvious regional and vertical market segments, but it is not my single largest common-interest customer (present or potential) base. The tomorrow's textbook today that I think more likely, is "How they do it over there", for several values of "there". W.R.T. Fletcher, have a look at Keith Sklower's work. From owner-Big-Internet@munnari.oz.au Fri Oct 23 17:48:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13518; Fri, 23 Oct 1992 17:48:59 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210230748.13518@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13513; Fri, 23 Oct 1992 17:48:50 +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 ; Fri, 23 Oct 1992 08:48:23 +0100 To: throop@dg-rtp.dg.com (Dean D. Throop) Cc: Big-Internet@munnari.oz.au Subject: Re: buying time by reconfiguration In-Reply-To: Your message of "Thu, 22 Oct 92 15:56:28 EDT." <9210221956.AA22207@walrus> Date: Fri, 23 Oct 92 08:48:17 +0100 From: Jon Crowcroft >The hard part is your point iv) changing the addresses of the end >hosts. How do you change the address of an end node on the network? rather easily, as it happens... >Most end node machines don't support multiple IP addresses from >different networks on a single interface. This means the hosts have >to jump from old address to new address. >access based on source host. NFS uses the IP address to validate >mounts. You can't just change the IP address of a machine you have most X and NFS do name lookupo to get addr, so you fix DNS/NIS and it comes out in the wash how many people do mount 10.1.3.3:/foo /bar or xterm -display 192.133.22.1:0.1 not too many, i hope... i mean thats one reason why mockapetris did DNS isnt it? to escape the tyranny of addresses... jon From owner-Big-Internet@munnari.oz.au Fri Oct 23 18:42:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15839; Fri, 23 Oct 1992 18:42: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 AA15833; Fri, 23 Oct 1992 18:42:13 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA20801; Fri, 23 Oct 1992 09:43:17 +0100 Message-Id: <199210230843.AA20801@mitsou.inria.fr> To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au Subject: Re: Security features In-Reply-To: Your message of "Thu, 22 Oct 92 23:47:16 EDT." <843.bill.simpson@um.cc.umich.edu> Date: Fri, 23 Oct 92 09:43:11 -0500 From: Christian Huitema X-Mts: smtp >There was a mini-BOF at the San Diego IETF, where it was suggested that >IP security would be another protocol number, which merely have an >encrypted header section containing such sensitive information as the >real protocol, port, TCP header, etc, plus all of the data. (I first >heard this scheme from Phil Karn, who was attending.) I think there is a risk if we equate "IP security" with "encryption". There is certainly a demand for confidential transfers and protection against flow analysis, but focusing on this let us carries the risk of focusing on heavyweight technologies and going directly into the export control wall. The first problem should be the mail bridge. How come that organization install mail bridges rather than IP relay? They get no data confidentiality, no protection against traffic analysis. What they do get is protection against foreign packets hitting random processes in their system, i.e. "hackers". The various "firewalls" based on filtering addresses and ports have the same "market". This is what we should address, and the key is probably "authentication" and "autorization". Christian Huitema From owner-Big-Internet@munnari.oz.au Fri Oct 23 21:00:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21050; Fri, 23 Oct 1992 21:01:13 +1000 (from owner-Big-Internet) Return-Path: Received: from kauai.mcl.unisys.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21040; Fri, 23 Oct 1992 21:00:56 +1000 (from perry@MCL.Unisys.COM) Received: by kauai.MCL.Unisys.COM (4.1/mls/3.2) id AA04113; Fri, 23 Oct 92 06:57:29 EDT Date: Fri, 23 Oct 92 06:57:29 EDT From: perry@MCL.Unisys.COM (Dennis Perry) Message-Id: <9210231057.AA04113@kauai.MCL.Unisys.COM> To: big-internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: Criteria for selecting IPv7 Cc: perry@mcl.unisys.com I would like to commend Craig for doing what should have been obvious from the first - start from the beginning! Systems Engineering 101 - what are the requirements. Given a list, are there gold plated ones in that list that can be ignored as wishful thinking, not real requirements. Cost drivers will also need to be taken in to account at some point in the future, but that gets into "trade" studies. Keep it comming, Craig!!! dennis From owner-Big-Internet@munnari.oz.au Sat Oct 24 00:21:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29652; Sat, 24 Oct 1992 00:21:47 +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 AA29648; Sat, 24 Oct 1992 00:21:32 +1000 (from jonson@server.af.mil) Received: by server.af.mil (5.59/25-eef) id AA01430; Fri, 23 Oct 92 09:18:08 CDT From: Matt Jonson Message-Id: <9210231418.AA01430@server.af.mil> Subject: Re: Day vs Chiappa re EID To: jnc@ginger.lcs.mit.edu Date: Fri, 23 Oct 92 9:18:05 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <9210211628.AA28232@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 21, 92 12:28 pm X-Mailer: ELM [version 2.3 PL11] > Subject: Re: Day vs Chiappa re EID > This is what you said before: >> non-topologically significant EID's. The latter implies that the routing has >> to track EID's, and we get no scaling, so this clearly will not work. The >> former has the problem that if you have a multi-homed host, you need to pick >> which interface to send to. Then I asked, referring to the case of the non-topologically significant EIDs: (n-tsEs)... > What about a case where n-tsEs (from above ;-)) are hierarchically managed > and a router doesn't make a choice unless it is in the same management > area as the end-system. Wouldn't that scale? You still end up with the > problem of routers tracking EIDs. > > I couldn't grasp this? What I was getting at was the scalability. Is it necessarily true that n-tsEs won't scale? True if they're flat, but true if they are hierarchically managed? just something off the cuff, but what if the n-tsE was the only info in the packet, given that it was hierarchically managed, and routers made decisions, instead of on topological path, on managerial path, until you get the packet to a router within the managerial domain that knows about the EID of the packet destination, which then starts doing the topological routing... I guess the only point to this kind of a concept would be to deal with multiply homed end-systems. Any thoughts, flames? /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 Any opinions expressed above are personal and don't represent the U.S Government From owner-Big-Internet@munnari.oz.au Sat Oct 24 00:39:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00867; Sat, 24 Oct 1992 00:39:26 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA00856; Sat, 24 Oct 1992 00:39:19 +1000 (from kasten@ftp.com) Received: from ftp.com (via babyoil.ftp.com) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA15637; Fri, 23 Oct 92 10:07:27 -0400 Received: by ftp.com id AA01607; Fri, 23 Oct 92 09:52:23 -0400 Date: Fri, 23 Oct 92 09:52:23 -0400 Message-Id: <9210231352.AA01607@ftp.com> To: desjardi@boa.gsfc.nasa.gov, big-internet@munnari.oz.au Subject: Protocol Transitions (was Re: concerns about CLNP) From: kasten@ftp.com (Frank Kastenholz) Reply-To: kasten@ftp.com Cc: jnc@ginger.lcs.mit.edu, tuba@lanl.gov Dick, (First, I've copied the big-i list on this since the topic is wandering more into general big-i issues and away from tuba-specific issues.) I think that having two protocol transitions in less than 10 years is a non-starter. It costs big dollars for vendors to learn about, develop, test, field, and support a brand new protocol. Even though we will have IPv7 in a year or so, I expect that we, the vendors, will still need to support IPv4 for many years after IPv7 is done. There will be places that won't or can't convert and we will have to support them. There will be lots of places that do not need IPv7 because they are not connected to the Internet (hard to believe, but true) and it will be difficult to convert them all over. To have to go through this effort TWICE when once could suffice is simply bad. I've said this before, I'll say it again, I'd rather keep the current IP and Internet Routing going for an extra year or two with whatever hacks, chewing gum and baling wire, prayers, sleepless nights, etc, then be constantly changing network layer protocols. We will have to live with IPv7 as the dominant network layer protocol for 10 years or more. We better be sure that it will do what we need. -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Sat Oct 24 00:40:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01029; Sat, 24 Oct 1992 00:40:59 +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 AA01018; Sat, 24 Oct 1992 00:40:46 +1000 (from jonson@server.af.mil) Received: by server.af.mil (5.59/25-eef) id AA03623; Fri, 23 Oct 92 09:38:13 CDT From: Matt Jonson Message-Id: <9210231438.AA03623@server.af.mil> Subject: Re: Day vs Chiappa re EID To: Garrett.Wollman@UVM.EDU Date: Fri, 23 Oct 92 9:38:03 CDT Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: <9210202153.AA16290@sadye.emba.uvm.edu>; from "Garrett.Wollman@UVM.EDU" at Oct 20, 92 5:53 pm X-Mailer: ELM [version 2.3 PL11] > Subject: Re: Day vs Chiappa re EID > > Well, one of the ideas that I have had is that, if a host's interface > goes dead, *AND* the router has some way of knowing it (e.g., some > sort of active communication that's not happing but should be), then > it can send back a *CMP ``Dest EID not available at this address'', > which would cause the *sending* host to re-compute the address. (The > router doesn't actually have to keep track of EIDs, only addresses, > but the The Best of All Worlds, I would have the ``route server'' and > packet-forwarding functions co-located, so it would have to know about > local EIDs anyway. CLNP routers can do this already, no?) I guess it depends on how you view the CLNP addresses and then actually implement the routing. In practice, would/can/does IS-IS map more than one SNPA to a single NSAP? How does a level two router deal with info from multiple level 1s that know about different SNPAs for the same NSAP? Please go private to me since this may be out of the bounds of big-internet. /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 Oct 24 01:05:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02327; Sat, 24 Oct 1992 01:05:47 +1000 (from owner-Big-Internet) Return-Path: Received: from ub-gate.UB.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02324; Sat, 24 Oct 1992 01:05:38 +1000 (from solensky@andr.UB.com) Received: from sunny.andr.UB.com (sunny.andr.UB.com) by ub-gate.UB.com (4.1/SMI-4.1[UB-1.8]) id AA22983; Fri, 23 Oct 92 08:05:30 PDT Received: from fenway.andr.UB.com by sunny.andr.UB.com (4.1/SMI-4.1) id AA24459; Fri, 23 Oct 92 11:05:27 EDT Received: by fenway.andr.UB.com (4.1/SMI-4.1) id AA11655; Fri, 23 Oct 92 11:03:04 EDT Date: Fri, 23 Oct 92 11:03:04 EDT From: Frank T Solensky Message-Id: <9210231503.AA11655@fenway.andr.UB.com> To: Big-Internet@munnari.OZ.AU, peter@goshawk.lanl.gov, tuba@LANL.GOV Subject: Fletcher transition (was Re: IETF at Crossroads) >From: peter@goshawk.lanl.gov > >... In terms of changing from Fletcher to >the IP/TCP checksum, it seems to me that it might be worthwhile to feed >this change back into the ISO standard, using the implementation >experience of the Internet community to support the change. > >If some of these objections were made with some member of the Internet >protocol suite, people would start talking about fixing the >standard. Perhaps this attitude and style should be carried over to >the ISO world. Successful strategies are often expansionist. > There's two basic points about TUBA that I've never been able to reconcile. On one hand, CLNP is an existing standard, so we're able to interoperate with an installed base. On the other, the standard can be changed based on operational experience. It seems to me that if one does convince ISO to change the standard, you'd then have to deal with making the installed base interoperable again: just as any proposed change to the Internet protocol suite would. Anyone have any ideas how this transition could be accomplished? Or has a proposal already been floated on the tuba list (in which case: could you summarize? I'd like to get onto the TUBA list also, but think that this might be of interest to the rest of us on Big-I but not yet on TUBA). -- Frank From owner-Big-Internet@munnari.oz.au Sat Oct 24 01:38:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03377; Sat, 24 Oct 1992 01:38:22 +1000 (from owner-Big-Internet) Return-Path: Received: from relay.hp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03371; Sat, 24 Oct 1992 01:38:17 +1000 (from eva@hpindda.cup.hp.com) Received: from hpindda.cup.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA27001; Fri, 23 Oct 92 08:38:08 -0700 Received: by hpindda.cup.hp.com (15.11/15.5+IOS 3.20+cup+OMrelay) id AA25767; Fri, 23 Oct 92 08:38:47 pdt From: Eva Kuiper Message-Id: <9210231538.AA25767@hpindda.cup.hp.com> Subject: Re: Fletcher transition (was Re: IETF at Crossroads) To: solensky@andr.UB.com Date: Fri, 23 Oct 92 8:38:44 PDT Cc: Big-Internet@munnari.OZ.AU, peter@goshawk.LANL.GOV, tuba@lanl.gov, eva@hpindda.cup.hp.com In-Reply-To: <9210231503.AA11655@fenway.andr.UB.com>; from "Frank T Solensky" at Oct 23, 92 11:03 am Mailer: Elm [revision: 64.9] > It seems to me that if one does convince ISO to change the standard, you'd > then have to deal with making the installed base interoperable again: just > as any proposed change to the Internet protocol suite would. The way this operates is through the Regional Workshops where the implementors meet regularly, just like the IETF, to make sure that the available implementors agreements reflect the current updates in the standards. This work is generally done in parallel with the work in the base standard so that when a standard reaches IS status the agreements are ready to go stable. It is these stable agreements that are used in the various procurement specs, such as GOSIP, IGOSS... Thus there is a known date when compliance is required. This means that ISO changes to CLNP could be rolled smoothly into the installed base. By the way, currently there are at least 19 conformance tested CLNP products listed in the US GOSIP Register for those who are wondering about the status of today's implementations. Eva > > Anyone have any ideas how this transition could be accomplished? Or has a > proposal already been floated on the tuba list (in which case: could you > summarize? I'd like to get onto the TUBA list also, but think that this > might be of interest to the rest of us on Big-I but not yet on TUBA). > > -- Frank > > From owner-Big-Internet@munnari.oz.au Sat Oct 24 02:20:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04907; Sat, 24 Oct 1992 02:20:48 +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 AA04885; Sat, 24 Oct 1992 02:20:36 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15724; Fri, 23 Oct 92 12:20:26 -0400 Date: Fri, 23 Oct 92 12:20:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210231620.AA15724@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, throop@dg-rtp.dg.com Subject: Re: buying time by reconfiguration Cc: jnc@ginger.lcs.mit.edu The hard part is your point iv) changing the addresses of the end hosts. ... Changing the address of an interface is the easy part. ... You can't just change the IP address of a machine you have to change all the servers that give it service. ... Even magically getting all the above won't handle everying. Changing IP addresses would be seen as a big impact by the users and they wouldn't see any benefit. They see a working system right now. Why should they spend a couple of week finding all the places where IP addresses are stored and change them? They don't deal with routing table sizes. That not an issue they understand. Hmm, let me see (in my role as 'advocatus diaboli' :-) if I can follow the reasoning here: Routing is about to break; we need CIDR to fix the routing; we need to change addresses to make CIDR work well; changing addresses is too hard relative to the benefit of fixed routing; therefor, addresses will not be changed. You could be right. People have speculated about this possibility; the system may just break up into pieces, or people may deploy NAT boxes to avoid having to change the addresses, etc. There's the question I want to ask: a number of the schemes discussed on this mailing list (TUBA particularly, but others [e.g. IPAE and SIP] are basically in the same boat, and I'm *not* picking on TUBA, just following a line of reasoning, and TUBA claims to do nothing much beyond provide larger addresses) have the characteristic that they *deploy a new packet format* to..... *fix the routing*! Lemma question: what's easier, changing the address on a host, or updating the host to a whole new software package to implement a new packet format? Question: If they won't go through the minor hassle of changing IP addresses to fix the routing as the system scales, are they going to go through the larger hassle of deploying a new packet format for this same goal? Darned if I know if people will change their addresses for CIDR. Maybe they will, and maybe they won't. One thing I *do* predict; if they won't change their addresses to fix the routing, they won't change to a new packet format unless it gives some major new capability, and the future is NAT boxes. (Hmm, time for a startup? :-) Noel From owner-Big-Internet@munnari.oz.au Sat Oct 24 02:23:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05131; Sat, 24 Oct 1992 02:23:41 +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 AA05090; Sat, 24 Oct 1992 02:23:30 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15772; Fri, 23 Oct 92 12:23:25 -0400 Date: Fri, 23 Oct 92 12:23:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210231623.AA15772@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu Subject: Cross posting to Big-I *and* TUBA Cc: Big-Internet@munnari.oz.au, tuba@lanl.gov Arrgh! Most of us are on both of these lists! Can we keep the mail volumedown, and post general stuff *just* to Big-I, and TUBA specific stuff (like Fletcher checksum stuff) *just* to TUBA? Thanks! Noel From owner-Big-Internet@munnari.oz.au Sat Oct 24 03:01:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06803; Sat, 24 Oct 1992 03:01:54 +1000 (from owner-Big-Internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06793; Sat, 24 Oct 1992 03:01:40 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA16122 (5.65c/UK-2.1-921001); Fri, 23 Oct 1992 13:03:05 -0400 From: Gary Scott Malkin Date: Fri, 23 Oct 1992 13:03:05 -0400 Message-Id: <16122.199210231703@atlas.xylogics.com> To: ietf@nri.reston.va.us, big-internet@munnari.oz.au Subject: Traceroute BOF Gentlebeings, I've scheduled a Traceroute BOF at the next IETF on Thursday from 7:30-10:00. As you know, there is an I-D available (draft-malkin-traceroute-00.txt). I've already added two new things to the ICMP message: Output Link Speed and Output Link MTU. I plan to submit a second draft next week. If there are any comments or suggestions, please get them to me by Wednesday 10/28 so that I can include them in the next draft. If you're planning to attend the BOF, please let me know so that I can give Megan an attendance estimate. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Sat Oct 24 03:12:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07028; Sat, 24 Oct 1992 03:13:16 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210231713.7028@munnari.oz.au> Received: from hadar.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07020; Sat, 24 Oct 1992 03:12:58 +1000 (from ULLMANN@PROCESS.COM) Date: Fri, 23 Oct 1992 13:11 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: general comment Hi, I've been on holiday for a few weeks (Dublin; very nice trip, thank you :-) and spent the week since reading the 800+ messages in my mailbox. I note a number of issues that I have opinions on. Fortunately for you, since I am the author of one of the drafts, I can spare you a replay if you will kindly read internet-drafts/draft-ullmann-ipv7-00.txt (available in the usual places). IMNSHO, the most important issue is than IPv7 must coexist with IPv4 so seamlessly that it seems at most a minor revision to most users _including_ most administrators. The migration period will be very long indeed; longer than IP has existed to date. (And remember the definition of "migration": a (usually seasonal) going and _returning_.) I can also state that more strongly in the negative: Regardless of what IPv7 _is_, if it is _perceived_ as anything other than a minor revision of IPv4, the war will be lost to CLNP. ---- One more observation. (I forget the name of the law, perhaps someone will remind me) _____'s Law: Any problem in systems design can be solved by an extra level of indirection. Ullmann's Commentary on _____'s Law: Any problem in systems design can be sufficently obfuscated by level(s) of indirection such that even the most knowledgable observers will not be able to show that the problem has not actually been solved. With my Best Regards, Robert Ullmann Process Software Corporation +1 508 879 6994 x226 From owner-Big-Internet@munnari.oz.au Sat Oct 24 03:43:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07900; Sat, 24 Oct 1992 03:43:57 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210231743.7900@munnari.oz.au> Received: from tengwar.itd.nrl.navy.mil by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07892; Sat, 24 Oct 1992 03:43:42 +1000 (from atkinson@tengwar.itd.nrl.navy.mil) Received: by tengwar.itd.nrl.navy.mil (16.8/16.2) id AA03582; Fri, 23 Oct 92 13:40:12 -0400 Date: Fri, 23 Oct 92 13:40:12 -0400 From: Ran Atkinson To: big-internet@munnari.oz.au Subject: Re: Security Features I believe we need to provide an option for authentication at the network layer. It is not at all clear to me that most sites need confidentiality at the network layer. It seems pretty clear that most non-military sites don't think they need confidentiality in the network layer or below. There might be some advantage to a confidentiality option at the transport layer just so that one can avoid having to rewrite each application to add confidentiality mechanisms. The tradeoff is that one is trusting the OS to protect the data confidentiality above the transport layer if the transport layer is the only place one implements a confidentiality option. We should try to talk in terms of desirable properties such as authentication, integrity, and confidentiality rather than talk in terms of "security" because the latter term is so broad as to be ambiguous in the context of email discussions. Ran atkinson@itd.nrl.navy.mil From owner-big-internet@munnari.oz.au Sat Oct 24 04:05:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08441; Sat, 24 Oct 1992 04:05: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 AA06139; Sat, 24 Oct 1992 02:36:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA15847; Fri, 23 Oct 92 12:36:47 -0400 Date: Fri, 23 Oct 92 12:36:47 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9210231636.AA15847@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: Criteria for selecting IPv7 Cc: jnc@ginger.lcs.mit.edu Craig: I think security (currently #10) ought to be about #2. The network just ain't never gonna get that big (current #2) unless it is securable (not secure, some people don't care, but many others do). Dave Clark has been pointing this out for years (starting at Interop some years back) after the worm. I think easy configuration (currently #11) ought to be #3, for pretty much the same reasons. If Joe Sixpack (or his/her distant cousin in Taiwan/ Slovakia/etc) can't set it up easily it ain't gonna get that big either. I'd bump the low end of the speed in #4 by a factor; 300 baud modems are pretty extinct now, and 1200 is only a few years away from the same fate. Plan for the future, *not* the present! I'm not sure I'd put policy routing as low as #12. Of course, it all depends on what you mean by policy routing; in some sense, gated tables, etc are policy routing. If you use that definition, people have already voted with their feet/money; they made commerical router vendors add this stuff long before they added multicast (#6). Of the old points, I'd put robustness (their old #1) back in, somewhere in the low numbers (e.g. #2/3, definitely ahead of easy to install). If it's a ubiquitous service, it *has* to be dependable. Noel From owner-Big-Internet@munnari.oz.au Sat Oct 24 04:35:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09268; Sat, 24 Oct 1992 04:35:41 +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 AA09262; Sat, 24 Oct 1992 04:35:31 +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 1905; Fri, 23 Oct 92 14:34:00 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 0252; Fri, 23 Oct 92 14:33:59 EDT Date: Fri, 23 Oct 92 14:17:58 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Security Features To: Ran Atkinson , big-internet@munnari.oz.au In-Reply-To: <9210231743.7900@munnari.oz.au> Message-Id: <921023.141758.EDT.VALDIS@vtvm1.cc.vt.edu> On Fri, 23 Oct 92 13:40:12 -0400 you said: > We should try to talk in terms of desirable properties such as >authentication, integrity, and confidentiality rather than talk in >terms of "security" because the latter term is so broad as to be >ambiguous in the context of email discussions. Ran: I concur. At least in *my* environment, I do *NOT* need full "security" at the network level. What my environment (the largest university in Virginia) needs is authentication at the network level - I need to know that the purported source machine of a packet is in fact the machine that emitted the packet. Authentication and confidentiality is needed at the session/transport level - however, a standard API such as Kerberos or similar would suffice here. Of course, the most sensitive thing that's likely to flow over our campus backbone is probably a student's transcript or similar. Although we *do* make a serious attempt to secure all confidential data, we in no way claim that we enforce the same levels of security as we would have to if the data was the launch codes for ICBMs. ;) On the other hand, there are things that I don't think should be found on the Internet, no matter *what* security option(s) we engineer. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Sat Oct 24 04:45:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09612; Sat, 24 Oct 1992 04:47:12 +1000 (from owner-Big-Internet) Return-Path: Received: from dg-rtp.rtp.dg.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09543; Sat, 24 Oct 1992 04:45:44 +1000 (from throop@dg-rtp.dg.com) Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4.1/dg-rtp-proto) id AA25042; Fri, 23 Oct 1992 14:41:35 -0400 Received: by walrus (5.4.1/140.2) id AA22499; Fri, 23 Oct 1992 14:38:53 -0400 Date: Fri, 23 Oct 1992 14:38:53 -0400 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9210231838.AA22499@walrus> To: jnc@ginger.lcs.mit.edu, J.Crowcroft@cs.ucl.ac.uk, Big-Internet@munnari.oz.au Subject: Re: buying time by reconfiguration >From: Jon Crowcroft >i mean thats one reason why mockapetris did DNS isnt it? DNS solved the problem of getting an address for a host on the other side of the net. People don't have to maintain a single giant hosts table that contains all hosts. It didn't help get hosts booted and running. In fact it make the problem worse because most DNS configurations hard code in the IP address of the first DNS resolver(s). The trade off was clearly worth it but we've got another IP address stored in numerical format in a configuration file. There are other boot files that contains the IP address of the booting host and the IP address of the local servers. Trying to find and change all these in the local network will be hard. > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Message-Id: <9210231620.AA15724@ginger.lcs.mit.edu> > To: Big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, throop@dg-rtp.dg.com > Subject: Re: buying time by reconfiguration > > The hard part is your point iv) changing the addresses of the end hosts. > ... Changing the address of an interface is the easy part. ... You can't > just change the IP address of a machine you have to change all the servers > that give it service. ... Even magically getting all the above won't handle > everying. > > Changing IP addresses would be seen as a big impact by the users and they > wouldn't see any benefit. They see a working system right now. Why should > they spend a couple of week finding all the places where IP addresses are > stored and change them? They don't deal with routing table sizes. That > not an issue they understand. > > > Hmm, let me see (in my role as 'advocatus diaboli' :-) if I can follow > the reasoning here: > > Routing is about to break; we need CIDR to fix the routing; we need to change > addresses to make CIDR work well; changing addresses is too hard relative to > the benefit of fixed routing; therefor, addresses will not be changed. > > You could be right. People have speculated about this possibility; the > system may just break up into pieces, or people may deploy NAT boxes to avoid ^^^^^^^^^ ?? > having to change the addresses, etc. > There's the question I want to ask: a number of the schemes discussed > on this mailing list (TUBA particularly, but others [e.g. IPAE and SIP] are > basically in the same boat, and I'm *not* picking on TUBA, just following a > line of reasoning, and TUBA claims to do nothing much beyond provide larger > addresses) have the characteristic that they *deploy a new packet format* > to..... *fix the routing*! > > Lemma question: what's easier, changing the address on a host, or updating the > host to a whole new software package to implement a new packet format? It a tough question. A new packet format might offer some important new feature people will want to have (multi-cast audio maybe?). Other than that, they would probably be happy just bouncing packets off their local server and reading mail as they are already doing. > > Question: If they won't go through the minor hassle of changing IP addresses > to fix the routing as the system scales, are they going to go through the > larger hassle of deploying a new packet format for this same goal? > > > Darned if I know if people will change their addresses for CIDR. Maybe >they will, and maybe they won't. One thing I *do* predict; if they won't change > their addresses to fix the routing, they won't change to a new packet format > unless it gives some major new capability, and the future is NAT boxes. (Hmm, > time for a startup? :-) We've got a new capabilities coming along that might help- CDDI. If we convert existing wiring to CDDI, we will change controllers and that gives us a chance to re-allocate IP network numbers. Users will see the performance increase as something they want. This will also give us the 2nd network interface so we can multi-home the servers with a better address. Of course some user's won't want to spend the money for a new controller and will stick with the existing Ethernets. Most of these machines just communicate with their servers for file data or X service or whatever. We can make the servers become application bridges for mail and what few FTP end users do. Once new addresses have been installed in the routers, we excise these non-aggregatable network numbers from the routing tables. The gateways will filter the addresses so they won't get off the the local Ethernet. The network numbers will remain allocated and people will know where they are and who owns them. This means the multi-homed servers won't have to worry about the network number being reused somewhere else on the net. Only the local servers and routers will have to have routing entries for these excised networks. Old hosts will continue to use their old addresses to talk with their server(s). The backbone's just won't correctly route those addresses. Anyone using a machine with an excised network number will quickly learn to use the server as an application bridge. If this isn't acceptable, the machine can be reconfigured with a new address. This can be done slowly and without much impact on local traffic. The local routers can turn on filtering to see what breaks. Then filtering can be turned off so people can get work done while the breaks are repaired. One day nothing breaks (or at least nothing used by a VIP) and a little later the backbones can delete their routing table entries. It isn't pretty but it is based on something that might happen, converting to something users can understand (CDDI), and it doesn't impact the bulk of the installed base to server traffic. We can't reuse the network numbers but at lease we can reduce the size of the routing tables. Given my past experience with crystal ball gazing, I've clearly overtaxed its capabilities by this point. > > Noel Dean Throop throop@dg-rtp.dg.com From owner-Big-Internet@munnari.oz.au Sat Oct 24 04:55:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09872; Sat, 24 Oct 1992 04:55:39 +1000 (from owner-Big-Internet) Return-Path: Received: from boa.gsfc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09869; Sat, 24 Oct 1992 04:55:31 +1000 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.57/Ultrix3.0-C) id AA11575; Fri, 23 Oct 92 14:54:52 -0400 Message-Id: <9210231854.AA11575@boa.gsfc.nasa.gov> Subject: Re: Protocol Transitions (was Re: concerns about CLNP) To: kasten@ftp.com Date: Fri, 23 Oct 92 14:54:51 EDT From: Dick desJardins Cc: big-internet@munnari.oz.au, tuba@lanl.gov In-Reply-To: <9210231352.AA01607@ftp.com>; from "Frank Kastenholz" at Oct 23, 92 9:52 am X-Mailer: ELM [version 2.3 PL11] > > Dick, > > (First, I've copied the big-i list on this since the topic is > wandering more into general big-i issues and away from tuba-specific > issues.) > > I think that having two protocol transitions in less than 10 years is > a non-starter. It costs big dollars for vendors to learn about, > develop, test, field, and support a brand new protocol. Even though > we will have IPv7 in a year or so, I expect that we, the vendors, > will still need to support IPv4 for many years after IPv7 is done. > There will be places that won't or can't convert and we will have to > support them. There will be lots of places that do not need IPv7 > because they are not connected to the Internet (hard to believe, but > true) and it will be difficult to convert them all over. > > To have to go through this effort TWICE when once could suffice is > simply bad. > > I've said this before, I'll say it again, I'd rather keep the current > IP and Internet Routing going for an extra year or two with whatever > hacks, chewing gum and baling wire, prayers, sleepless nights, etc, > then be constantly changing network layer protocols. We will have to > live with IPv7 as the dominant network layer protocol for 10 years or > more. We better be sure that it will do what we need. > > -- > Frank Kastenholz > > In that case, Frank, I would think that's the thing to do. Keep IPv4 and CIDR going, obviously CLNP is going to keep going as well as IPX, etc, and when SIP/PIP/Nimrod etc is ready, we'll go in that direction. I'm more comfortable with this than with adopting something like IPAE that I don't agree with the approach and we don't know what the consequences are. CLNP is already underway and has lots of addresses available as people run out of CIDR addresses or simply don't want to face that hassle. While we're at it, let's make sure the new protocol has autoconfigura- tion at least as good as CLNP/ES-IS does! That way, address/ID changes are no big deal. Dick From owner-Big-Internet@munnari.oz.au Sat Oct 24 05:26:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10522; Sat, 24 Oct 1992 05:26:55 +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 AA10505; Sat, 24 Oct 1992 05:26:22 +1000 (from craig@aland.bbn.com) Received: from uu2.psi.com by shark.mel.dit.csiro.au with SMTP id AA10183 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 24 Oct 1992 05:18:15 +1000 Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA07344; Fri, 23 Oct 92 15:10:31 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA11363; Fri, 23 Oct 92 12:08:51 PDT Message-Id: <9210231908.AA11363@aland.bbn.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: re: Criteria for selecting IPv7 From: Craig Partridge Date: Fri, 23 Oct 92 12:08:50 -0700 Sender: craig@aland.bbn.com Hi Noel: Keep in mind that these are criteria for IPv7, not the whole architecture. If IPv7 precluded the use of PEM, or encrypted TCP, I'd be distressed. But then again, I wouldn't be as distressed as I would be if I couldn't get data through at all. That means, at best, security comes in around #6. And unless you believe that folks desperately want authenticated packets (i.e. yes it came from this source and is for this destination), I'd argue security falls below the increased functionality that consumers want (which puts it around #10). Again, this is not saying we don't have to deal with the security issue -- the question is *where* [let's not design it into each layer thank you]. I think the argument for putting easy configuration higher on the list is a good one. What do other folks think? I also think you've hit a good point on robustness -- I'll find a place to put it in. Thanks a lot for commenting! Craig From owner-Big-Internet@munnari.oz.au Sat Oct 24 05:57:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11780; Sat, 24 Oct 1992 05:57:49 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA11768; Sat, 24 Oct 1992 05:57:43 +1000 (from ljm@ftp.com) Received: from ftp.com (via babyoil.ftp.com) by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA24734; Fri, 23 Oct 92 15:10:48 -0400 Received: from ljm.leather-lace.ftp.com by ftp.com via PCMAIL with DMSP id AA14090; Fri, 23 Oct 92 15:04:32 -0400 Date: Fri, 23 Oct 92 15:04:32 -0400 Message-Id: <9210231904.AA14090@ftp.com> To: Craig Partridge Subject: Re: Criteria for selecting IPv7 From: ljm@ftp.com (leo j mclaughlin iii) Reply-To: ljm@ftp.com Cc: big-internet@munnari.oz.au Sender: ljm@ftp.com Repository: babyoil.ftp.com Originating-Client: leather-lace.ftp.com > > After some discussion with folks on the TUBA list and a re-reading of >the IESG Deliberations on Routing and Addressing, I think we're going to >have problems setting the IPv7 debate unless we get much more concrete about >the criteria for deciding on a protocol.... > Indeed. It has been apparent for quite some time that the arguments for and against different protocols and features of protocols are really arguments about the future direction of networking. However, it is unclear to me that agreement will or can be reached. Or rather, that agreement will be reached by any other mechanism than the normal internet one of different sets of vendors fielding different protocols which prosper to a greater or lesser extext. That said, I cannot resist the temptation to introduce my own chauvinism into the fray. >1. The protocol must allow a straightforward transition plan from the > current IPv4. > >2. The protocol must scale to allow the addressing of billions of end-systems. > At this point, I argue that along with (2) come two other requirements that are before (3). 2A. The protocol must be usable in resource limited environments. It is a mistake to believe that advances in hardware technology will allow us to be profligate in our use of system resources. It is true that things recognizable as 'computers' will grow in power. However, the more interesting trend is toward a future in which everything from watches to keys are networked. It is this trend that will drive the requirement for billions of end-systems. And it is this trend that will mandate that the networking system which becomes ubiquitous (be it generated by the IETF or ISO or a rich entrepreneur) will be the one best suited for use in billions of very small devices. 2B. (was 9.) The protocol should support mobile hosts. Unless the trends in human behavior change dramatically in the next few years, the overwhelming majority of networked systems will be mobile in fairly short order. The networking protocol and system which is to be the next version of IP must be designed such that mobility is the norm, not an odd case which places additional demands on the networking infrastructure. enjoy, leo j mclaughlin iii ljm@ftp.com From owner-Big-Internet@munnari.oz.au Sat Oct 24 06:06:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12280; Sat, 24 Oct 1992 06:06:53 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA12275; Sat, 24 Oct 1992 06:06:36 +1000 (from callon@bigfut.enet.dec.com) Received: from inet-gw-1.pa.dec.com by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA27901; Fri, 23 Oct 92 15:21:03 -0400 Received: by inet-gw-1.pa.dec.com; id AA16377; Fri, 23 Oct 92 11:34:34 -0700 Received: by us1rmc.bb.dec.com; id AA03290; Fri, 23 Oct 92 14:30:29 -0400 Message-Id: <9210231830.AA03290@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Fri, 23 Oct 92 14:30:31 EDT Date: Fri, 23 Oct 92 14:30:31 EDT From: Ross Callon To: solensky@andr.ub.com Cc: tuba@lanl.gov, big-internet@munnari.oz.au Apparently-To: solensky@andr.ub.com, tuba@lanl.gov, big-internet@munnari.oz.au Subject: re: changes to CLNP (was "Fletcher transition, IETF at Crossroads") > It seems to me that if one does convince ISO to change the standard, you'd > then have to deal with making the installed base interoperable again: just > as any proposed change to the Internet protocol suite would. > > Anyone have any ideas how this transition could be accomplished? Or has a > proposal already been floated on the tuba list (in which case: could you > summarize? I'd like to get onto the TUBA list also, but think that this > might be of interest to the rest of us on Big-I but not yet on TUBA). So far the changes proposed are compatible with what has been deployed, although more restrictive in some cases (such as requiring the EIDs to be globally unique, whereas existing CLNP equipment only requires the IDs to be unique within a single area). In general, the intention is that TUBA needs to be constrained by existing equipment the way that any modification/enhancement is constrained by existing equipment. Thus, the IETF would control these changes, but we would want to be reasonable in the changes that we would make. This is sort of analogous to adding subnetting to the IP suite: The Internet community needed to add subnetting in a manner which did not break existing equipment. Ross From owner-big-internet@munnari.oz.au Sat Oct 24 06:32:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13773; Sat, 24 Oct 1992 06:33: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 AA10514; Sat, 24 Oct 1992 05:26:34 +1000 (from craig@aland.bbn.com) Received: from uu2.psi.com by shark.mel.dit.csiro.au with SMTP id AA10216 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 24 Oct 1992 05:26:42 +1000 Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA08221; Fri, 23 Oct 92 15:20:39 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA11376; Fri, 23 Oct 92 12:19:21 PDT Message-Id: <9210231919.AA11376@aland.bbn.com> To: ljm@ftp.com (leo j mclaughlin iii) Cc: big-internet@munnari.oz.au Subject: re: Criteria for selecting IPv7 From: Craig Partridge Date: Fri, 23 Oct 92 12:19:20 -0700 Sender: craig@aland.bbn.com Leo: Thanks for the comments. Two quick questions: * Do you seriously believe that support mobility is more important than being able to communicate? If not, then I think mobility can come no higher than #6 on the list. Also, do you believe that the schemes for mobility are so far advanced that we can make them obligatory now? [A larger question given that guaranteed flow and mobility work are progressing quickly -- how long are you willing to wait before putting IPv7 in stone]. * Could you define resource-poor in the year 2000? Will a watch have 1K of memory or 1M? (This is serious -- we need some hard numbers to aim for). Will its bandwidth be in kilobits or megabits (can we accept Noel's request to up the bottom value in the required bandwidth range?). Craig PS: On your initial comment: > It has been apparent for quite some time that the arguments for > and against different protocols and features of protocols are really arguments > about the future direction of networking. However, it is unclear to me that > agreement will or can be reached. Well, so far (1/2 day's e-mail) suggests that the list is actually rather popular. Folks largely agree with it, modulo exact ranking of some points. That suggests that maybe, just maybe, the IETF community could settle on a rough concensus about what the expectations are. (E.g. get down to debating whether points #6 and #7 should be reversed in order, at which point I think most of us would say "hey, this is close enough"). From owner-big-internet@munnari.oz.au Sat Oct 24 07:06:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14873; Sat, 24 Oct 1992 07:06:30 +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 AA12934; Sat, 24 Oct 1992 06:17:02 +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, 23 Oct 92 16:16:36 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tuba@lanl.gov; Fri, 23 Oct 92 16:16:34 EDT Date: Fri, 23 Oct 92 16:16:34 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9210232016.AA11366@chiya.bellcore.com> To: desjardi@boa.gsfc.nasa.gov, kasten@ftp.com Subject: Re: Protocol Transitions (was Re: concerns about CLNP) Cc: big-internet@munnari.oz.au, tuba@lanl.gov > > While we're at it, let's make sure the new protocol has autoconfigura- > tion at least as good as CLNP/ES-IS does! That way, address/ID changes > are no big deal. > > Dick > I am under the impression that X3S3.3 has given up the project to do auto-configuration of NSAP address prefixes that, in concert with good directory service management, would have gone a long way towards really making address/ID changes no big deal........ PX From owner-Big-Internet@munnari.oz.au Sat Oct 24 07:20:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15287; Sat, 24 Oct 1992 07:21:01 +1000 (from owner-Big-Internet) Return-Path: Received: from regal.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15279; Sat, 24 Oct 1992 07:20:52 +1000 (from dkatz@cisco.com) Received: by regal.cisco.com; Fri, 23 Oct 92 14:19:30 -0700 Date: Fri, 23 Oct 92 14:19:30 -0700 From: Dave Katz Message-Id: <9210232119.AA13653@regal.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: desjardi@boa.gsfc.nasa.gov, kasten@ftp.com, big-internet@munnari.oz.au, tuba@lanl.gov In-Reply-To: Paul Tsuchiya's message of Fri, 23 Oct 92 16:16:34 EDT <9210232016.AA11366@chiya.bellcore.com> Subject: Protocol Transitions (was Re: concerns about CLNP) This is not true; I have in my hands a copy of 9542 PDAM1 (now DAM1 I think) for dynamic address assignment. Date: Fri, 23 Oct 92 16:16:34 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) > > While we're at it, let's make sure the new protocol has autoconfigura- > tion at least as good as CLNP/ES-IS does! That way, address/ID changes > are no big deal. > > Dick > I am under the impression that X3S3.3 has given up the project to do auto-configuration of NSAP address prefixes that, in concert with good directory service management, would have gone a long way towards really making address/ID changes no big deal........ PX From owner-Big-Internet@munnari.oz.au Sat Oct 24 07:43:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16156; Sat, 24 Oct 1992 07:47:43 +1000 (from owner-Big-Internet) Return-Path: Received: from atlas.xylogics.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15977; Sat, 24 Oct 1992 07:43:43 +1000 (from gmalkin@xylogics.com) Received: by atlas.xylogics.com id AA28150 (5.65c/UK-2.1-921001); Fri, 23 Oct 1992 17:44:47 -0400 From: Gary Scott Malkin Date: Fri, 23 Oct 1992 17:44:47 -0400 Message-Id: <28150.199210232144@atlas.xylogics.com> To: ietf@nri.reston.va.us, big-internet@munnari.oz.au Subject: Traceroute BOF Gentlebeings, When I announced the Traceroute BOF, I mistakenly said it would be on Thursday from 7:30-10:00. That is the Open Plenary and IESG Meeting. The Traceroute BOF will be on WEDNESDAY from 7:30-10:00. Sorry for the confusion. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Sat Oct 24 07:36:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15889; Sat, 24 Oct 1992 07:38:38 +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 AA15862; Sat, 24 Oct 1992 07:36:44 +1000 (from craig@aland.bbn.com) Received: from port10.sunnyvale.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA19105; Fri, 23 Oct 92 17:36:17 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA12486; Fri, 23 Oct 92 14:27:19 PDT Message-Id: <9210232127.AA12486@aland.bbn.com> To: big-internet@munnari.oz.au Subject: where to get CCR on-line Reply-To: Craig Partridge From: Craig Partridge Date: Fri, 23 Oct 92 14:27:19 -0700 Sender: craig@aland.bbn.com Hi folks: I got a few queries about how to get Keith Sklower's article on the Fletcher checksum. Apparently some libraries don't subscribe to ACM Computer Communication Review (CCR). While I firmly recommend browbeating your local corporate librarians in such cases, most of the articles from my tenure as CCR editor are available on-line by anonymous FTP from nnsc.nsf.net, in the directory CCR. Articles are organized in directories by month and year of issue, and are named in the directories by the name of the first author. Most articles are in Postscript. Sklower's article should be in CCR/oct89/sklower.ps Craig E-mail: craig@aland.bbn.com or craig@bbn.com From owner-Big-Internet@munnari.oz.au Sat Oct 24 09:18:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19302; Sat, 24 Oct 1992 09:18:55 +1000 (from owner-Big-Internet) Return-Path: Received: from ucsd.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19293; Sat, 24 Oct 1992 09:18:40 +1000 (from tots!tots.Logicon.COM!tep@UCSD.EDU) Received: from tots.UUCP by ucsd.edu; id AA24628 sendmail 5.67/UCSD-2.2-sun via UUCP Fri, 23 Oct 92 16:15:54 -0700 From: tots!tots.Logicon.COM!tep@UCSD.EDU Received: from galt by tots.Logicon.COM (3.2/4.16) id AA02207; Fri, 23 Oct 92 15:16:11 PDT Received: by galt.tots.Logicon.COM (3.2/4.02-client) id AA00587; Fri, 23 Oct 92 15:16:09 PDT Date: Fri, 23 Oct 92 15:16:09 PDT Message-Id: <9210232216.AA00587@galt.tots.Logicon.COM> To: big-internet@tots.Logicon.COM Subject: Interop92 Reply-To: tep@tots.Logicon.COM X-Organization: Logicon, Inc., San Diego, California Will anyone be discussing "big-internet" issues at Interop in San Francisco? Perhaps a small get-together to hoist a few in appreciation of the protocol that has brought us all together (and to its decendants that will keep us together) ? :-) Tom E. Perrine (tep) | tep@Logicon.COM |Voice: +1 619 597 7221 Logicon, Inc. | sun!suntan!tots!tep | or : +1 619 455 1330 4010 Sorrento Valley Blvd| | FAX: +1 619 552 0729 San Diego CA 92121-1498 |Been there, done that, bought the T-shirt... From owner-Big-Internet@munnari.oz.au Sat Oct 24 12:02:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25377; Sat, 24 Oct 1992 12:02:37 +1000 (from owner-Big-Internet) Return-Path: Received: from ucsd.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25374; Sat, 24 Oct 1992 12:02:26 +1000 (from tots!ucsd.EDU!Eng.Sun.COM!Bob.Hinden@UCSD.EDU) Received: from tots.UUCP by ucsd.edu; id AA04305 sendmail 5.67/UCSD-2.2-sun via UUCP Fri, 23 Oct 92 18:45:44 -0700 Received: by tots.Logicon.COM (3.2/4.16) id AA02516; Fri, 23 Oct 92 18:15:22 PDT Received: from Sun.COM by ucsd.edu; id AA01592 sendmail 5.67/UCSD-2.2-sun via SMTP Fri, 23 Oct 92 17:50:17 -0700 for big-internet Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA02919; Fri, 23 Oct 92 17:50:15 PDT Received: from bigriver.Eng.Sun.COM by Eng.Sun.COM (4.1/SMI-4.1) id AA07577; Fri, 23 Oct 92 17:50:20 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA06759; Fri, 23 Oct 92 17:44:43 PDT Date: Fri, 23 Oct 92 17:44:43 PDT From: tots!ucsd.EDU!Eng.Sun.COM!Bob.Hinden@UCSD.EDU (Bob Hinden) Message-Id: <9210240044.AA06759@bigriver.Eng.Sun.COM> To: tep@tots.Logicon.COM Cc: big-internet@tots.Logicon.COM In-Reply-To: <9210232216.AA00587@galt.tots.Logicon.COM> Subject: Interop92 > Will anyone be discussing "big-internet" issues at Interop in San > Francisco? There is a session at Interop on Thursday 10/29 at 10:30AM titled "The Future of IP". The session number is G16. Lyman Chapin is chairing the session and will give an introduction. Peter Ford will speak on Tuba. I will speak on IPAE. Bob Braden will talk about futures and current research projects. Please come, ask questions, throw tomatoes, etc. Bob From owner-Big-Internet@munnari.oz.au Sat Oct 24 12:59:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27295; Sat, 24 Oct 1992 12:59:39 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9210240259.27295@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27292; Sat, 24 Oct 1992 12:59:31 +1000 (from jcurran@nic.near.net) To: Craig Partridge Cc: Noel Chiappa , big-internet@munnari.oz.au Subject: Re: Criteria for selecting IPv7 In-Reply-To: Your message of Fri, 23 Oct 92 12:08:50 -0700. <9210231908.AA11363@aland.bbn.com> Date: Fri, 23 Oct 92 22:58:20 -0400 From: John Curran -------- ] From: Craig Partridge ] Subject: re: Criteria for selecting IPv7 ] Date: Fri, 23 Oct 92 12:08:50 -0700 ] ] ... ] And unless you believe that folks desperately want authenticated packets ] (i.e. yes it came from this source and is for this destination), I'd ] argue security falls below the increased functionality that consumers ] want (which puts it around #10). Again, this is not saying we don't have ] to deal with the security issue -- the question is *where* [let's not ] design it into each layer thank you]. Prioritizing the criteria is an excellent idea. I believe that the first N criteria should be the absolute minimum to solve the problem at hand (i.e. provide IP-like capabilities for a bigger Internet) These probably are viable transition, address growth, routing scaling, and speed adaptability. Autoconfiguration, security, mobility, and similiar gains should follow the basic requirements. While I agree with Noel and think lack of these features will inhibit the growth of the Internet, that consequence might be considered a benefit if we can't find a solution that meets the minimum criteria. /John From owner-Big-Internet@munnari.oz.au Sat Oct 24 13:53:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29338; Sat, 24 Oct 1992 13:54:06 +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 AA29332; Sat, 24 Oct 1992 13:53:47 +1000 (from ljm@ftp.com) Received: from ljm.leather-lace.ftp.com by ftp.com via PCMAIL with DMSP id AA26651; Fri, 23 Oct 92 23:53:31 -0400 Date: Fri, 23 Oct 92 23:53:31 -0400 Message-Id: <9210240353.AA26651@ftp.com> To: craig@aland.bbn.com Subject: re: Criteria for selecting IPv7 From: ljm@ftp.com (leo j mclaughlin iii) Reply-To: ljm@ftp.com Cc: big-internet@munnari.oz.au Sender: ljm@ftp.com Repository: babyoil.ftp.com Originating-Client: leather-lace.ftp.com > >Two quick questions: > >* Do you seriously believe that support mobility is more important than being > able to communicate? If not, then I think mobility can come no higher > than #6 on the list.... I freely admit that I have somewhat of a different perspective on the problem. At base, I believe that the movement toward a multibillion node internet will be the outgrowth of many, many individual decisions each made by independent agents. Moreover, almost none of them will care about the results of the sum of their actions. As a result, if IPv7 is not suited for use in small, mobile, non-configurable devices then the question of IPv7's relative ability to address large scale routing problems will become moot. IPv7 will join CLNP in going the way of the dinosaur and son-of-IPX or son-of-NetBEUI or yet-another-proprietary- protocol will become ubiquitous. >...Also, do you believe that the schemes for mobility are so far advanced >that we can make them obligatory now?... It is more that I would say that any proposed system must support a mapping between aliases and network attachment points such that 'my watch' retains connectivity as I move about my office and the world. It also must deal well with a universe in which most nodes are mobile over long time periods and many nodes are mobile over short time periods. Now, how does that statement map into your question? Certainly, packet format (e.g. SIP) need not concern itself with this issue. However, address format certainly does. Or at least, it must be recognized that an address format which does not itself directly support mobility places a different level of burden on the routing and name resolution systems. Lastly, though I am familiar with the work at Columbia and have a passing acquaintance with SONY's proposal I do not see either of them as a solution to the general problem. Both are simply reasonable solutions to the problem of allowing for a relatively small number of mobile hosts in a sea of IPv4. >* Could you define resource-poor in the year 2000? Will a watch have 1K > of memory or 1M? (This is serious -- we need some hard numbers to > aim for). Defining 'resource-poor' device is fairly easy, something on the order of a micromachine. 'Networked' and 'resource-poor' is much harder. I would guess that 64K would continue as a sort of magic number moving from back in time as a fairly robust iron core computer through the early '80s in PCs to today in toasters to tomorrow in even smaller devices. Your mileage may vary. >Will its bandwidth be in kilobits or megabits (can we accept > Noel's request to up the bottom value in the required bandwidth range?). I've forgotten too much physics. How much would energy utilization increase as the bandwidth of an electromagnetic transmission increases? Assuming a two orders of magnitude increase in battery technology, that reasonable pieces of the EM spectrum are used, and that a battery lifetime of less than 1yr is unacceptable, what transmission bandwidth would a watch sized device reasonably support? enjoy, leo j mclaughlin iii ljm@ftp.com From owner-Big-Internet@munnari.oz.au Sun Oct 25 04:04:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28973; Sun, 25 Oct 1992 04:04:07 +1100 (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 AA28967; Sun, 25 Oct 1992 04:04:00 +1100 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA01864; Sat, 24 Oct 92 11:03:56 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA04119; Sat, 24 Oct 92 11:03:55 MDT Message-Id: <9210241703.AA04119@goshawk.lanl.gov> To: ljm@ftp.com Cc: craig@aland.bbn.com, big-internet@munnari.oz.au, peter@p.lanl.gov Subject: Re: Criteria for selecting IPv7 In-Reply-To: Your message of Fri, 23 Oct 92 23:53:31 -0400. <9210240353.AA26651@ftp.com> Date: Sat, 24 Oct 92 11:03:54 MST From: peter@goshawk.lanl.gov It seems to me with all of this talk on mobility that the IETF needs to get a serious handle on PCS and such. Perhaps we can ask the IETF secretariat to schedule some technical plenary sessions on these kinds of topics? cheers, peter From owner-Big-Internet@munnari.oz.au Sun Oct 25 06:18:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02722; Sun, 25 Oct 1992 06:18:13 +1100 (from owner-Big-Internet) Return-Path: Received: from ucsd.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02719; Sun, 25 Oct 1992 06:18:08 +1100 (from tots!ucsd.EDU!ISI.EDU!braden@UCSD.EDU) Received: from tots.UUCP by ucsd.edu; id AA02149 sendmail 5.67/UCSD-2.2-sun via UUCP Sat, 24 Oct 92 12:15:53 -0700 Received: by tots.Logicon.COM (3.2/4.16) id AA00601; Sat, 24 Oct 92 11:41:08 PDT Received: from zephyr.isi.edu by ucsd.edu; id AA00439 sendmail 5.67/UCSD-2.2-sun via SMTP Sat, 24 Oct 92 11:32:18 -0700 for big-internet Received: by zephyr.isi.edu (5.65c/5.61+local-9) id ; Sat, 24 Oct 1992 11:31:51 -0700 Date: Sat, 24 Oct 1992 11:31:51 -0700 From: tots!ucsd.EDU!ISI.EDU!braden@UCSD.EDU (Bob Braden) Message-Id: <199210241831.AA27864@zephyr.isi.edu> To: Bob.Hinden@eng.sun.com Subject: Re: Interop92 Cc: big-internet@tots.Logicon.COM > > Lyman Chapin is chairing the session and will give an introduction. > Peter Ford will speak on Tuba. I will speak on IPAE. Bob Braden will > talk about futures and current research projects. > Actually, Bob Braden will be talking specifically about support for real-time service. He does NOT encourage throwing tomatoes, etc. The machine-picked tomatoes you get these days are too hard. Bob Braden From owner-Big-Internet@munnari.oz.au Sun Oct 25 07:50:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04750; Sun, 25 Oct 1992 07:50:23 +1100 (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 AA04747; Sun, 25 Oct 1992 07:50:18 +1100 (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; Sat, 24 Oct 92 16:49:57 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tuba@lanl.gov; Sat, 24 Oct 92 16:49:56 EDT Date: Sat, 24 Oct 92 16:49:56 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9210242049.AA12023@chiya.bellcore.com> To: dkatz@cisco.com, tsuchiya@thumper.bellcore.com Subject: Re: Protocol Transitions (was Re: concerns about CLNP) Cc: big-internet@munnari.oz.au, desjardi@boa.gsfc.nasa.gov, kasten@ftp.com, tuba@lanl.gov > > This is not true; I have in my hands a copy of 9542 PDAM1 (now DAM1 I think) > for dynamic address assignment. > Yes, I was aware that the dynamic address assignment work was going on, but the bit about prefix assignment per se has been dropped, right? Or, put another way, in the current spec, is there any way to change just the "inter-domain" part of the NSAP for all hosts in an area? PX From owner-Big-Internet@munnari.oz.au Sun Oct 25 23:38:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03321; Sun, 25 Oct 1992 23:38:26 +1100 (from owner-Big-Internet) Return-Path: Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03315; Sun, 25 Oct 1992 23:38:19 +1100 (from news@ux3.cso.uiuc.edu) Received: from ux3.cso.uiuc.edu by ux1.cso.uiuc.edu with SMTP id AA02344 (5.67a8/IDA-1.5 for ); Sun, 25 Oct 1992 06:37:54 -0600 Received: by ux3.cso.uiuc.edu id AA21673 (5.67a/IDA-1.5 for info-big-internet@ux1.cso.uiuc.edu); Sun, 25 Oct 1992 12:37:37 GMT Newsgroups: info.big-internet Path: uxa.cso.uiuc.edu!mcwg9235 From: mcwg9235@uxa.cso.uiuc.edu (Marsha Woodbury ) Subject: San Francisco dial up needed Message-Id: Summary: how? Sender: usenet@ux3.cso.uiuc.edu (Net Noise owner) Organization: University of Illinois at Urbana Date: Sun, 25 Oct 1992 12:37:33 GMT Keywords: freenet? Lines: 7 Apparently-To: info-big-internet@ux1.cso.uiuc.edu One quick question_--what number do I dial while in SF to access the internet?? Thanks. -- Marsha Woodbury marsha-w@uiuc.edu A simile is like a metaphor. University of Illinois, Middle of Nowhere From owner-Big-Internet@munnari.oz.au Mon Oct 26 23:37:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19844; Mon, 26 Oct 1992 23:38:01 +1100 (from owner-Big-Internet) Return-Path: Received: from cheviot.ncl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19784; Mon, 26 Oct 1992 23:37:15 +1100 (from Denis.Russell@ncl.ac.uk) Received: from [128.240.2.201] (pudding.ncl.ac.uk) by cheviot.ncl.ac.uk id (5.65cVUW/NCL-CMA.1.35 for ) with SMTP; Mon, 26 Oct 1992 12:36:07 GMT Date: Mon, 26 Oct 1992 12:36:07 GMT Message-Id: <199210261236.AA25977@cheviot.ncl.ac.uk> To: Big-Internet@munnari.oz.au From: Denis.Russell@ncl.ac.uk X-Sender: ndmr@eata.ncl.ac.uk Subject: Re: buying time by reconfiguration At 5:41 pm 22/10/92 +0100, Jon Crowcroft wrote: > >>Such address management services for IPv7 are vital, I think. > >One ma^H^Hperson's maintenance tool is another person's security hole... > >that is a very good point - thanks for the check&balance! Well, I was assuming that with IPv7, the entity identifier (EID) and the routing directive (RD) would be separate. I was also assuming that the EID would be fairly static, and be the thing used for security purposes, and that the RD would be expected to change more rapidly, certainly more rapidly than today's IP addresses, and thus we would have to have tools of some sort to manage this. Since I was assuming RDs would not be used for security purposes, then I was assuming that the impact on security would be minimal. (I'd like to avoid the discussion about whether security should be done at this level at all.) In the meantime, I am absolutely convinced that to make IPv4 last until any replacement is available, we lucky owners of class Bs will have to renounce our wonderful addresses in favour of a more hierarchically structured and densely allocated address space that we are moving towards with CIDR. This means that we shall have to manage the changeover in a rapidly growing number of attached machines. Currently the only mechanism for this is skilled personnel and shoeleather. This is not even up to the job of the current IP address management, let alone the management of IPv7 routing directives. Spreading the changeover over weeks, rather than having a "flag weekend" is the only practical possibility, but won't actually reduce the actual cost significantly. Of course, the problem is that current IP addresses are, sort-of, EIDs and RDs combined, and thus having to change them because of their RD function impacts their EID function, and thus any security that relies on this aspect. It is a useful comment that security matters must be considered, but we can't use them as a reason for not doing anything, nor for using personpower on a scale that is just not affordable. Denis From owner-Big-Internet@munnari.oz.au Tue Oct 27 00:29:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21831; Tue, 27 Oct 1992 00:29:37 +1100 (from owner-Big-Internet) Return-Path: Received: from interlock.ans.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21828; Tue, 27 Oct 1992 00:29:30 +1100 (from pgross@ans.net) Received: by interlock.ans.net id AA19104 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Mon, 26 Oct 1992 08:28:47 -0500 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 26 Oct 1992 08:28:47 -0500 Message-Id: <199210261327.AA33583@home.ans.net> To: peter@goshawk.lanl.gov Cc: ljm@ftp.com, craig@aland.bbn.com, big-internet@munnari.oz.au Subject: Re: Criteria for selecting IPv7 In-Reply-To: (Your message of Sat, 24 Oct 92 11:03:54 MST.) <9210241703.AA04119@goshawk.lanl.gov> Date: Mon, 26 Oct 92 08:27:06 -0500 From: Phill Gross It seems to me with all of this talk on mobility that the IETF needs to get a serious handle on PCS and such. Perhaps we can ask the IETF secretariat to schedule some technical plenary sessions on these kinds of topics? Very good idea. We will look into it for the Columbus meeting (all presentation slots are already filled for the upcoming IETF meeting in DC). Does anyone have specific suggestions for speakers? Thanks, Phill From owner-Big-Internet@munnari.oz.au Tue Oct 27 01:25:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23756; Tue, 27 Oct 1992 01:25:52 +1100 (from owner-Big-Internet) Return-Path: Received: from sunic.sunet.se by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23742; Tue, 27 Oct 1992 01:25:39 +1100 (from boss@sunet.se) Received: from localhost.sunet.se by sunic.sunet.se (5.65c8/1.28) id AA11391; Mon, 26 Oct 1992 15:24:55 +0100 Message-Id: <199210261424.AA11391@sunic.sunet.se> To: Phill Gross Cc: peter@goshawk.lanl.gov, ljm@ftp.com, craig@aland.bbn.com, big-internet@munnari.oz.au Subject: Re: Criteria for selecting IPv7 In-Reply-To: Your message of Mon, 26 Oct 92 08:27:06 -0500. <199210261327.AA33583@home.ans.net> Date: Mon, 26 Oct 92 15:24:54 +0100 From: Bernhard Stockman Why not use the ORAD session for this. (Thursday 1.30 - 3.30) Bernhard. From owner-Big-Internet@munnari.oz.au Tue Oct 27 01:27:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23775; Tue, 27 Oct 1992 01:27:26 +1100 (from owner-Big-Internet) Return-Path: Received: from sunic.sunet.se by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23771; Tue, 27 Oct 1992 01:27:06 +1100 (from boss@sunet.se) Received: from localhost.sunet.se by sunic.sunet.se (5.65c8/1.28) id AA11497; Mon, 26 Oct 1992 15:26:04 +0100 Message-Id: <199210261426.AA11497@sunic.sunet.se> To: Phill Gross Cc: peter@goshawk.lanl.gov, ljm@ftp.com, craig@aland.bbn.com, big-internet@munnari.oz.au, boss@sunet.se Subject: Re: Criteria for selecting IPv7 In-Reply-To: Your message of Mon, 26 Oct 92 08:27:06 -0500. <199210261327.AA33583@home.ans.net> Date: Mon, 26 Oct 92 15:26:02 +0100 From: Bernhard Stockman Did of course mean the "Criteria for selecting IPv7" discussion as the subject indicated. Bernhard. From owner-Big-Internet@munnari.oz.au Tue Oct 27 01:58:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24760; Tue, 27 Oct 1992 01:59:00 +1100 (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 AA24739; Tue, 27 Oct 1992 01:58:44 +1100 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA21400 (5.65b/CWI-2.182); Mon, 26 Oct 1992 15:58:27 +0100 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA18899; Mon, 26 Oct 92 15:58:54 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA26627; Mon, 26 Oct 92 15:58:05 +0100 Message-Id: <9210261458.AA26627@dxcern.cern.ch> Subject: re: Criteria for selecting IPv7 To: big-internet@munnari.oz.au Date: Mon, 26 Oct 92 15:58:04 MET From: Brian Carpenter CERN-CN In-Reply-To: <9210231919.AA11376@aland.bbn.com>; from "Craig Partridge" at Oct 23, 92 12:19 pm X-Mailer: ELM [version 2.3 PL11 CERN 11] > > * Could you define resource-poor in the year 2000? If we want the Internet to continue growing in the ex-communist and developing world, there will be plenty people there with 9.6k lines and 286 PCs running MS/DOS. So resource-poor then will mean what it means now, and my guess is that in such regions people will be running good ol' IPv4 indefinitely. That gives criterion #1.5: The protocol must allow interworking with IPv4 zones for an indefinite length of time. 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#, | | YAP, IPv7, EIP, IPAE, (Mini)PIP, SIP, Nimrod, TUNE or TUBA. | From owner-Big-Internet@munnari.oz.au Tue Oct 27 02:11:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25157; Tue, 27 Oct 1992 02:12:04 +1100 (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 AA25151; Tue, 27 Oct 1992 02:11:42 +1100 (from brian@dxcern.cern.ch) Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA22217 (5.65b/CWI-2.182); Mon, 26 Oct 1992 16:11:24 +0100 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA20182; Mon, 26 Oct 92 16:11:52 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA29045; Mon, 26 Oct 92 16:11:03 +0100 Message-Id: <9210261511.AA29045@dxcern.cern.ch> Subject: Re: buying time by reconfiguration To: Big-Internet@munnari.oz.au Date: Mon, 26 Oct 92 16:11:02 MET From: Brian Carpenter CERN-CN In-Reply-To: <9210221956.AA22207@walrus>; from "Dean D. Throop" at Oct 22, 92 3:56 pm X-Mailer: ELM [version 2.3 PL11 CERN 11] >--------- Text sent by Dean D. Throop follows: ... > > The hard part is your point iv) changing the addresses of the end > hosts. How do you change the address of an end node on the network? > Most end node machines don't support multiple IP addresses from > different networks on a single interface. This means the hosts have > to jump from old address to new address. > Well we did this when we transitioned from an "illegal" 100.0.*.* network to our IANA assigned network. It only took one year to plan, was scheduled for the lab's Christmas closure, and we had fewer than 2000 nodes at the time. It was very painful indeed, but mainly for the network group rather than the users. This was an order of magnitude easier than changing protocol and address length. We have been planning that for another (mono-vendor) network architecture for some years and still don't know if we can really do it. The key issue seems to be whether the routing backbone can be migrated independently of the hosts. I think Craig is 150% correct to put the transition plan as the #1 criterion, and Noel may well be correct that there is money to be made out of NATs. 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, SIP, Nimrod, TUNE or TUBA. | From owner-Big-Internet@munnari.oz.au Tue Oct 27 05:39:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00483; Tue, 27 Oct 1992 05:39:18 +1100 (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 AA00480; Tue, 27 Oct 1992 05:39:09 +1100 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA27767; Mon, 26 Oct 92 10:38:56 -0800 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA04501; Mon, 26 Oct 1992 13:38:53 -0500 To: solensky@andr.ub.com Cc: Big-Internet@munnari.OZ.AU, peter@goshawk.LANL.GOV, tuba@lanl.gov Subject: Re: Fletcher transition (was Re: IETF at Crossroads) In-Reply-To: <9210231503.AA11655@fenway.andr.UB.com> References: <9210231503.AA11655@fenway.andr.UB.com> X-Mailer: Poste 2.0 From: David Oran Date: Mon, 26 Oct 92 13:38:53 -0500 Message-Id: <921026133853.4410@sneezy.lkg.dec.com> > >From: peter@goshawk.lanl.gov > > > >... In terms of changing from Fletcher to > >the IP/TCP checksum, it seems to me that it might be worthwhile to feed > >this change back into the ISO standard, using the implementation > >experience of the Internet community to support the change. > > > >If some of these objections were made with some member of the Internet > >protocol suite, people would start talking about fixing the > >standard. Perhaps this attitude and style should be carried over to > >the ISO world. Successful strategies are often expansionist. > > > From Frank T Solensky : > There's two basic points about TUBA that I've never been able to reconcile. > On one hand, CLNP is an existing standard, so we're able to interoperate > with an installed base. On the other, the standard can be changed based > on operational experience. > > It seems to me that if one does convince ISO to change the standard, you'd > then have to deal with making the installed base interoperable again: just > as any proposed change to the Internet protocol suite would. > > Anyone have any ideas how this transition could be accomplished? Or has a > proposal already been floated on the tuba list (in which case: could you > summarize? I'd like to get onto the TUBA list also, but think that this > might be of interest to the rest of us on Big-I but not yet on TUBA). > Incompatible changes are...well...incompatible. there's nothing you can do about that and you have to weigh the incompatibility against the benefits of the change. ISO does this kind of analysis and tradeoff all the time, just as the IETF does. If it is the consumers of CLNP who would benefit from changing CLNP in an incompatible way, then there's a good chance of convincing people to do it. If the consumers get screwed, then the opposition to changing the standard will be vociferous. Doesn't this sound like the IETF? Many people have made the point that if the Internet community becomes a (the?) major consumer of CLNP technology, then the voice should be pretty damn strong. You can choose to dismiss this, but you would be doing so based on subjective bias rather than experience and data. I know of numerous instances where changes were made to ISO standards both during the standardization process and based on operational (at least pilot) experience. The one that comes immdiately to mind was changing ISIS to allow a multi-homing cardinality greater than 3. This was done based on real-world requirements from a major INTERNET operational network (ESnet). In most cases we were able to make the change in an upwardly compatible way by being clever about it. For example, you could quite reasonably phase over to a non-Fletcher checksum by using an unused bit in the header to indicate which checksum you had. To avoid conflicts with the existing checksum field, you could put the new checksum in a TRAILER and set the fletcher checksum to zero to indicate no Fletcher checksum, or even leave the Fletcher checksum there and say the new one takes precedence for checking. There's lots of creative things you can do. Let's have a bit more trust and cooperation here, ok? From owner-Big-Internet@munnari.oz.au Tue Oct 27 05:40:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00534; Tue, 27 Oct 1992 05:40:44 +1100 (from owner-Big-Internet) Return-Path: Received: from yonge.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00531; Tue, 27 Oct 1992 05:40:38 +1100 (from @yonge.csri.toronto.edu:chk@dino.alias.com) Received: from alias by yonge.csri.toronto.edu with UUCP id <5191>; Mon, 26 Oct 1992 13:39:33 -0500 Received: from dino.alias.com by porter.alias.com with SMTP id AA19196 (5.65a/IDA-1.4.2 for jnc@ginger.lcs.mit.edu); Mon, 26 Oct 92 11:38:07 -0500 Received: by dino.alias.com id AA09905 (5.65a/IDA-1.4.2 for big-internet@munnari.oz.au); Mon, 26 Oct 92 11:38:04 -0500 From: chk@alias.com (C. Harald Koch) Message-Id: <9210261638.AA09905@dino.alias.com> Subject: Re: Criteria for selecting IPv7 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Mon, 26 Oct 1992 11:38:03 -0500 Cc: big-internet@munnari.oz.au In-Reply-To: <9210231636.AA15847@ginger.lcs.mit.edu>; from "Noel Chiappa" at Oct 23, 92 12:36 pm X-Mailer: ELM [version 2.3 PL8] > I'd bump the low end of the speed in #4 by a factor; 300 baud modems > are pretty extinct now, and 1200 is only a few years away from the same fate. > Plan for the future, *not* the present! The effective bandwidth of a mobile host can often be 1200bps or less, due to noise conditions, limited RF spectrum availability, channel sharing, etc. Don't rule out slow links; they *will* exist. -- Harald Koch chk@alias.com From owner-Big-Internet@munnari.oz.au Tue Oct 27 06:36:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02262; Tue, 27 Oct 1992 06:42:21 +1100 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02066; Tue, 27 Oct 1992 06:36:42 +1100 (from oran@sneezy.lkg.dec.com) Received: by inet-gw-1.pa.dec.com; id AA16605; Mon, 26 Oct 92 11:33:12 -0800 Received: by sneezy.lkg.dec.com (5.65/DEC-Ultrix/4.3)id AA04637; Mon, 26 Oct 1992 14:32:56 -0500 To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Cc: desjardi@boa.gsfc.nasa.gov, kasten@ftp.com, big-internet@munnari.oz.au Subject: Re: Protocol Transitions (was Re: concerns about CLNP) In-Reply-To: <9210232016.AA11366@chiya.bellcore.com> References: <9210232016.AA11366@chiya.bellcore.com> X-Mailer: Poste 2.0 From: David Oran Date: Mon, 26 Oct 92 14:32:56 -0500 Message-Id: <921026143256.4410@sneezy.lkg.dec.com> Encoding: 16 TEXT, 6 TEXT SIGNATURE > I am under the impression that X3S3.3 has given up the > project to do auto-configuration of NSAP address > prefixes that, in concert with good directory service > management, would have gone a long way towards really > making address/ID changes no big deal........ > Huh? The thing has passed its CD ballot and is going for DIS! The part that does this for hosts, that is. The part that deals with assigning area addresses automatically in the routers based on the inter-domain topology has in fact not gone anywhere, mostly because the person promoting it stopped coming to the meetings. This would be a "good thing" to have, but is not nearly as important as the host part. Dave. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Tue Oct 27 07:02:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03119; Tue, 27 Oct 1992 07:02:51 +1100 (from owner-Big-Internet) Return-Path: Received: from dg-rtp.rtp.dg.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03096; Tue, 27 Oct 1992 07:02:18 +1100 (from throop@dg-rtp.dg.com) Received: from walrus.rtp.dg.com by dg-rtp.dg.com (5.4.1/dg-rtp-proto) id AA13072; Mon, 26 Oct 1992 15:01:15 -0500 Received: by walrus (5.4.1/140.2) id AA00798; Mon, 26 Oct 1992 14:58:44 -0500 Date: Mon, 26 Oct 1992 14:58:44 -0500 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9210261958.AA00798@walrus> To: Big-Internet@munnari.oz.au, brian@dxcern.cern.ch Subject: Re: buying time by reconfiguration >From: Brian Carpenter CERN-CN >Subject: Re: buying time by reconfiguration >Date: Mon, 26 Oct 92 16:11:02 MET >Message-Id: <9210261511.AA29045@dxcern.cern.ch> > ... >Well we did this when we transitioned from an "illegal" 100.0.*.* >network to our IANA assigned network. It only took one year to >plan, was scheduled for the lab's Christmas closure, and we had >fewer than 2000 nodes at the time. It was very painful indeed, but >mainly for the network group rather than the users. > It sounds to me like you were fairly lucky. We've have people here that use PC-NFS on their PC to access their files. One day the disk on their PC starts going bad so they copy all their files onto a server disk and setup a floppy diskette to boot the PC without the hard disk. Basically they are running the PC diskless. The IP address of their PC and the servers now lives on the floppy diskette. If they shutoff their PC and take that diskette home, there's no way to change the IP address over a holiday. And of course they make several copies of the diskette so if it dies, they have a backup. Since some of these people don't use their PCs very much, they live with these arrangements rather than fight the budget police for another disk drive. If you change IP addresses, you'll find this sorta of stuff coming of the woodwork for weeks and weeks. Dean Throop throop@dg-rtp.dg.com From owner-Big-Internet@munnari.oz.au Tue Oct 27 07:24:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03852; Tue, 27 Oct 1992 07:24:42 +1100 (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 AA03848; Tue, 27 Oct 1992 07:24:36 +1100 (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, 26 Oct 92 15:22:01 EST Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Mon, 26 Oct 92 15:22:00 EST Date: Mon, 26 Oct 92 15:22:00 EST From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9210262022.AA14025@chiya.bellcore.com> To: oran@sneezy.lkg.dec.com, tsuchiya@thumper.bellcore.com Subject: Re: Protocol Transitions (was Re: concerns about CLNP) Cc: big-internet@munnari.oz.au, desjardi@boa.gsfc.nasa.gov, kasten@ftp.com > > > I am under the impression that X3S3.3 has given up the > > project to do auto-configuration of NSAP address > > prefixes that, in concert with good directory service > > management, would have gone a long way towards really > > making address/ID changes no big deal........ > > > Huh? The thing has passed its CD ballot and is going for DIS! > The part that does this for hosts, that is. The part that deals > with assigning area addresses automatically in the routers based > on the inter-domain topology has in fact not gone anywhere, > mostly because the person promoting it stopped coming to the meetings. > > This would be a "good thing" to have, but is not nearly as important > as the host part. > Thanks, I was mis-informed....... PX From owner-Big-Internet@munnari.oz.au Tue Oct 27 20:50:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07199; Tue, 27 Oct 1992 20:50:59 +1100 (from owner-Big-Internet) Return-Path: Message-Id: <9210270950.7199@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07195; Tue, 27 Oct 1992 20:50:42 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 27 Oct 1992 09:50:16 +0000 To: throop@dg-rtp.dg.com (Dean D. Throop) Cc: Big-Internet@munnari.oz.au, brian@dxcern.cern.ch, J.Crowcroft@cs.ucl.ac.uk Subject: Re: buying time by reconfiguration In-Reply-To: Your message of "Mon, 26 Oct 92 14:58:44 EST." <9210261958.AA00798@walrus> Date: Tue, 27 Oct 92 09:50:13 +0000 From: Jon Crowcroft >>Well we did this when we transitioned from an "illegal" 100.0.*.* >>network to our IANA assigned network. It only took one year to >It sounds to me like you were fairly lucky. We've have people here ... >Since some of these people don't use their PCs very much, they sure there are people it is hard for, there are also well managed networks that it is easy for (we build all our dos and unix releases centrally, so its fairly straightforeward, and if somone has an unofficial IP addr wired in somewhere, they are breaking our network usage rules, so we don't give much sympathy!) anyhow,this isnt an all or nothing - if any sites can do it, thy help... ` what i wanted was some kind of feel about how many might re-address, and how much it would help! my suspicion, form the lack of positive answers is that most internet sites are pretty slapdash in their management, so you'd only get a few 10s% re-addressing, and it'd only help a small amunt...so i will shut up now:-) jon From owner-Big-Internet@munnari.oz.au Wed Oct 28 03:13:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20757; Wed, 28 Oct 1992 03:13:49 +1100 (from owner-Big-Internet) Return-Path: Received: from mulga.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20753; Wed, 28 Oct 1992 03:13:42 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Received: from bells.cs.ucl.ac.uk by mulga.cs.mu.OZ.AU with SMTP (5.64+1.3.1+0.50); id AA28107 Wed, 28 Oct 1992 03:12:03 +1100 (from J.Crowcroft@cs.ucl.ac.uk) Message-Id: <9210271612.28107@mulga.cs.mu.OZ.AU> Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 27 Oct 1992 16:08:26 +0000 To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: Criteria for selecting IPv7 Date: Tue, 27 Oct 92 16:08:23 +0000 From: Jon Crowcroft craig, io've tried applying your criteria to the current options - this is a quick hack, and people are welcome to disagree, one thing that is clear is you need ease of interworking as well as ease of transition. disclaimer - this _definitely_ reflects my biases and ignorances, just wanted to see if it could be done a bit! ===================> The Solutions judged by the Partridge Criteria ---------------------------------------------- 2TIER RFC 1335 Wang, Z. A Two-Tier Address Structure Crowcroft, J. for the Internet: A Solution to the Problem of Address Space Exhaustion rfc/rfc1335.txt 2TIER dynamically allocates globally unique addrs to hosts when they wish to do non-local communication Essential: 1. EasyTransition yes 2. 10**10 Hosts yes 3. LessthanLinearRouteGrowth 10**9 nets sort of 4. 3bps Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20719; Wed, 28 Oct 1992 03:11:59 +1100 (from dee@ranger.enet.dec.com) Received: by inet-gw-1.pa.dec.com; id AA24633; Tue, 27 Oct 92 08:00:54 -0800 Received: by us1rmc.bb.dec.com; id AA01003; Tue, 27 Oct 92 10:53:00 -0500 Message-Id: <9210271553.AA01003@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Tue, 27 Oct 92 10:57:09 EST Date: Tue, 27 Oct 92 10:57:09 EST From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 27-Oct-1992 1052" To: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au Subject: RE: Re: Fletcher transition (was Re: IETF at Crossroads) I don't understand the point of the following discussion. IPV7 will be an IETF/IAB protocol under the change control of the IETF/IAB. It does not matter much if it's design starts at CLNP or starts at IPV4. (Seems to me that it makes much more sense to start at the later but that's beside the point.) There clearly will be changes and whatever comes out will not be compatible with CLNP and will not be compatible with IPV4. Unless ISO is willing to cede change control for CLNP to the IETF/IAB, it is of no consequence whether changes to CLNP to track IPV7 can be gotten through ISO quickly, easily, and unmodified (a false claim from most of what I have heard) or slowly, painfully, and with pertubations (much more likely). Should I rebroadcast my IETF mailing list message summarizing all the reasons why CLNP is a bad idea for IPV7? It also, unsurprisingly, pointed a number of problems that were common to both CLNP and IPV4. Most people found it persuasive at the time. Donald PS: The stuff below about adding yet more wasted bytes by zeroing out the Fletcher checksum and adding a checksum better adapted to the Big Internet is yet another example of the many ways I pointed out that kludging CLNP would result in an IPV7 starting out with about 15 wasted bytes in every header. -------------- From: US1RMC::"oran@sneezy.lkg.dec.com" "David Oran" 26-OCT-1992 18:02 To: solensky@andr.ub.com CC: Big-Internet@munnari.OZ.AU, peter@goshawk.LANL.GOV, tuba@lanl.gov Subj: Re: Fletcher transition (was Re: IETF at Crossroads) > >From: peter@goshawk.lanl.gov > > > >If some of these objections were made with some member of the Internet > >protocol suite, people would start talking about fixing the > >standard. Perhaps this attitude and style should be carried over to > >the ISO world. Successful strategies are often expansionist. > > > From Frank T Solensky : > There's two basic points about TUBA that I've never been able to reconcile. > On one hand, CLNP is an existing standard, so we're able to interoperate > with an installed base. On the other, the standard can be changed based > on operational experience. > > It seems to me that if one does convince ISO to change the standard, you'd > then have to deal with making the installed base interoperable again: just > as any proposed change to the Internet protocol suite would. > ... If it is the consumers of CLNP who would benefit from changing CLNP in an incompatible way, then there's a good chance of convincing people to do it. If the consumers get screwed, then the opposition to changing the standard will be vociferous. Doesn't this sound like the IETF? Many people have made the point that if the Internet community becomes a (the?) major consumer of CLNP technology, then the voice should be pretty damn strong. You can choose to dismiss this, but you would be doing so based on subjective bias rather than experience and data. In most cases we were able to make the change in an upwardly compatible way by being clever about it. For example, you could quite reasonably phase over to a non-Fletcher checksum by using an unused bit in the header to indicate which checksum you had. To avoid conflicts with the existing checksum field, you could put the new checksum in a TRAILER and set the fletcher checksum to zero to indicate no Fletcher checksum, or even leave the Fletcher checksum there and say the new one takes precedence for checking. From owner-Big-Internet@munnari.oz.au Wed Oct 28 06:18:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25737; Wed, 28 Oct 1992 06:18:30 +1100 (from owner-Big-Internet) Return-Path: Received: from usc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25734; Wed, 28 Oct 1992 06:18:24 +1100 (from estrin@caldera.usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3-USC+2.3) id AA11652; Tue, 27 Oct 92 11:18:20 PST Received: by caldera.usc.edu (4.1/SMI-3.0DEV3-ucs+1.1) id AA00710; Tue, 27 Oct 92 11:18:16 PST Date: Tue, 27 Oct 92 11:18:16 PST Message-Id: <9210271918.AA00710@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin@caldera.usc.edu To: big-internet@munnari.oz.au In-Reply-To: Jon Crowcroft's message of Tue, 27 Oct 92 16:08:23 +0000 <9210271612.28107@mulga.cs.mu.OZ.AU> Subject: Re: Criteria for selecting IPv7 Reply-To: estrin@usc.edu I finally had a chance to read over Craigs list (he does not have the benefit of hindsight that DDC had in writing his list :}...Craig, be sure to save it so that you can refer to it 15 years from now when you write some retrospective paper for Proceedings of IEEE :}) My biggest question/comment is on item 1....Having a transition plan is one thing, but how do we compare the costs/pain of different transition plans...that seems to be a hard issue all by itself and maybe we need a list of requirements for this issue alone! From owner-Big-Internet@munnari.oz.au Wed Oct 28 11:13:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06013; Wed, 28 Oct 1992 11:13:40 +1100 (from owner-Big-Internet) Return-Path: Received: from inet-gw-1.pa.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05999; Wed, 28 Oct 1992 11:13:16 +1100 (from callon@bigfut.enet.dec.com) Received: by inet-gw-1.pa.dec.com; id AA27198; Tue, 27 Oct 92 15:40:47 -0800 Received: by us1rmc.bb.dec.com; id AA13165; Tue, 27 Oct 92 18:24:52 -0500 Message-Id: <9210272324.AA13165@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Tue, 27 Oct 92 18:37:02 EST Date: Tue, 27 Oct 92 18:37:02 EST From: Ross Callon To: j.crowcroft@cs.ucl.ac.uk Cc: big-internet@munnari.oz.au Apparently-To: j.crowcroft@cs.ucl.ac.uk, big-internet@munnari.oz.au Subject: re: Re: Criteria for selecting IPv7 > i've tried applying your criteria to the current options - this is a > quick hack, and people are welcome to disagree, > > one thing that is clear is you need ease of interworking as well as > ease of transition. > > disclaimer - this _definitely_ reflects my biases and ignorances, just > wanted to see if it could be done a bit! Taking a quick look through your list, I would answer a lot of the questions in a different manner than you did. To me this implies two things: (i) The questionaire needs to be filled in by the folks who are proponents of each proposal; (ii) More importantly, it is not enough to just say "yes" to some feature. We need to explain **how** in detail. Also, it is clear that there is still a lot of misunderstanding of the proposals, even by folks who are very active in the goings on of this mailing list. I don't know how we are going to fix this. Ross From owner-Big-Internet@munnari.oz.au Thu Oct 29 02:34:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17765; Thu, 29 Oct 1992 02:34:15 +1100 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA17759; Thu, 29 Oct 1992 02:34:06 +1100 (from brian@dxcern.cern.ch) Received: from mcsun.EU.net by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA19728; Tue, 27 Oct 92 11:13:12 -0500 Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA25696 (5.65b/CWI-2.182); Tue, 27 Oct 1992 17:06:44 +0100 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA16657; Tue, 27 Oct 92 17:07:15 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA26491; Tue, 27 Oct 92 17:06:32 +0100 Message-Id: <9210271606.AA26491@dxcern.cern.ch> Subject: oops To: big-internet@munnari.oz.au Date: Tue, 27 Oct 92 17:06:32 MET From: Brian Carpenter CERN-CN X-Mailer: ELM [version 2.3 PL11 CERN 11] Sorry, I fumbled with the editor and forgot to delete junk at the end of my last message (or my next message, if the mailer favours short ones) -- Brian From owner-Big-Internet@munnari.oz.au Thu Oct 29 06:07:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27931; Thu, 29 Oct 1992 06:07:33 +1100 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA27924; Thu, 29 Oct 1992 06:07:26 +1100 (from brian@dxcern.cern.ch) Received: from mcsun.EU.net by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA18705; Tue, 27 Oct 92 11:08:22 -0500 Received: from dxmint.cern.ch by mcsun.EU.net with SMTP id AA25483 (5.65b/CWI-2.182); Tue, 27 Oct 1992 17:01:56 +0100 Received: by dxmint.cern.ch (dxcern) (5.57/3.14) id AA15688; Tue, 27 Oct 92 17:02:31 +0100 Received: by dxcern.cern.ch (5.57/Ultrix3.0-C) id AA23594; Tue, 27 Oct 92 17:01:49 +0100 Message-Id: <9210271601.AA23594@dxcern.cern.ch> Subject: Re: Criteria for selecting IPv7 To: big-internet@munnari.oz.au Date: Tue, 27 Oct 92 17:01:49 MET From: Brian Carpenter CERN-CN In-Reply-To: <9210230053.AA08439@aland.bbn.com>; from "Craig Partridge" at Oct 22, 92 5:53 pm X-Mailer: ELM [version 2.3 PL11 CERN 11] >--------- Text sent by Craig Partridge follows: > > > Comments welcome (including ones that say this is a dumb idea). > The least dumb idea I've seen for at least a week! Some comments: > > > 1. The protocol must allow a straightforward transition plan from the > current IPv4. ++ and must allow interworking with IPv4 regions for an indefinite ++ length of time. > > [If we can't transition to the new protocol, then no matter how wonderful > it is, we'll never get to it.] > ++ [If we can't interwork then consumer resistance will prevent ++ transition ever starting.] ... > 11. The protocol should permit easy and largely distribution configuration > and operation. > > [People complain that IP is hard to manage. We cannot plug and play. > It would be nice to fix that problem. But I think people care more > about the previous 10 items] ?Huh? I care a _lot_ about this! ... ++13. The protocol should not create insuperable problems for designers ++ of existing multiprotocol routers. ++ [If people can't add IPv7 to existing routers deployment will ++ be severely hampered.] 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, SIP, Nimrod, TUNE or TUBA. | > > 2. The protocol must scale to allow the addressing of billions of end-systems. > > [If we cannot address all hosts in some fashion, presumably we cannot > connect them all to the network, and we cannot hope to route data to > them.] > > 3. The protocol must permit the use of routing schemes which allow routing > tables to grow at a rate much less than linearly with the number of > constituent networks. > > [If we can't route then connecting all those hosts is worthless, but > without connected hosts, there's no point in routing. Thus this is > third.] > > (As a rough sanity check for any scheme, assume that an inexpensive > router [costing $5K 1992 USD] in the year 2000 will have around 1 gigabyte > of router table memory and at that time there will be about 2 million > networks and 75 million end-systems). > > 4. The protocol must work across an internetwork with individual link speeds > ranging from a few kilobits per second to hundreds of gigabits per second. > By work, we mean we have hopes that it can come close to filling the link > at high speeds, but scales gracefully to deal with low speeds. > > [The joy of IP is that it works over just about anything. That ease > of adding new technologies must be maintained. I believe this range > of speed is right for the next twenty years, though it may be we should > say terabits at the high-end]. > > 5. The protocol must support an unreliable datagram delivery service. > > [We like IP's datagram service and it seems to work very well. So > let's keep it. But clearly it matters less than being able to get > the data from here to there, which points 1-4 cover]. > > 6. The protocol must allow for both unicast and multicast addressing. > > [So far, we've done well with unicast and broadcast but broadcast > scales far less well than multicast. We can fight about whether > we should say "local" multicast, i.e. just on the local subnet here, > and make wide-area multicast a lesser priority. Certainly the > ability to send to more than one peer in a message has proved > important. This is an enhancement to the datagram delivery service > so it pre-supposes 5]. > > 7. The protocol must support some means for cost recovery. > > NOTE: this doesn't say billing. Just that commercial providers need > to be able to puzzle out some way to charge for services. Charging > based on leased-line rates, etc., as we do today, is OK. > > [If we don't have the right services, billing for them isn't useful, > so this goes below the previous 6 points]. > > ****************************************************************************** > I think there's an important break here. We go from essential points to > strongly desired items. > ****************************************************************************** > > 8. The protocol should support guaranteed flows. > > [Multimedia is on our desk top. The IETF multicast shows we can do > it over internetworks, with some hitches. We must accept that multimedia > is part of the networking future. If we better understood the problem, > I'd put this about the starred line. Most folks believe that multicast > delivery of flows is important, so it falls below multicast.] > > 9. The protocol should support mobile hosts. > > [Again, mobility is becoming increasingly important. Look at the portables > that everyone is carrying. Note the strength of the Apple commercial > showing someone automatically connecting up her Powerbook to her computer > back in the office. I think conferencing and multimedia support from > your regular office computer is more important than mobility, thus > this falls after 8]. > > 10. The protocol should permit the use of security in the network. > > [This is not just for the military, but for banks, etc. And note > all the folks who want to put security in for their local installations. > Right now, I think the market values security slightly less than > functionality, which is why it lands here]. > > > 12. The protocol should permit policy routing. > > [I'm most concerned with policy routing in the form of choosing carriers. > We'd like to do it, and it would benefit the commercial community. But > in the scheme of things, making life easier for local installations is > probably more important than making life easy for carriers.] > ************************************************************************** > ************************************************************************** > > I quit at 12 because I felt the list was already getting too long. > Thus, for example, I didn't include weak QOS. We haven't needed it (yes > it would be nice, but we haven't suffered grievously without it, so let's > not encumber ourselves with it as a requirement). > > Some comparison with the original list may be useful too. > > The original list had as first priority, continued function "despite loss > of networks or gateways." We've actually historically made ourselves > dependent on backbones and the like, so I didn't include this item. > > The second point was multiple types of service -- I think we've refined > that idea, thus points 5,6,8, and 9. > > The third goal was accomodating a variety of networks (see point 4, and > arguably 5, since datagrams seem to accomdate variety well). > > Fourth point was distributed management of its resources (see point 11). > > Fifth point was cost-effectiveness (I haven't included this). > > Sixth point was low cost attachment (see point 5 -- datagrams arguably > make attachement easy). > > Seventh (and last point) was it must be accountable (see point 7). > From owner-Big-Internet@munnari.oz.au Thu Oct 29 17:20:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02162; Thu, 29 Oct 1992 17:20:16 +1100 (from owner-Big-Internet) Return-Path: Received: from ux1.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02141; Thu, 29 Oct 1992 17:20:01 +1100 (from news@indiana.edu) Received: from usenet.ucs.indiana.edu by ux1.cso.uiuc.edu with SMTP id AA28131 (5.67a8/IDA-1.5 for ); Thu, 29 Oct 1992 00:19:03 -0600 Message-Id: <199210290619.AA28131@ux1.cso.uiuc.edu> Received: by PO2.Indiana.EDU; id AA26272 (5.65c+jsm/2.5jsm); Thu, 29 Oct 1992 01:19:43 -0500 Date: Thu, 29 Oct 1992 01:19:43 -0500 From: USENET News System To: info-big-internet@ux1.cso.uiuc.edu Newsgroups: info.big-internet Path: bronze.ucs.indiana.edu!jgraham From: jgraham@bronze.ucs.indiana.edu (the End) Subject: newsgroup for "best of I-net" ? Message-ID: Sender: news@usenet.ucs.indiana.edu (USENET News System) Nntp-Posting-Host: bronze.ucs.indiana.edu Organization: Rumor Control inc. Date: Thu, 29 Oct 1992 06:19:38 GMT Which newgroup did we decide on for posting the "classics" ? Thanks, Jim jgraham@bio.indiana.edu PS. Please E-mail me as I'll never see it here :) Thanks. From owner-Big-Internet@munnari.oz.au Fri Oct 30 04:32:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28597; Fri, 30 Oct 1992 04:33:05 +1100 (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 AA28591; Fri, 30 Oct 1992 04:32:53 +1100 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA15093; Thu, 29 Oct 92 12:29:01 -0500 Date: Thu, 29 Oct 92 12:29:01 -0500 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9210291729.AA15093@er.doe.gov> To: ALH@eagle.es.net Subject: re: How to make a TUBA go Cc: big-internet@munnari.oz.au The internet address depletion---routing table explosion problem is a classic "problem of the commons". In medeival england there were commongrazing lands in the village. Each individual farmer's best interest drove him to increase the number ofsheep as muchaspossible. However, once there were too many sheep thenall the grass, and sheep, died. Similarly, the vast majority of IP users have NO INCENTIVE to change their protocol for CLNP or anything else. Their optimum strategy is to try and get Class B's. Similarly, vendors best interest in the short term at least is to sell current developed products for which there is the largest possible market. Of course it is true, just as in England in 1300 that when the commons dies that all of these products becomemuch less valuable fo a number, though not all, sites. It is also true that this problem manifests itself most immediately at the backbones who buy fewer routers than the en sites. Note that all of these concerns apply to any new protocol introduction! CLNP has the single advantage that many sites need to implement it any- way because of its ISO status, GOSIP,... There are of course a number of problems with CLNP. Most importantly that its an old design and does not easily support many of the new features we would like our network to have. However,for most users new features are much less important than stable operatit ion of current features. Also note that the chances of having a "new protocol" ready for mass deployment on an operational network in 18 months...even with infinite funding are not good even if consensus was achieved in November. So where does that leave us: Some renumbering will be essential because its the only information com- pression technique we have implemented. We need much better tools to make this managable at sites (On the positive side, thissort of tool would probably be useful to sitesanyway so there is some economic driver here.) How much memory and cpu can the backbone providers put in their routers. What tools do the backbone providers need to manage the tables. It would be useful to understand the bounday between the information the user needs and the information the network needs andwork to isolate the information the user needs so that everything else can be dynamically assigned. Thiswould help the first item above. We need tounbury all references to specific IP adresses in existing applications that are widelydeployed and evaluate the impact of duynamic addressassignment on th them. Finally, the backbone providers need to explore "special" routing featuresthat they may need such as shortcutrouting to help with the inevitable explosion in information. DanHitchcock