From owner-Big-Internet@munnari.oz.au Wed Jul 1 00:19:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24262; Wed, 1 Jul 1992 00:19:30 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206301419.24262@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24249; Wed, 1 Jul 1992 00:19:12 +1000 (from I.Wakeman@cs.ucl.ac.uk) Received: from kant.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Tue, 30 Jun 1992 15:17:20 +0100 To: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 29-Jun-1992 1508" Cc: big-internet@munnari.oz.au Subject: Re: Options efficiency (was Re: Para Meta Matters... ) In-Reply-To: Your message of "Mon, 29 Jun 92 15:06:47 EDT." <9206291906.AA07676@us1rmc.bb.dec.com> Date: Tue, 30 Jun 92 15:17:04 +0100 From: I.Wakeman@cs.ucl.ac.uk Donald Eastlake writes... >You know I've heard this about options being inefficient for routers from man y >sources. Apparently it is a great force against the definition of any more e nd >to end options which tends to stiffle research/experimentation. > > [suggestion for an options present bit in the header] The problem is not so much in the header design - if the header length is greater than 20 than options are present - but in the implementations of the forwarding mechanisms. The processing power of modern routers is sufficent to process a number of options at faster than the line speed of a 2 MBit link. However there are some implementations that decide that option processing is always going to be too slow for the line speed and place any packets with options in a separate queue to be dealt with at leisure, taking advantage of the non-requirement for in-order delivery (although I hardly consider that a"best-effort"). Fortunately, some anti-social implementations are not in the commonest routers. Unfortunately, they happen to be at some important strategic locations. The implementors ought to classify options as easy, intermediate or hard when they are deciding when they should be done (if they must re-order packets) cheers ian >-------------- >From: US1RMC::"pgross@ans.net" "Phill Gross" 27-JUN-1992 22:44 >CC: Jon Crowcroft , jnc@ginger.lcs.mit.edu (Noel >Chiappa), big-internet@munnari.oz.au, wilder@ans.net, enger@ans.net >Subj: Re: Para Meta Matters... > > I was quickly informed that IP options kill router performance. > >Question -- is there any reason why modern routers couldn't put option >processing in the microcode of their smart interface cards? Would >that help? > >Phill From owner-big-internet@munnari.oz.au Wed Jul 1 01:22:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25894; Wed, 1 Jul 1992 01:22:39 +1000 (from owner-big-internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24551; Wed, 1 Jul 1992 00:27:39 +1000 (from oran@sneezy.lkg.dec.com) Received: by crl.dec.com; id AA18896; Tue, 30 Jun 92 10:09:06 -0400 Received: by sneezy (5.57/ULTRIX-4.2-3) id AA01836; Tue, 30 Jun 92 10:02:52 -0400 To: Bob Smart Subject: Re: routing in the telephone network In-Reply-To: <9206292341.AA18002@wanda.mel.dit.CSIRO.AU> References: <9206292341.AA18002@wanda.mel.dit.CSIRO.AU> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.0B3 From: Dave Oran Date: Tue, 30 Jun 92 10:02:44 -0400 Message-Id: <920630100244.272@sneezy.lkg.dec.com> Encoding: 40 TEXT, 5 TEXT SIGNATURE > Clever of them to have variable length addresses from day 1. Now that > we are moving towards variable length addresses we are considering > adding in fixed length IDs. Well I guess we wouldn't want to leave our > children without any technical challenges to exercise their minds. Well, you couldn't have picked a worse example to use to extoll the virtues of variable-length addresses. POTS numbers have the following disgusting properties: 1. The Initial codes are "escape codes" which are neither standardized nor part of the address, but which each host (person in this case) needs to know. 2. The addresses are not referentially transparent - what works depends on where you input it. For example, if I key in the full international E.163 address of the phone in the next cubicle, it doesn't work. This leads to all the silly nonsense of "your should have dialed a 1 first, stupid" (which since the system *knew* that it could have handled better). 3. The padding rules are baroque in the extreme (mostly due to the effects of (1) above. Look at the hoops OSI NSAP addressing had to jump through to accomodate E.163 and E.164 addresses, or the crazy special cases needed on X.121 addresses on a per-administration basis for X.25 networks. The above notwithstanding, I'm a fan of variable length network addresses. I also agree that making host IDs variable length is not a terrible idea, as long as they can be generated in a distributed fashion. One possibility mentioned was to use OSI OIDs, which is not such a terrible idea, especially if you use the form used by OSF DCE for generating OIDs from UUIDS, which would allow completely decentralized allocation. Something to watch out for, is not putting reasonable bounds on the size of these beasts. If you don't it will be very difficult to analyze or predict the performance of routers, since worst-case analysis will be so far off from average-case behavior. That's one nice property of bounded variable-length addresses like OSI NSAPS. The routers know ahead of time their real-time budget for the forwarding lookup. David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@sneezy.lkg.dec.com 550 King Street Littleton, MA 01460 From owner-big-internet@munnari.oz.au Wed Jul 1 01:34:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26174; Wed, 1 Jul 1992 01:35:00 +1000 (from owner-big-internet) Return-Path: Message-Id: <9206301535.26174@munnari.oz.au> Received: from att-out.att.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24692; Wed, 1 Jul 1992 00:38:17 +1000 (from tds@hoserve.att.com) Date: Tue, 30 Jun 92 10:37 EDT From: tds@hoserve.att.com Sender: Antonio_DeSimone@att.com To: big-internet@munnari.oz.au Subject: Re: routing in the telephone network In-Reply-To: <9206300649.AA00365@ginger.lcs.mit.edu> References: <9206300649.AA00365@ginger.lcs.mit.edu> Reply-To: tds@hoserve.att.com A few people have asked for pointers to papers on how routing works in the AT&T Network. Here are two references from Bell Labs people. The first is specifically about the AT&T Network routing; the second is more abstract. You might also look at the review articles by Frank Kelly on Loss Networks in Annals of Applied Probability (not sure of the exact reference...I'm looking at a copy of the galley proofs. Sometime in 1991 probably) and on Network Routing (abstract attached) As Deborah points out, this is not directly relevant to the Internet, since this system is for a homogeneous, fully connected network, and (mostly) a single grade of service. Still, some of the general characteristics are of interest...certainly the Internet problem is no easier. For example, routing on longer paths is a mechanism that can lead to instabilities, so controls are needed to suppress routing on longer paths in overload conditions (trunk reservation controls do this in the circuit network). The multi-rate problem has also been tackled, again using trunk reservation controls to suppress instabilities. Note that these controls are at the level of end-to-end flows, which is typically the unit on which resource allocation decisions are made, why I say that there may be something to learn here when resource reservations are coupled to routing. I had started some work sometime back to apply some of these techniques (Erlang fixed-point approximations, etc) to sparse networks with an eye towards saying something about multi-path routing in Internet-type network. That work has been dormant for about a year now (for want of a good grad student...) but contact me if you're interested in pursuing it. References follow: Title: Real-Time Network Routing in an Integrated Network Author information: Ash, G.R. of AT&T-BL; Org = 51174 Chen, J. of AT&T-BL; Org = 51174 Frey, A.E. of AT&T-BL; Org = 55812 Huang, B.D. of AT&T-BL; Org = 51174 Material(s) for Written Presentation: Abstract Paper Intended Publication: Name: Proceedings of the 13th International Teletraffic Congress Date: June 19, 1991 Clearance Status: Released Effective: 080290 Abstract: This paper describes Real-time Network Routing (RTNR) for integrated networks, and the results of analysis and simulation studies related to RTNR. RTNR is a new adaptive routing method which provides switches a simple way of exchanging trunk group status information, and thereby determining the availability and load conditions of the direct and all two-link paths to the destination. Title: Analysis and Optimal Design of Aggregated-Least-Busy- Alternative Routing on Symmetric Loss Networks with Trunk Reservations Author information: Mitra, D. of AT&T-BL; Org = 11212 Gibbens, R.J. of Univ. of Cambridge Material(s) for Written Presentation: Abstract Paper Intended Publication: Name: Proceedings of 13th International Teletraffic Congress - Copenhagen, Denmark Clearance Status: Released - comments to be incorporated Effective: 082090 Abstract: We investigate a distributed, dynamic routing strategy, called here Aggregated-Least-Busy-Alternative (ALBA), for circuit-switched loss networks. The networks considered are symmetric and fully connected, the offered calls from Poisson streams and routes have at most 2 links. In ALBA(K) the states of each link are lumped into K (K>=2) aggregates and the route of each call is determined by local information on the aggregate-states of the links of the alternate routes at the time of that call's arrival. Network Routing Philosophical Transactions of the Royal Society of London, Series A, Mathematical and Physical Sciences, V337, N1647, 1991, p343-367 Author(s): Kelly FP Number of References: 56 Journal Subject Category: MULTIDISCIPLINARY SCIENCES Abstract: How should flows through a network be organized, so that the network responds sensibly to failures and overloads? The question is currently of considerable technological importance in connection with the development of computer and telecommunication networks, while in various other forms it has a long history in the fields of physics and economics. In all of these areas there is interest in how simple, local rules, often involving random actions, can produce coherent and purposeful behaviour at the macroscopic level. This paper describes some examples from these various fields, and indicates how analogies with fundamental concepts such as energy and price can provide powerful insights into the design of routing schemes for communication networks. From owner-Big-Internet@munnari.oz.au Wed Jul 1 01:55:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26638; Wed, 1 Jul 1992 01:56:09 +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 AA26614; Wed, 1 Jul 1992 01:55:36 +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 AA16943; Tue, 30 Jun 92 08:55:16 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA01240; Tue, 30 Jun 92 08:55:17 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA11199; Tue, 30 Jun 92 08:54:58 PDT Date: Tue, 30 Jun 92 08:54:58 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9206301554.AA11199@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA12886; Tue, 30 Jun 92 08:55:13 PDT To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au In-Reply-To: <9206300806.AA01029@ginger.lcs.mit.edu> Subject: RE: Assorted thoughts (was network number and addresses (are we changing CLNP??) ) Reminds me of a great quote from Tom Lyon of Sun: "Todays Address is Tomorrows Name" Hope that helps put this in some perspective. Bob From owner-Big-Internet@munnari.oz.au Wed Jul 1 02:41:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27753; Wed, 1 Jul 1992 02:42:18 +1000 (from owner-Big-Internet) Return-Path: Received: from gateway.bnr.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27745; Wed, 1 Jul 1992 02:41:41 +1000 (from FORTINP@BNR.CA) Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA17497; Tue, 30 Jun 92 12:40:57 -0400 Message-Id: <9206301640.AA17497@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 3480; Tue, 30 Jun 92 12:39:07 EDT Date: 30 Jun 92 12:42:00 EDT To: , tli@cisco.com From: Pierre (P.) Fortin Subject: re:Draft IESG recommendation on ROAD activities Sender: Pierre (P.) Fortin > If we don't do C#, how are you going to tell customers that > if they're not one of the lucky ones to get one of the few > remaining class B numbers, that they can't, ever, have > 254 > hosts on a net, as all that's left is class C's? That is, > without one of those revolting "multiple nets on a cable" > hacks (which would support C# subnetted with > 8 host bits > and old hosts just as well). > > Revolting is in the eye of the beholder. ;-) > > In any case, I see this issue as actually decreasing over time. > Putting more than 200 SS2's on a single Ether, for example, is a > wonderful way to stress test your users. > > Tony Tony, That depends on your definition of "Ether"... Although I am not condoning this particular setup, we are running upwards of 600-800 hosts on several "Ethers" in a "workgroup environment" using multi-port bridges (MPB) connected to FDDI "backbones". Each w/g handles on average 20-25 devices and at least one server; but since these w/g's are all on the same subnet, the remaining issue is broad-/multi-cast traffic [which can be kept very low by the judicious use of "application" LANs]. (...and yes, the w/g traffic levels are quite high.) The main reasons for going with this large MPB-bridged environment were: 1. lack of dynamic host addressing 2. routers require new [sub]nets (requiring host changes); bridges don't 3. ease of migration (swap out old discrete bridges; see reasons 1. & 2.) [and yes, I am assuming that "migration" means more than one-way...] 4. transparent to users 5. backout is similarly "simple" 6. nothing breaks (almost... :^) ...all related to the lack of auto-configuring tools... My point here is that just like other work-arounds/hacks, currently available technology and creative LAN topology design can be used to eliminate "user stress testing"... so while discussions are going on here, users who are not aware of the impending address/routing problems are working *within* the current technologies/limitations and doing ingenious (OK: kludgie(sp?)) LAN "designs" because they have a real need to extend their environment's useable bandwidth without impacting the end-user who is busy doing the work which brings in the $$$... IMHO, this issue is probably going to *increase* over time. So, I would prefer seeing your argument moved into the "specific implementations can be solved with more $" category... Heck, if anyone has 200 SS2s on their "Ether", they should have a "bandwidth-extending" LAN topology anyway; thus, they likely _will_ want to use multiple C's per cable (when B's run out)... and this for reasons related to the lack of "automation" tools. [Although I took exception to Noel's comment about AppleTalk, I am otherwise totally in agreement with the auto-configuring goal he was trying to put across...] Again, I'm not condoning it, but the realities are that within the current RFCs and vendor creativity; users *are* getting away with many devices on an "Ether", and with *lots* of traffic at that. Not to mention that users can also keep _their_ address space from running out with these LAN kludges... So, we still need to solve the Class B depletion issue while hopefully not unduly penalizing future users (by making assumptions about their [lack of] ingenuity) who were not part of the making of the current addressing problem... Regards, Pierre Webster: From owner-big-internet@munnari.oz.au Wed Jul 1 03:00:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28318; Wed, 1 Jul 1992 03:00:35 +1000 (from owner-big-internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27962; Wed, 1 Jul 1992 02:49:08 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Tue, 30 Jun 92 09:48:56 -0700 Date: Tue, 30 Jun 92 09:48:56 -0700 From: Tony Li Message-Id: <9206301648.AA23612@cider.cisco.com> To: kre@munnari.oz.au Cc: big-internet@munnari.oz.au In-Reply-To: Robert Elz's message of Tue, 30 Jun 92 18:32:21 +1000 <17881.709893141@munnari.oz.au> Subject: Draft IESG recommendation on ROAD activities From: Robert Elz We can't require massive upgrades of everything, but we can allow upgraded hosts or nets full of upgraded hosts, to work better than old ones. There's nothing new about that. Exactly. So if you have old hosts and C# addresses, things don't work well. If we did C#, we would end up handing out lots of C# addresses. For each one we hand out we have to tell the administrator that they need to go get operating system upgrades for all hosts on that C#, or that they need to subnet it down to a C. Does this seem confusing to you? Please don't forget that this includes the administrator of Mom and Pop's Grocery Store and Networking Emporium. Tony From owner-Big-Internet@munnari.oz.au Wed Jul 1 03:25:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28972; Wed, 1 Jul 1992 03: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 AA28967; Wed, 1 Jul 1992 03:25:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA05218; Tue, 30 Jun 92 13:25:39 -0400 Date: Tue, 30 Jun 92 13:25:39 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9206301725.AA05218@ginger.lcs.mit.edu> To: kre@munnari.oz.au, tli@cisco.com Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu If we did C#, we would end up handing out lots of C# addresses. For each one we hand out we have to tell the administrator that they need to go get operating system upgrades for all hosts on that C#, or that they need to subnet it down to a C. Huh? We switched from E to C# because the hosts couldn't hack E. Are you now telling me that trying to tell a host it has an address from C space, but with a mask smaller than a C, will cause the host to barfo or drop down to the larger mask 'native' to C? The HR RFC (RFC-1122, section 3.2.2.9) does not even SHOULD this behaviour. It does say you MUST accept an incoming mask from the network. You SHOULD do a reasonability test, which it defines to be not all 1's, and either all 0's or ar least the high 8 bit's 1. (If memory serves, it was done this way precisely to allow Cluster Networking; a gold Old Boy pin (oops sorry, make that Old Sentient Being pin :-) to anyone who remebers what Clusters were!) Do hosts commonly have code stiffer than that; i.e. that check to make sure it as at least as many bits at the network class? I thought I was the only person in the universe who wrote code that anal-retentive...... Noel From owner-Big-Internet@munnari.oz.au Wed Jul 1 08:35:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11466; Wed, 1 Jul 1992 08:35:15 +1000 (from owner-Big-Internet) Return-Path: Received: from animal.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11456; Wed, 1 Jul 1992 08:35:00 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA19359; Tue, 30 Jun 92 18:28:40 EDT Date: Tue, 30 Jun 92 18:28:40 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9206302228.AA19359@animal.clearpoint.com> To: jnc@ginger.lcs.mit.edu, kre@munnari.oz.au, tli@cisco.com Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Mail from 'jnc@ginger.lcs.mit.edu (Noel Chiappa)' dated: Tue, 30 Jun 92 13:25:39 -0400 Cc: big-internet@munnari.oz.au > Huh? We switched from E to C# because the hosts couldn't hack E. Are >you now telling me that trying to tell a host it has an address from C space, >but with a mask smaller than a C, will cause the host to barfo or drop down to >the larger mask 'native' to C? It's not that so much -- Robert had tested this out earlier today on his workstation (what type: a BSD deriviatve?). There may be an issue with some of the less obvious things that aren't actually broken but would need to be done, though (the SHOULDs rather than the MUSTs): if a person configures their system with a C# address, s/he'd rather have the correct default mask rather than having to manually configure it. Jeff Honig had pointed out in a message dated last Nov 27 the results his quick review of the BSD code -- a number of places had assumed that if a net was not class A or B, it must be C. There were other issues identified also, but most had to do with why Class E addresses wouldn't have worked. > The HR RFC (RFC-1122, section 3.2.2.9) does not even SHOULD this >behaviour. It does say you MUST accept an incoming mask from the network. >.. > Do hosts commonly have code stiffer than that; i.e. that check to make >sure it as at least as many bits at the network class? Heck, can we assume that hosts are commonly 1122-compliant? -- Frank From owner-big-internet@munnari.oz.au Wed Jul 1 08:58:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12150; Wed, 1 Jul 1992 08:58: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 AA09768; Wed, 1 Jul 1992 07:27:36 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA25910; Tue, 30 Jun 92 14:27:12 -0700 Received: by us1rmc.bb.dec.com; id AA20757; Tue, 30 Jun 92 17:25:29 -0400 Message-Id: <9206302125.AA20757@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Tue, 30 Jun 92 17:25:32 EDT Date: Tue, 30 Jun 92 17:25:32 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 30-Jun-1992 1726" 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: Re: Para Meta Matters... I gather from some other postings that much of this has been automated. When I was delving into this stuff, many years ago, as a telephone hacker, it was all manual/static. In fact I toured the AT&T Long Lines building in lower Manhattan form which this was coordinated. It had a hugh wall map with light indicating load/overload status of various centers. At least at that time all routing was done on at most the first six digits of a phone number. In some cases, the routing discarded some leading digits and tried again or replaced some initial digits, particularly for more peculiar services like area code 800. At one time, as far as I could tell, all interstate 800-xxx-yyyz phone numbers actually translated into some normal area code type number and due to the six digit routing limit, it was infeasible to check the last digit (z above). Thus, in some cases, you could call some ordinary person with an 800 number who happened to be in an exchange that some 800 numbers mapped to even though they had not signed up for 800 service. Donald -------------- From: US1RMC::"jnc@ginger.lcs.mit.edu" "Noel Chiappa" 30-JUN-1992 17:01 To: ranger::dee, jnc@ginger.lcs.mit.edu CC: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Subj: RE: Re: Para Meta Matters... Right, I'd heard about some of this. However, I think I recall hearing that at this point the routing was all manual/static, right? Noel From owner-big-internet@munnari.oz.au Wed Jul 1 09:08:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12453; Wed, 1 Jul 1992 09:08:46 +1000 (from owner-big-internet) Return-Path: Received: from cruskit.aarnet.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11819; Wed, 1 Jul 1992 08:48:25 +1000 (from gih900@cruskit.aarnet.edu.au) Received: by cruskit.aarnet.edu.au id AA07838 (5.65+/IDA-1.3.5 for big-internet@munnari.oz.au); Wed, 1 Jul 92 08:48:06 +1000 Date: Wed, 1 Jul 92 08:48:06 +1000 From: Geoff Huston Message-Id: <9206302248.AA07838@cruskit.aarnet.edu.au> To: jnc@ginger.lcs.mit.edu, kre@munnari.oz.au Subject: Re: Draft IESG recommendation on ROAD activities Cc: pgross@ans.net, big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, road@lanl.gov kre writes:.. Yes, but the other way to save Bs is to allocate lots of Cs and watch the routing tables explode. CIDR will keep the routing table sizes down I still don't accept this statement at face value - the time gap between an entity wanting an IP net number for an isolated LAN and the subsequent point in time where the entity goes out onto the IP connection provider market and picks an IP connection provider is typically months or longer. In such a scenario CIDR has no hope of aggregating to any appreciable extent - you simply cannot pre-judge which provider will be picked - and you simply can't make the entity make a purchase decision months (or even years) in advance of the actual act of connection into the Internet domain. C# is at least a neutral solution from this respect. CIDR can do some things C# can't, so that helps reconcile me too. Certainly - CIDR has my support, its an obvious thing to do (obvious now its suggested anyway). ONLY if you are prepared to renumber lots of hosts on lots of subnets from time to time - which makes the entire exercise horrendously costly. Aggregation ability will never fall in the lap of the providers - no matter how you try and structure the IP subnet allocation mechanisms the level of indirection between number allocation and IP routing is simply too great to allow (semi-)automatic aggregation. I still think its necessary to start on C# now I'd have to agree. Geoff Huston From owner-Big-Internet@munnari.oz.au Wed Jul 1 09:38:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13312; Wed, 1 Jul 1992 09:39:06 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9206302339.13312@munnari.oz.au> Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13299; Wed, 1 Jul 1992 09:38:41 +1000 (from kre) Date: Wed, 1 Jul 1992 09:38:41 +1000 From: Robert Elz To: G.Huston@aarnet.edu.au, jnc@ginger.lcs.mit.edu Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, pgross@ans.net, road@lanl.gov Date: Wed, 1 Jul 92 08:48:06 +1000 From: Geoff Huston Message-Id: <9206302248.AA07838@cruskit.aarnet.edu.au> I still don't accept this statement at face value - the time gap ... If you're only looking for CIDR to work because of chance juxtapositions of net numbers that happen to occur on a regional, then I agree you won't see major benefits - some probably, but not huge ones. You will get soem from sites that get their net numbers issued by the regional to which they happen to connect, and some more just by random chance (here in Aust we have a few cases where sites just happened to apply for net numbers at just about the same time and were assigned consecutive numbers). But the place where CIDR will definitely win, is where one site really wants a class B, but instead is told "here take these 16 class C's instead". There you can assume that wherever the site connects, all 16 class C's will connect at the same point, and CIDR will here cause those class C's to look just like a C#. CIDR has the added advantage that it will work just the same with sites that obtained blocks of C's in the past, before the problems of running out of B's, or of routing table explosion were really being seriousl looked at. There's no question that we should go ahead with CIDR. But there are times when "16 C's" just isn't as convenient as one C#, so we really need to be doing C# as well. kre ps: I will investigate other hosts on my C net later today, see if I can find anything that won't let me set a mask < 24 bits. I could just say which vendor's host passed the test yesterday, but since I can test some others, I think it would be fairer not to single out one and make them appear to have some extra wisdom just by neglect of testing all the others that I can easily test. But there are lots of vendor reps on this list, far more than I have access to implementations from. Is there anyone at all who cares to admit that their (host) implementation won't allow a subnet mask < 24 bits on a class C? From owner-Big-Internet@munnari.oz.au Wed Jul 1 10:41:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15050; Wed, 1 Jul 1992 10:41:33 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207010041.15050@munnari.oz.au> Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15045; Wed, 1 Jul 1992 10:41:23 +1000 (from kre) Date: Wed, 1 Jul 1992 10:41:23 +1000 From: Robert Elz To: Big-Internet@munnari.OZ.AU Subject: New net number graphs Date: Tue, 30 Jun 92 17:19:32 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9206302119.AA19266@animal.clearpoint.com> To: kre@munnari.oz.au Subject: New graphs It's the same two graphs as before: the first being the growth of the NSFNet projected into a logistic model, the second being a plot of the different maximum values derived using data up to the corresponding time: indicating how the ceiling has been rising with each update. It's worth noting that the increase this month is only 521 nets more than last month's prediction (15729 vs. 15208). However, since one point does not a trend make, that's probably all it's worth. -- Frank Fank's new set of graphs are in "nsf-netnumbers-9207.ps" in the big-internet directory on munnari.oz.au [128.250.1.21]. kre From owner-Big-Internet@munnari.oz.au Wed Jul 1 12:58:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19081; Wed, 1 Jul 1992 12:59: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 AA19042; Wed, 1 Jul 1992 12:58:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08110; Tue, 30 Jun 92 22:57:45 -0400 Date: Tue, 30 Jun 92 22:57:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207010257.AA08110@ginger.lcs.mit.edu> To: solensky@animal.clearpoint.com Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu s/he'd rather have the correct default mask rather than having to manually configure it Aren't people using the ICMP Address Mask message to get this? This has been there for years; if code isnb't using a long standing method to get info dynamically, sorry, I've not much sympathy for those forced to configure by hand. quick review of the BSD code -- a number of places had assumed that if a net was not class A or B, it must be C As I recall the problem with those code cases, it was something which was not A, B or C was treated as illegal; this made use of E impractical. This code should work just fine for BSD boxes that are not routers. If they are not being silly and running an IGP, bur rather getting Host Redirects, this should all work fine, although I can believe differently. This analysis may be faulty where the BSD host is *connected* to a class C# network. Any BSD wizards out there? Heck, can we assume that hosts are commonly 1122-compliant? Oh, I know that. I was just making the assumption that the average TCP/IP software was proabbly not as picky as even HR, so if it would work with HR it'll probably work with most hosts. Noel ETF. Fair warning, if no consensus emerges by then I will be tempted to say we flip a coin and do whatever it says, discussion be damned. These endless delays, delays, and delays, since the Road fiasco started at Santa Fe, while we debate, trying to pick the optimal solution, are killing us. Guys, this is just a band-aid; we don't have to get it 100%; 80% will do! Can we decide on *something* and do it? Noel PS: Just out of interest, not because I'm trying to go anywhere with this, the IESG released this recommendation weeks ago; how come nobody said anything till KRE sent in his .02? Do we need to look at improving how we release this sort of thing? Should we have sent a short message with bullets as well as the report? From owner-Big-Internet@munnari.oz.au Wed Jul 1 15:30:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23480; Wed, 1 Jul 1992 15:30:38 +1000 (from owner-Big-Internet) Return-Path: Received: from cruskit.aarnet.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23477; Wed, 1 Jul 1992 15:30:33 +1000 (from gih900@cruskit.aarnet.edu.au) Received: by cruskit.aarnet.edu.au id AA08733 (5.65+/IDA-1.3.5 for big-internet@munnari.oz.au); Wed, 1 Jul 92 15:30:23 +1000 Date: Wed, 1 Jul 92 15:30:23 +1000 From: Geoff Huston Message-Id: <9207010530.AA08733@cruskit.aarnet.edu.au> To: jnc@ginger.lcs.mit.edu Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us Noel puts forward the proposition that the anticipated behaviour is that _until_ the entity connects to the internet they may as well use any old number, and renumber themselves at the point in time when they connect:... i.e.: you *can't* assign them a 'permanent' address *until* they join up, and you know where they are in the topology. Which I'd contend is precisely what we want to _avoid_. But I do recognise that time is running out (hell who doesn't) and note that: Fair warning, if no consensus emerges by then I will be tempted to say we flip a coin and do whatever it says, discussion be damned. These endless delays, delays, and delays, since the Road fiasco started at Santa Fe, while we debate, trying to pick the optimal solution, are killing us. Guys, this is just a band-aid; we don't have to get it 100%; 80% will do! Can we decide on *something* and do it? is a perfectly valid comment. What I am trying to say is just that CIDR may prove to be a 20% solution rather than 80%. Its not the elegance or otherwise I'm worried about in the C# / CIDR issue - its whether CIDR will make any difference at all in the routing table size and in the length or time remaining until allocatable address space exhaustion. PS: Just out of interest, not because I'm trying to go anywhere with this, the IESG released this recommendation weeks ago; how come nobody said anything till KRE sent in his .02? Do we need to look at improving how we release this sort of thing? Should we have sent a short message with bullets as well as the report? Good point - these comments were first aired on June 11, and posted to this list on June 14 after the IEPG had spent a torrid period going over the ROAD output. We nominated Bernhard Stockman to convey these concerns to Phil Gross and to report them to the Boston IETF. Geoff From owner-Big-Internet@munnari.oz.au Wed Jul 1 15:48:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23920; Wed, 1 Jul 1992 15:49:07 +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 AA23900; Wed, 1 Jul 1992 15:48:49 +1000 (from kre) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Tue, 30 Jun 92 22:57:45 -0400. <9207010257.AA08110@ginger.lcs.mit.edu> Date: Wed, 01 Jul 92 15:48:36 +1000 Message-Id: <18186.709969716@munnari.oz.au> From: Robert Elz Date: Tue, 30 Jun 92 22:57:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9207010257.AA08110@ginger.lcs.mit.edu> Aren't people using the ICMP Address Mask message to get this? No. This has been there for years; Its also been implemented so badly as to be the surest way to config your host with a random netmask (including one with all the one bits at the host end). Still, configuring it isn't hard, most people do that now. Remember we're not talking about everyone reconfiguring everything, just people who get a new class C# number having to set the netmask in hosts that obviously have to be renumbered already (they've just obtained the C# number). However config is done, automated somewhere, entirely by entering numbers by hand, or by moving jumpers on a logic board or something, configuring the netmask as well as the IP address, default gateway, ... is not much of an extra burden, so whether it defaults to the "natural" mask or not isn't really all that important. This analysis may be faulty where the BSD host is *connected* to a class C# network. I don't think there's any problem with BSD hosts on C# netnumbers. I have just tested every different kind of box I could find on my class C net (which I keep so I can play with stuff and not upset the world at large). On each of the following, I had no problem setting a netmask of < 24 bits with the class C address (on some I tried the natural C# mask, on others something between, I'm fairly sure that makes no difference at all). Sun running SunOS 4.1.1 SGI running Irix 4.0.x Decstation running Ultrix 4.2 PC running PC/NFS 3.5 Mac II running A/UX 2.xx Labtam MT200 X terminal (Xengine J91) Teltronix DAS 9200 Logic Analyser with 92Lan 1.0 The only thing I could find that failed was Mac II running MacTCP 1.1 which is just as anal retentive as Noel apparently, and "knows" that a class C number has the top 24 bits set in the netmask, and won't allow any less to be set (nor will it allow me to say its a class B number but with a first octet of 192 or more). I'd still appreciate it if some of the people responsible, or with knowledge of other implementations (someone from FTP? Someone who knows KA9Q? Someone from, or who knows, IP for various non-unix playforms? IBM mainframes? VMS? ICL? CDC? ...) would let us know what those implementations do with a class C number and a netmask of < 24 bits. Note that hosts that can't be config'd to know a narrower than 24 bit netmask on a C# net (if that's what the local config wants to use) will probably still work OK, it will look to them just as if there are simply a bunch of other netnumbers sharing the same cable, which wile pretty ugly, is something that a lot of sites do now for one reason or other, its not as if this config would shut them out of operation, just make them a bit less effecient. kre From owner-Big-Internet@munnari.oz.au Wed Jul 1 16:02:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24310; Wed, 1 Jul 1992 16:03:08 +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 AA24297; Wed, 1 Jul 1992 16:02:50 +1000 (from kre) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Tue, 30 Jun 92 23:12:07 -0400. <9207010312.AA08164@ginger.lcs.mit.edu> Date: Wed, 01 Jul 92 16:02:38 +1000 Message-Id: <18197.709970558@munnari.oz.au> From: Robert Elz Date: Tue, 30 Jun 92 23:12:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9207010312.AA08164@ginger.lcs.mit.edu> how come nobody said anything till KRE sent in his .02? It may have been partly that sometimes it seems useless to argue against a decision once its been made. In my case it was a combination of simple lack of time, and some frustration that anyone could do anything so inane, and appear to finalise it without appearing to seek comments in advance. This was probably discussed at the IETF, but I wasn't able to get there, so until you posted your message just ahead of Phil's announcement it looked from here to be just stagnation. After that it seemed like it might be just too late - I spent a while just cooling off so the message I sent wouldn't appear too abusive... Its very hard to get the processes right here - discussion is needed to get the bugs out (and was useful in turning E into C# etc), but after that we really just about need an autocratic "Do this now" from someone, and we need that now. I agree, the next IETF is the last chance, at that point, either C# or CIDR, or both *must* be moved to "must implement as soon as possible" status. Either one will do for now, the other will then have a few more months to be debated, or to wait for things to fall into place. Both would be better. No more delays! kre From owner-Big-Internet@munnari.oz.au Wed Jul 1 18:28:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28123; Wed, 1 Jul 1992 18:29: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 AA28091; Wed, 1 Jul 1992 18:28:45 +1000 (from kre) To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Tue, 30 Jun 92 23:12:07 -0400. <9207010312.AA08164@ginger.lcs.mit.edu> Date: Wed, 01 Jul 92 18:28:38 +1000 Message-Id: <18220.709979318@munnari.oz.au> From: Robert Elz Date: Tue, 30 Jun 92 23:12:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-ID: <9207010312.AA08164@ginger.lcs.mit.edu> Well, yes, exactly. Since CIDR addresses (indeed, most of what we consider "addresses") have topological significance (i.e. an "address" tells you somthing about *where* something is), you *can't* assign them a 'permanent' address *until* they join up, and you know where they are in the topology. If part of implementing CIDR is going to mean requiring everyone to renumber - ideally sites already on the net, and new sites joining, which would be required for maximum benefit, then its doomed already. That is simply not going to happen. Neither part of it will happen - sites connected already aren't going to renumber, nor are sites that have allocated numbers, but are not yet connected (there are something > 45000 class C numbers allocated already (very quick back of the envelope calculation) - and only ~6000 total nets connected, those other 39000++ net number owners aren't going to be happy if they're told their old number, obtained because they wanted one that would enable them to connect without renumbering, is no longer valid for that purpose). You're only going to get a benefit from CIDR for newly assigned net numbers, and only by hoping that sites getting new numbers obtain numbers that will enable supernetting when they do connect, probably by obtaining the number through the regional net they're going to connect to. How effective this is going to be, other than when multiple numbers are allocated to one site, is hard to tell. A little perhaps, I wouldn't expect much more than that. Certainly better than nothing though. Until they join, they might just as well use 192.9.200 or whatever that number is that Sun used to ship; That's the number, but in doing that they'd be going against all advise currently offered, and definitely making more work for themselves (the sooner you get the number right the easier it is). Aside - has anyone noticed that 192.9.200 seems to have been allocated (re-allocated) to some poor unfortunate now ? From the latest network-contacts.txt from the NIC ... 192.9.200.0 C CENDATA McGrath, Robert (RM524) cendata!cendata!mcgrath@uunet.uu.net (217) 359-8010 ext 247 What a devious form or torture to inflict on a site! Sun used to own the whole 192.9 block, but no more it appears? Back to the point, I said... I still think its necessary to start on C# now Noel replied... What's to start on, other than implementation? Nothing, that's the point - except that probably most of the people who count won't comit to doing it until C# is blessed. After all, if your router decides that C# is a new class, then the IAB/IESG/... decides not to go ahead (that is, confirms the current recommendation) then you're going to have a broken implementation once class C numbers in the C# range start being assigned. We do need the "C# is a new class" edict. kre From owner-Big-Internet@munnari.oz.au Wed Jul 1 21:27:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02184; Wed, 1 Jul 1992 21:27:12 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207011127.2184@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02180; Wed, 1 Jul 1992 21:27:07 +1000 (from P.Tsuchiya@cs.ucl.ac.uk) Received: from waffle.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 1 Jul 1992 12:25:25 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: Assorted thoughts (was network number and addresses (are we changing CLNP??) ) In-Reply-To: Your message of "Tue, 30 Jun 92 04:06:34 EDT." <9206300806.AA01029@ginger.lcs.mit.edu> Date: Wed, 01 Jul 92 12:25:09 +0100 From: Paul Tsuchiya You need to be told when the routing hierarchy above the net changes and it is very convenient to be able to address the network as a fixed named entity. By the way, Pip has a mode of operation where no routers or hosts in a stub domain need to know anything about the routing hierarchy above the net. One of the examples in the overview covers this. PT From owner-Big-Internet@munnari.oz.au Wed Jul 1 23:05:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04305; Wed, 1 Jul 1992 23:05:56 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207011305.4305@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04295; Wed, 1 Jul 1992 23:05:34 +1000 (from ULLMANN@PROCESS.COM) Date: Wed, 1 Jul 1992 09:02 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: FWD: Re: Draft IESG recommendation on ROAD activities From: Robert Elz But there are lots of vendor reps on this list, far more than I have access to implementations from. Is there anyone at all who cares to admit that their (host) implementation won't allow a subnet mask < 24 bits on a class C? Sure :-) Process Software, TCPware (for VMS). But it is clearly a bug (RFC1122 non-compliance) and ought to be fixed presently. (If C# gets standing, we will clearly need to fix it sooner. :-) To answer the question (since I have been down in the gory details of several implementations) I don't think it is a common problem. Most vendors (including me in a prior incarnation) fixed such things when we did subnetting properly, implementing arbitrary masks. The class masks were then used _only_ as a default. Robert Ullmann Process Software Corporation. From owner-Big-Internet@munnari.oz.au Wed Jul 1 23:48:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05426; Wed, 1 Jul 1992 23:48:27 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05423; Wed, 1 Jul 1992 23:48:19 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Wed, 1 Jul 92 06:48:12 -0700 Date: Wed, 1 Jul 92 06:48:12 -0700 From: Tony Li Message-Id: <9207011348.AA05193@cider.cisco.com> To: kre@munnari.oz.au Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us In-Reply-To: Robert Elz's message of Wed, 01 Jul 92 18:28:38 +1000 <18220.709979318@munnari.oz.au> Subject: Draft IESG recommendation on ROAD activities If part of implementing CIDR is going to mean requiring everyone to renumber - ideally sites already on the net, and new sites joining, which would be required for maximum benefit, then its doomed already. CIDR does not require any existing site to renumber. You're only going to get a benefit from CIDR for newly assigned net numbers, and only by hoping that sites getting new numbers obtain numbers that will enable supernetting when they do connect, probably by obtaining the number through the regional net they're going to connect to. The site does not have to enable supernetting. It just gets its number from its regional. The regional worries about supernetting. How effective this is going to be, other than when multiple numbers are allocated to one site, is hard to tell. A little perhaps, I wouldn't expect much more than that. Certainly better than nothing though. It is a lot better than that. All new sites connected by one regional can be represented by one aggregate in the routing table. Please read the RFC for details. Tony From owner-Big-Internet@munnari.oz.au Thu Jul 2 00:42:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07574; Thu, 2 Jul 1992 00:42:23 +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 AA07564; Thu, 2 Jul 1992 00:42:10 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA01333 (5.65/1.23); Wed, 1 Jul 92 10:41:52 -0400 Date: Wed, 1 Jul 92 10:41:52 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9207011441.AA01333@sadye.emba.uvm.edu> To: Tony Li Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, jnc@ginger.lcs.mit.edu, kre@munnari.oz.au Subject: Draft IESG recommendation on ROAD activities In-Reply-To: <9207011348.AA05193@cider.cisco.com> References: <18220.709979318@munnari.oz.au> <9207011348.AA05193@cider.cisco.com> On Wed, 1 Jul 92 06:48:12 -0700, Tony Li said: > The site does not have to enable supernetting. It just gets its > number from its regional. The regional worries about supernetting. But this is precisely the problem! There are many sites out there which already have numbers assigned, but have not decided who to use as their IP carrier. The point which everyone else seems to have been trying to make is that you are either forcing users to pick a wide-area carrier before they do anything with IP on their local networks, or forcing them to change their numbers when they actually do get hooked up to the Internet as a whole. -GAWollman -- Garrett A. Wollman = wollman@emba.uvm.edu = UVM is welcome to my opinions = uvm-gen!wollman = That's what being alive is all about. No deity, no higher goal exists, than to bring joy to another person. - Elf Sternberg From owner-Big-Internet@munnari.oz.au Thu Jul 2 00:56:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07961; Thu, 2 Jul 1992 00:56: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 AA07950; Thu, 2 Jul 1992 00:56:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10744; Wed, 1 Jul 92 10:55:54 -0400 Date: Wed, 1 Jul 92 10:55:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207011455.AA10744@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: Big Time Cc: jnc@ginger.lcs.mit.edu Well, guys, we just hit the Big Time. A person from the Internetworking department of Comm Week just called me; they are doing a story on the whole routing/addressing debate... Noel From owner-Big-Internet@munnari.oz.au Thu Jul 2 01:12:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08191; Thu, 2 Jul 1992 01:12:08 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08188; Thu, 2 Jul 1992 01:12:02 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Wed, 1 Jul 92 08:11:55 -0700 Date: Wed, 1 Jul 92 08:11:55 -0700 From: Tony Li Message-Id: <9207011511.AA05601@cider.cisco.com> To: Garrett.Wollman@UVM.EDU Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, jnc@ginger.lcs.mit.edu, kre@munnari.oz.au In-Reply-To: Garrett.Wollman@UVM.EDU's message of Wed, 1 Jul 92 10:41:52 -0400 <9207011441.AA01333@sadye.emba.uvm.edu> Subject: Draft IESG recommendation on ROAD activities But this is precisely the problem! There are many sites out there which already have numbers assigned, but have not decided who to use as their IP carrier. The point which everyone else seems to have been trying to make is that you are either forcing users to pick a wide-area carrier before they do anything with IP on their local networks, or forcing them to change their numbers when they actually do get hooked up to the Internet as a whole. We are not forcing anyone to do anything. If you have a number already assigned then you should use it. If and when you decide to pick a carrier, you MAY renumber your site into the carriers address space, but you are not forced to. We are hoping that the carriers/regionals will encourage this behavior, perhaps through economic incentives. For example, if you wish the regional to advertise your network numbers, the regional may wish to charge you a slightly higher administrative fee. Tony From owner-Big-Internet@munnari.oz.au Thu Jul 2 02:00:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09293; Thu, 2 Jul 1992 02:00:32 +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 AA09289; Thu, 2 Jul 1992 02:00:22 +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 5891; Wed, 01 Jul 92 11:59:07 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 4600; Wed, 01 Jul 92 11:59:07 EDT Date: Wed, 01 Jul 92 11:37:29 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Draft IESG recommendation on ROAD activities To: Tony Li , kre@munnari.oz.au Cc: big-internet@munnari.oz.au In-Reply-To: <9207011348.AA05193@cider.cisco.com> Message-Id: <920701.113729.EDT.VALDIS@vtvm1.cc.vt.edu> On Wed, 1 Jul 92 06:48:12 -0700 Tony Li said: >The site does not have to enable supernetting. It just gets its >number from its regional. The regional worries about supernetting. Supernetting - a good idea, but I don't see how the regionals can win. Virginia Tech is a class B net 127.173.x.x - we *used* to be connected via a T-1 managed by Suranet. For various reasons, our main T-1 is now managed by ANS. At the time of the change, we had some 600 or so IP addressable hosts. Now, if we had made said move in a post-supernetting world, we'd have to either renumber or the regional doesn't get the benefit of supernetting. What is the "carrot" that the regional will use to get the site to renumber? Remember that it will have to be a *big* carrot in order to offset the manpower cost of re-numbering all those machines (not counting all the ugly things that happen during the cut-over such as running two networks on the same wire, etc)? Somehow, I think there'd be a *major* push to: (a) pay any "surcharge" rather than to have to re-number *and* (b) look for the network provider with the lowest surcharge... Would ANS have gotten us to renumber without imposing a (guesstimate) $5K/year surcharge? Probably not. Would ANS have gotten our business at *all* if they posed a $5K/year surcharge? Probably not. Is ANS here to make money? Probably not^h^h^hyes. :) Remember that this is in the same political/economic climate that has AT&T saying "Come on back, we'll switch you for free..." to solicit long-haul service. I'd be surprised if we leave 1992 without similar marketing tactics being in widespread use on the data side of the fence (if they aren't already). Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Thu Jul 2 02:06:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09398; Thu, 2 Jul 1992 02:06:09 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09384; Thu, 2 Jul 1992 02:06:01 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Wed, 1 Jul 92 09:05:55 -0700 Date: Wed, 1 Jul 92 09:05:55 -0700 From: Tony Li Message-Id: <9207011605.AA05883@cider.cisco.com> To: VALDIS@VTVM1.CC.VT.EDU Cc: kre@munnari.oz.au, big-internet@munnari.oz.au In-Reply-To: Valdis Kletnieks's message of Wed, 01 Jul 92 11:37:29 EDT <920701.113729.EDT.VALDIS@vtvm1.cc.vt.edu> Subject: Draft IESG recommendation on ROAD activities Supernetting - a good idea, but I don't see how the regionals can win. The regionals win because they can now offer a new service to new customers: address allocation. You don't go through the NIC and wait N weeks. Your regional gives it to you today. Tony From owner-Big-Internet@munnari.oz.au Thu Jul 2 02:10:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09486; Thu, 2 Jul 1992 02:10:15 +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 AA09483; Thu, 2 Jul 1992 02:10:10 +1000 (from postel@ISI.EDU) Received: from bel.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Wed, 1 Jul 1992 09:10:15 -0700 Date: Wed, 1 Jul 1992 09:08:04 -0700 From: postel@ISI.EDU Posted-Date: Wed, 1 Jul 1992 09:08:04 -0700 Message-Id: <199207011608.AA21345@bel.isi.edu> Received: by bel.isi.edu (5.65c/4.0.3-4) id ; Wed, 1 Jul 1992 09:08:04 -0700 To: jnc@ginger.lcs.mit.edu Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us Hi. If CIDR addresses are assigned on a geographic basis rather than a provider basis you could assign the addresses prior to provider selection, and addresses need not change if you change providers. --jon. From owner-Big-Internet@munnari.oz.au Thu Jul 2 02:27:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09909; Thu, 2 Jul 1992 02:27:33 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09906; Thu, 2 Jul 1992 02:27:25 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Wed, 1 Jul 92 09:27:10 -0700 Date: Wed, 1 Jul 92 09:27:10 -0700 From: Tony Li Message-Id: <9207011627.AA06060@cider.cisco.com> To: postel@ISI.EDU Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us In-Reply-To: postel@ISI.EDU's message of Wed, 1 Jul 1992 09:08:04 -0700 <199207011608.AA21345@bel.isi.edu> Subject: Draft IESG recommendation on ROAD activities If CIDR addresses are assigned on a geographic basis rather than a provider basis you could assign the addresses prior to provider selection, and addresses need not change if you change providers. Yes, but then you end up with interesting situations where multiple providers are advertising the same geographic aggregation. This is basically the gist of the city code addressing scheme. Tony From owner-Big-Internet@munnari.oz.au Thu Jul 2 02:51:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10449; Thu, 2 Jul 1992 02:51:16 +1000 (from owner-Big-Internet) Return-Path: Received: from cody.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10445; Thu, 2 Jul 1992 02:51:04 +1000 (from rrv@cody.cso.uiuc.edu) Received: by cody.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03) id AA23792; Wed, 1 Jul 1992 11:50:59 -0500 Date: Wed, 1 Jul 1992 11:50:59 -0500 From: rrv@cody.cso.uiuc.edu (Ross Veach) Message-Id: <9207011650.AA23792@cody.cso.uiuc.edu> To: jnc@ginger.lcs.mit.edu, kre@munnari.oz.au Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us I must still be missing something. I still haven't done all of the background reading. Where is the C# proposal? My understanding is that C# is just defining a new network class with a 20 bit net mask in the upper portion of the current class C address space. Am I right? If I am, then C# is nothing more than a rigidly fixed case of what CIDR does in a completely general manner. Hosts will have exactly the same problems. IGPs will have exactly the same problems. EGPs will have exactly the same problems. Why bother with the rigidly fixed case? The authorities that allocate network numbers can start allocating class C numbers in power of 2 groups on power of 2 boundries today. If an organization can only justify 9 bits of address space, it would get 9 bits of address space. If it can justify 12 bits of address space, it would get 12 bits of address space. Simple. From owner-Big-Internet@munnari.oz.au Thu Jul 2 02:58:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10651; Thu, 2 Jul 1992 02:58:41 +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 AA10639; Thu, 2 Jul 1992 02:58:33 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA15137); Wed, 1 Jul 92 11:58:13 CDT Received: by san-miguel.is.rice.edu (AA12019); Wed, 1 Jul 92 11:58:10 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9207011658.AA12019@san-miguel.is.rice.edu> Subject: Re: Draft IESG recommendation on ROAD activities To: tli@cisco.com (Tony Li) Date: Wed, 1 Jul 92 11:58:09 CDT Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us In-Reply-To: <9207011511.AA05601@cider.cisco.com>; from "Tony Li" at Jul 1, 92 8:11 am X-Mailer: ELM [version 2.3 PL11] In fact, what we try and do is provide a "DMZ" space between a customers internal IP space and the regional space. Something like so: 190.1.0.0 <-> 194.1.2.0 <-> 189.1.0.0 internal net DMZ net regional net This way they keep their own space "private" and the regional allocates the routed space. This approch has a number of problems, but it seems to work in a lot of situations. -- 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 Thu Jul 2 03:03:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10727; Thu, 2 Jul 1992 03:03:49 +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 AA10724; Thu, 2 Jul 1992 03:03: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 6050; Wed, 01 Jul 92 13:02:27 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 6194; Wed, 01 Jul 92 13:02:26 EDT Date: Wed, 01 Jul 92 12:58:32 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Draft IESG recommendation on ROAD activities To: Tony Li Cc: big-internet@munnari.oz.au In-Reply-To: <9207011605.AA05883@cider.cisco.com> Message-Id: <920701.125832.EDT.VALDIS@vtvm1.cc.vt.edu> On Wed, 1 Jul 92 09:05:55 -0700 you said: >The regionals win because they can now offer a new service to new >customers: address allocation. You don't go through the NIC and wait >N weeks. Your regional gives it to you today. Tony - Right. But the regional *only* wins if they get a commitment that in 18 months (or whatever), the customer will choose *that* regional. Otherwise, the regional just assumed all of the headache of managing that address allocation, and some OTHER regional gets the traffic (and income). Let's not lose sight of the fact that *90%* of all the allocated network numbers are *NOT* connected to the Internet at the present time. And I've seen *NO* evidence to suggest that *that* trend is likely to change in the near future.... /Valdis From owner-Big-Internet@munnari.oz.au Thu Jul 2 03:28:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11213; Thu, 2 Jul 1992 03:28:17 +1000 (from owner-Big-Internet) Return-Path: Received: from malgudi.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11210; Thu, 2 Jul 1992 03:28:09 +1000 (from kannan@oar.net) Received: from valhalla.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA03318; Wed, 1 Jul 1992 13:27:59 -0400 Message-Id: <199207011727.AA03318@malgudi.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, iesg@nri.reston.va.us Reply-To: kannan@oar.net Subject: Re: Big Time In-Reply-To: Your message of Wed, 01 Jul 92 10:55:54 -0400.<9207011455.AA10744@ginger.lcs.mit.edu> Date: Wed, 01 Jul 92 13:31:08 -0400 From: Kannan Varadhan >>> From: jnc@ginger.lcs.mit.edu (Noel Chiappa) >>> Date: Wed, 01 Jul 92 10:55:54 EDT > Well, guys, we just hit the Big Time. A person from the Internetworking > department of Comm Week just called me; they are doing a story on the whole > routing/addressing debate... Yeah, and some of the questions they asked were not too flatterring. Noel, Did you remember to ask them what was their title for the article, and when it was going to appear? I forgot. Kannan -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From owner-Big-Internet@munnari.oz.au Thu Jul 2 03:41:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11527; Thu, 2 Jul 1992 03:41:56 +1000 (from owner-Big-Internet) Return-Path: Received: from malgudi.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11523; Thu, 2 Jul 1992 03:41:49 +1000 (from kannan@oar.net) Received: from valhalla.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA03459; Wed, 1 Jul 1992 13:41:39 -0400 Message-Id: <199207011741.AA03459@malgudi.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: Tony Li Cc: VALDIS@VTVM1.CC.VT.EDU, kre@munnari.oz.au, big-internet@munnari.oz.au Reply-To: kannan@oar.net Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 01 Jul 92 09:05:55 -0700.<9207011605.AA05883@cider.cisco.com> Date: Wed, 01 Jul 92 13:44:48 -0400 From: Kannan Varadhan >>> From: Tony Li >>> Date: Wed, 01 Jul 92 09:05:55 PDT > Supernetting - a good idea, but I don't see how the regionals can win. > > The regionals win because they can now offer a new service to new > customers: address allocation. You don't go through the NIC and wait > N weeks. Your regional gives it to you today. Sorry, Tony, but that doesn't quite jell :-) The regionals win because a) the backbones win, i.e. the backbones don't go under, under the weight of the routing table computation complexities. b) the address space is more sensibly done, and hence, we put off a lumbering truck that says, there ain't no mo addresses, pal, which translates into more people on the internet, and more customers, etc. etc. etc. and what with all the market economies springing up these days, mo' money :-) The point is that while the direct benefits of CIDR are not immediately apparent, they do benefit the community in the short run. On another front, can we do cidr and c# in parallel? I believe that cidr is a superset of c# in terms of the technical problems we need to solve. For instance, cidr'd routes when advertised via egp or bgp3 require to be exploded into equivalent class a, b or c routes. c# is likewise. In both those cases, hosts can be made somewhat blissfully ignorant, or otherwise of classless nature of addresses, but all hosts on a local wire must be classful or classless, and we probably cannot have a mix of the two. Just some thoughts, (while desperately trying to catch up on the volume of traffic), Kannan -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From owner-Big-Internet@munnari.oz.au Thu Jul 2 03:53:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11766; Thu, 2 Jul 1992 03:53:31 +1000 (from owner-Big-Internet) Return-Path: Received: from malgudi.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11763; Thu, 2 Jul 1992 03:53:25 +1000 (from kannan@oar.net) Received: from valhalla.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA03522; Wed, 1 Jul 1992 13:53:12 -0400 Message-Id: <199207011753.AA03522@malgudi.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: postel@ISI.EDU Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us Reply-To: kannan@oar.net Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 01 Jul 92 09:08:04 -0700.<199207011608.AA21345@bel.isi.edu> Date: Wed, 01 Jul 92 13:56:22 -0400 From: Kannan Varadhan >>> From: postel@ISI.EDU >>> Date: Wed, 01 Jul 92 09:08:04 PDT > If CIDR addresses are assigned on a geographic basis rather than a > provider basis you could assign the addresses prior to provider > selection, and addresses need not change if you change providers. Yes, but then this, as the Deering area codes proposal for NSAP allocation shows us, requires all the providers in a area to cooperate with each other in some transitively closed manner; not really a reality at present, is it? Kannan -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From owner-Big-Internet@munnari.oz.au Thu Jul 2 04:05:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12043; Thu, 2 Jul 1992 04:06:05 +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 AA12033; Thu, 2 Jul 1992 04:05:56 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA19894; Wed, 1 Jul 92 11:05:27 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA05113; Wed, 1 Jul 92 11:05:28 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA20731; Wed, 1 Jul 92 11:05:08 PDT Date: Wed, 1 Jul 92 11:05:08 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9207011805.AA20731@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA22873; Wed, 1 Jul 92 11:05:22 PDT To: kannan@oar.net Cc: postel@isi.edu, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US In-Reply-To: <199207011753.AA03522@malgudi.oar.net> Subject: Re: Draft IESG recommendation on ROAD activities > > If CIDR addresses are assigned on a geographic basis rather than a > > provider basis you could assign the addresses prior to provider > > selection, and addresses need not change if you change providers. > > Yes, but then this, as the Deering area codes proposal for NSAP allocation > shows us, requires all the providers in a area to cooperate with each > other in some transitively closed manner; not really a reality at > present, is it? I thought that was exactly what does happens at FIX (E&W) and the CIX. They exchange routing information with each other. Bob From owner-Big-Internet@munnari.oz.au Thu Jul 2 04:06:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12053; Thu, 2 Jul 1992 04:06:38 +1000 (from owner-Big-Internet) Return-Path: Received: from malgudi.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12050; Thu, 2 Jul 1992 04:06:33 +1000 (from kannan@oar.net) Received: from valhalla.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA03625; Wed, 1 Jul 1992 14:06:23 -0400 Message-Id: <199207011806.AA03625@malgudi.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: Valdis Kletnieks Cc: Tony Li , big-internet@munnari.oz.au Reply-To: kannan@oar.net Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 01 Jul 92 12:58:32 -0400.<920701.125832.EDT.VALDIS@vtvm1.cc.vt.edu> Date: Wed, 01 Jul 92 14:09:33 -0400 From: Kannan Varadhan >>> From: Valdis Kletnieks >>> Date: Wed, 01 Jul 92 12:58:32 EDT > On Wed, 1 Jul 92 09:05:55 -0700 you said: > >The regionals win because they can now offer a new service to new > >customers: address allocation. You don't go through the NIC and wait > >N weeks. Your regional gives it to you today. > > Right. But the regional *only* wins if they get a commitment that in > 18 months (or whatever), the customer will choose *that* regional. > Otherwise, the regional just assumed all of the headache of managing > that address allocation, and some OTHER regional gets the traffic (and income) Ummm...in the cidr scheme of managing things, the regional defers getting an address until connect. (I know kre is going to jump on me soon :-) > Let's not lose sight of the fact that *90%* of all the allocated network > numbers are *NOT* connected to the Internet at the present time. > And I've seen *NO* evidence to suggest that *that* trend is likely to > change in the near future.... In Ohio, we have seen a mix of customers, some of whom came with their own address and said, connect us, and a fairly significant majority that said, gee connect us, and oh btw, what's an ip address? :-) cidr is based on the fundamental idea that the internet has not stopped growing yet, and in all probability, it is going to explode. It assumes that when someone wants to get an address from a central authority, they suggest at that time that the requestor defer getting one until they connect to the Internet, and at that time, get one from the provider. Just because things have been done one way "really" ought not be a justification for maintaining the status quo, should it? Kannan -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From owner-Big-Internet@munnari.oz.au Thu Jul 2 04:21:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12337; Thu, 2 Jul 1992 04:21:43 +1000 (from owner-Big-Internet) Return-Path: Received: from malgudi.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12334; Thu, 2 Jul 1992 04:21:34 +1000 (from kannan@oar.net) Received: from malgudi.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA03850; Wed, 1 Jul 1992 14:21:15 -0400 Message-Id: <199207011821.AA03850@malgudi.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: Bob.Hinden@eng.sun.com (Bob Hinden) Cc: postel@isi.edu, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, iesg@NRI.Reston.VA.US Reply-To: kannan@oar.net Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 01 Jul 92 11:05:08 -0700.<9207011805.AA20731@b5mail.Eng.Sun.COM> Date: Wed, 01 Jul 92 14:21:14 -0400 From: Kannan Varadhan >>> From: Bob.Hinden@eng.sun.com (Bob Hinden) >>> Date: Wed, 01 Jul 92 11:05:08 PDT >> > If CIDR addresses are assigned on a geographic basis rather than a >> > provider basis you could assign the addresses prior to provider >> > selection, and addresses need not change if you change providers. >> > Yes, but then this, as the Deering area codes proposal for NSAP allocation >> shows us, requires all the providers in a area to cooperate with each >> other in some transitively closed manner; not really a reality at >> present, is it? > I thought that was exactly what does happens at FIX (E&W) and the CIX. > They exchange routing information with each other. Ummm...I could think of a few numerous unworkable situations, but taking just the most popular, look at how much paroxysms we are going through to get just ANS and the CIS folks talking? And they are just 2 entities in 2 places. Kannan -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From owner-Big-Internet@munnari.oz.au Thu Jul 2 04:22:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12345; Thu, 2 Jul 1992 04:22:24 +1000 (from owner-Big-Internet) Return-Path: Received: from cincsac.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12342; Thu, 2 Jul 1992 04:22:17 +1000 (from medin@nsipo.nasa.gov) Received: Wed, 1 Jul 92 11:21:54 PDT from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (4.1/1.5T) Message-Id: <9207011821.AA15866@cincsac.arc.nasa.gov> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: Re: Big Time In-Reply-To: Your message of "Wed, 01 Jul 92 10:55:54 EDT." <9207011455.AA10744@ginger.lcs.mit.edu> Date: Wed, 01 Jul 92 11:21:54 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Yup, a reporter from comm. week called me asking for comment about the IAB recommending a transition to ISO to deal with the address space problem as well. Looks like things are really confused out there. They think people are talking about GOSIP format CLNP, not what we're talking about. Confusion reigns. Thanks, Milo From owner-Big-Internet@munnari.oz.au Thu Jul 2 04:22:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12354; Thu, 2 Jul 1992 04:23:01 +1000 (from owner-Big-Internet) Return-Path: Received: from malgudi.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12351; Thu, 2 Jul 1992 04:22:54 +1000 (from kannan@oar.net) Received: from valhalla.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA03855; Wed, 1 Jul 1992 14:22:49 -0400 Message-Id: <199207011822.AA03855@malgudi.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: Robert Elz Cc: jnc@ginger.lcs.mit.edu (Noel Chiappa), big-internet@munnari.oz.au, iesg@nri.reston.va.us Reply-To: kannan@oar.net Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 01 Jul 92 18:28:38 +1000.<18220.709979318@munnari.oz.au> Date: Wed, 01 Jul 92 14:25:58 -0400 From: Kannan Varadhan >>> From: Robert Elz >>> Date: Wed, 01 Jul 92 18:28:38 +1000 > If part of implementing CIDR is going to mean requiring everyone > to renumber - ideally sites already on the net, and new sites > joining, which would be required for maximum benefit, then its > doomed already. That is simply not going to happen. Neither Tony already spelled out potentials in doing cidr. Let me add one bit. Dave Oran spelled out one potential doom for cidr, which was fairly interesting. According to him (and I summarise here, and he may step in and explain it better), cidr will fall apart when the entropy in the system attains infinity, due to a good majority of the sites switching providers ever so often, as to completely eliminate any potential for aggregation. In the bad case, cidr requires that sites that move, or are multi-homed require multiple advertisements. It recommends that sites renumber to reduce this entropy, but may not happen. This will ultimately cause cidr to fall apart. It is also expected that this will happen in the much longer term (length of time is relative, as, for instance, egp2 is a "short term solution :-). By the time this entropy, and resultant atrophisation sets in, some other solution such as pip, clnp, nimrod, osi or other is in place, and starting to reap significant benefits. > Until they join, they might just as well use 192.9.200 or > whatever that number is that Sun used to ship; > > Aside - has anyone noticed that 192.9.200 seems to have > been allocated (re-allocated) to some poor unfortunate now ? > >From the latest network-contacts.txt from the NIC ... > > 192.9.200.0 C CENDATA > McGrath, Robert (RM524) cendata!cendata!mcgrath@uunet.uu.net > (217) 359-8010 ext 247 Oh boy, joy of joys. Has anyone told them about this? :-) > What a devious form or torture to inflict on a site! And they have both of their name servers in the same address space. > Sun used to own the whole 192.9 block, but no more it appears? > > Back to the point, I said... > I still think its necessary to start on C# now > Noel replied... > What's to start on, other than implementation? > > Nothing, that's the point - except that probably most of the > people who count won't comit to doing it until C# is blessed. > After all, if your router decides that C# is a new class, then > the IAB/IESG/... decides not to go ahead (that is, confirms the > current recommendation) then you're going to have a broken > implementation once class C numbers in the C# range start > being assigned. We do need the "C# is a new class" edict. The problem with C# is that it propogates the classful IP myth, which the HR RFC explicitly says is a bad idea, and everyone is trying to stamp out. It would probably take just as much time now to porpogate a new class as to go to a classless IP, so why C#? Kannan -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From owner-Big-Internet@munnari.oz.au Thu Jul 2 04:35:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12655; Thu, 2 Jul 1992 04:35:50 +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 AA12638; Thu, 2 Jul 1992 04:35:31 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA26954; Wed, 1 Jul 92 12:35:19 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA07328; Wed, 1 Jul 92 12:35:18 MDT Message-Id: <9207011835.AA07328@goshawk.lanl.gov> To: Robert Elz Cc: big-internet@munnari.oz.au Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 01 Jul 92 09:38:41 +1000. <9206302338.13299@munnari.oz.au> Date: Wed, 01 Jul 92 12:35:17 MST From: peter@goshawk.lanl.gov > But there are lots of vendor reps on this list, far more than I have access > to implementations from. Is there anyone at all who cares to admit that > their (host) implementation won't allow a subnet mask < 24 bits on a class C? A similar question could be asked about running multiple C's on a single physical net. (hack, hack, hack ...) peter From owner-Big-Internet@munnari.oz.au Thu Jul 2 04:59:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13217; Thu, 2 Jul 1992 04:59: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 AA13212; Thu, 2 Jul 1992 04:59:02 +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 6309; Wed, 01 Jul 92 14:57:46 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 8876; Wed, 01 Jul 92 14:57:46 EDT Date: Wed, 01 Jul 92 14:19:43 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Draft IESG recommendation on ROAD activities To: Kannan Varadhan Cc: Tony Li , big-internet@munnari.oz.au In-Reply-To: <199207011806.AA03625@malgudi.oar.net> Message-Id: <920701.141943.EDT.VALDIS@vtvm1.cc.vt.edu> On Wed, 01 Jul 92 14:09:33 -0400 you said: >cidr is based on the fundamental idea that the internet has not stopped >growing yet, and in all probability, it is going to explode. It assumes >that when someone wants to get an address from a central authority, they >suggest at that time that the requestor defer getting one until they >connect to the Internet, and at that time, get one from the provider. > > Just because things have been done one way "really" ought not be > a justification for maintaining the status quo, should it? Yes, but it's often quite informative to contemplate *why* something has worked for a long time before changing it. I see the ability to decouple setting up a net and choosing a provider as being a very useful thing to preserve. This is starting to sound more and more like we're advocating saying "If you didn' choose a net provider when you bought that first spool of thinwire, we'd *really* like it if you renumber your entire internal network when you connect". Does anybody have any numbers on what percent of sites have changed primary providers in the last 5 years? How much would these type of "holes" impact supernetting? Seems to me that if you are supernetting 16 nets together, and *one* changes providers, you're left with a block of 8, a 4, a 2, and 2 singletons (one of which is now routed via some other provider). Does anybody have a good estimate what the "holes" will do in practice? /Valdis P.S. Are the regionals ready to pick up all the administrivia load that would be caused if we actually implemented this? I forsee an increased workload - only partially because of the actual registration. The rest is likely to be things like sites with *NO* TCP/IP experience saying "Well, we've had to choose a net provider, let's get connected".. From owner-Big-Internet@munnari.oz.au Thu Jul 2 05:34:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13877; Thu, 2 Jul 1992 05:34:47 +1000 (from owner-Big-Internet) Return-Path: Received: from cody.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13874; Thu, 2 Jul 1992 05:34:39 +1000 (from rrv@cody.cso.uiuc.edu) Received: by cody.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03) id AA23006; Wed, 1 Jul 1992 14:34:34 -0500 Date: Wed, 1 Jul 1992 14:34:34 -0500 From: rrv@cody.cso.uiuc.edu (Ross Veach) Message-Id: <9207011934.AA23006@cody.cso.uiuc.edu> To: kannan@oar.net Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au > but all hosts on a local wire must be classful or classless, and we > probably cannot have a mix of the two. I don't agree. At least in my environment (10,000+ hosts) very few hosts can see more than one router, and I'd like to eleminate even those few. The routers broadcast a RIP default route only, and that to the all ones IP broadcast address. The routers also run Proxy ARP. We've got hosts with all kinds of subnet masks, some too big, some too small, some with none at all (just the network mask). The only real requirement is that a host must believe it's on the same wire with its router. If hosts don't need to understand routing (they don't if they're only exposed to 1 router), and if we only allocate classless networks in the old class C part of the address space (a decision), and if people only use 254 host subnets or smaller (likely), there are no host related problems period. From owner-Big-Internet@munnari.oz.au Thu Jul 2 05:43:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14073; Thu, 2 Jul 1992 05:43:24 +1000 (from owner-Big-Internet) Return-Path: Received: from malgudi.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14064; Thu, 2 Jul 1992 05:43:15 +1000 (from kannan@oar.net) Received: from valhalla.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA04616; Wed, 1 Jul 1992 15:43:06 -0400 Message-Id: <199207011943.AA04616@malgudi.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: Valdis Kletnieks Cc: Tony Li , big-internet@munnari.oz.au Reply-To: kannan@oar.net Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 01 Jul 92 14:19:43 -0400.<920701.141943.EDT.VALDIS@vtvm1.cc.vt.edu> Date: Wed, 01 Jul 92 15:46:15 -0400 From: Kannan Varadhan >>> From: Valdis Kletnieks >>> Date: Wed, 01 Jul 92 14:19:43 EDT > On Wed, 01 Jul 92 14:09:33 -0400 you said: > > Just because things have been done one way "really" ought not be > > a justification for maintaining the status quo, should it? > > Yes, but it's often quite informative to contemplate *why* something has > worked for a long time before changing it. I see the ability to > decouple setting up a net and choosing a provider as being a very useful > thing to preserve. yes, verily so. > This is starting to sound more and more like we're advocating saying "If > you didn' choose a net provider when you bought that first spool of > thinwire, we'd *really* like it if you renumber your entire internal > network when you connect". But, nothing in the cidr document said that. It only said, gee, it would be nice if you picked your address space out of your providers, and we would very much like you to do so, because of (a), (b), and (c) and so on, and so forth. It is matter of reality that folks are going to change providers, to come with pre-acquired addresses, folks are going to become multi-homed etc. This is what leads to the entropy that I mentioned in an earlier message. cidr is not saying `renumber or die.' > Does anybody have any numbers on what percent of sites have changed > primary providers in the last 5 years? How much would these type of > "holes" impact supernetting? Seems to me that if you are supernetting > 16 nets together, and *one* changes providers, you're left with a block > of 8, a 4, a 2, and 2 singletons (one of which is now routed via some > other provider). Does anybody have a good estimate what the "holes" > will do in practice? The cidr documents gave some numbers based on statistics on how many sites are multi-homed and what their growth trends have been. IMHO, I believe cidr will die, not so much from people changing providers, as from their becoming more and more multi-homed, because of economics, policies, etc. In spite of that cidr would be the right way to go. > P.S. Are the regionals ready to pick up all the administrivia load that > would be caused if we actually implemented this? I forsee an increased > workload - only partially because of the actual registration. The rest > is likely to be things like sites with *NO* TCP/IP experience saying > "Well, we've had to choose a net provider, let's get connected".. Most regionals are already doing this. On OARnet, part of your coming to us for a connection is in us first verifying that you have a valid IP address, and then qorking on getting your domain name, IP address, reverse mapping etc. etc. We have a small block of class Cs that we keep around, and hand out to customers as they join us. This is has not strained our administrative resources much. Kannan -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From owner-Big-Internet@munnari.oz.au Thu Jul 2 05:54:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14223; Thu, 2 Jul 1992 05:54: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 AA14220; Thu, 2 Jul 1992 05:54:14 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13781; Wed, 1 Jul 92 15:54:10 -0400 Date: Wed, 1 Jul 92 15:54:10 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207011954.AA13781@ginger.lcs.mit.edu> To: rrv@cody.cso.uiuc.edu Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, jnc@ginger.lcs.mit.edu First, a logistical note; I'm soon going to start dropping the IESG and IAB as extra CC's on this series. Any member of either body which aren't already on this list, and who want to hear this, should send mail to 'big-internet-request@munnari.oz.au'. I don't know where the class C# document is; it's an ID, I know. The difference between C# and CIDR is in most respects minor, as you point out. However, in one major way, it really quite substantial. In C# (and the Internet now), you can tell very easily, by looking at just the 32 bits of an internet address, where the significance boundaries are; i.e. if the high bit is 0, the top 7 bits after that are a network number, etc. In CIDR, you can't tell anything about anything without having a mask as well as an address. Many routing protocols (e.g. RIP, IGRP (I think), EGP, BGP-3) don't carry around a mask, and thus have to be substantially modifed (i.e. packet formats changed) to work with CIDR, if they are going to be modified at all (EGP probably will not be). I would rate this as significant. Noel From owner-Big-Internet@munnari.oz.au Thu Jul 2 05:56:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14346; Thu, 2 Jul 1992 05:57:02 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14341; Thu, 2 Jul 1992 05:56:55 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA13829; Wed, 1 Jul 92 15:56:50 -0400 Date: Wed, 1 Jul 92 15:56:50 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207011956.AA13829@ginger.lcs.mit.edu> To: kannan@oar.net Subject: Re: Big Time Cc: big-internet@munnari.oz.au, iesg@nri.reston.va.us, jnc@ginger.lcs.mit.edu No on both counts, but I got the impression she was rushing to meet a deadline. Wonder how they got onto the story? Noel From owner-Big-Internet@munnari.oz.au Thu Jul 2 06:06:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14590; Thu, 2 Jul 1992 06:06:58 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14580; Thu, 2 Jul 1992 06:06:53 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Wed, 1 Jul 92 13:06:25 -0700 Date: Wed, 1 Jul 92 13:06:25 -0700 From: Tony Li Message-Id: <9207012006.AA11332@cider.cisco.com> To: VALDIS@VTVM1.CC.VT.EDU Cc: kannan@oar.net, tli@cisco.com, big-internet@munnari.oz.au In-Reply-To: Valdis Kletnieks's message of Wed, 01 Jul 92 14:19:43 EDT <920701.141943.EDT.VALDIS@vtvm1.cc.vt.edu> Subject: Draft IESG recommendation on ROAD activities Seems to me that if you are supernetting 16 nets together, and *one* changes providers, you're left with a block of 8, a 4, a 2, and 2 singletons (one of which is now routed via some other provider). That's not the way that supernetting works. If one changes providers, you continue to advertise the aggregate. The new provider needs to advertise the one net that moved. Since it has a longer mask, the new regional gets the traffic for that net. Tony From owner-Big-Internet@munnari.oz.au Thu Jul 2 06:17:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14861; Thu, 2 Jul 1992 06:17:55 +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 AA14855; Thu, 2 Jul 1992 06:17:47 +1000 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA03758; Wed, 1 Jul 92 13:17:28 -0700 Date: Wed, 1 Jul 92 13:17:27 PDT From: Vince Fuller To: Geoff Huston Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 1 Jul 92 15:30:23 +1000 Message-Id: A couple of comments about the CIDR/C# debate: Noel puts forward the proposition that the anticipated behaviour is that _until_ the entity connects to the internet they may as well use any old number, and renumber themselves at the point in time when they connect:... i.e.: you *can't* assign them a 'permanent' address *until* they join up, and you know where they are in the topology. Which I'd contend is precisely what we want to _avoid_. Speaking as a US regional network operator, I would observe that in many cases, this is a non-issue. Many, if not most, of our new members didn't even have a network number when they came to us. In fact, if we were able to allocate, CIDR-style, a piece of address space already assigned to us we would have not only reduced routing table load but also would have been able to connect the new site a lot quicker since there'd be no wait for the NIC to hand out a new number. One of the recommendations made by the CIDR/Supernetting paper is that service providers be allocated large blocks of space for further allocation to their clients. Not only does this allow "supernetting" to reduce routing table space but it also distributes the administrative load of network number allocation out from the center. is a perfectly valid comment. What I am trying to say is just that CIDR may prove to be a 20% solution rather than 80%. Its not the elegance or otherwise I'm worried about in the C# / CIDR issue - its whether CIDR will make any difference at all in the routing table size and in the length or time remaining until allocatable address space exhaustion. I don't understand this argument. As previously discussed between KRE and TLI, the pieces of the Internet that have to change to support C# are the same pieces which must change for CIDR - i.e. the routing protocols and transit routers either have to learn about C# network numbers or about classless. Given that CIDR provides a superset of C#'s functionality with not much more deployment time cost, why do C#? Remember also that C# requires that we make a hard-and-fast decision to permanently allocate half of the remaining class-C space to support fixed-sized networks. CIDR gets away from these rigid network size classifications and allows more flexibility, even if no benefit can be acheived through the "supernetting" technique. --Vince From owner-Big-Internet@munnari.oz.au Thu Jul 2 06:21:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14943; Thu, 2 Jul 1992 06:21:43 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207012021.14943@munnari.oz.au> Received: from segin.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14938; Thu, 2 Jul 1992 06:21:29 +1000 (from HUSTON@PROCESS.COM) Date: Wed, 1 Jul 1992 16:21 -0400 From: HUSTON@PROCESS.COM (Steve Huston) To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au Subject: Re: Big Time > No on both counts, but I got the impression she was rushing to >meet a deadline. Wonder how they got onto the story? Last time Comm Week ran an article (on SMP) the writer of the story sent a note to the SNMP discussion mailing list looking for more info. I'd bet they've been watching this list for the last few weeks... -Steve From owner-Big-Internet@munnari.oz.au Thu Jul 2 06:33:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15178; Thu, 2 Jul 1992 06:34:15 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207012034.15178@munnari.oz.au> Received: from alcor.process.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15162; Thu, 2 Jul 1992 06:33:53 +1000 (from ULLMANN@PROCESS.COM) Date: Wed, 1 Jul 1992 16:31 -0400 From: ULLMANN@PROCESS.COM (Robert L Ullmann) To: big-internet@munnari.oz.au Subject: FWD: Re: Big Time From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Subject: Re: Big Time No on both counts, but I got the impression she was rushing to meet a deadline. Wonder how they got onto the story? Noel Oh, maybe they read this list? (or at least the IETF list) Communications Weak is published by CMP Publications: CMP Publications Inc. (CMP-DOM) 600 Community Drive, Manhasset, New York, 11030 Domain Name: CMP.COM Administrative Contact: Mercer, Jim (JM233) jimm@CMP.COM (516) 562-5000 Technical Contact, Zone Contact: Fulton, Sean (SF91) sean@CMP.COM (516) 562-5430 Both of those names sound familiar. One expects that they sometimes talk to the editorial staff, eh? :-) Rob From owner-Big-Internet@munnari.oz.au Thu Jul 2 06:40:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15289; Thu, 2 Jul 1992 06:40:22 +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 AA15284; Thu, 2 Jul 1992 06:40:10 +1000 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA03870; Wed, 1 Jul 92 13:39:59 -0700 Date: Wed, 1 Jul 92 13:39:59 PDT From: Vince Fuller To: Valdis Kletnieks Cc: Kannan Varadhan , Tony Li , big-internet@munnari.oz.au Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 01 Jul 92 14:19:43 EDT Message-Id: Does anybody have any numbers on what percent of sites have changed primary providers in the last 5 years? How much would these type of "holes" impact supernetting? Seems to me that if you are supernetting 16 nets together, and *one* changes providers, you're left with a block of 8, a 4, a 2, and 2 singletons (one of which is now routed via some other provider). Does anybody have a good estimate what the "holes" will do in practice? Please read the document, which analyzes this case in detail. Basically, in this case the first provider continues to advertise the block of 16. The second provider explicitly advertises the single network which moved. Based on the rule of longest-match routing, the route to the single network is preferred. Things are slightly more complicated when the multi-homing is considered, but that too is covered by the document. As Kannan and I both pointed-out, a *lot* of the new sites connecting to the Internet *don't* have existing network numbers (and, in fact, don't even know what a network number is until we explain it to them). For these sites, obtaining their network number from a service provider rather than the central NIC is a blessing not a curse. --Vince From owner-Big-Internet@munnari.oz.au Thu Jul 2 06:44:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15388; Thu, 2 Jul 1992 06:44:25 +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 AA15385; Thu, 2 Jul 1992 06:44:16 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA00573; Wed, 1 Jul 92 14:44:09 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA08388; Wed, 1 Jul 92 14:44:08 MDT Message-Id: <9207012044.AA08388@goshawk.lanl.gov> To: big-internet@munnari.oz.au Subject: Re: Draft IESG recommendation on ROAD activities Date: Wed, 01 Jul 92 14:44:07 MST From: peter@goshawk.lanl.gov A critical element to success is a reasonable addressing plan, one which helps determine the correct (as close as you can get) address for a site/campus. This is one of those nasty multidimensional problems which depends on factors like number of end-hosts, are they believers in the bridging or routing religions, where in the global internet routing hierarchy are they, etc. It would appear that CIDR and C# may be able to live with similar addressing plans. The point of CIDR is that you can do more than cause clumping of 16 Cs into a C# network. This aggregation can have impact at several places in the routing hierarchy, with the large "backbone" networks such as the NSFnet, NSI, Ebone having the highest probablility of blowing EBone, etc. Perhaps we need to have a plan which includes C# style addressing, but will allow for management and aggregation of C# networks by using CIDR? Does this make sense or does it simply add to the confusion? This could allow people to use either C# or CIDR or both or neither. By using a regional plan of assigning addresses, it will be possible to get real and significant reduction in route advertisements into the networks which hold the global internet together. Partially addressing Geoff Huston's concerns this will allow address assignment prior to carrier selection. It will force the carriers (funny title given the current players in the game) to conform to some restrictions in topology (CIXes, GIXes, etc), but this is the price to be paid to get the job done. Perhaps when the problem is reduced to : 128 class As + 16K class Bs + 64K class C#s + 1M class Cs we can just use super-routers? cheers, peter From owner-Big-Internet@munnari.oz.au Thu Jul 2 06:50:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15521; Thu, 2 Jul 1992 06:50:21 +1000 (from owner-Big-Internet) Return-Path: Received: from cody.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15518; Thu, 2 Jul 1992 06:50:14 +1000 (from rrv@cody.cso.uiuc.edu) Received: by cody.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03) id AA19779; Wed, 1 Jul 1992 15:50:03 -0500 Date: Wed, 1 Jul 1992 15:50:03 -0500 From: rrv@cody.cso.uiuc.edu (Ross Veach) Message-Id: <9207012050.AA19779@cody.cso.uiuc.edu> To: jnc@ginger.lcs.mit.edu Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us > Many routing protocols (e.g. RIP, IGRP (I think), EGP, BGP-3) don't > carry around a mask, and thus have to be substantially modifed (i.e. packet > formats changed) to work with CIDR, if they are going to be modified at all > (EGP probably will not be). You have a point. The code has to change in both cases, but not the packet format. Except EGP would have to change packet format if we wanted to allow peering over on C#. I would argue that isn't even desirable. There are certainly ways around it (DMZ). RIP and IGRP (like you, I think) within a subnetted network use statically configured masks that are not part of the protocol, so your point doesn't hold there. We should find out if IGRP carries a mask, but I don't think RIP is used much as an IGP for transit networks. Still, we could start today allocating 12-bit networks in the C# space and smaller networks in the other part of the C space. I have more to say, but I've got to run... From owner-Big-Internet@munnari.oz.au Thu Jul 2 06:52:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15585; Thu, 2 Jul 1992 06:52:45 +1000 (from owner-Big-Internet) Return-Path: Received: from cincsac.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15582; Thu, 2 Jul 1992 06:52:27 +1000 (from medin@nsipo.nasa.gov) Received: Wed, 1 Jul 92 13:51:26 PDT from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (4.1/1.5T) Message-Id: <9207012051.AA16286@cincsac.arc.nasa.gov> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: kannan@oar.net, big-internet@munnari.oz.au, iesg@nri.reston.va.us Subject: Re: Big Time In-Reply-To: Your message of "Wed, 01 Jul 92 15:56:50 EDT." <9207011956.AA13829@ginger.lcs.mit.edu> Date: Wed, 01 Jul 92 13:51:25 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Well I just talked to her again. She had gotten a draft of the IAB draft from Lyman, and was talking to him about some of thsi stuff. It seems that other people she had talked to were flaming the IAB something awful about pre-mature decisions, etc... She also seemed to have the impression that the IAB was only going to be accepting comments for a week, and then would move forward, and that people had pretty much made up their minds on the subject. I don't know where she got this viewpoint, but I assured her a lot of hard issues need serious thinking still, and that it's premature to decide what exactly to do right now. This issue about confusing IPv7 being based on CLNP packet formats and converting Internet to GOSIP protocols will be a BIG problem unless it's handled straightforwardly. Certainly, we do not want our IP vendors to be chewed up in the marketplace by OSI vendors telling customers that the Internet is being converted to OSI protocols shortly. Can you imagine what a good marketing guy will do with this? Thanks, Milo From owner-Big-Internet@munnari.oz.au Thu Jul 2 06:56:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15663; Thu, 2 Jul 1992 06:56:49 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15656; Thu, 2 Jul 1992 06:56:40 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA14293; Wed, 1 Jul 92 16:56:26 -0400 Date: Wed, 1 Jul 92 16:56:26 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207012056.AA14293@ginger.lcs.mit.edu> To: kannan@oar.net Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us The problem with C# is that it propogates the classful IP myth, which the HR RFC explicitly says is a bad idea Whoa! The goal of the HR RFC is that *hosts* should not be in the business of parsing addresses, not that classes are bad (with which I might agree, after some thought), or that routers should not know about classes. The whole point of this was to allow just what we see now; a change to the parsing of addresses which does not affect all the hosts, but simply the routers, on the grounds that the routers are a smaller and more easily changed (I know, this is relative, after all) group of machines. Noel From owner-Big-Internet@munnari.oz.au Thu Jul 2 07:33:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16390; Thu, 2 Jul 1992 07:33:38 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16386; Thu, 2 Jul 1992 07:33:31 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Wed, 1 Jul 92 14:33:01 -0700 Date: Wed, 1 Jul 92 14:33:01 -0700 From: Tony Li Message-Id: <9207012133.AA14267@cider.cisco.com> To: rrv@cody.cso.uiuc.edu Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us In-Reply-To: Ross Veach's message of Wed, 1 Jul 1992 15:50:03 -0500 <9207012050.AA19779@cody.cso.uiuc.edu> Subject: Draft IESG recommendation on ROAD activities We should find out if IGRP carries a mask, but I don't think RIP is used much as an IGP for transit networks. IGRP does not carry a mask, but it is frequently used as the IGP for transit networks. Tony From owner-Big-Internet@munnari.oz.au Thu Jul 2 07:36:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16445; Thu, 2 Jul 1992 07:36:40 +1000 (from owner-Big-Internet) Return-Path: Received: from animal.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16439; Thu, 2 Jul 1992 07:36:29 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA20734; Wed, 1 Jul 92 17:32:12 EDT Date: Wed, 1 Jul 92 17:32:12 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9207012132.AA20734@animal.clearpoint.com> To: peter@goshawk.lanl.gov, big-internet@munnari.oz.au Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Mail from 'peter@goshawk.lanl.gov' dated: Wed, 01 Jul 92 14:44:07 MST To answer an earlier question, the current C# draft is anon-FTPable from both munnari.oz.au and nnsc.nsf.net; on the former system, it's in big-internet/rfc-bigip.txt.2, on the latter system, it's under the unfortunate name "internet-drafts/draft-solensky-csharp-00.txt" (i think) From Kannan Varadhan : >On another front, can we do cidr and c# in parallel? I believe >that cidr is a superset of c# in terms of the technical problems >we need to solve. For instance, cidr'd routes when advertised >via egp or bgp3 require to be exploded into equivalent class a, >b or c routes. c# is likewise. In both those cases, hosts can >be made somewhat blissfully ignorant, or otherwise of classless >nature of addresses, but all hosts on a local wire must be >classful or classless, and we probably cannot have a mix of the >two. >From Peter Ford : >It would appear that CIDR and C# may be able to live with similar >addressing plans. ... Perhaps we need to have a plan which includes C# style >addressing, but will allow for management and aggregation of C# networks by >using CIDR? Does this make sense or does it simply add to the confusion? >This could allow people to use either C# or CIDR or both or neither. Seems like a viable option... use, say, the upper quarter of the C-space as nets consisting of 8-K nodes or more, the other quarter would continue to be 254 nodes or less.. this would still allow the aggreation to occur.. (maybe call them 'C-sharp major/minor' since we're coming to .. a chord?) If we've all agreed that the programming effort for both options is reasonably low, then the incremental cost won't be overwhelming. and I see that Robert Elz mentions the same in a message I received while trying to type this one in.. I can update the draft if this becomes the consensus opinion, but, again, I think that the main thing is that _something_ be done SOON and that the something should be CIDR: while renumbering systems would be nice, it's not a strict requirement for a network to maintain connectivity after changing service providers. >From Kannan Varadhan : >The problem with C# is that it propogates the classful IP myth, which >the HR RFC explicitly says is a bad idea Can't help thinking that we're getting ever closer to the point where IP itself may be a myth :-) -- Frank From owner-Big-Internet@munnari.oz.au Thu Jul 2 07:49:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16684; Thu, 2 Jul 1992 07:49:36 +1000 (from owner-Big-Internet) Return-Path: Received: from malgudi.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16681; Thu, 2 Jul 1992 07:49:30 +1000 (from kannan@oar.net) Received: from valhalla.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA06254; Wed, 1 Jul 1992 17:49:23 -0400 Message-Id: <199207012149.AA06254@malgudi.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Reply-To: kannan@oar.net Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 01 Jul 92 15:54:10 -0400.<9207011954.AA13781@ginger.lcs.mit.edu> Date: Wed, 01 Jul 92 17:52:32 -0400 From: Kannan Varadhan >>> From: jnc@ginger.lcs.mit.edu (Noel Chiappa) >>> Date: Wed, 01 Jul 92 15:54:10 EDT > In C# (and the Internet now), you can tell very easily, by looking at > just the 32 bits of an internet address, where the significance boundaries > are; i.e. if the high bit is 0, the top 7 bits after that are a network > number, etc. In CIDR, you can't tell anything about anything without having a > mask as well as an address. Well host entities that do it today will have to recognise c# as address+mask, or at least BSD hosts that kre was talking about. Else, the hosts will have to change. As you pointed out earlier, the HR RFC does require hosts to become classless, not classful, with yet another class. Routers are going to have to change anyway, c# or cidr. > Many routing protocols (e.g. RIP, IGRP (I think), EGP, BGP-3) don't > carry around a mask, and thus have to be substantially modifed (i.e. packet > formats changed) to work with CIDR, if they are going to be modified at all > (EGP probably will not be). There's rip2 in the works, ospf already views routes as net+mask, bgp4 is coming along. EGP would still need to be modified for c#. RIP (and IGRP?) could blissfully thrash along with C# as they do today, or would they? Taking Ross' scenario earlier, whereby broadcast addresses are 255.255.255.255, throwing in one host with a class C# address, another with a c# address faked to look as a class C address (it is a dec20 that did not understand even subnets :-), would not the c# host view all the advertisements from the dec20 as being host routes in RIP? Ross? > I would rate this as significant. So, what's the point? Kannan -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From owner-Big-Internet@munnari.oz.au Thu Jul 2 08:18:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17284; Thu, 2 Jul 1992 08:18:34 +1000 (from owner-Big-Internet) Return-Path: Received: from animal.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17281; Thu, 2 Jul 1992 08:18:26 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA20830; Wed, 1 Jul 92 18:14:29 EDT Date: Wed, 1 Jul 92 18:14:29 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9207012214.AA20830@animal.clearpoint.com> To: solensky@animal.clearpoint.com, peter@goshawk.lanl.gov, big-internet@munnari.oz.au Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Mail from 'solensky@animal (Frank T. Solensky)' dated: Wed, 1 Jul 92 17:32:12 EDT >Seems like a viable option... use, say, the upper quarter of the C-space as >nets consisting of 8-K nodes or more, the other quarter would continue to be >254 nodes or less.. this would still allow the aggreation to occur.. On second thought, this would be doing it backwards. The goal of the whole CIDR exercise is truly classless addresses, this would reduce it to "almost classless". It also suffers from having to look at the leading five bits in order to make a decision on what default mask to use. -- Frank From owner-Big-Internet@munnari.oz.au Thu Jul 2 08:38:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17821; Thu, 2 Jul 1992 08:38:32 +1000 (from owner-Big-Internet) Return-Path: Received: from malgudi.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17818; Thu, 2 Jul 1992 08:38:24 +1000 (from kannan@oar.net) Received: from malgudi.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA06590; Wed, 1 Jul 1992 18:37:59 -0400 Message-Id: <199207012237.AA06590@malgudi.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: solensky@animal.clearpoint.com (Frank T. Solensky) Cc: peter@goshawk.lanl.gov, big-internet@munnari.oz.au Reply-To: kannan@oar.net Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 01 Jul 92 17:32:12 -0400.<9207012132.AA20734@animal.clearpoint.com> Date: Wed, 01 Jul 92 18:37:58 -0400 From: Kannan Varadhan >>> From: solensky@animal.clearpoint.com (Frank T. Solensky) >>> Date: Wed, 01 Jul 92 17:32:12 EDT > >From Kannan Varadhan : > >The problem with C# is that it propogates the classful IP myth, which > >the HR RFC explicitly says is a bad idea > > Can't help thinking that we're getting ever closer to the point where IP > itself may be a myth :-) yeah, and you could tell you grandchildren, "well, kids, in *those* days, we had this thing called IP with 4 byte addresses . . . " Kannan -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From owner-Big-Internet@munnari.oz.au Thu Jul 2 08:39:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17849; Thu, 2 Jul 1992 08:39:38 +1000 (from owner-Big-Internet) Return-Path: Received: from cruskit.aarnet.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17846; Thu, 2 Jul 1992 08:39:33 +1000 (from gih900@cruskit.aarnet.edu.au) Received: by cruskit.aarnet.edu.au id AA09390 (5.65+/IDA-1.3.5 for big-internet@munnari.oz.au); Thu, 2 Jul 92 08:39:19 +1000 Date: Thu, 2 Jul 92 08:39:19 +1000 From: Geoff Huston Message-Id: <9207012239.AA09390@cruskit.aarnet.edu.au> To: tli@cisco.com, kre@munnari.oz.au, VALDIS@VTVM1.CC.VT.EDU Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au On Wed, 1 Jul 92 06:48:12 -0700 Tony Li said: >The site does not have to enable supernetting. It just gets its >number from its regional. The regional worries about supernetting. Supernetting - a good idea, but I don't see how the regionals can win. Do the regionals have to care? The problem with the routing space is NOT in a site - they have default rather than carrying around 7,500 nets. The problem with the routing space need NOT be the regionals - they can engineer default so as to limit routing entries to thousands (rather than hundreds of thousands) of entries in the worst case, and often can engineer default to get the number of routing entries in the high hundreds / low thousands. So they are not the problem. The problem with routing space happens on those operators who call themselves backbones and who don't (or can't) use default to mask off a whole heap of entries. SO - economically its in a regional's best interest to accept ANY net number that a customer wants to throw at them - thats just good business. The routing problem doesn't get critical within the domain of the regional - the routing problem simply gets shunted upward into the backbone operators - who do not have ANY econmomic clout to get anyone to renumber as they do not deal directly with the end client base. So I'd suggest that Tony's reasoning that you can bias the market towards renumbering to allow aggregation starting at the regional level may not adequately describe the situation. It would appear to be pulling at the wrong lever! Geoff From owner-Big-Internet@munnari.oz.au Thu Jul 2 08:41:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17907; Thu, 2 Jul 1992 08:41:31 +1000 (from owner-Big-Internet) Return-Path: Received: from cruskit.aarnet.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17899; Thu, 2 Jul 1992 08:41:23 +1000 (from gih900@cruskit.aarnet.edu.au) Received: by cruskit.aarnet.edu.au id AA09396 (5.65+/IDA-1.3.5 for big-internet@munnari.oz.au); Thu, 2 Jul 92 08:41:03 +1000 Date: Thu, 2 Jul 92 08:41:03 +1000 From: Geoff Huston Message-Id: <9207012241.AA09396@cruskit.aarnet.edu.au> To: VALDIS@VTVM1.CC.VT.EDU, tli@cisco.com Subject: Re: Draft IESG recommendation on ROAD activities Cc: kre@munnari.oz.au, big-internet@munnari.oz.au Tony, Supernetting - a good idea, but I don't see how the regionals can win. The regionals win because they can now offer a new service to new customers: address allocation. You don't go through the NIC and wait N weeks. Your regional gives it to you today. when N = 1 this is not an overwhelmingly good line of reasoning. Geoff From owner-Big-Internet@munnari.oz.au Thu Jul 2 08:46:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18136; Thu, 2 Jul 1992 08:46:29 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18124; Thu, 2 Jul 1992 08:46:16 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Wed, 1 Jul 92 15:46:01 -0700 Date: Wed, 1 Jul 92 15:46:01 -0700 From: Tony Li Message-Id: <9207012246.AA22002@cider.cisco.com> To: G.Huston@aarnet.edu.au Cc: VALDIS@VTVM1.CC.VT.EDU, tli@cisco.com, kre@munnari.oz.au, big-internet@munnari.oz.au In-Reply-To: Geoff Huston's message of Thu, 2 Jul 92 08:41:03 +1000 <9207012241.AA09396@cruskit.aarnet.edu.au> Subject: Draft IESG recommendation on ROAD activities Supernetting - a good idea, but I don't see how the regionals can win. The regionals win because they can now offer a new service to new customers: address allocation. You don't go through the NIC and wait N weeks. Your regional gives it to you today. when N = 1 this is not an overwhelmingly good line of reasoning. True. However, N = 1 is NOT the common case (at least as I've heard it). Tony From owner-Big-Internet@munnari.oz.au Thu Jul 2 08:54:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18361; Thu, 2 Jul 1992 08:54:25 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18357; Thu, 2 Jul 1992 08:54:14 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Wed, 1 Jul 92 15:54:04 -0700 Date: Wed, 1 Jul 92 15:54:04 -0700 From: Tony Li Message-Id: <9207012254.AA23143@cider.cisco.com> To: G.Huston@aarnet.edu.au Cc: kre@munnari.oz.au, VALDIS@VTVM1.CC.VT.EDU, big-internet@munnari.oz.au In-Reply-To: Geoff Huston's message of Thu, 2 Jul 92 08:39:19 +1000 <9207012239.AA09390@cruskit.aarnet.edu.au> Subject: Draft IESG recommendation on ROAD activities The problem with the routing space need NOT be the regionals - they can engineer default so as to limit routing entries to thousands (rather than hundreds of thousands) of entries in the worst case, and often can engineer default to get the number of routing entries in the high hundreds / low thousands. So they are not the problem. Until the regionals start to interconnect. Then just default isn't sufficient and things get really messy. I would guesstimate that at least 50% of the US regionals are now in this situation. Things in Europe right now seem to be equally interesting and even more volitaile. SO - economically its in a regional's best interest to accept ANY net number that a customer wants to throw at them - thats just good business. The routing problem doesn't get critical within the domain of the regional - the routing problem simply gets shunted upward into the backbone operators - who do not have ANY econmomic clout to get anyone to renumber as they do not deal directly with the end client base. Not necessarily. If backbones are able to charge regionals for each network advertisement then the backbone exerts pressure on the regional to aggregate. The regional in turn passes this charge to the site. Such a charge is certainly reasonable, given that each network number consumes both machine resources on the backbone and (assuming the current technical path) administrative resources for the configuration of that network in the backbone database. Tony From owner-Big-Internet@munnari.oz.au Thu Jul 2 09:22:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19185; Thu, 2 Jul 1992 09:23:00 +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 AA19178; Thu, 2 Jul 1992 09:22:35 +1000 (from dee@ranger.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA02705; Wed, 1 Jul 92 16:22:21 -0700 Received: by us1rmc.bb.dec.com; id AA05014; Wed, 1 Jul 92 10:44:13 -0400 Message-Id: <9207011444.AA05014@us1rmc.bb.dec.com> Received: from ranger.enet; by us1rmc.enet; Wed, 1 Jul 92 10:44:13 EDT Date: Wed, 1 Jul 92 10:44:13 EDT From: "Donald E. Eastlake, III, LJO2/I4 +1 508 486 2358 01-Jul-1992 1044" To: bob.hinden@eng.sun.com, i.wakeman@cs.ucl.ac.uk Cc: big-internet@munnari.oz.au Apparently-To: big-internet@munnari.oz.au, i.wakeman@cs.ucl.ac.uk, bob.hinden@eng.sun.com Subject: RE: Options efficiency (was Re: Para Meta Matters... ) >From: US1RMC::"Bob.Hinden@Eng.Sun.COM" "Bob Hinden" 30-JUN-1992 18:59 >Subj: Options efficiency (was Re: Para Meta Matters... ) > >By the way, lest we forget, hosts also have to process options. >Performance in hosts is also an important issue. > >Bob This is an example where I think a little more work in the hosts for less work in every router would be more than worth it. Stuff that makes it up to a backbone typically goes through >10 routers although I guess there is lots of local traffic. Besides, it is not clear to me that there would be a significant increase in host processing load. It would, in fact, be somewhat easier for hosts to skip over the router options. ------ From: US1RMC::"I.Wakeman@cs.ucl.ac.uk" "MAIL-11 Daemon" 30-JUN-1992 19:03 Subj: Re: Options efficiency (was Re: Para Meta Matters... ) >Donald Eastlake writes... >>You know I've heard this about options being inefficient for routers from man y >>sources. Apparently it is a great force against the definition of any more e nd >>to end options which tends to stiffle research/experimentation. >> > [suggestion for an options present bit in the header] That was a suggestion for a *router* options present bit, not just any options present. >The problem is not so much in the header design - if the header length >is greater than 20 than options are present - but in the >implementations of the forwarding mechanisms. The processing power of >modern routers is sufficent to process a number of options at faster >than the line speed of a 2 MBit link. However there are some >implementations that decide that option processing is always going to >be too slow for the line speed and place any packets with options in a >separate queue to be dealt with at leisure, taking advantage of the >non-requirement for in-order delivery (although I hardly consider that >a"best-effort"). .... > >The implementors ought to classify options as easy, intermediate or >hard when they are deciding when they should be done (if they must >re-order packets) This sounds like a fine idea to me but from the point of view of a router an option that has significant only to the end hosts should be easier than easy. In fact, with my proposal, the router would never touch it at all. >cheers >ian From owner-Big-Internet@munnari.oz.au Thu Jul 2 09:34:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19559; Thu, 2 Jul 1992 09:34:21 +1000 (from owner-Big-Internet) Return-Path: Received: from malgudi.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19556; Thu, 2 Jul 1992 09:34:15 +1000 (from kannan@oar.net) Received: from malgudi.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA07107; Wed, 1 Jul 1992 19:34:00 -0400 Message-Id: <199207012334.AA07107@malgudi.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: Geoff Huston Cc: big-internet@munnari.oz.au Reply-To: kannan@oar.net Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Thu, 02 Jul 92 08:39:19 +1000.<9207012239.AA09390@cruskit.aarnet.edu.au> Date: Wed, 01 Jul 92 19:34:00 -0400 From: Kannan Varadhan >>> From: Geoff Huston >>> Date: Thu, 02 Jul 92 08:39:19 +1000 > On Wed, 1 Jul 92 06:48:12 -0700 Tony Li said: > >The site does not have to enable supernetting. It just gets its > >number from its regional. The regional worries about supernetting. > > Supernetting - a good idea, but I don't see how the regionals can win. > > Do the regionals have to care? > > SO - economically its in a regional's best interest to accept ANY net > number that a customer wants to throw at them - thats just good > business. The routing problem doesn't get critical within the domain of > the regional - the routing problem simply gets shunted upward into the > backbone operators - who do not have ANY econmomic clout to get anyone > to renumber as they do not deal directly with the end client base. There was this 'ere proposal to ask the backbones to start charging for advertisements, and which would get filtered down to the end sites, and giving them discounts/incentives to renumber as carrots before don well, anyway. . . Noel, care to comment on the hot potatoe, Kannan -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From owner-Big-Internet@munnari.oz.au Thu Jul 2 09:54:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20234; Thu, 2 Jul 1992 09:54:53 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207012354.20234@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20229; Thu, 2 Jul 1992 09:54:46 +1000 (from lyman@BBN.COM) From: "Lyman Chapin" Subject: IAB proposal for CIDR and IPv7 To: big-internet@munnari.oz.au, iab@venera.isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov Date: Wed, 1 Jul 92 19:08:10 EDT Mail-System-Version: A summary of the IAB's proposals in response to the work of the ROAD group. ---------------------------------------------------------------------- During its meeting in Kobe, Japan on June 18 and 19, the IAB reviewed the draft report of the ROAD group concerning the problems of "running out of IP network numbers" and "Internet routing table size explosion", and a companion report from the IESG of "IESG Deliberations on Routing and Addressing". The IAB's analysis of the many possibilities suggested by these two reports led it to the following conclusions, which are docu- mented in an internet-draft entitled "IP Version 7": 1) The ROAD group's work, compiled over a period of four months, makes it very clear that the problems of too few IP addresses and too many Internet routes are real and immediate, and represent a clear and present danger to the future successful growth of the worldwide Internet. The IAB was therefore unable to agree with the IESG recommendation to pursue an additional six-month program of further analysis before deciding on a plan for dealing with the ROAD problems. The detailed design, engineering, and deployment work must begin now, and it is therefore imperative that the efforts of the Internet community be focussed on a common goal. 2) The IETF should aggresively pursue the work to engineer CIDR ("classless inter-domain routing", described in RFC 1338), including the extensions to the inter-AD routing protocols to support variable-length masks/prefixes, and the associated address administration paradigm. 3) Since CIDR postpones, but does not prevent, the eventual exhaustion of the 32-bit IP address space, the IETF should also aggressively pursue a detailed technical and organizational plan for using CLNP (the OSI internetwork protocol defined by the ISO 8473 standard, which uses 160-bit addresses) as the basis for a new version of IP (which we have dubbed "IP version 7"), succeeding over time the current version of IP (version 4) in the Internet. An initial description of how CLNP could be used for this purpose within the current TCP/IP architecture and with the existing Internet applications is described in RFC 1347. 4) CLNP has larger addresses than IP, but like IP it lacks features that are expected to be necessary to support future Internet appli- cations and services. The IAB therefore also encourages the pursuit of research in areas such as policy-based routing, route preallocation and cacheing, and deterministic end-to-end QOS mainten- ance (for real-time and other delay-variance sensitive traffic). It is important to understand that (3) above does NOT mean "adopting OSI" or "migrating to OSI" or "converting the Internet to use GOSIP protocols". The IAB recommends only that a new version of IP (IPv7), with much wider addresses and a more extensible header, be based on the existing CLNP. IPv7 is intended to be deployed within the current Internet TCP/IP architecture, not as part of an "OSI stack". There are, of course, many issues that must be resolved before CIDR and IPv7 can actually be deployed in the operational Internet. No one should imagine that there is not still a great deal of work to be done, notwith- standing the efforts that have already been expended by several of the IETF working groups and by the members of the ROAD group over the past year. In recommending that the ROAD problems be addressed by a combination of CIDR, IPv7, and further research, the IAB has deliberately chosen NOT to recommend any of the possible alternatives, so as to present a single focal point for the community consisting of what we believe to be the best technical solutions to the problems. This should not be construed as a blanket "condemnation" of the alternative proposals that have been floated in various parts of the IETF. However, we believe that the normal IETF process of "let a thousand [proposals] bloom", in which the "right choice" emerges gradually and naturally from a dialectic of deployment and experimentation, would in this case expose the community to too great a risk that the Internet will drown in its own explosive success before the process had run its course. The IAB does not take this step lightly, nor without regard for the Internet traditions that are unavoidably offended by it. We look forward to a lively discussion of these conclusions during the upcoming IETF meeting in Boston. - Lyman Chapin IAB chair From owner-Big-Internet@munnari.oz.au Thu Jul 2 10:06:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20634; Thu, 2 Jul 1992 10:06:09 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207020006.20634@munnari.oz.au> Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20631; Thu, 2 Jul 1992 10:06:07 +1000 (from kre) Date: Thu, 2 Jul 1992 10:06:07 +1000 From: Robert Elz To: Big-Internet@munnari.oz.au Subject: CIDR & C# People, this discussion is going way off the rails. We're missing the one essential piece of information necessary to evaluate how effective CIDR will be - hindsight. But that doesn't matter, we can wait for that. No-one is suggesting not doing CIDR, just musing over how effective it will be. Since we simply don't know, and can do no more than guess, throwing our respective guesses at one another isn't getting us anywhere. The issue that started all this was whether we should do C# as well, or whether CIDR will be enough. So far I've heard just 2 arguments against doing C# (two meaningful arguments). One is that it will reserve away for all time half (or in some later suggestion 1/4, but I suspect there are lots of reasons for ignoring that) of the available class C addressing space. That would be material if it weren't for the fact that only about 3% of the available class C's are taken now. Certainly if we did CIDR alone, we'd expect allocation of C's to speed up a lot, but even then allocating out that number of C's will get things to the level where even the supernetting stuff is going to leave very very big routing tables under the best scenario. That is, even not doing C#, by the time half the C address space is allocated we'd better be well on the way to having something much better in place. But with C# using half the space, demand for C nets won't be nearly as great, many sites that would need a bunch of C's will use one C# instead. This really changes nothing - it's not really material whether we give a site 16 class C's (that CIDR will compress into one, or less, advertisements) or one class C# that is one advertisement, and which CIDR could link with others as well. I don't think th "half the address space is wasted" argument is a good one. The other is "perpetuation of class based addressing". This one I sympathise with, I'm a complete advocate of getting rid of address classes and using address/mask pairs everywhere. I just don't see that we can do that right now, and not being able to do it I can't make myself use it as an argument against C#. The one argument in C#'s favour (apart from being able to do it now if the IESG/IAB would only agree to it) is that it actually provides a mechanism where a site with > 254 hosts that they want to link on one network number can survive. I don't see how CIDR helps there at all - ie: CIDR is not a strict superset of C#, if it was, I'd agree, doing C# will be a waste of time. Now, I know that many of you (and I) believe that putting > 254 hosts on one cable is stretching the bounds of sanity - but that's not the issue. The question is whether someone applying for a net number will be able to guarantee that his organisation is *never* going to want to do that. In some cases that's easy - some organisations know they'll only ever have a few hosts, those are the ones that have traditionally had only one class C number, nothing will change there. Others will know that they're never going to shove huge numbers of hosts on a cable, and either a group of C's or one subnetted C# or B will serve just as well. Others, which can't be so sure are just going to have to apply for a class B number if there's no C# to give them. This is where C# has something to offer. It will also conserve Bs for the really big sites. In any case, can we end this "CIDR will be wonderful" "No it won't" exchange, and concentrate on the one issue of whether we should do C# as well as CIDR or not? kre ps: As Noel suggested, I have deleted IAB and IESG from this message, the ROAD list was deleted a while ago, and even earlier the explicit copy to Phil Gross - I suspect that poor Phil may have been getting 5 copies of some of the original message in this series - and without even a whimper! From owner-Big-Internet@munnari.oz.au Thu Jul 2 10:25:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21291; Thu, 2 Jul 1992 10:25:49 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21286; Thu, 2 Jul 1992 10:25:36 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Wed, 1 Jul 92 17:25:30 -0700 Date: Wed, 1 Jul 92 17:25:30 -0700 From: Tony Li Message-Id: <9207020025.AA25047@cider.cisco.com> To: kre@munnari.oz.au Cc: Big-Internet@munnari.oz.au In-Reply-To: Robert Elz's message of Thu, 2 Jul 1992 10:06:07 +1000 <9207020006.20634@munnari.oz.au> Subject: CIDR & C# So far I've heard just 2 arguments against doing C# (two meaningful arguments). One is that it will reserve away for all time half (or in some later suggestion 1/4, but I suspect there are lots of reasons for ignoring that) of the available class C addressing space. That would be material if it weren't for the fact that only about 3% of the available class C's are taken now. Certainly if we did CIDR alone, we'd expect allocation of C's to speed up a lot, but even then allocating out that number of C's will get things to the level where even the supernetting stuff is going to leave very very big routing tables under the best scenario. That is, even not doing C#, by the time half the C address space is allocated we'd better be well on the way to having something much better in place. I suggest that you take a look at draft-rekhter-ipaddress-guide-01.txt. If this addressing plan is followed, CIDR will immediately gobble up a considerable chunk of the C space itself. I don't think th "half the address space is wasted" argument is a good one. Given that neither CIDR nor C# can possibly make 100% efficient usage of its address space, and that both will allocate more space than they will immediately use, I would instead argue that the loss to fragmentation is prohibitive. Tony From owner-Big-Internet@munnari.oz.au Thu Jul 2 11:13:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22824; Thu, 2 Jul 1992 11:13:21 +1000 (from owner-Big-Internet) Return-Path: Received: from malgudi.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22818; Thu, 2 Jul 1992 11:13:09 +1000 (from kannan@oar.net) Received: from malgudi.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA07641; Wed, 1 Jul 1992 21:13:05 -0400 Message-Id: <199207020113.AA07641@malgudi.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: Robert Elz Cc: Big-Internet@munnari.oz.au Reply-To: kannan@oar.net Subject: Re: CIDR & C# In-Reply-To: Your message of Thu, 02 Jul 92 10:06:07 +1000.<9207020006.20634@munnari.oz.au> Date: Wed, 01 Jul 92 21:13:04 -0400 From: Kannan Varadhan >>> From: Robert Elz >>> Date: Thu, 02 Jul 92 10:06:07 +1000 Great summary, kre! > The other is "perpetuation of class based addressing". This one I sympathise > with, I'm a complete advocate of getting rid of address classes and using > address/mask pairs everywhere. I just don't see that we can do that right > now, and not being able to do it I can't make myself use it as an argument > against C#. It will probably take just as much effort to do C# as it would to do away with address classes altogether? Howzzat? > The one argument in C#'s favour (apart from being able to do it now if the > IESG/IAB would only agree to it) is that it actually provides a mechanism > where a site with > 254 hosts that they want to link on one network number > can survive. I don't see how CIDR helps there at all - ie: CIDR is not > a strict superset of C#, if it was, I'd agree, doing C# will be a waste of > time. A site that wants more than 254 hosts in one cable (and I know of at least one existing site that does that, Tony), C# would favour giving them the eqvt. of 4 class C nets. CIDR would do likewise. The hacks required in hosts would be just the same. What's the issue here? The "argument" in favour of C# could be just as well that it gives a new site joining the internet a quantified notion of what their network number is. For instance, today one can do a `whois 131.187.0.0' and expect a response, as opposed to `whois 131.187.0.0 255.255.0.0.' Comments? Kannan -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From owner-Big-Internet@munnari.oz.au Thu Jul 2 11:17:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23039; Thu, 2 Jul 1992 11:17:07 +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 AA23035; Thu, 2 Jul 1992 11:17:01 +1000 (from vaf@Valinor.Stanford.EDU) Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA05015; Wed, 1 Jul 92 18:16:57 -0700 Date: Wed, 1 Jul 92 18:16:56 PDT From: Vince Fuller To: Robert Elz Cc: Big-Internet@munnari.oz.au Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: CIDR & C# In-Reply-To: Your message of Thu, 2 Jul 1992 10:06:07 +1000 Message-Id: One is that it will reserve away for all time half (or in some later suggestion 1/4, but I suspect there are lots of reasons for ignoring that) of the available class C addressing space. That would be material if it weren't for the fact that only about 3% of the available class C's are taken now. Certainly if we did CIDR alone, we'd expect allocation of C's to speed up a lot, but even then allocating out that number of C's will get things to the level where even the supernetting stuff is going to leave very very big routing tables under the best scenario. That is, even not doing C#, by the time half the C address space is allocated we'd better be well on the way to having something much better in place. I don't agree with this logic and here's why: if and when CIDR/supernetting becomes blessed as the "true bandaid way", initial demand for allocation of class-Cs may increase by one or more orders of magnitude. The basic premise of supernetting is that of lumping individual class-Cs together so that they form "supernets" of whatever size is needed. For transit networks, this will mean allocating a chunk of class-Cs and then parcelling out smaller chunks to their clients. To minimize routing table size in the "backbones", though, these transit-provider chunks should be as big as possible. RFC1338 goes so far as to give an example of a transit provider allocating a 4K block of class-Cs. Depending on the number of levels of hierarchy to be supported, one can imagine blocks being allocated which are both larger and smaller than this. While there may be >2meg class C's available, it isn't hard to see how a couple of hundred transit providers could make a dent in this. Note that one of the plusses of CIDR/supernetting is that it isn't restricted to consuming the class-C space - once CIDR is widely deployed any remaining class-A/B space can be appropriately subnetted using CIDR (*not* supernetting) techniques if class-C's threaten to run out. This is why I think CIDR is a short-to-mid-term solution of more general use than C#. The one argument in C#'s favour (apart from being able to do it now if the IESG/IAB would only agree to it) is that it actually provides a mechanism where a site with > 254 hosts that they want to link on one network number can survive. I don't see how CIDR helps there at all - ie: CIDR is not a strict superset of C#, if it was, I'd agree, doing C# will be a waste of time. Now, I know that many of you (and I) believe that putting > 254 hosts on one cable is stretching the bounds of sanity - but that's not the issue. The question is whether someone applying for a net number will be able to guarantee that his organisation is *never* going to want to do that. In some cases that's easy - some organisations know they'll only ever have a few hosts, those are the ones that have traditionally had only one class C number, nothing will change there. Others will know that they're never going to shove huge numbers of hosts on a cable, and either a group of C's or one subnetted C# or B will serve just as well. Others, which can't be so sure are just going to have to apply for a class B number if there's no C# to give them. This is where C# has something to offer. It will also conserve Bs for the really big sites. But CIDR/supernetting offers exactly the same thing. If a site expects to have 4000 hosts, then allocate them 4096 IP addresses in the form of 16 class-Cs which are bit-aligned to be representable as a "supernet". From the point of view of hosts and unmodified routers, this "supernet" looks *exactly* like a C# network number. The advantage is that "supernets" are available in all shapes and sizes and don't add artificial "class" baggage where it is unnecessary. Note that to make full productive use of *either* a "supernet" or a C# number routers really should be modified. In either case, you can probably get away with subnetting a bunch of class-C's but that's not the point - the point is that "supernets" are just a more general form of C#s: a bunch of what used to be called class-C network numbers fused together into a larger, more useful block. --Vince From owner-Big-Internet@munnari.oz.au Thu Jul 2 12:07:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24542; Thu, 2 Jul 1992 12:07:19 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207020207.24542@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24537; Thu, 2 Jul 1992 12:07:10 +1000 (from jcurran@nic.near.net) To: Tony Li Cc: kre@munnari.oz.au, Big-Internet@munnari.oz.au Subject: Re: CIDR & C# In-Reply-To: Your message of Wed, 01 Jul 92 17:25:30 -0700. <9207020025.AA25047@cider.cisco.com> Date: Wed, 01 Jul 92 22:06:32 -0400 From: John Curran -------- From: Tony Li Subject: CIDR & C# Date: Wed, 1 Jul 92 17:25:30 -0700 ... I suggest that you take a look at draft-rekhter-ipaddress-guide-01.txt. If this addressing plan is followed, CIDR will immediately gobble up a considerable chunk of the C space itself. I think that the deployment of CIDR between the major network service providers will result in a significant reduction in the overall backbone routing table size. From looking at NEARnet's announcements, it's quite possible that an overall 20% reduction will be achieved. This is still quite low and is due to the large number of older network numbers which have limited aggregation possibilities. This is not the case with newer sites: we've added 115 networks to our routing table in the last year which would only take 8 entries using CIDR. From discussions with other providers, it is clear that many are already providing IP network number assignments from a bit-boundary range, and will also see significant reductions in routing announcements. There's one small question I have on the allocation plan above: Given that providers assign IP network numbers from contiguous blocks of 32 to 128 network numbers, the addition of CIDR routes to the backbone could be quite small over the first year; possibly as few as 5 CIDR routes per major network provider. The non-CIDR routes in the same period will likely make up the majority of additions (about 50-100 per provider). Increasing the initial allocation for each provider to a block of 1024 networks (or more) *will* reduce the total number of CIDR routes, but only by 3 or 4 routes per provider and the overall improvement will be "noise" compared to the non-CIDR growth. Hence, use of larger class-C allocation blocks quickly enters one into the realm of dimishing returns. Given the possible future need for class "C" address space, and the dramatic growth in network providers, does anyone feel that it is worth trying to allocate two years worth of addresses in advance to each provider, simply to reduce their number of CIDR-style routes from 10 to 1? /John From owner-Big-Internet@munnari.oz.au Thu Jul 2 20:12:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07768; Thu, 2 Jul 1992 20:12:41 +1000 (from owner-Big-Internet) Return-Path: Received: from sunic2.sunet.se by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07765; Thu, 2 Jul 1992 20:12:28 +1000 (from boss@sunet.se) Received: from localhost.sunet.se by sunic2.sunet.se (5.65c8/1.28) id AA15823; Thu, 2 Jul 1992 12:12:18 +0200 Message-Id: <199207021012.AA15823@sunic2.sunet.se> To: Big-Internet@munnari.oz.au From: boss@sunet.se Subject: CIDR, C# and Blocks for Delegation of Address Authority. Date: Thu, 02 Jul 92 12:12:17 +0200 Sender: boss@sunet.se As have been pointed out on this list, there are problems when you go provider based, i.e. providers gets blocks of addresses and not all organizations having assigned a network number will initially get connected to any provider, hence does not fit into a topological based aggregation of addresses. To me it seems that the delegation of address assignment should be based on decoupling of assingment authority from connecting authority at least at the top level for geographical regions. Two such authorities does already exist, the NIC at GSI and the European RIPE NIC. Regional address authorities could then distribute sub-blocks to providers within that region. Using such a scheme, organizations assigning and connecting at the same instance will have the possibility of chosing a provider from that region. Organizations that does not intend to connect could use the provider-independent regional address authority. There is hence not mandatory for providers to coordinate. Coordination should happen between regional the NIC's to enforce aggregation of addresses. I realize that there will be providers spanning more than one region and that this will not make aggregation 100% effective but this will probably not be the general case. I could also be pointed out the current assigned C space should remain as is. I don't think it would be very useful to enforce a renumbering of less than 3% of current allocated the C-space. There has been some discussion weather CIDR is a superset of C# or not and as an indication that this is not the case the situation of >254 hosts on a single network number was mentioned. To be able to take local advantage of CIDR or C# this will make changes to host software necessary and I do not think this is an issue regarding the time-frame C# and/or CIDR is intended for. The real need for an aggregation of routes is within the non-defaulting backbones and here CIDR will be more efficient than C# as having a not fixed aggregation size. As an example, a C#-net expands to 16 class C-nets. Using the total current class C address space (2**(5+8+8)) this will give 2**(1+8+8) C# addresses. This is to my understanding far to less aggregation to deal with the routing table size problem. One drawback with CIDR, as have been mentioned, is that many networks, now not being connected, later on will turn up and get connected and, not conforming to the address blocks, distort the aggregation benefits. It has been mentioned that there are around 40000 nets assigned and not connected as compared to the around 6000 connected. The assumption made is, to my understanding, that the today unconnected nets will come on with a higher rate to get connected than has been recently observed. It seems to be the thinking that the so far observed distribution of time between assigning a net-number and getting connected would not be valid in the near future and by that make the CIDR estimations invalid. I would like to here more about the reasoning behind this thinking as I am not convinced of its correctness. To my understanding the ratio between connected and non-connected nets as well as the time distribution between initial assignment and getting connected could very well stay close to constant in the near future and by that, the entropy of CIDR will be within limits for the estimated time-frame. It might be useful to verify this statement though. I tried a couple of times to get the assigned net numbers database from the GSI NIC to undertake such an investigation but got unfortunately no reaction at all. Finally, I think it is good to keep separate the two major issues involved in C# and CIDR, that of better address usage and that of avoiding a routing table expolosion in the non-defaulting backbones. Both C# and CIDR will give better address usage and by that being able to deal with the class B address exhaustion problem. CIDR will, as I see it, be more efficient in dealing with the routing table problem as discussed above. One remaining issue for CIDR to be deployed is the definition of aggregations sizes and delegation of assignment authority. There exist today two proposals for aggregation and delegation, both in the form of Internet-Drafts: draft-rekhter-ipaddress-guide-01.txt and draft-karrenberg-proposal-00.txt Yakov Rekhter and Tony Li suggests (in the Appendix A) that a major division of the remaining C is done between North-America and Europe with 220.0.0.0 252.0.0.0 for North America giving 220.*.* - 223.*.* class C-nets 216.0.0.0 252.0.0.0 for Europe giving 216.*.* - 219.*.* class C nets i.e 2**(2+8+8) nets for North America and Europe. Other regions are not discussed. Compared with routing efficiency this will optimally give two aggregated routing entries, one for North America and one for Europe. In the proposal by Daniel Karrenberg and myself the suggested sizes are 193.0.0.0 to 223.0.0.0 with mask 255.0.0.0 for nominated address authorities This will give 2**(8+8) nets for each authority. It is also suggested that blocks not delegated to any nominated authority remains in the current authority until other registries are being installed and nominated as address authority for a region. Compared with routing efficiency this will give at most 32 routing entries in the international backbone routers if optimally used. For more details see the drafts. I guess there are pros and cons in both schemes. It will be necessary to find the optimal division between routing efficiency and delegation of authority. The difference between 2 entries or 32 entries as calculated above is not very significant if compared to the total number of routing entries the entire class C space would give if not aggregated at all. When is routing efficiency starting to decrease too much, i.e. how small blocks would be feasible to use and still have routing efficiency? What would be the block-sizes need by the top-level address authorities? This and related issues will be discussed at a comming BOF in Boston focusing on address aggregation and delegation of authority. The hope is that by comming to a consensus here, these rather administrative concerns will not be a hindrance for the urgently needed CIDR deployment. Regards, Bernhard Stockman. From owner-Big-Internet@munnari.oz.au Thu Jul 2 23:55:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12469; Thu, 2 Jul 1992 23:55:10 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12462; Thu, 2 Jul 1992 23:55:01 +1000 (from oran@sneezy.lkg.dec.com) Received: by crl.dec.com; id AA08278; Thu, 2 Jul 92 09:54:52 -0400 Received: by sneezy (5.57/ULTRIX-4.2-3) id AA04109; Thu, 2 Jul 92 09:52:20 -0400 To: kannan@oar.net Cc: big-internet@munnari.oz.au, iesg@nri.reston.va.us, iab@nri.reston.va.us Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: <199207011822.AA03855@malgudi.oar.net> References: <199207011822.AA03855@malgudi.oar.net> X-Mailer: Poste 2.0B3 From: Dave Oran Date: Thu, 2 Jul 92 09:52:19 -0400 Message-Id: <920702095219.15893@sneezy.lkg.dec.com> Encoding: 54 TEXT, 5 TEXT SIGNATURE > Dave Oran spelled out one potential doom for cidr, which was fairly > interesting. According to him (and I summarise here, and he may step in > and explain it better), cidr will fall apart when the entropy in the > system attains infinity, due to a good majority of the sites switching > providers ever so often, as to completely eliminate any potential for > aggregation. In the bad case, cidr requires that sites that move, or > are multi-homed require multiple advertisements. It recommends that > sites renumber to reduce this entropy, but may not happen. This will > ultimately cause cidr to fall apart. You couldn't have said it better, Kannan. Going further, I'd extend this to any scheme, such as city codes. That scheme trades providers for geographies, so you limit the entropy for switching providers but increase it for hosts that move. I'll get on my high horse, and again propose that if we are going to touch hosts for any purpose, we get autoconfiguration of Internet addresses designed and implemented widely and be done with this problem forever. I claim that no matter how the situation evolves - C#, CIDR, TUBA, etc., we will inevitably need a system in which network layer addresses autoconfigure to deal with the desire of the infrastructure providers to periodically make significant changes in the topology of the Internet, or the users to move logically (or physically) among attachment points. Today, we are tremendously constrained in the kinds of topological changes that can be accomodated due to the cost of renumbering. One "solution" (and I use the quotes advisedly) is to throw out the entire existing architecture and go with an architecture in which addresses are not used for identifying the endpoints (hosts). (If I'm to believe the claims in the Nimrod and Pip documents they both provide this separation). This would allow addresses to be used strictly as routing hints, and of course is attractive in theory. The amount of new protocol work needed to make this happen is truly daunting (to me anyway), and treads on delicate areas in distributed system design such as tradeoffs between stability and responsiveness. Within the context of the existing architecture, however, it is quite straightforward to add autoconfiguration of IP (or NSAP) addresses. In fact, most of the tools are available today - DHCP, ESIS, ISIS, etc. The one big missing piece is an automatic protocol for updating the DNS entry for a host when its address changes, and ensuring that IP address caches time out in a time period commensurate with the expected reconfiguration rate. If the IAB bombshell in fact detonates successfully on the Internet infrastructure, then I would like to see the techniques for address autoconfiguration accomodated by CLNP, ESIS, ISIS (and implemented by DECnet Phase V systems for OSI stacks) considered for possible transplantation to the DNS environment. It would be a real shame to go through a painful transition and wind up with a system as brittle against reconfiguration stresses as the current Internet. 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 Jul 3 00:07:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13877; Fri, 3 Jul 1992 00:07:24 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207021407.13877@munnari.oz.au> Received: from DUNGEON.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13873; Fri, 3 Jul 1992 00:07:16 +1000 (from tmallory@BBN.COM) To: dee@ranger.enet.dec.com Cc: big-internet@munnari.oz.au Subject: Re: Options efficiency In-Reply-To: Your message of Wed, 01 Jul 92 10:44:13 -0400. <9207011444.AA05014@us1rmc.bb.dec.com> Date: Thu, 02 Jul 92 10:03:11 -0400 From: Tracy Mallory > That was a suggestion for a *router* options present bit, not just any options > present. > > > >The implementors ought to classify options as easy, intermediate or > >hard when they are deciding when they should be done (if they must > >re-order pack> ets) There are other possibilities in the middle ground, such as agreeing on a set of Efficient Forwarding Guidelines: 1) Restrict the set of options guaranteed efficient handling. In particular, eliminate the options not copied on fragmentation, including the time-stamp and the record-route (not SSRR or LSRR) options. Neither of these options is copied on fragmentation indicating that they serve no purpose in the forwarding process, and if present they make the fragmentation process much slower. Further, the time-stamp option is relatively difficult to implement, especially in firm/hard-ware, since it has both many internal options and requires a change to the IP header checksum that cannot be precomputed. 2) Require options to be padded so that a given option always appears in the same position relative to long-word boundaries. For instance, SSRR and LSRR options must be preceded by a single "pad" option, so that the IP address replacements are always on long-word boundaries, and the pointer update is always in a known location. This allows straight-forward precomputation of part of the checksum update. A router that chose to save, and then compare the old address being replaced in an SSRR option could have the difference between the new and old checksums precomputed. (Think 155Mbps hardware!) 3) Require all router processable options to come before other options. 4) Require router options to be present in ascending numerical order by option code. Then, if an extra flag is available, change the RouterOptions flag to be EfficiencyGuidelinesConformant. Many people might also want to require that the possibility of fragmentation be eliminated. I would rather not climb too far into that rathole, but note that packets conformant to the guidelines above could be fragmented extremely easily. Almost the same guidelines could be applied to CLNP headers as well! Cheers, Tracy From owner-Big-Internet@munnari.oz.au Fri Jul 3 01:08:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15092; Fri, 3 Jul 1992 01:08:39 +1000 (from owner-Big-Internet) Return-Path: Received: from harvard.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15089; Fri, 3 Jul 1992 01:08:30 +1000 (from gmalkin@Xylogics.COM) Received: by harvard.harvard.edu (5.54/a0.25) (for big-internet@munnari.oz.au) id AA16447; Thu, 2 Jul 92 11:08:16 EDT Received: by Xylogics.COM (4.12/4.7_jlv1/7/90) id AA12976; Thu, 2 Jul 92 11:09:28 edt Date: Thu, 2 Jul 92 11:09:28 edt From: Gary Malkin Message-Id: <9207021509.AA12976@Xylogics.COM> To: tli@cisco.com Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us In-Reply-To: Tony Li's message of Wed, 1 Jul 92 14:33:01 -0700 <9207012133.AA14267@cider.cisco.com> Subject: Draft IESG recommendation on ROAD activities > We should find out if IGRP carries a mask, but I don't think RIP is > used much as an IGP for transit networks. Don't forget that RIP-2 will carry subnet masks. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Fri Jul 3 01:24:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15310; Fri, 3 Jul 1992 01:24:18 +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 AA15306; Fri, 3 Jul 1992 01:24:09 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA00567; Thu, 2 Jul 92 08:20:44 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA21232; Thu, 2 Jul 92 08:20:37 MDT Message-Id: <9207021420.AA21232@goshawk.lanl.gov> To: solensky@animal.clearpoint.com (Frank T. Solensky) Cc: big-internet@munnari.oz.au Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of Wed, 01 Jul 92 18:14:29 -0400. <9207012214.AA20830@animal.clearpoint.com> Date: Thu, 02 Jul 92 08:20:33 MST From: peter@goshawk.lanl.gov Frank, I must be missing something viz. your comments on backwardness. I would think that a C# address in CIDR would simply be the "correct" pair conforming to the addressing plan. My main point is that we can come up with an addressing plan which can accomodate a future with either C#, CIDR, both or neither and start assigning addresses accordingly. This would be good planning irrespective of the technology chosen. Geoff's comments point to the need of having enough degrees of freedom so that the system can accomodate things such as address assignment prior to carrier selection. I believe we can construct such a plan, providing we do some smart things with respect to network interconnectivity. CIDR appears to support a wide number of degrees of freedom so I am in favor of using it as the stiffest requirement in the development of the IP addressing plan. Even if C# were "chosen" (what does that mean in the IETF context?), I would recommend establishing an addressing plan (RSN) that allows for later introduction and use of CIDR. cheers, peter From owner-Big-Internet@munnari.oz.au Fri Jul 3 01:33:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15584; Fri, 3 Jul 1992 01:33:55 +1000 (from owner-Big-Internet) Return-Path: Received: from malgudi.oar.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15572; Fri, 3 Jul 1992 01:33:46 +1000 (from kannan@oar.net) Received: from valhalla.oar.net for kannan@oar.net by malgudi.oar.net (5.65c+KVa/920428.1525) id AA11930; Thu, 2 Jul 1992 11:33:35 -0400 Message-Id: <199207021533.AA11930@malgudi.oar.net> X-Mail-Agent: mh-6.7.2-MIME To: boss@sunet.se Cc: Big-Internet@munnari.oz.au Reply-To: kannan@oar.net Subject: Re: CIDR, C# and Blocks for Delegation of Address Authority. In-Reply-To: Your message of Thu, 02 Jul 92 12:12:17 +0200.<199207021012.AA15823@sunic2.sunet.se> Date: Thu, 02 Jul 92 11:36:45 -0400 From: Kannan Varadhan >>> From: boss@sunet.se >>> Date: Thu, 02 Jul 92 12:12:17 +0200 > To my understanding the ratio between connected and non-connected nets > as well as the time distribution between initial assignment and > getting connected could very well stay close to constant in the near > future and by that, the entropy of CIDR will be within limits for the > estimated time-frame. It might be useful to verify this statement > though. I tried a couple of times to get the assigned net numbers > database from the GSI NIC to undertake such an investigation but got > unfortunately no reaction at all. Bernhard, Some of these numbers and trends are tabulated in the supernetting/cidr document. There are also a variety of wonderful (and distressing) curves that Frank has been doing over time. These should be reasonable pointers. I believe I may have some of the raw data lying around, if you would like those. These were compiled from various places including the SRI NIC, some stats from GSI, merit and BBN, the last two for routing tables growths. > Finally, I think it is good to keep separate the two major issues > involved in C# and CIDR, that of better address usage and that of > avoiding a routing table expolosion in the non-defaulting backbones. I believe that the two problems, routing table growth, and address explosion are different facets of the same problem, and it has to be the same leash that muzzles them in. Kannan -=- Kannan Varadhan, 1224, Kinnear Road, +1 614 292 4137 Internet Engineer (OARnet) Columbus, OH 43212 +1 614 292 7168 (FAX) From owner-Big-Internet@munnari.oz.au Fri Jul 3 01:45:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15926; Fri, 3 Jul 1992 01:45:54 +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 AA15922; Fri, 3 Jul 1992 01:45:47 +1000 (from postel@ISI.EDU) Received: from bel.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Thu, 2 Jul 1992 08:46:23 -0700 Date: Thu, 2 Jul 1992 08:44:08 -0700 From: postel@ISI.EDU Posted-Date: Thu, 2 Jul 1992 08:44:08 -0700 Message-Id: <199207021544.AA27728@bel.isi.edu> Received: by bel.isi.edu (5.65c/4.0.3-4) id ; Thu, 2 Jul 1992 08:44:08 -0700 To: oran@sneezy.lkg.dec.com Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, iab@nri.reston.va.us, iesg@nri.reston.va.us Dave: This sounds like a great thing, this autoconfiguration of addressing, and i'd sure like to see it work. One step in this direction, you say, is making addresses arbitrary - so they have nothing to do with location either topologically or geographically. To do this, one introduces a new mapping from addresses to the information that is really used for routing. However, little is said about how this "information that is really used for routing" is created, updated, and passed around. One is left to assume it is much like the way we deal with addresses in our routing system today. This seems to me like pure computer science. --jon. PS: In mathematics a key technique is to reduce a problem to a previously solved problem. Computer Science is similar -- the key technique is to reduce a problem to a previously unsolved problem. From owner-Big-Internet@munnari.oz.au Fri Jul 3 01:59:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16302; Fri, 3 Jul 1992 01:59:28 +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 AA16293; Fri, 3 Jul 1992 01:59:20 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA21675; Thu, 2 Jul 92 08:59:10 -0700 Date: Wed, 1 Jul 92 18:38:55 EDT From: "William Allen Simpson" Message-Id: <498.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: Draft IESG recommendation on ROAD activities > From: Robert Elz > I'd still appreciate it if some of the people responsible, or > with knowledge of other implementations (someone from FTP? > Someone who knows KA9Q? Someone from, or who knows, IP KA9Q and derivatives will configure and route any length subnet mask, as long as the bits are contiguous. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Fri Jul 3 02:24:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16827; Fri, 3 Jul 1992 02:24:15 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207021624.16827@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16824; Fri, 3 Jul 1992 02:24:06 +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, 2 Jul 1992 17:23:23 +0100 To: big-internet@munnari.oz.au, ietf@isi.edu, road@lanl.gov Subject: Re: IAB proposal for CIDR and IPv7 In-Reply-To: Your message of "Wed, 01 Jul 92 19:08:10 EDT." <9207012354.20234@munnari.oz.au> Date: Thu, 02 Jul 92 17:22:58 +0100 From: Jon Crowcroft >3) Since CIDR postpones, but does not prevent, the eventual > exhaustion of the 32-bit IP address space, the IETF should > also aggressively pursue a detailed technical and organizational > plan for using CLNP (the OSI internetwork protocol defined by the > ISO 8473 standard, which uses 160-bit addresses) as the basis for silence = shocked disbelief? here is a paraphrase of what i sent about this to some of the lists... ...several people asked if i could send it to a wider group... CIDR i like. CLNP is premature...and probably a step backwards it also is introducing a policy which is NOT in line with starting new Internet Standard Initiatives on a level playing field, since only some vendors (very few end system vendors, slightly more router vendors) provide CLNP bundled... Do you want to see the political equation? IPv7 = DECNET Phase 5? jon p.s. PIP and Nimrod and other initiatives come from less partisan sources. p.p.s i have no particluar axe to grind except to see the best technical and logistically acceptable solution for internet health and growth From owner-big-internet@munnari.oz.au Fri Jul 3 03:57:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18762; Fri, 3 Jul 1992 03:57:57 +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 AA16292; Fri, 3 Jul 1992 01:59:19 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA21669; Thu, 2 Jul 92 08:58:41 -0700 Date: Wed, 1 Jul 92 18:30:16 EDT From: "William Allen Simpson" Message-Id: <497.bsimpson@angband.stanford.edu> To: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Cc: postel@isi.edu, jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US Reply-To: bsimpson@angband.stanford.edu Subject: Re: Draft IESG recommendation on ROAD activities > From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) > > > If CIDR addresses are assigned on a geographic basis rather than a > > > provider basis you could assign the addresses prior to provider > > > selection, and addresses need not change if you change providers. > > > > Yes, but then this, as the Deering area codes proposal for NSAP allocation > > shows us, requires all the providers in a area to cooperate with each > > other in some transitively closed manner; not really a reality at > > present, is it? > > I thought that was exactly what does happens at FIX (E&W) and the CIX. > They exchange routing information with each other. > And there should be many more as the NSF re-bid winner ramps up next year. I would expect that they spring up around the country. (This depends on the actual proposal accepted.) Do we have some "good guys" from our side reviewing the NSF re-bid? Isn't address assignment and routing database part of that RFP? Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Fri Jul 3 04:18:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19072; Fri, 3 Jul 1992 04:18:17 +1000 (from owner-Big-Internet) Return-Path: Received: from SPECTRUM.CMC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19068; Fri, 3 Jul 1992 04:18:10 +1000 (from lars@CMC.COM) Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA04657; Thu, 2 Jul 92 11:17:44 PDT Newsgroups: ietf.big-internet Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Addresses, Identifiers and Routing Hints Message-Id: <1992Jul2.181730.4619@spectrum.CMC.COM> Organization: CMC (a Rockwell Company), Santa Barbara, California, USA References: <9207021624.16827@munnari.oz.au> Date: Thu, 2 Jul 92 18:17:30 GMT Apparently-To: Big-Internet@munnari.OZ.AU All the talk about whether it is possible or not to achieve significant reduction of routing tables in the defaultless backbone by automatic aggregation if we hand out net numbers via the regionals have convinced me that Noel is right: It is not practical to route on an endpoint identifier. What we DO want to route on, is the identity of the regional carrier through which this customer network is connected. There are only a few dozens of these, and I suspect that it will be a long time before we reach a thousand. We should evaluate what it would take to remove all but one network number per carrier from the defaultless backbone routers. (1) This would obviously alleviate the routing table congestion from the backbone instantly. It would not require any modifications to the backbone routers. (2) It could be implemented with no changes to the end nodes, although widespread implementation of certain features (already standardized but not widely implemented) could make life much easier. And some new features would be desirable. (3) Significant enhancement would be required in the routing fabric; otherwise every "customer network" would be as World.STD.Com today: Reachable only via carriers that have agreements to route them. The ideal place to implement these changes would be in the first level routers (usually stub area routers). (4) We would need to establish a mechanism to decide which network numbers are "Registered Carriers" allowed to be in the backbone tables, and which are not. I would propose a route registration fee as the simplest mechanism to allocate this resource. (5) Having established such a limited number of routing landmarks, we need a place to put it in the packet. The representation of the landmark could either be an IP network number or a routing domain AS-number. If we use the former, the natural place for the landmark would be in the destination IP address field of the packet that traverses the backbone (i.e. encapsulation), or in a (loose) source route. (6) Source routes can help us with policy routing as well as with many scaling problems. One nice feature of source routes, is that they are reversible. (7) Alternatively, the stub routers could look up the "approved landmark" for any packets coming by with an unapproved destination, and encapsulate the packet as it passes through. Or patch it up with a source route via the proper landmark. (8) If the packet is not properly translated before it reaches the backbone, the backbone provider could do the fixup (for a per-packet fee). This would make the network work for users who can't or won't fix their hosts or local routers, while still giving some incentive to do it right. (I.e. the backbone provider would have a default route pointing to the "route fixer" box.) The biggest problem I see with this as an interim solution to the routing information explosion is the very limited option area in the IPv4 packet. -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC (Rockwell Digital Systems) Telephone: +1-805-968-4262 Santa Barbara, CA 93117-5503 TeleFAX: +1-805-968-8256 From owner-Big-Internet@munnari.oz.au Fri Jul 3 05:59:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21933; Fri, 3 Jul 1992 05:59:57 +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 AA21926; Fri, 3 Jul 1992 05:59:50 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA14374; Thu, 2 Jul 92 13:59:32 -0600 Received: from localhost.lanl.gov by goshawk.lanl.gov (4.1/5.17) id AA24236; Thu, 2 Jul 92 13:59:31 MDT Message-Id: <9207021959.AA24236@goshawk.lanl.gov> To: John Curran Cc: Big-Internet@munnari.oz.au Subject: Re: CIDR & C# In-Reply-To: Your message of Wed, 01 Jul 92 22:06:32 -0400. <9207020207.24542@munnari.oz.au> Date: Thu, 02 Jul 92 13:59:30 MST From: peter@goshawk.lanl.gov < discussion of block addressing to providers and how big should they be > John, I believe a mistake to avoid is the notion of assigning a block to a provider and assuming that the provider "owns" the block ad infinitum. What would be preferable would be a two phase commit, essentially allocating a block of addresses to a provider, and the provider to assign the network addresses. There is difference between allocation and assignment. With the block allocation the provider accepts a stewardship for good address assignment. If the top level numbering authority (IANA/NIC) needs a subtree of addresses back, the provider could be *required* to relinquish the largest power of two sized block of unassigned addresses and readvertise the routing of the assigned networks using longer prefixes out of the originally allocated prefix. If such a strategy were adopted, we could afford large "allocations" since over time the top level can reclaim unassigned addresses to be reallocated. This could be done at various levels of the CIDR hierarchy, such as continents/countries/U.S. regionals/campuses. For your consideration, peter From owner-Big-Internet@munnari.oz.au Fri Jul 3 08:30:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25184; Fri, 3 Jul 1992 08:31:02 +1000 (from owner-Big-Internet) Return-Path: Received: from sunic2.sunet.se by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25174; Fri, 3 Jul 1992 08:30:50 +1000 (from boss@sunet.se) Received: from localhost.sunet.se by sunic2.sunet.se (5.65c8/1.28) id AA09630; Fri, 3 Jul 1992 00:30:30 +0200 Message-Id: <199207022230.AA09630@sunic2.sunet.se> To: kannan@oar.net Cc: Big-Internet@munnari.oz.au Subject: Re: CIDR, C# and Blocks for Delegation of Address Authority. In-Reply-To: Your message of Thu, 02 Jul 92 11:36:45 -0400. <199207021533.AA11930@malgudi.oar.net> Date: Fri, 03 Jul 92 00:30:30 +0200 From: Bernhard Stockman SUNET Kannan, I have seen the estimations in the CIDR I-D and the curves about the estimated Internet growth with regards to routing table sizes. The assumptions is, as far as I see, that these estimations will not significantly change as a result of currently not connected nets starting to get connected at a higher rate than today. It would be nice if that assumption could be verified. There has been expressed concerns that this assumption would not be valid when Internet now, e.g. going commercialized, will experience an increased rate of networks getting connected. The entropy estimations on which CIDR is built might then not hold and by that not give the needed time to deploy the mid-term solutions. Bernhard. From owner-Big-Internet@munnari.oz.au Fri Jul 3 09:09:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26315; Fri, 3 Jul 1992 09:11:18 +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 AA26283; Fri, 3 Jul 1992 09:09:51 +1000 (from craig@aland.bbn.com) Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA07627; Thu, 2 Jul 92 19:09:29 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA28811; Thu, 2 Jul 92 16:08:29 PDT Message-Id: <9207022308.AA28811@aland.bbn.com> To: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov Subject: IPv7 (CLNP) a mistake Reply-To: Craig Partridge From: Craig Partridge Date: Thu, 02 Jul 92 16:08:29 -0700 Sender: craig@aland.bbn.com I've read the IAB announcement, RFC 1347 and the Internet Draft, and am afraid I view this idea of adopting CLNP as IPv7 as a disasterous idea. First, adopting CLNP means buying into the ISO standards process. While the Kobe announcement states that choosing CLNP is "not choosing OSI," it is the case that we'd be choosing to make the network layer of the Internet protocol suite the same as the OSI protocol suite. As such, we have to face the painful reality that any future changes that the Internet community wishes to see in the network layer will require ISO approval too. ISO and the Internet community have radically different views about the standards making process (e.g. testing before standardizing, whether to bill for standards, and the like). Indeed, the Internet community decided not to join up with ANSI/ISO a few years ago because both communities felt there were incompatibilities in their processes. Now we're proposing to buy into the ISO process to manage our network layer. We'll all have to learn the detailed workings of the ISO process if we want to change the network layer -- and since it requires some number of meetings to be ANSI/ISO accredited, we'd better all start attending those meetings now (in addition to our IETF meetings) so we can be prepared to defend our ideas in the ISO process. Do we really want to pass much (all?) of our control over the Internet network layer to a process that the Internet community finds incompatible? (I've heard at least one person suggest that if ISO doesn't like Internet-proposed changes, we'll just publish our own version of CLNP. Ignoring ISO copyright issues about issuing a modified ISO spec [which may or may not prove to big deal], I don't buy this idea. First, why even call this new network layer CLNP unless we believe we mean to keep in sync. Second, having an Internet and an ISO CLNP means that vendors will have to support two versions of CLNP, which they won't like. Consider how much folks already complain about the different GOSIPs. We'll find ourselves in a tremendous vise to harmonize with ISO. We've tried that twice before, with CMIP over TCP and IS-IS. In one case, the idea was a complete flop but only after a waste of some years of effort. In neither case was the process pleasant. I don't think we want more of these kinds of problems.). Second, CLNP deals with only *one* of the several issues facing IP, namely address depletion. At the same time, it forces us to take a giant step back on other issues. CLNP does *not* support multicasting. There are proposals in the works to add it -- but that means CLNP is about five years behind IP on this topic. IP multicast is working now and it has taken a lot of effort -- it is in products (Solaris 2.0) and in BSD (4.4 and mods are available for 4.3). We're making good progress on mobile host support. Some experimental implementations under IP are getting heavy use. We'll have to go back to the CLNP drawing board on those projects too. Ideas to support multimedia applications are fast becoming reality (witness the recent IETF multicasts on the Internet). If we buy CLNP we'll have to wait a few years for ISO to approve those extensions. With the exception of a brief mentions about leaving space for options and making sure that multicast will somehow be supported, the various documents don't address this issue. In short, CLNP as IPv7 seems destined to be a technical step backwards and to place a severe crimp on protocol innovation at a time when we need to innovate. (Some folks have expressed concern that the rise in voice and multimedia on the Internet will stress IP *this* year. To my knowledge, no one has tried running voice over CLNP). Are we so sure that we should choose CLNP with all its limitations, especially now that CIDR gives us a bit of breathing room in which to think? Are we so sure CLNP is the right decision that we shouldn't even consider developing at least one other approach in parallel, just in case we discover CLNP really is a tar baby? Craig From owner-Big-Internet@munnari.oz.au Fri Jul 3 09:43:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27205; Fri, 3 Jul 1992 09:43:43 +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 AA27201; Fri, 3 Jul 1992 09:43:32 +1000 (from lixia@parc.xerox.com) Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <11716>; Thu, 2 Jul 1992 16:43:15 PDT Received: by redwing.parc.xerox.com id <57234>; Thu, 2 Jul 1992 16:43:05 -0700 Date: Thu, 2 Jul 1992 16:43:02 PDT Sender: Lixia Zhang From: Lixia Zhang Reply-To: lixia@parc.xerox.com To: Craig Partridge Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov Subject: Re: IPv7 (CLNP) a mistake In-Reply-To: Your message of Thu, 2 Jul 1992 16:08:29 -0700 Message-Id: > In short, CLNP as IPv7 seems destined to be a technical step backwards > and to place a severe crimp on protocol innovation at a time when we > need to innovate. I agree with this statement with my both hands up. For decisions this big, I'm shocked to see that IAB made the move without holding an open hearing period for opinions from the internet community. I would like to hear how other people think about this. Lixia From owner-Big-Internet@munnari.oz.au Fri Jul 3 09:54:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27432; Fri, 3 Jul 1992 09:54:32 +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 AA27428; Fri, 3 Jul 1992 09:54:26 +1000 (from braden@ISI.EDU) Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Thu, 2 Jul 1992 16:34:28 -0700 Date: Thu, 2 Jul 1992 16:32:30 -0700 From: braden@ISI.EDU Posted-Date: Thu, 2 Jul 1992 16:32:30 -0700 Message-Id: <199207022332.AA04998@braden.isi.edu> Received: by braden.isi.edu (5.65c/4.0.3-4) id ; Thu, 2 Jul 1992 16:32:30 -0700 To: big-internet@munnari.oz.au, craig@aland.bbn.com, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov Subject: Re: IPv7 (CLNP) a mistake First, adopting CLNP means buying into the ISO standards process. Craig, This just is simply not true. Please see the Internet Draft that is trying to get out of CNRI.. Bob From owner-Big-Internet@munnari.oz.au Fri Jul 3 10:31:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28489; Fri, 3 Jul 1992 10:32:01 +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 AA28480; Fri, 3 Jul 1992 10:31:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22333; Thu, 2 Jul 92 20:31:40 -0400 Date: Thu, 2 Jul 92 20:31:40 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207030031.AA22333@ginger.lcs.mit.edu> To: oran@sneezy.lkg.dec.com, postel@isi.edu Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu One step in this direction, you say, is making addresses arbitrary - so they have nothing to do with location either topologically or geographically. This sounds a lot like the properties of what I am calling the 'identifier'; it says *who* you are (uniquely), but says nothing about *where* you are. However, little is said about how this "information that is really used for routing" is created, updated, and passed around. One is left to assume it is much like the way we deal with addresses in our routing system today. Exactly! To me, an 'address' is something that just says *where* in the topology you are. Not who/what is at that place, or how to get to that address. Now, I know, this is just terminology; we could call them 'bloogs' and hold the same discussions. However, it seems useful to give to abstract ideas the name which is a closest match from day to day life. In day to day life, an address is a (structured) 'name' for a place. This seems to me like pure computer science. Absolutely. Every time I think about this I feel like I'm an undergrad back in 6.033, with Saltzer up there lecturing on namespaces! I know I'm sounding like a broken record (clearly one made of vapor desposited quartz, given the number of times I've played the same song); I hope those of you whom I have bored to tears (and past) can forgive me some day! Noel From owner-Big-Internet@munnari.oz.au Fri Jul 3 10:36:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28652; Fri, 3 Jul 1992 10:37:10 +1000 (from owner-Big-Internet) Return-Path: Received: from uu2.psi.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28629; Fri, 3 Jul 1992 10:36:50 +1000 (from craig@aland.bbn.com) Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA13691; Thu, 2 Jul 92 20:36:27 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA29438; Thu, 2 Jul 92 17:35:28 PDT Message-Id: <9207030035.AA29438@aland.bbn.com> To: braden@ISI.EDU Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov Subject: re: IPv7 (CLNP) a mistake Reply-To: Craig Partridge From: Craig Partridge Date: Thu, 02 Jul 92 17:35:27 -0700 Sender: craig@aland.bbn.com > First, adopting CLNP means buying into the ISO standards process. > > Craig, > > This just is simply not true. Please see the Internet Draft that is > trying to get out of CNRI.. Bob: I read the ID very carefully before sending my earlier note. I believe that the key paragraph is: The IAB proposal is to adopt the CLNP protocol specification and packet formats for IPv7. The eventual consequence of this decision will be the publication, at some point in the future, of a complete IPv7 specification that is functionally and syntactically compatible with CLNP (defined by the second edition of the ISO 8473 standard, published in 1992). The intent is to run the existing and future Internet transport protocols -- in particular, TCP and UDP -- above IPv7. This would let us benefit from the larger addresses of CLNP while maintaining the present Internet architecture, without inventing a new protocol specification and without losing change control. We must of course avoid gratuitous changes, but the IAB/IETF must be able to make any changes that are necessary for successful deployment, operation, and evolution of IPv7. In the longer term, the use of CLNP will contribute to the inevitable convergence of the OSI and TCP/IP protocol suites in the Internet (IAB/IETF) context. In short we will adopt CLNP (an ISO protocol); we wish to be "functionally and syntactically" compatible and to "converge" with OSI; and want to be able to make "changes ... necessary for successful, deployment, operation, and evolution of IPv7." If we want to make changes and still be compatible with and converge with OSI, we'll have to convince ISO to go along, which means we have to work in the ISO standards process. So we've bought into the ISO process (for the network layer). Craig From owner-Big-Internet@munnari.oz.au Fri Jul 3 11:36:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00458; Fri, 3 Jul 1992 11:37: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 AA00445; Fri, 3 Jul 1992 11:36:58 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11551>; Thu, 2 Jul 1992 18:36:38 PDT Received: from localhost ([127.0.0.1]) by skylark.parc.xerox.com with SMTP id <22277>; Thu, 2 Jul 1992 18:36:27 -0700 To: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov Subject: Re: IPv7 (CLNP) a mistake Date: Thu, 2 Jul 1992 18:36:18 PDT From: Steve Deering Message-Id: <92Jul2.183627pdt.22277@skylark.parc.xerox.com> I share Craig's dismay with the IAB's decision. In addition to the real and serious problems that Craig raises concerning change control over the fundamental protocol of the Internet, I am concerned about technical and procedural aspects of the IAB decision. Technically, changing from IP to CLNP means trading addresses that are too short for address that are too long (yeah, I know, memory and bandwidth keep getting cheaper, but it's a shame to fill it up with a bunch of bytes that just say who got to allocate the next bunch of bytes, not to mention all the null padding), plus a checksum that's more expensive to compute in software and a bunch of non-32-bit-aligned fields that are more expensive to parse. If I understand the transition plan, it also means adding an entirely new set of router-to-router and host-to-router protocols to all of the boxes in the Internet, in addition to the IP-based protocols already present, which will have a significant cost, not only in terms of computing and network resources, but more importantly in terms of the manageability of the Internet and the training of its users and maintainers. If all we want is bigger addresses (and that's all that CLNP gives us), it would be far better just to make the minimal changes to IPv4 and its routing protocols to carry bigger addresses, in such a way that much of the existing routing, management, and "cultural" infrastructure can be retained. The recent proposals by Hinden & Crocker and by Zheng Wang appear to be viable examples of that approach. On the other hand, if we are going to make a change of the magnitude of that suggested, let's get something more out of it than just bigger addresses. As Craig pointed out, the Internet is just starting to see an explosion of new applications and services -- it's not just telnet, FTP, and email any more. We need a more capable infrastructure, not just a more scalable one. This is an exciting period of creative activity in the Internet; it would be a real shame to derail (and possibly smother) that activity in a small-gain, big-pain transition to CLNP. Procedurally, I am dismayed at the undemocratic and closed nature of the decision making process, and of the haste with which such a major decision was made. I understand the need for immediate action on the CIDR front; however, given the reprieve of CIDR, I am not convinced that the IP address space will run out so soon that there is no time for an open evaluation of the longer-term alternatives, and possibly even a building of concensus in the community. I thought the IESG recommendation of a six-month evaluation period was very sensible; instead, we got a decision handed down from a closed IAB meeting, based on the work of the closed ROAD group. (I was a member of the ROAD group, invited to participate after I discovered its existence by accident and asked what was going on.) I also am not convinced that the ROAD group had sufficient time to evaluate the alternatives. For example, Bob Hinden came up with his particular encapsulation scheme part way through the ROAD activity, and it has evolved considerably since the last ROAD meeting, addressing most of its previously-identified shortcomings. Another example is Paul Tsuchiya's PIP proposal, which has emerged since ROAD. I hope the IAB will explain why it deemed it necessary to endorse CLNP in the midst of active development of less disruptive alternatives (e.g., the Hinden scheme) and more capable alternatives (e.g., PIP). Steve Deering From owner-Big-Internet@munnari.oz.au Fri Jul 3 12:40:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02532; Fri, 3 Jul 1992 12:40:49 +1000 (from owner-Big-Internet) Return-Path: Received: from cincsac.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02521; Fri, 3 Jul 1992 12:40:32 +1000 (from medin@nsipo.nasa.gov) Received: Thu, 2 Jul 92 19:39:44 PDT from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (4.1/1.5T) Message-Id: <9207030239.AA18618@cincsac.arc.nasa.gov> To: Craig Partridge Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov Subject: Re: IPv7 (CLNP) a mistake In-Reply-To: Your message of "Thu, 02 Jul 92 16:08:29 PDT." <9207022308.AA28811@aland.bbn.com> Date: Thu, 02 Jul 92 19:39:43 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) I totally agree with Craig. There are a number of problems with trying to base an IPv7 on CLNP in the manner that the IAB is trying to do. First off, if you really didn't want to buy into the ISO standards process, routing protocols, ES-IS, etc, you ought to have taken the CLNP packet format, renamed all the fields, and then proclaimed the output IPv7. This would have the effect you are looking for, having compatibility of packet format, but being independent in other areas. By saying you are basing the protocol on CLNP, you cause everyone to bring along all the baggage they associate with OSI. Another problem is that how addressing in this new scheme will work. There is rightly a large amount of opposition to using real OSI delegated NSAP's, for a number of technical reasons, but if the perception of them being OSI addresses exists, all the baroque procedures for acquiring NSAP addresses may try to be applied, causing even more confusion. In the US, this is just plain complicated; overseas, it can often be the case that the existing Internet activists in that country are in direct opposition to the official NSAP authorities, such as PTT's. Confusion will reign, and it won't be pretty. And the very people the IAB and IETF are trying to support will be hurt. Additionally, with such an RFC published, the marketing arms of the various OSI vendors (which have been rather quiet in the past couple of years) will go into high gear, going into Government labs and commercial organizations, pitting fumeware against real TCP/IP products, and telling potential customers that the Internet is now transitioning to OSI protocols, and how they should be ahead of the power curve and skip the TCP/IP step completely, thereby depriving the customer of working products, and the IP vendor of deserved revenue. It's not that the IAB proposal says this will happen in so many words, but a cursory reading of the document, and the quote that Craig cited certainly will support this sort of viewpoint. I could go on, but the real problem is how the process is working. If the area directors of the IESG who are intimately working and wrestling with the issues feel that making the choice about what the future of the IP protocol ought to be is unclear, then the IAB ought to listen to that and act accordingly. Many of these issues are hard problems. They do not go away just because you use CLNP. When the IAB tells them that the IAB knows what's best - better than the best minds in this arena know, they are on very dangerous ground. It should be pointed out that the IAB has no real authority, and never really has had any (maybe they have even less now since being absorbed by the ISOC). The IAB doesn't direct, it leads. And the ability of it to lead is based on the respect and confidence of the R&D, vendor, and user communities. When the IAB moves in this rather high-handed fashion, it erodes any leadership it has, and simply compromises it's ability to push forward with any strategy. If one looks back at history, the IAB has been most successful when it embraced excellent technical standards, with real experience in prototyping and testing, with the support of the technical and user communities. It has been an utter failure when trying to advance less well defined proposals that are not consistent with the Internet community's traditions and corporate wisdom (CMOT comes to mind as an example). I have many technical concerns with this approach, but I fear that any discussion about the proposal's merits and faults will be secondary to the manner which the IAB chose to push this approach. In my opinion, the IAB has seriously undermined it's ability to advance and implement this strategy by destroying it's own credibility as a leader. The CLNP proposal will now have the tarbaby of a perceived powergrab associated with it, and is unlikely to move forward. The IAB may well succeed in getting this RFC advanced, but nobody will care. The IETF will continue to make progress in other approaches, prototyping and testing, and real solutions will eventually come forth and be deployed. Leadership is earned, and once damaged is very difficult to rebuild. This area, the scaling of the Internet (address depletion is a red herring, the real issue is scaling), is an area where progress can ONLY be made by rational debate, technical leadership and consensus building. By attempting to cram this approach down the technical community's throat, the IAB has undermined all these goals, and has made it harder for progress in ANY approach to be made, which is perhaps the most tragic aspect of this whole sad affair. This action isn't in the best traditions of the Internet, though I fear it may in fact be setting a new trend. Thanks, Milo PS Usual disclaimers about not representing the Government apply... From owner-Big-Internet@munnari.oz.au Fri Jul 3 13:56:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04809; Fri, 3 Jul 1992 13:56:46 +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 AA04806; Fri, 3 Jul 1992 13:56:38 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA03751); Thu, 2 Jul 92 22:56:07 CDT Received: by san-miguel.is.rice.edu (AA13241); Thu, 2 Jul 92 22:56:05 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9207030356.AA13241@san-miguel.is.rice.edu> Subject: Re: IPv7 (CLNP) a mistake To: medin@nsipo.nasa.gov (Milo S. Medin) Date: Thu, 2 Jul 92 22:56:03 CDT Cc: craig@aland.bbn.com, big-internet@munnari.oz.au, iab@isi.edu, iseg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov In-Reply-To: <9207030239.AA18618@cincsac.arc.nasa.gov>; from "Milo S. Medin" at Jul 2, 92 7:39 pm X-Mailer: ELM [version 2.3 PL11] Ok, So the IAB proposal is flawed. It seems that every other proposal that has been cussed in the big-internet forum over the last few months is flawed as well. Some proposals seem to be easier to implement than others, while some will take significant time. What seems to be lacking in all the verbage being tossed around are plans to provide implementations and agreements to build testbeds for these implementations. I understand that it may be a heinous thought, but we could use the net to actually build and test some of these ideas. Yes, it may impact "production" services but after all, this is (at least in the US) still a research, development and educational network. (At least thats how I read the NSF AUP). Recent questions about the structure of the Internet seems to point out that it is no longer an IP only network. What is the phrase... time to fish or cut bait. I, for one, would like to see something related to implementation planning for some of the various drafts. I think that we could persuade our regional to help with some of the proposals... we are already experimenting with CLNP, and we could work with either the CIDR or C# plans, (as long as GSI will hand out the address blocks) as long as we can get others to help out. When can we see something on PIP/PIPE/Nimrod, other than architectural plans? It will be interesting to see if we can "prove" the IAB wrong, rather than casting aspersions. -- 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 Fri Jul 3 16:56:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09688; Fri, 3 Jul 1992 16:57:00 +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 AA09681; Fri, 3 Jul 1992 16:56:55 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA22184; Thu, 2 Jul 92 23:56:40 -0700 Date: Fri, 3 Jul 92 02:39:58 EDT From: "William Allen Simpson" Message-Id: <505.bsimpson@angband.stanford.edu> To: ietf@isi.edu Cc: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: IAB proposal for CIDR and IPv7 Two administrative discrepencies: 1) When I went to read this fine document, I discovered that it consisted of an index of the directory on nnsc.nsf.net. The same file was also at ftp.nisc.sri.com. Hopefully, this will be fixed. (Debra Legare emailed me a separate copy when I reported the error.) 2) I uploaded and just finished re-reading RFC994, which I hadn't looked at in a very long time. The effect of the NLPID listed in that document when sending over current links will appear to be IP version 8, not 7. 7.2.2 Network Layer Protocol Identifier The value of this field is set to binary 1000 0001 to identify this Network Layer protocol as ISO 8473, Protocol for Providing the Connectionless- mode Network Service. The value of this field is set to binary 0000 0000 to identify the Inactive Network Layer protocol subset. Or are we getting a new NLPID value "0111 xxxx" and defining our own IP/CLNP hybrid? Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Fri Jul 3 17:03:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09840; Fri, 3 Jul 1992 17:03:30 +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 AA09837; Fri, 3 Jul 1992 17:03:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA23454; Fri, 3 Jul 92 03:03:02 -0400 Date: Fri, 3 Jul 92 03:03:02 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207030703.AA23454@ginger.lcs.mit.edu> To: bmanning@is.rice.edu, medin@nsipo.nasa.gov Subject: Re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, craig@aland.bbn.com, iab@isi.edu, ietf@isi.edu, iseg@nri.reston.va.us, road@lanl.gov I, for one, would like to see something related to implementation planning for some of the various drafts. ... When can we see something on .../Nimrod, other than architectural plans? As you may recall, I made and appeal to the IETF mailng list at the start of June, for help in making Nimrod happen (i.e. detailed engineering design, protocol specs, test implementation and field trials), I received a number of responses; thanks to everyone who responded. It seems that a group at BBN, among them Martha Steenstrup, chair of the IDPR WG of the IETF, represents the most appropriate group to work with on this. Their experience with Source Routed Link State routing architectures, gained during the IDPR work, makes them a natural fit to work with on Nimrod. Many of the key radical ideas of Nimrod are also in IDPR, and experience gained with IDPR will be of great value with Nimrod. In some sense, IDPR can be viewed as "phase 0" of Nimrod, and the work done on IDPR will be used, and of substantial value, in allowing Nimrod to hit the ground running. Nothing is definite yet: we are discussing how to proceed, and there is no certainty that we will get any funding to make any of this happen, although obviously I have high hopes. If this work should proceed, it will definitely be in the context of an IETF WG, which will be open to all in the usual manner. Exactly when this will all be happening, I'm not sure; I would like to see things move along quickly, but this depends on funding. Noel From owner-Big-Internet@munnari.oz.au Fri Jul 3 17:27:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10539; Fri, 3 Jul 1992 17:27:19 +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 AA10536; Fri, 3 Jul 1992 17:27:10 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA05487; Fri, 3 Jul 1992 09:26:49 +0200 Message-Id: <199207030726.AA05487@mitsou.inria.fr> To: postel@ISI.EDU Cc: big-internet@munnari.oz.au, iab@nri.reston.va.us, iesg@nri.reston.va.us Subject: Re: Draft IESG recommendation on ROAD activities In-Reply-To: Your message of "Thu, 02 Jul 92 08:44:08 PDT." <199207021544.AA27728@bel.isi.edu> Date: Fri, 03 Jul 92 09:26:48 -0400 From: Christian Huitema X-Mts: smtp Jon, You are slightly incorrect when you say that mapping from addresses to the information that is really used for routing is "a previously unsolved problem". It has not yet been solved at the network level, but it certainly has been solved at the message handling level, where routing is performed with help of the DNS and "MX records": the mail address is an identifier, the MX record tells you how to get to the mailbox. It is interesting to observe that this is an evolution away from hierarchical routing -- before the introduction of the MX records, all mail to France was send to the server for "*.fr", etc... Similarly, the usage of a name server for mapping between "Internet address" and "subnet address" has been proposed for public data networks, where a "broadcasting ARP" solution cannot be used. In this case, we have a transit network dependant mapping between Internet address and routing information. Indeed, there are less mail messages floating around the Internet than there are IP packets, and one could see a "response time" problem. However, mail represents about 1/4th of the total trafic, and the average mail message is probably not much more than half a dozen packets. Which means that the "mapping through directory" solution is already demonstrated to work at a rate equivalent to 1/24 the packet rate of the Internet. Moreover, the "non mail" trafic tends to be composed of ftp like connections, which means that the "working set" of addresses will be fairly stable and that the "directory" information will be easily cached. Christian Huitema From owner-Big-Internet@munnari.oz.au Fri Jul 3 17:30:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10721; Fri, 3 Jul 1992 17:30:56 +1000 (from owner-Big-Internet) Received: from [192.88.97.13] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10715; Fri, 3 Jul 1992 17:30:48 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 5771; Fri, 03 Jul 92 09:30:01 MET Received: by DEARN (Mailer R2.08) id 6856; Fri, 03 Jul 92 09:30:00 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 7729 for MOD-IETF@SEARN.SUNET.SE; Fri, 3 Jul 1992 09:28:26 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 2897; Fri, 03 Jul 92 09:25:34 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Fri, 03 Jul 92 09:25:28 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <14920-0@survis.surfnet.nl>; Fri, 3 Jul 1992 09:27:03 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <12282-0@survis.surfnet.nl>; Fri, 3 Jul 1992 02:49:20 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <03538-0@relay.surfnet.nl>; Fri, 3 Jul 1992 02:49:16 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09513; 2 Jul 92 20:36 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09509; 2 Jul 92 20:36 EDT Received: from uu2.psi.com by NRI.Reston.VA.US id aa08896; 2 Jul 92 20:37 EDT Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA13691; Thu, 2 Jul 92 20:36:27 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA29438; Thu, 2 Jul 92 17:35:28 PDT Return-Path: Message-Id: <9207030035.AA29438@aland.bbn.com> To: BSMTP Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Subject: re: IPv7 (CLNP) a mistake Reply-To: Craig Partridge From: Craig Partridge Date: Thu, 02 Jul 92 17:35:27 -0700 Sender: owner-mod-ietf@searn.sunet.se > First, adopting CLNP means buying into the ISO standards process. > > Craig, > > This just is simply not true. Please see the Internet Draft that is > trying to get out of CNRI.. Bob: I read the ID very carefully before sending my earlier note. I believe that the key paragraph is: The IAB proposal is to adopt the CLNP protocol specification and packet formats for IPv7. The eventual consequence of this decision will be the publication, at some point in the future, of a complete IPv7 specification that is functionally and syntactically compatible with CLNP (defined by the second edition of the ISO 8473 standard, published in 1992). The intent is to run the existing and future Internet transport protocols -- in particular, TCP and UDP -- above IPv7. This would let us benefit from the larger addresses of CLNP while maintaining the present Internet architecture, without inventing a new protocol specification and without losing change control. We must of course avoid gratuitous changes, but the IAB/IETF must be able to make any changes that are necessary for successful deployment, operation, and evolution of IPv7. In the longer term, the use of CLNP will contribute to the inevitable convergence of the OSI and TCP/IP protocol suites in the Internet (IAB/IETF) context. In short we will adopt CLNP (an ISO protocol); we wish to be "functionally and syntactically" compatible and to "converge" with OSI; and want to be able to make "changes ... necessary for successful, deployment, operation, and evolution of IPv7." If we want to make changes and still be compatible with and converge with OSI, we'll have to convince ISO to go along, which means we have to work in the ISO standards process. So we've bought into the ISO process (for the network layer). Craig From owner-Big-Internet@munnari.oz.au Fri Jul 3 17:45:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11257; Fri, 3 Jul 1992 17:45:57 +1000 (from owner-Big-Internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11254; Fri, 3 Jul 1992 17:45:48 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 5822; Fri, 03 Jul 92 09:45:09 MET Received: by DEARN (Mailer R2.08) id 7543; Fri, 03 Jul 92 09:45:08 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 7820 for MOD-IETF@SEARN.SUNET.SE; Fri, 3 Jul 1992 09:43:40 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 3082; Fri, 03 Jul 92 09:41:52 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Fri, 03 Jul 92 09:41:49 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <15173-0@survis.surfnet.nl>; Fri, 3 Jul 1992 09:34:31 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <12701-0@survis.surfnet.nl>; Fri, 3 Jul 1992 04:44:14 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <03625-0@relay.surfnet.nl>; Fri, 3 Jul 1992 04:44:10 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09930; 2 Jul 92 22:39 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09926; 2 Jul 92 22:39 EDT Received: from cincsac.arc.nasa.gov by NRI.Reston.VA.US id aa11724; 2 Jul 92 22:40 EDT Return-Path: Original-Received: Thu, 2 Jul 92 19:39:44 PDT from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (4.1/1.5T) Pp-Warning: Illegal Received field on preceding line Message-Id: <9207030239.AA18618@cincsac.arc.nasa.gov> To: BSMTP Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Subject: Re: IPv7 (CLNP) a mistake In-Reply-To: Your message of "Thu, 02 Jul 92 16:08:29 PDT." <9207022308.AA28811@aland.bbn.com> Date: Thu, 02 Jul 92 19:39:43 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Sender: owner-mod-ietf@searn.sunet.se I totally agree with Craig. There are a number of problems with trying to base an IPv7 on CLNP in the manner that the IAB is trying to do. First off, if you really didn't want to buy into the ISO standards process, routing protocols, ES-IS, etc, you ought to have taken the CLNP packet format, renamed all the fields, and then proclaimed the output IPv7. This would have the effect you are looking for, having compatibility of packet format, but being independent in other areas. By saying you are basing the protocol on CLNP, you cause everyone to bring along all the baggage they associate with OSI. Another problem is that how addressing in this new scheme will work. There is rightly a large amount of opposition to using real OSI delegated NSAP's, for a number of technical reasons, but if the perception of them being OSI addresses exists, all the baroque procedures for acquiring NSAP addresses may try to be applied, causing even more confusion. In the US, this is just plain complicated; overseas, it can often be the case that the existing Internet activists in that country are in direct opposition to the official NSAP authorities, such as PTT's. Confusion will reign, and it won't be pretty. And the very people the IAB and IETF are trying to support will be hurt. Additionally, with such an RFC published, the marketing arms of the various OSI vendors (which have been rather quiet in the past couple of years) will go into high gear, going into Government labs and commercial organizations, pitting fumeware against real TCP/IP products, and telling potential customers that the Internet is now transitioning to OSI protocols, and how they should be ahead of the power curve and skip the TCP/IP step completely, thereby depriving the customer of working products, and the IP vendor of deserved revenue. It's not that the IAB proposal says this will happen in so many words, but a cursory reading of the document, and the quote that Craig cited certainly will support this sort of viewpoint. I could go on, but the real problem is how the process is working. If the area directors of the IESG who are intimately working and wrestling with the issues feel that making the choice about what the future of the IP protocol ought to be is unclear, then the IAB ought to listen to that and act accordingly. Many of these issues are hard problems. They do not go away just because you use CLNP. When the IAB tells them that the IAB knows what's best - better than the best minds in this arena know, they are on very dangerous ground. It should be pointed out that the IAB has no real authority, and never really has had any (maybe they have even less now since being absorbed by the ISOC). The IAB doesn't direct, it leads. And the ability of it to lead is based on the respect and confidence of the R&D, vendor, and user communities. When the IAB moves in this rather high-handed fashion, it erodes any leadership it has, and simply compromises it's ability to push forward with any strategy. If one looks back at history, the IAB has been most successful when it embraced excellent technical standards, with real experience in prototyping and testing, with the support of the technical and user communities. It has been an utter failure when trying to advance less well defined proposals that are not consistent with the Internet community's traditions and corporate wisdom (CMOT comes to mind as an example). I have many technical concerns with this approach, but I fear that any discussion about the proposal's merits and faults will be secondary to the manner which the IAB chose to push this approach. In my opinion, the IAB has seriously undermined it's ability to advance and implement this strategy by destroying it's own credibility as a leader. The CLNP proposal will now have the tarbaby of a perceived powergrab associated with it, and is unlikely to move forward. The IAB may well succeed in getting this RFC advanced, but nobody will care. The IETF will continue to make progress in other approaches, prototyping and testing, and real solutions will eventually come forth and be deployed. Leadership is earned, and once damaged is very difficult to rebuild. This area, the scaling of the Internet (address depletion is a red herring, the real issue is scaling), is an area where progress can ONLY be made by rational debate, technical leadership and consensus building. By attempting to cram this approach down the technical community's throat, the IAB has undermined all these goals, and has made it harder for progress in ANY approach to be made, which is perhaps the most tragic aspect of this whole sad affair. This action isn't in the best traditions of the Internet, though I fear it may in fact be setting a new trend. Thanks, Milo PS Usual disclaimers about not representing the Government apply... From owner-Big-Internet@munnari.oz.au Fri Jul 3 17:45:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11263; Fri, 3 Jul 1992 17:46:06 +1000 (from owner-Big-Internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11258; Fri, 3 Jul 1992 17:45:58 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 5823; Fri, 03 Jul 92 09:45:11 MET Received: by DEARN (Mailer R2.08) id 7544; Fri, 03 Jul 92 09:45:09 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 7820 for MOD-IETF@SEARN.SUNET.SE; Fri, 3 Jul 1992 09:43:40 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 3082; Fri, 03 Jul 92 09:41:52 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Fri, 03 Jul 92 09:41:49 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <15173-0@survis.surfnet.nl>; Fri, 3 Jul 1992 09:34:31 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <12701-0@survis.surfnet.nl>; Fri, 3 Jul 1992 04:44:14 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <03625-0@relay.surfnet.nl>; Fri, 3 Jul 1992 04:44:10 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa09930; 2 Jul 92 22:39 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa09926; 2 Jul 92 22:39 EDT Received: from cincsac.arc.nasa.gov by NRI.Reston.VA.US id aa11724; 2 Jul 92 22:40 EDT Return-Path: Original-Received: Thu, 2 Jul 92 19:39:44 PDT from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (4.1/1.5T) Pp-Warning: Illegal Received field on preceding line Message-Id: <9207030239.AA18618@cincsac.arc.nasa.gov> To: BSMTP Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Subject: Re: IPv7 (CLNP) a mistake In-Reply-To: Your message of "Thu, 02 Jul 92 16:08:29 PDT." <9207022308.AA28811@aland.bbn.com> Date: Thu, 02 Jul 92 19:39:43 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Sender: owner-mod-ietf@searn.sunet.se I totally agree with Craig. There are a number of problems with trying to base an IPv7 on CLNP in the manner that the IAB is trying to do. First off, if you really didn't want to buy into the ISO standards process, routing protocols, ES-IS, etc, you ought to have taken the CLNP packet format, renamed all the fields, and then proclaimed the output IPv7. This would have the effect you are looking for, having compatibility of packet format, but being independent in other areas. By saying you are basing the protocol on CLNP, you cause everyone to bring along all the baggage they associate with OSI. Another problem is that how addressing in this new scheme will work. There is rightly a large amount of opposition to using real OSI delegated NSAP's, for a number of technical reasons, but if the perception of them being OSI addresses exists, all the baroque procedures for acquiring NSAP addresses may try to be applied, causing even more confusion. In the US, this is just plain complicated; overseas, it can often be the case that the existing Internet activists in that country are in direct opposition to the official NSAP authorities, such as PTT's. Confusion will reign, and it won't be pretty. And the very people the IAB and IETF are trying to support will be hurt. Additionally, with such an RFC published, the marketing arms of the various OSI vendors (which have been rather quiet in the past couple of years) will go into high gear, going into Government labs and commercial organizations, pitting fumeware against real TCP/IP products, and telling potential customers that the Internet is now transitioning to OSI protocols, and how they should be ahead of the power curve and skip the TCP/IP step completely, thereby depriving the customer of working products, and the IP vendor of deserved revenue. It's not that the IAB proposal says this will happen in so many words, but a cursory reading of the document, and the quote that Craig cited certainly will support this sort of viewpoint. I could go on, but the real problem is how the process is working. If the area directors of the IESG who are intimately working and wrestling with the issues feel that making the choice about what the future of the IP protocol ought to be is unclear, then the IAB ought to listen to that and act accordingly. Many of these issues are hard problems. They do not go away just because you use CLNP. When the IAB tells them that the IAB knows what's best - better than the best minds in this arena know, they are on very dangerous ground. It should be pointed out that the IAB has no real authority, and never really has had any (maybe they have even less now since being absorbed by the ISOC). The IAB doesn't direct, it leads. And the ability of it to lead is based on the respect and confidence of the R&D, vendor, and user communities. When the IAB moves in this rather high-handed fashion, it erodes any leadership it has, and simply compromises it's ability to push forward with any strategy. If one looks back at history, the IAB has been most successful when it embraced excellent technical standards, with real experience in prototyping and testing, with the support of the technical and user communities. It has been an utter failure when trying to advance less well defined proposals that are not consistent with the Internet community's traditions and corporate wisdom (CMOT comes to mind as an example). I have many technical concerns with this approach, but I fear that any discussion about the proposal's merits and faults will be secondary to the manner which the IAB chose to push this approach. In my opinion, the IAB has seriously undermined it's ability to advance and implement this strategy by destroying it's own credibility as a leader. The CLNP proposal will now have the tarbaby of a perceived powergrab associated with it, and is unlikely to move forward. The IAB may well succeed in getting this RFC advanced, but nobody will care. The IETF will continue to make progress in other approaches, prototyping and testing, and real solutions will eventually come forth and be deployed. Leadership is earned, and once damaged is very difficult to rebuild. This area, the scaling of the Internet (address depletion is a red herring, the real issue is scaling), is an area where progress can ONLY be made by rational debate, technical leadership and consensus building. By attempting to cram this approach down the technical community's throat, the IAB has undermined all these goals, and has made it harder for progress in ANY approach to be made, which is perhaps the most tragic aspect of this whole sad affair. This action isn't in the best traditions of the Internet, though I fear it may in fact be setting a new trend. Thanks, Milo PS Usual disclaimers about not representing the Government apply... From owner-Big-Internet@munnari.oz.au Fri Jul 3 19:19:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13473; Fri, 3 Jul 1992 19:20:04 +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 AA13463; Fri, 3 Jul 1992 19:19:57 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA22593; Fri, 3 Jul 92 02:19:42 -0700 Date: Fri, 3 Jul 92 04:29:36 EDT From: "William Allen Simpson" Message-Id: <506.bsimpson@angband.stanford.edu> To: ietf@ISI.EDU Cc: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: why 160-bit addresses are daft.... > Note - double the 4800 back to 9600 for slip or ppp performance > over existing modems and you get 160 vs 800 - the ratio is still the same. > > I reassert, gentlefolks, that 160 bit addresses is raving lunacy. > > -Mike O'Dell > Resident Crank with a 9600 baud modem > I originally got involved with IETF because of PPP, to get dialup IP addresses and VJ header compression. I'm in the Merit regional, and they have 1200 and 2400 bps service all over this state (Michigan). The links in the "backbone" are 9600. Internally, the maximum unfragmented packet size is 240 bytes. So, you can see that big headers are not what we want here. Someday, there may be header compression for CLNP. Otherwise, I'm quite sure that I won't be using CLNP for a long, long, long time. Be that as it may, the real lunacy is the autocratic fashion in which the decision was made. The big-internet group has been debating for quite a while. The IESG area directors hadn't reached a consensus. Yet, the newly re-constituted IAB took it upon themselves to make a decision, in an inaccessible meeting, without a recommendation from the people who will actually do the work! May I suggest that we engage in a Boston tradition: let's dump the IAB in the harbor. With ISO books attached. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com - resident curmudgeon with 2400 bps modem From owner-Big-Internet@munnari.oz.au Fri Jul 3 19:20:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13485; Fri, 3 Jul 1992 19:20:28 +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 AA13482; Fri, 3 Jul 1992 19:20:22 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA22596; Fri, 3 Jul 92 02:20:03 -0700 Date: Fri, 3 Jul 92 04:59:12 EDT From: "William Allen Simpson" Message-Id: <507.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: IPv7 (CLNP) a mistake > From: bmanning@is.rice.edu (William Manning) > What is the phrase... time to fish or cut bait. I, for one, would > like to see something related to implementation planning for some of the > various drafts. I think that we could persuade our regional to help with > some of the proposals... we are already experimenting with CLNP, and we could > work with either the CIDR or C# plans, (as long as GSI will hand out the > address blocks) as long as we can get others to help out. When can we > see something on PIP/PIPE/Nimrod, other than architectural plans? It will > be interesting to see if we can "prove" the IAB wrong, rather than casting > aspersions. > I am willing to experiment with my PIPE (dream) in the KA9Q based environment I did all of my PPP testing in. I wrote the spec with that in mind. The problem with devoting full time to it would be funding. That's an advantage that Paul has that I don't. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Fri Jul 3 20:58:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15830; Fri, 3 Jul 1992 20:59:08 +1000 (from owner-Big-Internet) Return-Path: Received: from kiddo.merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15824; Fri, 3 Jul 1992 20:58:58 +1000 (from jyy@merit.edu) Received: Fri, 3 Jul 92 06:59:02 -0400 by kiddo.merit.edu (AIX/1.6) Date: Fri, 3 Jul 92 06:59:02 -0400 From: Jessica Yu Message-Id: <9207031059.AA16413@kiddo.merit.edu> To: G.Huston@aarnet.edu.au, VALDIS@VTVM1.CC.VT.EDU, kre@munnari.oz.au, tli@cisco.com Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au >From: Geoff Huston >SO - economically its in a regional's best interest to accept ANY net >number that a customer wants to throw at them - thats just good >business. The routing problem doesn't get critical within the domain of >the regional - the routing problem simply gets shunted upward into the >backbone operators - who do not have ANY econmomic clout to get anyone >to renumber as they do not deal directly with the end client base. Jeff, when the routing table explosion problem hits the network everybody defaults to, everybody (including regionals/providers) looses. E.g. Regionals would only be able to reach part of the Internet and they would loose customers as a result. So is there any incentive for regionals/providers to help doing routing aggregation? Yes! --Jessica From owner-Big-Internet@munnari.oz.au Fri Jul 3 23:46:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19282; Fri, 3 Jul 1992 23:46:21 +1000 (from owner-Big-Internet) Return-Path: Received: from gizmo.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19279; Fri, 3 Jul 1992 23:46:14 +1000 (from mo@gizmo.bellcore.com) Received: by gizmo.bellcore.com (5.61/1.34) id AA07608; Fri, 3 Jul 92 09:46:10 -0400 Date: Fri, 3 Jul 92 09:46:10 -0400 From: mo@gizmo.bellcore.com (Michael O'Dell) Message-Id: <9207031346.AA07608@gizmo.bellcore.com> To: ietf@isi.edu Subject: Defeat snatched from the jaws of Victory... Cc: big-internet@munnari.oz.au This is VERY bad bongos. While the technical and procedural failings of the IAB'sCLNP decision are bad enough, the political repercussions could well end the Internet as we now now it. The reports I've be told from the latest OSI Upper Level Protocols working group meeting indicate that the the body responsible for the 7-layer mistake now admits it has been a complete failure and they largely decided to retarget their efforts to TCP/IP because of its pervasiveness. (IE, they'd like to see their efforts used.) That's thowing in the the towel by any metric. In short, we were really winning. Now, the IAB annouces that the Internet should adopt part of the 7-layer mistake. What kind of message does this send? It means that once the network can fully route CLNP traffic there will no longer be any reason for the TCP/IP stack to exist. The market place won't support wide-scale use of two non-interoperating environments and the computer vendors will start pushing like hell to recover their OSI investments. Political Correctness will exert itself as well. It is also a kiss-of-death for all the emerging internet technology companies. The OSI marketting droids will have a field-day with this. If this decision stands (or is honored with any weight), we will have witnessed the death of two major forces for technical excellence this year: the Internet and CSRG at Berkeley. [Note that I didn't say they always achieved the goal, but that they were honestly striving for it without overly-much regard to political maneuvering and marketplace jerrymandering by large vendors.] Gee, I hope this is all wrong. -Mike O'Dell Bellcore?? Bellcore isn't allowed opinions, and they wouldn't want these if they were. From owner-Big-Internet@munnari.oz.au Fri Jul 3 23:56:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19458; Fri, 3 Jul 1992 23:56:26 +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 AA19447; Fri, 3 Jul 1992 23:56:07 +1000 (from craig@aland.bbn.com) Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA00167; Fri, 3 Jul 92 09:55:37 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA00944; Fri, 3 Jul 92 06:53:44 PDT Message-Id: <9207031353.AA00944@aland.bbn.com> To: bmanning@is.rice.edu Cc: big-internet@munnari.oz.au, iab@isi.edu, ietf@isi.edu, iseg@nri.reston.va.us, road@lanl.gov Subject: Re: IPv7 (CLNP) a mistake In-Reply-To: Your message of Fri, 03 Jul 92 03:03:02 -0400. <9207030703.AA23454@ginger.lcs.mit.edu> Reply-To: Craig Partridge Date: Fri, 03 Jul 92 06:53:43 -0700 From: Craig Partridge I, for one, would like to see something related to implementation planning for some of the various drafts. ... When can we see something ... other than architectural plans? I think you'll see publicly available implementations of IPAE by early fall. A survey of the necessary changes to the BSD code has been done and with the exception of fixing up the BSD library routines (not to be confused with the system call interface), the changes are entirely straightforward, and mostly trivial, and completely invisible to the user. Craig From owner-Big-Internet@munnari.oz.au Sat Jul 4 00:43:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21374; Sat, 4 Jul 1992 00:44:00 +1000 (from owner-Big-Internet) Return-Path: Received: from sayshell.umd.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21347; Sat, 4 Jul 1992 00:43:44 +1000 (from louie@sayshell.umd.edu) Received: by sayshell.umd.edu (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0) id AA09329; Fri, 3 Jul 92 10:43:15 EDT Message-Id: <9207031443.AA09329@sayshell.umd.edu> To: lixia@parc.xerox.com Cc: Craig Partridge , big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov Reply-To: louie@ni.umd.edu (Louis A. Mamakos) Subject: Re: IPv7 (CLNP) a mistake In-Reply-To: Your message of "Thu, 02 Jul 92 16:43:02 PDT." Date: Fri, 03 Jul 92 10:43:14 -0400 From: "Louis A. Mamakos" I sure seems to me that a proposed change with such extensive impact on the operational aspect of the Internet should have the benefit of considerable open discussion and comment. We cannot afford to "look before we leap" in this instance. I have heard enough dissent over just the 160 bit addresses to make me wary without even commenting on some of the other aspects of the proposal. Personally, I'm not too keen on variable length addresses, nor do I consider them an advantage. Since the new architecture looks to be more dependent on directory services than the the old, I'm particularly concerned about low bandwidth connected hosts where header compression alogrithms won't do any good with UDP-like queries. In any case, most of the document seems reasonable until we get to section 5. "THE WAY FORWARD": In order to guarantee the survival of the Internet, work should start now on the various items detailed in this document. Delaying by a few more months in order to gather more information would be very unlikely to help us make a decision, and would encourage people to spend their time crafting arguments for why CLNP is or is not a better solution than some alternative, rather than working on the detailed specification of how CLNP can be used as the basis for IPv7 and resolving the technical questions (particularly in the area of address administration and the effect on existing application software) that must be answered in order to specify a deployment plan for IPv7. However real and pressing our current problems are, we must afford a few more months for more "public" comment and review on this proposal before commiting significant resources along a particular line of work and a particular architecture. The cost of failure is just too high. There are too many viewpoints which may not have been considered by the group crafting this proposal; Mike O'Dell brings one to the table which may or may not have been addressed. Personally, I'd like to hear arguments for why CLNP is or is not a better solution than alternatives (such as Hinden and Crocker's IPAE). One internet draft crafted by the IAB is not sufficiently compelling for me, and seems to fly in the face of the consensus building process the Internet community (well, it once really was a community) has mostly successfully used in the past. Louis Mamakos h | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Equivalences: ============ ISO DoD version version Li IHL Seg Len Tot Len (oddbyte align) SP/MS/Type Flags/off Lifetime TTL cksum cksum (oddbyte align) (about twice as cheap, but no byte swap protection) Leaving us with: Addr len indicator and according to rfc 994, 20 octets each of src+dst addr. Comparing these in function: Both CLNP & IP are datagram, i.e. support statelkess send & receive, plus forwarding. Both support fragmentation (now has to be renamed segmentation, considered harmful, and confusing with TCP segments), (loose and strict) source routing, error reports (and CLNP has the DEC Congestion experienced" bit). What more does CLNP have? Address Space? Well IP has 4 bytes of address plus AS number CLNP has, usably, 11 bytes...ignoring the wselector (and if you use the ID as a real end system ID (e.g. MAC addresses a la DECNET), you get 4 bytes of routing directive... shurely shum mishtake? From owner-Big-Internet@munnari.oz.au Sat Jul 4 01:04:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21786; Sat, 4 Jul 1992 01:04:27 +1000 (from owner-Big-Internet) Return-Path: Received: from relay.surfnet.nl by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21783; Sat, 4 Jul 1992 01:04:15 +1000 (from dixon@rare.nl) Received: from erasmus.rare.nl by relay.surfnet.nl with SMTP (PP) id <09153-0@relay.surfnet.nl>; Fri, 3 Jul 1992 17:03:33 +0200 Received: by erasmus.rare.nl (4.1/4.31) id AA09648; Fri, 3 Jul 92 17:03:32 +0200 Date: Fri, 3 Jul 92 17:03:32 +0200 From: dixon@rare.nl (Tim Dixon) Message-Id: <9207031503.AA09648@erasmus.rare.nl> To: ietf@isi.edu, mo@gizmo.bellcore.com Subject: Re: Defeat snatched from the jaws of Victory... Cc: big-internet@munnari.oz.au What is the logical deduction about IP from the following two loudest complaints about the IAB decision? a) CLNP is a useless part of a useless protocol suite b) CLNP is too similar to IP Yes, you've got it! Amusing, but unhelpful. Almost as amusing as the various implications that if the IAB sees a round wheel lying on the ground it isn't allowed to use it without first making sure the IETF doesn't prefer it square. Actually, I suspect that the IAB decision is, at best, only marginally relevant to the problems, imagined or real, of the Internet. However, that is considerably more relevant than most of the reaction. Tim From owner-Big-Internet@munnari.oz.au Sat Jul 4 01:06:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21842; Sat, 4 Jul 1992 01:07:14 +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 AA21833; Sat, 4 Jul 1992 01:06:56 +1000 (from kre) To: peter@goshawk.lanl.gov Cc: John Curran , Big-Internet@munnari.oz.au Subject: Re: CIDR & C# In-Reply-To: Your message of Thu, 02 Jul 92 13:59:30 -0700. <9207021959.AA24236@goshawk.lanl.gov> Date: Sat, 04 Jul 92 01:06:46 +1000 Message-Id: <19141.710176006@munnari.oz.au> From: Robert Elz Date: Thu, 02 Jul 92 13:59:30 MST From: peter@goshawk.lanl.gov Message-ID: <9207021959.AA24236@goshawk.lanl.gov> < discussion of block addressing to providers and how big should they be > I believe a mistake to avoid is the notion of assigning a block to a provider and assuming that the provider "owns" the block ad infinitum. ... If such a strategy were adopted, we could afford large "allocations" since over time the top level can reclaim unassigned addresses to be reallocated. No you can't. Just consider applying this technique recursively, which is what will happen. You assign continents huge ranges, the continents assign countries big ranges, countries assign states/provinces/regions average size regions, and they assign numbers to sites. Now, lets say we assign antartica a couple of hundred million net numbers to assign, they will take that, and divide it into chunks of 40 million addresses, and hand those out to the countries with a claim in antartica, those countries hand out 10 million addresses to each of their bases, and then each base delegates out 10 or 20 net numbers to the nets that need them. Now we realise we've overdone it a bit, and rather than 300 million addresses, the antartic really only need 300, but how exactly do we get them back? The net numbers that have been assigned by this strategy are 0-20, 10000000-10000020, 20000000-20000020, 30000000-30000020, ... all the way through the 300 million addresses. There are vast numbers unused, but no chunk bigger than 9999980. You end up with hundreds of small pieces interspersed with small ranges of allocated addresses, all in all a mess. John Curran was absolutely right - there's no point at all attempting to realise perfection, if we can limit the backbone routing tables to < 10000 (starting at 6000 or so now) until this band aid approach can be retired, we'll have done very well. The difference between 10 and 500 supernetted routes from CIDR (excluding leakage) isn't worth considering - the only way to allocate blocks in a way that will enable any kind of efficiency at all, is to do it in reasonably "small" chunks - that is comparatively speaking, so while reclaiming addresses is still a theoretical possibility, it would only be necessary in the most dire of circumstances. kre From owner-Big-Internet@munnari.oz.au Sat Jul 4 01:30:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22343; Sat, 4 Jul 1992 01:32:43 +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 AA22286; Sat, 4 Jul 1992 01:30:41 +1000 (from kre) To: dixon@rare.nl (Tim Dixon) Cc: ietf@isi.edu, mo@gizmo.bellcore.com, big-internet@munnari.oz.au Subject: Re: Defeat snatched from the jaws of Victory... In-Reply-To: Your message of Fri, 03 Jul 92 17:03:32 +0200. <9207031503.AA09648@erasmus.rare.nl> Date: Sat, 04 Jul 92 01:30:32 +1000 Message-Id: <19158.710177432@munnari.oz.au> From: Robert Elz Date: Fri, 3 Jul 92 17:03:32 +0200 From: dixon@rare.nl (Tim Dixon) Message-ID: <9207031503.AA09648@erasmus.rare.nl> a) CLNP is a useless part of a useless protocol suite b) CLNP is too similar to IP Yes, you've got it! Amusing, but unhelpful. While expressed that way the arguments may appear amusing, they're not at all. (a) points out that the decision may risk embroiling the Internet in a political mess that no-one wants, no matter how hard we try to stay out of it by protesting our independance. (b) indicates that while CLNP will take a massive effort to deploy, the actual benefit in doing that might not be nearly as much as it would appear at first glance, and that this step may not end up actually lasting long before another radical change is needed. General feeling has been that only one more major change can be supported in the Internet - certainly only one more in the forseeable future, after that inertia will simply be too much to overcome, and nothing more than tinkering around the edges will really be possible. The IAB's decision has gone against this as well, they're actually planning for two radical revisions, CLNP, and then something later once a choice has been made, to add policy routing, etc, which CLNP won't give. kre From owner-Big-Internet@munnari.oz.au Sat Jul 4 01:36:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22419; Sat, 4 Jul 1992 01:36: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 AA22416; Sat, 4 Jul 1992 01:36:09 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24596; Fri, 3 Jul 92 11:35:03 -0400 Date: Fri, 3 Jul 92 11:35:03 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207031535.AA24596@ginger.lcs.mit.edu> To: Christian.Huitema@sophia.inria.fr, postel@isi.edu Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Exactly, caching will bring the lookup rate down to something reasonable; you won't do a lookup on every packet. In particular, if we adopt flows, as posited by Dave Clark in the ~79/81 timeframe, we'd have to do such a lookup at most once per TCP connection, pretty much the same rate as for DNS lookups. For that matter, I doubt we do a DNS lookup on every piece of mail now; probably 'MUNNARI.OZ.AU' is already in the DNS cache on this machine! Noel PS: As before, I've dropped the IAB and IESG as additional addresses to avoid mail meltdown. From owner-Big-Internet@munnari.oz.au Sat Jul 4 02:16:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23168; Sat, 4 Jul 1992 02:16: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 AA23160; Sat, 4 Jul 1992 02:16:35 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA24803; Fri, 3 Jul 92 12:16:29 -0400 Date: Fri, 3 Jul 92 12:16:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207031616.AA24803@ginger.lcs.mit.edu> To: dixon@rare.nl, ietf@isi.edu, mo@gizmo.bellcore.com Subject: Re: Defeat snatched from the jaws of Victory... Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu What is the logical deduction about IP from the following two loudest complaints about the IAB decision? a) CLNP is a useless part of a useless protocol suite b) CLNP is too similar to IP Exactly. It was a conclusion similar to the conclusion of this line of thought that lead me to point out to what then known as the Internet Working Group (the predecessor to the IAB/IETF complex) at a presentation at ISI in about 1981 that the IP architecture: i) had made some non-optimal choices (which I don't see as indicative of a poor design process, since everyone was still very much feeling their way back then) about confusing things like addresses and host identifiers, and in fact had proabbly left out a layer of naming at the packet level ii) was probably obsolescent as a result of this aspect of the design, and would benefit greatly from being redone at some point Thus, you have the mental framework on hand in which I first looked at a copy of the CLNP spec (I don't recall exactly when, but it was in the earily 80's), and upon making the observation you have labelled b), realized CLNP was neither fish (IP/TCP interoperable) nor fowl (a design which righted some of the fundamental errors of IP). Well, it's all water under the bridge know. I guess the point is that that the two observations you have listed above lead me to exactly the same conclusion: both IP and CLNP are obsolescent. I somehow doubt this was your point, though... Almost as amusing as the various implications that In a telecon on this matter, I was rebuked (and rightly so) by Lyman for being funny about this. Now, I agree, sometimes things are so desparate you can be funny, or scream, but being funny can be taken the wrong way, so let's be sparing with it in public debate, everyone, OK? if the IAB sees a round wheel lying on the ground it isn't allowed to use it without first making sure the IETF doesn't prefer it square. Exactly. If you really think otherwise, you don't appreciate organically the IETF process, which is embodied not so much in our written rules, (which reflect, not create, the original reality created by experience), but in the character and attitudes of our members. "Our ordinary citizens, though occupied with the pursuits of industry, are still fair judges of public matters; for, unlike any other nation, ... we Athenians are able to judge at all events if we cannot originate, and instead of looking on discussion as a stumbling block in the way of action, we think it an indispensable preliminary to any wise action at all." --Pericles, given in Thucydides, "Peloponnesian War", Tr. Crawley. Noel From owner-Big-Internet@munnari.oz.au Sat Jul 4 02:49:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23959; Sat, 4 Jul 1992 02:49:16 +1000 (from owner-Big-Internet) Return-Path: Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23956; Sat, 4 Jul 1992 02:49:07 +1000 (from medin@nsipo.nasa.gov) Received: Fri, 3 Jul 92 09:48:29 PDT from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Message-Id: <9207031648.AA13870@dscs.arc.nasa.gov> To: Jon Crowcroft Cc: Steve Deering , big-internet@munnari.oz.au Subject: Re: IPv7 (CLNP) a mistake hmmm In-Reply-To: Your message of "Fri, 03 Jul 92 15:43:03 BST." <9207031443.21353@munnari.oz.au> Date: Fri, 03 Jul 92 09:48:28 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Jon, I do not the believe the IAB is proposing the allocation of NSAP addresses for addresses in IPv7. That is, they are taking the packet, but no decision has been made on how to profile the address fields. It's unlikely any standard profile would be used, because they all have a good set of problems, even US GOSIP is not large enough in the inter-domain area to do what is needed. Something totally new (and incompatible with NSAPs) will likely be required. This one of my big problems with the approach. By calling out CLNP, but then not using real NSAP's, you confuse the heck out of people. Many ISO types in a given organization will assert administrative control because of this, leading to a pile of ugly arguments. It seems the one thing we MUST avoid is triggering the official address allocation authorities from getting into the act. In the Fed. Government, these are usually procurement weenies. They are rarely the Internet people. The Internet has really benefitted from the ability of anyone in an organization being able to get an address without the manager of that organization having to approve it. This has allowed IP to sneak in to many places, subverting the MIS departments in many large organizations. The OSI process on the other hand, has been crippled in terms of allocation of addresses because of the bureaucracy involved. It used to be (and maybe still is) that in the Fed. Government, the head of the agency has to request the allocation from GSA. Anytime the head of an agency does something like this, he'll assign it to the group in the org chart that seems to make sense, not realizing that often times, the real networking people are not in that organization. In many cases, they look at the org chart, see they have someone is charge of computing procurement, and give the address authority to them! It's important for OSI to grow that this politically correct process be fixed, and at least NIST is trying hard to do that. Rich Collela and I have had a lot of fruitful discussions on this subject. But it's pretty darn broken now, and the Internet needs something a LOT better than that. Thanks, Milo PS You get 5 bytes of interdomain routing in US GOSIP. More thrust, but not enough to get into orbit... PPS Usual disclaimers apply... From owner-Big-Internet@munnari.oz.au Sat Jul 4 03:09:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24529; Sat, 4 Jul 1992 03:09:54 +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 AA24525; Sat, 4 Jul 1992 03:09:47 +1000 (from bmanning@is.rice.edu) Received: from san-miguel.is.rice.edu by is.rice.edu (AA04101); Fri, 3 Jul 92 12:09:43 CDT Received: by san-miguel.is.rice.edu (AA13440); Fri, 3 Jul 92 12:09:42 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9207031709.AA13440@san-miguel.is.rice.edu> Subject: Re: Defeat snatched from the jaws of Victory... To: kre@munnari.oz.au (Robert Elz) Date: Fri, 3 Jul 92 11:54:46 CDT In-Reply-To: <19158.710177432@munnari.oz.au>; from "Robert Elz" at Jul 4, 92 1:30 am X-Mailer: ELM [version 2.3 PL11] Sender: bmanning@is.rice.edu Robert Elz > > General feeling has been that only one more major change can > be supported in the Internet - certainly only one more in the > forseeable future, after that inertia will simply be too much > to overcome, and nothing more than tinkering around the edges > will really be possible. > > The IAB's decision has gone against this as well, they're > actually planning for two radical revisions, CLNP, and then > something later once a choice has been made, to add policy > routing, etc, which CLNP won't give. > And what happens when something stops growing? If the current Internet can only take one more "hit", then maybe the IAB is right, One last hurrah for the IP/CLNP based internet, and then on to bigger and better things... At least we should have a transition plan... (How much of this was already covered in the ROAD discussions?) -- 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 Sat Jul 4 03:11:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24548; Sat, 4 Jul 1992 03:11:16 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207031711.24548@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24545; Sat, 4 Jul 1992 03:11: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 ; Fri, 3 Jul 1992 18:10:50 +0100 To: "Milo S. Medin" (NASA ARC NSI Office) Cc: big-internet@munnari.oz.au Subject: Re: IPv7 (CLNP) a mistake hmmm Date: Fri, 03 Jul 92 18:10:23 +0100 From: Jon Crowcroft >Jon, I do not the believe the IAB is proposing the allocation of NSAP addresses thats realy weird - i mean a CLNP packet without an NSAP is like a fish with a bicycle...or why not just do IP with 20 byte addresses...less changes to the routers and hosts:-) >being able to get an address without the manager of that organization having >to approve it. This has allowed IP to sneak in to many places, subverting >the MIS departments in many large organizations. The OSI process on the other absolutely agree! >PS You get 5 bytes of interdomain routing in US GOSIP. More thrust, but not >enough to get into orbit... right - sounds plausible, not far off what i thought! >PPS Usual disclaimers apply... dis claimer is better than DAT jon From owner-Big-Internet@munnari.oz.au Sat Jul 4 03:24:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24817; Sat, 4 Jul 1992 03:24:35 +1000 (from owner-Big-Internet) Return-Path: Received: from hobbit.gandalf.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24814; Sat, 4 Jul 1992 03:24:26 +1000 (from mm@cannibal.gandalf.ca) Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA11368; Fri, 3 Jul 92 13:24:20 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA14378; Fri, 3 Jul 92 13:24:17 EDT Date: Fri, 3 Jul 92 13:24:17 EDT From: mm@gandalf.ca (Mississippi Mud) Message-Id: <9207031724.AA14378@cannibal.gandalf.ca> To: kre@munnari.oz.au Subject: Re: Defeat snatched from the jaws of Victory... Cc: big-internet@munnari.oz.au b) CLNP is too similar to IP (b) indicates that while CLNP will take a massive effort to deploy, the actual benefit in doing that might not be nearly as much as it would appear at first glance, and that this step may not end up actually lasting long before another radical change is needed. At the risk of being labelled an OSI nut or something, I'd just like to say that if this adoption of such a similar protocol were not seen to be so radical a few years earlier, the addressing problem would not be so pressing now. I can recall 3 years ago Radia Perlman telling a room full of IEEE Infocom attendees that IP's address space was too small. Now that it is down to the wire, it is a more massive undertaking, and since it still seems so radical to go to CLNP, all kinds of structural changes are being thrown into the discussion, and the ideas range from band-aids to replacing internal combustion with solar power. The big problem with CLNP seems to be in how the address space is structured. So redesign it; everybody else does! The argument about the ISO adopting TCP/IP, if you look deeper, indicates that decisions taken about the Internet are likely to find their way into these other standards eventually anyway, regardless of who buys into what process. The reason being that they are often TC (Technically Correct). Don't refuse a solution just because someone's trying to pour it down your throat. -Chris Sullivan From owner-Big-Internet@munnari.oz.au Sat Jul 4 03:42:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25182; Sat, 4 Jul 1992 03:43: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 AA25178; Sat, 4 Jul 1992 03:42:50 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11815>; Fri, 3 Jul 1992 10:42:23 PDT Received: from localhost ([127.0.0.1]) by skylark.parc.xerox.com with SMTP id <22277>; Fri, 3 Jul 1992 10:42:14 -0700 To: "Milo S. Medin" (NASA ARC NSI Office) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: IPv7 (CLNP) a mistake hmmm In-Reply-To: Your message of Fri, 03 Jul 92 09:48:28 -0700. <9207031648.AA13870@dscs.arc.nasa.gov> Date: Fri, 3 Jul 1992 10:42:12 PDT From: Steve Deering Message-Id: <92Jul3.104214pdt.22277@skylark.parc.xerox.com> > PS You get 5 bytes of interdomain routing in US GOSIP. More thrust, but not > enough to get into orbit... If you were to allocate 2 bytes to identify "city" (i.e., a geographical region about the size covered by a telephone area code), and three bytes to identify the domain within the city, that would allow up to 16 million domains in each of 65 thousand cities, assuming flat allocation within each of those two levels. (Really big cities with more than 16 million IP routing domains could be assigned multiple city codes.) That ought to get you into orbit around this planet, and even around this solar system. Steve From owner-Big-Internet@munnari.oz.au Sat Jul 4 04:06:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25658; Sat, 4 Jul 1992 04:07:08 +1000 (from owner-Big-Internet) Return-Path: Received: from ray.lloyd.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25652; Sat, 4 Jul 1992 04:06:58 +1000 (from brian@lloyd.com) Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01695; Fri, 3 Jul 92 11:06:16 PDT Date: Fri, 3 Jul 92 11:06:16 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207031806.AA01695@ray.lloyd.com> To: craig@aland.bbn.com Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov In-Reply-To: Craig Partridge's message of Thu, 02 Jul 92 16:08:29 -0700 <9207022308.AA28811@aland.bbn.com> Subject: IPv7 (CLNP) a mistake Reply-To: brian@lloyd.com Could someone please set me straight. I thought that IPv7 as proposed by the IAB would be an attempt to take what has been learned from CLNP and apply it to a new protocol/packet format. From this point of view IPv7 is not CLNP. It is a new protocol/packet format that is based on knowledge gleaned from both IP and CLNP, therefore, since we are trying to create a new protocol that meets the needs of the Internet there is no rational reason to participate in either the ISO or the CCITT standards process. Like many of you I also subscribe to the school of thought that the standards organizations tend to throw a lot of excess baggage into their protocols (the kitchen sink school of protocol design :-). On the other hand, just because you throw in lots of useless things doesn't mean that you don't toss in the occasional useful feature as well. Old saying, "even a blind hog finds an acorn occasionally." Think of CLNP as a [not-so] grand experiment from which we can learn and improve. Is this not the Internet Way; to try something, learn from it, and then use the experience to improve the protocol? From that point of view CLNP is merely a first cut. So a new protocol -based- on CLNP (and IP) might not be a bad idea as long as we are not talking slavish adherence to ISO excessiveness. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 P.S. Seems to me that this might be a good opportunity to bury the hatchet (no, not in each other's skulls) and let the ISORMites seriously participate in the development of CLNP-II (nicknamed IPv7 but they'll know it is really an improved and streamlined CLNP). [;-) * 0.5] B From owner-Big-Internet@munnari.oz.au Sat Jul 4 04:30:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26104; Sat, 4 Jul 1992 04:30:29 +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 AA26098; Sat, 4 Jul 1992 04:30:11 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA22768; Fri, 3 Jul 92 11:29:59 -0700 Date: Fri, 3 Jul 92 14:03:21 EDT From: "William Allen Simpson" Message-Id: <509.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Imbedding IP addresses in short NSAPs There has been a great deal of moaning about the length of NSAPs and alignment problems in CLNP. If we, as a group, get a AFI/IDI pair of our own, we can define the NSAP to be as long or as short as we want. Or variable length. The alignment looks pretty hopeless. But because of the destination length field, at least the destination always starts on an even byte. We should just define our NSAP length to come out odd, which will put the source length on an odd byte, and the source address on an even byte. In another message, I propose a 32,64,96,128 ... bit address format. Adding the 1 octet IP protocol (NSEL) field at the end will give us the odd length. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Sat Jul 4 04:30:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26105; Sat, 4 Jul 1992 04:30:29 +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 AA26096; Sat, 4 Jul 1992 04:30:10 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA22765; Fri, 3 Jul 92 11:29:17 -0700 Date: Fri, 3 Jul 92 12:41:41 EDT From: "William Allen Simpson" Message-Id: <508.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Class 'E' - Extending the IP address Ah, a long weekend. Time to crank out a couple more ideas. This one probably isn't new, but I'll float it anyway, since we need to do something about variable length addresses in light of the IAB's "CLNP decision". CLASS 'E' - AN EXTENSIBLE IP ADDRESS Introduction Once upon a time, the IP protocol stack was criticized because of the large size of its headers. One of the principle reasons for the size was the use of 32 bit addresses. This was larger than some other addressing spaces then in use. Despite this foresight, it is now expected that this space of over four billion addresses will be exhausted sometime in the not too distant future. Currently, all IP addresses are 32 bits (4 octets) in length. This is a convenient size for many common computer processors. In particular, this size leads to efficient memory timing utilization. Memory access is often the bottleneck in forwarding packets. This proposal uses the next defined "class" to provide a self encoded extensible address space, while continuing 32 bit boundary alignment. Classes The current IP Protocol specification [RFC791] defines a set of classes as follows: High Order Bits Format Class --------------- ------------------------------- ----- 0 7 bits of net, 24 bits of host a 10 14 bits of net, 16 bits of host b 110 21 bits of net, 8 bits of host c 111 escape to extended addressing mode Since that time, Class 'D' has been carved out of the end of Class 'C' for Multicast [RFC????]. 1101 Multicast This proposal defines the Class 'E' for Extended Addressing, and reserves Class 'F' for Future Use. It is noted that 'FF' is already reserved for broadcast in all classes. 1110 Extended Addressing 1111 Future Use 1111 1111 Broadcast Extended Addresses The Extended Address provides for a self encoded extensible address space which is 32 bit aligned. This space is "classless". A separate "network mask" may be used to delineate the network, subnet, and host parts of the address [RFC????]. The length of the address may be determined by the low order bits in the first octet of the Extended Address: First Octet Length --------------- ------------------------------- 1110 0xxx 64 bits (8 octets) 1110 10xx 96 bits (12 octets) 1110 110x 128 bits (16 octets) 1110 1110 160 bits (20 octets) 1110 1111 reserved for future expansion It is expected that this mapping will take us well into the next millenium, until we need to number all of the sub-atomic particles in the universe, or until ever-expanding allocation committees decide we need more, whichever is sooner. Heterogeneous Environment It is intended that 32 bit addresses will remain the primary form of address. In particular, addresses which are frequently examined by large numbers of machines, such as broadcasts and multicasts, MUST always be sent in the 32 bit form. The final 32 bits of any Extended Address SHOULD be an address of classes A to D. This facilitates mapping addresses between current and future addressing formats. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Sat Jul 4 04:36:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26246; Sat, 4 Jul 1992 04:37:15 +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 AA26234; Sat, 4 Jul 1992 04:36:44 +1000 (from craig@aland.bbn.com) Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA18643; Fri, 3 Jul 92 14:36:23 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA02858; Fri, 3 Jul 92 11:35:22 PDT Message-Id: <9207031835.AA02858@aland.bbn.com> To: brian@lloyd.com (Brian Lloyd) Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov Subject: re: IPv7 (CLNP) a mistake Reply-To: Craig Partridge From: Craig Partridge Date: Fri, 03 Jul 92 11:35:21 -0700 Sender: craig@aland.bbn.com Brian: See my note to Bob Braden of yesterday. The goal is to adopt ISO CLNP and to keep in harmony (the exact words are "functionally compatible" and "convergent") with ISO CLNP. IPv7 is CLNP by another name. Craig From owner-Big-Internet@munnari.oz.au Sat Jul 4 04:48:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26541; Sat, 4 Jul 1992 04:48:18 +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 AA26534; Sat, 4 Jul 1992 04:48:09 +1000 (from estrin%caldera.usc.edu@usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA26503; Fri, 3 Jul 92 11:46:28 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA09841; Fri, 3 Jul 92 11:46:28 PDT Date: Fri, 3 Jul 92 11:46:28 PDT Message-Id: <9207031846.AA09841@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin%caldera.usc.edu@usc.edu To: lixia@parc.xerox.com Cc: craig@aland.bbn.com, big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov In-Reply-To: Lixia Zhang's message of Thu, 2 Jul 1992 16:43:02 PDT Subject: Re: IPv7 (CLNP) a mistake Reply-To: estrin@usc.edu It sounds as if : 1. The IAB needs to explain why it believes we can adopt CLNP format and still have change control. 2. Those who have experience with CLNP need to convince us that progress/solutions for multicast, mobility, etc developed for IP are TECHNICALLY portable; IF we can assume that 1 makes them politically portable. 3. Someone from the IAB needs to summarize why the alternatives available today were not found to be viable. eg. what aspects of an IP encapsulation scheme are too risky to assume a robust system wide implementation and deployment in the timeframe required. The CLNP folks (not only from digital but other places) claim experience running CLNP and it seems that the IAB felt a somewhat "conservative", i.e. low risk, strategy was essential. Do you disagree with a) their assessment of the risk of other schemes, b) the risk of CLNP, or c) their making the conservative choice? Finally, I was not able to attend the San Diego IETF but I **thought** that the CLNP based scheme was put forth at that time and that community discussion was requested. But this could be a misperception on my part. Is it? D. From owner-Big-Internet@munnari.oz.au Sat Jul 4 04:56:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26642; Sat, 4 Jul 1992 04:56:21 +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 AA26639; Sat, 4 Jul 1992 04:56:12 +1000 (from estrin%caldera.usc.edu@usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA26731; Fri, 3 Jul 92 11:56:02 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA09861; Fri, 3 Jul 92 11:56:02 PDT Date: Fri, 3 Jul 92 11:56:02 PDT Message-Id: <9207031856.AA09861@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin%caldera.usc.edu@usc.edu To: deering@parc.xerox.com Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov In-Reply-To: Steve Deering's message of Thu, 2 Jul 1992 18:36:18 PDT <92Jul2.183627pdt.22277@skylark.parc.xerox.com> Subject: Re: IPv7 (CLNP) a mistake Reply-To: estrin@usc.edu I have to second Steve's comments about the timing question. That question needs to be answered before any of the ones i mentioned in my prev message, namely "WHy doesn't CIDR give us just a bit of breathing room in which to spend n months evaluating the alternatives with the attention this issue deserves?". THere might be a reasonable answer to this, but I cant come up with it first hand... From owner-Big-Internet@munnari.oz.au Sat Jul 4 05:00:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26700; Sat, 4 Jul 1992 05:01: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 AA26693; Sat, 4 Jul 1992 05:00:57 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11820>; Fri, 3 Jul 1992 12:00:29 PDT Received: from localhost ([127.0.0.1]) by skylark.parc.xerox.com with SMTP id <22277>; Fri, 3 Jul 1992 12:00:19 -0700 To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Class 'E' - Extending the IP address In-Reply-To: Your message of Fri, 03 Jul 92 09:41:41 -0700. <508.bsimpson@angband.stanford.edu> Date: Fri, 3 Jul 1992 12:00:17 PDT From: Steve Deering Message-Id: <92Jul3.120019pdt.22277@skylark.parc.xerox.com> > Since that time, Class 'D' has been carved out of the end of Class 'C' > for Multicast [RFC????]. > > 1101 Multicast Incorrect. Class D was carved out of "reserved", and is identified by 1110 in the high-order four bits. So it's now: 0 class A 10 class B 110 class C 1110 class D (multicast) 1111 reserved The multicast reference is RFC 1112. Steve From owner-Big-Internet@munnari.oz.au Sat Jul 4 05:07:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26775; Sat, 4 Jul 1992 05:08:01 +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 AA26772; Sat, 4 Jul 1992 05:07:45 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA05977; Fri, 3 Jul 92 12:07:06 PDT Date: Fri, 3 Jul 92 12:07:06 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9207031907.AA05977@saffron.acc.com> To: bsimpson@angband.stanford.edu Subject: Re: Class 'E' - Extending the IP address Cc: big-internet@munnari.oz.au Bill: May I suggest that you re-title your proposal? You used the same address space as the previous Class E proposal, but did something very different with it. How about "variable length IP Address"? (cough, gag, choke). I have one suggestion to add to it: let the remaining 24 bits of the first 32 indicate who assigned the address, and let all such addresses provide a 16 bit trailing "host number". The part in the middle is at the discretion of the assigning authority. Route aggregation would occur by having routers outside the assigning domain route toward the domain (the first 32 bits); only routers in the target domain would have to deal with the remainder. Fred From owner-Big-Internet@munnari.oz.au Sat Jul 4 05:34:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27284; Sat, 4 Jul 1992 05:34:54 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207031934.27284@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27281; Sat, 4 Jul 1992 05:34:46 +1000 (from jcurran@nic.near.net) To: peter@goshawk.lanl.gov Cc: Big-Internet@munnari.oz.au Subject: Re: CIDR & C# In-Reply-To: Your message of Thu, 02 Jul 92 13:59:30 -0700. <9207021959.AA24236@goshawk.lanl.gov> Date: Fri, 03 Jul 92 15:34:33 -0400 From: John Curran -------- ] From: peter@goshawk.lanl.gov ] Subject: Re: CIDR & C# ] Date: Thu, 02 Jul 92 13:59:30 MST ] ] ... ] I believe a mistake to avoid is the notion of assigning a block ] to a provider and assuming that the provider "owns" the block ad infinitum. ] ] What would be preferable would be a two phase commit, essentially ] allocating a block of addresses to a provider, and the provider to ] assign the network addresses. There is difference between allocation ] and assignment. With the block allocation the provider accepts a ] stewardship for good address assignment. If the top level numbering ] authority (IANA/NIC) needs a subtree of addresses back, the provider ] could be *required* to relinquish the largest power of two sized block ] of unassigned addresses and readvertise the routing of the assigned ] networks using longer prefixes out of the originally allocated prefix. I was not precise in my mail. I had presumed that the provider was simply an agent in the assignment process and did not "own" the addresses in the interim. ] If such a strategy were adopted, we could afford large "allocations" ] since over time the top level can reclaim unassigned addresses to ] be reallocated. Yes, this could be done if one presumes that relatively few blocks are "allocated" and hence the administrative burden of reclaimation was low. Note that many IP network allocations have become "lost" as organizations and contacts change over time. I don't think that we'd like to have a significant part of the address space "lost" in this manner. My concern over large block allocation stems from the possibility of hundreds of network service providers in growing Internet. Any large allocation runs the risk of having to be "recalled" and split in order to provide sufficient addresses for future providers. Failure to provide for the entry of providers create a barrier after the NREN plan has worked so hard to avoid such barriers. ] This could be done at various levels of the CIDR hierarchy, such ] as continents/countries/U.S. regionals/campuses. At the bottom levels, gains are very significant. Encouraging each provider to aggregate their o(1000) routes into 10 routes would be very worthwhile. Trying to insure that these aggregate into a single route for each provider requires long-term stability that may not be present. /John From owner-Big-Internet@munnari.oz.au Sat Jul 4 05:54:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27588; Sat, 4 Jul 1992 05:54:15 +1000 (from owner-Big-Internet) Return-Path: Received: from HQ.TGV.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27572; Sat, 4 Jul 1992 05:54:01 +1000 (from karl@Mel-Brooks.TGV.COM) Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ; Fri, 3 Jul 92 12:53:32 PDT Received: from karl.lvs.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1) id AA01043; Fri, 3 Jul 92 12:54:39 PDT Date: Fri, 3 Jul 92 12:54:39 PDT Message-Id: <9207031954.AA01043@mel-brooks.empirical.com> To: lixia@parc.xerox.com Subject: Re: IPv7 (CLNP) a mistake From: karl@Mel-Brooks.TGV.COM (Karl Auerbach, Empirical Tools and Technologies, 408/427-5280) Reply-To: karl@TGV.COM Cc: craig@aland.bbn.com, big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov Sender: karl@Mel-Brooks.TGV.COM Repository: empirical.com Originating-Client: lvs.empirical.com I agree with Lixia. There are a number of problems with our current IP protocol, only one of which is the address size. There are many useful ideas we can glean from CLNP (I personally like non-segmenting nets), but the pain of a wholesale transition to CLNP would not be offset by the relatively small increment in capability. I, personally, like many of the ideas in NIMROD. I, like most of us, don't have the foggiest notion, however, how they might be implemented. And I certainly want to make sure that whatever protocol we do adopt avoids performance stupidies like variable size fields, critical data at indeterminate offsets, checksums at the beginning or middle of the packet, and overly-huge addresses. And there is nothing in CLNP (or IP) to make life pleasant for nomadic devices. [However, I am becomming increasingly convinced that nomadic operation is more a concern for applications and applications protocols than it is for the network layer and ancillary routing protocols.] Remember, that we are talking about the protocol that happens with each packet as it passes through each router. That means it happens *many* times per second, making little inefficiencies into a big overhead. --karl-- > > In short, CLNP as IPv7 seems destined to be a technical step backwards > > and to place a severe crimp on protocol innovation at a time when we > > need to innovate. > > I agree with this statement with my both hands up. > > For decisions this big, I'm shocked to see that IAB made the move > without holding an open hearing period for opinions from the internet > community. > > I would like to hear how other people think about this. > > Lixia From owner-Big-Internet@munnari.oz.au Sat Jul 4 06:38:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28422; Sat, 4 Jul 1992 06:38:38 +1000 (from owner-Big-Internet) Return-Path: Received: from ray.lloyd.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28419; Sat, 4 Jul 1992 06:38:28 +1000 (from brian@lloyd.com) Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA01877; Fri, 3 Jul 92 13:37:57 PDT Date: Fri, 3 Jul 92 13:37:57 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207032037.AA01877@ray.lloyd.com> To: craig@aland.bbn.com Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov In-Reply-To: Craig Partridge's message of Fri, 03 Jul 92 11:35:21 -0700 <9207031835.AA02858@aland.bbn.com> Subject: IPv7 (CLNP) a mistake Reply-To: brian@lloyd.com Reply-To: Craig Partridge From: Craig Partridge Date: Fri, 03 Jul 92 11:35:21 -0700 Sender: craig@aland.bbn.com Brian: See my note to Bob Braden of yesterday. The goal is to adopt ISO CLNP and to keep in harmony (the exact words are "functionally compatible" and "convergent") with ISO CLNP. IPv7 is CLNP by another name. Craig I saw it after I made my posting. I am not now quite as enamored of the idea as I originally was. Going with CLNP verbatim implies that we go along with the braindamaged way that ISO wants to assign addresses. In that case I think that CLNP is a bad idea. Rolling something new that borrows from the good features of IP and CLNP but does away with their respective warts is a good thing. Going with CLNP en toto just doesn't seem worth the pain. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From owner-Big-Internet@munnari.oz.au Sat Jul 4 06:43:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB28557; Sat, 4 Jul 1992 06:43:23 +1000 (from owner-Big-Internet) Return-Path: Received: from jarvis.csri.toronto.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28549; Sat, 4 Jul 1992 06:43:14 +1000 (from @jarvis.csri.toronto.edu,@relay.cs.toronto.edu:@smoke.cs.toronto.edu:rayan@cs.toronto.edu) Received: by jarvis.csri.toronto.edu id <61>; Fri, 3 Jul 1992 16:42:53 -0400 To: Big-Internet@munnari.OZ.AU From: rayan@cs.toronto.edu (Rayan Zachariassen) Subject: Re: Draft IESG recommendation on ROAD activities Organization: Department of Computer Science, University of Toronto References: <9207031535.AA24596@ginger.lcs.mit.edu> Distribution: list Date: Fri, 3 Jul 1992 16:42:43 -0400 Message-Id: <92Jul3.164253edt.61@jarvis.csri.toronto.edu> jnc@ginger.lcs.mit.edu (Noel Chiappa) writes: > For that matter, I doubt we do a DNS lookup on every piece of mail >now; probably 'MUNNARI.OZ.AU' is already in the DNS cache on this machine! Don't underestimate the sloth of even a local cache. In a mailer I used to treat the DNS as a "fast" database on the assumption that typical access patterns would make effective use of the cache maintained in the nameserver process, and so I only maintained a small LRU cache in the querying process. I've seen the effect of increasing the LRU cache size in the querying process by a factor N: throughput went up by a similar factor (the real numbers are: LRU cache size from 10 to 200, processing time from 200 to 15 seconds). In other words, querying a local cache that must be accessed with "overhead" can be a significant bottleneck. rayan From owner-Big-Internet@munnari.oz.au Sat Jul 4 06:52:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28680; Sat, 4 Jul 1992 06:52: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 AA28677; Sat, 4 Jul 1992 06:52:25 +1000 (from ljm@ftp.com) Received: from ljm.leather-lace.ftp.com by ftp.com via PCMAIL with DMSP id AA08999; Fri, 3 Jul 92 16:56:52 -0400 Date: Fri, 3 Jul 92 16:56:52 -0400 Message-Id: <9207032056.AA08999@ftp.com> To: big-internet@munnari.oz.au Subject: If TUBA is the answer, it must be a very silly question... From: ljm@ftp.com (leo j mclaughlin iii) Reply-To: ljm@ftp.com Cc: iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov Sender: ljm@ftp.com Repository: babyoil.ftp.com Originating-Client: leather-lace.ftp.com At the IETF in San Diego, the ROAD 'WG meetings' wrestled with the question of what problems we were trying to solve. As I recall, three items stood above all else: 1) Building toward a long term future in which network nodes became cheap, mobile, and plentiful. A future in which everything from one's toaster to one's wristwatch/alarm was on the network. 2) Creating the routing infrastructure to handle the sort of network traffic and complexity such a future will bring. 10 to the 9th networks was the number most frequently mentioned. 3) Allow existing hosts and networks to work as well as possible for as long as possible. All our experience in trying to upgrade existing implementations shows that for whatever reasons the installed base is extremely resistant to change. Having read the draft, I do not understand how a transition strategy which views CLNP as IPv7 as a replacement for IPv4 hopes to meet these problems. 1) Cheap -- Implementation experience has shown that CLNP is unsuccessful as a solution for cheap end nodes. Even where it has been divorced from the OSI upper layers and installed by edict (e.g. MAP/TOP using NetBIOS over TP4 over CLNP) it is being replaced by TCP/IP because of CLNP's performance penalties in both size and throughput. Mobile -- While it might be possible to transfer the work done in mobile hosts, dynamic addressing, and multi-cast to CLNP it is exceedingly doubtful that the attempt to change the basic infrastructure of the internet would hasten the deployment of such technologies. Plentiful -- Neither TUBA nor IPAE will probably be able to deal with truly large values of plentiful and this is acknowledged by both documents. However, TUBA requires that every host and every network on the Internet be significantly modified in order to reach that intermediate state. 2) Most of the arguments about 'Plentiful' can be applied here as well. However, it can also be noted that our router implementation experience has shown that the variable length addressing structure of CLNP makes it suboptimal for high speed routers. 3) Though the internet draft has some words to the contrary, TUBA seems to ignore the importance of maintaining compatibility with existing systems. Today we have an infrastructure that delicately balances between ARP, proxy ARP, RARP, BOOTP, IP, ICMP, RIP, other routing protocols, and the many and varied applications of the Internet. To seek to substantially modify that infrastructure -- and to mandate that change within a short timeframe -- is extraordinarily foolish. enjoy, leo j mclaughlin iii ljm@ftp.com From owner-Big-Internet@munnari.oz.au Sat Jul 4 07:00:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28833; Sat, 4 Jul 1992 07:00:15 +1000 (from owner-Big-Internet) Received: from merit.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28830; Sat, 4 Jul 1992 07:00:09 +1000 (from mak@merit.edu) Return-Path: Received: from home.merit.edu by merit.edu (5.65/1123-1.0) id AA12475; Fri, 3 Jul 92 16:59:21 -0400 Received: by home.merit.edu (4.1/client-0.9) id AA06542; Fri, 3 Jul 92 16:32:48 EDT From: mak@merit.edu Message-Id: <9207032032.AA06542@home.merit.edu> To: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov Subject: IPv7 Date: Fri, 03 Jul 92 16:32:46 -0400 We would like to express our strong support for the decision made by the IAB with respect to adopting CLNP as the basis for V7 of the Internet Protocol. It is high time to acknowledge that the Internet involves significant investment from the computer industry (both within the US and abroad), and provides production services to an extremely large and diverse population of users. Such and environment dictates that decisions about critical aspects of the Internet should lean towards conservatism, and should clearly steer away from proposals whose success is predicated on some future research. While other than CLNP proposals may on the surface sound tempting, the Internet community should not close its eyes to plain reality -- namely that at the present moment these proposals are nothing more than just proposals; with no implementations, no experience, and in few cases strong dependencies on future research and funding. Resting the Internet future on such foundation creates and unjustifiable risk for the whole Internet community. The decision made by the IAB clearly demonstrated that the the IAB was able to go beyond parochial arguments (TCP/IP vs CLNP), and make its judgements based on practical and pragmatic considerations. Yakov Rekhter (IBM Corporation) Mark Knopper (Merit Network) From owner-Big-Internet@munnari.oz.au Sat Jul 4 07:21:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29108; Sat, 4 Jul 1992 07:21:39 +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 AA29105; Sat, 4 Jul 1992 07:21:34 +1000 (from dino@cisco.com) Received: by regal.cisco.com; Fri, 3 Jul 92 14:21:11 -0700 Date: Fri, 3 Jul 92 14:21:11 -0700 From: Dino Farinacci Message-Id: <9207032121.AA11816@regal.cisco.com> To: mak@merit.edu Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov In-Reply-To: mak@merit.edu's message of Fri, 03 Jul 92 16:32:46 -0400 <9207032032.AA06542@home.merit.edu> Subject: IPv7 >> We would like to express our strong support for the decision >> made by the IAB with respect to adopting CLNP as the basis for >> V7 of the Internet Protocol. My sentiments exactly. Note the phrase "as the basis for V7". Was not OSPF based on IS-IS, was not SNMP based on ASN.1. Is not IDRP based on BGP. Is not CLNS multicasting based on Deering's work. These are all protocols/technologies. Let's use any of them to our advantage. >> The decision made by the IAB clearly demonstrated that the >> the IAB was able to go beyond parochial arguments (TCP/IP vs >> CLNP), and make its judgements based on practical and pragmatic >> considerations. I agree. Dino P.S. There is relief, nothing new is based on RIP :-) From owner-Big-Internet@munnari.oz.au Sat Jul 4 07:55:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29617; Sat, 4 Jul 1992 07:55:07 +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 AA29602; Sat, 4 Jul 1992 07:55:01 +1000 (from braden@ISI.EDU) Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Fri, 3 Jul 1992 14:44:54 -0700 Date: Fri, 3 Jul 1992 14:42:56 -0700 From: braden@ISI.EDU Posted-Date: Fri, 3 Jul 1992 14:42:56 -0700 Message-Id: <199207032142.AA05142@braden.isi.edu> Received: by braden.isi.edu (5.65c/4.0.3-4) id ; Fri, 3 Jul 1992 14:42:56 -0700 To: craig@aland.bbn.com Subject: re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov In short we will adopt CLNP (an ISO protocol); we wish to be "functionally and syntactically" compatible and to "converge" with OSI; and want to be able to make "changes ... necessary for successful, deployment, operation, and evolution of IPv7." If we want to make changes and still be compatible with and converge with OSI, we'll have to convince ISO to go along, which means we have to work in the ISO standards process. So we've bought into the ISO process (for the network layer). Craig Craig, An argument that came up repeatedly in IAB discussions was the objection that adapting (note the "a") CLNP was a case of trying to have our cake and eat it too. Well, yes. And I believe we can. If and where CLNP does not work, let's fix it. There is nobody -- except ourselves -- who can stop us from succeeding. In the quotation you cite, convergence with OSI is clearly labelled as a long-term goal, not a requirement for IPv7. The primary requirement for IPv7 is to work in the global Internet. We do not have to ask anyone's permission. I think it also says that the IAB/IETF should adopt an address format appropriate for the Internet. A lot of us share the suspicion that this will NOT be any of the existing NSAP formats. How about real-time? My view is that real-time is still research. It's coming, but we have to expand the address space on a shorter timeframe. We don't have enough faith in the CIDR approach to bet our Internet on it. I hope that replacing the 60 byte limit on IP headers with a 254 byte limit will help us to do initial real-time work, using options. How about multicasting? The document says (clearly, I hope) that there must be no regression of functionality, and it specifically mentions multicast. It was my understanding that CLNP multicast along the IP multicast model was a done deal, except for a logjam created by the OSI standards process. That logjam is irrelevant to the IETF. Let's do it. Above all, "Don't panic!" Bob. From owner-Big-Internet@munnari.oz.au Sat Jul 4 07:57:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29691; Sat, 4 Jul 1992 07:58:00 +1000 (from owner-Big-Internet) Return-Path: Received: from animal.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29678; Sat, 4 Jul 1992 07:57:49 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA25190; Fri, 3 Jul 92 17:53:43 EDT Date: Fri, 3 Jul 92 17:53:43 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9207032153.AA25190@animal.clearpoint.com> To: bsimpson@angband.stanford.edu, deering@parc.xerox.com Subject: Re: Class 'E' - Extending the IP address Cc: big-internet@munnari.oz.au As Steve points out, this proposal would have to use part of the "real" class E space, thus the first byte of the address would be of the form '1111 0xxx'. Would it possibly make more sense to use the next three bits as an integer field instead (eg: 1111 0000 -> 64 bits, 1111 0001 -> 128..) Also, could/should the three bytes between this format identifier and the first part of the address be used for anything? -- Frank From owner-Big-Internet@munnari.oz.au Sat Jul 4 08:07:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29894; Sat, 4 Jul 1992 08:07:17 +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 AA29891; Sat, 4 Jul 1992 08:07:09 +1000 (from braden@ISI.EDU) Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Fri, 3 Jul 1992 15:08:40 -0700 Date: Fri, 3 Jul 1992 15:06:41 -0700 From: braden@ISI.EDU Posted-Date: Fri, 3 Jul 1992 15:06:41 -0700 Message-Id: <199207032206.AA05212@braden.isi.edu> Received: by braden.isi.edu (5.65c/4.0.3-4) id ; Fri, 3 Jul 1992 15:06:41 -0700 To: J.Crowcroft@cs.ucl.ac.uk Subject: IPv7 Checksum Cc: big-internet@munnari.oz.au So, Jon, should IPv7 use the IPv4 checksum, or can we come up with a different checksum that also provides byte swap protection but is easier/faster to compute than the 8473 checksum? Bob From owner-Big-Internet@munnari.oz.au Sat Jul 4 08:12:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29966; Sat, 4 Jul 1992 08:12:32 +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 AA29962; Sat, 4 Jul 1992 08:12:27 +1000 (from braden@ISI.EDU) Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Fri, 3 Jul 1992 15:05:09 -0700 Date: Fri, 3 Jul 1992 15:03:12 -0700 From: braden@ISI.EDU Posted-Date: Fri, 3 Jul 1992 15:03:12 -0700 Message-Id: <199207032203.AA05199@braden.isi.edu> Received: by braden.isi.edu (5.65c/4.0.3-4) id ; Fri, 3 Jul 1992 15:03:12 -0700 To: bsimpson@angband.stanford.edu, ietf@ISI.EDU Subject: Re: why 160-bit addresses are daft.... Cc: big-internet@munnari.oz.au So, you can see that big headers are not what we want here. Someday, there may be header compression for CLNP. Bill, So, let's make it someday very soon. Certainly, you are right: without acceptable header compression, IPv7 would be a loser over low bandwidth paths. Bob Braden From owner-Big-Internet@munnari.oz.au Sat Jul 4 08:20:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00206; Sat, 4 Jul 1992 08:20:32 +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 AA00203; Sat, 4 Jul 1992 08:20:26 +1000 (from braden@ISI.EDU) Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Fri, 3 Jul 1992 15:13:48 -0700 Date: Fri, 3 Jul 1992 15:11:50 -0700 From: braden@ISI.EDU Posted-Date: Fri, 3 Jul 1992 15:11:50 -0700 Message-Id: <199207032211.AA05238@braden.isi.edu> Received: by braden.isi.edu (5.65c/4.0.3-4) id ; Fri, 3 Jul 1992 15:11:50 -0700 To: brian@lloyd.com, craig@aland.bbn.com Subject: re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov From craig@aland.bbn.com Fri Jul 3 11:43:45 1992 To: brian@lloyd.com (Brian Lloyd) Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov Subject: re: IPv7 (CLNP) a mistake Reply-To: Craig Partridge From: Craig Partridge Date: Fri, 03 Jul 92 11:35:21 -0700 Sender: craig@aland.bbn.com Brian: See my note to Bob Braden of yesterday. The goal is to adopt ISO CLNP and to keep in harmony (the exact words are "functionally compatible" and "convergent") with ISO CLNP. IPv7 is CLNP by another name. Craig Craig, I hate to keep saying this, but your statement is incorrect. Bob Braden From owner-Big-Internet@munnari.oz.au Sat Jul 4 08:48:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00669; Sat, 4 Jul 1992 08:48:33 +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 AA00666; Sat, 4 Jul 1992 08:48:26 +1000 (from dino@cisco.com) Received: by regal.cisco.com; Fri, 3 Jul 92 15:48:18 -0700 Date: Fri, 3 Jul 92 15:48:18 -0700 From: Dino Farinacci Message-Id: <9207032248.AA12287@regal.cisco.com> To: braden@ISI.EDU Cc: bsimpson@angband.stanford.edu, ietf@ISI.EDU, big-internet@munnari.oz.au In-Reply-To: braden@ISI.EDU's message of Fri, 3 Jul 1992 15:03:12 -0700 <199207032203.AA05199@braden.isi.edu> Subject: why 160-bit addresses are daft.... >> So, let's make it someday very soon. Certainly, you are right: >> without acceptable header compression, IPv7 would be a loser over low >> bandwidth paths. Did anyone realize that a CLNP header with IP-address sized addresses gives you a header (without fragmentation) of 19 bytes in length. 9 bytes - fixed header 5 bytes - Source address 5 bytes - Destination address --- 19 No one said that IPv7 had to use GOSIP addresses. And from what I'm hearing, we don't want to. The IETF decides on the address length it wants to go with (note 5 bytes above - a address length byte included). Regarding byte alignment, when we switch a packet: 1) We need to look at version. IP - offset byte 0 CLNP - offset byte 2 2) We need to look at TTL. IP - offset byte 8 CLNP - offset byte 3 3) We need to look at the checksum. IP - offset byte 10 (2 bytes) CLNP - offset byte 5 (2 bytes) Pretty much the same processing (IETF could move the type byte to the end of the fixed header so the checksum is on even byte boundary) except for CLNP needs to look at NLPID to see if is truly a CLNS packet and the type byte to determine it is not an Error PDU. Regarding checksum algorithm. 1) Fletcher (OSI) checksum is slower because it is byte oriented. IP is word oriented and everyone does it on longword boundaries. Don't forget, this is only on the header, we're talking 20-30 bytes. Regarding addresses: 1) Will take longer with IPv7 because we are *required* to make them longer. So it is going to cost you something (but your getting something for it). OSI might be *big* but CLNP itself is not really any bigger than IP. Dino From owner-Big-Internet@munnari.oz.au Sat Jul 4 09:19:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01117; Sat, 4 Jul 1992 09:19:15 +1000 (from owner-Big-Internet) Return-Path: Received: from bellcore.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01114; Sat, 4 Jul 1992 09:19:10 +1000 (from mo@gizmo.bellcore.com) Received: from gizmo.bellcore.com by bellcore.bellcore.com (5.61/1.34) id AA02551; Fri, 3 Jul 92 19:19:00 -0400 Message-Id: <9207032319.AA02551@bellcore.bellcore.com> To: mak@merit.edu Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov, mo@gizmo.bellcore.com Subject: Re: IPv7 In-Reply-To: Your message of "Fri, 03 Jul 92 16:32:46 EDT." <9207032032.AA06542@home.merit.edu> Date: Fri, 03 Jul 92 19:18:58 -0400 From: mo@gizmo.bellcore.com I hardly see how the IAB suggestion is founded in any more real-world experience than anything else being examined. And it clearly suffers from at least one debilitating problem - squanderously-large addresses. Holding up the mantle of conservativism is hardly a vote for this half-baked CLNP approach. I may be Politically Correct, but it isn't technically supportable. -Mike From owner-Big-Internet@munnari.oz.au Sat Jul 4 09:22:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01158; Sat, 4 Jul 1992 09:22:54 +1000 (from owner-Big-Internet) Return-Path: Received: from bellcore.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01155; Sat, 4 Jul 1992 09:22:48 +1000 (from mo@gizmo.bellcore.com) Received: from gizmo.bellcore.com by bellcore.bellcore.com (5.61/1.34) id AA02575; Fri, 3 Jul 92 19:22:30 -0400 Message-Id: <9207032322.AA02575@bellcore.bellcore.com> To: Dino Farinacci Cc: braden@ISI.EDU, bsimpson@angband.stanford.edu, ietf@ISI.EDU, big-internet@munnari.oz.au, mo@gizmo.bellcore.com Subject: Re: why 160-bit addresses are daft.... In-Reply-To: Your message of "Fri, 03 Jul 92 15:48:18 PDT." <9207032248.AA12287@regal.cisco.com> Date: Fri, 03 Jul 92 19:22:29 -0400 From: mo@gizmo.bellcore.com Sorry, but when I read the document is said that IPv7 would use 20-byte addresses. Variable length addresses make the router folks nutso (and with good cause). -Mike From owner-Big-Internet@munnari.oz.au Sat Jul 4 09:36:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01386; Sat, 4 Jul 1992 09:36:24 +1000 (from owner-Big-Internet) Return-Path: Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01383; Sat, 4 Jul 1992 09:36:15 +1000 (from hwb@upeksa.sdsc.edu) Received: Fri, 3 Jul 1992 16:36:06 -0700 by upeksa.sdsc.edu (AIX/1.6) From: Hans-Werner Braun Message-Id: <9207032336.AA16883@upeksa.sdsc.edu> Subject: Milo going Nova. To: iab@isi.edu, big-internet@munnari.oz.au, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov Date: Fri, 3 Jul 92 16:36:05 PDT The following are somewhat random thoughts from a not-quite- innocent bystander. A large part is just my perspective on some background information that may be useful to understand the state of the current process and how things worked and work, and then later (last 1/3rd?) describing things in the context of IPv7. Sorry for the size of this note. Unless you have a serious interest in this area, you may want to skip it... I assume many of you remember the days, so many years ago, when the IAB was a group working on behalf of DARPA to give them input on things happening and on future research. A prominent Task Force (there were no working groups then), was the Gateway and And DataStructure (GADS, I *think* I got the name right) Task Force, then chaired by Dave Mills. Gosh, when was that? 84-85ish? I attended only their last meeting, by invitation of Dave Mills. Quite small group then, 15 to 20 people or so. The GADS was just about to split into the IETF (after having called INENG first) and the INARC (Internet Architecture Task Force). The INENG/IETF was chaired by Mike Corrigan, INARC by Dave Mills, both reporting directly to the IAB, and both quite small (still 15-20 or so people then, as there was alot of people overlap). Why was the GADS split then? There is a serious and everlasting controversy about immediate engineering concerns, as well as long term, research and architecture. The GADS tended to not work efficiently in both areas. Possibly because there are too many shades of gray? So, INENG/IETF were still quite small and fit into a small conference room. I remember even Scott Brim and myself taking a bit of a risk dragging Milo into his first of such meeting (conveniently happening at SRI at that time), as it was quite an invitation-only group. At some time it became clear that DARPA had some domestic constituents for networking, particularly from the NSFNET, including regional networks. I remember that I (and may be others) had a bit of a hard time to convince the IETF to allow the NSFNET constituents to be represented. It finally resulted in a small group of people meeting with Mike Corrigan in the Pentagon to discuss the issue to allow for the broadening of the INENG/IETF. I think this included (besides Mike Corrigan) Mike St.Johns (then with DCA), Phill Gross (then Mike C.'s assistant on INENG/IETF matters), Scott Brim and myself. Sorry if I left someone out here, but if at all, it could only have been one or two people more. After all the discussion before, I was surprised at how easy of a meeting this was. Mike C. essential just said ok, fine, or something like that. From that time on the IETF participation exploded, eventually even creating alot of interest with vendors and service providers. I also remember that it was a bit of a fight to even let others contribute to the Internet Monthly Reports, not to say that it even took MUCH longer to make IMRs publicly available. At some point of time the IAB reorganized into an IAB consisting of more technically oriented people, including continuing without the previously participating US government program managers. I think around that time the FRICC was also created, and lateron evolved into the FNC. I think at the time the organizational structure of the IAB was also changed, leaving only the IETF and IRTF left as Task Forces. Again, I just barely managed to be part of the *last* meeting of the old IAB structure. Over the years the IAB and IETF continued to evolve toward a quite open group. In particular the IETF works now under the premise of free participation for everyone who wants to. Today's quite large set of IETF working groups are managed by an Internet Engineering Steering group, on behalf of the IAB. The IETF/IESG is quite good at pushing protocols forward that they believe in, and typically forward recommendations to the IAB about what standardization status certain protocols should be at. There are two things that the IETF/IESG are not really that good at, which, obviously, the IAB also has to take blame for as well. A) the GADS syndrome of not always being able to differentiate between short term engineering and long term research, resulting in the development of some semi-relevant (to existing and imminent infrastructure) protocols and activities. There were, in fact, cases where operational requirements warranted certain kind of protocols soon, but the IESG preferred to focus on longer term things, that then never happened. Luckily enough, those cases did not happen very often, and all in all the protocol evolution works typically in a quite reasonable fashion and keeping most constituents happy. B) the other real issue with the IETF/IESG (and IAB, for that matter) appears in cases where there are multiple competing proposals for a continuation of efforts. Fighting those out in some cases results in quite polarized positions of people defending their preferred choice, many times between people with very strong personalities, quite able to defend their choices. Examples of this are the CMIP/SGMP and ISIS/OSPF debates, Bernstein's complaints, and introducing SMP late into IETF activities. If I were a vendor, non-decisions surely would confuse me seriously. Especially if all I wanted to do, as an industrial constituent, would be to deliver products and make money, while not having the resources to spend for probably at least a third of a full time person to just participate in the IETF discussions and meetings; not to speak of such a person having to be quite vocal, fluent in the language, strong in expressions and such, to survive with the sharks of the IETF/IESG/IAB who are into this for many years already. I have heard industrial players tell us that we have to make decisions earlyon, given their engineering/development cycle (isn't it 2-3 years?), and critical importance on stability on a fast moving environment. Y'know trying to hit a target traveling at close to light speed is not always easy. Selecting between multiple targets traveling at such a speed and making the right choices isn't that trivial either. Actually, none of the IETF, IESG or IAB is really used to solution selection, particularly the necessary process to do so. There is simply no process in place for those necessary activities, that will likely drastically increase in frequency as the network continues to evolve. When I was PI on the NSFNET backbone project, I was really in a bind. It was then early 1988 and we were obligated to deliver a brand new T1 NSFNET backbone by July. I have heard many comments at that time that it was impossible to deliver in time, but in reality we did, including routing wise. The old 56kbps NSFNET backbone with its attached regional networks had a very different routing paradigm from what we selected for the new one. And the old one clearly did not work. We had some thought of using EGP then, which was clearly not used in the 56kbps NSFNET backbone. I received open hostility for the protocol selection from people, including at least one complaint to the NSF, at a time where the whole IETF community was quite hostile (look into the archives), as the network was falling apart and not much has happened in time to prevent it. I could have then chosen to ask the IETF for help, but there would have been no way to get it resolved in time, while having a contractional deliverable of about half a year into the future, and NSF having high expectations for the money they were paying. In fact, NSF contacted me then on the 30th of July asking about that day being the contractually promised date. I responded that the day ain't over yet and then was able to later in the day post a note that we are starting with real traffic on the new NSFNET backbone. Anyway, again, the IETF would not have been able to come up with a solution in time, given polarized views and quite some hostility then. So, a few people (Yakov Rekhter (IBM), Scott Brim (Cornell/gated), Mark Fedor (PSI), Jeff Honig (Cornell/gated) and I (then Merit/NSFNET) met in Yorktown some cold winter day in early 1988 to nail down the routing architecture for the new NSFNET backbone. We essentially managed to do it during the day and some (I think small) email followup, followed by immediate implementation. These concepts were critical for the management and operation of the network, and included things like the use of EGP, a policy- controlled data base for routing configuration, and full (without DEFAULT) routing knowledge in the NSFNET backbone (which was quite controversial and revolutionary then, given that the "Core" (ARPANET/MILNET) was still running on all thrusters. But we had to take some risk, in order for the network to survive, given all the people depending on the network in 1988. Depending in 1988? How does that compare to to today? The routing and addressing problem is arising because of the extreme success of an environment that evolves at a very high speed. Very many people and billions of dollars depend on it. Industry and service providers are investing alot into predictable services. Many people could get into serious difficulties if services get disrupted just for a day. Or an hour? Aren't we even upset if just one connection of ours breaks? How many people really realize how fragile the environment really is, how it works and scales on a world-wide level without global management, and what the pressing problems will be 6, 12, 24, ... months from now? Hey, we all remember when we thought that 128 networks in the Internet, including internationally, was a very high number. Where are we now? 5000+ networks in the NSFNET backbone, 2000 or so more in Europe that are not even known to the NSFNET backbone because of AUP restrictions, and probably lots more in, e.g., Asia. We cannot take things lightly, both in the need not to disrupt current services, and not to neglect upcoming needs in an operational, infrastructural environment. The IAB and its IESG/IETF/etc. do not really have the operation and management of the global infrastructure on their plate. How much discussion has there been about, e.g., EBONE, NSFNET recompetition, WIDE and such. In fact, when I joined the IAB, and it still somewhat continues, I was appalled at how they neglected operational infrastructure, stressing instead protocol standardization as their means of fostering the architecture. There is finally some activity in the IETF now relative to operations, but it is pretty new and I am not sure about its impact yet. So, who is really worrying about the survival of the global infrastructure, including outside of the scope of their own network and its next door neighbors? The IAB? (So far no strong infrastructural focus) The CCIRN/IEPG? (Somewhat, but too small set of constituents, and not easy to make rapid progress)? The ISoc? (Not sure yet; I am not convinced about an infrastructural leadership from there) RARE/RIPE? (hey, they seem to be going good work, are on the right wavelength and so; but I am not sure whether their scope includes globality)? The IETF/IESG? (I outlined shortcomings before, like difficulties in mediating between multiple choices and such, and differentiating between pressing infrastructural needs and striving for more "optimal" solutions that turn out to be rather researchy)? I simply do not know. The whole process is not easy. We have a few problems. We don't have much time. We cannot really start researching a new protocol, as the research/development/ implementation/testing/deployment cycle is far too long. I believe that anything really innovative has to be split off into research and deferred until it can really deliver. We need consensus at a global level, which would not be easy to build up, given many "official" people's commitments to full OSI (US agencies, international constituents, ...). We are faced with religions (like OSI being compared to AIDS), wrong perceptions (buying into ISO fully and loosing control), political overtones (the IAB is evil and has to be destroyed). By the way, I suspect that undermining the IAB's role with the goal of crushing it would be less a problem for IAB members, than for the IETF in terms of dumping the whole environment into anarchy. I have even heard people suggest to cut financial support from the agencies to the IAB (I, as an IAB member, do not receive any funding out of the IAB support; even my travel to IAB meetings has to be paid for by other means). My understanding is that same funding largely covers the IETF secretariat to coordinate IETF meetings, mailing lists etc., in support of IETF activities. So, I suspect that would hurt the constituents that the same people would like to see survive. We also have a difficulty in that the proposed engineering choices (like CIDR, C#, encapsulation) come at a possibly high cost (integration, management, global engineering, router changes, possibly host changes) and not without technical problems (e.g., possibly isolated islands and/or inflexible routing could be created). I posted some detailed list of concerns to the ROAD group before, outlining issues surfacing as those engineering choices get applied to the Internet at a systems level. I sure would feel more comfortable with the short term choices if we had a longer term alternative (well, any alternative for that matter) to use for the sites that could run into problems. The IESG publicly announced a recommendation a few weeks ago, essentially suggesting to evolve CIDR immediately to address short term concerns, to defer everything else until (at least) November, and to invite people to suggest further alternatives. I believe that this IESG choice was reasonable given their mission, but does not reflect on the real needs that are even arising today. How many new suggestions are we receiving? One per week? One every other week. If we have 30 or more suggestions by November, without any process in place to select among them, we will have a serious problem on our hands, with people insisting to leverage their investment into a specific solution by a broad application of it to the infrastructure. They will very loudly defending their work. Just look at how neglected Bernstein felt (I am not defending him, just suggesting that many people may be upset like him, come November). As such, the IAB felt that the process in place within the IETF/IESG may not be sufficient to strive towards a decision early, at a time when we really do not have time to spare. The IAB did not want to lose sight of advanced protocol work, and is strongly encouraging continued research, leaving room for protocols more advanced than IP or CLNP by the time they mature. Even today a multiprotocol environment is commonplace, allowing for the introduction of even better solution as their time comes. The IAB also realized that short term measures are essential, and is encouraging current activities to continue. However, as the major next step, applying some realism (both technical and political), implementability, current experience (quite a bit in Europe in the RARE WG4, for example), scalability and expected life time, modeling things after CLNP appears to be a reasonable choice. I was actually amazed and positively surprised that the IAB as a group was willing to take the risk of publishing the statement about which several people are now vociferously complaining. This is new for the IAB and, by the way, has nothing at all to do with the ISoc, but with the lack of progress and the otherwise uncertainty of an acceptable position/decision any time soon. I personally would have preferred to issue a much stronger statement, much closer to a decision and certainly as a RFC, not an ID. Others on the IAB felt that being too pushy here would be unwise, and would rather float it as a proposal for a while, fully anticipating the risk they would take, and much rather use an Internet Draft medium, in case major show stoppers emerged. The IAB took a risk on this one, inspired fundamentally by their deep care for the Internet and the belief that some pragmatic public statement is essential, if only to hold up and model alternatives against. I am pretty sure that if there were a better alternative that could gain Internet wide (global) consensus, certainly technically, but also to some extent politically, which could be implementable in time and engineered with relatively few nightmares, scaled to a great many networks, allowed for addressing schemes that allow for collapsing of routing information, and so on..., that the IAB would be more then willing to evaluate such an alternative, and, if it proves to be better and also realistic (rather than a research effort that may be a solution lateron), to adopt it. Look, the ID has been floated as a draft and a position paper. A stick in the ground. Comments about coming in heavy handed and ignoring the IETF are just nonsense. As are notions of a wholesale move towards OSI and GOSIP. As is the notion of losing change control. In fact, the document says "based upon CLNP." It would sure be nice if IPv7 and CLNP could be aligned. It sure would be my preferred choice. However, if CLNP proves insufficient for a significant reason, then we may have to revert modifying it, meaning a creation of a private protocol. But, at least then we can say that OSI protocols were insufficient for some sound reason, and at least forward our changes, those we make based on Internet community consensus and not on ANSI/ISO consensus, to other standardization organizations. Look, the whole things isn't that much of a big deal. US agencies and some service providers, especially international but also domestic ones, already invest in CLNP (for OSI purposes). CLNP headers are just like scrambled IP headers, not a big difference. Addresses can optionally be long, but don't have to. We were certainly not suggesting to use the currently assigned NSAP schemes. And, the CLNP discussion is nothing new. It is going on for years in many camps, and also surface in ROAD activities and was also prominently displayed as a possible choice at ROAD presentations, like the one at the last IETF meeting. No need to panic. Though, sound constructive feedback, including critizism, is always welcome. Hans-Werner From owner-Big-Internet@munnari.oz.au Sat Jul 4 10:39:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02450; Sat, 4 Jul 1992 10:39:45 +1000 (from owner-Big-Internet) Return-Path: Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02445; Sat, 4 Jul 1992 10:39:40 +1000 (from hwb@upeksa.sdsc.edu) Received: Fri, 3 Jul 1992 17:39:30 -0700 by upeksa.sdsc.edu (AIX/1.6) From: Hans-Werner Braun Message-Id: <9207040039.AA18849@upeksa.sdsc.edu> Subject: Re: why 160-bit addresses are daft.... To: dino@cisco.com (Dino Farinacci) Date: Fri, 3 Jul 92 17:39:29 PDT Cc: ietf@isi.edu, big-internet@munnari.oz.au In-Reply-To: <9207032248.AA12287@regal.cisco.com>; from "Dino Farinacci" at Jul 3, 92 3:48 pm Dino: > No one said that IPv7 had to use GOSIP addresses. And from what I'm > hearing, we don't want to. The IETF decides on the address length it > wants to go with (note 5 bytes above - a address length byte included). I would make your comment even stronger. The Internet community, including the IAB, will have to critically depend on the IETF to define the appropriate addressing structure (including length). That requires serious work, and the experience of the people having been involved in both IP and CLNP networking will be imperative here. Hans-Werner From owner-Big-Internet@munnari.oz.au Sat Jul 4 12:20:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03998; Sat, 4 Jul 1992 12:20:39 +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 AA03995; Sat, 4 Jul 1992 12:20:34 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28756; Fri, 3 Jul 92 22:20:29 -0400 Date: Fri, 3 Jul 92 22:20:29 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207040220.AA28756@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, mak@merit.edu, road@lanl.gov Subject: Re: IPv7 Cc: jnc@ginger.lcs.mit.edu and should clearly steer away from proposals whose success is predicated on some future research I guess we will have to make do with existing resource allocation and congestion control mechanisms, since this is still an area of substantial research at the moment. While other than CLNP proposals may on the surface sound tempting, ... at the present moment these proposals are nothing more than just proposals; with no implementations, no experience Oh, so I assume you are hereby excluding TUBA, which as far as I know, has not been implemented and tested yet? Exactly how many implementations are there, and how widespread is the test deployment, of TCP over CLNP? able to go beyond parochial arguments (TCP/IP vs CLNP) I seem to be hearing you say that the arguments of some of those who think this is a bad idea are based on parochialism? I guess it doesn't surprise me to hear you say this; the real technical arguments that some people have as to why CLNP is not the answer (no security architecture, no auto-configuration architecture, no resource allocation architecture, etc, etc, etc) seem to have passed you by. You know, Yakov, not all of the people who aren't in favor of CLNP oppose it just because we love TCP/IP. Just conceivably there are real technical issues we care about; some of us even want to get rid of *IP* because of those issues.. Noel From owner-Big-Internet@munnari.oz.au Sat Jul 4 13:40:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05296; Sat, 4 Jul 1992 13:40:25 +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 AA05280; Sat, 4 Jul 1992 13:40:15 +1000 (from lixia@parc.xerox.com) Received: from redwing.parc.xerox.com ([13.2.116.19]) by alpha.xerox.com with SMTP id <11570>; Fri, 3 Jul 1992 20:40:04 PDT Received: by redwing.parc.xerox.com id <57234>; Fri, 3 Jul 1992 20:39:54 -0700 Date: Fri, 3 Jul 1992 20:39:42 PDT Sender: Lixia Zhang From: Lixia Zhang Reply-To: lixia@parc.xerox.com To: Hans-Werner Braun Cc: big-internet@munnari.oz.au, ietf@isi.edu Subject: Re: Milo going Nova. In-Reply-To: Your message of Fri, 3 Jul 1992 16:36:05 -0700 Message-Id: > Sorry for the size of this note. Unless you have a serious > interest in this area, you may want to skip it... Hi Hans-Werner, Your msg is indeed a bit too long to read, especially in a holiday eve :-) Yes you got the name right, GADS. It was created late'84, the first meeting was held Jan'85 in D.C. Doesn't seem to be that long ago, except when one looks at how much IP world has changed. I agree with you on that, up to today, we have not had a viable solution(not proposals, but field-tested implementation) to the problem. (someone privately commented that this might also reflect a failure of the funders) But this is not equivalent to say that we have no solution. Just as you have had successful experience of putting NSFbackbone up on time, some special effort out of this community in the next few months may well present a solution in time. Lixia From owner-Big-Internet@munnari.oz.au Sat Jul 4 15:05:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06814; Sat, 4 Jul 1992 15:05:59 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06811; Sat, 4 Jul 1992 15:05:54 +1000 (from billw@cisco.com) Received: by cider.cisco.com; Fri, 3 Jul 92 22:05:46 -0700 Date: Fri, 3 Jul 92 22:05:46 PDT From: William "Chops" Westfield To: Jon Crowcroft Cc: big-internet@munnari.oz.au, ietf@ISI.EDU, road@lanl.gov Subject: Re: IAB proposal for CIDR and IPv7 In-Reply-To: Your message of Thu, 02 Jul 92 17:22:58 +0100 Message-Id: it also is introducing a policy which is NOT in line with starting new Internet Standard Initiatives on a level playing field, since only some vendors (very few end system vendors, slightly more router vendors) provide CLNP bundled... Is it now stated policy of the IETF/etc that new Standard initiatives should place vendors on a level playing field? This sort of attitude was instrumental in making the OSI specs the impossible conglomeration that they are now! All is lost. BillW From owner-Big-Internet@munnari.oz.au Sat Jul 4 15:06:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06825; Sat, 4 Jul 1992 15:06:40 +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 AA06819; Sat, 4 Jul 1992 15:06:26 +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 AA22275; Fri, 3 Jul 92 11:47:04 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA28470; Fri, 3 Jul 92 11:47:07 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA08471; Fri, 3 Jul 92 11:46:45 PDT Date: Fri, 3 Jul 92 11:46:45 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9207031846.AA08471@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA10067; Fri, 3 Jul 92 11:47:00 PDT To: ietf@isi.edu Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, Bob.Hinden@Eng.Sun.COM Subject: Comments on IPv7 Document Folks, Here are my comments on the IAB recommendation for adopting CLNP as IPv7. I strongly disagree with the overall recommendation presented. IMHO I think what is proposed does not solve one of the key medium term problems which face the Internet. In particular, it does nothing to solve the routing explosion problems until after CLNP is very widely deployed in hosts. I am very concerned that this will occur a long time after the routing table explosion has killed the internet. CIDR alone does not buy us enough time. Bob >>Abstract >> >> Internet growth has created serious problems of address space >> consumption and routing information explosion. A solution to these >> problems requires a new version of the Internet Protocol, which we >> call IP version 7 ("IPv7"). This memo presents architectural >> guidelines that any IPv7 should meet. It then discusses how an IPv7 I see no justification is this document for why a new version of IP is "required" to solve the address space consumption and routing table explosion problems. A new version of IP is one approach, but I don't see why it is required. IPAE and similar approaches present clear alternatives to deploying a new version of IP with much less impact on the existing operational system. Further, no solution to the routing table explosion problem is presented here at all as far as I can tell. >> based upon the OSI CLNP protocol would meet these requirements, and >> presents the reasons for the IAB's preference for this solution. >> Finally, it makes a three-part recommendation: (1) proceed at full >> speed on CIDR; (2) do the design work on IPv7 based on CLNP; and (3) >> continue to pursue research in advanced routing and other future >> extensions of the Internet architecture. >> 1.1 The Need for IPv7 >> >> The rapid growth of the Internet has exposed the consequences of a >> design choice made 15 years ago, the choice of a fixed-length 32- >> bit address field for IP [IEN-005]. At that time, 32 bits appeared >> to be a very wide field, allowing many thousands of networks and >> millions of hosts, several orders of magnitude beyond the likely >> size of the Internet. However, the Internet has now grown to this >> order of magnitude, leading to two different scaling problems: >> >> * Routing Information Explosion >> >> The cost and complexity of Internet routing grow very rapidly >> with the number of networks. This growth is creating >> increasingly serious operational problems. >> >> * Address Space Consumption >> >> Current IP addresses are 32 bits. While this seems to be a >> very large number (4*10**9), its division into host and >> network parts and into class A, B, and C networks >> significantly reduces the available space. Projections are >> difficult and highly arguable, but at the current rate of >> growth, the existing space may be used up in the foreseeable >> future. I think it is important to also say that the first problem is going to hit much sooner than the second problem. If we only concentrate on the second problem, the first will kill us! I think a major weakness of this proposal is that it only addresses the address space consumption problem. No solution is presented to the Routing explosion problem. From my understanding of the TCP/UDP over CLNP proposal (Simple CLNP and TUBA), there will not be any significant relief to this problem until there is very widespread deployment of CLNP in hosts. CIDR does not buy us enough time. Given the number of significant issues discussed in section 3 regarding a CLNP deployment that need to be resolved before CLNP can be widely deployed, I don't see any way that can be done in time. I believe that the proposed approach will lead to a fragmented internet. >> 1.3 Overall Plan >> >> In ROAD discussions, it was useful to divide the solution of the IP >> scaling problems into short-term, medium-term, and long-term phases >> [ROAD]. The real situation is much more complicated, with >> considerable overlap as well as uncertainty about time frames, yet >> this is a useful model for planning. We support the ROAD group >> model that IPv7 belongs to the mid-term time frame, in the sense >> that: >> >> (1) more immediate steps must be taken to avoid exhaustion of the >> address space before IPv7 can be deployed; and >> >> (2) there are substantial research questions which must be >> pursued, but which cannot be expected to be resolved until >> after IPv7 is deployed. >> >> For the short-term effort, we support the ROAD group suggestion of >> CIDR (Classless Inter-domain Routing) [CIDR], a form of "super- >> netting". CIDR will provide short-term relief from exhaustion of >> the address space by breaking the rigidly fixed boundaries that >> define class A, B, and C IP addresses, using a more flexible bit- >> level mask (or equivalently a variable-length address prefix) to >> distinguish the network number. To attack the routing information >> explosion, CIDR will select addresses to match topology, allowing >> the aggregation of routes. As we point out later, this aggregation >> will carry over to, and indeed is important to the success of, >> IPv7. >> >> We do not dwell on CIDR here; there are already several CIDR- >> related engineering efforts in progress in the IETF. This memo >> emphasizes IPv7. Section 2 introduces a set of requirements that >> must be satisfied by any IPv7 architecture, while Section 3 >> discusses two alternative approaches for realizing IPv7. One It is important to also say that CIDR only slows down the routing table growth and buy us some time. How much is uncertain. Without some very radical steps like reassigning all IP addresses (which I know that any customer I have ever talked to would hate due to the cost and disruption of implementing it), what we buy in time will be short lived. Also, as I think we all know, there are still significant technical problems with CIDR that need to be also worked out. >>2. ARCHITECTURAL PRINCIPLES >> ..... >> Before discussing these principles, we make a basic philosophical >> point: whatever the choice for IPv7, its "change control" must rest >> with the IAB/IETF. Despite our desire to eventually converge with >> other standards groups, the ability for protocol and architectural >> evolution within the IRTF and IETF is absolutely essential to the >> continued success of the Internet. It also critical if we embark on this course, that we also retain change control on ALL of the other pieces that go with it. For example, in addition to CLNP, I would think that we would need to "own" the routing protocols (ISIS and IDRP), address resolution (ES-IS), number spaces, network management, and others. All of these would need to have new specifications written and made available as RFC's. This will be a very significant effort. Also the style that the CLNP, ISIS, etc., documents are written in is very different from the style of the TCP/IP documents. It will not suffice to just republish them if that was possible. There may also be significant copyright issues with making these documents available online. The current mode of obtaining these specifications for CLNP and related protocols (e.g. purchasing a hard copy) is unacceptable to the internet community. >> 2.1. Architectural Simplicity >> >> We believe that the success of the Internet architecture (as >> evidenced by the growth problem discussed in this memo) rests on >> its simplicity, which should be retained to the extent possible. While this is certainly a good goal, from my experience what is proposed here does not seem to be simple. It requires all elements of the internet layer to change. It may be simple from an architectural perspective, but from the products world, it is a very massive expensive change. >> As an example of simplicity, we would prefer an architecture that >> does not introduce any new logical boundaries into the Internet. >> Such boundaries could make the job of address registration and >> route aggregation harder. I am not sure what is meant by a "logical boundary", but a case can also be made that boundaries can simplify administration. This is in no way clearcut. >> 2.3. Larger Address Space >> >> Since we require globally unique addresses and since the current >> address space is too small, we must escape the limitations imposed >> by the current 32-bit addresses. The new architecture must allow >> much wider address fields, to accommodate: >> >> (1) registering several millions, or even billions, of networks; >> >> (2) allowing some degree of inefficiency in the address >> registration; >> >> (3) permitting the expression of a hierarchy in the address; >> >> (4) allowing for new addressing architectures in the future, if >> the need arises. >> >> Here (2) and (3) are needed in order to allow decentralized >> registration and route aggregation (see Sections 2.4 and 2.5). >> >> This move to a new address format is likely to impact much host and >> router software; every piece of software that handles an Internet >> address will have to be modified to handle wider addresses. It is >> important to note the nature of this impact: broad (many modules >> affected) but shallow (very specific, localized changes). This is saying that we only have to change everything a little bit. This is a very big impact on products and the operational internet. >> We furthermore argue in favor of a variable-length address format, >> with a known upper bound. This upper bound will need to be large, >> potentially increasing the IP header size significantly. However, >> with a reasonable address assignment scheme, most networks numbers >> will be much smaller. Indeed, it might be desirable to use the >> existing 4-byte IP addresses for many hosts during a transition. Another point that needs to be addressed is the amount of storeage NSAP addresses will take in routers. Ignoring the issue of performance inefficiencies in processing variable length addresses, I fail to understand how routers in this architecture will be able to store large quantities of 20-byte addresses when today they have problems with fewer 4-byte addresses. Memory is certainly getting cheaper, but not by a factor this large. We need larger addresses for sure, but 5 time bigger? >> 2.7. Extensibility >> >> Evolution from IPv4 to IPv7 will be occurring at the same time that >> research work is on the verge of requiring architectural extensions >> in other areas. Two important examples are supporting real time >> applications (e.g., packet voice and video) [Realtime], and >> providing better security services. IPv7 should provide easy >> extensibility in order to support such new areas. >> >> In particular, it is vital to escape the 60 byte limit on the IPv4 >> header, in order to have more space available for options. Why is it "vital" to escape the 60-byte limit on IP options? There is a significant body of experience that says the options are a bad idea in the first place. This is the first time I have seen this argument that we should have room for more options. >> 2.8. Compatibility >> >> As mentioned above, larger addresses should by no means imply a >> change in the overall Internet architecture. In particular, it >> should certainly not imply a reduction in the network >> functionality. For example, it is mandatory that IPv7 should >> continue to support the IP multicast architecture. Also, the >> current techniques for debugging (e.g., "ping" and "traceroute") >> should still be possible. Yes, but how long will it take to recreate this functionality in CLNP? These are not architectural issues, but are important elements of the current operational internet. We need more than an architecture to build a working internet. >> There are many "tendrils" from IPv4 that reach up into the >> transport and application layers [RFC-1122]. Examples are the >> receipt of ICMP Unreachable, Redirect, and Source Quench messages, >> and setting TOS and TTL values and/or source routes. Other >> examples arise in the use of Internet addresses by applications, >> e.g., IP. We would ideally like to minimize the impact on the >> layers above IP, although this may not prove entirely feasible. >> 2.9. Interoperability >> >> Transition from IPv4 to IPv7 must occupy a number of years, so it >> will be necessary for IPv4 hosts to be able to interoperate with >> IPv7 hosts. A general scheme for handling old/new host >> interoperability, based upon the DNS, is given in [TUBA]. >> >> In order to ease the transition and ensure connectivity within the >> Internet, the addressing plan should allow the address space to be >> *embedded* into the IPv7 space. For example, this will avoid the >> need to maintain parallel routing tables. >> >> The following diagram shows the protocol stack that a host may >> expect to implement. During the transition to IPv7 (which is >> likely to be lengthy), an Internet host must support both IPv4 and >> IPv7. It would use IPv4 for communication with an unmodified host >> [TUBA]. Yes, but what happens after we can no longer route on IP address because the routing has broken down. We will have plenty of IP addresses to assign, but because it will not be possible to route on more than ~100,000 networks, IP will only work in local areas. The sites (hosts, router, DNS, net management, etc) which have not yet added support for CLNP will loose the ability to communicate outside of their area. This will fragment the internet and reduce the motivation of people to want to connect to it. >>3. POSSIBLE APPROACHES TO IPv7 >> >> Two divergent approaches have been suggested for IPv7. >> >> (1) Some form of IP encapsulation. A good example of this approach >> is the IP Address Encapsulation proposal [IPAE]. >> >> Encapsulation schemes maximize Internet-layer protocol >> compatibility by design; however, these schemes also represent a >> significant change in the IP architecture. I disagree with this notion that IPAE is a significant change in the IP architecture. It is based on the basic mechanisms in the IP architecture. Replacing IP with CLNP and the other associated things that go with it, is also a significant architectural change. Why is one good and the other bad? Before IPAE and similar approaches are discarded, it should be allowed a full and open discussion of its advantages and disadvantages. Doing otherwise, IMHO would be a great disservice to the internet community. >> (2) Keep the IP architecture essentially unchanged, but change the >> format of an IP header to expand the addresses. There is much more to do than changing the format of the IP header. Real operational and product issues must be addressed. It is too simple to just say that we need a new header. What is proposed is much much more than just changing the format of the IP header. >> .... >> The IAB proposal is to adopt the CLNP protocol specification and >> packet formats for IPv7. The eventual consequence of this decision >> will be the publication, at some point in the future, of a complete >> IPv7 specification that is functionally and syntactically compatible >> with CLNP (defined by the second edition of the ISO 8473 standard, >> published in 1992). The intent is to run the existing and future >> Internet transport protocols -- in particular, TCP and UDP -- above >> IPv7. This would let us benefit from the larger addresses of CLNP >> while maintaining the present Internet architecture, without inventing >> a new protocol specification and without losing change control. We >> must of course avoid gratuitous changes, but the IAB/IETF must be able >> to make any changes that are necessary for successful deployment, >> operation, and evolution of IPv7. In the longer term, the use of CLNP >> will contribute to the inevitable convergence of the OSI and TCP/IP >> protocol suites in the Internet (IAB/IETF) context. Why is this inevitable and why just two protocols? There are other internet protocol families which have larger installed bases. >> The next section reviews the advantages of this CLNP-based solution. >> Section 3.2.discusses the issues that must be resolved before a CLNP- >> based IPv7 can be deployed in the Internet. >> >> 3.1. The case for (and against) CLNP >> >> An advantage of CLNP is simply that the protocol is already >> specified, and several implementations exist. Adopting (and >> adapting; see the next section) the CLNP format will avoid design >> of a new protocol from scratch, a process that would consume >> valuable time and delay testing and deployment. >> >> Besides the change to variable-length 20 bytes addresses, CLNP has >> another important technical advantage: it frees us from the 60-byte >> limitation on an IP header. CLNP has a limit of 254, and there is >> an escape code (length 255) that could allow an extended header; >> this will allow more extensive use of IP options for future >> extensions. As noted, above I don't think a case has been made why larger space for options is a feature. I don't think this is an advantage. The more the options space is used the harder, the harder it will be to get high forwarding performance in routers. >> We should admit frankly some technical limitations of CLNP, which >> it shares with IPv4: >> >> * Maximum packet length is limited to 64K bytes. >> >> * The message identifier uses a 16-bit field. >> >> * The Time-to-live field is one byte. >> >> * If full-size (20 byte) addresses are used in options, the 255 >> byte limit gets used up fast. For example, the largest source >> route with 20-byte addresses will be 8 hops. This is not very different from the number of hops which can be carried in IP. Am I missing something? It seems to be at odds with the discussion in the previous paragraphs about CLNP's ability to carry more options than IP. Seems like CLNP holds more bytes, but about the same amount of information. >> In addition, CLNP has awkward boundary alignments for RISC- >> architecture machines. We do not regard any of these as show- >> stoppers. The RISC performance issue is not a showstopper, but is an important performance concern. I can't see any way around this except for a very major change to CLNP. Another concern I have with CLNP is the checksum algorithm used. It is much more expensive to compute in software than the IP checksum. I have even heard that some comments that it is harder to do in hardware. Specifically, I site the decision by Protocol Engines to not include the CLNP checksum in the network chip they have built. Greg Chessins should be able to provide more information. Regarding checksums, I also have a specific concern for hosts because CLNP uses one type of checksum and TCP uses a different checksum. There has been much work done on host performance optimizations which combine the IP and TCP checksum calculations into one optimized loop that also moves the data from kernel space to user space. I have real concern that this type of optimizations will be lost or be made much harder with the proposed architecture. >> 3.2 Additional Issues with CLNP. >> >> To adopt the CNLP format for IPv7, a number of issues must be >> resolved. Callon has provided one analysis of the changes needed >> and the interoperability issues for using CLNP as the basis for >> IPv7 [TUBA]. >> >> * Address Format and Registration Plan >> >> The existing NSAP registration plans [OSI-NSAP], which were >> designed for OSI usage, will have to be reviewed in light of >> the Internet needs. One requirement is to embed the existing >> Internet addresses. Seems likely that we will define our own NSAP address. Few are happy with the provider based NSAP schemes currently proposed. >> * Protocol Identification >> >> A substitute for the IPv4 "protocol identification" field will >> have to be defined. A plausible solution would be to use the >> "last address byte" (the "NSEL" or "NSAP selector" field, >> which is defined to be the last byte of the NSAP address by >> ANSI standard X3.210-1992). Why not just add this to the CLNP header. What is the affect of carrying the protocol field as part of the address have on existing implementations? >> .... >> * Header Size >> >> The possible problems posed by increasing the size of the IP >> header will have to be evaluated. The impact on slow Internet >> links may be alleviated by adapting header compression >> algorithms analogous to Jacobson's [RFC-1144]. How big will the header be? How much of an impact will there be on the existing internet infrastructure? Will lines need to be upgraded? Is this a reasonable solution for mobile hosts using low bandwidth links? This is a very serious issue. >> * Multicasting >> >> The proposed extensions to CLNP for multicasting will have to >> be incorporated. Yes this will have to be done. How long will this take? What is the status of multicasting on CLNP? Every time I talk to Steve Deering he is very pessimistic about the progress of multicasting in CLNP. Multicasting is a service that IP has now. Sun and other vendors have products shipping today which support and use it. It is an important part of Sun's networking strategy. If a new version of IP is adopted, it must have multicasting from the start. >>.... >> It is of course a long-term objective to work towards a single >> unified internet protocol layer for the entire Internet. Why is this a long term objective? I was not aware of a consensus that thought this was true. I thought the objective of this proposed change was to solve the Internet's routing and addressing problems. >> In the OSI framework, IS-IS and IDRP are the currently-defined IGP >> and EGP routing protocols, respectively. A careful study may be >> needed to evaluate whether to adopt ISO routing protocols or to >> evolve IP routing protocols to support IPV7. The routing protocols >> currently in use in the Internet represent a huge investment that >> should be thrown away only for compelling reasons. Furthermore, we >> must facilitate further research in routing protocols. >> This will be a very difficult task and be a very major change regardless of what protocols are selected. >> In order to survive the transition to IPv7, the existing routing >> protocols will have to be upgraded to handle long variable-length >> addresses and masks/prefixes. The careful study of routing >> protocols is an important element in the success of the migration. Changing routing protocol continues to be hard. This proposal is saying that all of the routing protocol in the internet will have to change or have significant modifications. This is a very large impact. The alternative proposals (IPAE and EIP) build on top of the current routing protocols and don't require all of the existing protocols to change. Other work which will have to be done is to define current mappings for running CLNP over all of the current types of networks, that we currently have for IP. This is a significant project and will open up old issues about how best to do it over each type of network. >>5. THE WAY FORWARD >> >> In order to guarantee the survival of the Internet, work should start >> now on the various items detailed in this document. Delaying by a few >> more months in order to gather more information would be very unlikely >> to help us make a decision, and would encourage people to spend their >> time crafting arguments for why CLNP is or is not a better solution >> than some alternative, rather than working on the detailed >> specification of how CLNP can be used as the basis for IPv7 and >> resolving the technical questions (particularly in the area of address >> administration and the effect on existing application software) that >> must be answered in order to specify a deployment plan for IPv7. On the other hand if we proceed this way, we are likely to start a war. There is no consensus on this approach. I think it would be much preferable to take some time to work out the many issues stated in this document regarding the conversion to CLNP and to examine other approaches. There will be much less fighting if the community feels that there has been a fair hearing of the issues and approaches. From owner-Big-Internet@munnari.oz.au Sat Jul 4 15:14:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07003; Sat, 4 Jul 1992 15:14:08 +1000 (from owner-Big-Internet) Return-Path: Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06999; Sat, 4 Jul 1992 15:14:03 +1000 (from hwb@upeksa.sdsc.edu) Received: Fri, 3 Jul 1992 22:13:58 -0700 by upeksa.sdsc.edu (AIX/1.6) From: Hans-Werner Braun Message-Id: <9207040513.AA19381@upeksa.sdsc.edu> Subject: Re: Milo going Nova. To: lixia@parc.xerox.com Date: Fri, 3 Jul 92 22:13:58 PDT Cc: big-internet@munnari.oz.au, ietf@isi.edu In-Reply-To: ; from "Lixia Zhang" at Jul 3, 92 8:39 pm Lixia: >some special effort out of this >community in the next few months may well present a solution in time. That would certainly be ok with me, but would require more than some protocol specification. Scalability is not only a technical term these days. It is quite worrysome to see how many dependencies there are on the network, and what it would take to make solutions viable, acceptable, implementable and manageable, including in a global and also quite politicized arena. It seems to me at times that a technical specification is not the biggest problem to solve any more, unlike in the DARPA days, where advanced ideas were much more welcome and applicable for the network at hand. Today in many cases it seems to take a year or so to to just find funding for new effort, to even just *start* the development of a specification. The environment is much more complicated today than in the 1984 DARPA days you point to, there are many sharks out there, and lots of people critically depend on services that must not be interrupted. The time has come that we have to realize that the importance of the network is reaching towards the importance of telephony networks, with national securities and billions of dollars at stake. Not to lessen their importance, but research and development has to be decoupled from the operational infrastructure in order to retain a large scale manageable situation. It is not easy to make judgments. There is no completely right solution, as there will be compromises somewhere, in whatever solutions people will propose; even if someone would come up with a protocol for generations to come. Hans-Werner From owner-Big-Internet@munnari.oz.au Sat Jul 4 20:40:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15304; Sat, 4 Jul 1992 20:40:19 +1000 (from owner-Big-Internet) Return-Path: Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15295; Sat, 4 Jul 1992 20:40:12 +1000 (from hwb@upeksa.sdsc.edu) Received: Sat, 4 Jul 1992 03:40:06 -0700 by upeksa.sdsc.edu (AIX/1.6) From: Hans-Werner Braun Message-Id: <9207041040.AA06427@upeksa.sdsc.edu> Subject: Re: Milo going Nova. To: lixia@parc.xerox.com Date: Sat, 4 Jul 92 3:40:05 PDT Cc: big-internet@munnari.oz.au, ietf@isi.edu In-Reply-To: ; from "Lixia Zhang" at Jul 3, 92 8:39 pm Lixia: I was thinking a bit more about your comment: >I agree with you on that, up to today, we have not had a viable >solution(not proposals, but field-tested implementation) to the >problem. (someone privately commented that this might also reflect >a failure of the funders) The "private comment" is really not new, as you know, and I heard it several times before. No need to be secretive about it. I also heard comments like that agencies reduced some funding, particularly on routing, when the NSFNET at times "just did it" without further funding. I think we have some major problem in perception here. You can probably put some blame on the funders, but the problem is really a bit more complex. Over the last several years the IETF has been a convenient vehicle to develop ideas and meet colleagues to help work such ideas out. As such, not only engineering work has been dumped onto the IETF but also research type of work, and certainly much that is in the gray area between research and engineering. As such, it is not surprising if possible funders really wonder about funding engineering type things, if NSFNET (and other service providers) have no choice but working on the engineering issues at hand anyway, with or without extra funding. This was certainly the situation we were in when the BGP effort started. We saw an imperative requirement to make certain changes to inter-AS routing (at least last-AS (eventually AS path) and incremental updates), and could not wait for things like ORWG or EGP-3 to pan out. At the same time at least the NSFNET had no intentions to prevent more longer term research to happen, and putting that longer term stuff into the engineering category, and then resulting in possible failure to find funding, is certainly a fault of the people who were doing their work in the IETF as well, as it creates a strange perception. I believe (and do believe so for a long time already) that people and efforts would be much better of, including to attract funding, if it would always be clear as to where the time horizon of a specific effort is, and whether it should be really treated as engineering, or rather covered outside of the engineering realm. May be some {non-}fundees would have fewer problems communicating the need for funding, including as it would be outside the scope of short term engineering, to their funding agencies. Then again, that has to be offset by the immediate exposure people have for their ideas within the IETF, and their hope for immediate (or semi-immediate) application to operational infrastructure. It is hard to see how one can really have it both ways. The way things were handled, I cannot blame funding agencies to a large degree, though you certainly have a point there. The IAB also recognized this, which is a reason why the IPv7 document includes a strong statement in support of more forward looking research. While we should tell funders that the network research and development is far from over yet, possible fundees really should be more careful as to how/where they position themselves. I suspect that the IAB would be quite willing to help here, if stronger statements would be required as to the need to consider longer term efforts for network research, including statements as to the need to fund them. Hans-Werner From owner-Big-Internet@munnari.oz.au Sat Jul 4 21:11:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15659; Sat, 4 Jul 1992 21:11:11 +1000 (from owner-Big-Internet) Return-Path: Received: from haig.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15656; Sat, 4 Jul 1992 21:11:07 +1000 (from S.Kille@isode.com) Received: from glengoyne.isode.com by haig.cs.ucl.ac.uk with Internet SMTP id ; Sat, 4 Jul 1992 12:10:38 +0100 Received: from localhost by glengoyne.isode.com with SMTP (PP) id <01283-0@glengoyne.isode.com>; Sat, 4 Jul 1992 11:57:23 +0100 To: braden@ISI.EDU Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov Subject: Re: IPv7 (CLNP) a mistake Phone: +44-71-223-4062 In-Reply-To: Your message of Fri, 03 Jul 92 14:42:56 -0700. <199207032142.AA05142@braden.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Sat, 04 Jul 92 11:57:21 +0100 Message-Id: <1281.710247441@isode.com> From: Steve Hardcastle-Kille Bob, This is a comment, rather than promoting either side of the argument. A very analogous situation has happened with directory services. There was much debate about X.500 vs other more researchy and potentially promising ideas. Whilst X.500 has not been endorsed officially, as I hope it will be, there is an increasing acceptance of its status on the Internet. Politically, the adoption of X.500 has been very beneficial, and there are an increasing number of activities that are looking to benefit from this infrastructure. Technically, it has not been a case of simply adopting the ISO Standard - this is what the plethora of X.500 related RFCs are all about. Changes have been done with some care, to ensure interoperability with "pure" X.500, as opposed to just using X.500 as a start point. Adapting X.500 to Internet needs will continue, for example with the use of Internet-oriented lightweight access protocols. I believe that the approach of taking an ISO standard, and adapting it to the problems in hand has, to a large extent, let us have the cake and eat it. Steve From owner-Big-Internet@munnari.oz.au Sun Jul 5 01:27:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20420; Sun, 5 Jul 1992 01:28:02 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20416; Sun, 5 Jul 1992 01:27:54 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00704; Sat, 4 Jul 92 11:27:45 -0400 Date: Sat, 4 Jul 92 11:27:45 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207041527.AA00704@ginger.lcs.mit.edu> To: Bob.Hinden@eng.sun.com, ietf@isi.edu Subject: Re: Comments on IPv7 Document Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us We need larger addresses for sure, but 5 time bigger? This is not a point I can totally agree with. I do think we need long addresses to run a system the size we plan for, but simultaneously get the kind of fan-out at each level we need to run a routing system with reasonable overhead in memory, etc, costs. Remember, adding one bit at any layer doubles the amount of memory needed to store the map/routing-table for that layer! Two 8 bit layers gives you as much address space as one 16 bit layer, but at about 1% of the cost in memory to store the related routing information (if you have absolutely no optimzations such as optimal entry points to surrounding areas). However, you probably won't get the same number of effective addresses because of breakage; you probably need three 8 bit layers to match one 16 bit layer, but still at a great savings in memory. This means many small layers; i.e. long addresses. I agree that we do need a short entity, which we can stand the overhead of in each packet of a long transaction, and which can also serve as a cache tag for looking up these long addresses in the caches which have *already* augmented (and in future, will I think totally replace) the routing tables. There is a significant body of experience that says the options are a bad idea in the first place. Again, I can't concur. Options are the only way we have of extending the semantics of the packet layer. Sure, if we add one which has to be in every packet, we will have to upgrade the routers to process it effectively. Still, in a giant system, we'd better have a way to expland the semantics without changing the packet format, or we are really sunk. On the other hand if we proceed this way, we are likely to start a war. .... There will be much less fighting if the community feels that there has been a fair hearing of the issues and approaches. Going to start a war? Pardon me, but I hear people reaching for their launch buttons all over. "The protocol war to end all protocol wars...." I totally agree that this blowup is one of the most utter and futile wastes of energy I have ever seen. However, the horse is well and truly out of the barn. Noel From owner-Big-Internet@munnari.oz.au Sun Jul 5 01:50:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20849; Sun, 5 Jul 1992 01:50:29 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207041550.20849@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20846; Sun, 5 Jul 1992 01:50:24 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from sartre.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 4 Jul 1992 16:50:12 +0100 To: braden@ISI.EDU Cc: big-internet@munnari.oz.au Subject: Re: IPv7 Checksum In-Reply-To: Your message of "Fri, 03 Jul 92 15:06:41 PDT." <199207032206.AA05212@braden.isi.edu> Date: Sat, 04 Jul 92 16:49:50 +0100 From: Jon Crowcroft >So, Jon, should IPv7 use the IPv4 checksum, or can we come up with a >different checksum that also provides byte swap protection but is >easier/faster to compute than the 8473 checksum? Bob since most IP routers i know dont have byte swapping bugs anymore, but i dont know more than 1 CLNP router, i couldnt say - i think i might prefer the speed to stay the same firstly...if there is a reason to introduce a slow down as well as new bugs, then i would be interested to hear:-) jon From owner-Big-Internet@munnari.oz.au Sun Jul 5 02:02:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21043; Sun, 5 Jul 1992 02:02:55 +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 AA21040; Sun, 5 Jul 1992 02:02:51 +1000 (from kre) To: Big-Internet@munnari.OZ.AU, iab@isi.edu Cc: ietf@isi.edu Subject: IPv7 and criticisms thereof Date: Sun, 05 Jul 92 02:02:41 +1000 Message-Id: <19446.710265761@munnari.oz.au> From: Robert Elz I'm a bit confused... I have read the ID, and I've read Bob Braden's and Hans-Werner Braun's comments, and I'm perplexed at exactly what people are criticising - even more than that, perhaps astonished at those supporting it. The ID, when read with the messages, seems to be not much more than a political statement to me - or at least, the part of it that has been of concern here seems like that. The Internet is, according to the ID, going to switch to using CLNP, but exactly what that CLNP is isn't decided, other than a name. We don't know what the addressing will be like, apparently even the checksum algorithm is up for grabs. That more or less means we have some new datagram format whose name will be renamed from CLNP to IPv7 - though the details are all unknown. Probably the packet format will look something like ISO CLNP, though even that doesn't look absolutely certain, and in any case is about the least important thing that needs to be decided - I suspect that one IETF WG session could define a new packet format (layout) with no real difficulty, its just not such a complex activity. So, exactly what is it that everyone is complaining about? It seems that we can define anything at all, just as long as we call it CLNP so it can be renamed to IPv7, and that will suit the IAB. Its a little hard to imagine that the IAB don't realise that the difficult part of all of this has been, and continues to be, finding an addressing and routing architecture that will work into the future - that part is not addressed at all in the ID. What format the packet is that carries the new addressing isn't what you'd call a vital issue once we assume that it won't be compatible in any way with IPv4 (which isn't to say this assumption is justified). So, I'd suggest that we hold off on the screaming, and go back to our previous work - treat the ID as we would any other management level policy statement - as something to pay lip service to, but otherwise ignore any time it gets in the way. kre ps: I have almost restrained myself from wondering whether its going to be called IPv7 because of the magic '7' in the ISO world. From owner-Big-Internet@munnari.oz.au Sun Jul 5 02:53:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21810; Sun, 5 Jul 1992 02:53:15 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207041653.21810@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21807; Sun, 5 Jul 1992 02:53:09 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Sat, 4 Jul 1992 17:39:57 +0100 To: Robert Elz Cc: Big-Internet@munnari.OZ.AU, ietf@isi.edu Subject: Re: IPv7 and criticisms thereof In-Reply-To: Your message of "Sun, 05 Jul 92 02:02:41 +0900." <19446.710265761@munnari.oz.au> Date: Sat, 04 Jul 92 17:39:37 +0100 From: Jon Crowcroft >than a name. We don't know what the addressing will be like, >apparently even the checksum algorithm is up for grabs. Exactly! thats why i sent out my hastily hacked comparison of CLNP&IP - if you leave out address formats, aggregation and allocation, then you have left out solving the address space problem and routing sacaling problem - i.e. the very problems the IAB claim to be proposing a son for i.e. you still have to do ALL the work - pip, EIP, IPAE and others propose equally sensible packet formats (better since all are 32 bit aligned and since they aren't already set in 7 layer cake, could be made 64 bit alinged if need be...) - but packet format mangling code is only a few weeks work...souped up route lookup microcode (CAMs) and forwarding loops (bit slice, cut through or parallel in many routers...) is what takes the time - and that all dfepends on: what scheme is being proposed: a) decide a format (fixed or variable - max?) b) to distribute the rights to allocate IPv7 addresses c) to support route aggregation with efficient route lookup and forwarding... d) anything new that IP is just about to do? i.e. the real solutions? [by the way, i really appreciate the IAB gettign the discussion going & certianly believe hans' statement that they have the 'good' of the Internet at heart...] jon From owner-Big-Internet@munnari.oz.au Sun Jul 5 04:38:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24080; Sun, 5 Jul 1992 04:38:23 +1000 (from owner-Big-Internet) Return-Path: Received: from HQ.TGV.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24077; Sun, 5 Jul 1992 04:38:19 +1000 (from karl@Mel-Brooks.TGV.COM) Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ; Sat, 4 Jul 92 11:38:00 PDT Received: from karl.lvs.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1) id AA01366; Sat, 4 Jul 92 11:39:07 PDT Date: Sat, 4 Jul 92 11:39:07 PDT Message-Id: <9207041839.AA01366@mel-brooks.empirical.com> To: dino@cisco.com Subject: Re: why 160-bit addresses are daft.... From: karl@Mel-Brooks.TGV.COM (Karl Auerbach, Empirical Tools and Technologies, 408/427-5280) Reply-To: karl@TGV.COM Cc: braden@ISI.EDU, bsimpson@angband.stanford.edu, ietf@ISI.EDU, big-internet@munnari.oz.au Sender: karl@Mel-Brooks.TGV.COM Repository: empirical.com Originating-Client: lvs.empirical.com > Regarding byte alignment, when we switch a packet: > 3) We need to look at the checksum. > IP - offset byte 10 (2 bytes) > CLNP - offset byte 5 (2 bytes) We ought to put the checksum at the end and make it such that it can be computed by I/O hardware as the packet is squeezed out the interface. And destination addresses ought to be as early as possible to make cut-through routers easier. > Regarding checksum algorithm. > 1) Fletcher (OSI) checksum is slower because it is byte oriented. The "fast" algorithms for Fletcher require a multiply and, if I remember right, a modulo calculation. On a large part of the hardware base (and especially on wimpy PC's) these are pretty expensive instructions (and some risc machines don't even have hardware for these.) > OSI might be *big* but CLNP itself is not really any bigger than IP. And it inherits some of the same disregard for how things actually work, removes some IP glitches, and adds a few more of its own. All this talk reminds me of an old joke (which I'm not sure is relevant): The English have finally decided to conform to the rest of the world's habit of driving on the right/correct side of the road. Starting next Monday, all the large trucks will make the switch, on Tuesday, the passenger automobiles... --karl-- From owner-Big-Internet@munnari.oz.au Sun Jul 5 08:16:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27306; Sun, 5 Jul 1992 08:16:51 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207042216.27306@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27303; Sun, 5 Jul 1992 08:16:45 +1000 (from lyman@BBN.COM) From: "Lyman Chapin" Subject: Re: IPv7 (CLNP) a mistake To: craig:; Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov In-Reply-To: <9207022308.AA28811@aland.bbn.com> Date: Sat, 4 Jul 92 17:52:41 EDT Mail-System-Version: >To: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, > ietf@isi.edu, road@lanl.gov >Subject: IPv7 (CLNP) a mistake >From: Craig Partridge >Date: Thu, 02 Jul 92 16:08:29 -0700 > > >I've read the IAB announcement, RFC 1347 and the Internet Draft, and am >afraid I view this idea of adopting CLNP as IPv7 as a disasterous idea. Craig, You're certainly not alone in this opinion! However, I think you have misunderstood some crucial elements of the IAB's plan, and made some assumptions that I (at least) don't think are valid. > >First, adopting CLNP means buying into the ISO standards process. Absolutely not. If I thought that this were true, mine would be the loudest voice arguing against the proposal, given the experience I've had with the formal ISO/CCITT standards process. Trading the Internet process for that of ISO would so clearly be a giant step backwards that I can't imagine anyone, even a die-hard OSI supporter, advocating it. For at least the past four years, almost every person working on CLNP and its relatives (addressing, routing protocols, and extensions) in ANSI and ISO has also been a committed Internet person. Every one of them prefers the IETF way of doing things to the ISO way. The people who actually manage and carry out the work on CLNP in ISO and the national standards bodies of the US, UK, Norway, Denmark, Japan, and Finland are Internet people. >While the Kobe announcement states that choosing CLNP is "not choosing OSI," >it is the case that we'd be choosing to make the network layer of the Internet >protocol suite the same as the OSI protocol suite. As such, we have >to face the painful reality that any future changes that the Internet >community wishes to see in the network layer will require ISO approval too. I'm tempted to just ask "why?", but that might sound disingenuous. Any change to CLNP that is necessary for CLNP to operate as the internetwork protocol of the Internet is, by definition, a change that all but one or two of the ISO people working on CLNP would support. It is hard to imagine ISO failing to approve such a change - who would vote against it? The voters would almost all be Internet people. ISO approval, assuming it is considered to be necessary, would inevitably lag IETF/IAB approval by a year or so, but with the reality of CLNP evolution fixed firmly in the IETF/IAB arena, who would care? >ISO and the Internet community have radically different views about >the standards making process (e.g. testing before standardizing, whether >to bill for standards, and the like). Indeed, the Internet community >decided not to join up with ANSI/ISO a few years ago because both >communities felt there were incompatibilities in their processes. >Now we're proposing to buy into the ISO process to manage our network layer. >We'll all have to learn the detailed workings of the ISO process if >we want to change the network layer -- and since it requires some >number of meetings to be ANSI/ISO accredited, we'd better all start >attending those meetings now (in addition to our IETF meetings) so Agghhh! I've been doing that for too many years - believe me, you wouldn't wish it on your enemies, much less your friends in the IETF! True, you'll have to know more about what ISO is doing on the network layer than you do now, but the pain will be far less than what you've described above. >we can be prepared to defend our ideas in the ISO process. Do we >really want to pass much (all?) of our control over the Internet >network layer to a process that the Internet community finds >incompatible? As we've clearly stated in RFC 1310, the IAB does not accept Internet standards over which we don't have change control. If CLNP becomes IPv7, and we decide that IPv7 must be changed in some way to improve its useful- ness to the Internet, then that change will be made. If ISO later (with ISO, unfortunately, it's always going to be "later"...) agrees to also make the change, then that will be very good (as you point out below, the best situation would be for IPv7 and ISO-CLNP to stay the same), and I expect that the people currently working on CLNP in ISO (and the companies that have been supporting them) will consider it very important to make this happen. However, it is not essential - if, for some reason, ISO decides *not* to go along, IPv7 won't suddenly stop working. With the number of interests that will be served by making sure that ISO *does* track any IPv7 evolution in the Internet, I don't foresee this happening (but, to be fair, recognize that it's a possibility). The IAB/IETF process determines what happens to IPv7, and ISO may, if it wishes, follow suit - not the other way around. > >(I've heard at least one person suggest that if ISO doesn't like >Internet-proposed changes, we'll just publish our own version of CLNP. >Ignoring ISO copyright issues about issuing a modified ISO spec [which >may or may not prove to big deal], I don't buy this idea. First, why >even call this new network layer CLNP unless we believe we mean to keep >in sync. Second, having an Internet and an ISO CLNP means that vendors >will have to support two versions of CLNP, which they won't like. ...and, since they are the people who have been determining the evolution of CLNP in ISO, they will presumably spend the effort to make sure that this doesn't happen (whom could it possibly benefit?)... >Consider how much folks already complain about the different GOSIPs. >We'll find ourselves in a tremendous vise to harmonize with ISO. We've >tried that twice before, with CMIP over TCP and IS-IS. In one case, >the idea was a complete flop but only after a waste of some years of >effort. In neither case was the process pleasant. I don't think we >want more of these kinds of problems.). > >Second, CLNP deals with only *one* of the several issues facing IP, namely >address depletion. At the same time, it forces us to take a giant step >back on other issues. CLNP does *not* support multicasting. There >are proposals in the works to add it -- but that means CLNP is about five >years behind IP on this topic. IP multicast is working now and it has >taken a lot of effort -- it is in products (Solaris 2.0) and in >BSD (4.4 and mods are available for 4.3). We're making good progress >on mobile host support. Some experimental implementations under >IP are getting heavy use. We'll have to go back to the CLNP drawing >board on those projects too. Ideas to support multimedia applications are >fast becoming reality (witness the recent IETF multicasts on the >Internet). If we buy CLNP we'll have to wait a few years for ISO >to approve those extensions. With the exception of a brief mentions >about leaving space for options and making sure that multicast will >somehow be supported, the various documents don't address this issue. This is a very pessimistic viewpoint, and one with which I simply don't agree. It's misleading to say "CLNP does *not* support multicasting" - neither does IP (IGRP, OSPF, and BGP do), and since the architecture of CLNP internetworking is identical to that of IP, there is no reason to expect that the work involved in expressing new stuff in CLNP rather than IP is anything like "going back to the drawing board". If CLNP becomes IPv7, I don't expect anyone to suddenly stop working on innovations based on IPv4 - that's what's out there (and no IPv4-->IPv7 shift is going to happen overnight). But there is no reason to think that the work based on IPv4 will not be directly applicable to IPv7 - and factoring good ideas into CLNP is something that vendors are likely to be motivated to do any- way, whether the result is called "CLNP" in a dual-stack IP/CLNP product or "IPv7" in a dual-stack IPv4/IPv7 product. The statement "If we buy CLNP we'll have to wait a few years for ISO to approve those extenstions" is simply false. Clearly the IAB intends for the Internet community to own IPv7. Why would we hold up an extension "waiting for ISO"? (there's a potential pun lurking there, which I will resist pursuing....) > >In short, CLNP as IPv7 seems destined to be a technical step backwards >and to place a severe crimp on protocol innovation at a time when we >need to innovate. (Some folks have expressed concern that the rise in >voice and multimedia on the Internet will stress IP *this* year. To my >knowledge, no one has tried running voice over CLNP). Are we so sure >that we should choose CLNP with all its limitations, especially now that >CIDR gives us a bit of breathing room in which to think? Are we so sure >CLNP is the right decision that we shouldn't even consider developing at >least one other approach in parallel, just in case we discover CLNP >really is a tar baby? CLNP as IPv7 is not intended to be any improvement on IP with respect to new Internet applications (including voice and multimedia) - it is intended only to stave off the ROAD problems, while research proceeds on a genuinely "new" internet protocol. The IAB doesn't believe that it is wise or prudent to place such a heavy bet on CIDR (which may or may not give us "enough" breathing room, depending on a lot of factors that are difficult to predict accurately enough to confidently hedge the bet). And I strongly suspect that people will continue to work on IPAE and other proposals with or without the IAB's blessing, notwithstanding our explicit recommendation that people focus their efforts on the unresolved issues surrounding a CLNP-based IPv7. > >Craig - Lyman From owner-Big-Internet@munnari.oz.au Sun Jul 5 08:22:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27367; Sun, 5 Jul 1992 08:22:50 +1000 (from owner-Big-Internet) Return-Path: Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27364; Sun, 5 Jul 1992 08:22:43 +1000 (from medin@nsipo.nasa.gov) Received: Sat, 4 Jul 92 15:22:20 PDT from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Message-Id: <9207042222.AA16204@dscs.arc.nasa.gov> To: Hans-Werner Braun Cc: iab@ISI.EDU, big-internet@munnari.oz.au, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov Subject: Musings on the past few messages In-Reply-To: Your message of "Fri, 03 Jul 92 16:36:05 PDT." <9207032336.AA16883@upeksa.sdsc.edu> Date: Sat, 04 Jul 92 15:22:15 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Wow! I go away for a couple days of vacation and helping with irrigation down at my family's farm in the valley, and I log in to find my name in lights! And I thought the fireworks were reserved for today (the 4th!) :-). First off, let me clear up a few points. I did not mean to launch a personal invective at the members of the IAB. I have much respect for them, and I have dealt with many of them in a variety of areas in the past. HWB and I both sit on the FEPG, and I when I had more time for fun stuff, I used to attend ANSI X3S3.3 meetings that Lyman Chapin chaired. I firmly believe they are motivated to try and assure the growth and prosperity of the Internet community and the operational Internet itself. I made no reference about them being "evil" and having the IAB be destroyed nor was that my intention. I certainly was not advocating anarchy; that's rather inconsistent with my political viewpoints in any case. If that was what people read into it, I profusely apologize. However, people sometimes make mistakes. I believe the decision to put a stake in the ground now on this issue is a mistake. As H-W correctly pointed out, this kind of decision is a very rare and new thing for the IAB to do. It's a well meaning attempt to try and cut short the debate, and push the IETF community ahead with progress in developing a solution to the address space and routing problems which we are feeling now, and that will get worse later on. I do not believe any of the IAB was trying to act with malice here. This goal is in fact part of the problem. I said in my earlier note that the IAB has no real authority; that it is an organization that leads, not directs. H-W, I didn't think you disagreed with that. I fully share your frustration with progress on moving ahead with projects in the IETF. I have been involved in more than my share of headaches in that area. However, what I have learned from this experience is that the eventual IAB decision is not really what decides things. It is in fact the debate on the issues that really decides things. It is that debate, where the various burning issues are hammered out between the R&D community, the vendors, and the users. It is the debate in fact, where most of the community develops their viewpoints on whether or not a particular approach is a good approach or bad approach, and where people decide where to throw their development resources at. Sometimes there isn't always consensus, but eventually the various battles rage and productive solutions come out as implemented prototypes and solutions. It's far from efficient, but has seemed to work pretty well in the past. Now, if we were done with that debate, and we had a clear consensus, then such a move by the IAB would be appropriate, by codifying that consensus in an official position of the community as a whole. My problem is that that consensus didn't exist, certainly not on the issue of advancing the CLNP approach as THE approach for the medium to long term. By trying to cut off the debate, the normal process is stopped short of it's natural conclusion. This in many ways affects the timeframe that any solution can be implemented in. I would venture to say that a unified IETF working towards a goal achieved by consensus would complete it's various tasks far more quickly than an IETF where the various players are not firmly convinced that the selected approach is the right one. It's the enthusiasm behind the effort that can lead to rapid implementation, coupled with very tangible benefits that act as an incentive for people to migrate. Now, with regards to my ISOC comment. If you accept my proposition that the IAB leads by technical leadership, then anything that obscures that only diffuses the issue. It's not any formal IAB authority that makes the IAB successful. Nor is ISOC sponsorship, or government blessing or anything else. It's the IAB's technical leadership that causes people to stop and take note of what the IAB does and doesn't do, because IAB actions are not taken as the actions of the individuals on the IAB, but as the codification of the IETF and Internet community views as a whole. When the IAB pushes ahead with a proposal that is not a codification of the community's viewpoints, it seriously erodes it's technical leadership, unless there is a clearly superior proposal it is trying to advance. I don't view this statement as particularly incendiary. In this particular case, Bob Hinden's (the routing area director) and others' commentary on the draft show that the CLNP approach is not clearly superior. It may in the end prove to be the approach that everyone settles on, but it's not something that should be pushed on from the top. It needs to be decided on, bottom up, through the working groups and the IESG, because that's the process where the debate occurs. That is why this approach is harmful to the process of consensus building, and without consensus, the changes of the type that are being discussed are very unlikely to happen. Now, I never believed or argued the IPv7 document advocated a US GOSIP or other standard addressing standard for NSAP's. That was pretty clear. It also appears that the checksum location and type is also up for grabs. It appears that the proposal never really advances TUBA specifically. In fact, many of the supporters of a CLNP approach may not like the outcome of the proposed IPv7 process at all, since it probably won't be interoperable with the OSI at all. The other main point of my note was that given that we aren't really talking OSI or even a common CLNP packet definition, the draft really confuses people as to what it exactly was trying to say. When I discussed this with HW on the phone, he thought that was a good point and that the document needs to clarify this aspect. This way, marketing people and others will not be able to exploit this unfairly. And we won't have to deal with the aforementioned baroqueness of the current NSAP allocation organizations. The Internet is a big business these days. Perceptions are important, and they need to be considered. Now, on a few miscellaneous points. There are a lot of hard problems here. These problems will not go away with CLNP. The address depletion problem is not the really big problem. That is primarily an administrative problem, and can be handled by a number of mechanisms. If this is really the overriding focus of concern, we should move to stop issuing of coordinated address space to disconnected nets. That, coupled with recycling of disconnected net numbers can go a LONG way to preventing the address depletion problem from biting us. Coupled with CIDR, this does in fact buy us some time. Maybe quite a bit of time on the address depletion front. It does require new sites when the come on line to renumber. That's a pain. But running out of addresses is worse of course. Also, many commercial organizations have only one or 2 machines that actually need Internet connectivity, because the security capabilities we have in the network are so awful right now. This means that the other systems in that organization do not really need coordinated space either. The real problem is overall scaling of the routing system, and trying to grow the system for a couple more years at exponential growth with existing routing designs and hierarchy. I run an operational international backbone, of something like 150 routers. Our routers at the FIX points have no default. They carry total information. We also are a COTS (commercial off the shelf) shop, and we don't try and build routers or router software. I would hope that a major goal of the IETF process in this area is allow organizations like mine to continue to be able to be major players in the network game without resorting to non-COTS technology. And if the scaling of the routing system isn't the major goal behind the solution being proposed, then we really have problems. To Lixia, it's fair to blame the funding agencies a certain amount, but I will say that when I talk to DARPA and others about this problem, they respond that they do not receive a lot of proposals for research in this area. It is a pain to deal with the proposal process I agree, but there is money to be had for these sorts of activities for good proposals. At least that's certainly been true in the past couple of years. And to others who seem to be taking an us vs. them attitude about TCP/IP vs OSI. I would say that the real enemy, if one has to use the term, of TCP/IP is not OSI, but in fact the proprietary network technologies out there, who outnumber IP based solutions in installed base. Even if OSI went away today, we would still have to deal with multiprotocol routers and support for new and old proprietary solutions for a long time to come. I do believe that the OSI people are after the same end goal that the Internet is after, namely full interoperability with lots of functionality and robust implementation. Having attended ANSI X3S3 meetings in the past, I will say that they suffer from a far more political standardization process than we will ever deal with. OSI has suffered greatly in terms of deployed and functional products, not because there are stupid people working on it; quite the contrary is true, there are some very sharp people who work in the OSI arena. But the process they suffer from greatly impedes work and causes a lot of extra complication and hurts the quality of output. Compromise is at every step. This is why I and others worry the most about the process in the IAB/IETF system. Because it's been our processes and traditions that have made the IP suite so darn successful. And on the issue of personality, I went to my 10 year high school reunion last year. Many of my old friends there commented on how mellow I had gotten in the past few years! I actually never considered my note very extreme; and I'm rather disappointed if some people perceived it that way. I got flames from both sides on what I said, that I was too harsh and many that I was too light. I was trying to to take a moderate tone. I guess you can't please everyone all of the time. :-) Now, back to the furrows... Thanks, Milo From owner-Big-Internet@munnari.oz.au Sun Jul 5 08:46:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27868; Sun, 5 Jul 1992 08:46:52 +1000 (from owner-Big-Internet) Return-Path: Received: from cody.cso.uiuc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27858; Sun, 5 Jul 1992 08:46:45 +1000 (from rrv@cody.cso.uiuc.edu) Received: by cody.cso.uiuc.edu (AIX 3.2/UCB 5.64/4.03) id AA12991; Sat, 4 Jul 1992 17:46:33 -0500 Date: Sat, 4 Jul 1992 17:46:33 -0500 From: rrv@cody.cso.uiuc.edu (Ross Veach) Message-Id: <9207042246.AA12991@cody.cso.uiuc.edu> To: kannan@oar.net Subject: Re: Draft IESG recommendation on ROAD activities Cc: big-internet@munnari.oz.au > would not the c# host view all the advertisements from the dec20 as being > host routes in RIP? Ross? Surely there aren't enough dec 20s acting as routers to have an impact on decision making at the Internet level. Surely even a dec 20 can be instructed to not send RIP in an environment where it has no routing information to contribute. From owner-Big-Internet@munnari.oz.au Sun Jul 5 10:42:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29810; Sun, 5 Jul 1992 10:42:56 +1000 (from owner-Big-Internet) Return-Path: Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29807; Sun, 5 Jul 1992 10:42:51 +1000 (from hwb@upeksa.sdsc.edu) Received: Sat, 4 Jul 1992 17:42:41 -0700 by upeksa.sdsc.edu (AIX/1.6) From: Hans-Werner Braun Message-Id: <9207050042.AA09079@upeksa.sdsc.edu> Subject: Re: Milo going Nova. To: farber@central.cis.upenn.edu Date: Sat, 4 Jul 92 17:42:41 PDT Cc: lixia@parc.xerox.com, ietf@isi.edu, big-internet@munnari.oz.au In-Reply-To: <9207050038.AA20847@linc.cis.upenn.edu>; from "farber@central.cis.upenn.edu" at Jul 4, 92 8:38 pm Dave: You certainly said it better than I did. Hans-Werner >Hans-Werner, > >I would take a complementary but slightly different position on network >research. It is clear to me that what we need is network research and >network advanced development efforts. All to often, and I have sat on >enough review panels to have heard it often, we come out on the short end >of the stick with the NSF (and maybe others) because our "research" spans a >spectrum from fixing current problems to real far out research. It gets >compared against more of the far out stuff and so it sounds like much is >"poor research". > >I propose that the agencies recognize that development needs to be done to >keep and expand the network as well as research into the edge domains such >as gigabits etc. In Physics, I suspect, every part of building a Super >Collider is not research. It is developing gadgets that enable facilities >for research to be done. Lets try to get money set aside for such >development activities that are judged by the metrics of short term needs >not academic research. > >Everyone would be happier including the agencies. > >Dave > >btw if you thing this is worth while forward it to the IETF lists From owner-Big-Internet@munnari.oz.au Sun Jul 5 17:05:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05987; Sun, 5 Jul 1992 17:05:40 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA05984; Sun, 5 Jul 1992 17:05:37 +1000 (from jnc@ginger.lcs.mit.edu) Received: from ginger.lcs.mit.edu by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA17761; Sun, 5 Jul 92 03:04:37 -0400 Received: by ginger.lcs.mit.edu id AA02711; Sun, 5 Jul 92 03:02:07 -0400 Date: Sun, 5 Jul 92 03:02:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207050702.AA02711@ginger.lcs.mit.edu> To: Lyman@bbn.com Subject: Re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov Lyman: This sounds much like ideas for this suggested interaction between the Internet and OSI that I've heard from you in the past, and is a more sophisticated and plausible version of this than made it into the IAB I-D; it's too bad the multiple drafts the IAB went through didn't manage to work this in. Having read it, though, I am still left with the feeling that somewhere in a forest, 2+2 is not adding up to 4, as I'll explain in a bit. Mind you, I see the argument for having only a single non-proprietary open packet networking architecture, but I still think the best way to do this (as I have indicated previously) is to design an entirely new protocol which we can label the common decendant of both. This is little different in practise from your suggestion, you might say, and there is something to that. However, it does avoid certain classes of pointless angst, such as the variety we are now experiencing. Let's assume for the sake of argument that we want a new packet layer very soon (an assumption I absolutely disagree with, as explained below). It is suggested that we are to take a protocol (CLNP) which both sides seem to keep saying is basically the same as IP, but has two major claimed advantages; longer addresses, and space for more options. (I will put to one side, for sake of clarity, debates about whether those longer addresses are what we need. I will also put to one side claims of disadvantages, like a less-well suited checksum, etc.) However, we aren't binding ourselves (for reasons of abilty to meet requirements) to keeping that protocol exactly the same. To me, this sounds like we have just voided the best argument for switching to a second protocol, which is the interoperability issue. Surely, if the Internet CLNP is functionally different in a useful way, it won't be interoperable, right? I mean, if all we are getting is larger addresses and space for more options, and have to make changes to the protocol which make it non- interoperable with vanilla implementations, surely we could get the same thing my modifying our existing network layer (IP) at the same effective cost. In fact, the cost would be less, since we wouldn't have to make some of the major changes to our protcol suite that a switch to a new network layer would entail (e.g. phasing in ES-IS, etc, etc). If we are going to modify an existing protocol to get what we need (and I don't agree we should be doing this at the moment), why switch to a totally different one to do it? I'm also less sanguine than you are about the ability to get the ISO world to track changes made here. Standards bodies *all* (including the IETF, I willingly admit) seem to have a bad case of N.I.H. I mean, look at IEEE; they just *couldn't* resist dinkering with Ethernet, a widely deployed and very sucessful standard. I *still* think the best interim path is to put off the adoption of a new packet layer as long as we possibly can, until we understand more about some major, little-understood, technical issues that a successful large scale networking infrastructure will have to face (such as resource allocation, pervasive network security, substantial auto-configuration, etc, etc.) This delay will also allow us a clearer vision of the physical network infra- structure of the future, includling things like Gigabiot nets, etc. I believe we can kill two birds with one stone: deploy an entirely new routing and addressing architecture, and maximize the lifetime of the current IP, by the simple expedient of changing the interpretation of the current 32 bit source/dest fields in a way that gives us a capability we have long wanted anyway. By the time that is thinking about running out of steam (and even if we only get 10% utilization of the 2^32 sized identifier space, we still get *four hundred million* hosts), we should know a lot more about these research topics, and can move straight to a third generation packet protocol. Noel From owner-Big-Internet@munnari.oz.au Sun Jul 5 20:40:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09512; Sun, 5 Jul 1992 20:40: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 AA09509; Sun, 5 Jul 1992 20:40:35 +1000 (from smart@mel.dit.csiro.au) Received: from manta.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA16781 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sun, 5 Jul 1992 20:40:33 +1000 Received: by manta.mel.dit.CSIRO.AU (4.1/SMI-4.0.1) id AA19449; Sun, 5 Jul 92 20:40:32 EST Message-Id: <9207051040.AA19449@manta.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Nimrod (and bits of PIP): an interpretation. Date: Sun, 05 Jul 92 20:40:32 +1000 From: Bob Smart Saying what you think you understand is a good way to attract clarification and resolve misunderstandings. So here is my summary of Nimrod and some bits of PIP from the perspective of the poor Network managers who have to make it all work. We can probably do all this using CLNP packet format if politics requires it. Suppose, to start with, that we are an isolated entity, domain name yy.zz. We build our local network as a 2 level hierarchy: equivalent to the normal subnets and hosts. This is how we set up the DNS: net.yy.zz. PIN A . #that says that we are the root of the address hierarchy subnetA.yy.zz. PIN A net.yy.zz.1 # that said that subnetA is subnet 1 in net.yy.zz subnetB.yy.zz. PIN A net.yy.zz.2 #etc aa.yy.zz. PIN A subnetA.yy.zz.11 # that said that host aa.yy.zz was host number 11 on subnetA bb.yy.zz. PIN A subnetB.yy.zz.22 We can change subnet numbers without renumbering the hosts if we want to. More significantly we can change our addressing by joining on below some wider hierarchy. Suppose we now join NSFnet and they say that we are network 75 on one of their backbones. Now we don't have to renumber all our hosts, we just change the entry that says we are the root net.yy.zz. PIN A t3bone.nsf.net.75 So if t3bone.nsf.net is top level address 12, then the full address of host bb.yy.zz is now 12.75.2.22. Now suppose we also join PSInet for our commercial traffic. We are network 40 on their backbone which is toplevel 66. We just add a single entry: net.yy.zz. PIN A t3bone.nsf.net.75 PIN A psinet.psi.com.40 Now bb.yy.zz has 2 addresses: 12.75.2.22 and 66.40.2.22. If PIP packet format/forwarding is used then the internal routing in yy.zz's net using the 2 level addresses will still work. Obviously router configuration changes will be needed to allow the new external links to work. In PIP they aren't too many. When packets arrive for 12.75.2.22 or 66.40.2.22 the pointer is on the 2 and the routers don't have to know about the meaning of 12.75 and 66.40 (though I think there will be other reasons why they should). Since these addresses are perfectly synchronized with network providers there is no routing table problem at all. It is CIDR taken to its logical conclusion. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The above system of provider-oriented hierarchical addressing is one of PIP's modes. PIP can also do a system like the current IP system where addresses are decoupled from network providers, but getting away from that is the main reason for looking at separating address from ID. I will assume that provider oriented addresses are the way to go. A problem with network provider oriented addresses is that they are potentially a bit variable to use for identification. Perhaps that is only a problem for mobile hosts but separation of address and ID has other advantages, so we assume that there is a separate identifier. One mode of operation envisaged in Nimrod is to use the current IP address as an identifier, and that is a very important mode for transition. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Nimrod assumes (at least) two modes of routing. One is source routing. Routing based on provider-oriented hierarchical addresses is in this category, and is compatible with the aims of Nimrod. You can regard the "no brainer" route resulting from a provider-oriented hierarchical addresses as being derived from a particular form of route thinning/ abstraction. The other mode of routing is based on flows. A source routed setup packet is sent which sets up a flow with associated resources (such as guaranteed bandwidth). Subsequent packets use flow based addressing. While this is intended to be the main form of packet forwarding in Nimrod, it doesn't have to be implemented immediately. We can start with just no-brainer routing based on provider oriented hierarchical addresses and add more sophisticated stuff later. Both Nimrod modes are supported by PIP. Noel is concerned that PIP wasn't actually derived from Nimrod's requirements, but it was obviously derived from a very similar experience and knowledge of routing requirements. Anyway below I assume that the packet format is PIP, but it could easily be CLNP with addressing that suits us, or something else. The hard part of Nimrod is to do with improved routing protocols and algorithms and thinning/compaction/abstraction schemes to handle the huge amounts of information. However all that hard stuff is in the future, and I think we can understand the basics of Nimrod without that. If we can't there's no point asking me. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - One key idea in Nimrod is protecting the existing hosts. The way this works is that existing IP protocols are continued, but the IP address in the packet becomes just an identifier. The hosts on your subnet might now have all sorts of IP addresses. The router on the subnet has to solve this problem for the hosts on the subnet. It does this by: (a) forwarding back packets sent to the router for hosts on the same subnet; (b) responding with proxy arp to arps for hosts not on the subnet. It is a good idea to set the hosts' netmask to 0.0.0.0 to prevent (a), but that isn't necessary. The router then forwards the packet across the Internet to its destination. To do this it must encapsulate or convert the packet to PIP(/whatever) format. Convert is better because encapsulation should be undone before final delivery, but a converted packet can logically be sent all the way to the destination if the destination has learnt the new protocol. An important point about Nimrod is that it is only the first router, the one on your subnet, which has to know how to convert the destination identifiers your users use to addresses. It can easily build up a large cache of such things and not have to often do lookups [and if translations time out and become invalid then the router should try to keep them up to date rather than wait until after they have timed out then drop packets until a new valid translation has been obtained]. In the early days when IP addresses are the IDs, the translation can naturally be kept under the in-addr.arpa domain. So if the existing globally unique IP address of bb.yy.zz is 192.9.200.73 we would have 73.200.9.192.in-addr.arpa. IN PTR bb.yy.zz. PIN A 12.75.2.22 PIN A 66.40.2.22 The latter 2 lines would be generated automatically for the Network Manager from other information, so that the answer can be returned quickly to the router. [The router could get the answer with a series of queries starting with the PTR record, but we need to compact the time needed for the router to get this information as much as possible.] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Keeping the IP address as an ID lets it be much more densely used, though there are limits to this due to the way in-addr.arpa is administered [and you have to use some hierarchical administration scheme]. When you combine that with Milo's suggestions you can probably keep the hosts using the current packet format going for a long time. Meanwhile we can bring in hosts that talk the NewIP format. The more of these the less strain on your subnet router doing conversions. Not only that but when the hosts choose the address to send to they can take into account policy issues. About all the router can do is follow very simple rules based on information returned from the in-addr.arpa query: "if the PTR record ends in EDU or GOV or AU then use the NSFnet based source (and/or destination) address, otherwise use the PSInet backbone". The main router linking yy.zz to the world will choose an outgoing link (NSFnet or PSInet) based on the source address chosen by the source host or chosen by the subnet router on behalf of the host. Since, at this stage, the IDs are all 32-bit pseudo-IP4 addresses, the hosts talking the NewIP format and the hosts that imagine IP4 is still going can still see each other with no problem. Not only that, but all higher level protocols are still exactly the same. No need for address translation, no problem with IP4 addresses put by higher level protocols into packets. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - The beautiful result of all this is that a lot of the work of routing has been taken out of the backbone routers and moved into the hosts or local routers. Making the end-points do the work has always been an important principal of IP. It is one of the reasons IP scales well, because as you get more hosts you also get more horse-power and memory to do that work. All this can also be phased in very easily. You can run NewIP and old IP4 in parallel. If your network has moved to NewIP then you will look for PIN A records for an IP destination. If you don't find them you just send by IP4 for as long as the IP4 backbone is still going. We can phase out the IP4 backbone without forcing any hosts to move to NewIP. Then we can look at: bigger IDs, flows with attached resources, better routing algorithms, improved security. It would be nice to have a good idea about how we are going to progress to make sure the forwarding engine and packet format are as suitable as possible, but we don't have to know exactly where we are going. [By the way we could say that IDs are 32-bit IP4-compatible unless the first 2 bits are 10. Any Class As between 64 and 126 are out of luck. We can define longer IDs starting 10 at a later time.] When I first heard of the idea that routers should do DNS (or similar) lookups and keep ID->address translation I thought it was silly. But given that it is only one router close to the source host that has to do it, and given all the other advantages, I think it is worth considering. Bob Smart From owner-Big-Internet@munnari.oz.au Mon Jul 6 04:17:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17317; Mon, 6 Jul 1992 04:17: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 AA17312; Mon, 6 Jul 1992 04:17:31 +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 AA12596; Sun, 5 Jul 92 11:17:10 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA08638; Sun, 5 Jul 92 11:17:13 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA16295; Sun, 5 Jul 92 11:16:53 PDT Date: Sun, 5 Jul 92 11:16:53 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9207051816.AA16295@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA25808; Sun, 5 Jul 92 11:17:07 PDT To: Lyman@bbn.com Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu In-Reply-To: <9207050702.AA02711@ginger.lcs.mit.edu> Subject: IPv7 == CLNP or CLNP+ ? Lyman, I would like to amplify the point which Noel makes in his message for clarification of the question of is IPv7 going to change CLNP or use it "exactly" as is. I keep hearing the argument made both ways and think it is important that this be made very clear. I also agree with Noel that the IAB proposal does not make this very clear. If we use CLNP exactly as is then I see the internet having to live with a number of serious technical shortcomings (e.g. checksum algorithm, no protocol ID, poor field alignment, etc.). Taking this approach is supported by the argument in the proposal (section 3.1) for not taking the risk of designing a new protocol and delaying it's testing and deployment. It would align IPv7 with ISO and current CLNP implementations. If we do change CLNP (which I think the current technical shortcomings warrant) then we will have created a new protocol. Lets call it CLNP+ Vendors would now have to support and deploy yet another protocol. IP will not go away soon. ISO CLNP is specified by GOSIP, used in Decnet P5, etc. CLNP+ would now be used in the Internet. It would take time to decide on what changes are to be made, do a specification, implementations, test it, and deploy it. All of the reasons argued against in the proposal for adopting CLNP in the first place. There seems to be some contradiction in the proposal why it is bad to to extend IP, which would have less impact on the internet layer, while it is ok to extend CLNP. I think this is a very important topic that needs to clarified soon. I would like to see a clear statement, something like: IPv7 will use CLNP "exactly" as is, or IPv7 will use a modified version of CLNP I don't think it can be both ways. If the argument is being made that we could adopt CLNP as IPv7 as is now, and then change it later, I am somewhat skeptical. I think there would be enormous pressure to not do this and it would introduce yet again another internet protocol for the vendors to support and deploy. Or to say it another way, we would have change control over something which we could not change. Bob From owner-Big-Internet@munnari.oz.au Mon Jul 6 04:56:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17913; Mon, 6 Jul 1992 04:56:33 +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 AA17910; Mon, 6 Jul 1992 04:56:24 +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 AA13205; Sun, 5 Jul 92 11:56:12 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA09013; Sun, 5 Jul 92 11:56:14 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA16473; Sun, 5 Jul 92 11:55:54 PDT Date: Sun, 5 Jul 92 11:55:54 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9207051855.AA16473@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA25953; Sun, 5 Jul 92 11:56:07 PDT To: "Lyman Chapin" Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu In-Reply-To: <9207042216.AA14379@p.lanl.gov> Subject: Re: IPv7 (CLNP) a mistake Lyman, In your message to Craig you said: >CLNP as IPv7 is not intended to be any improvement on IP with respect to new >Internet applications (including voice and multimedia) - it is intended only >to stave off the ROAD problems, while research proceeds on a genuinely "new" >internet protocol. The IAB doesn't believe that it is wise or prudent to >place such a heavy bet on CIDR (which may or may not give us "enough" breathing >room, depending on a lot of factors that are difficult to predict accurately I agree with you assessment of CIDR [we do agree on some things :-) ], but do not understand how the IPv7 proposal solves the Routing Information Explosion problem, defined (in section 1.1) as one of the two major scaling problems facing the internet. I don't see any relief for this problem until CLNP has very widespread deployment in hosts and routers. I don't think the current routing infrastructure will last long enough for this to be a viable approach alone. In discussions I have had with Ross Callon, the author of the Simple CLNP proposal, he agreed that we need something to keep the internet going until CLNP can be widely deployed. The current IPv7 proposal does not address this. I think it is a major shortcoming. Bob From owner-Big-Internet@munnari.oz.au Mon Jul 6 04:58:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17925; Mon, 6 Jul 1992 04:58:09 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17921; Mon, 6 Jul 1992 04:58:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03985; Sun, 5 Jul 92 14:57:48 -0400 Date: Sun, 5 Jul 92 14:57:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207051857.AA03985@ginger.lcs.mit.edu> To: Bob.Hinden@eng.sun.com, Lyman@bbn.com Subject: Re: IPv7 == CLNP or CLNP+ ? Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu Bob, your comments bear directly on another thought I had last night while turning this all over in my mind. This is the issue of the deployed CLNP base, and the effect this will have on the ability to carry out the strategy Lyman has outlined, of getting what the Internet sees as necessary modifications 'flowed-through' the ISO. One thing we hear extensively from CLNP proponents (maybe that's too strong, but I can't think of a good crisp word for 'people who are part of CLNP deployment') is that there *is* a substantial, growing, deployed, CLNP base. Once again, to me at least, on putting these two statements made in association with the choice of CLNP together, things don't seem to add up. Given this deployed base, won't that make it that much harder to get non-interoperable modifications to the basic CLNP through the ISO? Is the ISO really going to be willing to obsolete the substantial investment made by all the vendors and users who have taken the path the ISO laid out? I fear that the future that Craig is wary of, in which pressures develop to have the Internet conform, is more likely than is sometimes seems. Noel From owner-Big-Internet@munnari.oz.au Mon Jul 6 04:59:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17948; Mon, 6 Jul 1992 05:00:00 +1000 (from owner-Big-Internet) Return-Path: Received: from usc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17938; Mon, 6 Jul 1992 04:59:55 +1000 (from estrin%caldera.usc.edu@usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA03422; Sun, 5 Jul 92 11:59:45 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA17856; Sun, 5 Jul 92 11:59:44 PDT Date: Sun, 5 Jul 92 11:59:44 PDT Message-Id: <9207051859.AA17856@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin%caldera.usc.edu@usc.edu To: smart@mel.dit.csiro.au Cc: big-internet@munnari.oz.au In-Reply-To: Bob Smart's message of Sun, 05 Jul 92 20:40:32 +1000 <9207051040.AA19449@manta.mel.dit.CSIRO.AU> Subject: Re: Nimrod (and bits of PIP): an interpretation. Reply-To: estrin@usc.edu For one approach to achieving thinning/compaction/abstraction (ie scaling), along with functionality of specialized routes, see RFC 1322 by Yakov Rekhter, STeve Hotz and myself. (I dont know who will yell at me the loudest if I refer to it as "an instantiation of Nimrod"; but since everyone is busy yelling about lots of things maybe this will go unnoticed...) From owner-Big-Internet@munnari.oz.au Mon Jul 6 05:43:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18764; Mon, 6 Jul 1992 05:43:49 +1000 (from owner-Big-Internet) Return-Path: Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18761; Mon, 6 Jul 1992 05:43:42 +1000 (from hwb@upeksa.sdsc.edu) Received: Sun, 5 Jul 1992 12:43:30 -0700 by upeksa.sdsc.edu (AIX/1.6) From: Hans-Werner Braun Message-Id: <9207051943.AA19817@upeksa.sdsc.edu> Subject: Re: Musings on the past few messages To: medin@nsipo.nasa.gov (Milo S. Medin) Date: Sun, 5 Jul 92 12:43:30 PDT Cc: iab@ISI.EDU, big-internet@munnari.oz.au, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov In-Reply-To: <9207042222.AA16204@dscs.arc.nasa.gov>; from "Milo S. Medin" at Jul 4, 92 3:22 pm Hey, Milo, besides the subject field, my note was really not targeted towards you, but in response to a great many comments I saw from several people. Sorry about the appearance. I just tried to be a little funny, I guess, and you are *such* a good victim for teasing comments. Especially with the thick skin you grew on the Internet and other farms. Y'know, I meant to use supernova, but then thought that'd stretch it... Besides, as you also allude to, we have a good history of collaborating and getting things done, and I expect that to continue, despite occasional arguments. After all, arguments are there for a reason. >I made no reference about them being "evil" and having the IAB be destroyed >nor was that my intention. I certainly was not advocating anarchy; that's >rather inconsistent with my political viewpoints in any case. I did not mean to imply that *you* said such things. Sorry for creating a misperception there. >This goal is in fact part of the problem. I said in my earlier note >that the IAB has no real authority; that it is an organization that >leads, not directs. H-W, I didn't think you disagreed with that. I >fully share your frustration with progress on moving ahead with projects >in the IETF. I have been involved in more than my share of headaches >in that area. However, what I have learned from this experience is >that the eventual IAB decision is not really what decides things. It >is in fact the debate on the issues that really decides things. It >is that debate, where the various burning issues are hammered out >between the R&D community, the vendors, and the users. It is >the debate in fact, where most of the community develops their viewpoints >on whether or not a particular approach is a good approach or bad approach, >and where people decide where to throw their development resources at. >Sometimes there isn't always consensus, but eventually the various >battles rage and productive solutions come out as implemented prototypes >and solutions. It's far from efficient, but has seemed to work pretty >well in the past. I am not disagreeing with your IAB comments here, and I can assure you that the IAB realizes them, but, if the IETF does not watch out, the same could apply to the IETF. Remember, we are at the threshold of a market driven environment. In principle, a bigger brother than the IAB could come and "just do it." Large scale phone companies, international PTTs and such, for example, as they discover that there is enough money in data networking worth their attention. A major point here is that the combination of the IETF and the IAB really has to deliver here, in order to survive. And to deliver before disasters happen. I am not telling you anything new here, as you know quite well that the IAB and the IETF are really in the same boat. We will start to have to more and more listen to market requirements. I know that's a hard sell to us Internet-engineers, but I am not sure we have a choice. >Now, I never believed or argued the IPv7 document advocated a US GOSIP or other >standard addressing standard for NSAP's. That was pretty clear. It >also appears that the checksum location and type is also up for grabs. >It appears that the proposal never really advances TUBA >specifically. In fact, many of the supporters of a CLNP approach >may not like the outcome of the proposed IPv7 process at all, since >it probably won't be interoperable with the OSI at all. The other >main point of my note was that given that we aren't really talking OSI >or even a common CLNP packet definition, the draft really confuses >people as to what it exactly was trying to say. When I discussed this >with HW on the phone, he thought that was a good point and that the >document needs to clarify this aspect. This way, marketing people >and others will not be able to exploit this unfairly. And we won't >have to deal with the aforementioned baroqueness of the current NSAP >allocation organizations. The Internet is a big business these days. >Perceptions are important, and they need to be considered. I still believe that you are making a good point here. In an area that can easily get confusing, and where religious and emotional overtones are quite present in the discussion. In any case, I think we have to realize that, as discussed earlier, this is not wholesale OSI. Also, CLNP has nothing to do with addresses. NSAP addresses are a completely different specification. CLNP defines just a packet format and the semantics attached to certain fields, *not* including the structure of addresses. There are a variety of reasons why we have to take CLNP into account, and I alluded to that in my earlier note. My personal opinion is that it looks like we have at least three medium term choices: 1. We could be compatible with CLNP. I.e., network-switch-wise, to create some "unified" world wide fabric, leaving many other details to be of end-end relevance only. That could end religions TCP/IP vs. OSI wars to a large extend. End-systems could use higher layer OSI or TCP/etc. as they see fit. Compatible still means using our own flavors for, e.g., addresses (and I think Ross Callon has explained before how to deal with ports), but may be we can get things somewhat transparent to global switching fabric and global (-ly distributed) network management. If that prooves unworkable: 2. We could make incompatible changes as the Internet community perceives necessary. We should forward our changes as shortcomings in ISO protocols to ANSI/ISO/whoever for their consideration, if only so we can claim later that we made a good faith effort not to create OSI-warfare, and that we seriously considered the options, and that our state of affairs is surpassing the one of ISO (after all, we have a network to take care of). If that fails as well: 3. We could still create our own protocol. We should still come up with a good and defensible rationale to be forwarded to ANSI/ISO/whoever, to have made a good faith effort to have considered the ISO-option, and explain why their approach is unworkable. Any of those alternative should help with the "eventual migration to ISO standard protocols," made so many times over the last many years. At least, whatever we will finally settle on, will be measured against the IAB draft statement, and not against IPv4, CIDR, C#, CNAP or so. As such, people have a blank sheet to work from, which really broadens the perspective, given the many years of experiences in the Internet community, for, e.g., what addresses of a world-wide scaled network should really look like. Hans-Werner From owner-Big-Internet@munnari.oz.au Mon Jul 6 06:04:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19055; Mon, 6 Jul 1992 06:04:11 +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 AA19047; Mon, 6 Jul 1992 06:04:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04196; Sun, 5 Jul 92 16:03:54 -0400 Date: Sun, 5 Jul 92 16:03:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207052003.AA04196@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: Nimrod (and bits of PIP): an interpretation. Cc: jnc@ginger.lcs.mit.edu A substantial piece of work! Things are a bit too hot on other fronts to devote full time to this, but a few quick comments, and some minor clarifictions of Nimrod issues. Provider oriented heirarchical addresses are not quite what Nimrod had in mind, but it's close. Nimrod addresses grow from the bottom up, and it's not *necessary* for you to have addresses which are *subsidiary* to provider X to be *attached* to provider X. This is a common misperception (you made the same basic one in some private mail I never got to answering when you assumed virtual machines would have addresses subsidiary to the physical machine they were in). There is nothing to stop you in either case from giving a name to a piece of the topology attached to a certain low level entity which is at the same level, or even, higher, in the topology. It doesn't have to be lower. To make this general statement concrete, think of the VM example. If the hardware machine is at a.b.p.x, there is nothing to say the virtual machines have to have addresses a.b.p.x.1, etc, etc. In fact, I would argue this is wrong. An interface is the lowest level thing there is; you can't have network topology *inside* interfaces. You *can* have topology *next* (i.e. attached) to an interface, so the best scheme would have the VM's be addressed as, say, a.b.q.1, etc, etc. Remember how Nimrod topology aggregation works; you (effectively) take a big map of the physical network, and draw a set of circles enclosing areas of the network. You then repeat the process recursively. However, there is no necessity that the nesting take any particular form, or that the circles enclose particular areas of the topology. I think you are confusing administrative issues of allocation (which are clearly eased by making addresses subsidiary), with the issues of what is important in topological abstraction from the routing calculations' point of view. Remember, aggregation is simply tuning that 2 part cost function I mentioned a while back! Addresses should defer to the topology, *not* the administration of address assigment! Using this framework, even if a provider which is currently enclosed in area a.p of the topology gets customer X, it does not have to follow that X's addresses are of the form a.p.y; they could easily be of the form a.q, or even b! In each case, the *map* would show a link between a.p and whichever way you decided to name the X aggregate. This would impose an extra cost on routing; e.g. in the form of an entity a.q which had to be tracked inside a, but it could also provide better routing to a.q. Addresses are not just a question of 'who plugs in to whom'; the connectivity map shows that. There are a number of reasons for separating the address and ID, not just mobile hosts, which simply offer the most appealing case for an example. My mind is pretty tired at the moment, but one I recall is multi-homed hosts, both onto different networks and onto the same network (e.g. the infamous dual-MAC dual-rail FDDI). The motivatiosn in this case are reliability and speed, and in both it's useful to know that the multiple network attachment point addresses correspond to the same 'host'. There are others, for example mobile processes, bu the complete list escapes me at the moment. Nimrod assumes (at least) two modes of routing. This is true, sort of, but you missed one possible optimization. (Recall that I havne't picked between possible optimizations in the Nimrod document, since you can't optimize until you've done the engineering.) One possible mode of operation (section 6.1) is neither source routed nor flow associated, but rather hop-by-hop, with a possible additional limited number of access classes. You can regard the "no brainer" route The 'no-brainer' stuff has to do with whether you accept the default map for both source routed traffic and flow related traffic, or take the effort to get one with more details to do your routign calculation on. (The HbH optimization noted above would, of course, have to use the default map). improved routing protocols and algorithms and thinning/compaction/ abstraction schemes to handle the huge amounts of information. However all that hard stuff is in the future, and I think we can understand the basics of Nimrod without that. Absolutely. I don't understand any of that stuff either; in large part it is research which is not yet done (and which I have no mental capability to do :-)! The whole point of Nimrod is to provide a framework in which we can deploy this stuff *trivially* as it becomes available. One thing is that I think the basic *protocols* can be done now; they would be the topology exchange and flow setup. However, since the algorithms are mostly *local* (as opposed to HbH routign architectures), they are easy to change incrementally (like TCP retrans algs; they changed while the protocol stayed the same). The router then forwards the packet across the Internet to its destination. To do this it must encapsulate or convert the packet to PIP(/whatever) format. Why do any of these? The endpoints are uniquely identified by the source and destination IP 'addresses', which can serve as cache tags for looking up the correct flow (which will contain the source and destination addresses, if the routers need that information for any reason). Just leave the packet as it is! Sure, for packets from unmodifed hosts, we may need to add a 'flow-id' as an option if we don't want all traffic between that pair to be part of the same flow, but why do anything more? (I know about unmodified routers; kill them off.) An important point about Nimrod is that it is only the first router Exactly. If you want to really speed up the process, you could have the routers wiretap the DNS traffic, so it doesn't have to take a separate query. In this case, however, the cure may be uglier than the disease! Meanwhile we can bring in hosts that talk the NewIP format. The more of these the less strain on your subnet router doing conversions. This is not the immediate first step to reduce strain; we modify the hosts to get the new style address from the DNS and stick it in outgoing packets (only first packet of a flow, of course). This is a relatively simple change to the IP layer which will have significant impact; a lot less work than changing every piece of code which knows the layout of the IP header! By the way we could say that IDs are 32-bit IP4-compatible unless the first 2 bits are 10. Hmm, similar to a though I had last night about where the ID's will come from in the existing 32 bit space. For *each* class A number we reclaim, we get 2^24, or 16 million, ID's! So, we give each continent a class A, and when one runs out, we give them another one. Meanwhile, we reclaim many already handed out A's. Noel From owner-Big-Internet@munnari.oz.au Mon Jul 6 06:32:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19522; Mon, 6 Jul 1992 06:32:18 +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 AA19519; Mon, 6 Jul 1992 06:32:08 +1000 (from craig@aland.bbn.com) Received: from port22.sc.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA16980; Sun, 5 Jul 92 16:31:44 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA09863; Sun, 5 Jul 92 13:30:33 PDT Message-Id: <9207052030.AA09863@aland.bbn.com> To: Lyman Chapin Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov Subject: re: IPv7 (CLNP) a mistake (reply to Lyman) Reply-To: Craig Partridge From: Craig Partridge Date: Sun, 05 Jul 92 13:30:33 -0700 Sender: craig@aland.bbn.com Lyman: I very much appreciate your note. However, I'm afraid I'm still not at all convinced. Noel and Bob Hinden have pointed out most of the items that concern me. I only want to add a couple of points about ISO and IETF/IAB process issues that still worry me deeply. Your note is very clear that the expectation is that the IAB/IETF process and ISO process will somehow work in concert. IAB/IETF will lead and ISO will follow. I'm deeply dubious. Yes it is now fashionable in the computing industry to do joint ventures with one's former competitors, but even if the intentions are pure, cultural clashes usually prevent success. (Few of the joint ventures have produced much). Further, if the IAB/IETF is forced to diverge from ISO, as apparently the IAB will if operational needs dictate, then it is unclear that CLNP will have provided any long-term benefits. We'll be revising our internet protocol just as we would with IP, except now the base format is CLNP. I'm left with the strong impression that the IAB has proposed to chose CLNP in the cheerful hope that it can lead ISO along, and that if the IAB fails in this goal, we'll be stuck with fixing yet another packet format that (for reasons Bob and Noel and others list) didn't fully solve our technical problems. Craig From owner-Big-Internet@munnari.oz.au Mon Jul 6 08:36:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21659; Mon, 6 Jul 1992 08:36:59 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21654; Mon, 6 Jul 1992 08:36:54 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA22241; Sun, 5 Jul 92 15:36:49 PDT Message-Id: <9207052236.AA22241@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au, ietf@isi.edu Subject: Future of IP: Making it Happen Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 Date: Sun, 05 Jul 92 15:36:48 -0700 From: Dave Crocker Folks, Recent events have triggered a mass of email about, for, and against various proposals and decisions concerning IP. I would like to encourage the community to keep in mind what leverage they, the community, have. The Internet is unusual by its degree of participation among academia/research, vendor, and customer/user constituencies. Each is essential. And in this community, action talks. If you agree with one point of view and disagree with others, do express your disagreement, but I suggest that it is far, far more important that you pursue your agreement, not just voice it. Various proposals have their own email lists. Join whatever ones are compatible with your opinions. (Of course, if you are really dedicated, you might also want to track the ones you don't agree with.) There will be some BOFs at the IETF. Go to them. As has been observed, proposals and specifications are useless unless they are implemented, tested and used. In particular, I would strongly urge the customer/user community to think about costs, training efforts, and operational impacts of the various proposals and PLEASE contribute those thoughts to the technical process. Dave From owner-Big-Internet@munnari.oz.au Mon Jul 6 09:20:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22623; Mon, 6 Jul 1992 09:20:56 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22619; Mon, 6 Jul 1992 09:20:54 +1000 (from smart@mel.dit.csiro.au) Received: from manta.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA19152 (5.65c/IDA-1.4.4/DIT-1.3 for ); Mon, 6 Jul 1992 09:20:52 +1000 Received: by manta.mel.dit.CSIRO.AU (4.1/SMI-4.0.1) id AA01003; Mon, 6 Jul 92 09:20:52 EST Message-Id: <9207052320.AA01003@manta.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: Nimrod (and bits of PIP): an interpretation. In-Reply-To: Your message of "Sun, 05 Jul 92 16:03:54 -0400." <9207052003.AA04196@ginger.lcs.mit.edu> Date: Mon, 06 Jul 92 09:20:50 +1000 From: Bob Smart > Provider oriented hierarchical addresses are not quite what Nimrod had >in mind, but it's close. Nimrod addresses grow from the bottom up, and it's >not *necessary* for you to have addresses which are *subsidiary* to provider X >to be *attached* to provider X. Recent arguments about entropy in CIDR suggest that provider oriented hierarchical addresses are the correct solution to avoid table blowout. That is from my interpretation of the PIP document, but I was claiming it was not incompatible with Nimrod. In fact it seems to follow from things the Nimrod doc says about addresses being correlated with routing. I don't quite grok the "circles" argument so if you have some other routing-oriented scheme my understanding will have to await a more comprehensive description. The point I was trying to make about the DNS is this: if addresses are more transient things than we are used to then there are potential problems with massive changes to the DNS. However if we design our new DNS RRs carefully then instead of a full address we will just have the lowest component of the address + the _name_ of the higher component. Then we can change higher components (e.g. change network provider) with a single DNS change. > Addresses should defer to the topology, *not* the >administration of address assignment! I would think that addresses deferring to topology is _exactly_ what you get with provider oriented hierarchical addresses. Whereas if the address is independent of how you attach to the topology then it can't defer to the topology. So I find your comment very confusing. > This would impose an extra cost on routing; e.g. in the form of an >entity a.q which had to be tracked inside a, but it could also provide better >routing to a.q. Addresses are not just a question of 'who plugs in to whom'; >the connectivity map shows that. I think you are saying here that the no brainer route derived from provider oriented hierarchical addresses may not be the best. Sure! Thats why PIP calls the address components routing hints. > > The router then forwards the packet across the Internet to its destination. > To do this it must encapsulate or convert the packet to PIP(/whatever) > format. > > Why do any of these? The endpoints are uniquely identified by the >source and destination IP 'addresses', which can serve as cache tags for >looking up the correct flow (which will contain the source and destination >addresses, if the routers need that information for any reason). Just leave >the packet as it is! Cache is a nice word here, very encouraging. Trouble is a cache entry is something you can lightly throw away in the knowledge that you can get it again any time from slower storage. How does an intermediate router do that? Also you can't just assume that src+dest address = 1 flow. If an application sets up a flow with 64Kb guaranteed bandwidth it doesn't want other packets between the same source and destination using that flow. I don't personally think that flows are valuable until you have a new packet format that reaches into the hosts. Much better initially to put addresses in every packet and keep no state in the routers. That's the way Internet routers are now and anything else has too large a research component. Well perhaps my little synthesis of everything-I-can-understand from PIP and Nimrod is sufficiently different to justify writing up as a separate proposal? Noel certainly hasn't convinced me its wrong. Bob Smart From owner-Big-Internet@munnari.oz.au Mon Jul 6 10:35:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24277; Mon, 6 Jul 1992 10:35:55 +1000 (from owner-Big-Internet) Return-Path: Received: from ray.lloyd.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24269; Mon, 6 Jul 1992 10:35:44 +1000 (from brian@lloyd.com) Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA03378; Sun, 5 Jul 92 17:35:23 PDT Date: Sun, 5 Jul 92 17:35:23 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207060035.AA03378@ray.lloyd.com> To: louie@ni.umd.edu Cc: lixia@parc.xerox.com, craig@aland.bbn.com, big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, road@lanl.gov In-Reply-To: "Louis A. Mamakos"'s message of Fri, 03 Jul 92 10:43:14 -0400 <9207031443.AA09329@sayshell.umd.edu> Subject: IPv7 (CLNP) a mistake Reply-To: brian@lloyd.com I agree, Louie. There is sufficient time to come up with a GOOD solution rather than just grabbing the first solution (CLNP). Adoption of the classless network address (CIDR) is likely to extend the lifetime of the existing 32-bit address for several more years. Technology advances rapidly and I am absolutely convinced that something better than CLNP can be devised in plenty of time before all the address space is consumed. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From owner-Big-Internet@munnari.oz.au Mon Jul 6 11:35:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25887; Mon, 6 Jul 1992 11:36: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 AA25878; Mon, 6 Jul 1992 11:35:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04895; Sun, 5 Jul 92 21:35:52 -0400 Date: Sun, 5 Jul 92 21:35:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207060135.AA04895@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: Nimrod (and bits of PIP): an interpretation. Cc: jnc@ginger.lcs.mit.edu Recent arguments about entropy in CIDR suggest that provider oriented hierarchical addresses are the correct solution to avoid table blowout. It is true that there is a strong relationship between what heirarchy in DV systems and LS does for you. In either system, increasing the scope across which an entity is visible as a separate destination increases the cost of the routing overhead. It's also quite true that in both LS and DV systems you can take entities which are attached to provider X and have them show us as separate entities from X to the routing. However, the point I was trying to make is that it's not necessary (and not always a good idea) to address something through a provider. Also, everyone needs to remember clearly that there are *no* routing tables in Nimrod; just maps. I would think that addresses deferring to topology is _exactly_ what you get with provider oriented hierarchical addresses. Not necessarily. It all depends on how the site is hooked up, etc, etc. E.g. if an organization is hooked to a U.S. only provider, but also has inernal links to European locations, and is also not a transit net, you may introduce routing inefficiencies if it is allocated addresses from the provider 'branch'. Yes, in many cases (e.g. all singly connected sites), as noted above, an address from the provider 'branch' will provide optimal routing. However, let's be careful not to confuse address *administration* and *allocation* with address *topology representation*. This is not stated in a clear way; sorry, that's the best I can manage. Another way to look at it is to say that you can draw the nested circles on the map in an arbitrary way, not related to who owns the links and switches in the network the map represents. I.e. you could draw a circle around a bunch of switches, half of which are owned by one provider and half another, if that's what provided the minimal value to the routing sum of costs function. Address allocation (i.e. getting a number from someone) and address use for abstraction are often very closely related (e.g. the provider based addressing), and it is easy to i) confuse them in your mind, as concepts, and ii) confuse them in practise. Remember, the real point with abstraction is to minimize that sum of costs function, which may conflict with the desire to assign addresses along organization boundaries. I think you are saying here that the no brainer route derived from provider oriented hierarchical addresses may not be the best. Well, I think this is sort of what I am thinking. I was harking back to the point I tried to make above; I think many people too tightly couple address allocation and address use. Use of a.q is both easy and perfectly legitimate; whether you do it or not depends on what it does for you. Trouble is a cache entry is something you can lightly throw away in the knowledge that you can get it again any time from slower storage. You're right, it isn't a good word. I was thinking cache since it only contains actively used info, and since it is accesses through a tag. Also you can't just assume that src+dest address = 1 flow. If an application sets up a flow ... Yes, I think I alluded to maybe needing a flow identifier in some cases. Clearly, this is an example of another case which would need a flow identifier in the data packets. I see I forgot to address this in the Nimrod document. Oh well, can't cover all the bases; it was getting horrendously long already anyway! I don't personally think that flows are valuable until you have a new packet format that reaches into the hosts. Much better initially to put addresses in every packet and keep no state in the routers. Well, people who don't like long addresses in packets might not agree. It also means we'd have to modify the hosts to do this if you want to extend the address size anytime soon. Why are people *so* hung up on stateless routers? Routers have per- host state now! What do you think an ARP translation table is? It's just state that happens to be easy to reload if you lose it... If I wasn't so tired I could probably come up with more examples. Nimrod flow state is almost as easy to discard; it is not *critical* or unrecreatable state. I think we are thinking roughly the same things here as far as abstraction/aggregation goes, but it's sometimes hard to tell, as I think in terms of this aggresively map/non-HbH view of the world which is quite different from most people's view of routing. Noel From owner-Big-Internet@munnari.oz.au Mon Jul 6 13:49:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29028; Mon, 6 Jul 1992 13:49:46 +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 AA29015; Mon, 6 Jul 1992 13:49:34 +1000 (from vjs@rhyolite.wpd.sgi.com) Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for big-internet@munnari.oz.au id AA22248; Sun, 5 Jul 92 20:49:28 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:big-internet@munnari.oz.au id AA04165; Sun, 5 Jul 92 21:49:25 -0600 Date: Sun, 5 Jul 92 21:49:25 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9207060349.AA04165@rhyolite.wpd.sgi.com> To: big-internet@munnari.oz.au Subject: re: IPv7 Checksum > braden@ISI.EDU writes: > > So, Jon, should IPv7 use the IPv4 checksum, or can we come up with a > different checksum that also provides byte swap protection but is > easier/faster to compute than the 8473 checksum? > > Bob The perhaps excessive simplicity of the IPv4 checksum has some advantages: (1) relatively easy to do in hardware at gigabit speed. (2) easy to do parts of the packet in various places e.g. compute the checksum of the data while copying to or from user buffers, and later combine that checksum with the psuedo-header I'm told by people who looked at silicon to do it, that the Fletcher checksum is a lot more difficult to make fast. They gave up and picked a different checksum for some flavors of XTP. The Fletcher checksum does not easily "distribute" over concatenation. It's possible, but is so much more difficult that (2) is probably not a useful idea, which probably has non-trivial effects on all of the popular ideas for making TCP fast. The speed with which the TCP/IP checksum can be calculated makes it possible to get most of 100Mbit/sec through TCP/IP/FDDI with current, commercial workstations with usual hardware, not just Cray's. That would seem to me rather more difficult with the Fletcher checksum. All of this applies mostly to TCP instead of IPv-whatever. Still, wouldn't it be unsanitary to have different checksum algorithms in new-IP and new-TCP? (TCP also changes, doesn't? At least a new psuedo-header for the new addressing? Would the OSI religious objections to the psuedo-header have larger effects? Would TCP ultimately be replaced by TP4?) You'd think that byte-swap concerns would be more applicable to the bulk of the packets, to the data instead of just the headers. Vernon Schryver, vjs@sgi.com P.S. I know of one BSD based implementation where the IP checksum in the common, non-option case has been in-lined into a single expression. That saves no more than a few dozen cycles--altho 90% of the whole IP checksum cost. It would be less attractive with the Fletcher checksum. From owner-Big-Internet@munnari.oz.au Mon Jul 6 17:03:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04361; Mon, 6 Jul 1992 17:04:05 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04344; Mon, 6 Jul 1992 17:03:59 +1000 (from billw@cisco.com) Received: by cider.cisco.com; Mon, 6 Jul 92 00:03:32 -0700 Date: Mon, 6 Jul 92 0:03:32 PDT From: William "Chops" Westfield To: karl@TGV.COM Cc: dino@cisco.com, braden@ISI.EDU, bsimpson@angband.stanford.edu, ietf@ISI.EDU, big-internet@munnari.oz.au Subject: Re: why 160-bit addresses are daft.... In-Reply-To: Your message of Sat, 4 Jul 92 11:39:07 PDT Message-Id: We ought to put the checksum at the end and make it such that it can be computed by I/O hardware as the packet is squeezed out the interface. This is arguable for header checksums. For example, the IP header checksum is as much a check for buggy software as for transmission errors, and using hardware checksumming so that the checksumis "always correct" might not be a good idea. Of course, if you do all the routing in hardware too, you might as well. The Fletcher Checksume would be more problematic if it doesn't support "incremental" calculation (in IP, since all you update is the TTL, you don't need to fully checksum the new header...) BillW From owner-Big-Internet@munnari.oz.au Mon Jul 6 17:12:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04606; Mon, 6 Jul 1992 17:12:25 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04603; Mon, 6 Jul 1992 17:12:20 +1000 (from billw@cisco.com) Received: by cider.cisco.com; Mon, 6 Jul 92 00:12:11 -0700 Date: Mon, 6 Jul 92 0:12:11 PDT From: William "Chops" Westfield To: braden@ISI.EDU (Bob Braden) Cc: bsimpson@angband.stanford.edu, ietf@ISI.EDU, big-internet@munnari.oz.au Subject: Re: why 160-bit addresses are daft.... In-Reply-To: Your message of Fri, 3 Jul 1992 15:03:12 -0700 Message-Id: without acceptable header compression, IPv7 would be a loser over low bandwidth paths. "Header compression" as it exists now is largely a TCP level thing. It ought to be trivial to modify existing software to support any network level protocol, including CLNP. Furthermore, the compressed datagram size is independent of the size of the network level protocol. If you can live with header compression, then 160 bit addresses are a moot point. Now, the amateur packet radio people may have quite good reasons for not wanting to use header compression (header compression only buys you anything when the link is mostly reliable), but I think these are generally fixed by runninga reliable link layer instead. BillW From owner-Big-Internet@munnari.oz.au Mon Jul 6 20:54:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09886; Mon, 6 Jul 1992 20:54:19 +1000 (from owner-Big-Internet) Return-Path: Received: from [132.151.1.35] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09883; Mon, 6 Jul 1992 20:54:13 +1000 (from vcerf@NRI.Reston.VA.US) Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05851; 6 Jul 92 6:50 EDT To: Bob Hinden Cc: Lyman@bbn.com, big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu Subject: Re: IPv7 == CLNP or CLNP+ ? In-Reply-To: Your message of "Sun, 05 Jul 92 11:16:53 PDT." <9207051816.AA16295@b5mail.Eng.Sun.COM> Date: Mon, 06 Jul 92 06:50:53 -0400 From: vcerf@NRI.Reston.VA.US Message-Id: <9207060650.aa05851@IETF.NRI.Reston.VA.US> Bob and others on these distribution lists, I have just returned from a trip to Africa and discovered that the Internet community has found its own way to celebrate Independence Day in the US (with fireworks on the network). I think I have about 1200 messages accumulated which need to be read (groan). Here's a personal perspective on the vigorous discussion triggered by the recent IAB message concerning IPv7: 1. We clearly do need to take action to deal with the routing information explosion and the predictable exhaustion of addresses in the IPv4 format. 2. We want very much to continue to evolve the Internet functionality and, in particular, need to deal with real-time, multi-cast, mobile hosts (and nets?!), sophisticated routing policy expression, and so on. 3. One way to achieve intense evaluation of a proposal is to posit it as a starting point and consider the implications of its adoption. The CLNP specification is proposed as the starting point for the IPv7 both to lend concreteness to the ensuing discussion (I hope this does NOT result in concrete brickbats being hurled through MIME mail....!!) and to take advantage of whatever has already been learned by use of this particular packet format. I am persuaded that the growth problems we face are real and imminent and that we must make firm plans as quickly as we can to allow time for all the deployment and engineering work to be done. If, in the discussions which follow, we focus on whether the CLNP format can serve or must change (and in what way), we ought to be able to sort out the viability of starting with CLNP versus starting from something else. Please note that CLNP started with IP4, so the key question is whether we can define IPv7 based on CLNP or whether there is strong technical reason to start at another point in the potential solution space. What has been published by the IAB is a plan, not a final decision. For my part, I hoped that making a concrete proposal to start with CLNP format would focus the discussion and generate considered comment. I have certainly not been disappointed in the latter regard!! We may learn from the discussions which follow that something other than CLNP is a far superior starting point or we may discover that IPv7 can start there with considerable utility. The important thing, in my view, is that we acknowledge the need to move ahead rapidly to make our technical plans - any solutions to scaling will be a great challenge to implement and deploy before we are overcome with "success". Vint From owner-Big-Internet@munnari.oz.au Tue Jul 7 00:00:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13603; Tue, 7 Jul 1992 00:00:48 +1000 (from owner-Big-Internet) Return-Path: Received: from mbunix.mitre.org by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13579; Tue, 7 Jul 1992 00:00:31 +1000 (from wheeler@jeckle.mitre.org) Received: from jeckle.mitre.org by mbunix.mitre.org (911016.SGI/4.7) id AA08970; Mon, 6 Jul 92 10:00:02 -0400 Posted-From: The MITRE Corporation, Bedford, MA Received: from localhost by jeckle (4.1/SMI-4.1) id AA17284; Mon, 6 Jul 92 09:58:26 EDT Message-Id: <9207061358.AA17284@jeckle> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU Subject: Re: IPv7 == CLNP or CLNP+ ? In-Reply-To: Your message of Sun, 05 Jul 92 14:57:48 -0400. <9207051857.AA03985@ginger.lcs.mit.edu> Date: Mon, 06 Jul 92 09:58:25 -0400 From: wheeler@jeckle.mitre.org > Given this deployed base, won't that make it that much harder to get > non-interoperable modifications to the basic CLNP through the ISO? Is the ISO > really going to be willing to obsolete the substantial investment made by all > the vendors and users who have taken the path the ISO laid out? It sure will be. Just look at '88 X.400 vs. '84 X.400. Brien From owner-Big-Internet@munnari.oz.au Tue Jul 7 00:09:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14678; Tue, 7 Jul 1992 00:09:44 +1000 (from owner-Big-Internet) Return-Path: Received: from gateway.bnr.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14674; Tue, 7 Jul 1992 00:09:35 +1000 (from FORTINP@BNR.CA) Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA05643; Mon, 6 Jul 92 10:07:52 -0400 Message-Id: <9207061407.AA05643@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 4915; Mon, 06 Jul 92 10:06:02 EDT Date: 6 Jul 92 10:08:00 EDT To: From: Pierre (P.) Fortin Subject: Big Picture (was: Class 'E' - Extending the IP address) Sender: Pierre (P.) Fortin Let me see if I've got this straight... [In all the following figures, ABCDE = assigned and abcde = unassigned network addresses.] (Assuming various proposals were adopted;) The Class structure is taking us recursively though a n/2 process of assigning addresses resulting in the following picture (from RFC1166): 0 1 2 3 01234567890123456789012345678901 000x 0aAAaAAAAA$AAAAAAaAAAAAAaAAAAAAA [$ = 10.0.0.0] 001x aaaAAaaaaAAAAaA@aaaaaaaaaaaaaaaa [@ = my Class A (47)] 010x aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 011x aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaL [L = loopback] (mainly 127.0.0.1) 100x BBBBBBBBBBBbbbbb [<...> gleaned from RFC1335] 101x bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 110x Cccccccccccccccc 1101 ################ C# 1110 Dddddddddddddddd 11110 xxxxxxxx length = x[64|92|128|160|...] 11111 eeeeeeee Simplified further: AAAaaaaaBBbbc#de address space allocated ??? =- . address space used It's bad enough the bulk of the 2**32 addresses have been wasted; now I'm hearing (er... reading) proposals to "punch a hole in the bottom of the barrel"... C'mon!!! Let's get real! :^\ Frankly, I feel very much like an address "hog" when I look at this picture. Especially when I consider that I have ~30,000 hosts spread over ~600 subnets for an average of 50 per... (less than 0.2% used!!!) If the Internet has ~900,000 connected hosts, that's only 0.02% used. WHOA! I'm already making 10x better use of my Class A address space than the rest of the Internet... that makes me feel [a little] better. Seriously, while some of my previous postings were obviously premature, I *still* have a problem buying into the premise that we are running out of address space. The real problem, as I see it, is that the address space has been **squandered**... In my case, I followed RFC950 to subnet network 47 at 12 & 12 bits. Given what we [at BNR/NT] now know about squeezing blood out of a stone, it *is* possible to have 600-800+ high-performance/high-traffic devices on a single subnet while still operating relatively safely in terms of broad-/multi-cast issues. [Done here using Multi-Port Bridges (MPB) with FDDI backbones. I have not yet made use of un-numbered serial links which would reduce our subnet "waste" by ~150. So, assuming: a. <1022 devices per subnet b. <510 subnets corporately we COULD have gotten along with 2**19 addresses (524,288) for a 5.7% address utilization. Then again, with aggregation (through variable- length subnet masks and RFC1219), we could have done just fine with 2**18 (9 & 9 split) addresses (262,144) for 11.4% utilization and room to grow; but this is HINDSIGHT... Looking at the picture differently: actual Class A: 16,777,216 or 0.3906% or 1/256 of the Internet classless 2**19: 524,288 or 0.0122% or 1/8192 classless 2**18: 262,144 or 0.0061% or 1/16384 Differently again (using 2**15 as "in-use" addresses on my network 47): actual Class A: 99.8% WASTED!! classless 2**19: 93.8% WASTED!! classless 2**18: 87.5% WASTED. Remember from above that my address utilization is 10x BETTER than the current Internet... and I _still_ feel TERRIBLE about this situation. With the current state of "secure gateway" technology, there is NO WAY that my Class A network will be visible to the Internet; and this will likely be so beyond any actual deployment of "solutions" being discussed here. So, feel free to consider network 47 "free space" for the purposes of researching new solutions. I wonder how many other Class A networks are similarly hidden? Any Class A address owners care to give their views? Especially those who are not visible to the Internet... With my [hidden] Class A network, regardless of how many gateways I have to the real Internet, I feel is is *MY* responsibility to get traffic from *anywhere* on my network to an Internet gateway for external access. As a result, I find the use of several existing Class C addresses MORE than adequate for Internet access. Of course, this is possible through our requirement that internal users logon to a secure gateway to then have access [via a single Class C address] to the Internet. In other words: other than horsepower limits (CPU and links), our users appear to the Internet as one of two hosts at a couple of gateway locations (FOUR addresses on TWO Class C nets to the Internet). Each user only really adds to the "port" numbers used. Now I really feel like I'm wasting Internet address space... Heck, with this scheme, I would think that a *portion* of my Class C gateway networks would be sufficient. They are subnetted 4 and 4 with a couple of gateway hosts each... I suppose that having a more transparent gateway would be desired by my users; but having an internal-Class-A to external-Class-C-plus-port translation gateway _might_ be satisfactory (gotta *think* about this one some more). Random thoughts: --------------- Looking at the 2**32 address space re-divided into two 2**31 spaces and overlapped; like this: 0 1 2 3 01234567890123456789012345678901 x00x <--------------A&B-------------> [assuming light Class A use] x01x <--------------A&b-------------> x10x <-----a&C------><-----a&C#-----> x11x <-----a&d------><-----a&e------> I might find it [a little] easier to accept all "the sky is falling" arguments. If I next [possibly naively] believe that all the visible Class A networks *could* individually fit into Class B spaces using *existing* subnetting schemes, the ENTIRE (less 0 & 127) existing Class A space would be free... at a cost of very few Class B addresses. Hmmm... I wonder how everyone would feel about 2**31 (2,147,483,648) addresses within which we could investigate new allocations, addresses, IDs and routing mechanisms? ...without otherwise destroying the current [bad as it is perceived] infrastructure. Just one bit to check: 0 = research traffic 1 = "normal" user traffic Let your mind w[a/o]nder... :^) -EndOfRandomThoughts- Just trying to help. Really... Cheers, Pierre PS: Regardless of what the outcome is within these discussions, there are still the issues of WHAT we are telling new users to do via existing RFCs. It's one thing to have a solution, but quite another to make sure it is not similarly scr*wed by current RFCs/thinking... From owner-Big-Internet@munnari.oz.au Tue Jul 7 00:12:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14736; Tue, 7 Jul 1992 00:12:46 +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 AA14733; Tue, 7 Jul 1992 00:12:41 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA19112; Mon, 6 Jul 92 07:12:36 -0700 Received: by sneezy (5.57/ULTRIX-4.2-3)id AA10687; Mon, 6 Jul 92 10:12:34 -0400 To: big-internet@munnari.oz.au Subject: Checksum in CLNP In-Reply-To: <9207032248.AA12287@regal.cisco.com> References: <9207032248.AA12287@regal.cisco.com> X-Mailer: Poste 2.0B3 From: Dave Oran Date: Mon, 6 Jul 92 10:12:14 -0400 Message-Id: <920706101214.15893@sneezy.lkg.dec.com> Encoding: 35 TEXT, 5 TEXT SIGNATURE I noticed some comments on the CLNP checksum (Fletcher), its difficulty of computation relative to XOR, vertical parity, etc. and I think there is something people might be missing in this area. The CLNP checksum can be turned off. By using ones complement arithmetic, the Fletcher checksum has a representation (plus zero) which means "no checksum computed". Thus a simple zero test during packet parsing can bypass the whole thing. If we in fact go forward with IPv7 based on CLNP, people might want to take the following into account: 1. When using TCP/UDP ala TUBA, the TCP checksum is still present and carries end-to-end protection. 2.When using TP4, the TP4 checksum, if turned on, provides end-to-end protection. 3. The CLNP checksum only covers the header, not the data, and hence gives no additional end-to-end coverage. From this it can be seen that the only protection the CLNP checksum gives is against misdelivery due to smashed addresses in the header. This was in fact the motivation for including it in the protocol, AND making its generation by a sender optional. If there is confidence in the other forms of error coverage to reject misdelivered packets, then the CLNP checksum is of minimal value and could be mandated as turned off in the Internet profiles for IPv7. Small point, compared to the cosmic issues being zinged around this list, but I felt compelled to mention it anyway. Cheers, Dave. David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@sneezy.lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Tue Jul 7 00:18:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14842; Tue, 7 Jul 1992 00:18:30 +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 AA14839; Tue, 7 Jul 1992 00:18:25 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA19422; Mon, 6 Jul 92 07:18:20 -0700 Received: by sneezy (5.57/ULTRIX-4.2-3)id AA10761; Mon, 6 Jul 92 10:18:18 -0400 To: mo@gizmo.bellcore.com Subject: Re: why 160-bit addresses are daft.... In-Reply-To: <9207032322.AA02575@bellcore.bellcore.com> References: <9207032322.AA02575@bellcore.bellcore.com> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.0B3 From: Dave Oran Date: Mon, 6 Jul 92 10:18:12 -0400 Message-Id: <920706101812.15893@sneezy.lkg.dec.com> Mike O'Dell writes... > Sorry, but when I read the document is said that IPv7 would use 20-byte > addresses. Variable length addresses make the router folks nutso > (and with good cause). > I'm sorry, but I have to disagree with you about the effect on routers of variable length addresses. With longest-match forwarding and patricia algorithms for forwarding table lookup, modern routers are effectively treating fixed-length addresses as variable length anyway. From owner-Big-Internet@munnari.oz.au Tue Jul 7 01:01:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15962; Tue, 7 Jul 1992 01:02:12 +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 AA15954; Tue, 7 Jul 1992 01:01:55 +1000 (from craig@aland.bbn.com) Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA12277; Mon, 6 Jul 92 11:01:24 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA12504; Mon, 6 Jul 92 08:00:23 PDT Message-Id: <9207061500.AA12504@aland.bbn.com> To: William Chops Westfield Cc: ietf@isi.edu, big-internet@munnari.oz.au Subject: checksums (why 160-bit addresses are daft...) Reply-To: Craig Partridge From: Craig Partridge Date: Mon, 06 Jul 92 08:00:22 -0700 Sender: craig@aland.bbn.com Bill: Just FYI... Fletcher checksums can be incrementally updated. (There's a paper by Narkassis on the subject in Oct89 CCR I believe). I agree with you that trailer checksums aren't worth the bother. Craig ut in the end, the IETF can do what it wants. Now, if you want maximum interoperability, that's a good reason to at least ask ISO not to use the same code point for the CLNP option, and to treat the PROTO option as a type III (pass thru). Also, I think the copyright issue is a herring; you could always have a requirements or profile document that tells you what and how to use the CLNP document. From owner-Big-Internet@munnari.oz.au Tue Jul 7 01:08:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16156; Tue, 7 Jul 1992 01:08:54 +1000 (from owner-Big-Internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16152; Tue, 7 Jul 1992 01:08:45 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 9982; Mon, 06 Jul 92 17:07:47 MET Received: by DEARN (Mailer R2.08) id 2194; Mon, 06 Jul 92 17:07:46 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6586 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:05:59 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7773; Mon, 06 Jul 92 17:04:48 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:04:46 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07063-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:06:16 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <01888-0@survis.surfnet.nl>; Fri, 3 Jul 1992 23:55:26 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <10278-0@relay.surfnet.nl>; Fri, 3 Jul 1992 23:55:15 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04963; 3 Jul 92 17:52 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04955; 3 Jul 92 17:52 EDT Received: from venera.isi.edu by NRI.Reston.VA.US id aa22111; 3 Jul 92 17:53 EDT Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Fri, 3 Jul 1992 14:44:54 -0700 Received: by braden.isi.edu (5.65c/4.0.3-4) id ; Fri, 3 Jul 1992 14:42:56 -0700 Return-Path: Date: Fri, 3 Jul 1992 14:42:56 -0700 From: braden@isi.edu Posted-Date: Fri, 3 Jul 1992 14:42:56 -0700 Message-Id: <199207032142.AA05142@braden.isi.edu> To: BSMTP Subject: re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Sender: owner-mod-ietf@searn.sunet.se In short we will adopt CLNP (an ISO protocol); we wish to be "functionally and syntactically" compatible and to "converge" with OSI; and want to be able to make "changes ... necessary for successful, deployment, operation, and evolution of IPv7." If we want to make changes and still be compatible with and converge with OSI, we'll have to convince ISO to go along, which means we have to work in the ISO standards process. So we've bought into the ISO process (for the network layer). Craig Craig, An argument that came up repeatedly in IAB discussions was the objection that adapting (note the "a") CLNP was a case of trying to have our cake and eat it too. Well, yes. And I believe we can. If and where CLNP does not work, let's fix it. There is nobody -- except ourselves -- who can stop us from succeeding. In the quotation you cite, convergence with OSI is clearly labelled as a long-term goal, not a requirement for IPv7. The primary requirement for IPv7 is to work in the global Internet. We do not have to ask anyone's permission. I think it also says that the IAB/IETF should adopt an address format appropriate for the Internet. A lot of us share the suspicion that this will NOT be any of the existing NSAP formats. How about real-time? My view is that real-time is still research. It's coming, but we have to expand the address space on a shorter timeframe. We don't have enough faith in the CIDR approach to bet our Internet on it. I hope that replacing the 60 byte limit on IP headers with a 254 byte limit will help us to do initial real-time work, using options. How about multicasting? The document says (clearly, I hope) that there must be no regression of functionality, and it specifically mentions multicast. It was my understanding that CLNP multicast along the IP multicast model was a done deal, except for a logjam created by the OSI standards process. That logjam is irrelevant to the IETF. Let's do it. Above all, "Don't panic!" Bob. From owner-Big-Internet@munnari.oz.au Tue Jul 7 01:19:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16418; Tue, 7 Jul 1992 01:19:42 +1000 (from owner-Big-Internet) Received: from MITVMA.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16415; Tue, 7 Jul 1992 01:19:33 +1000 (from @mitvma.mit.edu:owner-mod-ietf@searn.sunet.se) Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2) with BSMTP id 2273; Mon, 06 Jul 92 11:19:01 EDT Received: from FRORS12.BITNET by MITVMA.MIT.EDU (Mailer R2.08 R208004) with BSMTP id 2605; Mon, 06 Jul 92 11:18:57 EDT Received: by FRORS12 (Mailer R2.08 R208004) id 4998; Mon, 06 Jul 92 17:16:14 EDT Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6620 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:12:26 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7810; Mon, 06 Jul 92 17:07:07 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:07:04 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07281-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:08:20 +0200 Received: from hearnvax.nic.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <00300-0@survis.surfnet.nl>; Mon, 6 Jul 1992 12:56:44 +0200 Received: from IETF.nri.reston.VA.US (132.151.1.35) by HEARNVAX.nic.SURFnet.nl with PMDF#10216; Mon, 6 Jul 1992 12:57 MET Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05860; 6 Jul 92 6:51 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05856; 6 Jul 92 6:50 EDT Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa24550; 6 Jul 92 6:52 EDT Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05851; 6 Jul 92 6:50 EDT Return-Path: Date: Mon, 06 Jul 92 06:50:53 -0400 From: vcerf@NRI.Reston.VA.US Subject: Re: IPv7 == CLNP or CLNP+ ? In-Reply-To: Your message of "Sun, 05 Jul 92 11:16:53 PDT." <9207051816.AA16295@b5mail.Eng.Sun.COM> To: BSMTP Cc: Lyman@bbn.com, big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu Message-Id: <9207060650.aa05851@IETF.NRI.Reston.VA.US> X-Envelope-To: huizer@SURFNET.NL Sender: owner-mod-ietf@searn.sunet.se Bob and others on these distribution lists, I have just returned from a trip to Africa and discovered that the Internet community has found its own way to celebrate Independence Day in the US (with fireworks on the network). I think I have about 1200 messages accumulated which need to be read (groan). Here's a personal perspective on the vigorous discussion triggered by the recent IAB message concerning IPv7: 1. We clearly do need to take action to deal with the routing information explosion and the predictable exhaustion of addresses in the IPv4 format. 2. We want very much to continue to evolve the Internet functionality and, in particular, need to deal with real-time, multi-cast, mobile hosts (and nets?!), sophisticated routing policy expression, and so on. 3. One way to achieve intense evaluation of a proposal is to posit it as a starting point and consider the implications of its adoption. The CLNP specification is proposed as the starting point for the IPv7 both to lend concreteness to the ensuing discussion (I hope this does NOT result in concrete brickbats being hurled through MIME mail....!!) and to take advantage of whatever has already been learned by use of this particular packet format. I am persuaded that the growth problems we face are real and imminent and that we must make firm plans as quickly as we can to allow time for all the deployment and engineering work to be done. If, in the discussions which follow, we focus on whether the CLNP format can serve or must change (and in what way), we ought to be able to sort out the viability of starting with CLNP versus starting from something else. Please note that CLNP started with IP4, so the key question is whether we can define IPv7 based on CLNP or whether there is strong technical reason to start at another point in the potential solution space. What has been published by the IAB is a plan, not a final decision. For my part, I hoped that making a concrete proposal to start with CLNP format would focus the discussion and generate considered comment. I have certainly not been disappointed in the latter regard!! We may learn from the discussions which follow that something other than CLNP is a far superior starting point or we may discover that IPv7 can start there with considerable utility. The important thing, in my view, is that we acknowledge the need to move ahead rapidly to make our technical plans - any solutions to scaling will be a great challenge to implement and deploy before we are overcome with "success". Vint From owner-Big-Internet@munnari.oz.au Tue Jul 7 02:43:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18666; Tue, 7 Jul 1992 02:43:44 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207061643.18666@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18660; Tue, 7 Jul 1992 02:43:34 +1000 (from lyman@BBN.COM) From: "Lyman Chapin" Subject: Re: IPv7 (CLNP) a mistake To: Bob.Hinden@eng.sun.com Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU, Lyman@munnari.oz.au In-Reply-To: <9207051855.AA16473@b5mail.Eng.Sun.COM> Date: Mon, 6 Jul 92 11:55:11 EDT Mail-System-Version: >Date: Sun, 5 Jul 92 11:55:54 PDT >From: Bob.Hinden@eng.sun.com (Bob Hinden) >To: "Lyman Chapin" >Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, > ietf@ISI.EDU >Subject: Re: IPv7 (CLNP) a mistake > >Lyman, > >In your message to Craig you said: > >>CLNP as IPv7 is not intended to be any improvement on IP with respect to new >>Internet applications (including voice and multimedia) - it is intended only >>to stave off the ROAD problems, while research proceeds on a genuinely "new" >>internet protocol. The IAB doesn't believe that it is wise or prudent to >>place such a heavy bet on CIDR (which may or may not give us "enough" breathing >>room, depending on a lot of factors that are difficult to predict accurately > >I agree with you assessment of CIDR [we do agree on some things :-) ], >but do not understand how the IPv7 proposal solves the Routing >Information Explosion problem, defined (in section 1.1) as one of the two >major scaling problems facing the internet. I don't see any relief for >this problem until CLNP has very widespread deployment in hosts and >routers. I don't think the current routing infrastructure will last long >enough for this to be a viable approach alone. > >In discussions I have had with Ross Callon, the author of the Simple CLNP >proposal, he agreed that we need something to keep the internet going >until CLNP can be widely deployed. The current IPv7 proposal does not >address this. I think it is a major shortcoming. > >Bob > > Bob, This is a good point, and one on which the IAB proposal should be much clearer. CLNP doesn't by itself solve the routing information explosion problem; it does, however, come with a tool for solving that problem (the CLNP addresses are not just larger, they are designed to permit much more flexibility in arranging hierarchies to support aggregation of routing information). I suspect that figuring out how to support useful aggregation based on CLNP addresses is equivalent to figuring out how to support it based on any other addressing scheme - and that it's a hard problem. - Lyman From owner-Big-Internet@munnari.oz.au Tue Jul 7 02:52:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18838; Tue, 7 Jul 1992 02:52:49 +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 AA18835; Tue, 7 Jul 1992 02:52:41 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA09550 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Mon, 6 Jul 1992 12:52:24 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Mon, 6 Jul 1992 12:52:24 -0400 Message-Id: <199207061652.AA45613@home.ans.net> To: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu Subject: Messages on IPv7 In-Reply-To: (Your message of Mon, 06 Jul 92 06:50:53 D.) <9207060650.aa05851@IETF.NRI.Reston.VA.US> Date: Mon, 06 Jul 92 12:52:17 -0500 From: Phill Gross Folks, Let me suggest that we restrict all following messages on IPv7 to a single mailing list. For comments on the IAB announcement (either criticism or support), please send to the ietf@isi.edu. For specific technical comments on any next generation Internet level protocol (eg, IPv7, IPAE, EIP, PIP, Nimrod, etc), please send to the big-internet@munnari.oz.au. In the case where you want to include technical objections or support in your comments on the IAB announcement, please try to briefly state the case in the message to the IETF list, and then follow-up in more detail on the Big-Internet list. Please delete ROAD, IAB, and IESG from all future messages. Let's assume anyone on those 3 lists who wants to follow any of these discussions should subscribe to either or both the IETF and Big-Internet lists. Thanks, Phill From owner-Big-Internet@munnari.oz.au Tue Jul 7 02:56:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18993; Tue, 7 Jul 1992 02:57:01 +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 AA18971; Tue, 7 Jul 1992 02:56:45 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA00657; Mon, 6 Jul 92 09:55:47 PDT Date: Mon, 6 Jul 92 09:55:47 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9207061655.AA00657@saffron.acc.com> To: J.Crowcroft@cs.ucl.ac.uk, braden@ISI.EDU Subject: Re: IPv7 Checksum Cc: big-internet@munnari.oz.au >> So, Jon, should IPv7 use the IPv4 checksum, or can we come up with a >> different checksum that also provides byte swap protection but is >> easier/faster to compute than the 8473 checksum? Jon, Bob: Here's a suggestion; I think it provides what you're looking for except for bytes of all zeroes. You'll recognize it as deriving from XNS IDP, which uses the same algorithm on 16 bit words. I use an operator ROTATE_LEFT(value,n). In C, that would be calculated as MASK & ((value << n) | (value >> (WORD_SIZE - n))) In most machine languages, there is a ROTATE_LEFT instruction, and I would assume that folks would use it. I use '+' to mean a one's complement sum. unsigned char octet_checksum (octets, number_of_octets) unsigned char *octets; int number_of_octets; { unsigned char sum = 0; while (--number_of_octets >= 0) sum = ROTATE_LEFT (sum + *octets++, 1); return sum; } In 680X0 Assembly: MOVE.W 10(SP),D2 * number_of_octets CLR.L D1 * temporary register CLR.L D0 * sum MOVE.L 4(SP),A0 * pointer to octets BRA.S first loop: MOVE.B (A0)+,D1 * get octet ADDX.B D1,D0 * add into sum ROL.B #1,D0 * rotate first: DBRA D2,loop RTS * return sum in D0 From owner-big-internet@munnari.oz.au Tue Jul 7 02:59:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19088; Tue, 7 Jul 1992 02:59:22 +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 AA18202; Tue, 7 Jul 1992 02:25:31 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA08187 (5.65/1.23); Mon, 6 Jul 92 12:23:20 -0400 Date: Mon, 6 Jul 92 12:23:20 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9207061623.AA08187@sadye.emba.uvm.edu> To: dave@sabre.bellcore.com (Dave Piscitello) Cc: big-internet@munnari.oz.au, ietf@isi.edu Subject: re: IPv7 (CLNP) a mistake In-Reply-To: <9207061448.AA02860@japan> References: <9207061448.AA02860@japan> On Mon, 6 Jul 92 10:48:32 EDT, dave@sabre.bellcore.com (Dave Piscitello) said: > Also, I think the copyright issue is a herring; you could always have > a requirements or profile document that tells you what and how to use the > CLNP document. And who was it who said ``you can't grep a dead tree''? -GAWollman From owner-Big-Internet@munnari.oz.au Tue Jul 7 03:02:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19157; Tue, 7 Jul 1992 03:03:10 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207061703.19157@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19152; Tue, 7 Jul 1992 03:02:54 +1000 (from J.Crowcroft@cs.ucl.ac.uk) Received: from dannebrog.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Mon, 6 Jul 1992 18:02:34 +0100 To: fbaker@acc.com (Fred Baker) Cc: big-internet@munnari.oz.au Subject: Re: IPv7 Checksum In-Reply-To: Your message of "Mon, 06 Jul 92 09:55:47 PDT." <9207061655.AA00657@saffron.acc.com> Date: Mon, 06 Jul 92 18:02:07 +0100 From: Jon Crowcroft >>> So, Jon, should IPv7 use the IPv4 checksum, or can we come up with a >>> different checksum that also provides byte swap protection but is >>> easier/faster to compute than the 8473 checksum? >for bytes of all zeroes. You'll recognize it as deriving from XNS IDP, >which uses the same algorithm on 16 bit words. smart! - i wasn't aware of IDP cksum alg... now, how about using PIP Routing Directives plus IDs for "new" systems, and PIP RDs (from Bob Smarts excellent DNS scheme) plus NAT plus old IP addrs as IDs for "addresses" for "old" systems...? j. From owner-Big-Internet@munnari.oz.au Tue Jul 7 03:29:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19958; Tue, 7 Jul 1992 03:29:45 +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 AA19938; Tue, 7 Jul 1992 03:29:30 +1000 (from kre) To: "Lyman Chapin" Cc: big-internet@munnari.oz.au, iietf@ISI.EDU Subject: Re: IPv7 (CLNP) a mistake In-Reply-To: Your message of Mon, 06 Jul 92 11:55:11 -0400. Date: Tue, 07 Jul 92 03:29:17 +1000 Message-Id: <20266.710443757@munnari.oz.au> From: Robert Elz Date: Mon, 6 Jul 92 11:55:11 EDT From: "Lyman Chapin" I suspect that figuring out how to support useful aggregation based on CLNP addresses is equivalent to figuring out how to support it based on any other addressing scheme - and that it's a hard problem. Its not just "a" hard problem, its "the" hard problem, the rest of creating the protocol to support whatever addressing is designed is trivial by comparison. I suspect this is the real reason behind a lot of the criticism. The IAB decision(recommendation) hasn't done anything to help solve the real problem, its just constrained the solution space. Now rather than having a totally free hand, we're constrained by CLNP addressing - and while that doesn't look to be a big constraint, as long as we forget GOSIP addressing - we can't really be sure yet. 160 bits should be big enough, but who knows? All we've gained is some ISO lip service, which isn't really helping anyone. kre From owner-Big-Internet@munnari.oz.au Tue Jul 7 03:44:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20603; Tue, 7 Jul 1992 03:47:26 +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 AA20479; Tue, 7 Jul 1992 03:44:17 +1000 (from kre) To: Dave Oran Cc: mo@gizmo.bellcore.com, big-internet@munnari.oz.au Subject: Re: why 160-bit addresses are daft.... In-Reply-To: Your message of Mon, 06 Jul 92 10:18:12 -0400. <920706101812.15893@sneezy.lkg.dec.com> Date: Tue, 07 Jul 92 03:44:04 +1000 Message-Id: <20295.710444644@munnari.oz.au> From: Robert Elz Date: Mon, 6 Jul 92 10:18:12 -0400 From: Dave Oran Message-ID: <920706101812.15893@sneezy.lkg.dec.com> With longest-match forwarding and patricia algorithms for forwarding table lookup, modern routers are effectively treating fixed-length addresses as variable length anyway. Are there routers that routinely do patricia lookups on the address in every packet passing through? The advantage of fixed length addresses is that they make nice (easy) cache keys - do the expensive lookup when you have to, then just use it over and over. kre From owner-big-internet@munnari.oz.au Tue Jul 7 04:00:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21338; Tue, 7 Jul 1992 04:00:38 +1000 (from owner-big-internet) Received: from MITVMA.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16147; Tue, 7 Jul 1992 01:08:35 +1000 (from @mitvma.mit.edu:owner-mod-ietf@searn.sunet.se) Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2) with BSMTP id 2171; Mon, 06 Jul 92 11:08:43 EDT Received: from FRORS12.BITNET by MITVMA.MIT.EDU (Mailer R2.08 R208004) with BSMTP id 2369; Mon, 06 Jul 92 11:08:41 EDT Received: by FRORS12 (Mailer R2.08 R208004) id 4525; Mon, 06 Jul 92 17:08:44 EDT Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6586 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:05:59 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7773; Mon, 06 Jul 92 17:04:48 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:04:46 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07063-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:06:16 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <01888-0@survis.surfnet.nl>; Fri, 3 Jul 1992 23:55:26 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <10278-0@relay.surfnet.nl>; Fri, 3 Jul 1992 23:55:15 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04963; 3 Jul 92 17:52 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04955; 3 Jul 92 17:52 EDT Received: from venera.isi.edu by NRI.Reston.VA.US id aa22111; 3 Jul 92 17:53 EDT Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Fri, 3 Jul 1992 14:44:54 -0700 Received: by braden.isi.edu (5.65c/4.0.3-4) id ; Fri, 3 Jul 1992 14:42:56 -0700 Return-Path: Date: Fri, 3 Jul 1992 14:42:56 -0700 From: braden@isi.edu Posted-Date: Fri, 3 Jul 1992 14:42:56 -0700 Message-Id: <199207032142.AA05142@braden.isi.edu> To: BSMTP Subject: re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Sender: owner-mod-ietf@searn.sunet.se In short we will adopt CLNP (an ISO protocol); we wish to be "functionally and syntactically" compatible and to "converge" with OSI; and want to be able to make "changes ... necessary for successful, deployment, operation, and evolution of IPv7." If we want to make changes and still be compatible with and converge with OSI, we'll have to convince ISO to go along, which means we have to work in the ISO standards process. So we've bought into the ISO process (for the network layer). Craig Craig, An argument that came up repeatedly in IAB discussions was the objection that adapting (note the "a") CLNP was a case of trying to have our cake and eat it too. Well, yes. And I believe we can. If and where CLNP does not work, let's fix it. There is nobody -- except ourselves -- who can stop us from succeeding. In the quotation you cite, convergence with OSI is clearly labelled as a long-term goal, not a requirement for IPv7. The primary requirement for IPv7 is to work in the global Internet. We do not have to ask anyone's permission. I think it also says that the IAB/IETF should adopt an address format appropriate for the Internet. A lot of us share the suspicion that this will NOT be any of the existing NSAP formats. How about real-time? My view is that real-time is still research. It's coming, but we have to expand the address space on a shorter timeframe. We don't have enough faith in the CIDR approach to bet our Internet on it. I hope that replacing the 60 byte limit on IP headers with a 254 byte limit will help us to do initial real-time work, using options. How about multicasting? The document says (clearly, I hope) that there must be no regression of functionality, and it specifically mentions multicast. It was my understanding that CLNP multicast along the IP multicast model was a done deal, except for a logjam created by the OSI standards process. That logjam is irrelevant to the IETF. Let's do it. Above all, "Don't panic!" Bob. From owner-big-internet@munnari.oz.au Tue Jul 7 04:05:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21546; Tue, 7 Jul 1992 04:05:21 +1000 (from owner-big-internet) Received: from MITVMA.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16153; Tue, 7 Jul 1992 01:08:50 +1000 (from @mitvma.mit.edu:owner-mod-ietf@searn.sunet.se) Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2) with BSMTP id 2173; Mon, 06 Jul 92 11:08:47 EDT Received: from FRORS12.BITNET by MITVMA.MIT.EDU (Mailer R2.08 R208004) with BSMTP id 2372; Mon, 06 Jul 92 11:08:43 EDT Received: by FRORS12 (Mailer R2.08 R208004) id 4526; Mon, 06 Jul 92 17:08:44 EDT Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6586 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:05:59 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7773; Mon, 06 Jul 92 17:04:48 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:04:46 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07063-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:06:16 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <01888-0@survis.surfnet.nl>; Fri, 3 Jul 1992 23:55:26 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <10278-0@relay.surfnet.nl>; Fri, 3 Jul 1992 23:55:15 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa04963; 3 Jul 92 17:52 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa04955; 3 Jul 92 17:52 EDT Received: from venera.isi.edu by NRI.Reston.VA.US id aa22111; 3 Jul 92 17:53 EDT Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Fri, 3 Jul 1992 14:44:54 -0700 Received: by braden.isi.edu (5.65c/4.0.3-4) id ; Fri, 3 Jul 1992 14:42:56 -0700 Return-Path: Date: Fri, 3 Jul 1992 14:42:56 -0700 From: braden@isi.edu Posted-Date: Fri, 3 Jul 1992 14:42:56 -0700 Message-Id: <199207032142.AA05142@braden.isi.edu> To: BSMTP Subject: re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Sender: owner-mod-ietf@searn.sunet.se In short we will adopt CLNP (an ISO protocol); we wish to be "functionally and syntactically" compatible and to "converge" with OSI; and want to be able to make "changes ... necessary for successful, deployment, operation, and evolution of IPv7." If we want to make changes and still be compatible with and converge with OSI, we'll have to convince ISO to go along, which means we have to work in the ISO standards process. So we've bought into the ISO process (for the network layer). Craig Craig, An argument that came up repeatedly in IAB discussions was the objection that adapting (note the "a") CLNP was a case of trying to have our cake and eat it too. Well, yes. And I believe we can. If and where CLNP does not work, let's fix it. There is nobody -- except ourselves -- who can stop us from succeeding. In the quotation you cite, convergence with OSI is clearly labelled as a long-term goal, not a requirement for IPv7. The primary requirement for IPv7 is to work in the global Internet. We do not have to ask anyone's permission. I think it also says that the IAB/IETF should adopt an address format appropriate for the Internet. A lot of us share the suspicion that this will NOT be any of the existing NSAP formats. How about real-time? My view is that real-time is still research. It's coming, but we have to expand the address space on a shorter timeframe. We don't have enough faith in the CIDR approach to bet our Internet on it. I hope that replacing the 60 byte limit on IP headers with a 254 byte limit will help us to do initial real-time work, using options. How about multicasting? The document says (clearly, I hope) that there must be no regression of functionality, and it specifically mentions multicast. It was my understanding that CLNP multicast along the IP multicast model was a done deal, except for a logjam created by the OSI standards process. That logjam is irrelevant to the IETF. Let's do it. Above all, "Don't panic!" Bob. From owner-big-internet@munnari.oz.au Tue Jul 7 04:10:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21837; Tue, 7 Jul 1992 04:10:14 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16352; Tue, 7 Jul 1992 01:17:17 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 0004; Mon, 06 Jul 92 17:13:45 MET Received: by DEARN (Mailer R2.08) id 2627; Mon, 06 Jul 92 17:13:44 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6619 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:12:11 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7803; Mon, 06 Jul 92 17:06:49 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:39 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07252-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:08:04 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <08865-3@survis.surfnet.nl>; Sun, 5 Jul 1992 20:53:33 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <22289-0@relay.surfnet.nl>; Sun, 5 Jul 1992 20:22:52 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03620; 5 Jul 92 14:15 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03616; 5 Jul 92 14:15 EDT Received: from Sun.COM by NRI.Reston.VA.US id aa06170; 5 Jul 92 14:17 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA12596; Sun, 5 Jul 92 11:17:10 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA08638; Sun, 5 Jul 92 11:17:13 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA16295; Sun, 5 Jul 92 11:16:53 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA25808; Sun, 5 Jul 92 11:17:07 PDT Return-Path: Date: Sun, 5 Jul 92 11:16:53 PDT From: Bob Hinden Message-Id: <9207051816.AA16295@b5mail.Eng.Sun.COM> To: BSMTP Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu In-Reply-To: <9207050702.AA02711@ginger.lcs.mit.edu> Subject: IPv7 == CLNP or CLNP+ ? Sender: owner-mod-ietf@searn.sunet.se Lyman, I would like to amplify the point which Noel makes in his message for clarification of the question of is IPv7 going to change CLNP or use it "exactly" as is. I keep hearing the argument made both ways and think it is important that this be made very clear. I also agree with Noel that the IAB proposal does not make this very clear. If we use CLNP exactly as is then I see the internet having to live with a number of serious technical shortcomings (e.g. checksum algorithm, no protocol ID, poor field alignment, etc.). Taking this approach is supported by the argument in the proposal (section 3.1) for not taking the risk of designing a new protocol and delaying it's testing and deployment. It would align IPv7 with ISO and current CLNP implementations. If we do change CLNP (which I think the current technical shortcomings warrant) then we will have created a new protocol. Lets call it CLNP+ Vendors would now have to support and deploy yet another protocol. IP will not go away soon. ISO CLNP is specified by GOSIP, used in Decnet P5, etc. CLNP+ would now be used in the Internet. It would take time to decide on what changes are to be made, do a specification, implementations, test it, and deploy it. All of the reasons argued against in the proposal for adopting CLNP in the first place. There seems to be some contradiction in the proposal why it is bad to to extend IP, which would have less impact on the internet layer, while it is ok to extend CLNP. I think this is a very important topic that needs to clarified soon. I would like to see a clear statement, something like: IPv7 will use CLNP "exactly" as is, or IPv7 will use a modified version of CLNP I don't think it can be both ways. If the argument is being made that we could adopt CLNP as IPv7 as is now, and then change it later, I am somewhat skeptical. I think there would be enormous pressure to not do this and it would introduce yet again another internet protocol for the vendors to support and deploy. Or to say it another way, we would have change control over something which we could not change. Bob From owner-big-internet@munnari.oz.au Tue Jul 7 04:14:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22035; Tue, 7 Jul 1992 04:14:32 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16363; Tue, 7 Jul 1992 01:17:27 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 0005; Mon, 06 Jul 92 17:13:47 MET Received: by DEARN (Mailer R2.08) id 2628; Mon, 06 Jul 92 17:13:45 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6619 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:12:11 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7803; Mon, 06 Jul 92 17:06:49 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:39 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07252-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:08:04 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <08865-3@survis.surfnet.nl>; Sun, 5 Jul 1992 20:53:33 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <22289-0@relay.surfnet.nl>; Sun, 5 Jul 1992 20:22:52 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03620; 5 Jul 92 14:15 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03616; 5 Jul 92 14:15 EDT Received: from Sun.COM by NRI.Reston.VA.US id aa06170; 5 Jul 92 14:17 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA12596; Sun, 5 Jul 92 11:17:10 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA08638; Sun, 5 Jul 92 11:17:13 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA16295; Sun, 5 Jul 92 11:16:53 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA25808; Sun, 5 Jul 92 11:17:07 PDT Return-Path: Date: Sun, 5 Jul 92 11:16:53 PDT From: Bob Hinden Message-Id: <9207051816.AA16295@b5mail.Eng.Sun.COM> To: BSMTP Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu In-Reply-To: <9207050702.AA02711@ginger.lcs.mit.edu> Subject: IPv7 == CLNP or CLNP+ ? Sender: owner-mod-ietf@searn.sunet.se Lyman, I would like to amplify the point which Noel makes in his message for clarification of the question of is IPv7 going to change CLNP or use it "exactly" as is. I keep hearing the argument made both ways and think it is important that this be made very clear. I also agree with Noel that the IAB proposal does not make this very clear. If we use CLNP exactly as is then I see the internet having to live with a number of serious technical shortcomings (e.g. checksum algorithm, no protocol ID, poor field alignment, etc.). Taking this approach is supported by the argument in the proposal (section 3.1) for not taking the risk of designing a new protocol and delaying it's testing and deployment. It would align IPv7 with ISO and current CLNP implementations. If we do change CLNP (which I think the current technical shortcomings warrant) then we will have created a new protocol. Lets call it CLNP+ Vendors would now have to support and deploy yet another protocol. IP will not go away soon. ISO CLNP is specified by GOSIP, used in Decnet P5, etc. CLNP+ would now be used in the Internet. It would take time to decide on what changes are to be made, do a specification, implementations, test it, and deploy it. All of the reasons argued against in the proposal for adopting CLNP in the first place. There seems to be some contradiction in the proposal why it is bad to to extend IP, which would have less impact on the internet layer, while it is ok to extend CLNP. I think this is a very important topic that needs to clarified soon. I would like to see a clear statement, something like: IPv7 will use CLNP "exactly" as is, or IPv7 will use a modified version of CLNP I don't think it can be both ways. If the argument is being made that we could adopt CLNP as IPv7 as is now, and then change it later, I am somewhat skeptical. I think there would be enormous pressure to not do this and it would introduce yet again another internet protocol for the vendors to support and deploy. Or to say it another way, we would have change control over something which we could not change. Bob From owner-big-internet@munnari.oz.au Tue Jul 7 04:19:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22329; Tue, 7 Jul 1992 04:19:49 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16365; Tue, 7 Jul 1992 01:17:37 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 0006; Mon, 06 Jul 92 17:13:49 MET Received: by DEARN (Mailer R2.08) id 2631; Mon, 06 Jul 92 17:13:46 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6619 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:12:11 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7803; Mon, 06 Jul 92 17:06:49 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:39 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07252-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:08:04 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <08865-3@survis.surfnet.nl>; Sun, 5 Jul 1992 20:53:33 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <22289-0@relay.surfnet.nl>; Sun, 5 Jul 1992 20:22:52 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa03620; 5 Jul 92 14:15 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa03616; 5 Jul 92 14:15 EDT Received: from Sun.COM by NRI.Reston.VA.US id aa06170; 5 Jul 92 14:17 EDT Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA12596; Sun, 5 Jul 92 11:17:10 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA08638; Sun, 5 Jul 92 11:17:13 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA16295; Sun, 5 Jul 92 11:16:53 PDT Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA25808; Sun, 5 Jul 92 11:17:07 PDT Return-Path: Date: Sun, 5 Jul 92 11:16:53 PDT From: Bob Hinden Message-Id: <9207051816.AA16295@b5mail.Eng.Sun.COM> To: BSMTP Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu In-Reply-To: <9207050702.AA02711@ginger.lcs.mit.edu> Subject: IPv7 == CLNP or CLNP+ ? Sender: owner-mod-ietf@searn.sunet.se Lyman, I would like to amplify the point which Noel makes in his message for clarification of the question of is IPv7 going to change CLNP or use it "exactly" as is. I keep hearing the argument made both ways and think it is important that this be made very clear. I also agree with Noel that the IAB proposal does not make this very clear. If we use CLNP exactly as is then I see the internet having to live with a number of serious technical shortcomings (e.g. checksum algorithm, no protocol ID, poor field alignment, etc.). Taking this approach is supported by the argument in the proposal (section 3.1) for not taking the risk of designing a new protocol and delaying it's testing and deployment. It would align IPv7 with ISO and current CLNP implementations. If we do change CLNP (which I think the current technical shortcomings warrant) then we will have created a new protocol. Lets call it CLNP+ Vendors would now have to support and deploy yet another protocol. IP will not go away soon. ISO CLNP is specified by GOSIP, used in Decnet P5, etc. CLNP+ would now be used in the Internet. It would take time to decide on what changes are to be made, do a specification, implementations, test it, and deploy it. All of the reasons argued against in the proposal for adopting CLNP in the first place. There seems to be some contradiction in the proposal why it is bad to to extend IP, which would have less impact on the internet layer, while it is ok to extend CLNP. I think this is a very important topic that needs to clarified soon. I would like to see a clear statement, something like: IPv7 will use CLNP "exactly" as is, or IPv7 will use a modified version of CLNP I don't think it can be both ways. If the argument is being made that we could adopt CLNP as IPv7 as is now, and then change it later, I am somewhat skeptical. I think there would be enormous pressure to not do this and it would introduce yet again another internet protocol for the vendors to support and deploy. Or to say it another way, we would have change control over something which we could not change. Bob From owner-big-internet@munnari.oz.au Tue Jul 7 04:24:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22621; Tue, 7 Jul 1992 04:24:50 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16367; Tue, 7 Jul 1992 01:17:47 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 0007; Mon, 06 Jul 92 17:13:56 MET Received: by DEARN (Mailer R2.08) id 2646; Mon, 06 Jul 92 17:13:55 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6620 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:12:26 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7810; Mon, 06 Jul 92 17:07:07 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:07:04 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07281-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:08:20 +0200 Received: from hearnvax.nic.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <00300-0@survis.surfnet.nl>; Mon, 6 Jul 1992 12:56:44 +0200 Received: from IETF.nri.reston.VA.US (132.151.1.35) by HEARNVAX.nic.SURFnet.nl with PMDF#10216; Mon, 6 Jul 1992 12:57 MET Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05860; 6 Jul 92 6:51 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05856; 6 Jul 92 6:50 EDT Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa24550; 6 Jul 92 6:52 EDT Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05851; 6 Jul 92 6:50 EDT Return-Path: Date: Mon, 06 Jul 92 06:50:53 -0400 From: vcerf@NRI.Reston.VA.US Subject: Re: IPv7 == CLNP or CLNP+ ? In-Reply-To: Your message of "Sun, 05 Jul 92 11:16:53 PDT." <9207051816.AA16295@b5mail.Eng.Sun.COM> To: BSMTP Cc: Lyman@bbn.com, big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu Message-Id: <9207060650.aa05851@IETF.NRI.Reston.VA.US> X-Envelope-To: huizer@SURFNET.NL Sender: owner-mod-ietf@searn.sunet.se Bob and others on these distribution lists, I have just returned from a trip to Africa and discovered that the Internet community has found its own way to celebrate Independence Day in the US (with fireworks on the network). I think I have about 1200 messages accumulated which need to be read (groan). Here's a personal perspective on the vigorous discussion triggered by the recent IAB message concerning IPv7: 1. We clearly do need to take action to deal with the routing information explosion and the predictable exhaustion of addresses in the IPv4 format. 2. We want very much to continue to evolve the Internet functionality and, in particular, need to deal with real-time, multi-cast, mobile hosts (and nets?!), sophisticated routing policy expression, and so on. 3. One way to achieve intense evaluation of a proposal is to posit it as a starting point and consider the implications of its adoption. The CLNP specification is proposed as the starting point for the IPv7 both to lend concreteness to the ensuing discussion (I hope this does NOT result in concrete brickbats being hurled through MIME mail....!!) and to take advantage of whatever has already been learned by use of this particular packet format. I am persuaded that the growth problems we face are real and imminent and that we must make firm plans as quickly as we can to allow time for all the deployment and engineering work to be done. If, in the discussions which follow, we focus on whether the CLNP format can serve or must change (and in what way), we ought to be able to sort out the viability of starting with CLNP versus starting from something else. Please note that CLNP started with IP4, so the key question is whether we can define IPv7 based on CLNP or whether there is strong technical reason to start at another point in the potential solution space. What has been published by the IAB is a plan, not a final decision. For my part, I hoped that making a concrete proposal to start with CLNP format would focus the discussion and generate considered comment. I have certainly not been disappointed in the latter regard!! We may learn from the discussions which follow that something other than CLNP is a far superior starting point or we may discover that IPv7 can start there with considerable utility. The important thing, in my view, is that we acknowledge the need to move ahead rapidly to make our technical plans - any solutions to scaling will be a great challenge to implement and deploy before we are overcome with "success". Vint From owner-big-internet@munnari.oz.au Tue Jul 7 04:29:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22945; Tue, 7 Jul 1992 04:29:39 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16369; Tue, 7 Jul 1992 01:17:55 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 0008; Mon, 06 Jul 92 17:13:57 MET Received: by DEARN (Mailer R2.08) id 2647; Mon, 06 Jul 92 17:13:55 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6620 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:12:26 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7810; Mon, 06 Jul 92 17:07:07 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:07:04 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07281-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:08:20 +0200 Received: from hearnvax.nic.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <00300-0@survis.surfnet.nl>; Mon, 6 Jul 1992 12:56:44 +0200 Received: from IETF.nri.reston.VA.US (132.151.1.35) by HEARNVAX.nic.SURFnet.nl with PMDF#10216; Mon, 6 Jul 1992 12:57 MET Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05860; 6 Jul 92 6:51 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05856; 6 Jul 92 6:50 EDT Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa24550; 6 Jul 92 6:52 EDT Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05851; 6 Jul 92 6:50 EDT Return-Path: Date: Mon, 06 Jul 92 06:50:53 -0400 From: vcerf@NRI.Reston.VA.US Subject: Re: IPv7 == CLNP or CLNP+ ? In-Reply-To: Your message of "Sun, 05 Jul 92 11:16:53 PDT." <9207051816.AA16295@b5mail.Eng.Sun.COM> To: BSMTP Cc: Lyman@bbn.com, big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu Message-Id: <9207060650.aa05851@IETF.NRI.Reston.VA.US> X-Envelope-To: huizer@SURFNET.NL Sender: owner-mod-ietf@searn.sunet.se Bob and others on these distribution lists, I have just returned from a trip to Africa and discovered that the Internet community has found its own way to celebrate Independence Day in the US (with fireworks on the network). I think I have about 1200 messages accumulated which need to be read (groan). Here's a personal perspective on the vigorous discussion triggered by the recent IAB message concerning IPv7: 1. We clearly do need to take action to deal with the routing information explosion and the predictable exhaustion of addresses in the IPv4 format. 2. We want very much to continue to evolve the Internet functionality and, in particular, need to deal with real-time, multi-cast, mobile hosts (and nets?!), sophisticated routing policy expression, and so on. 3. One way to achieve intense evaluation of a proposal is to posit it as a starting point and consider the implications of its adoption. The CLNP specification is proposed as the starting point for the IPv7 both to lend concreteness to the ensuing discussion (I hope this does NOT result in concrete brickbats being hurled through MIME mail....!!) and to take advantage of whatever has already been learned by use of this particular packet format. I am persuaded that the growth problems we face are real and imminent and that we must make firm plans as quickly as we can to allow time for all the deployment and engineering work to be done. If, in the discussions which follow, we focus on whether the CLNP format can serve or must change (and in what way), we ought to be able to sort out the viability of starting with CLNP versus starting from something else. Please note that CLNP started with IP4, so the key question is whether we can define IPv7 based on CLNP or whether there is strong technical reason to start at another point in the potential solution space. What has been published by the IAB is a plan, not a final decision. For my part, I hoped that making a concrete proposal to start with CLNP format would focus the discussion and generate considered comment. I have certainly not been disappointed in the latter regard!! We may learn from the discussions which follow that something other than CLNP is a far superior starting point or we may discover that IPv7 can start there with considerable utility. The important thing, in my view, is that we acknowledge the need to move ahead rapidly to make our technical plans - any solutions to scaling will be a great challenge to implement and deploy before we are overcome with "success". Vint From owner-Big-Internet@munnari.oz.au Tue Jul 7 04:31:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23064; Tue, 7 Jul 1992 04:31:31 +1000 (from owner-Big-Internet) Return-Path: Received: from HQ.TGV.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23052; Tue, 7 Jul 1992 04:31:15 +1000 (from karl@Mel-Brooks.TGV.COM) Received: from mel-brooks.empirical.com ([161.44.128.66]) by TGV.COM via INTERNET ; Mon, 6 Jul 92 11:30:24 PDT Received: from karl.lvs.empirical.com by mel-brooks.empirical.com (4.1/SMI-4.1) id AA01981; Mon, 6 Jul 92 11:31:29 PDT Date: Mon, 6 Jul 92 11:31:29 PDT Message-Id: <9207061831.AA01981@mel-brooks.empirical.com> To: billw@cider.cisco.com Subject: Re: why 160-bit addresses are daft.... From: karl@Mel-Brooks.TGV.COM (Karl Auerbach, Empirical Tools and Technologies, 408/427-5280) Reply-To: karl@TGV.COM Cc: dino@cisco.com, braden@ISI.EDU, bsimpson@angband.stanford.edu, ietf@ISI.EDU, big-internet@munnari.oz.au Sender: karl@Mel-Brooks.TGV.COM Repository: empirical.com Originating-Client: lvs.empirical.com > The Fletcher Checksume would be more problematic if it doesn't support > "incremental" calculation (in IP, since all you update is the TTL, you > don't need to fully checksum the new header...) Just curious, we all know that cisco routers (like other's) can switch about a zillion IP packets per second. But how fast can the same cisco switch CLNP packets? This might give us some idea about the overhead of CLNP. --karl-- From owner-big-internet@munnari.oz.au Tue Jul 7 04:34:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23236; Tue, 7 Jul 1992 04:34:30 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16375; Tue, 7 Jul 1992 01:18:07 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 0009; Mon, 06 Jul 92 17:13:59 MET Received: by DEARN (Mailer R2.08) id 2649; Mon, 06 Jul 92 17:13:57 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6620 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:12:26 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7810; Mon, 06 Jul 92 17:07:07 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:07:04 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07281-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:08:20 +0200 Received: from hearnvax.nic.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <00300-0@survis.surfnet.nl>; Mon, 6 Jul 1992 12:56:44 +0200 Received: from IETF.nri.reston.VA.US (132.151.1.35) by HEARNVAX.nic.SURFnet.nl with PMDF#10216; Mon, 6 Jul 1992 12:57 MET Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05860; 6 Jul 92 6:51 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05856; 6 Jul 92 6:50 EDT Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa24550; 6 Jul 92 6:52 EDT Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05851; 6 Jul 92 6:50 EDT Return-Path: Date: Mon, 06 Jul 92 06:50:53 -0400 From: vcerf@NRI.Reston.VA.US Subject: Re: IPv7 == CLNP or CLNP+ ? In-Reply-To: Your message of "Sun, 05 Jul 92 11:16:53 PDT." <9207051816.AA16295@b5mail.Eng.Sun.COM> To: BSMTP Cc: Lyman@bbn.com, big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu Message-Id: <9207060650.aa05851@IETF.NRI.Reston.VA.US> X-Envelope-To: huizer@SURFNET.NL Sender: owner-mod-ietf@searn.sunet.se Bob and others on these distribution lists, I have just returned from a trip to Africa and discovered that the Internet community has found its own way to celebrate Independence Day in the US (with fireworks on the network). I think I have about 1200 messages accumulated which need to be read (groan). Here's a personal perspective on the vigorous discussion triggered by the recent IAB message concerning IPv7: 1. We clearly do need to take action to deal with the routing information explosion and the predictable exhaustion of addresses in the IPv4 format. 2. We want very much to continue to evolve the Internet functionality and, in particular, need to deal with real-time, multi-cast, mobile hosts (and nets?!), sophisticated routing policy expression, and so on. 3. One way to achieve intense evaluation of a proposal is to posit it as a starting point and consider the implications of its adoption. The CLNP specification is proposed as the starting point for the IPv7 both to lend concreteness to the ensuing discussion (I hope this does NOT result in concrete brickbats being hurled through MIME mail....!!) and to take advantage of whatever has already been learned by use of this particular packet format. I am persuaded that the growth problems we face are real and imminent and that we must make firm plans as quickly as we can to allow time for all the deployment and engineering work to be done. If, in the discussions which follow, we focus on whether the CLNP format can serve or must change (and in what way), we ought to be able to sort out the viability of starting with CLNP versus starting from something else. Please note that CLNP started with IP4, so the key question is whether we can define IPv7 based on CLNP or whether there is strong technical reason to start at another point in the potential solution space. What has been published by the IAB is a plan, not a final decision. For my part, I hoped that making a concrete proposal to start with CLNP format would focus the discussion and generate considered comment. I have certainly not been disappointed in the latter regard!! We may learn from the discussions which follow that something other than CLNP is a far superior starting point or we may discover that IPv7 can start there with considerable utility. The important thing, in my view, is that we acknowledge the need to move ahead rapidly to make our technical plans - any solutions to scaling will be a great challenge to implement and deploy before we are overcome with "success". Vint From owner-big-internet@munnari.oz.au Tue Jul 7 04:39:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23486; Tue, 7 Jul 1992 04:39:59 +1000 (from owner-big-internet) Received: from MITVMA.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16364; Tue, 7 Jul 1992 01:17:37 +1000 (from @mitvma.mit.edu:owner-mod-ietf@searn.sunet.se) Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2) with BSMTP id 2251; Mon, 06 Jul 92 11:17:35 EDT Received: from FRORS12.BITNET by MITVMA.MIT.EDU (Mailer R2.08 R208004) with BSMTP id 2558; Mon, 06 Jul 92 11:17:30 EDT Received: by FRORS12 (Mailer R2.08 R208004) id 4997; Mon, 06 Jul 92 17:16:14 EDT Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6620 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:12:26 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7810; Mon, 06 Jul 92 17:07:07 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:07:04 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07281-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:08:20 +0200 Received: from hearnvax.nic.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <00300-0@survis.surfnet.nl>; Mon, 6 Jul 1992 12:56:44 +0200 Received: from IETF.nri.reston.VA.US (132.151.1.35) by HEARNVAX.nic.SURFnet.nl with PMDF#10216; Mon, 6 Jul 1992 12:57 MET Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa05860; 6 Jul 92 6:51 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa05856; 6 Jul 92 6:50 EDT Received: from ietf.NRI.Reston.Va.US by NRI.Reston.VA.US id aa24550; 6 Jul 92 6:52 EDT Received: from [127.0.0.1] by IETF.NRI.Reston.VA.US id aa05851; 6 Jul 92 6:50 EDT Return-Path: Date: Mon, 06 Jul 92 06:50:53 -0400 From: vcerf@NRI.Reston.VA.US Subject: Re: IPv7 == CLNP or CLNP+ ? In-Reply-To: Your message of "Sun, 05 Jul 92 11:16:53 PDT." <9207051816.AA16295@b5mail.Eng.Sun.COM> To: BSMTP Cc: Lyman@bbn.com, big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu Message-Id: <9207060650.aa05851@IETF.NRI.Reston.VA.US> X-Envelope-To: huizer@SURFNET.NL Sender: owner-mod-ietf@searn.sunet.se Bob and others on these distribution lists, I have just returned from a trip to Africa and discovered that the Internet community has found its own way to celebrate Independence Day in the US (with fireworks on the network). I think I have about 1200 messages accumulated which need to be read (groan). Here's a personal perspective on the vigorous discussion triggered by the recent IAB message concerning IPv7: 1. We clearly do need to take action to deal with the routing information explosion and the predictable exhaustion of addresses in the IPv4 format. 2. We want very much to continue to evolve the Internet functionality and, in particular, need to deal with real-time, multi-cast, mobile hosts (and nets?!), sophisticated routing policy expression, and so on. 3. One way to achieve intense evaluation of a proposal is to posit it as a starting point and consider the implications of its adoption. The CLNP specification is proposed as the starting point for the IPv7 both to lend concreteness to the ensuing discussion (I hope this does NOT result in concrete brickbats being hurled through MIME mail....!!) and to take advantage of whatever has already been learned by use of this particular packet format. I am persuaded that the growth problems we face are real and imminent and that we must make firm plans as quickly as we can to allow time for all the deployment and engineering work to be done. If, in the discussions which follow, we focus on whether the CLNP format can serve or must change (and in what way), we ought to be able to sort out the viability of starting with CLNP versus starting from something else. Please note that CLNP started with IP4, so the key question is whether we can define IPv7 based on CLNP or whether there is strong technical reason to start at another point in the potential solution space. What has been published by the IAB is a plan, not a final decision. For my part, I hoped that making a concrete proposal to start with CLNP format would focus the discussion and generate considered comment. I have certainly not been disappointed in the latter regard!! We may learn from the discussions which follow that something other than CLNP is a far superior starting point or we may discover that IPv7 can start there with considerable utility. The important thing, in my view, is that we acknowledge the need to move ahead rapidly to make our technical plans - any solutions to scaling will be a great challenge to implement and deploy before we are overcome with "success". Vint From owner-big-internet@munnari.oz.au Tue Jul 7 04:48:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23810; Tue, 7 Jul 1992 04:48:58 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16314; Tue, 7 Jul 1992 01:15:49 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 0001; Mon, 06 Jul 92 17:13:27 MET Received: by DEARN (Mailer R2.08) id 2592; Mon, 06 Jul 92 17:13:26 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6618 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:52 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7800; Mon, 06 Jul 92 17:06:36 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:32 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07225-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:53 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07601-0@survis.surfnet.nl>; Sun, 5 Jul 1992 09:08:05 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <19962-0@relay.surfnet.nl>; Sun, 5 Jul 1992 09:08:00 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02964; 5 Jul 92 3:03 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab02960; 5 Jul 92 3:03 EDT Received: from GINGER.LCS.MIT.EDU by NRI.Reston.VA.US id aa25666; 5 Jul 92 3:04 EDT Received: by ginger.lcs.mit.edu id AA02711; Sun, 5 Jul 92 03:02:07 -0400 Return-Path: Date: Sun, 5 Jul 92 03:02:07 -0400 From: Noel Chiappa Message-Id: <9207050702.AA02711@ginger.lcs.mit.edu> To: BSMTP Subject: Re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Sender: owner-mod-ietf@searn.sunet.se Lyman: This sounds much like ideas for this suggested interaction between the Internet and OSI that I've heard from you in the past, and is a more sophisticated and plausible version of this than made it into the IAB I-D; it's too bad the multiple drafts the IAB went through didn't manage to work this in. Having read it, though, I am still left with the feeling that somewhere in a forest, 2+2 is not adding up to 4, as I'll explain in a bit. Mind you, I see the argument for having only a single non-proprietary open packet networking architecture, but I still think the best way to do this (as I have indicated previously) is to design an entirely new protocol which we can label the common decendant of both. This is little different in practise from your suggestion, you might say, and there is something to that. However, it does avoid certain classes of pointless angst, such as the variety we are now experiencing. Let's assume for the sake of argument that we want a new packet layer very soon (an assumption I absolutely disagree with, as explained below). It is suggested that we are to take a protocol (CLNP) which both sides seem to keep saying is basically the same as IP, but has two major claimed advantages; longer addresses, and space for more options. (I will put to one side, for sake of clarity, debates about whether those longer addresses are what we need. I will also put to one side claims of disadvantages, like a less-well suited checksum, etc.) However, we aren't binding ourselves (for reasons of abilty to meet requirements) to keeping that protocol exactly the same. To me, this sounds like we have just voided the best argument for switching to a second protocol, which is the interoperability issue. Surely, if the Internet CLNP is functionally different in a useful way, it won't be interoperable, right? I mean, if all we are getting is larger addresses and space for more options, and have to make changes to the protocol which make it non- interoperable with vanilla implementations, surely we could get the same thing my modifying our existing network layer (IP) at the same effective cost. In fact, the cost would be less, since we wouldn't have to make some of the major changes to our protcol suite that a switch to a new network layer would entail (e.g. phasing in ES-IS, etc, etc). If we are going to modify an existing protocol to get what we need (and I don't agree we should be doing this at the moment), why switch to a totally different one to do it? I'm also less sanguine than you are about the ability to get the ISO world to track changes made here. Standards bodies *all* (including the IETF, I willingly admit) seem to have a bad case of N.I.H. I mean, look at IEEE; they just *couldn't* resist dinkering with Ethernet, a widely deployed and very sucessful standard. I *still* think the best interim path is to put off the adoption of a new packet layer as long as we possibly can, until we understand more about some major, little-understood, technical issues that a successful large scale networking infrastructure will have to face (such as resource allocation, pervasive network security, substantial auto-configuration, etc, etc.) This delay will also allow us a clearer vision of the physical network infra- structure of the future, includling things like Gigabiot nets, etc. I believe we can kill two birds with one stone: deploy an entirely new routing and addressing architecture, and maximize the lifetime of the current IP, by the simple expedient of changing the interpretation of the current 32 bit source/dest fields in a way that gives us a capability we have long wanted anyway. By the time that is thinking about running out of steam (and even if we only get 10% utilization of the 2^32 sized identifier space, we still get *four hundred million* hosts), we should know a lot more about these research topics, and can move straight to a third generation packet protocol. Noel From owner-big-internet@munnari.oz.au Tue Jul 7 05:00:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24152; Tue, 7 Jul 1992 05:00:47 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16315; Tue, 7 Jul 1992 01:15:59 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 0002; Mon, 06 Jul 92 17:13:29 MET Received: by DEARN (Mailer R2.08) id 2593; Mon, 06 Jul 92 17:13:27 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6618 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:52 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7800; Mon, 06 Jul 92 17:06:36 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:32 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07225-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:53 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07601-0@survis.surfnet.nl>; Sun, 5 Jul 1992 09:08:05 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <19962-0@relay.surfnet.nl>; Sun, 5 Jul 1992 09:08:00 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02964; 5 Jul 92 3:03 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab02960; 5 Jul 92 3:03 EDT Received: from GINGER.LCS.MIT.EDU by NRI.Reston.VA.US id aa25666; 5 Jul 92 3:04 EDT Received: by ginger.lcs.mit.edu id AA02711; Sun, 5 Jul 92 03:02:07 -0400 Return-Path: Date: Sun, 5 Jul 92 03:02:07 -0400 From: Noel Chiappa Message-Id: <9207050702.AA02711@ginger.lcs.mit.edu> To: BSMTP Subject: Re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Sender: owner-mod-ietf@searn.sunet.se Lyman: This sounds much like ideas for this suggested interaction between the Internet and OSI that I've heard from you in the past, and is a more sophisticated and plausible version of this than made it into the IAB I-D; it's too bad the multiple drafts the IAB went through didn't manage to work this in. Having read it, though, I am still left with the feeling that somewhere in a forest, 2+2 is not adding up to 4, as I'll explain in a bit. Mind you, I see the argument for having only a single non-proprietary open packet networking architecture, but I still think the best way to do this (as I have indicated previously) is to design an entirely new protocol which we can label the common decendant of both. This is little different in practise from your suggestion, you might say, and there is something to that. However, it does avoid certain classes of pointless angst, such as the variety we are now experiencing. Let's assume for the sake of argument that we want a new packet layer very soon (an assumption I absolutely disagree with, as explained below). It is suggested that we are to take a protocol (CLNP) which both sides seem to keep saying is basically the same as IP, but has two major claimed advantages; longer addresses, and space for more options. (I will put to one side, for sake of clarity, debates about whether those longer addresses are what we need. I will also put to one side claims of disadvantages, like a less-well suited checksum, etc.) However, we aren't binding ourselves (for reasons of abilty to meet requirements) to keeping that protocol exactly the same. To me, this sounds like we have just voided the best argument for switching to a second protocol, which is the interoperability issue. Surely, if the Internet CLNP is functionally different in a useful way, it won't be interoperable, right? I mean, if all we are getting is larger addresses and space for more options, and have to make changes to the protocol which make it non- interoperable with vanilla implementations, surely we could get the same thing my modifying our existing network layer (IP) at the same effective cost. In fact, the cost would be less, since we wouldn't have to make some of the major changes to our protcol suite that a switch to a new network layer would entail (e.g. phasing in ES-IS, etc, etc). If we are going to modify an existing protocol to get what we need (and I don't agree we should be doing this at the moment), why switch to a totally different one to do it? I'm also less sanguine than you are about the ability to get the ISO world to track changes made here. Standards bodies *all* (including the IETF, I willingly admit) seem to have a bad case of N.I.H. I mean, look at IEEE; they just *couldn't* resist dinkering with Ethernet, a widely deployed and very sucessful standard. I *still* think the best interim path is to put off the adoption of a new packet layer as long as we possibly can, until we understand more about some major, little-understood, technical issues that a successful large scale networking infrastructure will have to face (such as resource allocation, pervasive network security, substantial auto-configuration, etc, etc.) This delay will also allow us a clearer vision of the physical network infra- structure of the future, includling things like Gigabiot nets, etc. I believe we can kill two birds with one stone: deploy an entirely new routing and addressing architecture, and maximize the lifetime of the current IP, by the simple expedient of changing the interpretation of the current 32 bit source/dest fields in a way that gives us a capability we have long wanted anyway. By the time that is thinking about running out of steam (and even if we only get 10% utilization of the 2^32 sized identifier space, we still get *four hundred million* hosts), we should know a lot more about these research topics, and can move straight to a third generation packet protocol. Noel From owner-big-internet@munnari.oz.au Tue Jul 7 05:07:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24450; Tue, 7 Jul 1992 05:07:33 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16346; Tue, 7 Jul 1992 01:17:07 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 0003; Mon, 06 Jul 92 17:13:31 MET Received: by DEARN (Mailer R2.08) id 2596; Mon, 06 Jul 92 17:13:28 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6618 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:52 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7800; Mon, 06 Jul 92 17:06:36 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:32 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07225-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:53 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07601-0@survis.surfnet.nl>; Sun, 5 Jul 1992 09:08:05 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <19962-0@relay.surfnet.nl>; Sun, 5 Jul 1992 09:08:00 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02964; 5 Jul 92 3:03 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab02960; 5 Jul 92 3:03 EDT Received: from GINGER.LCS.MIT.EDU by NRI.Reston.VA.US id aa25666; 5 Jul 92 3:04 EDT Received: by ginger.lcs.mit.edu id AA02711; Sun, 5 Jul 92 03:02:07 -0400 Return-Path: Date: Sun, 5 Jul 92 03:02:07 -0400 From: Noel Chiappa Message-Id: <9207050702.AA02711@ginger.lcs.mit.edu> To: BSMTP Subject: Re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Sender: owner-mod-ietf@searn.sunet.se Lyman: This sounds much like ideas for this suggested interaction between the Internet and OSI that I've heard from you in the past, and is a more sophisticated and plausible version of this than made it into the IAB I-D; it's too bad the multiple drafts the IAB went through didn't manage to work this in. Having read it, though, I am still left with the feeling that somewhere in a forest, 2+2 is not adding up to 4, as I'll explain in a bit. Mind you, I see the argument for having only a single non-proprietary open packet networking architecture, but I still think the best way to do this (as I have indicated previously) is to design an entirely new protocol which we can label the common decendant of both. This is little different in practise from your suggestion, you might say, and there is something to that. However, it does avoid certain classes of pointless angst, such as the variety we are now experiencing. Let's assume for the sake of argument that we want a new packet layer very soon (an assumption I absolutely disagree with, as explained below). It is suggested that we are to take a protocol (CLNP) which both sides seem to keep saying is basically the same as IP, but has two major claimed advantages; longer addresses, and space for more options. (I will put to one side, for sake of clarity, debates about whether those longer addresses are what we need. I will also put to one side claims of disadvantages, like a less-well suited checksum, etc.) However, we aren't binding ourselves (for reasons of abilty to meet requirements) to keeping that protocol exactly the same. To me, this sounds like we have just voided the best argument for switching to a second protocol, which is the interoperability issue. Surely, if the Internet CLNP is functionally different in a useful way, it won't be interoperable, right? I mean, if all we are getting is larger addresses and space for more options, and have to make changes to the protocol which make it non- interoperable with vanilla implementations, surely we could get the same thing my modifying our existing network layer (IP) at the same effective cost. In fact, the cost would be less, since we wouldn't have to make some of the major changes to our protcol suite that a switch to a new network layer would entail (e.g. phasing in ES-IS, etc, etc). If we are going to modify an existing protocol to get what we need (and I don't agree we should be doing this at the moment), why switch to a totally different one to do it? I'm also less sanguine than you are about the ability to get the ISO world to track changes made here. Standards bodies *all* (including the IETF, I willingly admit) seem to have a bad case of N.I.H. I mean, look at IEEE; they just *couldn't* resist dinkering with Ethernet, a widely deployed and very sucessful standard. I *still* think the best interim path is to put off the adoption of a new packet layer as long as we possibly can, until we understand more about some major, little-understood, technical issues that a successful large scale networking infrastructure will have to face (such as resource allocation, pervasive network security, substantial auto-configuration, etc, etc.) This delay will also allow us a clearer vision of the physical network infra- structure of the future, includling things like Gigabiot nets, etc. I believe we can kill two birds with one stone: deploy an entirely new routing and addressing architecture, and maximize the lifetime of the current IP, by the simple expedient of changing the interpretation of the current 32 bit source/dest fields in a way that gives us a capability we have long wanted anyway. By the time that is thinking about running out of steam (and even if we only get 10% utilization of the 2^32 sized identifier space, we still get *four hundred million* hosts), we should know a lot more about these research topics, and can move straight to a third generation packet protocol. Noel From owner-big-internet@munnari.oz.au Tue Jul 7 05:16:57 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24751; Tue, 7 Jul 1992 05:17:15 +1000 (from owner-big-internet) Received: from MITVMA.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16328; Tue, 7 Jul 1992 01:16:46 +1000 (from @mitvma.mit.edu:owner-mod-ietf@searn.sunet.se) Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2) with BSMTP id 2240; Mon, 06 Jul 92 11:16:40 EDT Received: from FRORS12.BITNET by MITVMA.MIT.EDU (Mailer R2.08 R208004) with BSMTP id 2535; Mon, 06 Jul 92 11:16:36 EDT Received: by FRORS12 (Mailer R2.08 R208004) id 4972; Mon, 06 Jul 92 17:15:40 EDT Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6618 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:52 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7800; Mon, 06 Jul 92 17:06:36 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:32 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07225-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:53 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07601-0@survis.surfnet.nl>; Sun, 5 Jul 1992 09:08:05 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <19962-0@relay.surfnet.nl>; Sun, 5 Jul 1992 09:08:00 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02964; 5 Jul 92 3:03 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab02960; 5 Jul 92 3:03 EDT Received: from GINGER.LCS.MIT.EDU by NRI.Reston.VA.US id aa25666; 5 Jul 92 3:04 EDT Received: by ginger.lcs.mit.edu id AA02711; Sun, 5 Jul 92 03:02:07 -0400 Return-Path: Date: Sun, 5 Jul 92 03:02:07 -0400 From: Noel Chiappa Message-Id: <9207050702.AA02711@ginger.lcs.mit.edu> To: BSMTP Subject: Re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Sender: owner-mod-ietf@searn.sunet.se Lyman: This sounds much like ideas for this suggested interaction between the Internet and OSI that I've heard from you in the past, and is a more sophisticated and plausible version of this than made it into the IAB I-D; it's too bad the multiple drafts the IAB went through didn't manage to work this in. Having read it, though, I am still left with the feeling that somewhere in a forest, 2+2 is not adding up to 4, as I'll explain in a bit. Mind you, I see the argument for having only a single non-proprietary open packet networking architecture, but I still think the best way to do this (as I have indicated previously) is to design an entirely new protocol which we can label the common decendant of both. This is little different in practise from your suggestion, you might say, and there is something to that. However, it does avoid certain classes of pointless angst, such as the variety we are now experiencing. Let's assume for the sake of argument that we want a new packet layer very soon (an assumption I absolutely disagree with, as explained below). It is suggested that we are to take a protocol (CLNP) which both sides seem to keep saying is basically the same as IP, but has two major claimed advantages; longer addresses, and space for more options. (I will put to one side, for sake of clarity, debates about whether those longer addresses are what we need. I will also put to one side claims of disadvantages, like a less-well suited checksum, etc.) However, we aren't binding ourselves (for reasons of abilty to meet requirements) to keeping that protocol exactly the same. To me, this sounds like we have just voided the best argument for switching to a second protocol, which is the interoperability issue. Surely, if the Internet CLNP is functionally different in a useful way, it won't be interoperable, right? I mean, if all we are getting is larger addresses and space for more options, and have to make changes to the protocol which make it non- interoperable with vanilla implementations, surely we could get the same thing my modifying our existing network layer (IP) at the same effective cost. In fact, the cost would be less, since we wouldn't have to make some of the major changes to our protcol suite that a switch to a new network layer would entail (e.g. phasing in ES-IS, etc, etc). If we are going to modify an existing protocol to get what we need (and I don't agree we should be doing this at the moment), why switch to a totally different one to do it? I'm also less sanguine than you are about the ability to get the ISO world to track changes made here. Standards bodies *all* (including the IETF, I willingly admit) seem to have a bad case of N.I.H. I mean, look at IEEE; they just *couldn't* resist dinkering with Ethernet, a widely deployed and very sucessful standard. I *still* think the best interim path is to put off the adoption of a new packet layer as long as we possibly can, until we understand more about some major, little-understood, technical issues that a successful large scale networking infrastructure will have to face (such as resource allocation, pervasive network security, substantial auto-configuration, etc, etc.) This delay will also allow us a clearer vision of the physical network infra- structure of the future, includling things like Gigabiot nets, etc. I believe we can kill two birds with one stone: deploy an entirely new routing and addressing architecture, and maximize the lifetime of the current IP, by the simple expedient of changing the interpretation of the current 32 bit source/dest fields in a way that gives us a capability we have long wanted anyway. By the time that is thinking about running out of steam (and even if we only get 10% utilization of the 2^32 sized identifier space, we still get *four hundred million* hosts), we should know a lot more about these research topics, and can move straight to a third generation packet protocol. Noel From owner-big-internet@munnari.oz.au Tue Jul 7 05:27:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25022; Tue, 7 Jul 1992 05:27:26 +1000 (from owner-big-internet) Received: from MITVMA.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16355; Tue, 7 Jul 1992 01:17:21 +1000 (from @mitvma.mit.edu:owner-mod-ietf@searn.sunet.se) Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2) with BSMTP id 2249; Mon, 06 Jul 92 11:17:31 EDT Received: from FRORS12.BITNET by MITVMA.MIT.EDU (Mailer R2.08 R208004) with BSMTP id 2556; Mon, 06 Jul 92 11:17:28 EDT Received: by FRORS12 (Mailer R2.08 R208004) id 4974; Mon, 06 Jul 92 17:15:41 EDT Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6618 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:52 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7800; Mon, 06 Jul 92 17:06:36 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:32 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07225-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:53 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07601-0@survis.surfnet.nl>; Sun, 5 Jul 1992 09:08:05 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <19962-0@relay.surfnet.nl>; Sun, 5 Jul 1992 09:08:00 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa02964; 5 Jul 92 3:03 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id ab02960; 5 Jul 92 3:03 EDT Received: from GINGER.LCS.MIT.EDU by NRI.Reston.VA.US id aa25666; 5 Jul 92 3:04 EDT Received: by ginger.lcs.mit.edu id AA02711; Sun, 5 Jul 92 03:02:07 -0400 Return-Path: Date: Sun, 5 Jul 92 03:02:07 -0400 From: Noel Chiappa Message-Id: <9207050702.AA02711@ginger.lcs.mit.edu> To: BSMTP Subject: Re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Sender: owner-mod-ietf@searn.sunet.se Lyman: This sounds much like ideas for this suggested interaction between the Internet and OSI that I've heard from you in the past, and is a more sophisticated and plausible version of this than made it into the IAB I-D; it's too bad the multiple drafts the IAB went through didn't manage to work this in. Having read it, though, I am still left with the feeling that somewhere in a forest, 2+2 is not adding up to 4, as I'll explain in a bit. Mind you, I see the argument for having only a single non-proprietary open packet networking architecture, but I still think the best way to do this (as I have indicated previously) is to design an entirely new protocol which we can label the common decendant of both. This is little different in practise from your suggestion, you might say, and there is something to that. However, it does avoid certain classes of pointless angst, such as the variety we are now experiencing. Let's assume for the sake of argument that we want a new packet layer very soon (an assumption I absolutely disagree with, as explained below). It is suggested that we are to take a protocol (CLNP) which both sides seem to keep saying is basically the same as IP, but has two major claimed advantages; longer addresses, and space for more options. (I will put to one side, for sake of clarity, debates about whether those longer addresses are what we need. I will also put to one side claims of disadvantages, like a less-well suited checksum, etc.) However, we aren't binding ourselves (for reasons of abilty to meet requirements) to keeping that protocol exactly the same. To me, this sounds like we have just voided the best argument for switching to a second protocol, which is the interoperability issue. Surely, if the Internet CLNP is functionally different in a useful way, it won't be interoperable, right? I mean, if all we are getting is larger addresses and space for more options, and have to make changes to the protocol which make it non- interoperable with vanilla implementations, surely we could get the same thing my modifying our existing network layer (IP) at the same effective cost. In fact, the cost would be less, since we wouldn't have to make some of the major changes to our protcol suite that a switch to a new network layer would entail (e.g. phasing in ES-IS, etc, etc). If we are going to modify an existing protocol to get what we need (and I don't agree we should be doing this at the moment), why switch to a totally different one to do it? I'm also less sanguine than you are about the ability to get the ISO world to track changes made here. Standards bodies *all* (including the IETF, I willingly admit) seem to have a bad case of N.I.H. I mean, look at IEEE; they just *couldn't* resist dinkering with Ethernet, a widely deployed and very sucessful standard. I *still* think the best interim path is to put off the adoption of a new packet layer as long as we possibly can, until we understand more about some major, little-understood, technical issues that a successful large scale networking infrastructure will have to face (such as resource allocation, pervasive network security, substantial auto-configuration, etc, etc.) This delay will also allow us a clearer vision of the physical network infra- structure of the future, includling things like Gigabiot nets, etc. I believe we can kill two birds with one stone: deploy an entirely new routing and addressing architecture, and maximize the lifetime of the current IP, by the simple expedient of changing the interpretation of the current 32 bit source/dest fields in a way that gives us a capability we have long wanted anyway. By the time that is thinking about running out of steam (and even if we only get 10% utilization of the 2^32 sized identifier space, we still get *four hundred million* hosts), we should know a lot more about these research topics, and can move straight to a third generation packet protocol. Noel From owner-big-internet@munnari.oz.au Tue Jul 7 05:58:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25676; Tue, 7 Jul 1992 05:59:04 +1000 (from owner-big-internet) Return-Path: Message-Id: <9207061959.25676@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16025; Tue, 7 Jul 1992 01:04:43 +1000 (from lyman@BBN.COM) From: "Lyman Chapin" Subject: Re: IPv7 (CLNP) a mistake To: craig:; Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov In-Reply-To: <9207022308.AA28811@aland.bbn.com> Date: Mon, 6 Jul 92 10:18:21 EDT Mail-System-Version: >To: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, > ietf@isi.edu, road@lanl.gov >Subject: IPv7 (CLNP) a mistake >From: Craig Partridge >Date: Thu, 02 Jul 92 16:08:29 -0700 > > >I've read the IAB announcement, RFC 1347 and the Internet Draft, and am >afraid I view this idea of adopting CLNP as IPv7 as a disasterous idea. Craig, You're certainly not alone in this opinion! However, I think you have misunderstood some crucial elements of the IAB's plan, and made some assumptions that I (at least) don't think are valid. > >First, adopting CLNP means buying into the ISO standards process. Absolutely not. If I thought that this were true, mine would be the loudest voice arguing against the proposal, given the experience I've had with the formal ISO/CCITT standards process. Trading the Internet process for that of ISO would so clearly be a giant step backwards that I can't imagine anyone, even a die-hard OSI supporter, advocating it. For at least the past four years, almost every person working on CLNP and its relatives (addressing, routing protocols, and extensions) in ANSI and ISO has also been a committed Internet person. Every one of them prefers the IETF way of doing things to the ISO way. The people who actually manage and carry out the work on CLNP in ISO and the national standards bodies of the US, UK, Norway, Denmark, Japan, and Finland are Internet people. >While the Kobe announcement states that choosing CLNP is "not choosing OSI," >it is the case that we'd be choosing to make the network layer of the Internet >protocol suite the same as the OSI protocol suite. As such, we have >to face the painful reality that any future changes that the Internet >community wishes to see in the network layer will require ISO approval too. I'm tempted to just ask "why?", but that might sound disingenuous. Any change to CLNP that is necessary for CLNP to operate as the internetwork protocol of the Internet is, by definition, a change that all but one or two of the ISO people working on CLNP would support. It is hard to imagine ISO failing to approve such a change - who would vote against it? The voters would almost all be Internet people. ISO approval, assuming it is considered to be necessary, would inevitably lag IETF/IAB approval by a year or so, but with the reality of CLNP evolution fixed firmly in the IETF/IAB arena, who would care? >ISO and the Internet community have radically different views about >the standards making process (e.g. testing before standardizing, whether >to bill for standards, and the like). Indeed, the Internet community >decided not to join up with ANSI/ISO a few years ago because both >communities felt there were incompatibilities in their processes. >Now we're proposing to buy into the ISO process to manage our network layer. >We'll all have to learn the detailed workings of the ISO process if >we want to change the network layer -- and since it requires some >number of meetings to be ANSI/ISO accredited, we'd better all start >attending those meetings now (in addition to our IETF meetings) so Agghhh! I've been doing that for too many years - believe me, you wouldn't wish it on your enemies, much less your friends in the IETF! True, you'll have to know more about what ISO is doing on the network layer than you do now, but the pain will be far less than what you've described above. >we can be prepared to defend our ideas in the ISO process. Do we >really want to pass much (all?) of our control over the Internet >network layer to a process that the Internet community finds >incompatible? As we've clearly stated in RFC 1310, the IAB does not accept Internet standards over which we don't have change control. If CLNP becomes IPv7, and we decide that IPv7 must be changed in some way to improve its useful- ness to the Internet, then that change will be made. If ISO later (with ISO, unfortunately, it's always going to be "later"...) agrees to also make the change, then that will be very good (as you point out below, the best situation would be for IPv7 and ISO-CLNP to stay the same), and I expect that the people currently working on CLNP in ISO (and the companies that have been supporting them) will consider it very important to make this happen. However, it is not essential - if, for some reason, ISO decides *not* to go along, IPv7 won't suddenly stop working. With the number of interests that will be served by making sure that ISO *does* track any IPv7 evolution in the Internet, I don't foresee this happening (but, to be fair, recognize that it's a possibility). The IAB/IETF process determines what happens to IPv7, and ISO may, if it wishes, follow suit - not the other way around. > >(I've heard at least one person suggest that if ISO doesn't like >Internet-proposed changes, we'll just publish our own version of CLNP. >Ignoring ISO copyright issues about issuing a modified ISO spec [which >may or may not prove to big deal], I don't buy this idea. First, why >even call this new network layer CLNP unless we believe we mean to keep >in sync. Second, having an Internet and an ISO CLNP means that vendors >will have to support two versions of CLNP, which they won't like. ...and, since they are the people who have been determining the evolution of CLNP in ISO, they will presumably spend the effort to make sure that this doesn't happen (whom could it possibly benefit?)... >Consider how much folks already complain about the different GOSIPs. >We'll find ourselves in a tremendous vise to harmonize with ISO. We've >tried that twice before, with CMIP over TCP and IS-IS. In one case, >the idea was a complete flop but only after a waste of some years of >effort. In neither case was the process pleasant. I don't think we >want more of these kinds of problems.). > >Second, CLNP deals with only *one* of the several issues facing IP, namely >address depletion. At the same time, it forces us to take a giant step >back on other issues. CLNP does *not* support multicasting. There >are proposals in the works to add it -- but that means CLNP is about five >years behind IP on this topic. IP multicast is working now and it has >taken a lot of effort -- it is in products (Solaris 2.0) and in >BSD (4.4 and mods are available for 4.3). We're making good progress >on mobile host support. Some experimental implementations under >IP are getting heavy use. We'll have to go back to the CLNP drawing >board on those projects too. Ideas to support multimedia applications are >fast becoming reality (witness the recent IETF multicasts on the >Internet). If we buy CLNP we'll have to wait a few years for ISO >to approve those extensions. With the exception of a brief mentions >about leaving space for options and making sure that multicast will >somehow be supported, the various documents don't address this issue. This is a very pessimistic viewpoint, and one with which I simply don't agree. It's misleading to say "CLNP does *not* support multicasting" - neither does IP (IGRP, OSPF, and BGP do), and since the architecture of CLNP internetworking is identical to that of IP, there is no reason to expect that the work involved in expressing new stuff in CLNP rather than IP is anything like "going back to the drawing board". If CLNP becomes IPv7, I don't expect anyone to suddenly stop working on innovations based on IPv4 - that's what's out there (and no IPv4-->IPv7 shift is going to happen overnight). But there is no reason to think that the work based on IPv4 will not be directly applicable to IPv7 - and factoring good ideas into CLNP is something that vendors are likely to be motivated to do any- way, whether the result is called "CLNP" in a dual-stack IP/CLNP product or "IPv7" in a dual-stack IPv4/IPv7 product. The statement "If we buy CLNP we'll have to wait a few years for ISO to approve those extenstions" is simply false. Clearly the IAB intends for the Internet community to own IPv7. Why would we hold up an extension "waiting for ISO"? (there's a potential pun lurking there, which I will resist pursuing....) > >In short, CLNP as IPv7 seems destined to be a technical step backwards >and to place a severe crimp on protocol innovation at a time when we >need to innovate. (Some folks have expressed concern that the rise in >voice and multimedia on the Internet will stress IP *this* year. To my >knowledge, no one has tried running voice over CLNP). Are we so sure >that we should choose CLNP with all its limitations, especially now that >CIDR gives us a bit of breathing room in which to think? Are we so sure >CLNP is the right decision that we shouldn't even consider developing at >least one other approach in parallel, just in case we discover CLNP >really is a tar baby? CLNP as IPv7 is not intended to be any improvement on IP with respect to new Internet applications (including voice and multimedia) - it is intended only to stave off the ROAD problems, while research proceeds on a genuinely "new" internet protocol. The IAB doesn't believe that it is wise or prudent to place such a heavy bet on CIDR (which may or may not give us "enough" breathing room, depending on a lot of factors that are difficult to predict accurately enough to confidently hedge the bet). And I strongly suspect that people will continue to work on IPAE and other proposals with or without the IAB's blessing, notwithstanding our explicit recommendation that people focus their efforts on the unresolved issues surrounding a CLNP-based IPv7. > >Craig - Lyman From owner-Big-Internet@munnari.oz.au Tue Jul 7 05:58:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25679; Tue, 7 Jul 1992 05:59:04 +1000 (from owner-Big-Internet) Return-Path: Received: from bellcore.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25674; Tue, 7 Jul 1992 05:58:51 +1000 (from mo@gizmo.bellcore.com) Received: from gizmo.bellcore.com by bellcore.bellcore.com (5.61/1.34) id AA28050; Mon, 6 Jul 92 15:58:40 -0400 Message-Id: <9207061958.AA28050@bellcore.bellcore.com> To: big-internet@munnari.oz.au Subject: what headlines.... Date: Mon, 06 Jul 92 15:58:31 -0400 From: mo@gizmo.bellcore.com Communications Week 7/6/92: "Internet Board to Vote On IP Fix" " With little warning, the Internet Architecture Board has decided to change the way the Internet handles addressing, leaving users only two weeks to express their opinions on how to do it." and it goes on from there. I'm sure this article will engender the undying love of all the companies out there trying to make a living selling Internet technology, goods, and services. -Mike From owner-big-internet@munnari.oz.au Tue Jul 7 06:05:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25834; Tue, 7 Jul 1992 06:05:56 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16254; Tue, 7 Jul 1992 01:13:41 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 9994; Mon, 06 Jul 92 17:12:59 MET Received: by DEARN (Mailer R2.08) id 2560; Mon, 06 Jul 92 17:12:57 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6616 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:11 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7792; Mon, 06 Jul 92 17:06:09 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:05 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07183-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:16 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <05434-0@survis.surfnet.nl>; Sun, 5 Jul 1992 00:20:43 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <17504-0@relay.surfnet.nl>; Sun, 5 Jul 1992 00:20:39 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id ab01921; 4 Jul 92 18:15 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01917; 4 Jul 92 18:15 EDT Received: from BBN.COM by NRI.Reston.VA.US id aa17283; 4 Jul 92 18:16 EDT Return-Path: From: Lyman Chapin Subject: Re: IPv7 (CLNP) a mistake To: BSMTP Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov In-Reply-To: <9207022308.AA28811@aland.bbn.com> Date: Sat, 4 Jul 92 17:52:41 EDT Mail-System-Version: Message-Id: <9207041816.aa17283@NRI.Reston.VA.US> Sender: owner-mod-ietf@searn.sunet.se >To: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, > ietf@isi.edu, road@lanl.gov >Subject: IPv7 (CLNP) a mistake >From: Craig Partridge >Date: Thu, 02 Jul 92 16:08:29 -0700 > > >I've read the IAB announcement, RFC 1347 and the Internet Draft, and am >afraid I view this idea of adopting CLNP as IPv7 as a disasterous idea. Craig, You're certainly not alone in this opinion! However, I think you have misunderstood some crucial elements of the IAB's plan, and made some assumptions that I (at least) don't think are valid. > >First, adopting CLNP means buying into the ISO standards process. Absolutely not. If I thought that this were true, mine would be the loudest voice arguing against the proposal, given the experience I've had with the formal ISO/CCITT standards process. Trading the Internet process for that of ISO would so clearly be a giant step backwards that I can't imagine anyone, even a die-hard OSI supporter, advocating it. For at least the past four years, almost every person working on CLNP and its relatives (addressing, routing protocols, and extensions) in ANSI and ISO has also been a committed Internet person. Every one of them prefers the IETF way of doing things to the ISO way. The people who actually manage and carry out the work on CLNP in ISO and the national standards bodies of the US, UK, Norway, Denmark, Japan, and Finland are Internet people. >While the Kobe announcement states that choosing CLNP is "not choosing OSI," >it is the case that we'd be choosing to make the network layer of the Internet >protocol suite the same as the OSI protocol suite. As such, we have >to face the painful reality that any future changes that the Internet >community wishes to see in the network layer will require ISO approval too. I'm tempted to just ask "why?", but that might sound disingenuous. Any change to CLNP that is necessary for CLNP to operate as the internetwork protocol of the Internet is, by definition, a change that all but one or two of the ISO people working on CLNP would support. It is hard to imagine ISO failing to approve such a change - who would vote against it? The voters would almost all be Internet people. ISO approval, assuming it is considered to be necessary, would inevitably lag IETF/IAB approval by a year or so, but with the reality of CLNP evolution fixed firmly in the IETF/IAB arena, who would care? >ISO and the Internet community have radically different views about >the standards making process (e.g. testing before standardizing, whether >to bill for standards, and the like). Indeed, the Internet community >decided not to join up with ANSI/ISO a few years ago because both >communities felt there were incompatibilities in their processes. >Now we're proposing to buy into the ISO process to manage our network layer. >We'll all have to learn the detailed workings of the ISO process if >we want to change the network layer -- and since it requires some >number of meetings to be ANSI/ISO accredited, we'd better all start >attending those meetings now (in addition to our IETF meetings) so Agghhh! I've been doing that for too many years - believe me, you wouldn't wish it on your enemies, much less your friends in the IETF! True, you'll have to know more about what ISO is doing on the network layer than you do now, but the pain will be far less than what you've described above. >we can be prepared to defend our ideas in the ISO process. Do we >really want to pass much (all?) of our control over the Internet >network layer to a process that the Internet community finds >incompatible? As we've clearly stated in RFC 1310, the IAB does not accept Internet standards over which we don't have change control. If CLNP becomes IPv7, and we decide that IPv7 must be changed in some way to improve its useful- ness to the Internet, then that change will be made. If ISO later (with ISO, unfortunately, it's always going to be "later"...) agrees to also make the change, then that will be very good (as you point out below, the best situation would be for IPv7 and ISO-CLNP to stay the same), and I expect that the people currently working on CLNP in ISO (and the companies that have been supporting them) will consider it very important to make this happen. However, it is not essential - if, for some reason, ISO decides *not* to go along, IPv7 won't suddenly stop working. With the number of interests that will be served by making sure that ISO *does* track any IPv7 evolution in the Internet, I don't foresee this happening (but, to be fair, recognize that it's a possibility). The IAB/IETF process determines what happens to IPv7, and ISO may, if it wishes, follow suit - not the other way around. > >(I've heard at least one person suggest that if ISO doesn't like >Internet-proposed changes, we'll just publish our own version of CLNP. >Ignoring ISO copyright issues about issuing a modified ISO spec [which >may or may not prove to big deal], I don't buy this idea. First, why >even call this new network layer CLNP unless we believe we mean to keep >in sync. Second, having an Internet and an ISO CLNP means that vendors >will have to support two versions of CLNP, which they won't like. ..and, since they are the people who have been determining the evolution of CLNP in ISO, they will presumably spend the effort to make sure that this doesn't happen (whom could it possibly benefit?)... >Consider how much folks already complain about the different GOSIPs. >We'll find ourselves in a tremendous vise to harmonize with ISO. We've >tried that twice before, with CMIP over TCP and IS-IS. In one case, >the idea was a complete flop but only after a waste of some years of >effort. In neither case was the process pleasant. I don't think we >want more of these kinds of problems.). > >Second, CLNP deals with only *one* of the several issues facing IP, namely >address depletion. At the same time, it forces us to take a giant step >back on other issues. CLNP does *not* support multicasting. There >are proposals in the works to add it -- but that means CLNP is about five >years behind IP on this topic. IP multicast is working now and it has >taken a lot of effort -- it is in products (Solaris 2.0) and in >BSD (4.4 and mods are available for 4.3). We're making good progress >on mobile host support. Some experimental implementations under >IP are getting heavy use. We'll have to go back to the CLNP drawing >board on those projects too. Ideas to support multimedia applications are >fast becoming reality (witness the recent IETF multicasts on the >Internet). If we buy CLNP we'll have to wait a few years for ISO >to approve those extensions. With the exception of a brief mentions >about leaving space for options and making sure that multicast will >somehow be supported, the various documents don't address this issue. This is a very pessimistic viewpoint, and one with which I simply don't agree. It's misleading to say "CLNP does *not* support multicasting" - neither does IP (IGRP, OSPF, and BGP do), and since the architecture of CLNP internetworking is identical to that of IP, there is no reason to expect that the work involved in expressing new stuff in CLNP rather than IP is anything like "going back to the drawing board". If CLNP becomes IPv7, I don't expect anyone to suddenly stop working on innovations based on IPv4 - that's what's out there (and no IPv4-->IPv7 shift is going to happen overnight). But there is no reason to think that the work based on IPv4 will not be directly applicable to IPv7 - and factoring good ideas into CLNP is something that vendors are likely to be motivated to do any- way, whether the result is called "CLNP" in a dual-stack IP/CLNP product or "IPv7" in a dual-stack IPv4/IPv7 product. The statement "If we buy CLNP we'll have to wait a few years for ISO to approve those extenstions" is simply false. Clearly the IAB intends for the Internet community to own IPv7. Why would we hold up an extension "waiting for ISO"? (there's a potential pun lurking there, which I will resist pursuing....) > >In short, CLNP as IPv7 seems destined to be a technical step backwards >and to place a severe crimp on protocol innovation at a time when we >need to innovate. (Some folks have expressed concern that the rise in >voice and multimedia on the Internet will stress IP *this* year. To my >knowledge, no one has tried running voice over CLNP). Are we so sure >that we should choose CLNP with all its limitations, especially now that >CIDR gives us a bit of breathing room in which to think? Are we so sure >CLNP is the right decision that we shouldn't even consider developing at >least one other approach in parallel, just in case we discover CLNP >really is a tar baby? CLNP as IPv7 is not intended to be any improvement on IP with respect to new Internet applications (including voice and multimedia) - it is intended only to stave off the ROAD problems, while research proceeds on a genuinely "new" internet protocol. The IAB doesn't believe that it is wise or prudent to place such a heavy bet on CIDR (which may or may not give us "enough" breathing room, depending on a lot of factors that are difficult to predict accurately enough to confidently hedge the bet). And I strongly suspect that people will continue to work on IPAE and other proposals with or without the IAB's blessing, notwithstanding our explicit recommendation that people focus their efforts on the unresolved issues surrounding a CLNP-based IPv7. > >Craig - Lyman From owner-big-internet@munnari.oz.au Tue Jul 7 06:12:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25951; Tue, 7 Jul 1992 06:12:59 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16269; Tue, 7 Jul 1992 01:13:55 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 9995; Mon, 06 Jul 92 17:13:00 MET Received: by DEARN (Mailer R2.08) id 2561; Mon, 06 Jul 92 17:12:59 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6616 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:11 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7792; Mon, 06 Jul 92 17:06:09 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:05 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07183-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:16 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <05434-0@survis.surfnet.nl>; Sun, 5 Jul 1992 00:20:43 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <17504-0@relay.surfnet.nl>; Sun, 5 Jul 1992 00:20:39 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id ab01921; 4 Jul 92 18:15 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01917; 4 Jul 92 18:15 EDT Received: from BBN.COM by NRI.Reston.VA.US id aa17283; 4 Jul 92 18:16 EDT Return-Path: From: Lyman Chapin Subject: Re: IPv7 (CLNP) a mistake To: BSMTP Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov In-Reply-To: <9207022308.AA28811@aland.bbn.com> Date: Sat, 4 Jul 92 17:52:41 EDT Mail-System-Version: Message-Id: <9207041816.aa17283@NRI.Reston.VA.US> Sender: owner-mod-ietf@searn.sunet.se >To: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, > ietf@isi.edu, road@lanl.gov >Subject: IPv7 (CLNP) a mistake >From: Craig Partridge >Date: Thu, 02 Jul 92 16:08:29 -0700 > > >I've read the IAB announcement, RFC 1347 and the Internet Draft, and am >afraid I view this idea of adopting CLNP as IPv7 as a disasterous idea. Craig, You're certainly not alone in this opinion! However, I think you have misunderstood some crucial elements of the IAB's plan, and made some assumptions that I (at least) don't think are valid. > >First, adopting CLNP means buying into the ISO standards process. Absolutely not. If I thought that this were true, mine would be the loudest voice arguing against the proposal, given the experience I've had with the formal ISO/CCITT standards process. Trading the Internet process for that of ISO would so clearly be a giant step backwards that I can't imagine anyone, even a die-hard OSI supporter, advocating it. For at least the past four years, almost every person working on CLNP and its relatives (addressing, routing protocols, and extensions) in ANSI and ISO has also been a committed Internet person. Every one of them prefers the IETF way of doing things to the ISO way. The people who actually manage and carry out the work on CLNP in ISO and the national standards bodies of the US, UK, Norway, Denmark, Japan, and Finland are Internet people. >While the Kobe announcement states that choosing CLNP is "not choosing OSI," >it is the case that we'd be choosing to make the network layer of the Internet >protocol suite the same as the OSI protocol suite. As such, we have >to face the painful reality that any future changes that the Internet >community wishes to see in the network layer will require ISO approval too. I'm tempted to just ask "why?", but that might sound disingenuous. Any change to CLNP that is necessary for CLNP to operate as the internetwork protocol of the Internet is, by definition, a change that all but one or two of the ISO people working on CLNP would support. It is hard to imagine ISO failing to approve such a change - who would vote against it? The voters would almost all be Internet people. ISO approval, assuming it is considered to be necessary, would inevitably lag IETF/IAB approval by a year or so, but with the reality of CLNP evolution fixed firmly in the IETF/IAB arena, who would care? >ISO and the Internet community have radically different views about >the standards making process (e.g. testing before standardizing, whether >to bill for standards, and the like). Indeed, the Internet community >decided not to join up with ANSI/ISO a few years ago because both >communities felt there were incompatibilities in their processes. >Now we're proposing to buy into the ISO process to manage our network layer. >We'll all have to learn the detailed workings of the ISO process if >we want to change the network layer -- and since it requires some >number of meetings to be ANSI/ISO accredited, we'd better all start >attending those meetings now (in addition to our IETF meetings) so Agghhh! I've been doing that for too many years - believe me, you wouldn't wish it on your enemies, much less your friends in the IETF! True, you'll have to know more about what ISO is doing on the network layer than you do now, but the pain will be far less than what you've described above. >we can be prepared to defend our ideas in the ISO process. Do we >really want to pass much (all?) of our control over the Internet >network layer to a process that the Internet community finds >incompatible? As we've clearly stated in RFC 1310, the IAB does not accept Internet standards over which we don't have change control. If CLNP becomes IPv7, and we decide that IPv7 must be changed in some way to improve its useful- ness to the Internet, then that change will be made. If ISO later (with ISO, unfortunately, it's always going to be "later"...) agrees to also make the change, then that will be very good (as you point out below, the best situation would be for IPv7 and ISO-CLNP to stay the same), and I expect that the people currently working on CLNP in ISO (and the companies that have been supporting them) will consider it very important to make this happen. However, it is not essential - if, for some reason, ISO decides *not* to go along, IPv7 won't suddenly stop working. With the number of interests that will be served by making sure that ISO *does* track any IPv7 evolution in the Internet, I don't foresee this happening (but, to be fair, recognize that it's a possibility). The IAB/IETF process determines what happens to IPv7, and ISO may, if it wishes, follow suit - not the other way around. > >(I've heard at least one person suggest that if ISO doesn't like >Internet-proposed changes, we'll just publish our own version of CLNP. >Ignoring ISO copyright issues about issuing a modified ISO spec [which >may or may not prove to big deal], I don't buy this idea. First, why >even call this new network layer CLNP unless we believe we mean to keep >in sync. Second, having an Internet and an ISO CLNP means that vendors >will have to support two versions of CLNP, which they won't like. ..and, since they are the people who have been determining the evolution of CLNP in ISO, they will presumably spend the effort to make sure that this doesn't happen (whom could it possibly benefit?)... >Consider how much folks already complain about the different GOSIPs. >We'll find ourselves in a tremendous vise to harmonize with ISO. We've >tried that twice before, with CMIP over TCP and IS-IS. In one case, >the idea was a complete flop but only after a waste of some years of >effort. In neither case was the process pleasant. I don't think we >want more of these kinds of problems.). > >Second, CLNP deals with only *one* of the several issues facing IP, namely >address depletion. At the same time, it forces us to take a giant step >back on other issues. CLNP does *not* support multicasting. There >are proposals in the works to add it -- but that means CLNP is about five >years behind IP on this topic. IP multicast is working now and it has >taken a lot of effort -- it is in products (Solaris 2.0) and in >BSD (4.4 and mods are available for 4.3). We're making good progress >on mobile host support. Some experimental implementations under >IP are getting heavy use. We'll have to go back to the CLNP drawing >board on those projects too. Ideas to support multimedia applications are >fast becoming reality (witness the recent IETF multicasts on the >Internet). If we buy CLNP we'll have to wait a few years for ISO >to approve those extensions. With the exception of a brief mentions >about leaving space for options and making sure that multicast will >somehow be supported, the various documents don't address this issue. This is a very pessimistic viewpoint, and one with which I simply don't agree. It's misleading to say "CLNP does *not* support multicasting" - neither does IP (IGRP, OSPF, and BGP do), and since the architecture of CLNP internetworking is identical to that of IP, there is no reason to expect that the work involved in expressing new stuff in CLNP rather than IP is anything like "going back to the drawing board". If CLNP becomes IPv7, I don't expect anyone to suddenly stop working on innovations based on IPv4 - that's what's out there (and no IPv4-->IPv7 shift is going to happen overnight). But there is no reason to think that the work based on IPv4 will not be directly applicable to IPv7 - and factoring good ideas into CLNP is something that vendors are likely to be motivated to do any- way, whether the result is called "CLNP" in a dual-stack IP/CLNP product or "IPv7" in a dual-stack IPv4/IPv7 product. The statement "If we buy CLNP we'll have to wait a few years for ISO to approve those extenstions" is simply false. Clearly the IAB intends for the Internet community to own IPv7. Why would we hold up an extension "waiting for ISO"? (there's a potential pun lurking there, which I will resist pursuing....) > >In short, CLNP as IPv7 seems destined to be a technical step backwards >and to place a severe crimp on protocol innovation at a time when we >need to innovate. (Some folks have expressed concern that the rise in >voice and multimedia on the Internet will stress IP *this* year. To my >knowledge, no one has tried running voice over CLNP). Are we so sure >that we should choose CLNP with all its limitations, especially now that >CIDR gives us a bit of breathing room in which to think? Are we so sure >CLNP is the right decision that we shouldn't even consider developing at >least one other approach in parallel, just in case we discover CLNP >really is a tar baby? CLNP as IPv7 is not intended to be any improvement on IP with respect to new Internet applications (including voice and multimedia) - it is intended only to stave off the ROAD problems, while research proceeds on a genuinely "new" internet protocol. The IAB doesn't believe that it is wise or prudent to place such a heavy bet on CIDR (which may or may not give us "enough" breathing room, depending on a lot of factors that are difficult to predict accurately enough to confidently hedge the bet). And I strongly suspect that people will continue to work on IPAE and other proposals with or without the IAB's blessing, notwithstanding our explicit recommendation that people focus their efforts on the unresolved issues surrounding a CLNP-based IPv7. > >Craig - Lyman From owner-big-internet@munnari.oz.au Tue Jul 7 06:19:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26052; Tue, 7 Jul 1992 06:19:20 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16272; Tue, 7 Jul 1992 01:14:09 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 9996; Mon, 06 Jul 92 17:13:02 MET Received: by DEARN (Mailer R2.08) id 2563; Mon, 06 Jul 92 17:13:00 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6616 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:11 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7792; Mon, 06 Jul 92 17:06:09 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:05 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07183-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:16 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <05434-0@survis.surfnet.nl>; Sun, 5 Jul 1992 00:20:43 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <17504-0@relay.surfnet.nl>; Sun, 5 Jul 1992 00:20:39 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id ab01921; 4 Jul 92 18:15 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01917; 4 Jul 92 18:15 EDT Received: from BBN.COM by NRI.Reston.VA.US id aa17283; 4 Jul 92 18:16 EDT Return-Path: From: Lyman Chapin Subject: Re: IPv7 (CLNP) a mistake To: BSMTP Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov In-Reply-To: <9207022308.AA28811@aland.bbn.com> Date: Sat, 4 Jul 92 17:52:41 EDT Mail-System-Version: Message-Id: <9207041816.aa17283@NRI.Reston.VA.US> Sender: owner-mod-ietf@searn.sunet.se >To: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, > ietf@isi.edu, road@lanl.gov >Subject: IPv7 (CLNP) a mistake >From: Craig Partridge >Date: Thu, 02 Jul 92 16:08:29 -0700 > > >I've read the IAB announcement, RFC 1347 and the Internet Draft, and am >afraid I view this idea of adopting CLNP as IPv7 as a disasterous idea. Craig, You're certainly not alone in this opinion! However, I think you have misunderstood some crucial elements of the IAB's plan, and made some assumptions that I (at least) don't think are valid. > >First, adopting CLNP means buying into the ISO standards process. Absolutely not. If I thought that this were true, mine would be the loudest voice arguing against the proposal, given the experience I've had with the formal ISO/CCITT standards process. Trading the Internet process for that of ISO would so clearly be a giant step backwards that I can't imagine anyone, even a die-hard OSI supporter, advocating it. For at least the past four years, almost every person working on CLNP and its relatives (addressing, routing protocols, and extensions) in ANSI and ISO has also been a committed Internet person. Every one of them prefers the IETF way of doing things to the ISO way. The people who actually manage and carry out the work on CLNP in ISO and the national standards bodies of the US, UK, Norway, Denmark, Japan, and Finland are Internet people. >While the Kobe announcement states that choosing CLNP is "not choosing OSI," >it is the case that we'd be choosing to make the network layer of the Internet >protocol suite the same as the OSI protocol suite. As such, we have >to face the painful reality that any future changes that the Internet >community wishes to see in the network layer will require ISO approval too. I'm tempted to just ask "why?", but that might sound disingenuous. Any change to CLNP that is necessary for CLNP to operate as the internetwork protocol of the Internet is, by definition, a change that all but one or two of the ISO people working on CLNP would support. It is hard to imagine ISO failing to approve such a change - who would vote against it? The voters would almost all be Internet people. ISO approval, assuming it is considered to be necessary, would inevitably lag IETF/IAB approval by a year or so, but with the reality of CLNP evolution fixed firmly in the IETF/IAB arena, who would care? >ISO and the Internet community have radically different views about >the standards making process (e.g. testing before standardizing, whether >to bill for standards, and the like). Indeed, the Internet community >decided not to join up with ANSI/ISO a few years ago because both >communities felt there were incompatibilities in their processes. >Now we're proposing to buy into the ISO process to manage our network layer. >We'll all have to learn the detailed workings of the ISO process if >we want to change the network layer -- and since it requires some >number of meetings to be ANSI/ISO accredited, we'd better all start >attending those meetings now (in addition to our IETF meetings) so Agghhh! I've been doing that for too many years - believe me, you wouldn't wish it on your enemies, much less your friends in the IETF! True, you'll have to know more about what ISO is doing on the network layer than you do now, but the pain will be far less than what you've described above. >we can be prepared to defend our ideas in the ISO process. Do we >really want to pass much (all?) of our control over the Internet >network layer to a process that the Internet community finds >incompatible? As we've clearly stated in RFC 1310, the IAB does not accept Internet standards over which we don't have change control. If CLNP becomes IPv7, and we decide that IPv7 must be changed in some way to improve its useful- ness to the Internet, then that change will be made. If ISO later (with ISO, unfortunately, it's always going to be "later"...) agrees to also make the change, then that will be very good (as you point out below, the best situation would be for IPv7 and ISO-CLNP to stay the same), and I expect that the people currently working on CLNP in ISO (and the companies that have been supporting them) will consider it very important to make this happen. However, it is not essential - if, for some reason, ISO decides *not* to go along, IPv7 won't suddenly stop working. With the number of interests that will be served by making sure that ISO *does* track any IPv7 evolution in the Internet, I don't foresee this happening (but, to be fair, recognize that it's a possibility). The IAB/IETF process determines what happens to IPv7, and ISO may, if it wishes, follow suit - not the other way around. > >(I've heard at least one person suggest that if ISO doesn't like >Internet-proposed changes, we'll just publish our own version of CLNP. >Ignoring ISO copyright issues about issuing a modified ISO spec [which >may or may not prove to big deal], I don't buy this idea. First, why >even call this new network layer CLNP unless we believe we mean to keep >in sync. Second, having an Internet and an ISO CLNP means that vendors >will have to support two versions of CLNP, which they won't like. ..and, since they are the people who have been determining the evolution of CLNP in ISO, they will presumably spend the effort to make sure that this doesn't happen (whom could it possibly benefit?)... >Consider how much folks already complain about the different GOSIPs. >We'll find ourselves in a tremendous vise to harmonize with ISO. We've >tried that twice before, with CMIP over TCP and IS-IS. In one case, >the idea was a complete flop but only after a waste of some years of >effort. In neither case was the process pleasant. I don't think we >want more of these kinds of problems.). > >Second, CLNP deals with only *one* of the several issues facing IP, namely >address depletion. At the same time, it forces us to take a giant step >back on other issues. CLNP does *not* support multicasting. There >are proposals in the works to add it -- but that means CLNP is about five >years behind IP on this topic. IP multicast is working now and it has >taken a lot of effort -- it is in products (Solaris 2.0) and in >BSD (4.4 and mods are available for 4.3). We're making good progress >on mobile host support. Some experimental implementations under >IP are getting heavy use. We'll have to go back to the CLNP drawing >board on those projects too. Ideas to support multimedia applications are >fast becoming reality (witness the recent IETF multicasts on the >Internet). If we buy CLNP we'll have to wait a few years for ISO >to approve those extensions. With the exception of a brief mentions >about leaving space for options and making sure that multicast will >somehow be supported, the various documents don't address this issue. This is a very pessimistic viewpoint, and one with which I simply don't agree. It's misleading to say "CLNP does *not* support multicasting" - neither does IP (IGRP, OSPF, and BGP do), and since the architecture of CLNP internetworking is identical to that of IP, there is no reason to expect that the work involved in expressing new stuff in CLNP rather than IP is anything like "going back to the drawing board". If CLNP becomes IPv7, I don't expect anyone to suddenly stop working on innovations based on IPv4 - that's what's out there (and no IPv4-->IPv7 shift is going to happen overnight). But there is no reason to think that the work based on IPv4 will not be directly applicable to IPv7 - and factoring good ideas into CLNP is something that vendors are likely to be motivated to do any- way, whether the result is called "CLNP" in a dual-stack IP/CLNP product or "IPv7" in a dual-stack IPv4/IPv7 product. The statement "If we buy CLNP we'll have to wait a few years for ISO to approve those extenstions" is simply false. Clearly the IAB intends for the Internet community to own IPv7. Why would we hold up an extension "waiting for ISO"? (there's a potential pun lurking there, which I will resist pursuing....) > >In short, CLNP as IPv7 seems destined to be a technical step backwards >and to place a severe crimp on protocol innovation at a time when we >need to innovate. (Some folks have expressed concern that the rise in >voice and multimedia on the Internet will stress IP *this* year. To my >knowledge, no one has tried running voice over CLNP). Are we so sure >that we should choose CLNP with all its limitations, especially now that >CIDR gives us a bit of breathing room in which to think? Are we so sure >CLNP is the right decision that we shouldn't even consider developing at >least one other approach in parallel, just in case we discover CLNP >really is a tar baby? CLNP as IPv7 is not intended to be any improvement on IP with respect to new Internet applications (including voice and multimedia) - it is intended only to stave off the ROAD problems, while research proceeds on a genuinely "new" internet protocol. The IAB doesn't believe that it is wise or prudent to place such a heavy bet on CIDR (which may or may not give us "enough" breathing room, depending on a lot of factors that are difficult to predict accurately enough to confidently hedge the bet). And I strongly suspect that people will continue to work on IPAE and other proposals with or without the IAB's blessing, notwithstanding our explicit recommendation that people focus their efforts on the unresolved issues surrounding a CLNP-based IPv7. > >Craig - Lyman From owner-big-internet@munnari.oz.au Tue Jul 7 06:29:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26282; Tue, 7 Jul 1992 06:29:23 +1000 (from owner-big-internet) Received: from MITVMA.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16266; Tue, 7 Jul 1992 01:13:53 +1000 (from @mitvma.mit.edu:owner-mod-ietf@searn.sunet.se) Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2) with BSMTP id 2218; Mon, 06 Jul 92 11:14:01 EDT Received: from FRORS12.BITNET by MITVMA.MIT.EDU (Mailer R2.08 R208004) with BSMTP id 2470; Mon, 06 Jul 92 11:13:59 EDT Received: by FRORS12 (Mailer R2.08 R208004) id 4909; Mon, 06 Jul 92 17:13:52 EDT Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6616 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:11 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7792; Mon, 06 Jul 92 17:06:09 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:05 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07183-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:16 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <05434-0@survis.surfnet.nl>; Sun, 5 Jul 1992 00:20:43 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <17504-0@relay.surfnet.nl>; Sun, 5 Jul 1992 00:20:39 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id ab01921; 4 Jul 92 18:15 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01917; 4 Jul 92 18:15 EDT Received: from BBN.COM by NRI.Reston.VA.US id aa17283; 4 Jul 92 18:16 EDT Return-Path: From: Lyman Chapin Subject: Re: IPv7 (CLNP) a mistake To: BSMTP Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov In-Reply-To: <9207022308.AA28811@aland.bbn.com> Date: Sat, 4 Jul 92 17:52:41 EDT Mail-System-Version: Message-Id: <9207041816.aa17283@NRI.Reston.VA.US> Sender: owner-mod-ietf@searn.sunet.se >To: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, > ietf@isi.edu, road@lanl.gov >Subject: IPv7 (CLNP) a mistake >From: Craig Partridge >Date: Thu, 02 Jul 92 16:08:29 -0700 > > >I've read the IAB announcement, RFC 1347 and the Internet Draft, and am >afraid I view this idea of adopting CLNP as IPv7 as a disasterous idea. Craig, You're certainly not alone in this opinion! However, I think you have misunderstood some crucial elements of the IAB's plan, and made some assumptions that I (at least) don't think are valid. > >First, adopting CLNP means buying into the ISO standards process. Absolutely not. If I thought that this were true, mine would be the loudest voice arguing against the proposal, given the experience I've had with the formal ISO/CCITT standards process. Trading the Internet process for that of ISO would so clearly be a giant step backwards that I can't imagine anyone, even a die-hard OSI supporter, advocating it. For at least the past four years, almost every person working on CLNP and its relatives (addressing, routing protocols, and extensions) in ANSI and ISO has also been a committed Internet person. Every one of them prefers the IETF way of doing things to the ISO way. The people who actually manage and carry out the work on CLNP in ISO and the national standards bodies of the US, UK, Norway, Denmark, Japan, and Finland are Internet people. >While the Kobe announcement states that choosing CLNP is "not choosing OSI," >it is the case that we'd be choosing to make the network layer of the Internet >protocol suite the same as the OSI protocol suite. As such, we have >to face the painful reality that any future changes that the Internet >community wishes to see in the network layer will require ISO approval too. I'm tempted to just ask "why?", but that might sound disingenuous. Any change to CLNP that is necessary for CLNP to operate as the internetwork protocol of the Internet is, by definition, a change that all but one or two of the ISO people working on CLNP would support. It is hard to imagine ISO failing to approve such a change - who would vote against it? The voters would almost all be Internet people. ISO approval, assuming it is considered to be necessary, would inevitably lag IETF/IAB approval by a year or so, but with the reality of CLNP evolution fixed firmly in the IETF/IAB arena, who would care? >ISO and the Internet community have radically different views about >the standards making process (e.g. testing before standardizing, whether >to bill for standards, and the like). Indeed, the Internet community >decided not to join up with ANSI/ISO a few years ago because both >communities felt there were incompatibilities in their processes. >Now we're proposing to buy into the ISO process to manage our network layer. >We'll all have to learn the detailed workings of the ISO process if >we want to change the network layer -- and since it requires some >number of meetings to be ANSI/ISO accredited, we'd better all start >attending those meetings now (in addition to our IETF meetings) so Agghhh! I've been doing that for too many years - believe me, you wouldn't wish it on your enemies, much less your friends in the IETF! True, you'll have to know more about what ISO is doing on the network layer than you do now, but the pain will be far less than what you've described above. >we can be prepared to defend our ideas in the ISO process. Do we >really want to pass much (all?) of our control over the Internet >network layer to a process that the Internet community finds >incompatible? As we've clearly stated in RFC 1310, the IAB does not accept Internet standards over which we don't have change control. If CLNP becomes IPv7, and we decide that IPv7 must be changed in some way to improve its useful- ness to the Internet, then that change will be made. If ISO later (with ISO, unfortunately, it's always going to be "later"...) agrees to also make the change, then that will be very good (as you point out below, the best situation would be for IPv7 and ISO-CLNP to stay the same), and I expect that the people currently working on CLNP in ISO (and the companies that have been supporting them) will consider it very important to make this happen. However, it is not essential - if, for some reason, ISO decides *not* to go along, IPv7 won't suddenly stop working. With the number of interests that will be served by making sure that ISO *does* track any IPv7 evolution in the Internet, I don't foresee this happening (but, to be fair, recognize that it's a possibility). The IAB/IETF process determines what happens to IPv7, and ISO may, if it wishes, follow suit - not the other way around. > >(I've heard at least one person suggest that if ISO doesn't like >Internet-proposed changes, we'll just publish our own version of CLNP. >Ignoring ISO copyright issues about issuing a modified ISO spec [which >may or may not prove to big deal], I don't buy this idea. First, why >even call this new network layer CLNP unless we believe we mean to keep >in sync. Second, having an Internet and an ISO CLNP means that vendors >will have to support two versions of CLNP, which they won't like. ..and, since they are the people who have been determining the evolution of CLNP in ISO, they will presumably spend the effort to make sure that this doesn't happen (whom could it possibly benefit?)... >Consider how much folks already complain about the different GOSIPs. >We'll find ourselves in a tremendous vise to harmonize with ISO. We've >tried that twice before, with CMIP over TCP and IS-IS. In one case, >the idea was a complete flop but only after a waste of some years of >effort. In neither case was the process pleasant. I don't think we >want more of these kinds of problems.). > >Second, CLNP deals with only *one* of the several issues facing IP, namely >address depletion. At the same time, it forces us to take a giant step >back on other issues. CLNP does *not* support multicasting. There >are proposals in the works to add it -- but that means CLNP is about five >years behind IP on this topic. IP multicast is working now and it has >taken a lot of effort -- it is in products (Solaris 2.0) and in >BSD (4.4 and mods are available for 4.3). We're making good progress >on mobile host support. Some experimental implementations under >IP are getting heavy use. We'll have to go back to the CLNP drawing >board on those projects too. Ideas to support multimedia applications are >fast becoming reality (witness the recent IETF multicasts on the >Internet). If we buy CLNP we'll have to wait a few years for ISO >to approve those extensions. With the exception of a brief mentions >about leaving space for options and making sure that multicast will >somehow be supported, the various documents don't address this issue. This is a very pessimistic viewpoint, and one with which I simply don't agree. It's misleading to say "CLNP does *not* support multicasting" - neither does IP (IGRP, OSPF, and BGP do), and since the architecture of CLNP internetworking is identical to that of IP, there is no reason to expect that the work involved in expressing new stuff in CLNP rather than IP is anything like "going back to the drawing board". If CLNP becomes IPv7, I don't expect anyone to suddenly stop working on innovations based on IPv4 - that's what's out there (and no IPv4-->IPv7 shift is going to happen overnight). But there is no reason to think that the work based on IPv4 will not be directly applicable to IPv7 - and factoring good ideas into CLNP is something that vendors are likely to be motivated to do any- way, whether the result is called "CLNP" in a dual-stack IP/CLNP product or "IPv7" in a dual-stack IPv4/IPv7 product. The statement "If we buy CLNP we'll have to wait a few years for ISO to approve those extenstions" is simply false. Clearly the IAB intends for the Internet community to own IPv7. Why would we hold up an extension "waiting for ISO"? (there's a potential pun lurking there, which I will resist pursuing....) > >In short, CLNP as IPv7 seems destined to be a technical step backwards >and to place a severe crimp on protocol innovation at a time when we >need to innovate. (Some folks have expressed concern that the rise in >voice and multimedia on the Internet will stress IP *this* year. To my >knowledge, no one has tried running voice over CLNP). Are we so sure >that we should choose CLNP with all its limitations, especially now that >CIDR gives us a bit of breathing room in which to think? Are we so sure >CLNP is the right decision that we shouldn't even consider developing at >least one other approach in parallel, just in case we discover CLNP >really is a tar baby? CLNP as IPv7 is not intended to be any improvement on IP with respect to new Internet applications (including voice and multimedia) - it is intended only to stave off the ROAD problems, while research proceeds on a genuinely "new" internet protocol. The IAB doesn't believe that it is wise or prudent to place such a heavy bet on CIDR (which may or may not give us "enough" breathing room, depending on a lot of factors that are difficult to predict accurately enough to confidently hedge the bet). And I strongly suspect that people will continue to work on IPAE and other proposals with or without the IAB's blessing, notwithstanding our explicit recommendation that people focus their efforts on the unresolved issues surrounding a CLNP-based IPv7. > >Craig - Lyman From owner-big-internet@munnari.oz.au Tue Jul 7 06:36:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26385; Tue, 7 Jul 1992 06:36:06 +1000 (from owner-big-internet) Received: from MITVMA.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16277; Tue, 7 Jul 1992 01:14:23 +1000 (from @mitvma.mit.edu:owner-mod-ietf@searn.sunet.se) Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2) with BSMTP id 2219; Mon, 06 Jul 92 11:14:03 EDT Received: from FRORS12.BITNET by MITVMA.MIT.EDU (Mailer R2.08 R208004) with BSMTP id 2471; Mon, 06 Jul 92 11:14:00 EDT Received: by FRORS12 (Mailer R2.08 R208004) id 4910; Mon, 06 Jul 92 17:13:53 EDT Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6616 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:11 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7792; Mon, 06 Jul 92 17:06:09 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:05 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07183-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:16 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <05434-0@survis.surfnet.nl>; Sun, 5 Jul 1992 00:20:43 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <17504-0@relay.surfnet.nl>; Sun, 5 Jul 1992 00:20:39 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id ab01921; 4 Jul 92 18:15 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01917; 4 Jul 92 18:15 EDT Received: from BBN.COM by NRI.Reston.VA.US id aa17283; 4 Jul 92 18:16 EDT Return-Path: From: Lyman Chapin Subject: Re: IPv7 (CLNP) a mistake To: BSMTP Cc: big-internet@munnari.oz.au, iab@isi.edu, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov In-Reply-To: <9207022308.AA28811@aland.bbn.com> Date: Sat, 4 Jul 92 17:52:41 EDT Mail-System-Version: Message-Id: <9207041816.aa17283@NRI.Reston.VA.US> Sender: owner-mod-ietf@searn.sunet.se >To: big-internet@munnari.oz.au, iab@isi.edu, iesg@nri.reston.va.us, > ietf@isi.edu, road@lanl.gov >Subject: IPv7 (CLNP) a mistake >From: Craig Partridge >Date: Thu, 02 Jul 92 16:08:29 -0700 > > >I've read the IAB announcement, RFC 1347 and the Internet Draft, and am >afraid I view this idea of adopting CLNP as IPv7 as a disasterous idea. Craig, You're certainly not alone in this opinion! However, I think you have misunderstood some crucial elements of the IAB's plan, and made some assumptions that I (at least) don't think are valid. > >First, adopting CLNP means buying into the ISO standards process. Absolutely not. If I thought that this were true, mine would be the loudest voice arguing against the proposal, given the experience I've had with the formal ISO/CCITT standards process. Trading the Internet process for that of ISO would so clearly be a giant step backwards that I can't imagine anyone, even a die-hard OSI supporter, advocating it. For at least the past four years, almost every person working on CLNP and its relatives (addressing, routing protocols, and extensions) in ANSI and ISO has also been a committed Internet person. Every one of them prefers the IETF way of doing things to the ISO way. The people who actually manage and carry out the work on CLNP in ISO and the national standards bodies of the US, UK, Norway, Denmark, Japan, and Finland are Internet people. >While the Kobe announcement states that choosing CLNP is "not choosing OSI," >it is the case that we'd be choosing to make the network layer of the Internet >protocol suite the same as the OSI protocol suite. As such, we have >to face the painful reality that any future changes that the Internet >community wishes to see in the network layer will require ISO approval too. I'm tempted to just ask "why?", but that might sound disingenuous. Any change to CLNP that is necessary for CLNP to operate as the internetwork protocol of the Internet is, by definition, a change that all but one or two of the ISO people working on CLNP would support. It is hard to imagine ISO failing to approve such a change - who would vote against it? The voters would almost all be Internet people. ISO approval, assuming it is considered to be necessary, would inevitably lag IETF/IAB approval by a year or so, but with the reality of CLNP evolution fixed firmly in the IETF/IAB arena, who would care? >ISO and the Internet community have radically different views about >the standards making process (e.g. testing before standardizing, whether >to bill for standards, and the like). Indeed, the Internet community >decided not to join up with ANSI/ISO a few years ago because both >communities felt there were incompatibilities in their processes. >Now we're proposing to buy into the ISO process to manage our network layer. >We'll all have to learn the detailed workings of the ISO process if >we want to change the network layer -- and since it requires some >number of meetings to be ANSI/ISO accredited, we'd better all start >attending those meetings now (in addition to our IETF meetings) so Agghhh! I've been doing that for too many years - believe me, you wouldn't wish it on your enemies, much less your friends in the IETF! True, you'll have to know more about what ISO is doing on the network layer than you do now, but the pain will be far less than what you've described above. >we can be prepared to defend our ideas in the ISO process. Do we >really want to pass much (all?) of our control over the Internet >network layer to a process that the Internet community finds >incompatible? As we've clearly stated in RFC 1310, the IAB does not accept Internet standards over which we don't have change control. If CLNP becomes IPv7, and we decide that IPv7 must be changed in some way to improve its useful- ness to the Internet, then that change will be made. If ISO later (with ISO, unfortunately, it's always going to be "later"...) agrees to also make the change, then that will be very good (as you point out below, the best situation would be for IPv7 and ISO-CLNP to stay the same), and I expect that the people currently working on CLNP in ISO (and the companies that have been supporting them) will consider it very important to make this happen. However, it is not essential - if, for some reason, ISO decides *not* to go along, IPv7 won't suddenly stop working. With the number of interests that will be served by making sure that ISO *does* track any IPv7 evolution in the Internet, I don't foresee this happening (but, to be fair, recognize that it's a possibility). The IAB/IETF process determines what happens to IPv7, and ISO may, if it wishes, follow suit - not the other way around. > >(I've heard at least one person suggest that if ISO doesn't like >Internet-proposed changes, we'll just publish our own version of CLNP. >Ignoring ISO copyright issues about issuing a modified ISO spec [which >may or may not prove to big deal], I don't buy this idea. First, why >even call this new network layer CLNP unless we believe we mean to keep >in sync. Second, having an Internet and an ISO CLNP means that vendors >will have to support two versions of CLNP, which they won't like. ..and, since they are the people who have been determining the evolution of CLNP in ISO, they will presumably spend the effort to make sure that this doesn't happen (whom could it possibly benefit?)... >Consider how much folks already complain about the different GOSIPs. >We'll find ourselves in a tremendous vise to harmonize with ISO. We've >tried that twice before, with CMIP over TCP and IS-IS. In one case, >the idea was a complete flop but only after a waste of some years of >effort. In neither case was the process pleasant. I don't think we >want more of these kinds of problems.). > >Second, CLNP deals with only *one* of the several issues facing IP, namely >address depletion. At the same time, it forces us to take a giant step >back on other issues. CLNP does *not* support multicasting. There >are proposals in the works to add it -- but that means CLNP is about five >years behind IP on this topic. IP multicast is working now and it has >taken a lot of effort -- it is in products (Solaris 2.0) and in >BSD (4.4 and mods are available for 4.3). We're making good progress >on mobile host support. Some experimental implementations under >IP are getting heavy use. We'll have to go back to the CLNP drawing >board on those projects too. Ideas to support multimedia applications are >fast becoming reality (witness the recent IETF multicasts on the >Internet). If we buy CLNP we'll have to wait a few years for ISO >to approve those extensions. With the exception of a brief mentions >about leaving space for options and making sure that multicast will >somehow be supported, the various documents don't address this issue. This is a very pessimistic viewpoint, and one with which I simply don't agree. It's misleading to say "CLNP does *not* support multicasting" - neither does IP (IGRP, OSPF, and BGP do), and since the architecture of CLNP internetworking is identical to that of IP, there is no reason to expect that the work involved in expressing new stuff in CLNP rather than IP is anything like "going back to the drawing board". If CLNP becomes IPv7, I don't expect anyone to suddenly stop working on innovations based on IPv4 - that's what's out there (and no IPv4-->IPv7 shift is going to happen overnight). But there is no reason to think that the work based on IPv4 will not be directly applicable to IPv7 - and factoring good ideas into CLNP is something that vendors are likely to be motivated to do any- way, whether the result is called "CLNP" in a dual-stack IP/CLNP product or "IPv7" in a dual-stack IPv4/IPv7 product. The statement "If we buy CLNP we'll have to wait a few years for ISO to approve those extenstions" is simply false. Clearly the IAB intends for the Internet community to own IPv7. Why would we hold up an extension "waiting for ISO"? (there's a potential pun lurking there, which I will resist pursuing....) > >In short, CLNP as IPv7 seems destined to be a technical step backwards >and to place a severe crimp on protocol innovation at a time when we >need to innovate. (Some folks have expressed concern that the rise in >voice and multimedia on the Internet will stress IP *this* year. To my >knowledge, no one has tried running voice over CLNP). Are we so sure >that we should choose CLNP with all its limitations, especially now that >CIDR gives us a bit of breathing room in which to think? Are we so sure >CLNP is the right decision that we shouldn't even consider developing at >least one other approach in parallel, just in case we discover CLNP >really is a tar baby? CLNP as IPv7 is not intended to be any improvement on IP with respect to new Internet applications (including voice and multimedia) - it is intended only to stave off the ROAD problems, while research proceeds on a genuinely "new" internet protocol. The IAB doesn't believe that it is wise or prudent to place such a heavy bet on CIDR (which may or may not give us "enough" breathing room, depending on a lot of factors that are difficult to predict accurately enough to confidently hedge the bet). And I strongly suspect that people will continue to work on IPAE and other proposals with or without the IAB's blessing, notwithstanding our explicit recommendation that people focus their efforts on the unresolved issues surrounding a CLNP-based IPv7. > >Craig - Lyman From owner-big-internet@munnari.oz.au Tue Jul 7 06:43:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26509; Tue, 7 Jul 1992 06:43:46 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16280; Tue, 7 Jul 1992 01:14:28 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 9997; Mon, 06 Jul 92 17:13:15 MET Received: by DEARN (Mailer R2.08) id 2583; Mon, 06 Jul 92 17:13:14 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6617 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:25 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7798; Mon, 06 Jul 92 17:06:31 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:25 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07208-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:42 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <05449-0@survis.surfnet.nl>; Sun, 5 Jul 1992 00:24:45 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <17525-0@relay.surfnet.nl>; Sun, 5 Jul 1992 00:24:39 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01949; 4 Jul 92 18:21 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01945; 4 Jul 92 18:21 EDT Received: from dscs.arc.nasa.gov by NRI.Reston.VA.US id aa17384; 4 Jul 92 18:22 EDT Return-Path: Original-Received: Sat, 4 Jul 92 15:22:20 PDT from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Pp-Warning: Illegal Received field on preceding line Message-Id: <9207042222.AA16204@dscs.arc.nasa.gov> To: BSMTP Cc: iab@isi.edu, big-internet@munnari.oz.au, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Subject: Musings on the past few messages In-Reply-To: Your message of "Fri, 03 Jul 92 16:36:05 PDT." <9207032336.AA16883@upeksa.sdsc.edu> Date: Sat, 04 Jul 92 15:22:15 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Sender: owner-mod-ietf@searn.sunet.se Wow! I go away for a couple days of vacation and helping with irrigation down at my family's farm in the valley, and I log in to find my name in lights! And I thought the fireworks were reserved for today (the 4th!) :-). First off, let me clear up a few points. I did not mean to launch a personal invective at the members of the IAB. I have much respect for them, and I have dealt with many of them in a variety of areas in the past. HWB and I both sit on the FEPG, and I when I had more time for fun stuff, I used to attend ANSI X3S3.3 meetings that Lyman Chapin chaired. I firmly believe they are motivated to try and assure the growth and prosperity of the Internet community and the operational Internet itself. I made no reference about them being "evil" and having the IAB be destroyed nor was that my intention. I certainly was not advocating anarchy; that's rather inconsistent with my political viewpoints in any case. If that was what people read into it, I profusely apologize. However, people sometimes make mistakes. I believe the decision to put a stake in the ground now on this issue is a mistake. As H-W correctly pointed out, this kind of decision is a very rare and new thing for the IAB to do. It's a well meaning attempt to try and cut short the debate, and push the IETF community ahead with progress in developing a solution to the address space and routing problems which we are feeling now, and that will get worse later on. I do not believe any of the IAB was trying to act with malice here. This goal is in fact part of the problem. I said in my earlier note that the IAB has no real authority; that it is an organization that leads, not directs. H-W, I didn't think you disagreed with that. I fully share your frustration with progress on moving ahead with projects in the IETF. I have been involved in more than my share of headaches in that area. However, what I have learned from this experience is that the eventual IAB decision is not really what decides things. It is in fact the debate on the issues that really decides things. It is that debate, where the various burning issues are hammered out between the R&D community, the vendors, and the users. It is the debate in fact, where most of the community develops their viewpoints on whether or not a particular approach is a good approach or bad approach, and where people decide where to throw their development resources at. Sometimes there isn't always consensus, but eventually the various battles rage and productive solutions come out as implemented prototypes and solutions. It's far from efficient, but has seemed to work pretty well in the past. Now, if we were done with that debate, and we had a clear consensus, then such a move by the IAB would be appropriate, by codifying that consensus in an official position of the community as a whole. My problem is that that consensus didn't exist, certainly not on the issue of advancing the CLNP approach as THE approach for the medium to long term. By trying to cut off the debate, the normal process is stopped short of it's natural conclusion. This in many ways affects the timeframe that any solution can be implemented in. I would venture to say that a unified IETF working towards a goal achieved by consensus would complete it's various tasks far more quickly than an IETF where the various players are not firmly convinced that the selected approach is the right one. It's the enthusiasm behind the effort that can lead to rapid implementation, coupled with very tangible benefits that act as an incentive for people to migrate. Now, with regards to my ISOC comment. If you accept my proposition that the IAB leads by technical leadership, then anything that obscures that only diffuses the issue. It's not any formal IAB authority that makes the IAB successful. Nor is ISOC sponsorship, or government blessing or anything else. It's the IAB's technical leadership that causes people to stop and take note of what the IAB does and doesn't do, because IAB actions are not taken as the actions of the individuals on the IAB, but as the codification of the IETF and Internet community views as a whole. When the IAB pushes ahead with a proposal that is not a codification of the community's viewpoints, it seriously erodes it's technical leadership, unless there is a clearly superior proposal it is trying to advance. I don't view this statement as particularly incendiary. In this particular case, Bob Hinden's (the routing area director) and others' commentary on the draft show that the CLNP approach is not clearly superior. It may in the end prove to be the approach that everyone settles on, but it's not something that should be pushed on from the top. It needs to be decided on, bottom up, through the working groups and the IESG, because that's the process where the debate occurs. That is why this approach is harmful to the process of consensus building, and without consensus, the changes of the type that are being discussed are very unlikely to happen. Now, I never believed or argued the IPv7 document advocated a US GOSIP or other standard addressing standard for NSAP's. That was pretty clear. It also appears that the checksum location and type is also up for grabs. It appears that the proposal never really advances TUBA specifically. In fact, many of the supporters of a CLNP approach may not like the outcome of the proposed IPv7 process at all, since it probably won't be interoperable with the OSI at all. The other main point of my note was that given that we aren't really talking OSI or even a common CLNP packet definition, the draft really confuses people as to what it exactly was trying to say. When I discussed this with HW on the phone, he thought that was a good point and that the document needs to clarify this aspect. This way, marketing people and others will not be able to exploit this unfairly. And we won't have to deal with the aforementioned baroqueness of the current NSAP allocation organizations. The Internet is a big business these days. Perceptions are important, and they need to be considered. Now, on a few miscellaneous points. There are a lot of hard problems here. These problems will not go away with CLNP. The address depletion problem is not the really big problem. That is primarily an administrative problem, and can be handled by a number of mechanisms. If this is really the overriding focus of concern, we should move to stop issuing of coordinated address space to disconnected nets. That, coupled with recycling of disconnected net numbers can go a LONG way to preventing the address depletion problem from biting us. Coupled with CIDR, this does in fact buy us some time. Maybe quite a bit of time on the address depletion front. It does require new sites when the come on line to renumber. That's a pain. But running out of addresses is worse of course. Also, many commercial organizations have only one or 2 machines that actually need Internet connectivity, because the security capabilities we have in the network are so awful right now. This means that the other systems in that organization do not really need coordinated space either. The real problem is overall scaling of the routing system, and trying to grow the system for a couple more years at exponential growth with existing routing designs and hierarchy. I run an operational international backbone, of something like 150 routers. Our routers at the FIX points have no default. They carry total information. We also are a COTS (commercial off the shelf) shop, and we don't try and build routers or router software. I would hope that a major goal of the IETF process in this area is allow organizations like mine to continue to be able to be major players in the network game without resorting to non-COTS technology. And if the scaling of the routing system isn't the major goal behind the solution being proposed, then we really have problems. To Lixia, it's fair to blame the funding agencies a certain amount, but I will say that when I talk to DARPA and others about this problem, they respond that they do not receive a lot of proposals for research in this area. It is a pain to deal with the proposal process I agree, but there is money to be had for these sorts of activities for good proposals. At least that's certainly been true in the past couple of years. And to others who seem to be taking an us vs. them attitude about TCP/IP vs OSI. I would say that the real enemy, if one has to use the term, of TCP/IP is not OSI, but in fact the proprietary network technologies out there, who outnumber IP based solutions in installed base. Even if OSI went away today, we would still have to deal with multiprotocol routers and support for new and old proprietary solutions for a long time to come. I do believe that the OSI people are after the same end goal that the Internet is after, namely full interoperability with lots of functionality and robust implementation. Having attended ANSI X3S3 meetings in the past, I will say that they suffer from a far more political standardization process than we will ever deal with. OSI has suffered greatly in terms of deployed and functional products, not because there are stupid people working on it; quite the contrary is true, there are some very sharp people who work in the OSI arena. But the process they suffer from greatly impedes work and causes a lot of extra complication and hurts the quality of output. Compromise is at every step. This is why I and others worry the most about the process in the IAB/IETF system. Because it's been our processes and traditions that have made the IP suite so darn successful. And on the issue of personality, I went to my 10 year high school reunion last year. Many of my old friends there commented on how mellow I had gotten in the past few years! I actually never considered my note very extreme; and I'm rather disappointed if some people perceived it that way. I got flames from both sides on what I said, that I was too harsh and many that I was too light. I was trying to to take a moderate tone. I guess you can't please everyone all of the time. :-) Now, back to the furrows... Thanks, Milo From owner-big-internet@munnari.oz.au Tue Jul 7 06:50:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26682; Tue, 7 Jul 1992 06:50:39 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16284; Tue, 7 Jul 1992 01:14:50 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 9998; Mon, 06 Jul 92 17:13:18 MET Received: by DEARN (Mailer R2.08) id 2584; Mon, 06 Jul 92 17:13:15 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6617 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:25 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7798; Mon, 06 Jul 92 17:06:31 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:25 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07208-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:42 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <05449-0@survis.surfnet.nl>; Sun, 5 Jul 1992 00:24:45 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <17525-0@relay.surfnet.nl>; Sun, 5 Jul 1992 00:24:39 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01949; 4 Jul 92 18:21 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01945; 4 Jul 92 18:21 EDT Received: from dscs.arc.nasa.gov by NRI.Reston.VA.US id aa17384; 4 Jul 92 18:22 EDT Return-Path: Original-Received: Sat, 4 Jul 92 15:22:20 PDT from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Pp-Warning: Illegal Received field on preceding line Message-Id: <9207042222.AA16204@dscs.arc.nasa.gov> To: BSMTP Cc: iab@isi.edu, big-internet@munnari.oz.au, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Subject: Musings on the past few messages In-Reply-To: Your message of "Fri, 03 Jul 92 16:36:05 PDT." <9207032336.AA16883@upeksa.sdsc.edu> Date: Sat, 04 Jul 92 15:22:15 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Sender: owner-mod-ietf@searn.sunet.se Wow! I go away for a couple days of vacation and helping with irrigation down at my family's farm in the valley, and I log in to find my name in lights! And I thought the fireworks were reserved for today (the 4th!) :-). First off, let me clear up a few points. I did not mean to launch a personal invective at the members of the IAB. I have much respect for them, and I have dealt with many of them in a variety of areas in the past. HWB and I both sit on the FEPG, and I when I had more time for fun stuff, I used to attend ANSI X3S3.3 meetings that Lyman Chapin chaired. I firmly believe they are motivated to try and assure the growth and prosperity of the Internet community and the operational Internet itself. I made no reference about them being "evil" and having the IAB be destroyed nor was that my intention. I certainly was not advocating anarchy; that's rather inconsistent with my political viewpoints in any case. If that was what people read into it, I profusely apologize. However, people sometimes make mistakes. I believe the decision to put a stake in the ground now on this issue is a mistake. As H-W correctly pointed out, this kind of decision is a very rare and new thing for the IAB to do. It's a well meaning attempt to try and cut short the debate, and push the IETF community ahead with progress in developing a solution to the address space and routing problems which we are feeling now, and that will get worse later on. I do not believe any of the IAB was trying to act with malice here. This goal is in fact part of the problem. I said in my earlier note that the IAB has no real authority; that it is an organization that leads, not directs. H-W, I didn't think you disagreed with that. I fully share your frustration with progress on moving ahead with projects in the IETF. I have been involved in more than my share of headaches in that area. However, what I have learned from this experience is that the eventual IAB decision is not really what decides things. It is in fact the debate on the issues that really decides things. It is that debate, where the various burning issues are hammered out between the R&D community, the vendors, and the users. It is the debate in fact, where most of the community develops their viewpoints on whether or not a particular approach is a good approach or bad approach, and where people decide where to throw their development resources at. Sometimes there isn't always consensus, but eventually the various battles rage and productive solutions come out as implemented prototypes and solutions. It's far from efficient, but has seemed to work pretty well in the past. Now, if we were done with that debate, and we had a clear consensus, then such a move by the IAB would be appropriate, by codifying that consensus in an official position of the community as a whole. My problem is that that consensus didn't exist, certainly not on the issue of advancing the CLNP approach as THE approach for the medium to long term. By trying to cut off the debate, the normal process is stopped short of it's natural conclusion. This in many ways affects the timeframe that any solution can be implemented in. I would venture to say that a unified IETF working towards a goal achieved by consensus would complete it's various tasks far more quickly than an IETF where the various players are not firmly convinced that the selected approach is the right one. It's the enthusiasm behind the effort that can lead to rapid implementation, coupled with very tangible benefits that act as an incentive for people to migrate. Now, with regards to my ISOC comment. If you accept my proposition that the IAB leads by technical leadership, then anything that obscures that only diffuses the issue. It's not any formal IAB authority that makes the IAB successful. Nor is ISOC sponsorship, or government blessing or anything else. It's the IAB's technical leadership that causes people to stop and take note of what the IAB does and doesn't do, because IAB actions are not taken as the actions of the individuals on the IAB, but as the codification of the IETF and Internet community views as a whole. When the IAB pushes ahead with a proposal that is not a codification of the community's viewpoints, it seriously erodes it's technical leadership, unless there is a clearly superior proposal it is trying to advance. I don't view this statement as particularly incendiary. In this particular case, Bob Hinden's (the routing area director) and others' commentary on the draft show that the CLNP approach is not clearly superior. It may in the end prove to be the approach that everyone settles on, but it's not something that should be pushed on from the top. It needs to be decided on, bottom up, through the working groups and the IESG, because that's the process where the debate occurs. That is why this approach is harmful to the process of consensus building, and without consensus, the changes of the type that are being discussed are very unlikely to happen. Now, I never believed or argued the IPv7 document advocated a US GOSIP or other standard addressing standard for NSAP's. That was pretty clear. It also appears that the checksum location and type is also up for grabs. It appears that the proposal never really advances TUBA specifically. In fact, many of the supporters of a CLNP approach may not like the outcome of the proposed IPv7 process at all, since it probably won't be interoperable with the OSI at all. The other main point of my note was that given that we aren't really talking OSI or even a common CLNP packet definition, the draft really confuses people as to what it exactly was trying to say. When I discussed this with HW on the phone, he thought that was a good point and that the document needs to clarify this aspect. This way, marketing people and others will not be able to exploit this unfairly. And we won't have to deal with the aforementioned baroqueness of the current NSAP allocation organizations. The Internet is a big business these days. Perceptions are important, and they need to be considered. Now, on a few miscellaneous points. There are a lot of hard problems here. These problems will not go away with CLNP. The address depletion problem is not the really big problem. That is primarily an administrative problem, and can be handled by a number of mechanisms. If this is really the overriding focus of concern, we should move to stop issuing of coordinated address space to disconnected nets. That, coupled with recycling of disconnected net numbers can go a LONG way to preventing the address depletion problem from biting us. Coupled with CIDR, this does in fact buy us some time. Maybe quite a bit of time on the address depletion front. It does require new sites when the come on line to renumber. That's a pain. But running out of addresses is worse of course. Also, many commercial organizations have only one or 2 machines that actually need Internet connectivity, because the security capabilities we have in the network are so awful right now. This means that the other systems in that organization do not really need coordinated space either. The real problem is overall scaling of the routing system, and trying to grow the system for a couple more years at exponential growth with existing routing designs and hierarchy. I run an operational international backbone, of something like 150 routers. Our routers at the FIX points have no default. They carry total information. We also are a COTS (commercial off the shelf) shop, and we don't try and build routers or router software. I would hope that a major goal of the IETF process in this area is allow organizations like mine to continue to be able to be major players in the network game without resorting to non-COTS technology. And if the scaling of the routing system isn't the major goal behind the solution being proposed, then we really have problems. To Lixia, it's fair to blame the funding agencies a certain amount, but I will say that when I talk to DARPA and others about this problem, they respond that they do not receive a lot of proposals for research in this area. It is a pain to deal with the proposal process I agree, but there is money to be had for these sorts of activities for good proposals. At least that's certainly been true in the past couple of years. And to others who seem to be taking an us vs. them attitude about TCP/IP vs OSI. I would say that the real enemy, if one has to use the term, of TCP/IP is not OSI, but in fact the proprietary network technologies out there, who outnumber IP based solutions in installed base. Even if OSI went away today, we would still have to deal with multiprotocol routers and support for new and old proprietary solutions for a long time to come. I do believe that the OSI people are after the same end goal that the Internet is after, namely full interoperability with lots of functionality and robust implementation. Having attended ANSI X3S3 meetings in the past, I will say that they suffer from a far more political standardization process than we will ever deal with. OSI has suffered greatly in terms of deployed and functional products, not because there are stupid people working on it; quite the contrary is true, there are some very sharp people who work in the OSI arena. But the process they suffer from greatly impedes work and causes a lot of extra complication and hurts the quality of output. Compromise is at every step. This is why I and others worry the most about the process in the IAB/IETF system. Because it's been our processes and traditions that have made the IP suite so darn successful. And on the issue of personality, I went to my 10 year high school reunion last year. Many of my old friends there commented on how mellow I had gotten in the past few years! I actually never considered my note very extreme; and I'm rather disappointed if some people perceived it that way. I got flames from both sides on what I said, that I was too harsh and many that I was too light. I was trying to to take a moderate tone. I guess you can't please everyone all of the time. :-) Now, back to the furrows... Thanks, Milo From owner-big-internet@munnari.oz.au Tue Jul 7 06:57:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26762; Tue, 7 Jul 1992 06:57:43 +1000 (from owner-big-internet) Received: from vm.gmd.de by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16297; Tue, 7 Jul 1992 01:15:15 +1000 (from @vm.gmd.de:owner-mod-ietf@searn.sunet.se) Received: from DEARN by vm.gmd.de (IBM VM SMTP V2R2) with BSMTP id 9999; Mon, 06 Jul 92 17:13:19 MET Received: by DEARN (Mailer R2.08) id 2586; Mon, 06 Jul 92 17:13:17 MET Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6617 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:25 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7798; Mon, 06 Jul 92 17:06:31 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:25 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07208-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:42 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <05449-0@survis.surfnet.nl>; Sun, 5 Jul 1992 00:24:45 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <17525-0@relay.surfnet.nl>; Sun, 5 Jul 1992 00:24:39 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01949; 4 Jul 92 18:21 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01945; 4 Jul 92 18:21 EDT Received: from dscs.arc.nasa.gov by NRI.Reston.VA.US id aa17384; 4 Jul 92 18:22 EDT Return-Path: Original-Received: Sat, 4 Jul 92 15:22:20 PDT from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Pp-Warning: Illegal Received field on preceding line Message-Id: <9207042222.AA16204@dscs.arc.nasa.gov> To: BSMTP Cc: iab@isi.edu, big-internet@munnari.oz.au, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Subject: Musings on the past few messages In-Reply-To: Your message of "Fri, 03 Jul 92 16:36:05 PDT." <9207032336.AA16883@upeksa.sdsc.edu> Date: Sat, 04 Jul 92 15:22:15 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Sender: owner-mod-ietf@searn.sunet.se Wow! I go away for a couple days of vacation and helping with irrigation down at my family's farm in the valley, and I log in to find my name in lights! And I thought the fireworks were reserved for today (the 4th!) :-). First off, let me clear up a few points. I did not mean to launch a personal invective at the members of the IAB. I have much respect for them, and I have dealt with many of them in a variety of areas in the past. HWB and I both sit on the FEPG, and I when I had more time for fun stuff, I used to attend ANSI X3S3.3 meetings that Lyman Chapin chaired. I firmly believe they are motivated to try and assure the growth and prosperity of the Internet community and the operational Internet itself. I made no reference about them being "evil" and having the IAB be destroyed nor was that my intention. I certainly was not advocating anarchy; that's rather inconsistent with my political viewpoints in any case. If that was what people read into it, I profusely apologize. However, people sometimes make mistakes. I believe the decision to put a stake in the ground now on this issue is a mistake. As H-W correctly pointed out, this kind of decision is a very rare and new thing for the IAB to do. It's a well meaning attempt to try and cut short the debate, and push the IETF community ahead with progress in developing a solution to the address space and routing problems which we are feeling now, and that will get worse later on. I do not believe any of the IAB was trying to act with malice here. This goal is in fact part of the problem. I said in my earlier note that the IAB has no real authority; that it is an organization that leads, not directs. H-W, I didn't think you disagreed with that. I fully share your frustration with progress on moving ahead with projects in the IETF. I have been involved in more than my share of headaches in that area. However, what I have learned from this experience is that the eventual IAB decision is not really what decides things. It is in fact the debate on the issues that really decides things. It is that debate, where the various burning issues are hammered out between the R&D community, the vendors, and the users. It is the debate in fact, where most of the community develops their viewpoints on whether or not a particular approach is a good approach or bad approach, and where people decide where to throw their development resources at. Sometimes there isn't always consensus, but eventually the various battles rage and productive solutions come out as implemented prototypes and solutions. It's far from efficient, but has seemed to work pretty well in the past. Now, if we were done with that debate, and we had a clear consensus, then such a move by the IAB would be appropriate, by codifying that consensus in an official position of the community as a whole. My problem is that that consensus didn't exist, certainly not on the issue of advancing the CLNP approach as THE approach for the medium to long term. By trying to cut off the debate, the normal process is stopped short of it's natural conclusion. This in many ways affects the timeframe that any solution can be implemented in. I would venture to say that a unified IETF working towards a goal achieved by consensus would complete it's various tasks far more quickly than an IETF where the various players are not firmly convinced that the selected approach is the right one. It's the enthusiasm behind the effort that can lead to rapid implementation, coupled with very tangible benefits that act as an incentive for people to migrate. Now, with regards to my ISOC comment. If you accept my proposition that the IAB leads by technical leadership, then anything that obscures that only diffuses the issue. It's not any formal IAB authority that makes the IAB successful. Nor is ISOC sponsorship, or government blessing or anything else. It's the IAB's technical leadership that causes people to stop and take note of what the IAB does and doesn't do, because IAB actions are not taken as the actions of the individuals on the IAB, but as the codification of the IETF and Internet community views as a whole. When the IAB pushes ahead with a proposal that is not a codification of the community's viewpoints, it seriously erodes it's technical leadership, unless there is a clearly superior proposal it is trying to advance. I don't view this statement as particularly incendiary. In this particular case, Bob Hinden's (the routing area director) and others' commentary on the draft show that the CLNP approach is not clearly superior. It may in the end prove to be the approach that everyone settles on, but it's not something that should be pushed on from the top. It needs to be decided on, bottom up, through the working groups and the IESG, because that's the process where the debate occurs. That is why this approach is harmful to the process of consensus building, and without consensus, the changes of the type that are being discussed are very unlikely to happen. Now, I never believed or argued the IPv7 document advocated a US GOSIP or other standard addressing standard for NSAP's. That was pretty clear. It also appears that the checksum location and type is also up for grabs. It appears that the proposal never really advances TUBA specifically. In fact, many of the supporters of a CLNP approach may not like the outcome of the proposed IPv7 process at all, since it probably won't be interoperable with the OSI at all. The other main point of my note was that given that we aren't really talking OSI or even a common CLNP packet definition, the draft really confuses people as to what it exactly was trying to say. When I discussed this with HW on the phone, he thought that was a good point and that the document needs to clarify this aspect. This way, marketing people and others will not be able to exploit this unfairly. And we won't have to deal with the aforementioned baroqueness of the current NSAP allocation organizations. The Internet is a big business these days. Perceptions are important, and they need to be considered. Now, on a few miscellaneous points. There are a lot of hard problems here. These problems will not go away with CLNP. The address depletion problem is not the really big problem. That is primarily an administrative problem, and can be handled by a number of mechanisms. If this is really the overriding focus of concern, we should move to stop issuing of coordinated address space to disconnected nets. That, coupled with recycling of disconnected net numbers can go a LONG way to preventing the address depletion problem from biting us. Coupled with CIDR, this does in fact buy us some time. Maybe quite a bit of time on the address depletion front. It does require new sites when the come on line to renumber. That's a pain. But running out of addresses is worse of course. Also, many commercial organizations have only one or 2 machines that actually need Internet connectivity, because the security capabilities we have in the network are so awful right now. This means that the other systems in that organization do not really need coordinated space either. The real problem is overall scaling of the routing system, and trying to grow the system for a couple more years at exponential growth with existing routing designs and hierarchy. I run an operational international backbone, of something like 150 routers. Our routers at the FIX points have no default. They carry total information. We also are a COTS (commercial off the shelf) shop, and we don't try and build routers or router software. I would hope that a major goal of the IETF process in this area is allow organizations like mine to continue to be able to be major players in the network game without resorting to non-COTS technology. And if the scaling of the routing system isn't the major goal behind the solution being proposed, then we really have problems. To Lixia, it's fair to blame the funding agencies a certain amount, but I will say that when I talk to DARPA and others about this problem, they respond that they do not receive a lot of proposals for research in this area. It is a pain to deal with the proposal process I agree, but there is money to be had for these sorts of activities for good proposals. At least that's certainly been true in the past couple of years. And to others who seem to be taking an us vs. them attitude about TCP/IP vs OSI. I would say that the real enemy, if one has to use the term, of TCP/IP is not OSI, but in fact the proprietary network technologies out there, who outnumber IP based solutions in installed base. Even if OSI went away today, we would still have to deal with multiprotocol routers and support for new and old proprietary solutions for a long time to come. I do believe that the OSI people are after the same end goal that the Internet is after, namely full interoperability with lots of functionality and robust implementation. Having attended ANSI X3S3 meetings in the past, I will say that they suffer from a far more political standardization process than we will ever deal with. OSI has suffered greatly in terms of deployed and functional products, not because there are stupid people working on it; quite the contrary is true, there are some very sharp people who work in the OSI arena. But the process they suffer from greatly impedes work and causes a lot of extra complication and hurts the quality of output. Compromise is at every step. This is why I and others worry the most about the process in the IAB/IETF system. Because it's been our processes and traditions that have made the IP suite so darn successful. And on the issue of personality, I went to my 10 year high school reunion last year. Many of my old friends there commented on how mellow I had gotten in the past few years! I actually never considered my note very extreme; and I'm rather disappointed if some people perceived it that way. I got flames from both sides on what I said, that I was too harsh and many that I was too light. I was trying to to take a moderate tone. I guess you can't please everyone all of the time. :-) Now, back to the furrows... Thanks, Milo From owner-big-internet@munnari.oz.au Tue Jul 7 07:05:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26919; Tue, 7 Jul 1992 07:05:29 +1000 (from owner-big-internet) Received: from MITVMA.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16322; Tue, 7 Jul 1992 01:16:27 +1000 (from @mitvma.mit.edu:owner-mod-ietf@searn.sunet.se) Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2) with BSMTP id 2239; Mon, 06 Jul 92 11:16:36 EDT Received: from FRORS12.BITNET by MITVMA.MIT.EDU (Mailer R2.08 R208004) with BSMTP id 2531; Mon, 06 Jul 92 11:16:32 EDT Received: by FRORS12 (Mailer R2.08 R208004) id 4957; Mon, 06 Jul 92 17:15:11 EDT Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6617 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:25 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7798; Mon, 06 Jul 92 17:06:31 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:25 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07208-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:42 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <05449-0@survis.surfnet.nl>; Sun, 5 Jul 1992 00:24:45 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <17525-0@relay.surfnet.nl>; Sun, 5 Jul 1992 00:24:39 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01949; 4 Jul 92 18:21 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01945; 4 Jul 92 18:21 EDT Received: from dscs.arc.nasa.gov by NRI.Reston.VA.US id aa17384; 4 Jul 92 18:22 EDT Return-Path: Original-Received: Sat, 4 Jul 92 15:22:20 PDT from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Pp-Warning: Illegal Received field on preceding line Message-Id: <9207042222.AA16204@dscs.arc.nasa.gov> To: BSMTP Cc: iab@isi.edu, big-internet@munnari.oz.au, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Subject: Musings on the past few messages In-Reply-To: Your message of "Fri, 03 Jul 92 16:36:05 PDT." <9207032336.AA16883@upeksa.sdsc.edu> Date: Sat, 04 Jul 92 15:22:15 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Sender: owner-mod-ietf@searn.sunet.se Wow! I go away for a couple days of vacation and helping with irrigation down at my family's farm in the valley, and I log in to find my name in lights! And I thought the fireworks were reserved for today (the 4th!) :-). First off, let me clear up a few points. I did not mean to launch a personal invective at the members of the IAB. I have much respect for them, and I have dealt with many of them in a variety of areas in the past. HWB and I both sit on the FEPG, and I when I had more time for fun stuff, I used to attend ANSI X3S3.3 meetings that Lyman Chapin chaired. I firmly believe they are motivated to try and assure the growth and prosperity of the Internet community and the operational Internet itself. I made no reference about them being "evil" and having the IAB be destroyed nor was that my intention. I certainly was not advocating anarchy; that's rather inconsistent with my political viewpoints in any case. If that was what people read into it, I profusely apologize. However, people sometimes make mistakes. I believe the decision to put a stake in the ground now on this issue is a mistake. As H-W correctly pointed out, this kind of decision is a very rare and new thing for the IAB to do. It's a well meaning attempt to try and cut short the debate, and push the IETF community ahead with progress in developing a solution to the address space and routing problems which we are feeling now, and that will get worse later on. I do not believe any of the IAB was trying to act with malice here. This goal is in fact part of the problem. I said in my earlier note that the IAB has no real authority; that it is an organization that leads, not directs. H-W, I didn't think you disagreed with that. I fully share your frustration with progress on moving ahead with projects in the IETF. I have been involved in more than my share of headaches in that area. However, what I have learned from this experience is that the eventual IAB decision is not really what decides things. It is in fact the debate on the issues that really decides things. It is that debate, where the various burning issues are hammered out between the R&D community, the vendors, and the users. It is the debate in fact, where most of the community develops their viewpoints on whether or not a particular approach is a good approach or bad approach, and where people decide where to throw their development resources at. Sometimes there isn't always consensus, but eventually the various battles rage and productive solutions come out as implemented prototypes and solutions. It's far from efficient, but has seemed to work pretty well in the past. Now, if we were done with that debate, and we had a clear consensus, then such a move by the IAB would be appropriate, by codifying that consensus in an official position of the community as a whole. My problem is that that consensus didn't exist, certainly not on the issue of advancing the CLNP approach as THE approach for the medium to long term. By trying to cut off the debate, the normal process is stopped short of it's natural conclusion. This in many ways affects the timeframe that any solution can be implemented in. I would venture to say that a unified IETF working towards a goal achieved by consensus would complete it's various tasks far more quickly than an IETF where the various players are not firmly convinced that the selected approach is the right one. It's the enthusiasm behind the effort that can lead to rapid implementation, coupled with very tangible benefits that act as an incentive for people to migrate. Now, with regards to my ISOC comment. If you accept my proposition that the IAB leads by technical leadership, then anything that obscures that only diffuses the issue. It's not any formal IAB authority that makes the IAB successful. Nor is ISOC sponsorship, or government blessing or anything else. It's the IAB's technical leadership that causes people to stop and take note of what the IAB does and doesn't do, because IAB actions are not taken as the actions of the individuals on the IAB, but as the codification of the IETF and Internet community views as a whole. When the IAB pushes ahead with a proposal that is not a codification of the community's viewpoints, it seriously erodes it's technical leadership, unless there is a clearly superior proposal it is trying to advance. I don't view this statement as particularly incendiary. In this particular case, Bob Hinden's (the routing area director) and others' commentary on the draft show that the CLNP approach is not clearly superior. It may in the end prove to be the approach that everyone settles on, but it's not something that should be pushed on from the top. It needs to be decided on, bottom up, through the working groups and the IESG, because that's the process where the debate occurs. That is why this approach is harmful to the process of consensus building, and without consensus, the changes of the type that are being discussed are very unlikely to happen. Now, I never believed or argued the IPv7 document advocated a US GOSIP or other standard addressing standard for NSAP's. That was pretty clear. It also appears that the checksum location and type is also up for grabs. It appears that the proposal never really advances TUBA specifically. In fact, many of the supporters of a CLNP approach may not like the outcome of the proposed IPv7 process at all, since it probably won't be interoperable with the OSI at all. The other main point of my note was that given that we aren't really talking OSI or even a common CLNP packet definition, the draft really confuses people as to what it exactly was trying to say. When I discussed this with HW on the phone, he thought that was a good point and that the document needs to clarify this aspect. This way, marketing people and others will not be able to exploit this unfairly. And we won't have to deal with the aforementioned baroqueness of the current NSAP allocation organizations. The Internet is a big business these days. Perceptions are important, and they need to be considered. Now, on a few miscellaneous points. There are a lot of hard problems here. These problems will not go away with CLNP. The address depletion problem is not the really big problem. That is primarily an administrative problem, and can be handled by a number of mechanisms. If this is really the overriding focus of concern, we should move to stop issuing of coordinated address space to disconnected nets. That, coupled with recycling of disconnected net numbers can go a LONG way to preventing the address depletion problem from biting us. Coupled with CIDR, this does in fact buy us some time. Maybe quite a bit of time on the address depletion front. It does require new sites when the come on line to renumber. That's a pain. But running out of addresses is worse of course. Also, many commercial organizations have only one or 2 machines that actually need Internet connectivity, because the security capabilities we have in the network are so awful right now. This means that the other systems in that organization do not really need coordinated space either. The real problem is overall scaling of the routing system, and trying to grow the system for a couple more years at exponential growth with existing routing designs and hierarchy. I run an operational international backbone, of something like 150 routers. Our routers at the FIX points have no default. They carry total information. We also are a COTS (commercial off the shelf) shop, and we don't try and build routers or router software. I would hope that a major goal of the IETF process in this area is allow organizations like mine to continue to be able to be major players in the network game without resorting to non-COTS technology. And if the scaling of the routing system isn't the major goal behind the solution being proposed, then we really have problems. To Lixia, it's fair to blame the funding agencies a certain amount, but I will say that when I talk to DARPA and others about this problem, they respond that they do not receive a lot of proposals for research in this area. It is a pain to deal with the proposal process I agree, but there is money to be had for these sorts of activities for good proposals. At least that's certainly been true in the past couple of years. And to others who seem to be taking an us vs. them attitude about TCP/IP vs OSI. I would say that the real enemy, if one has to use the term, of TCP/IP is not OSI, but in fact the proprietary network technologies out there, who outnumber IP based solutions in installed base. Even if OSI went away today, we would still have to deal with multiprotocol routers and support for new and old proprietary solutions for a long time to come. I do believe that the OSI people are after the same end goal that the Internet is after, namely full interoperability with lots of functionality and robust implementation. Having attended ANSI X3S3 meetings in the past, I will say that they suffer from a far more political standardization process than we will ever deal with. OSI has suffered greatly in terms of deployed and functional products, not because there are stupid people working on it; quite the contrary is true, there are some very sharp people who work in the OSI arena. But the process they suffer from greatly impedes work and causes a lot of extra complication and hurts the quality of output. Compromise is at every step. This is why I and others worry the most about the process in the IAB/IETF system. Because it's been our processes and traditions that have made the IP suite so darn successful. And on the issue of personality, I went to my 10 year high school reunion last year. Many of my old friends there commented on how mellow I had gotten in the past few years! I actually never considered my note very extreme; and I'm rather disappointed if some people perceived it that way. I got flames from both sides on what I said, that I was too harsh and many that I was too light. I was trying to to take a moderate tone. I guess you can't please everyone all of the time. :-) Now, back to the furrows... Thanks, Milo From owner-big-internet@munnari.oz.au Tue Jul 7 07:09:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26963; Tue, 7 Jul 1992 07:09:09 +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 AA24599; Tue, 7 Jul 1992 05:11:28 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA25189; Mon, 6 Jul 92 12:11:07 -0700 Date: Mon, 6 Jul 92 14:58:34 EDT From: "William Allen Simpson" Message-Id: <515.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Cc: ietf-ppp@ucdavis.edu Reply-To: bsimpson@angband.stanford.edu Subject: CLNP/IP7 over PPP Within the PPP Working Group, we have been discussing the use of OSI protocols over PPP. Dave Katz wrote a draft over two years ago, and we are just now seeing implementations. The problem is, his proposal depends on address negotiation using an ES-IS exchange, which is not yet completed by ISO. This was fine when the implementation was already committed to ISO, but is not good if it becomes a universal IP requirement. 1) this is another area that the OSI standard isn't sufficiently complete to migrate from IP to CLNP. 2) this means that all PPP IP links will need to implement ES-IS, even if they don't adopt other parts of ISO. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-big-internet@munnari.oz.au Tue Jul 7 07:13:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26995; Tue, 7 Jul 1992 07:13:36 +1000 (from owner-big-internet) Received: from MITVMA.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16366; Tue, 7 Jul 1992 01:17:45 +1000 (from @mitvma.mit.edu:owner-mod-ietf@searn.sunet.se) Received: from MITVMA.MIT.EDU by mitvma.mit.edu (IBM VM SMTP V2R2) with BSMTP id 2252; Mon, 06 Jul 92 11:17:38 EDT Received: from FRORS12.BITNET by MITVMA.MIT.EDU (Mailer R2.08 R208004) with BSMTP id 2559; Mon, 06 Jul 92 11:17:31 EDT Received: by FRORS12 (Mailer R2.08 R208004) id 4956; Mon, 06 Jul 92 17:15:10 EDT Received: from SEARN.BITNET by SEARN.SUNET.SE (LISTSERV release 1.7c) with NJE id 6617 for MOD-IETF@SEARN.SUNET.SE; Mon, 6 Jul 1992 17:11:25 +0200 Received: from SEARN by SEARN.SUNET.SE (Mailer R2.08 R208004) with BSMTP id 7798; Mon, 06 Jul 92 17:06:31 +0200 Received: from survis.surfnet.nl by SEARN.SUNET.SE (IBM VM SMTP V2R2) with TCP; Mon, 06 Jul 92 17:06:25 +0200 Received: from surfnet.nl by survis.surfnet.nl with SMTP (PP) id <07208-0@survis.surfnet.nl>; Mon, 6 Jul 1992 17:07:42 +0200 Received: from relay.surfnet.nl by survis.surfnet.nl with SMTP (PP) id <05449-0@survis.surfnet.nl>; Sun, 5 Jul 1992 00:24:45 +0200 Received: from 132.151.1.35 by relay.surfnet.nl with SMTP (PP) id <17525-0@relay.surfnet.nl>; Sun, 5 Jul 1992 00:24:39 +0200 Received: from ietf.nri.reston.va.us by IETF.NRI.Reston.VA.US id aa01949; 4 Jul 92 18:21 EDT Received: from NRI.NRI.Reston.Va.US by IETF.NRI.Reston.VA.US id aa01945; 4 Jul 92 18:21 EDT Received: from dscs.arc.nasa.gov by NRI.Reston.VA.US id aa17384; 4 Jul 92 18:22 EDT Return-Path: Original-Received: Sat, 4 Jul 92 15:22:20 PDT from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Pp-Warning: Illegal Received field on preceding line Message-Id: <9207042222.AA16204@dscs.arc.nasa.gov> To: BSMTP Cc: iab@isi.edu, big-internet@munnari.oz.au, iesg@NRI.Reston.VA.US, ietf@isi.edu, road@lanl.gov Subject: Musings on the past few messages In-Reply-To: Your message of "Fri, 03 Jul 92 16:36:05 PDT." <9207032336.AA16883@upeksa.sdsc.edu> Date: Sat, 04 Jul 92 15:22:15 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Sender: owner-mod-ietf@searn.sunet.se Wow! I go away for a couple days of vacation and helping with irrigation down at my family's farm in the valley, and I log in to find my name in lights! And I thought the fireworks were reserved for today (the 4th!) :-). First off, let me clear up a few points. I did not mean to launch a personal invective at the members of the IAB. I have much respect for them, and I have dealt with many of them in a variety of areas in the past. HWB and I both sit on the FEPG, and I when I had more time for fun stuff, I used to attend ANSI X3S3.3 meetings that Lyman Chapin chaired. I firmly believe they are motivated to try and assure the growth and prosperity of the Internet community and the operational Internet itself. I made no reference about them being "evil" and having the IAB be destroyed nor was that my intention. I certainly was not advocating anarchy; that's rather inconsistent with my political viewpoints in any case. If that was what people read into it, I profusely apologize. However, people sometimes make mistakes. I believe the decision to put a stake in the ground now on this issue is a mistake. As H-W correctly pointed out, this kind of decision is a very rare and new thing for the IAB to do. It's a well meaning attempt to try and cut short the debate, and push the IETF community ahead with progress in developing a solution to the address space and routing problems which we are feeling now, and that will get worse later on. I do not believe any of the IAB was trying to act with malice here. This goal is in fact part of the problem. I said in my earlier note that the IAB has no real authority; that it is an organization that leads, not directs. H-W, I didn't think you disagreed with that. I fully share your frustration with progress on moving ahead with projects in the IETF. I have been involved in more than my share of headaches in that area. However, what I have learned from this experience is that the eventual IAB decision is not really what decides things. It is in fact the debate on the issues that really decides things. It is that debate, where the various burning issues are hammered out between the R&D community, the vendors, and the users. It is the debate in fact, where most of the community develops their viewpoints on whether or not a particular approach is a good approach or bad approach, and where people decide where to throw their development resources at. Sometimes there isn't always consensus, but eventually the various battles rage and productive solutions come out as implemented prototypes and solutions. It's far from efficient, but has seemed to work pretty well in the past. Now, if we were done with that debate, and we had a clear consensus, then such a move by the IAB would be appropriate, by codifying that consensus in an official position of the community as a whole. My problem is that that consensus didn't exist, certainly not on the issue of advancing the CLNP approach as THE approach for the medium to long term. By trying to cut off the debate, the normal process is stopped short of it's natural conclusion. This in many ways affects the timeframe that any solution can be implemented in. I would venture to say that a unified IETF working towards a goal achieved by consensus would complete it's various tasks far more quickly than an IETF where the various players are not firmly convinced that the selected approach is the right one. It's the enthusiasm behind the effort that can lead to rapid implementation, coupled with very tangible benefits that act as an incentive for people to migrate. Now, with regards to my ISOC comment. If you accept my proposition that the IAB leads by technical leadership, then anything that obscures that only diffuses the issue. It's not any formal IAB authority that makes the IAB successful. Nor is ISOC sponsorship, or government blessing or anything else. It's the IAB's technical leadership that causes people to stop and take note of what the IAB does and doesn't do, because IAB actions are not taken as the actions of the individuals on the IAB, but as the codification of the IETF and Internet community views as a whole. When the IAB pushes ahead with a proposal that is not a codification of the community's viewpoints, it seriously erodes it's technical leadership, unless there is a clearly superior proposal it is trying to advance. I don't view this statement as particularly incendiary. In this particular case, Bob Hinden's (the routing area director) and others' commentary on the draft show that the CLNP approach is not clearly superior. It may in the end prove to be the approach that everyone settles on, but it's not something that should be pushed on from the top. It needs to be decided on, bottom up, through the working groups and the IESG, because that's the process where the debate occurs. That is why this approach is harmful to the process of consensus building, and without consensus, the changes of the type that are being discussed are very unlikely to happen. Now, I never believed or argued the IPv7 document advocated a US GOSIP or other standard addressing standard for NSAP's. That was pretty clear. It also appears that the checksum location and type is also up for grabs. It appears that the proposal never really advances TUBA specifically. In fact, many of the supporters of a CLNP approach may not like the outcome of the proposed IPv7 process at all, since it probably won't be interoperable with the OSI at all. The other main point of my note was that given that we aren't really talking OSI or even a common CLNP packet definition, the draft really confuses people as to what it exactly was trying to say. When I discussed this with HW on the phone, he thought that was a good point and that the document needs to clarify this aspect. This way, marketing people and others will not be able to exploit this unfairly. And we won't have to deal with the aforementioned baroqueness of the current NSAP allocation organizations. The Internet is a big business these days. Perceptions are important, and they need to be considered. Now, on a few miscellaneous points. There are a lot of hard problems here. These problems will not go away with CLNP. The address depletion problem is not the really big problem. That is primarily an administrative problem, and can be handled by a number of mechanisms. If this is really the overriding focus of concern, we should move to stop issuing of coordinated address space to disconnected nets. That, coupled with recycling of disconnected net numbers can go a LONG way to preventing the address depletion problem from biting us. Coupled with CIDR, this does in fact buy us some time. Maybe quite a bit of time on the address depletion front. It does require new sites when the come on line to renumber. That's a pain. But running out of addresses is worse of course. Also, many commercial organizations have only one or 2 machines that actually need Internet connectivity, because the security capabilities we have in the network are so awful right now. This means that the other systems in that organization do not really need coordinated space either. The real problem is overall scaling of the routing system, and trying to grow the system for a couple more years at exponential growth with existing routing designs and hierarchy. I run an operational international backbone, of something like 150 routers. Our routers at the FIX points have no default. They carry total information. We also are a COTS (commercial off the shelf) shop, and we don't try and build routers or router software. I would hope that a major goal of the IETF process in this area is allow organizations like mine to continue to be able to be major players in the network game without resorting to non-COTS technology. And if the scaling of the routing system isn't the major goal behind the solution being proposed, then we really have problems. To Lixia, it's fair to blame the funding agencies a certain amount, but I will say that when I talk to DARPA and others about this problem, they respond that they do not receive a lot of proposals for research in this area. It is a pain to deal with the proposal process I agree, but there is money to be had for these sorts of activities for good proposals. At least that's certainly been true in the past couple of years. And to others who seem to be taking an us vs. them attitude about TCP/IP vs OSI. I would say that the real enemy, if one has to use the term, of TCP/IP is not OSI, but in fact the proprietary network technologies out there, who outnumber IP based solutions in installed base. Even if OSI went away today, we would still have to deal with multiprotocol routers and support for new and old proprietary solutions for a long time to come. I do believe that the OSI people are after the same end goal that the Internet is after, namely full interoperability with lots of functionality and robust implementation. Having attended ANSI X3S3 meetings in the past, I will say that they suffer from a far more political standardization process than we will ever deal with. OSI has suffered greatly in terms of deployed and functional products, not because there are stupid people working on it; quite the contrary is true, there are some very sharp people who work in the OSI arena. But the process they suffer from greatly impedes work and causes a lot of extra complication and hurts the quality of output. Compromise is at every step. This is why I and others worry the most about the process in the IAB/IETF system. Because it's been our processes and traditions that have made the IP suite so darn successful. And on the issue of personality, I went to my 10 year high school reunion last year. Many of my old friends there commented on how mellow I had gotten in the past few years! I actually never considered my note very extreme; and I'm rather disappointed if some people perceived it that way. I got flames from both sides on what I said, that I was too harsh and many that I was too light. I was trying to to take a moderate tone. I guess you can't please everyone all of the time. :-) Now, back to the furrows... Thanks, Milo From owner-big-internet@munnari.oz.au Tue Jul 7 08:06:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28423; Tue, 7 Jul 1992 08:06:45 +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 AA24598; Tue, 7 Jul 1992 05:11:29 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA25186; Mon, 6 Jul 92 12:10:33 -0700 Date: Mon, 6 Jul 92 13:35:41 EDT From: "William Allen Simpson" Message-Id: <514.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Extending the IP numbering space I made a stupid error in my last draft, and am also including the proposed imbedding function for CLNP. Also, since the terms "address" and "identifier" are so overloaded, I'm hoping we can call it the "IP System Number", to distinguish it from the "System Location". ---- AN EXTENSIBLE IP SYSTEM NUMBER Introduction Once upon a time, the IP protocol stack was criticized because of the large size of its headers. One of the principle reasons for the size was the use of 32 bit addresses. This was larger than most other addressing spaces of the time. Despite that foresight, it is now expected that this space of over four billion numbers will be exhausted sometime in the not too distant future. This proposal uses the remainder of the "extended addressing mode" to provide a self-encoded extensible number space, while preserving 32 bit boundary alignment. Classes The current IP Protocol specification [RFC791] defined a set of address classes named A, B and C. Since that time, class D has been carved out for Multicast [RFC1112]. It is noted that 'FF' is already reserved for Broadcast in all classes. All current IP addresses are 32 bits (4 octets) in length. This is a convenient size for many common computer processors. In particular, this size leads to efficient memory timing utilization. Memory access is often the bottleneck in forwarding packets. This proposal reserves the remainder of the first octet as a discriminator for numbers of other lengths. The complete table is as follows: High Order Bits Format Class --------------- ------------------------------- ----- 0 7 bits of net, 24 bits of host a 10 14 bits of net, 16 bits of host b 110 21 bits of net, 8 bits of host c 1110 Multicast d 1111 0 64 bits (8 octets) e 1111 10 96 bits (12 octets) f 1111 110 128 bits (16 octets) g 1111 1110 reserved for future use 1111 1111 Broadcast (4 octets) - Extended System Number The Extended System Number provides for a self-encoded extensible number space which is 32 bit aligned. This space is "classless". A separate "network mask" may be used to delineate the network, subnet, and host parts of the address, or the number space may be needed only as a globally unique "system identifier". It is expected that this mapping will take us well into the next millenium, until we need to number all of the sub-atomic particles in the universe, or until ever-expanding allocation committees decide we need more, whichever is sooner. Address Content It is intended that 32 bit addresses will remain the primary form of address. In particular, addresses which are frequently examined by large numbers of machines, such as broadcasts and multicasts, MUST always be sent in the 32 bit form. The final 32 bits of any Extended System Number SHOULD be an address of classes A to C. This facilitates mapping between current and future numbering formats. Otherwise, this proposal does not specify any particular address content. This numbering system is amenable to many of the address content proposals, such as provider-based or geographic-based allocation, or flat-space system identifiers. Use with CLNP The CLNP packet format does not maintain 32 bit field alignment. However, address field alignment can be achieved through judicious use of the IP System Number. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 octet +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ checksum LSB | Length | AFI | IDI | 9-12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | 13-16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSEL | Length | AFI | IDI | 17-20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | 21-24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NSEL | 25 +-+-+-+-+-+-+-+-+ Since the IP System Number is always a multiple of 32 bits, this will always align correctly, up to the 16 octet maximum (19 total, which is less than the 20 octet NSAP limit). Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-big-internet@munnari.oz.au Tue Jul 7 08:58:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29794; Tue, 7 Jul 1992 08:59:03 +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 AA26903; Tue, 7 Jul 1992 07:04:29 +1000 (from dino@cisco.com) Received: by regal.cisco.com; Mon, 6 Jul 92 14:04:07 -0700 Date: Mon, 6 Jul 92 14:04:07 -0700 From: Dino Farinacci Message-Id: <9207062104.AA15749@regal.cisco.com> To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au, ietf-ppp@ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Mon, 6 Jul 92 14:58:34 EDT <516.bsimpson@angband.stanford.edu> Subject: CLNP/IP7 over PPP >> The problem is, his proposal depends on address negotiation using an >> ES-IS exchange, which is not yet completed by ISO. This was fine when >> the implementation was already committed to ISO, but is not good if it >> becomes a universal IP requirement. See ISO 10589 for router-to-x operation over point-to-point links. Dino From owner-big-internet@munnari.oz.au Tue Jul 7 09:12:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00307; Tue, 7 Jul 1992 09:12:47 +1000 (from owner-big-internet) Return-Path: Received: from wolf.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27598; Tue, 7 Jul 1992 07:41:57 +1000 (from forster@cisco.com) Received: from lager.cisco.com by wolf.cisco.com with TCP; Mon, 6 Jul 92 14:41:35 -0700 Message-Id: <9207062141.AA07913@wolf.cisco.com> To: karl@TGV.COM Cc: dino@cisco.com, braden@ISI.EDU, bsimpson@angband.stanford.edu, ietf@ISI.EDU, big-internet@munnari.oz.au Subject: Re: why 160-bit addresses are daft.... In-Reply-To: Your message of "Sat, 04 Jul 92 11:39:07 PDT." <9207041839.AA01366@mel-brooks.empirical.com> Date: Mon, 06 Jul 92 14:41:34 PDT From: Jim Forster >> > Regarding checksum algorithm. >> > 1) Fletcher (OSI) checksum is slower because it is byte oriented. >> >> The "fast" algorithms for Fletcher require a multiply and, if I >> remember right, a modulo calculation. On a large part of the >> hardware base (and especially on wimpy PC's) these are pretty >> expensive instructions (and some risc machines don't even have >> hardware for these.) No multiplication is neccessary. The very dumb implementation would use two modulos per byte, but fortunately Nakassis solved this, and we can use this for an inner loop:. for (p = p1; p < p2; p++) { /* inner sum accumulation loop */ c0 = c0 + (*p); c1 = c1 + c0; } You do the two modulos at the end (typically). -- Jim From owner-Big-Internet@munnari.oz.au Tue Jul 7 13:46:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07349; Tue, 7 Jul 1992 13:47:08 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207070347.7349@munnari.oz.au> Received: from DUNGEON.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07340; Tue, 7 Jul 1992 13:46:59 +1000 (from tmallory@BBN.COM) To: big-internet@munnari.oz.au Cc: tmallory@BBN.COM Subject: Modifying CLNP for IPv7 Date: Mon, 06 Jul 92 23:39:47 -0400 From: Tracy Mallory If we have a free hand at "fixing" CLNP, how about removing the arbitrary restriction of only 20 bytes (er.. octets) per address? The length field for each is a byte, so why not simply allow up to ~120 bytes of address each for source and destination? We obviously won't need it for a while, but it makes room for any sort of PIP address and identification fields. Perhaps 120 is stretching it a bit... I'd also like to suggest that we keep the notion of mixing and matching different protocol layers in mind as new generations of protocols inevitably appear. One of the great failings of most internet protocol designs above level 1 is that they make little attempt to be compatible with other upper and lower layers, and choose to reinvent the entire networking universe each time. It seems a shame that we now are faced with N^^2 possible protocol stacks, and every month or so another SNMP over IPX, or IP over ATM, or TCP over CLNP decision has to be made because some group thought they had all the answers, and/or just wanted to keep control themselves. (short flame: It infuriates me that CLNP doesn't have a codepoint in the DIX (Ethernet V2, Xerox maintained) address space.) Regards, Tracy From owner-Big-Internet@munnari.oz.au Tue Jul 7 13:48:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07373; Tue, 7 Jul 1992 13:48:56 +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 AA07368; Tue, 7 Jul 1992 13:48:41 +1000 (from vjs@rhyolite.wpd.sgi.com) Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for big-internet@munnari.oz.au id AA15478; Mon, 6 Jul 92 20:48:23 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:tmallory@BBN.COM id AA13636; Mon, 6 Jul 92 21:48:18 -0600 Date: Mon, 6 Jul 92 21:48:18 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9207070348.AA13636@rhyolite.wpd.sgi.com> To: Tracy Mallory Subject: Re: IPv7 Checksum Cc: big-internet@munnari.oz.au > From: Tracy Mallory > > Vernon, > > Your note was clear and expressed most of my thoughts regarding internet > header checksums very well. I'd like to add an additional point of > comparison. > > > The perhaps excessive simplicity of the IPv4 checksum has some advantages: > > (1) relatively easy to do in hardware at gigabit speed. > > (2) easy to do parts of the packet in various places > > e.g. compute the checksum of the data while copying to or from > > user buffers, and later combine that checksum with > > the psuedo-header > > (3) easy to do incremental checksum updates using only standard 1's > complement addition, and updates on contiguous regions larger > than a byte can be easily optimized. That's what I meant by "distribute over concatentation". I hoped that sloppy formalism would suggest the general ideas of computing the checksum of parts of a buffer and later computing a checksum of the entire buffer by somehow combining the checksums of the part. It was also intended to connote the idea of computing the checksums of an entire buffer and part of the buffer, and from those two checksum, computing the checksum of the other part. Both of those operations are easy with the TCP checksum. I'd forgotten the common practice of just fudging the checksum based on changes to the TTL or even the IP addresses. However, that's a special case of "distributing the checksum over concantenation". > While the Fletcher checksum can be both computed and verified using only > one's complement addition, it can be easily updated only by > precomputation, since a change to any value already checksummed requires > (at least) multiplication to compute the new checksum. The incremental > update method used when the Packet Lifetime is decremented is a fine > example of precomputation in action (if you understood it on the first > try, my hat's off to you). Most general purpose RISC processors provide > fast (1-4 cycles) multiplication, but [I've been led to understand that] > general purpose multipliers use a lot of gates, and it's probably hard to > justify adding even a special purpose multiplication to a custom ASIC > implementation. I don't know about all general purpose RISC processors, but the two I do know about (MIPS and AMD) takes more than 1-4 cycles for a general integer multiply. You could get 1-4 cycles if you use the floating point hardware, but you can't do that in a UNIX kernel, because kernel code (at least for the R[34]000 UNIX kernel I know about) is unwilling to waste the cycles to save state on every interrupt and system call. As I recall, when playing buffer games, you must multiply in Fletcher's by the number of bytes accumulated, and so can't use the usual RISC compiler-strength reduction. I also meant to complain about computing the Fletcher checksum in hardware. Since other comments suggest other people have not considered that issue, I'll bore you with the detail. With the TCP checksum, you can partition a stream of bytes into two or more streams of 2-byte or 4-byte words, sum those streams with simple, fast adders, and at the end combine the sums in the familar way with easy hardware. (Odd bytes are handled exceptionally.) It is not so easy (i.e. impractical) with Fletcher's. Some people think this matters when trying to build a "flow-through router" for Gigabyte/sec data streams. > Further, if not precomputed, updating must be performed one octet at a time, > which makes it even more expensive. > > [I've skipped mentioning division since the divide step (mod 255) shown in > many algorithms can be relaced with standard 1's complement mask-shift-add > steps.] Yes. Many people forget that point. Vernon Schryver, vjs@sgi.com From owner-big-internet@munnari.oz.au Tue Jul 7 15:00:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09013; Tue, 7 Jul 1992 15:00:12 +1000 (from owner-big-internet) Return-Path: Message-Id: <9207070500.9013@munnari.oz.au> Received: from DUNGEON.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27225; Tue, 7 Jul 1992 07:25:51 +1000 (from tmallory@BBN.COM) To: Vernon Schryver Cc: big-internet@munnari.oz.au Subject: Re: IPv7 Checksum In-Reply-To: Your message of Sun, 05 Jul 92 21:49:25 -0600. <9207060349.AA04165@rhyolite.wpd.sgi.com> Date: Mon, 06 Jul 92 17:22:09 -0400 From: Tracy Mallory Vernon, Your note was clear and expressed most of my thoughts regarding internet header checksums very well. I'd like to add an additional point of comparison. > The perhaps excessive simplicity of the IPv4 checksum has some advantages: > (1) relatively easy to do in hardware at gigabit speed. > (2) easy to do parts of the packet in various places > e.g. compute the checksum of the data while copying to or from > user buffers, and later combine that checksum with > the psuedo-header (3) easy to do incremental checksum updates using only standard 1's complement addition, and updates on contiguous regions larger than a byte can be easily optimized. While the Fletcher checksum can be both computed and verified using only one's complement addition, it can be easily updated only by precomputation, since a change to any value already checksummed requires (at least) multiplication to compute the new checksum. The incremental update method used when the Packet Lifetime is decremented is a fine example of precomputation in action (if you understood it on the first try, my hat's off to you). Most general purpose RISC processors provide fast (1-4 cycles) multiplication, but [I've been led to understand that] general purpose multipliers use a lot of gates, and it's probably hard to justify adding even a special purpose multiplication to a custom ASIC implementation. Further, if not precomputed, updating must be performed one octet at a time, which makes it even more expensive. [I've skipped mentioning division since the divide step (mod 255) shown in many algorithms can be relaced with standard 1's complement mask-shift-add steps.] Tracy From owner-big-internet@munnari.oz.au Tue Jul 7 16:18:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11159; Tue, 7 Jul 1992 16:18: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 AA09226; Tue, 7 Jul 1992 15:09:50 +1000 (from deering@parc.xerox.com) Received: from skylark.parc.xerox.com ([13.2.116.7]) by alpha.xerox.com with SMTP id <11785>; Mon, 6 Jul 1992 22:09:33 PDT Received: from localhost ([127.0.0.1]) by skylark.parc.xerox.com with SMTP id <22277>; Mon, 6 Jul 1992 22:09:22 -0700 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, deering@parc.xerox.com Subject: Re: Mobile Hosts and IDs In-Reply-To: Your message of Fri, 26 Jun 92 12:37:14 -0700. <9206261937.AA08754@ginger.lcs.mit.edu> Date: Mon, 6 Jul 1992 22:09:16 PDT From: Steve Deering Message-Id: <92Jul6.220922pdt.22277@skylark.parc.xerox.com> Noel, This is a response to your message of more than a week ago (which seems like an eternity, at the metabolic rate of this mailing list), in which you criticized the idea of using "addresses" both to identify a mobile host and to identify its current location. You said: > Addresses are names which are used by the routing, primarily to > identify network attachment points. To use them to name something else (like > hosts) will work, but the mechanism required to make them work in this new > application will not be as clean as the mechanism you could have had if > you had picked some more appropriate name. > It's another general rule of system design that big systems don't > break; they just get more and more hard to use and modify as the accrete > more and more poorly integrated special purpose mechanisms. This applies > to a network architecture (which is, after all, just a *giant* distributed > program) just as well as it does to an operating system or any other big > system. I'd just like to point out that the kind of overloading of the address space advocated by the recent work on IP support for mobile hosts (e.g., the Columbia and the Sony work) has a good analog in the area of computer architecture: virtual memory. In VM, the same address space is used for virtual addresses (to name objects) and for real addresses (to name locations). Perhaps VM was considered a kludge when it was first invented, but I think it has proven to be an elegant and powerful mechanism. The Sony proposal, in fact, is explicitly based on the notion of virtual addresses, implemented by a "Virtual IP Layer" layered on top of the "Real IP Layer". > So, will it work to use addresses for something other than identifying > network attachment points? Yes. Is it good system engineering practice to > do that? No. Should we change it? Yes. I do wish you would try to be a little less dogmatic. Other people's judgement of "good system engineering practice" may reasonably differ from yours. Steve From owner-big-internet@munnari.oz.au Tue Jul 7 16:27:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11383; Tue, 7 Jul 1992 16:28:04 +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 AA10427; Tue, 7 Jul 1992 15:51:19 +1000 (from vjs@rhyolite.wpd.sgi.com) Received: from rhyolite.wpd.sgi.com by sgi.sgi.com via SMTP (911016.SGI/910110.SGI) for big-internet@munnari.oz.au id AA21570; Mon, 6 Jul 92 22:51:12 -0700 Received: by rhyolite.wpd.sgi.com (920330.SGI/911001.SGI) for @sgi.sgi.com:big-internet@munnari.oz.au id AA14577; Mon, 6 Jul 92 23:51:08 -0600 Date: Mon, 6 Jul 92 23:51:08 -0600 From: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Message-Id: <9207070551.AA14577@rhyolite.wpd.sgi.com> To: big-internet@munnari.oz.au Subject: Re: IPv7 Checksum fbaker@acc.com (Fred Baker) writes: > >> So, Jon, should IPv7 use the IPv4 checksum, or can we come up with a > >> different checksum that also provides byte swap protection but is > >> easier/faster to compute than the 8473 checksum? > > Jon, Bob: > > Here's a suggestion; I think it provides what you're looking for except > for bytes of all zeroes. You'll recognize it as deriving from XNS IDP, > which uses the same algorithm on 16 bit words. > > I use an operator ROTATE_LEFT(value,n). In C, that would be calculated as > > MASK & ((value << n) | (value >> (WORD_SIZE - n))) > .... This old checksum is a favorite of mine--I saw it first on the SDS-940 on 24-bit words in the 60's. It would detect more errors than the TCP checksum, but it would be a bit painful for "incremental checksumming" and other handy speed improving games. Consider what you'd need to do to adjust the TTL. It's not as painful as Fletcher's, but nothing you'd want to do in copyin/copyout() in a UNIX kernel, nor something you'd enjoy in silicon. Or so it seems to me. Vernon Schryver, vjs@sgi.com From owner-Big-Internet@munnari.oz.au Tue Jul 7 22:41:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19023; Tue, 7 Jul 1992 22:41: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 AA19018; Tue, 7 Jul 1992 22:41:03 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA17876 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 7 Jul 1992 22:40:58 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA13837; Tue, 7 Jul 92 22:40:58 EST Message-Id: <9207071240.AA13837@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Multiple addresses Date: Tue, 07 Jul 92 22:40:58 +1000 From: Bob Smart I think I've worked out one of the key questions that has to be resolved. Noel's image of an address formed by non-overlapping nested circles means that you get one address per interface, as with IP4. This is equivalent in PIP terms of picking one possible route from the root of the address hierarchy to the interface. The effect of having only one address is that to describe different ways to get to that interface you have to give a loose source route consisting of a sequence of complete addresses. That can't be at all compact. That is probably why Noel is concerned about having source chosen addresses in each packet. Also I am not sure how the information that the source needs to pick a route is kept and made available to the source. The alternative system of provider oriented heirarchical addresses means that an interface can have multiple addresses in the DNS. To me it seems that this gives information in a very convenient form to the source that has to choose the way the packet should go. It also allows source routed addresses that are very compact: see the PIP documents. There don't seem to be any significant costs in allowing multiple addresses? - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - It would be nice if the IETF could agree at its upcoming meeting that: 1. Choosing CLNP doesn't simplify anything unless CLNP addressing and routing is also chosen. 2. We need something that will scale better than IP4, and CLNP (as is) will scale worse. 3. While we could squeeze a new addressing and routing architecture into CLNP's 160 bit addresses, it would be a pointless exercise. 4. We need a solution that will preserve complete connectivity between the old world and the new for long enough to phase out the old (6 years if you're lucky). The only current proposal that looks likely to do that (allow existing host software/hardware to work unchanged) is Noel's proposal to separate address from ID and use the IP4 address as the ID initially. This (together with Milo's suggestions) allows a dense use of the 32 bit space. Bob Smart From owner-Big-Internet@munnari.oz.au Tue Jul 7 22:45:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19138; Tue, 7 Jul 1992 22:45:12 +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 AA19129; Tue, 7 Jul 1992 22:45:00 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA27725; Tue, 7 Jul 92 05:44:51 -0700 Received: by sneezy (5.57/ULTRIX-4.2-3)id AA27510; Tue, 7 Jul 92 08:44:48 -0400 To: bsimpson@angband.stanford.edu Subject: Re: CLNP/IP7 over PPP In-Reply-To: <515.bsimpson@angband.stanford.edu> References: <515.bsimpson@angband.stanford.edu> Cc: big-internet@munnari.oz.au X-Mailer: Poste 2.0B3 From: Dave Oran Date: Tue, 7 Jul 92 08:44:16 -0400 Message-Id: <920707084416.15893@sneezy.lkg.dec.com> Encoding: 40 TEXT, 5 TEXT SIGNATURE > The problem is, his proposal depends on address negotiation using an > ES-IS exchange, which is not yet completed by ISO. Could you fill me in on what this is about? I know you want to run ESIS on PPP so you can tell a host-host link from a host-router link from a router-router link. This is something I believe is statically configured in the IP world today, so using ESIS actually may give you more functionality. On the other hand, I don't get the business about address negotiation. Are you talking about using the ISO dynamic address assignment scheme on ESIS with PPP to assign addresses to dial-in hosts? If so that is more than today's PPP/IP implementations do. It is true, however, that the ESIS enhancements for dynamic address assignment have not passed their final approval yet. They are between initial and final ballot, about the same stage a draft internet standard is in the IETF process. >This was fine when > the implementation was already committed to ISO, but is not good if it > becomes a universal IP requirement. > I don't follow your argument here. Why? > 1) this is another area that the OSI standard isn't sufficiently > complete to migrate from IP to CLNP. Again, I must be missing something here. Why? > 2) this means that all PPP IP links will need to implement ES-IS, even > if they don't adopt other parts of ISO. This is true only if you want to use the autoconfiguration ESIS gives you. You could settle for all of the manual configuration you have to do for IP in the absence of DHCP, Router Discovery, etc., but ESIS is the protocol you run to get those things. It seems just as logical to use ESIS on PPP as it would to run DHCP and router discovery. Are there PPP mappings for those protocols as RFCs? I'm sorry if the above responses don't address your concern. I have the nagging feeling that theres something basic in your note that I'm missing. It would be helpful if you could try again to articulate the problem. 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 Tue Jul 7 23:53:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20533; Tue, 7 Jul 1992 23:53:35 +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 AA20530; Tue, 7 Jul 1992 23:53:24 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Tue, 7 Jul 92 09:53:09 EDT Received: by chiya.bellcore.com (4.1/4.7) id for smart@mel.dit.csiro.au; Tue, 7 Jul 92 09:53:07 EDT Date: Tue, 7 Jul 92 09:53:07 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207071353.AA02610@chiya.bellcore.com> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: Multiple addresses > > The alternative system of provider oriented heirarchical addresses means > that an interface can have multiple addresses in the DNS. To me it > seems that this gives information in a very convenient form to the > source that has to choose the way the packet should go. It also allows > source routed addresses that are very compact: see the PIP documents. > > There don't seem to be any significant costs in allowing multiple addresses? The significant cost of this in traditional IP is in managing the addresses in stub networks, since the "prefix" can change from time to time, or hosts internally have multiple addresses. But, these problems can be solved either with appropriate protocol mechanisms (which OSI is very close to having), or by the Pip trick of hiding external addressing info from internal routers and hosts. > > 2. We need something that will scale better than IP4, and CLNP (as is) > will scale worse. Using the existing RFC on NSAP allocation, CLNP will scale better than IP4. PT ps. (This doesn't mean I support the CLNP choice. But I think CLNP will scale well (can be made to scale well), but is so weak on policy and general evolvability that I hope we can do better.) From owner-Big-Internet@munnari.oz.au Wed Jul 8 00:33:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22256; Wed, 8 Jul 1992 00:34:12 +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 AA22249; Wed, 8 Jul 1992 00:33:43 +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 AA20926; Tue, 7 Jul 92 07:33:21 -0700 Received: by hpindda.cup.hp.com (15.11/15.5+IOS 3.20+cup+OMrelay) id AA04593; Tue, 7 Jul 92 07:33:13 pdt From: Eva Kuiper Message-Id: <9207071433.AA04593@hpindda.cup.hp.com> Subject: Re: Future of IP: Making it Happen To: dcrocker@Mordor.Stanford.EDU Date: Tue, 7 Jul 92 7:33:10 PDT Cc: big-internet@munnari.oz.au, ietf@ISI.EDU, eva@hpindda.cup.hp.com In-Reply-To: <9207052236.AA22241@Mordor.Stanford.EDU>; from "Dave Crocker" at Jul 05, 92 3:36 pm Mailer: Elm [revision: 64.9] Dave, Since you brought up making it happen, I'd like to mention the CLNP successes we have had to date. Last year we wanted to show CLNP on the Internet for Interop '91. In a period of about 3 months we had 25 regionals running CLNP with CLNP connections worldwide. Susan Hares from Merit coordinated this effort. She leads the NOOP group at IETF. Each of the router vendors donated time to instruct the regionals on the use of the routing for CLNP. Since we had no administrative authority for NSAPs on the Internet, OSINET assigned a portion of its address space. We had several hotstages for the router vendors where they verified interoperation before the end systems tried to connect. From all this we learned quite a bit. ESNET is running production CLNP now. Other regionals in the US have pilots for CLNP connections. The international standards are at or near completion. Even when they weren't, router vendors implemented draft versions. 3COM has had IS-IS for several years now since they started prototyping as the standard was being developed. All of the existing router vendors have the ability to route CLNP today. Today I can use CLNP over X.25 and connect to folks on CLNP networks in the US and Europe. The administrative guidelines which need to be developed belong to the Internet folks, not to ISO. A end system running ES-IS should be unaware of what type of routing a particular regional chooses. The network also in unaware of what protocols are running above the network layer. Multiprotocol routing and coexistence works today on the Internet. Lyman is not telling us about creating something new. We have also shown that not everyone has to change at once. I hope that we can all lend Susan a helping hand to continue to make this happen! Eva Kuiper HP From owner-big-internet@munnari.oz.au Wed Jul 8 01:00:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22925; Wed, 8 Jul 1992 01:00:33 +1000 (from owner-big-internet) Return-Path: Received: from gizmo.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18819; Tue, 7 Jul 1992 22:28:48 +1000 (from mo@gizmo.bellcore.com) Received: by gizmo.bellcore.com (5.61/1.34) id AA23501; Tue, 7 Jul 92 08:28:35 -0400 Date: Tue, 7 Jul 92 08:28:35 -0400 From: mo@gizmo.bellcore.com (Michael O'Dell) Message-Id: <9207071228.AA23501@gizmo.bellcore.com> To: big-internet@munnari.oz.au Subject: did Simpson's "An Extensible IP System Number" proposal get lost? for my money, this proposal is clear, concise, and is no harder to implement than any of the others i've seen. it should be releatively straight-forward to roll this into existing IP implementations and it provides as much as we need only when we need it. it will even work with CLNP (not that I consider this a feature). while it doesn't address Noel's fundamental concerns, it looks like it is at least as workable a transition vehicle as any of the other more radical solutions. so am I off in the weeds here? (metaphorically speaking) -Mike From owner-Big-Internet@munnari.oz.au Wed Jul 8 01:06:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23124; Wed, 8 Jul 1992 01:07:02 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23121; Wed, 8 Jul 1992 01:06:53 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA05731; Tue, 7 Jul 92 08:02:13 PDT Message-Id: <9207071502.AA05731@Mordor.Stanford.EDU> To: Eva Kuiper Cc: big-internet@munnari.oz.au, ietf@ISI.EDU Subject: Re: Future of IP: Making it Happen Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Tue, 07 Jul 92 07:33:10 -0700. <9207071433.AA04593@hpindda.cup.hp.com> Date: Tue, 07 Jul 92 08:02:12 -0700 From: Dave Crocker Eva, Hearing of CLNP demonstrations and vendor support is, of course, good news. But perhaps I should clarify what I was/am suggesting: Wherever the Internet ends up, there is a great deal of work to be done to get there. Alternatives need to be evaluated (or even designed.) Transitions need to be planned. And it is the _work_ that I am eliciting from the community. As one, small example, I will observe that _NOT ONE_ of the current alternatives has a fully fleshed-out addressing scheme designed for the Internet. By some simple measures, this is the only interesting task in this whole matter, yet we, the community, have made little progress in designing a solution. (Not CLNP, Not IPAE, ...) The nature of the design may well dictate the cost to a customer that chooses to change network suppliers, for example. This is a very, very important design topic. So I am encouraging the broad range of community members to participate in the development and selection of whatever technical work is before us, _as_ _the_ _community_ _usually_ _does_. Dave From owner-Big-Internet@munnari.oz.au Wed Jul 8 01:40:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23800; Wed, 8 Jul 1992 01:40:30 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23786; Wed, 8 Jul 1992 01:40:19 +1000 (from dkatz@cisco.com) Received: by cider.cisco.com; Tue, 7 Jul 92 08:39:47 -0700 Date: Tue, 7 Jul 92 08:39:47 -0700 From: Dave Katz Message-Id: <9207071539.AA25942@cider.cisco.com> To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au, ietf-ppp@ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Mon, 6 Jul 92 14:58:34 EDT <516.bsimpson@angband.stanford.edu> Subject: CLNP/IP7 over PPP ES-IS has been a full international standard for a number of years now. The only part of it that is still in progress is the address administration stuff (like RARP). The current ES-IS is just fine for the exchange of address information (and isn't even necessary for routers running IS-IS, which has its own mechanism), as well as router discovery and redirect. Where's the problem? Every existing CLNP implementation that I've seen has an ES-IS implementation sitting right beside it, and it's not exactly rocket science to implement. C'mon, there's plenty of other things to worry/complain/flame about without canards like this. Sender: ietf-ppp-request@ucdavis.edu Date: Mon, 6 Jul 92 14:58:34 EDT From: "William Allen Simpson" Within the PPP Working Group, we have been discussing the use of OSI protocols over PPP. Dave Katz wrote a draft over two years ago, and we are just now seeing implementations. The problem is, his proposal depends on address negotiation using an ES-IS exchange, which is not yet completed by ISO. This was fine when the implementation was already committed to ISO, but is not good if it becomes a universal IP requirement. 1) this is another area that the OSI standard isn't sufficiently complete to migrate from IP to CLNP. 2) this means that all PPP IP links will need to implement ES-IS, even if they don't adopt other parts of ISO. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Wed Jul 8 02:17:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24513; Wed, 8 Jul 1992 02:17:49 +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 AA24509; Wed, 8 Jul 1992 02:17:38 +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 AA23088; Tue, 7 Jul 92 09:17:31 -0700 Received: by hpindda.cup.hp.com (15.11/15.5+IOS 3.20+cup+OMrelay) id AA09968; Tue, 7 Jul 92 09:17:31 pdt From: Eva Kuiper Message-Id: <9207071617.AA09968@hpindda.cup.hp.com> Subject: Re: Future of IP: Making it Happen To: dcrocker@Mordor.Stanford.EDU Date: Tue, 7 Jul 92 9:17:28 PDT Cc: big-internet@munnari.oz.au, ietf@ISI.EDU, eva@hpindda.cup.hp.com In-Reply-To: <9207071502.AA05731@Mordor.Stanford.EDU>; from "Dave Crocker" at Jul 07, 92 8:02 am Mailer: Elm [revision: 64.9] Dave, > > Wherever the Internet ends up, there is a great deal of work to be > done to get there. Alternatives need to be evaluated (or even > designed.) Transitions need to be planned. And it is the _work_ that > I am eliciting from the community. This is exactly the work I am talking about also. The technology exists today. The network design and transition plan needs manpower. It became quite obvious during the piloting of CLNP that addresses probably needed some kind of subsetting by regionals to keep routing sane. Susan is addressing those issues as well. She needs all the help she can get. Anyone can assign an address, but address assignment also needs thinking into the potential routing schemes which the address implies. This is true whatever the network layer happens to be. Routing schemes imply routing management, etc. There is indeed a lot of work to be done. A lot can be borrowed from the experience already gained. I am encouraging folks to help Susan achieve success in the work she has been championing for so long. Its time for folks to roll up their sleeves and help her get the job done. Eva > > As one, small example, I will observe that _NOT ONE_ of the current > alternatives has a fully fleshed-out addressing scheme designed for > the Internet. By some simple measures, this is the only interesting > task in this whole matter, yet we, the community, have made little > progress in designing a solution. (Not CLNP, Not IPAE, ...) The > nature of the design may well dictate the cost to a customer that > chooses to change network suppliers, for example. This is a very, > very important design topic. So I am encouraging the broad > range of community members to participate in the development and selection > of whatever technical work is before us, _as_ _the_ _community_ _usually_ > _does_. > > Dave > From owner-big-internet@munnari.oz.au Wed Jul 8 04:10:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26768; Wed, 8 Jul 1992 04:11:05 +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 AA24432; Wed, 8 Jul 1992 02:14:57 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA03472; Tue, 7 Jul 92 09:14:20 PDT Date: Tue, 7 Jul 92 09:14:20 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9207071614.AA03472@saffron.acc.com> To: vjs@rhyolite.wpd.sgi.com Subject: Re: IPv7 Checksum Cc: big-internet@munnari.oz.au >> > Here's a suggestion; I think it provides what you're looking for except >> > for bytes of all zeroes. You'll recognize it as deriving from XNS IDP, >> > which uses the same algorithm on 16 bit words. [ statement of algorithm: one's complement sum of octets, with left rotation] >> > .... >> This old checksum is a favorite of mine--I saw it first on the SDS-940 >> on 24-bit words in the 60's. It would detect more errors than the TCP >> checksum, but it would be a bit painful for "incremental checksumming" >> and other handy speed improving games. Consider what you'd need to >> do to adjust the TTL. I'm a bit puzzled by this concern. I just checked our IDP code, and incremental TTL update is pretty straightforward. The one's complement sum solves that problem. Fred From owner-Big-Internet@munnari.oz.au Wed Jul 8 04:41:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27550; Wed, 8 Jul 1992 04:41: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 AA27546; Wed, 8 Jul 1992 04:41:28 +1000 (from dino@cisco.com) Received: by regal.cisco.com; Tue, 7 Jul 92 11:39:31 -0700 Date: Tue, 7 Jul 92 11:39:31 -0700 From: Dino Farinacci Message-Id: <9207071839.AA18468@regal.cisco.com> To: dave@sabre.bellcore.com Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, ietf@isi.edu, road@lanl.gov In-Reply-To: dave@sabre.bellcore.com's message of Tue, 7 Jul 1992 11:34:17 -0500 <9207071533.AA25995@sword.bellcore.com> Subject: IPv7 (CLNP) a mistake >> 1- you gotta implement it or you die >> 2- you don't have to implement it, but if you don't and you >> receive it, you gotta discard the packet >> 3- you don't have to implement it, and if you receive it, be >> rude: ignore it, and process the packet as if it weren't >> there Or do what most do when they don't route it, *bridge it* ;-) Dino From owner-Big-Internet@munnari.oz.au Wed Jul 8 05:31:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28388; Wed, 8 Jul 1992 05:31:56 +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 AA28385; Wed, 8 Jul 1992 05:31:48 +1000 (from akkana@hppces1.svale.hp.com) Received: from hppces1.svale.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA28329; Tue, 7 Jul 92 12:31:43 -0700 Received: by hppces1.svale.hp.com (15.11/15.5+IOS 3.21) id AA18418; Tue, 7 Jul 92 12:30:48 pdt Message-Id: <9207071930.AA18418@hppces1.svale.hp.com> From: akkana@hppces1.svale.hp.com (Akkana) Date: Tue, 7 Jul 1992 12:30:47 -0700 Reply-To: akkana@netcom.com Work-Phones: (415)321-4006, (408)720-3788 Home-Phone: (408)736-8643 X-Mailer: Z-Mail (2.0.0 7/1/91) To: big-internet@munnari.oz.au Subject: subscription request Please add me to the big-internet mailing list. Thanks! (And please use the netcom address in the signature, not the address from which I'm mailing this request.) -- ...Akkana akkana@netcom.com From owner-big-internet@munnari.oz.au Wed Jul 8 05:57:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28736; Wed, 8 Jul 1992 05:57:04 +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 AA26528; Wed, 8 Jul 1992 03:57:59 +1000 (from dab@berserkly.cray.com) Received: from handel.cray.com by timbuk.cray.com (4.1/CRI-MX 1.6ag) id AA08852; Tue, 7 Jul 92 12:57:47 CDT Received: by handel.cray.com id AA10116; 5.57/CRI-5.5; Tue, 7 Jul 92 12:56:28 -0500 Date: Tue, 7 Jul 92 12:56:28 -0500 From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9207071756.AA10116@handel.cray.com> To: big-internet@munnari.oz.au, mo@gizmo.bellcore.com Subject: Re: did Simpson's "An Extensible IP System Number" proposal get lost? > From owner-big-internet@munnari.oz.au Tue Jul 7 11:23:25 1992 > Date: Tue, 7 Jul 92 08:28:35 -0400 > From: mo@gizmo.bellcore.com (Michael O'Dell) > To: big-internet@munnari.oz.au > Subject: did Simpson's "An Extensible IP System Number" proposal get lost? > > for my money, this proposal is clear, concise, and is no harder to > implement than any of the others i've seen. it should be releatively > straight-forward to roll this into existing IP implementations and it > provides as much as we need only when we need it. it will even work > with CLNP (not that I consider this a feature). > > while it doesn't address Noel's fundamental concerns, it looks like > it is at least as workable a transition vehicle as any of the other > more radical solutions. > > so am I off in the weeds here? (metaphorically speaking) > > -Mike It's a problem if you try to roll this into existing IP implementations, and don't do anything about the IP Header Length field. As it is today, you only have 40 bytes for IP options. If you use the g type address that Bill proposes, at 16 bytes each, you wind up with only 16 bytes for the IP options. It'll work better with CLNP, since they have larger headers. Just changing the size of the IP address in the existing IP packet format without changing the max length of the IP header would not be a good solution. -David Borman, dab@cray.com From owner-big-internet@munnari.oz.au Wed Jul 8 07:02:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00439; Wed, 8 Jul 1992 07:02:07 +1000 (from owner-big-internet) Return-Path: Received: from cise.cise.nsf.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29125; Wed, 8 Jul 1992 06:16:25 +1000 (from steve@cise.cise.nsf.gov) Received: from ncri.cise.nsf.gov by cise.cise.nsf.gov id ; Tue, 7 Jul 92 16:15:43 -0400 Received: by ncri (5.57/Spike-2.0) id AA03433; Tue, 7 Jul 92 16:13:48 -0400 Message-Id: <9207072013.AA03433@ncri> To: farber@central.cis.upenn.edu Subject: Re: Milo going Nova. Cc: lixia@parc.xerox.com, ietf@isi.edu Cc: big-internet@munnari.oz.au, hwb@upeksa.sdsc.edu Date: Tue, 07 Jul 92 16:12:21 EDT From: Stephen Wolff >I propose that the agencies recognize that development needs to be done to >keep and expand the network as well as research into the edge domains such >as gigabits etc. In Physics, I suspect, every part of building a Super >Collider is not research. It is developing gadgets that enable facilities >for research to be done. Lets try to get money set aside for such >development activities that are judged by the metrics of short term needs >not academic research. NSF does, as you will remember, support development projects for NSFNET and the international network infrastructure generally. A Z39.50 implementation and gated are two from the distant past that come to mind; FOX and the X.400 projects are more recent. We will continue to accept unsolicited proposals for such work; peer reviewers will be drawn from the Internet community, and successful proposals will be funded out of the NSFNET budget line. -s From owner-Big-Internet@munnari.oz.au Wed Jul 8 07:30:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01698; Wed, 8 Jul 1992 07:30:59 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01683; Wed, 8 Jul 1992 07:30:46 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA08313; Tue, 7 Jul 92 14:30:37 PDT Message-Id: <9207072130.AA08313@Mordor.Stanford.EDU> To: vjs@rhyolite.wpd.sgi.com (Vernon Schryver) Cc: Tracy Mallory , big-internet@munnari.oz.au Subject: Re: IPv7 Checksum Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 06 Jul 92 21:48:18 -0600. <9207070348.AA13636@rhyolite.wpd.sgi.com> Date: Tue, 07 Jul 92 14:30:36 -0700 From: Dave Crocker Clearly, knowing the expense of writing the software mods for any of the proposed architectural/addressing changes is essential. What I am generally _not_ noting in the various suggestions floating through the net is any serious discussion about the impact of these changes on the installed base. What do users, sales folk, customer support folk, operations folk, etc. have to learn that is different from what they now know? What are the transition steps tht will be required to move to the proposed technology? How disruptive will the steps be? How expensive/risky will they be? What happens to the late-adopters? How can the new technology be administered and otherwise operated? (Well, of course, not _all_ of the proposals are ignoring these issues...) Dave From owner-big-internet@munnari.oz.au Wed Jul 8 11:13:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08908; Wed, 8 Jul 1992 11:13:04 +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 AA07932; Wed, 8 Jul 1992 10:35:58 +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 AA07582; Tue, 7 Jul 92 17:35:50 -0700 Received: by hpindda.cup.hp.com (15.11/15.5+IOS 3.20+cup+OMrelay) id AA24811; Tue, 7 Jul 92 17:35:46 pdt From: Eva Kuiper Message-Id: <9207080035.AA24811@hpindda.cup.hp.com> Subject: Re: IPv7 == CLNP or CLNP+ ? To: wheeler@jeckle.mitre.org Date: Tue, 7 Jul 92 17:35:45 PDT Cc: jnc@ginger.lcs.mit.edu, big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, ietf@ISI.EDU In-Reply-To: <9207061358.AA17284@jeckle>; from "wheeler@jeckle.mitre.org" at Jul 06, 92 9:58 am Mailer: Elm [revision: 64.9] Brien, You are quite right. If ISO and CCITT had stopped with the '84 X.400 we would not have the greatly enhanced '88 additions. It is because they were willing to progress when the needs arose that we have the '88 and now the '92. Of course, this really means the volunteer standards folks who contributed to the creation of the new features. We learned a lot from implementing and deploying the '84 standards and saw what was missing and what was needed for support of remote access and message store and security and extensibility of body parts. A lot of people contributed to this effort and we now have a richer and more flexible standard as a result. All standards evolve as new technologies arise which create new needs. Eva > > > Given this deployed base, won't that make it that much harder to get > > non-interoperable modifications to the basic CLNP through the ISO? Is the ISO > > really going to be willing to obsolete the substantial investment made by all > > the vendors and users who have taken the path the ISO laid out? > > It sure will be. Just look at '88 X.400 vs. '84 X.400. > > Brien > > > From owner-Big-Internet@munnari.oz.au Wed Jul 8 11:51:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09997; Wed, 8 Jul 1992 11:51:49 +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 AA09990; Wed, 8 Jul 1992 11:51:38 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA26627; Tue, 7 Jul 92 18:51:16 -0700 Date: Tue, 7 Jul 92 18:58:44 EDT From: "William Allen Simpson" Message-Id: <530.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Cc: ietf-ppp@ucdavis.edu Reply-To: bsimpson@angband.stanford.edu Subject: Re: CLNP/IP7 over PPP > From: Dave Katz > ES-IS has been a full international standard for a number of years now. > The only part of it that is still in progress is the address administration > stuff (like RARP). The current ES-IS is just fine for the exchange of > address information (and isn't even necessary for routers running IS-IS, > which has its own mechanism), as well as router discovery and redirect. > Where's the problem? > The problem is that the IAB messages assured us that NO OTHER PART of the OSI suite would need to be implemented. We were asked to identify places where this was not so. I have just identified one. > Every existing CLNP implementation that I've seen has an ES-IS implementation > sitting right beside it, and it's not exactly rocket science to implement. > But how many IP installations have already implemented ES-IS? And how will this interact with the other Internet Suite protocols that duplicate those functions? Every IP system has to run both in parallel for ages to come. Since I don't have the slightest idea what ES-IS looks like, I can't make any judgement call. I just have to raise the issues so that I can get the answers from others. > C'mon, there's plenty of other things to worry/complain/flame about without > canards like this. > As said, I'm identifying problems. In particular, this is a problem for the PPP working group. Since we may be required to support CLNP/IP7 without ES-IS, we may have to add more configuration options to OSI over PPP, a document that we thought was finished. As an alternative, we may need to send IP7 packets as a completely separate protocol flavor from CLNP. This abrogates some of the claimed advantages for CLNP/IP7. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-big-internet@munnari.oz.au Wed Jul 8 12:48:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11545; Wed, 8 Jul 1992 12:48:55 +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 AA05338; Wed, 8 Jul 1992 09:02:54 +1000 (from braden@ISI.EDU) Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Tue, 7 Jul 1992 16:04:08 -0700 Date: Tue, 7 Jul 1992 16:01:50 -0700 From: braden@ISI.EDU Posted-Date: Tue, 7 Jul 1992 16:01:50 -0700 Message-Id: <199207072301.AA06141@braden.isi.edu> Received: by braden.isi.edu (5.65c/4.0.3-4) id ; Tue, 7 Jul 1992 16:01:50 -0700 To: Bob.Hinden@eng.sun.com Subject: Re: Comments on IPv7 Document Cc: big-internet@munnari.oz.au, braden@ISI.EDU Bob, Thanks for your comments. Let me try to answer those I can, to clarify the thinking of the IAB on these issues. From owner-ietf@ISI.EDU Sat Jul 4 14:17:53 1992 Date: Fri, 3 Jul 92 11:46:45 PDT From: Bob.Hinden@eng.sun.com (Bob Hinden) To: ietf@ISI.EDU Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, Bob.Hinden@eng.sun.com Subject: Comments on IPv7 Document Folks, Here are my comments on the IAB recommendation for adopting CLNP as IPv7. I strongly disagree with the overall recommendation presented. IMHO I think what is proposed does not solve one of the key medium term problems which face the Internet. In particular, it does nothing to solve the routing explosion problems until after CLNP is very widely deployed in hosts. I am very concerned that this will occur a long time after the routing table explosion has killed the internet. CIDR alone does not buy us enough time. Bob >>Abstract >> >> Internet growth has created serious problems of address space >> consumption and routing information explosion. A solution to these >> problems requires a new version of the Internet Protocol, which we >> call IP version 7 ("IPv7"). This memo presents architectural >> guidelines that any IPv7 should meet. It then discusses how an IPv7 I see no justification is this document for why a new version of IP is "required" to solve the address space consumption and routing table explosion problems. "Required" here was intended to be interpreted in the light of the requirements set out in Section 2. In particular, it seemed to us that the requirements of architectural simplicity and global uniqueness force one to abandon an encapsulation solution like IPAE, and to change the IP header in order to maintain the present flat forwarding structure of the Internet architecture. I feel inclined to hold out for this architectural principle, regardless of whether or not IPv7 is based on CLNP. More on this below. A new version of IP is one approach, but I don't see why it is required. IPAE and similar approaches present clear alternatives to deploying a new version of IP with much less impact on the existing operational system. Further, no solution to the routing table explosion problem is presented here at all as far as I can tell. In our discussion, we clearly identified IPAE as a technically credible approach, and we recognized its low operational impact. However, as I noted above, we felt that continuing homogeneity of forwarding was a principle we did not want to give up. I suggest that there are lots of hidden costs implicit in introducing the new level of structure implied by Commonwealths. >> based upon the OSI CLNP protocol would meet these requirements, and >> presents the reasons for the IAB's preference for this solution. >> Finally, it makes a three-part recommendation: (1) proceed at full >> speed on CIDR; (2) do the design work on IPv7 based on CLNP; and (3) >> continue to pursue research in advanced routing and other future >> extensions of the Internet architecture. >> 1.1 The Need for IPv7 >> >> The rapid growth of the Internet has exposed the consequences of a >> design choice made 15 years ago, the choice of a fixed-length 32- >> bit address field for IP [IEN-005]. At that time, 32 bits appeared >> to be a very wide field, allowing many thousands of networks and >> millions of hosts, several orders of magnitude beyond the likely >> size of the Internet. However, the Internet has now grown to this >> order of magnitude, leading to two different scaling problems: >> >> * Routing Information Explosion >> >> The cost and complexity of Internet routing grow very rapidly >> with the number of networks. This growth is creating >> increasingly serious operational problems. >> >> * Address Space Consumption >> >> Current IP addresses are 32 bits. While this seems to be a >> very large number (4*10**9), its division into host and >> network parts and into class A, B, and C networks >> significantly reduces the available space. Projections are >> difficult and highly arguable, but at the current rate of >> growth, the existing space may be used up in the foreseeable >> future. I think it is important to also say that the first problem is going to hit much sooner than the second problem. I have not really followed these issues, but I think I have seen claims for the primacy of each. However, it was the intent of the IAB proposal to address both. We saw IPv7 deployment as a natural followon to CIDR deployment, with the address aggregation machinery of CIDR carrying over fairly directly to IPv7. If we only concentrate on the second problem, the first will kill us! I think a major weakness of this proposal is that it only addresses the address space consumption problem. No solution is presented to the Routing explosion problem. >From my understanding of the TCP/UDP over CLNP proposal (Simple CLNP and TUBA), there will not be any significant relief to this problem until there is very widespread deployment of CLNP in hosts. CIDR does The IAB discussion suggested that CIDR and IPv7 will use the same mechanism for limiting the growth of routing tables: route aggregation resulting from hierarchical address assignment. The bottom line is that this is the only mechanism we know of, which we believe can be deployed without a lot more research. In both cases, the hard and critical problem seems to be designing the administrative mechanisms for address assignment. We observed that address assignment becomes somewhat easier if you are released from the 32-bit limit; hence, this would be an important reason to drive towards IPv7. And we were painfully aware of the risks and unknowns in this area; but we could see no acceptable alternative that moves in (what we thought is) the right direction in the long term. not buy us enough time. Given the number of significant issues discussed in section 3 regarding a CLNP deployment that need to be resolved before CLNP can be widely deployed, I don't see any way that can be done in time. I believe that the proposed approach will lead to a fragmented internet. We did not actually think there are many really tough issues in section 3; most are straightforward protocol engineering. In any case, it seemed to us that starting from a known place, the format of CLNP, the engineering would converge more quickly than if we declared open season on the IPv4 header. >> 1.3 Overall Plan >> >> In ROAD discussions, it was useful to divide the solution of the IP >> scaling problems into short-term, medium-term, and long-term phases >> [ROAD]. The real situation is much more complicated, with >> considerable overlap as well as uncertainty about time frames, yet >> this is a useful model for planning. We support the ROAD group >> model that IPv7 belongs to the mid-term time frame, in the sense >> that: >> >> (1) more immediate steps must be taken to avoid exhaustion of the >> address space before IPv7 can be deployed; and >> >> (2) there are substantial research questions which must be >> pursued, but which cannot be expected to be resolved until >> after IPv7 is deployed. >> >> For the short-term effort, we support the ROAD group suggestion of >> CIDR (Classless Inter-domain Routing) [CIDR], a form of "super- >> netting". CIDR will provide short-term relief from exhaustion of >> the address space by breaking the rigidly fixed boundaries that >> define class A, B, and C IP addresses, using a more flexible bit- >> level mask (or equivalently a variable-length address prefix) to >> distinguish the network number. To attack the routing information >> explosion, CIDR will select addresses to match topology, allowing >> the aggregation of routes. As we point out later, this aggregation >> will carry over to, and indeed is important to the success of, >> IPv7. >> >> We do not dwell on CIDR here; there are already several CIDR- >> related engineering efforts in progress in the IETF. This memo >> emphasizes IPv7. Section 2 introduces a set of requirements that >> must be satisfied by any IPv7 architecture, while Section 3 >> discusses two alternative approaches for realizing IPv7. One It is important to also say that CIDR only slows down the routing table growth and buy us some time. How much is uncertain. Without some very radical steps like reassigning all IP addresses (which I know that any customer I have ever talked to would hate due to the cost and disruption of implementing it), what we buy in time will be short lived. Also, as I think we all know, there are still significant technical problems with CIDR that need to be also worked out. I can't say you're wrong; we need more data! >>2. ARCHITECTURAL PRINCIPLES >> ..... >> Before discussing these principles, we make a basic philosophical >> point: whatever the choice for IPv7, its "change control" must rest >> with the IAB/IETF. Despite our desire to eventually converge with >> other standards groups, the ability for protocol and architectural >> evolution within the IRTF and IETF is absolutely essential to the >> continued success of the Internet. It also critical if we embark on this course, that we also retain change control on ALL of the other pieces that go with it. For example, in addition to CLNP, I would think that we would need to "own" the routing protocols (ISIS and IDRP), address resolution (ES-IS), number spaces, network management, and others. Agreed, we would need to have change control over any specification that we had to change to conform to IPv7. That is one reason we suggested carrying forward IPv4-based routing protocols like OSPF. In any case, I don't believe this is insurmountable. All of these would need to have new specifications written and made available as RFC's. This will be a very significant effort. Also the style that the CLNP, ISIS, etc., documents are written in is very different from the style of the TCP/IP documents. I don't see this as an issue. It will not suffice to just republish them if that was possible. There may also be significant copyright issues with making these documents available online. The current mode of obtaining these specifications for CLNP and related protocols (e.g. purchasing a hard copy) is unacceptable to the internet community. We agree completely. >> 2.1. Architectural Simplicity >> >> We believe that the success of the Internet architecture (as >> evidenced by the growth problem discussed in this memo) rests on >> its simplicity, which should be retained to the extent possible. While this is certainly a good goal, from my experience what is proposed here does not seem to be simple. It requires all elements of the internet layer to change. It may be simple from an architectural perspective, but from the products world, it is a very massive expensive change. The paragraph is entitled "architectural simplicity". >> As an example of simplicity, we would prefer an architecture that >> does not introduce any new logical boundaries into the Internet. >> Such boundaries could make the job of address registration and >> route aggregation harder. I am not sure what is meant by a "logical boundary", but a case can also be made that boundaries can simplify administration. This is in no way clearcut. Think of a commonwealth as an example of a logical boundary. Dave Clark has suggested that an alternative Internet architecture would assume hetergentity -- partial connectivity or non-connectivity at the IP level, with e.g. application-layer gateways architected in. The IAB is not willing to buy into that... we want to maintain the concept of a fully-connected and uniform internet-level transport mechanism, with at worst some forbidden paths due to policy routing. And we did not like the logical complexity implied by commonwealths. Clearly, these are issues about reasonable people can differ. >> 2.3. Larger Address Space >> >> Since we require globally unique addresses and since the current >> address space is too small, we must escape the limitations imposed >> by the current 32-bit addresses. The new architecture must allow >> much wider address fields, to accommodate: >> >> (1) registering several millions, or even billions, of networks; >> >> (2) allowing some degree of inefficiency in the address >> registration; >> >> (3) permitting the expression of a hierarchy in the address; >> >> (4) allowing for new addressing architectures in the future, if >> the need arises. >> >> Here (2) and (3) are needed in order to allow decentralized >> registration and route aggregation (see Sections 2.4 and 2.5). >> >> This move to a new address format is likely to impact much host and >> router software; every piece of software that handles an Internet >> address will have to be modified to handle wider addresses. It is >> important to note the nature of this impact: broad (many modules >> affected) but shallow (very specific, localized changes). This is saying that we only have to change everything a little bit. This is a very big impact on products and the operational internet. ANY solution to our growth problems, even IPAE, will have "a very big impact on products and the operational internet". We felt that a change that kept the general principles intact but changed a header format would overall cause less disruption, learning time, etc., than another kind of solution. >> We furthermore argue in favor of a variable-length address format, >> with a known upper bound. This upper bound will need to be large, >> potentially increasing the IP header size significantly. However, >> with a reasonable address assignment scheme, most networks numbers >> will be much smaller. Indeed, it might be desirable to use the >> existing 4-byte IP addresses for many hosts during a transition. Another point that needs to be addressed is the amount of storeage NSAP addresses will take in routers. Ignoring the issue of performance inefficiencies in processing variable length addresses, I fail to understand how routers in this architecture will be able to store large quantities of 20-byte addresses when today they have problems with fewer 4-byte addresses. Memory is certainly getting cheaper, but not by a factor this large. We need larger addresses for sure, but 5 time bigger? We urged variable-length addresses. >> 2.7. Extensibility >> >> Evolution from IPv4 to IPv7 will be occurring at the same time that >> research work is on the verge of requiring architectural extensions >> in other areas. Two important examples are supporting real time >> applications (e.g., packet voice and video) [Realtime], and >> providing better security services. IPv7 should provide easy >> extensibility in order to support such new areas. >> >> In particular, it is vital to escape the 60 byte limit on the IPv4 >> header, in order to have more space available for options. Why is it "vital" to escape the 60-byte limit on IP options? There is a significant body of experience that says the options are a bad idea in the first place. This is the first time I have seen this argument that we should have room for more options. "Bad idea" seems a bit strong. They are an architectural technique for relatively painless extensions; I am not aware of an alternative, but this may just be my ignorance (I would be happy to be wrong here, and if there *is* an alternative, it could certainly affect my own conclusions). >> 2.8. Compatibility >> >> As mentioned above, larger addresses should by no means imply a >> change in the overall Internet architecture. In particular, it >> should certainly not imply a reduction in the network >> functionality. For example, it is mandatory that IPv7 should >> continue to support the IP multicast architecture. Also, the >> current techniques for debugging (e.g., "ping" and "traceroute") >> should still be possible. Yes, but how long will it take to recreate this functionality in CLNP? These are not architectural issues, but are important elements of the current operational internet. We need more than an architecture to build a working internet. Multicast is simply a non-issue, which I keep seeing brought up. IP-style multicasting in CLNP is a done deal technically; the specs are in place. The fact that it is not yet blessed by ISO is irrelevant to the IETF. It's all done, and an IPv7 based upon CLNP would just adopt the proposal for multicast. Ping has been done too, and the requirements for traceroute are in place in CLNP. So, the answer to your question is, not very long at all. >> There are many "tendrils" from IPv4 that reach up into the >> transport and application layers [RFC-1122]. Examples are the >> receipt of ICMP Unreachable, Redirect, and Source Quench messages, >> and setting TOS and TTL values and/or source routes. Other >> examples arise in the use of Internet addresses by applications, >> e.g., IP. We would ideally like to minimize the impact on the >> layers above IP, although this may not prove entirely feasible. >> 2.9. Interoperability >> >> Transition from IPv4 to IPv7 must occupy a number of years, so it >> will be necessary for IPv4 hosts to be able to interoperate with >> IPv7 hosts. A general scheme for handling old/new host >> interoperability, based upon the DNS, is given in [TUBA]. >> >> In order to ease the transition and ensure connectivity within the >> Internet, the addressing plan should allow the address space to be >> *embedded* into the IPv7 space. For example, this will avoid the >> need to maintain parallel routing tables. >> >> The following diagram shows the protocol stack that a host may >> expect to implement. During the transition to IPv7 (which is >> likely to be lengthy), an Internet host must support both IPv4 and >> IPv7. It would use IPv4 for communication with an unmodified host >> [TUBA]. Yes, but what happens after we can no longer route on IP address because the routing has broken down. We will have plenty of IP addresses to assign, but because it will not be possible to route on more than ~100,000 networks, IP will only work in local areas. The sites (hosts, router, DNS, net management, etc) which have not yet added support for CLNP will loose the ability to communicate outside of their area. This will fragment the internet and reduce the motivation of people to want to connect to it. I commented on the routing problem earlier (ref. route aggregation). >>3. POSSIBLE APPROACHES TO IPv7 >> >> Two divergent approaches have been suggested for IPv7. >> >> (1) Some form of IP encapsulation. A good example of this approach >> is the IP Address Encapsulation proposal [IPAE]. >> >> Encapsulation schemes maximize Internet-layer protocol >> compatibility by design; however, these schemes also represent a >> significant change in the IP architecture. I disagree with this notion that IPAE is a significant change in the IP architecture. It is based on the basic mechanisms in the IP architecture. Replacing IP with CLNP and the other associated things that go with it, is also a significant architectural change. Why is one good and the other bad? Well, I guess we just disagree. I think the introduction of a new layer of encapsulation and a new level of entity having different access rules is a significant complication of the architecture. Making the addresses bigger does not change the architecture. Before IPAE and similar approaches are discarded, it should be allowed a full and open discussion of its advantages and disadvantages. Doing otherwise, IMHO would be a great disservice to the internet community. That's a non-technical issue that I would rather not address at this time. I do understand your desire here, and I expect you will realize it. >> (2) Keep the IP architecture essentially unchanged, but change the >> format of an IP header to expand the addresses. There is much more to do than changing the format of the IP header. Real operational and product issues must be addressed. It is too simple to just say that we need a new header. What is proposed is much much more than just changing the format of the IP header. I would certainly agree that "Real operational and product issues must be addressed". >> The IAB proposal is to adopt the CLNP protocol specification and >> packet formats for IPv7. The eventual consequence of this decision >> will be the publication, at some point in the future, of a complete >> IPv7 specification that is functionally and syntactically compatible >> with CLNP (defined by the second edition of the ISO 8473 standard, >> published in 1992). The intent is to run the existing and future >> Internet transport protocols -- in particular, TCP and UDP -- above >> IPv7. This would let us benefit from the larger addresses of CLNP >> while maintaining the present Internet architecture, without inventing >> a new protocol specification and without losing change control. We >> must of course avoid gratuitous changes, but the IAB/IETF must be able >> to make any changes that are necessary for successful deployment, >> operation, and evolution of IPv7. In the longer term, the use of CLNP >> will contribute to the inevitable convergence of the OSI and TCP/IP >> protocol suites in the Internet (IAB/IETF) context. Why is this inevitable and why just two protocols? There are other internet protocol families which have larger installed bases. The word "inevitable" was a poor choice. It reflects our deep desire to end the costly and devisive us/them war in world-wide networking, so we can all get on with the problem; "inevitble" was wishful thinking. The other internet protocol families are proprietary, and therefore they do not appear to be feasible, even if they were desirable, as the basis for universal networking. >> The next section reviews the advantages of this CLNP-based solution. >> Section 3.2.discusses the issues that must be resolved before a CLNP- >> based IPv7 can be deployed in the Internet. >> >> 3.1. The case for (and against) CLNP >> >> An advantage of CLNP is simply that the protocol is already >> specified, and several implementations exist. Adopting (and >> adapting; see the next section) the CLNP format will avoid design >> of a new protocol from scratch, a process that would consume >> valuable time and delay testing and deployment. >> >> Besides the change to variable-length 20 bytes addresses, CLNP has >> another important technical advantage: it frees us from the 60-byte >> limitation on an IP header. CLNP has a limit of 254, and there is >> an escape code (length 255) that could allow an extended header; >> this will allow more extensive use of IP options for future >> extensions. As noted, above I don't think a case has been made why larger space for options is a feature. I don't think this is an advantage. The more the options space is used the harder, the harder it will be to get high forwarding performance in routers. >> We should admit frankly some technical limitations of CLNP, which >> it shares with IPv4: >> >> * Maximum packet length is limited to 64K bytes. >> >> * The message identifier uses a 16-bit field. >> >> * The Time-to-live field is one byte. >> >> * If full-size (20 byte) addresses are used in options, the 255 >> byte limit gets used up fast. For example, the largest source >> route with 20-byte addresses will be 8 hops. This is not very different from the number of hops which can be carried in IP. Am I missing something? It seems to be at odds with the discussion in the previous paragraphs about CLNP's ability to carry more options than IP. Seems like CLNP holds more bytes, but about the same amount of information. We do not expect there to be many (or any??) 20-byte addresses in the real Internet, so this worst case is generally irrelevant. In any case, the statement is that it is not a show-stopper. There is an engineering compromise here, and 254 byte max IP headers seem reasonable to me. >> In addition, CLNP has awkward boundary alignments for RISC- >> architecture machines. We do not regard any of these as show- >> stoppers. The RISC performance issue is not a showstopper, but is an important performance concern. I can't see any way around this except for a very major change to CLNP. I don't disagree. Another concern I have with CLNP is the checksum algorithm used. It is much more expensive to compute in software than the IP checksum. I have even heard that some comments that it is harder to do in hardware. Specifically, I site the decision by Protocol Engines to not include the CLNP checksum in the network chip they have built. Greg Chessins should be able to provide more information. The checksum has been extensively discussed in the last few days. I see no problem in changing it if we need to; the incremental update problem in a router does seem like a potential show-stopper to me. Regarding checksums, I also have a specific concern for hosts because CLNP uses one type of checksum and TCP uses a different checksum. There has been much work done on host performance optimizations which combine the IP and TCP checksum calculations into one optimized loop that also moves the data from kernel space to user space. I have real concern that this type of optimizations will be lost or be made much harder with the proposed architecture. Huh? This seems faintly wierd to me... are you sure they combine the IP and TCP checksums?? Anyway, that could be a factor in decision on what checksum to use. >> 3.2 Additional Issues with CLNP. >> >> To adopt the CNLP format for IPv7, a number of issues must be >> resolved. Callon has provided one analysis of the changes needed >> and the interoperability issues for using CLNP as the basis for >> IPv7 [TUBA]. >> >> * Address Format and Registration Plan >> >> The existing NSAP registration plans [OSI-NSAP], which were >> designed for OSI usage, will have to be reviewed in light of >> the Internet needs. One requirement is to embed the existing >> Internet addresses. Seems likely that we will define our own NSAP address. Few are happy with the provider based NSAP schemes currently proposed. Yes. >> * Protocol Identification >> >> A substitute for the IPv4 "protocol identification" field will >> have to be defined. A plausible solution would be to use the >> "last address byte" (the "NSEL" or "NSAP selector" field, >> which is defined to be the last byte of the NSAP address by >> ANSI standard X3.210-1992). Why not just add this to the CLNP header. What is the affect of carrying the protocol field as part of the address have on existing implementations? Agreed, a possible solution. The IAB did not want to make engineering judgments, except to try to detect show-stoppers before the show started. >> .... >> * Header Size >> >> The possible problems posed by increasing the size of the IP >> header will have to be evaluated. The impact on slow Internet >> links may be alleviated by adapting header compression >> algorithms analogous to Jacobson's [RFC-1144]. How big will the header be? How much of an impact will there be on the existing internet infrastructure? Will lines need to be upgraded? Is this a reasonable solution for mobile hosts using low bandwidth links? This is a very serious issue. WIth variable-length addresses, only as big as it needs to be. Agreed. I expect that header compression can be carried over. >> * Multicasting >> >> The proposed extensions to CLNP for multicasting will have to >> be incorporated. Yes this will have to be done. How long will this take? What is the status of multicasting on CLNP? Every time I talk to Steve Deering he is very pessimistic about the progress of multicasting in CLNP. I checked with Steve, and as noted above, this is a done deal. Multicasting is a service that IP has now. Sun and other vendors have products shipping today which support and use it. It is an important part of Sun's networking strategy. If a new version of IP is adopted, it must have multicasting from the start. >>.... >> It is of course a long-term objective to work towards a single >> unified internet protocol layer for the entire Internet. Why is this a long term objective? I was not aware of a consensus that thought this was true. I thought the objective of this proposed change was to solve the Internet's routing and addressing problems. Well, for one thing it was part of the results of Group 2 at the first IAB architecture retreat, recorded in RFC-1287 and reported to the Atlanta IETF meeting. I don't recall your objecting before. And is it a surprising objective? It seems like Motherhood/Apple Pie (in the sky, it would appear from this week's events!). Do you really take exception to it?? >> In the OSI framework, IS-IS and IDRP are the currently-defined IGP >> and EGP routing protocols, respectively. A careful study may be >> needed to evaluate whether to adopt ISO routing protocols or to >> evolve IP routing protocols to support IPV7. The routing protocols >> currently in use in the Internet represent a huge investment that >> should be thrown away only for compelling reasons. Furthermore, we >> must facilitate further research in routing protocols. >> This will be a very difficult task and be a very major change regardless of what protocols are selected. Not sure what "this" refers to here. >> In order to survive the transition to IPv7, the existing routing >> protocols will have to be upgraded to handle long variable-length >> addresses and masks/prefixes. The careful study of routing >> protocols is an important element in the success of the migration. Changing routing protocol continues to be hard. This proposal is saying that all of the routing protocol in the internet will have to change or have significant modifications. This is a very large impact. The alternative proposals (IPAE and EIP) build on top of the current routing protocols and don't require all of the existing protocols to change. Other work which will have to be done is to define current mappings for running CLNP over all of the current types of networks, that we currently have for IP. This is a significant project and will open up old issues about how best to do it over each type of network. As has been agreed for several years, it is the objective of the IAB/IETF to build a multiprotocol-suite Internet, so the IAB assumed that we are on the road to solving these issues anyway. >>5. THE WAY FORWARD >> >> In order to guarantee the survival of the Internet, work should start >> now on the various items detailed in this document. Delaying by a few >> more months in order to gather more information would be very unlikely >> to help us make a decision, and would encourage people to spend their >> time crafting arguments for why CLNP is or is not a better solution >> than some alternative, rather than working on the detailed >> specification of how CLNP can be used as the basis for IPv7 and >> resolving the technical questions (particularly in the area of address >> administration and the effect on existing application software) that >> must be answered in order to specify a deployment plan for IPv7. On the other hand if we proceed this way, we are likely to start a war. There is no consensus on this approach. I think it would be much preferable to take some time to work out the many issues stated in this document regarding the conversion to CLNP and to examine other approaches. There will be much less fighting if the community feels that there has been a fair hearing of the issues and approaches. Well, it does seem you were right about starting a war. The degree of irrationality that is floating around is quite disconcerting. I have recently seen some personal attacks on the integrity of IAB members that make me quite angry. I regret most that my attempt to explain our ideas was apparently inadequate, because people keep bringing up the same misconceptions. See you next week, Bob From owner-Big-Internet@munnari.oz.au Wed Jul 8 17:17:33 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19084; Wed, 8 Jul 1992 17:17:46 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19080; Wed, 8 Jul 1992 17:17:33 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA01946 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 8 Jul 1992 17:17:29 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA16678; Wed, 8 Jul 92 17:17:29 EST Message-Id: <9207080717.AA16678@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: Multiple addresses In-Reply-To: Your message of "Wed, 08 Jul 92 02:12:57 -0400." <9207080612.AA22916@ginger.lcs.mit.edu> Date: Wed, 08 Jul 92 17:17:28 +1000 From: Bob Smart > In addition to the interoperabilty reason you raised, a number of >people whose technical opinions I respect (e.g. Van Jacobsen) say it's not >optimal to make a packet format change now, but to wait, if possible, until we >know more. I am convinced by what they say; what do other think of this >point? I'd certainly like to hear what Van Jacobsen has to say. Can someone give him a prod. For my money we have to have a new packet format: 1. Otherwise we have a transition during which some packets are meant to be routed on the IP4 address and some are meant to be routed in some other magic way because the IP4 addresses are only IDs. This is a recipe for chaos. And we will have similar chaos if we choose something which is too like CLNP but uses different forwarding/routing. 2. Any proposal which doesn't have the addresses in the packets is a research project. To put new addresses in packets with the current format we'd have to them in options. This will make one of the problems with the current format even worse, apart from having efficiency difficulties. And PIP has shown that you can do a simple packet format that is also very general. If we reject it because somebody _might_ think of something which you can't do with PIP then we'll never be able to make a decision on a new format. Bob Smart From owner-Big-Internet@munnari.oz.au Wed Jul 8 17:35:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19448; Wed, 8 Jul 1992 17:35:56 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207080735.19448@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA19421; Wed, 8 Jul 1992 17:35:44 +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, 8 Jul 1992 08:35:27 +0100 To: mo@gizmo.bellcore.com Cc: big-internet@munnari.oz.au Subject: Re: what headlines.... In-Reply-To: Your message of "Mon, 06 Jul 92 15:58:31 EDT." <9207061958.AA28050@bellcore.bellcore.com> Date: Wed, 08 Jul 92 08:35:23 +0100 From: Jon Crowcroft > "Internet Board to Vote On IP Fix" >" With little warning, the Internet Architecture Board >has decided to change the way the Internet handles addressing, typical - incorrect -they've decided to change the packet format (which doesnt solve the problem) and now on what addressing to use (which would help...) also, in support of my interpretation of the DECNET==IPv7, i quote from the Interop 92 Fall "OSI Internets: Integration of IP and CLNP" tutoiral description (by Richard DesJardins (now where've i heard that name before?:-) "Both the US Government (GOSIP) and Digital Equipment Corp_ have adopted CLNP as therir future internetworking strategy, while both orsgs also have to support large IP..." this is the first time i have heard DENET or GOSIP described as "Internetworking" solutions.... jon From owner-big-internet@munnari.oz.au Wed Jul 8 18:43:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21527; Wed, 8 Jul 1992 18:43:08 +1000 (from owner-big-internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23632; Wed, 8 Jul 1992 01:32:44 +1000 (from dave@sabre.bellcore.com) Return-Path: Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA06317; Tue, 7 Jul 92 11:34:34 EDT Received: by sword.bellcore.com;id 9207071533.AA25995 Message-Id: <9207071533.AA25995@sword.bellcore.com> Date: Tue, 7 Jul 1992 11:34:17 -0500 To: Noel Chiappa From: dave@sabre.bellcore.com Subject: Re: IPv7 (CLNP) a mistake Cc: big-internet@munnari.oz.au, ietf@isi.edu, road@lanl.gov > However, we aren't binding ourselves (for reasons of abilty to meet >requirements) to keeping that protocol exactly the same. To me, this sounds >like we have just voided the best argument for switching to a second protocol, >which is the interoperability issue. Surely, if the Internet CLNP is >functionally different in a useful way, it won't be interoperable, right? Well, Noel, I disagree with most of your assessment. I truly believe that with CLNP, you can have your cake (change control) and eat it (maximize interoperability). I wish I could say it was designed that way, but I'll be happy to treat eat as a pleasant mistake. I interpret "change control" within the IETF as follows: we have a protocol that looks like CLNP, smells like CLNP, waddles over LANs and WANs like CLNP, but is called IPv7, and the documentation is in RFC form, available electronically, and changes are introduced through the process outlined in RFC 1310. It would be nice if every change we introduce is enthusiastically accepted by ISO, but not necessary. First, let's look at the options. Suppose the IETF wants to add an option and ISO don't:-( (maybe PROTO, maybe something else, maybe a preferred way of encoding an option over one ISO had used in CLNP). My vague and limited recollection of CLNP reminds me that CLNP options fall into three categories: 1- you gotta implement it or you die 2- you don't have to implement it, but if you don't and you receive it, you gotta discard the packet 3- you don't have to implement it, and if you receive it, be rude: ignore it, and process the packet as if it weren't there Since options are Header Item encoded, the extent of the agreement one needs from ISO is that they reserve some of the 2**6-1 values for IETF use, and that they treat options with header item values in this range as type 3's. Second, let's look at introducing efficiency. Folks claim that variable length headers are bad; we can fix the length of the CLNP address fields to the maximum length of IPv7 addresses, so for headers that don't carry variable length options, we've made processing predictable. And note that, absent the addressing info & options, the CLNP packet overhead is only 15 bytes. Now that nasty checksum. Evidence that the OSI TP/CLNP checksum is slow and misplaced is growing, and I see an opportunity here for us to correct a bad judgement. I'll also mention that there is a note in the ISO Transport Protocol spec that seems to imply that not everyone who worked on the checksum was happy with it: it suggests that a different checksum is an item for further study. In my mind, field experience falls into the category of further study:-) I think there is a real good chance to fix this. > In fact, the cost would be less, since we wouldn't have to make some >of the major changes to our protcol suite that a switch to a new network layer >would entail (e.g. phasing in ES-IS, etc, etc). this is a big assumption, don't you think? maybe I'm dense (yes, I borrowed this from your email to me earlier) but it seems to me that the impact here depends on what sort of addressing we come up with. I also think that there are lots of assumptions being made about the composition of the glorious ultimate NSAPA for IPv7; I haven't seen a concrete proposal that suggests we use RFC 1237 for IPv7, the TUBA proposal only suggests that we use NSAPAs--I see room to improve here, if necessary. > If we are going to modify an existing protocol to get what we need >(and I don't agree we should be doing this at the moment), why switch to a >totally different one to do it? probably for all the reasons you don't think carry weight: - compatibility/interoperability--maybe a platitude for you, but from an operational standpoint, I imagine there is some sympathy for having to train staff to operate one protocol for an otherwise multi-stack environment - NM instrumentation exists within the SNMP for CLNP (MIBs); none exist for a totally new protocol - midlevels, backbone, and stub networks have experience with CLNP--certainly not as much as IP, but more than a totally new protocol > I'm also less sanguine than you are about the ability to get the ISO >world to track changes made here. Standards bodies *all* (including the IETF, >I willingly admit) seem to have a bad case of N.I.H. I mean, look at IEEE; >they just *couldn't* resist dinkering with Ethernet, a widely deployed and >very sucessful standard. history repeats...history repeats...history repeats... maybe it doesn't have to. Lyman's point that the very same CLNPeople attend the IETF, ANSI, and ISO meetings should not be dismissed too easily. Dave Oran, Ross Callon, Radia Perlman and Paul Tsuchiya can attest more accurately than I to how amenable the "other" OSI folks have become to improving the CLNP "stack"; it sounds like they enjoy talking about link state packets, I appear to have left too soon (of course, I get to do *this* now:-) > I *still* think the best interim path is to put off the adoption of a >new packet layer as long as we possibly can, have you any idea how long is long? what risk do we run that CIDR will forestall collapse for that timeframe? --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) From owner-big-internet@munnari.oz.au Wed Jul 8 19:07:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22259; Wed, 8 Jul 1992 19:07:49 +1000 (from owner-big-internet) Return-Path: Received: from ppp.dbc.mtview.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28101; Wed, 8 Jul 1992 05:15:08 +1000 (from mrose@dbc.mtview.ca.us) Received: from localhost (localhost.ARPA) by dbc.mtview.ca.us (4.1/3.1.090690) id AA27476; Tue, 7 Jul 92 12:13:04 PDT To: lyman@bbn.com ("Lyman Chapin") Cc: big-internet@munnari.oz.au, iab@venera.isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov Reply-To: big-internets@munnari.oz.au Subject: Re: IAB proposal for CIDR and IPv7 In-Reply-To: Your message of "Wed, 01 Jul 1992 19:08:10 EDT." <9207012354.20234@munnari.oz.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 07 Jul 1992 12:12:57 -0700 Message-Id: <27466.710536377@dbc.mtview.ca.us> From: Marshall Rose [I've tried to make this note as concise as possible. Still, it's long. But, read it, you'll enjoy it--unless you're an IAB member!] I must say that I am not happy with this "decision", as it fails on both technical and political grounds. Technical: The discussion on the big-internets list demonstrates a consensus that moving to IPv7 solves at most one problem: more address space. It is less clear that IPv7 will be able to achieve route-aggregation without significant administrative overhead and/or total deployment. Unfortunately, IPv7 introduces a whole family of problems as the CLNS is not as mature as the IP layer, e.g., no multicasting; nor is CLNS integrated into the protocol suite (so we'd have to change a lot of other protocols to make use of it). So, the IPv7 "decision" manages to solve one problem, creates several others by requiring a massive change to the entire infrastructure, and doesn't solve any long-term issues (e.g., "Buck Rogers" routing.) However, the amazing part of this "decision" is the technical vacuum in which it was made. Key to understanding the notion of transition and coexistence is the idea that any scheme has associated with it a cost-distribution. That is, some parts of the system are going to be affected more than other parts. Sometimes there will be a lot of changes; sometimes a few. Sometimes the changes will be spread out; sometimes they will be concentrated. In order to compare transition schemes, you *must* compare their respective cost-distribution and then balance that against their benefits. That is, you can't just compare schemes on the basis of "where they will take you", you must also compare them on the basis of "what they will cost you and where". The IPv7 "decision" and associated Internet-draft do not contain such an analysis. Instead, they say something which could be paraphrased as: "we *will* do IPv7, we will ignore any other proposal, and all we need to do now is to figure out a way to make IPv7 work" The most polite term I can use for this behavior is irresponsible. Discounting other schemes without doing the cost-distribution/benefit analysis is tantamount to an oblique political decision. And yet, this is precisely the course taken by the IPv7 "decision" and Internet-draft. Political: IPv7 is either an ISO-standard protocol, or it's not an ISO-standard protocol. The argument about "being able to have our cake and eat it too" is specious. If you run CLNP, then you have bought into the ISO process. If not, then it isn't CLNP any more. How long before we overhear a conversation like this: "What do you mean your CLNP router/host doesn't do that version of CLNP? What do you mean there are two versions of CLNP and I just bought a router/host that does the wrong one?" Talk about skewering the users! Further, the choice of IPv7 will result in a massive injection of fear, uncertainty, and doubt in the marketplace. You have now opened the door to all kinds of marketing hype about "the Internet moving entirely to OSI". Whilst parts of OSI might have benefits in a multi-cultural internet, the likelihood of FTAM, VT, CMIP, or even MHS adoption in the Internet community is largely a pipe-dream. (And despite Hardcastle-Kille talking about "an increasing acceptance of (X.500)", I will note that Internet X.500 growth is largely linear, whilst the growth of WAIS, archie, etc., is exponential.) Still, the the choice of IPv7 has opened the door to the non-sensical argument of "leapfrog TCP/IP by going directly to OSI". This will probably set back the market by about five years. Although I might imagine that certain vendor influences on the IAB might relish the thought of this, I think we can all agree that it would be bad for the Internet community as a whole. The point here is an important one: actions, regardless of their intentions, have side-effects. The IPv7 choice, regardless of its technical merit, is going to stunt growth in the Internet community. Now the rather obvious hidden-agenda of the IAB in this matter is that they view this as an opportunity to harmonize the Internet and OSI protocol suites. Unfortunately, it appears that their zeal in taking advantage of this "opportunity" has blinded them to the severe negative impacts of IPv7. A Solution: I can think of two solutions. First, I suggest that the IAB figure out a way of saving face and retracting their "decision". Something along the lines of: "oh, you took us seriously. goodness no! we were just trying to show people the option of last resort (IPv7) unless we got our act together (e.g., started deploying IPAE)." Now, the IAB has a long and proud tradition of making silly decisions and then retracting them. From the network management arena, the CMOT and Ethernet MIB examples come to mind. So, perhaps they will figure out that they made a wrong move and perhaps they will decide to eat crow once again. If not, I feel that the Internet community has no option but to declare the IAB as having "historical" status. In voluntary systems such as ours, there is a fundamental concept of "the right-to-rule" which is perhaps better known as "the consent of the governed". Certainly the original IAB membership had a bona fide right-to-rule when it was composed of the senior researchers who designed and implemented a lot of the stuff that was used. Over time however, the IAB has degenerated under vendor and standardization influences. Now, under ISO(silent)C auspices, the IAB gets to hob-nob around the globe, drinking to the health of Political Correctness of International networking and poo-poo'ing its US-centric roots. I'm sorry, but I'm just not buying this. The Internet community is far too important to my professional and personal life for me to allow it to be sacrificed in the name of progress. So, do we really need the IAB? Of course not! With the exception of the RFC-editor (whose work is of direct benefit to the community), I will observe that the rest of the IAB membership lost its right-to-rule long ago. Let's face it: in general, these guys do little design, they don't code, they don't deploy, they don't deal with users, etc., etc., etc. Sure, there may be a couple of exceptions, but those are the exceptions, not the rule. If I were feeling particularly nasty, I would further observe that we've been humoring the IAB for quite some time now. The problem is, their latest fiasco is far too destructive to be funny. So, my second solution is this: we wait until the Boston meeting of the IETF. If the IAB retracts, we start working like demons using the IESG recommendations as a roadmap. If not, I suggest we start a grass roots effort to devise a small, stream-lined "Internet Technology Board" (pick your own name), which would maintain a document series of "good" technology, and be responsible to "the consent of the governed". It seems to me that we would could collapse the two-tier IAB/IESG structure into the ITB. Of course, fundamental to such a revolution would be the notion that we start paying more attention to "product". (At present, the IESG appears to care far more about "process" rather than "product"--we need to reverse that trend.) /mtr From owner-big-internet@munnari.oz.au Wed Jul 8 19:24:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22697; Wed, 8 Jul 1992 19:24: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 AA10013; Wed, 8 Jul 1992 11:52:39 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA26636; Tue, 7 Jul 92 18:51:59 -0700 Date: Tue, 7 Jul 92 19:59:47 EDT From: "William Allen Simpson" Message-Id: <533.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: CLNP/IP7 over PPP > From: Dave Oran > > The problem is, his proposal depends on address negotiation using an > > ES-IS exchange, which is not yet completed by ISO. > Could you fill me in on what this is about? I know you want to > run ESIS on PPP so you can tell a host-host link from a host-router > link from a router-router link. This is something I believe is > statically configured in the IP world today, so using ESIS actually > may give you more functionality. > Goodness gracious, we don't want to run ES-IS as a separate protocol on PPP! Whatever for? For PPP, we don't need to know what kind of link it is. And quite frankly, I've never had to tell an IP system that something was a host-host, host-router, etc, link for any reason. The current draft expects that OSI protocols are transparent to the link, and interact only with themselves. > On the other hand, I don't get the business about > address negotiation. Are you talking about using the ISO dynamic > address assignment scheme on ESIS with PPP to assign addresses > to dial-in hosts? Yes, we are talking about dynamic address assignment. > If so that is more than today's PPP/IP implementations > do. You are sadly misinformed. Dynamic address assignment was one of the original PPP design requirements, and every IP/PPP implementation I know of has it, except cisco (who haven't really finished theirs, but they shipped anyway.) > It is true, however, that the ESIS enhancements for dynamic address > assignment have not passed their final approval yet. They are between > initial and final ballot, about the same stage a draft internet > standard is in the IETF process. > For CLNP, it was proposed (several years ago) that we use an ES-IS mechanism for dynamic OSI address assignment, which was termed "future research". We have been waiting, and waiting, and waiting .... As far as I know, no CLNP/PPP implementation has it yet, initial ballot or final ballot notwithstanding. > >This was fine when > > the implementation was already committed to ISO, but is not good if it > > becomes a universal IP requirement. > > > I don't follow your argument here. Why? > If my box is running IP4 and Appletalk, but not IS-IS or any other ISO protocol, and I want to implement just CLNP headers for IP7, I don't want to have ES-IS, too. I already have equivalent mechanisms. The IAB draft clearly says: It is important to understand that (3) above does NOT mean "adopting OSI" or "migrating to OSI" or "converting the Internet to use GOSIP protocols". This means we don't need to implement ES-IS to have IP7. If we do, the IAB is incorrect. > > 1) this is another area that the OSI standard isn't sufficiently > > complete to migrate from IP to CLNP. > Again, I must be missing something here. Why? > You say "They are between initial and final ballot, about the same stage a draft internet standard is in the IETF process." What you should have said is "about the same stage as an _internet-draft_ is in the IETF process." As I said above, not yet implemented. > > 2) this means that all PPP IP links will need to implement ES-IS, even > > if they don't adopt other parts of ISO. > This is true only if you want to use the autoconfiguration ESIS gives > you. You could settle for all of the manual configuration you have > to do for IP in the absence of DHCP, Router Discovery, etc., but > ESIS is the protocol you run to get those things. It seems just as > logical to use ESIS on PPP as it would to run DHCP and router discovery. What manual configuration for IP/PPP? As I said above, autoconfiguration is one big reason for PPP. > Are there PPP mappings for those protocols as RFCs? > Yes. And implementations for Appletalk, IPX, DECnet, etc, without published RFCs. Silly us, to implement first. ---- BTW, I'm the person who kept OSI/PPP alive, even after the original author had given up. I think OSI/PPP may be useful someday. We just couldn't get anyone to implement until recently. B-u-t, anyone who says we can go to CLNP for IP7 -- without adopting the whole ball of wax -- is trying to sell us a bill of goods. That is the real point of this exercise. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Wed Jul 8 19:25:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22728; Wed, 8 Jul 1992 19:25:29 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207080925.22728@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22725; Wed, 8 Jul 1992 19:25:23 +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 ; Wed, 8 Jul 1992 10:24:54 +0100 To: braden@ISI.EDU Cc: big-internet@munnari.oz.au Subject: Re: Comments on IPv7 Document In-Reply-To: Your message of "Tue, 07 Jul 92 16:01:50 PDT." <199207072301.AA06141@braden.isi.edu> Date: Wed, 08 Jul 92 10:24:53 +0100 From: Zheng Wang > Why is it "vital" to escape the 60-byte limit on IP options? There is > a significant body of experience that says the options are a bad idea > in the first place. This is the first time I have seen this argument > that we should have room for more options. > >"Bad idea" seems a bit strong. They are an architectural technique for >relatively painless extensions; I am not aware of an alternative, but this >may just be my ignorance (I would be happy to be wrong here, and if there >*is* an alternative, it could certainly affect my own conclusions). If the header is really long (complex policy routes, lots of options), it may be more appropriate to set up a virtual circuit, ie. storing the states in routers/hosts rather than carrying them in packets. Cheers Zheng From owner-big-internet@munnari.oz.au Wed Jul 8 19:31:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22865; Wed, 8 Jul 1992 19:31: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 AA17185; Wed, 8 Jul 1992 16:13:22 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22916; Wed, 8 Jul 92 02:12:57 -0400 Date: Wed, 8 Jul 92 02:12:57 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207080612.AA22916@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: Multiple addresses Cc: jnc@ginger.lcs.mit.edu Noel's image of an address formed by non-overlapping nested circles means that you get one address per interface Ah, multiple addresses. Much cogitation under the bridge on that one.... It turns out that while I used to think that each interface would *probably* only have one address, I'm going that way less nowadays; I think Nimrod may want to allow multiple addresses for an interface. (It's certainly easier to think about the whole system if you don't have the overlaps, and maybe easier to implement, but let's not wander off in that direction.) Let me talk a bit about all the different fun things I can see doing with multiple addresses. The thing that tipped me over the edge was this issue I raised of the address heirarchy being isomorphic to the topology, so that if you want to keep that sum of costs fuction near a minimum you made need to change addresses over time as the topology changes, probably semi-automatically so the human cost is minimized Clearly this will be much easier (i.e. only possible :-) if an interface can have two addresses for a while; you phase the new one in, and then the old one out. Martha also has an interesting argument which says (as I understand it) that a particular abstraction heirarchy might be sufficiently non-optimal for certain kinds of policy routing (because of thinning decisions which have raised the cost of the resultant non-optimal routing for that traffic class) that it might be a lower overall sum of costs to maintain a separate addressing heirarchy (at extra cost) to get much better routing. Seems fairly wild to me, but hey, it's possible. (It's another optimization the worth of which is hard to gauge from general principles.) Now we get to those two perennial favourites, policy routing, and providing optimal entry choice with multiple provider attachments. The effect of having only one address is that to describe different ways to get to that interface you have to give a loose source route Well, sort of. If you've only got one address, policy routing demands that you be able to affect the routing in some other way. Source routes are good (maximum flexibility), but policy terms in the packet will work (expensive on long connections, though). That is probably why Noel is concerned about having source chosen addresses in each packet. Noel didn't quite grok this. I think this is one use of multiple addresses that I am dubious about. First, if you are doing policy routing with source routing and a map, (which is the most general and flexible way), this is unneeded. That's where I sit on this one. If you are doing hop-by-hop, what this amounts to is a *possible* optimization of the packet forwarding process. If you think about IDRP (or better yet the non-LS part of Unified), it maintains a number of routing tables, ones for each major defined policy class. If you had a policy indicator in the packet, you could think of that indicator as an extension to the address which selects which table to use. Now, think about the multiple addresses version; you have basically munged all the separate routing tables together, and don't need the seletor. Now, depending on how you've implemented your router, this may or may not be a slight efficiency improvement. Somehow, though, those munged routing tables bother me (not that I like routing tables at all, anyway.. :-). Keeping them separate make me feel better (not .... anyway.. :-). The alternative system of provider oriented heirarchical addresses... To me it seems that this gives information in a very convenient form to the source that has to choose the way the packet should go. Now, this one is interesting. (It's mentioned as a possible optimization in Nimrod 6.3; I used to be dubious about it but now I have to think about it.) Basically what you are doing is trying to allow people to optimize the path to you, and not tie you down to being accessed through a single service provider if you have multiple service connections, and for aggregation goals don't want to appear as a top-level entity of your own to which people can route directly. The advantage of doing that optimization this way is that when people do the name lookup, the discover then and there that there are potential different paths to you. It's less work than either route suffixes or topology probing. I don't have any clear thoughts on the best way to do this optimization (I'm starting to fade); it may well be that if we have the capability of multiple addresses and overlapping areas in Nimrod, this is the best way to do this one. Still, I haven't thought it through, and it is an optimization.... The only current proposal that looks likely to do that (allow existing host software/hardware to work unchanged) is Noel's proposal to separate address from ID and use the IP4 address as the ID initially. This ... allows a dense use of the 32 bit space. Thanks for the plug for Nimrod! Many people seeem to be taking the path "we need larger addresses" -> "we need a new packet format now", but I don't buy the inference. Yes, we need the former, but it doesn't necessarily lead to the latter. Reinterpreting the 32 bit field as an identifier and adding new addresses on 'somewhere else', even if you don't buy the Nimrod flow stuff, looks like the best bet to me. In addition to the interoperabilty reason you raised, a number of people whose technical opinions I respect (e.g. Van Jacobsen) say it's not optimal to make a packet format change now, but to wait, if possible, until we know more. I am convinced by what they say; what do other think of this point? Noel From owner-big-internet@munnari.oz.au Wed Jul 8 19:32:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22892; Wed, 8 Jul 1992 19:32:46 +1000 (from owner-big-internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12489; Wed, 8 Jul 1992 13:26:54 +1000 (from dkatz@cisco.com) Received: by cider.cisco.com; Tue, 7 Jul 92 20:26:28 -0700 Date: Tue, 7 Jul 92 20:26:28 -0700 From: Dave Katz Message-Id: <9207080326.AA19702@cider.cisco.com> To: bsimpson@angband.stanford.edu Cc: big-internet@munnari.oz.au, ietf-ppp@ucdavis.edu In-Reply-To: "William Allen Simpson"'s message of Tue, 7 Jul 92 18:58:44 EDT <530.bsimpson@angband.stanford.edu> Subject: CLNP/IP7 over PPP Well, the choices would seem to be: (1) Invent a new protocol (2) Extend existing protocols to handle NSAP addresses (probably the same as (1)) (3) Use ES-IS as is If I were an implementor, which of these three approaches would appear to give the most return? Of the three of these, which is most likely to already have been done? The problem is that the IAB messages assured us that NO OTHER PART of the OSI suite would need to be implemented. We were asked to identify places where this was not so. I have just identified one. It's not the case that it's necessary to use ES-IS, it's just smart. The fact that the letters "OSI" appear to be anathema to you doesn't make the reinvention of yet another wheel a good idea. But how many IP installations have already implemented ES-IS? And how will this interact with the other Internet Suite protocols that duplicate those functions? Every IP system has to run both in parallel for ages to come. ES-IS is available in BSD Reno for those who don't have the patience to do it themselves. How many of these installations have implemented CLNP/IPv7? Those that have CLNP already have ES-IS. Those that don't have IPv7 will have to implement it, and while they're in there they'll have to implement *something* for address resolution and all that stuff. May as well be something they can use for other things. There are many systems out there that are already dual, and they're working just fine. Since I don't have the slightest idea what ES-IS looks like, I can't make any judgement call. I just have to raise the issues so that I can get the answers from others. Perhaps you should take a look at it. I'm sure that there are a number of helpful people in your neck of the woods that could give you a hand. You and I both know a number of nice folks in large midwestern university towns. In particular, this is a problem for the PPP working group. Since we may be required to support CLNP/IP7 without ES-IS, we may have to add more configuration options to OSI over PPP, a document that we thought was finished. The document as it exists should go forward as it is. If in fact somebody is crazy enough to "require" supporting CLNP without ES-IS, then the issue can be revisited. Certainly more options can be added after the fact. This is a non-problem--there would seem to me to be nothing unique to PPP in this situation. As an alternative, we may need to send IP7 packets as a completely separate protocol flavor from CLNP. This abrogates some of the claimed advantages for CLNP/IP7. If it looks, wags, barks, and rolls in smelly stuff like CLNP, it would seem to be the height of silliness to make technical changes to support the illusion that it is something else. From owner-big-internet@munnari.oz.au Wed Jul 8 20:02:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23669; Wed, 8 Jul 1992 20:02: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 AA15359; Wed, 8 Jul 1992 15:25:51 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22705; Wed, 8 Jul 92 01:25:43 -0400 Date: Wed, 8 Jul 92 01:25:43 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207080525.AA22705@ginger.lcs.mit.edu> To: deering@parc.xerox.com, jnc@ginger.lcs.mit.edu Subject: Re: Mobile Hosts and IDs Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu ... a good analog in the area of computer architecture: virtual memory. In VM, the same address space is used for virtual addresses (to name objects) and for real addresses (to name locations). Umm, that's not quite the way I'd analyse this particular example, but I see what you are getting at. I don't think that VM was ever considered a kludge, and I certainly don't put it in that class. It's an interesting argument. Why is it that my Exupery meter is giving me different readings on the two cases? Hmmm... (*very* long pause) When you map from virtual memory addresses to real addresses, you are creating multiple virtual replications of a single original. Also, you are creating a virtual resource which an idealized abstraction, constructed out of a mix of economically available real-world parts (i.e. a large VM out of some real memory and a big disk). Other benefits, such as memory allocation simplicity, are usually seen as ancillary. (E.g. segment relocation came mostly before paging, as I recall, but there was a machine at Manchester...) Anyway, these goals (and very powerful goals they are, too) basically mandate the mapping from one instance of a namespace to another instance of the same kind of names. Now, when I think about the example of the network addresses, I'm a little harder put to see what major uses we have for this mapping from virtual to real network addresses (other than doing mobile hosts). I mean, sure I can come up with some, but I feel like I've got a hammer and am looking for nails! I'm not coming this way because of some powerful goals, which can be met in no other reasonable way, such as exist in the VM example. In addition, considering the alternatives (of which more below), I wonder if the best system coherence happens from having the source (or something near it, such as the routing agent or first hop router) be notified of the new real address. I mean, this conversion has to happen sooner or later; why not sooner? One good reason to do it later is it keeps the knowledge of where the host has gone in one place, rather than spreading it through the net; the disadvantage is it may cause the traffic to be taking non-optimal routes. This is an optimization tradeoff question which it is hard to answer without experience; it's usually not possible to answer this kind of thing from basic principles. It depends on things like 'how easy is it to change mappings', etc. Don't you think the necessity of having to work within the existing architecture had a big role to play in the design choices of the Sony system? I really think that the system will benefit from having a way of naming these things I call endpoints; fate-sharing regions (in the original TCP/IP definition, where all the state critical to a TCP connection was co-located with the application using the connection, so that "they all went together when they went"), or end-end regions (i.e. the entities between which the end-end mechanisms work). I admit it's hard to create a rigorous proof as to why this is a good idea, but I'm sure it is. I think that any time you have a fundamental class of object (i.e. endpoints) it is good design to have a namespace for them. If pressed, I will contemplate on this for a while and see what extra arguments I can come up with. What is clear to me is that once you have this extra namespace, you can do many things with it. Mobile hosts are just one; others include such things as: - handling multi-homed hosts (either for reliability or throughput); whichever interface the packet came in on, it's to the same entity - supporting multiple machines which share an interface, such as some multi-processors - allowing mobile processes Yes, you can probably do all these things with address mapping, but it's almost like you are creating two different kinds of addresses, 'real addresses' and 'virtual non-addresses' which happen to share the same syntax. Given two uses which are substantially different, it might make sense to come up with separate namespaces, with the syntax of each tuned to their use. What routing wants to see in an address is very different from what endpoint identifications wants to ses. Also, the real memory locations that you are mapping into are fungible; i.e. you can't tell, and don't care, which particular cell you have been mapped to. This is obviously not completely the case with real network addresses. (E.g. try doing a policy route to a virtual address where you have characteristics you care about which you can't pass on to a forwarder at the hosts's home location; you really need to know what the physical address is.) This is not a direct response to your point, but is another way in which the analogy is not a 100% fit. I do wish you would try to be a little less dogmatic. Other people's judgement of "good system engineering practice" may reasonably differ from yours. Ahh, I admit I have a (sometime unfortunate :-) weakness for a well-turned phrase, the rhetorical flourish. I apologise for any offense in this case; I was simply trying to state my opinions crisply, not trying to needle anyone. I guess that I had assumed that people would understand from context that an opinion was being stated; Computer Science has not yet codified Good Engineering Practise to "safety margin of 2", or anything so quantized. Plus to which I admit to having a somewhat idiosyncratic set of GEP's, to which I adhere with Fundamentalist (pick your religion) levels of comittment. I have found that this serves me well, but I admit it's not susceptible to logical proof. Noel From owner-Big-Internet@munnari.oz.au Thu Jul 9 00:16:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28730; Thu, 9 Jul 1992 00:16:14 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28727; Thu, 9 Jul 1992 00:16:08 +1000 (from dave@sabre.bellcore.com) Return-Path: Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA11452; Wed, 8 Jul 92 10:19:05 EDT Received: by sword.bellcore.com;id 9207081417.AA07987 Message-Id: <9207081417.AA07987@sword.bellcore.com> Date: Wed, 8 Jul 1992 10:18:59 -0500 To: wheeler@jeckle.mitre.org From: dave@sabre.bellcore.com Subject: Re: IPv7 == CLNP or CLNP+ ? Cc: big-internet@munnari.oz.au > >> Given this deployed base, won't that make it that much harder to get >> non-interoperable modifications to the basic CLNP through the ISO? Is the ISO >> really going to be willing to obsolete the substantial investment made by all >> the vendors and users who have taken the path the ISO laid out? > >It sure will be. Just look at '88 X.400 vs. '84 X.400. Brien, can you seriously believe that changes as extensive as 84-to-88 would be introduced to CLNP? In X.400, the entire UL architecture was revised, and the MHS architecture as well. --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) From owner-Big-Internet@munnari.oz.au Thu Jul 9 00:41:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29186; Thu, 9 Jul 1992 00:41:10 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207081441.29186@munnari.oz.au> Received: from vnet.ibm.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29183; Thu, 9 Jul 1992 00:41:06 +1000 (from suelin@vnet.ibm.com) Received: from RHQVM21 by vnet.ibm.com (IBM VM SMTP V2R2) with BSMTP id 8064; Wed, 08 Jul 92 10:40:30 EDT Date: Wed, 8 Jul 92 10:39:31 EDT From: "Susan A. Lin" To: big-internet@munnari.oz.au Subject: Subsribe Please include me in your mailing list. Thank you. Susan Lin From owner-Big-Internet@munnari.oz.au Thu Jul 9 01:31:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00343; Thu, 9 Jul 1992 01:31:40 +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 AA00333; Thu, 9 Jul 1992 01:31:31 +1000 (from fbaker@acc.com) Received: by saffron.acc.com (4.1/SMI-4.1) id AA07334; Wed, 8 Jul 92 08:30:55 PDT Date: Wed, 8 Jul 92 08:30:55 PDT From: fbaker@acc.com (Fred Baker) Message-Id: <9207081530.AA07334@saffron.acc.com> To: bsimpson@angband.stanford.edu Subject: Re: CLNP/IP7 over PPP Cc: big-internet@munnari.oz.au, ietf-ppp@ucdavis.edu >> The problem is that the IAB messages assured us that NO OTHER PART >> of the OSI suite would need to be implemented. We were asked to >> identify places where this was not so. I have just identified one. Bill: Anyone who is actually implementing CL/OSI understands that you need CLNS and ES-IS, plus an SNDCF for each supported interface type; for routers, add IS-IS and eventually IDRP; for ISO end stations, add TP4 and more. The IPv7 proposal, as I understand it, leaves CLNS and the SNDCFs (which include ES-IS) intact. We might change the checksum definition, add an option, or construct a new NSAP format, but any fundamental change to CLNS or its convergence layers would have to be stoutly defended. Protocols upstack will be quite familiar. Interface types that ISO didn't think up (Frame Relay, PPP, ...) will be supported. But CLNS and its convergence layers remain essentially intact. I think it's completely fair for them to say that they are not requiring anything that the ISO architecture doesn't already require you to add, and at the same time to assume that we will implement the specified architecture. Fred From owner-Big-Internet@munnari.oz.au Thu Jul 9 02:33:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01708; Thu, 9 Jul 1992 02:34: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 AA01681; Thu, 9 Jul 1992 02:33:36 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA26514; Wed, 8 Jul 92 12:33:24 -0400 Date: Wed, 8 Jul 92 12:33:24 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207081633.AA26514@ginger.lcs.mit.edu> To: bsimpson@angband.stanford.edu, fbaker@acc.com Subject: Re: CLNP/IP7 over PPP Cc: big-internet@munnari.oz.au, ietf-ppp@ucdavis.edu, jnc@ginger.lcs.mit.edu If we're going to have a discussion about potential difficulties with IP7, that's fine, but let's keep it on Big-I. Since it is not yet clear that IP-7 is going to happen, in the way the IAB posited in its draft, let's keep it off the PPP list, OK, which I'd prefer if it concentrated on documents it is working on? Not trying to stifle discussion, just tired of getting multiple copies of things! Noel From owner-Big-Internet@munnari.oz.au Thu Jul 9 05:39:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07518; Thu, 9 Jul 1992 05:39: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 AA07514; Thu, 9 Jul 1992 05:39:14 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws07.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA27521; Wed, 8 Jul 92 12:38:39 -0700 Date: Wed, 8 Jul 92 15:30:22 EDT From: "William Allen Simpson" Message-Id: <540.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Cc: ietf-ppp@ucdavis.edu Reply-To: bsimpson@angband.stanford.edu Subject: Re: CLNP/IP7 over PPP > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > If we're going to have a discussion about potential difficulties with > IP7, that's fine, but let's keep it on Big-I. Actually, I think this issue is completely plumbed. Fred's and Dave's comments cover everything I was asking. > Since it is not yet clear that IP-7 is going to happen, in the way > the IAB posited in its draft, let's keep it off the PPP list, OK, which > I'd prefer if it concentrated on documents it is working on? PPP just asked for "last call" on OSI/PPP a couple of weeks ago. I think the plan should be "we'll add it later if we have to", and go ahead with OSI/PPP as drafted. > Not trying to stifle discussion, just tired of getting multiple > copies of things! > me, too. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Thu Jul 9 11:10:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16991; Thu, 9 Jul 1992 11:10:23 +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 AA16986; Thu, 9 Jul 1992 11:10:10 +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 AB21177; Wed, 8 Jul 92 18:10:01 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA00865; Wed, 8 Jul 92 18:10:05 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA07609; Wed, 8 Jul 92 18:09:36 PDT Date: Wed, 8 Jul 92 18:09:36 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9207090109.AA07609@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA15876; Wed, 8 Jul 92 18:09:49 PDT To: braden@ISI.EDU Cc: Bob.Hinden@Eng.Sun.COM, big-internet@munnari.oz.au In-Reply-To: <199207072301.AA06141@braden.isi.edu> Subject: Re: Comments on IPv7 Document Bob, Thanks for your response. I will comment on your comments. Bob ********************************************************* > I see no justification is this document for why a new version of IP is > "required" to solve the address space consumption and routing table > explosion problems. > > "Required" here was intended to be interpreted in the light of the > requirements set out in Section 2. In particular, it seemed to us that > the requirements of architectural simplicity and global uniqueness > force one to abandon an encapsulation solution like IPAE, and to change > the IP header in order to maintain the present flat forwarding > structure of the Internet architecture. I feel inclined to hold out for > this architectural principle, regardless of whether or not IPv7 is > based on CLNP. > > More on this below. Given the opportunity to start over I agree that architectural principles are important goals. However, I think we have a very large and growing installed base. The issue of how much impact a change to the system has to the operational base needs to take precedence over some architectural principles. I also don't agree that solutions like IPAE violate the architectural principles specified in the CLNP proposal [though if I had written that document I might have picked different principles :-) ] I think it builds on what IP currently does. IPAE does introduce the notion of commonwealths and allows the hosts to select the commonwealth router to send its traffic to. I think this may have some very positive attributes like allowing a host to choose its service provider. This is a capability that we do not have now in the internet that I think we need. So, one can see this as violating an architectural principal or it can be viewed as introducing a new capability into the internet. > A new version of IP is one approach, but I don't > see why it is required. IPAE and similar approaches present clear > alternatives to deploying a new version of IP with much less impact on > the existing operational system. Further, no solution to the routing > table explosion problem is presented here at all as far as I can tell. > > In our discussion, we clearly identified IPAE as a technically credible > approach, and we recognized its low operational impact. However, as I > noted above, we felt that continuing homogeneity of forwarding was a > principle we did not want to give up. I suggest that there are lots of > hidden costs implicit in introducing the new level of structure > implied by Commonwealths. There are certainly hidden costs in both approaches (CLNP and IPAE). It is important that these costs be examined in sufficient detail that the internet community can make a cost/benefit decision. > I think it is important to also say that the first problem is going to > hit much sooner than the second problem. > > I have not really followed these issues, but I think I have seen claims > for the primacy of each. However, it was the intent of the IAB proposal > to address both. We saw IPv7 deployment as a natural followon to > CIDR deployment, with the address aggregation machinery of CIDR > carrying over fairly directly to IPv7. I have not heard anyone say that we will run out of addresses before the routing breaks. I don't see how the CLNP proposal addresses the Routing Explosion problem. > If we only concentrate on the > second problem, the first will kill us! I think a major weakness of > this proposal is that it only addresses the address space consumption > problem. No solution is presented to the Routing explosion problem. > > >From my understanding of the TCP/UDP over CLNP proposal (Simple CLNP > and TUBA), there will not be any significant relief to this problem > until there is very widespread deployment of CLNP in hosts. CIDR does > > The IAB discussion suggested that CIDR and IPv7 will use the same > mechanism for limiting the growth of routing tables: route aggregation > resulting from hierarchical address assignment. The bottom line is > that this is the only mechanism we know of, which we believe can be > deployed without a lot more research. In both cases, the hard and > critical problem seems to be designing the administrative mechanisms > for address assignment. We observed that address assignment becomes > somewhat easier if you are released from the 32-bit limit; hence, this > would be an important reason to drive towards IPv7. And we were > painfully aware of the risks and unknowns in this area; but we could > see no acceptable alternative that moves in (what we thought is) the > right direction in the long term. I agree that having larger addresses make it easier to solve the routing problem. The problem I see with the CLNP proposal is that we can't take advantage of this capability in CLNP until CLNP has a very widespread deployment in the internet. I don't see how this can be done before the current internet routing breaks. CIDR alone doesn't buy enough time. > not buy us enough time. Given the number of significant issues > discussed in section 3 regarding a CLNP deployment that need to be > resolved before CLNP can be widely deployed, I don't see any way that > can be done in time. I believe that the proposed approach will lead to > a fragmented internet. > > We did not actually think there are many really tough issues in section > 3; most are straightforward protocol engineering. In any case, it > seemed to us that starting from a known place, the format of CLNP, the > engineering would converge more quickly than if we declared open season on > the IPv4 header. From other messages on the net and from your response it looks to me like there is some agreement that we will need to to modify CLNP to turn it into IPv7. Why is this different from declaring "open season" on the IPv4 header? Why will we be able to control changes to one and not control changes to the other? > All of these would need to have new > specifications written and made available as RFC's. This will be a very > significant effort. Also the style that the CLNP, ISIS, etc., documents > are written in is very different from the style of the TCP/IP documents. > > I don't see this as an issue. I have talked to a number of implementors who have found the style of the TCP/IP documents much easier to understand and implement from than from the corresponding CLNP documents. This may be a matter of understanding of new terminology and style, but the effect is that it increases the cost of implementing the protocol. Changing cultures has a non-trivial cost. > This is saying that we only have to change everything a little bit. > This is a very big impact on products and the operational internet. > > ANY solution to our growth problems, even IPAE, will have "a very big > impact on products and the operational internet". We felt that a change > that kept the general principles intact but changed a header format would > overall cause less disruption, learning time, etc., than another kind > of solution. I agree the Internet has grown large enough that any change we make will have a big impact. I don't agree that all changes will have the same cost and that the CLNP proposal reduces the impact of the change by keeping the "general principals intact". It may keep the principles intact, but it changes most of the details. I think it is the details that impact the cost the most. > Why is it "vital" to escape the 60-byte limit on IP options? There is > a significant body of experience that says the options are a bad idea > in the first place. This is the first time I have seen this argument > that we should have room for more options. > > "Bad idea" seems a bit strong. They are an architectural technique for > relatively painless extensions; I am not aware of an alternative, but this > may just be my ignorance (I would be happy to be wrong here, and if there > *is* an alternative, it could certainly affect my own conclusions). I am of the opinion that the packets that carry the data should be as simple to forward as possible (note my work on ATM which takes this to the extreme). I think that the complexity required for routing / QOS / etc. should be done as much as possible out of band from the actual packets that carry the data. The notion of putting lots of stuff in options that go in every packet seems to me like a move in the wrong direction. I think it is much easier to make a few simple things go very fast than many complex ones. > Before IPAE and similar approaches are discarded, it should be allowed > a full and open discussion of its advantages and disadvantages. Doing > otherwise, IMHO would be a great disservice to the internet community. > > That's a non-technical issue that I would rather not address at this time. > I do understand your desire here, and I expect you will realize it. Thanks. I do think it is important. > Why is this inevitable and why just two protocols? There are other > internet protocol families which have larger installed bases. > > The word "inevitable" was a poor choice. It reflects our deep desire to > end the costly and devisive us/them war in world-wide networking, so > we can all get on with the problem; "inevitble" was wishful thinking. > The other internet protocol families are proprietary, and therefore > they do not appear to be feasible, even if they were desirable, as > the basis for universal networking. This is also an non-technical issue. > Why is this a long term objective? I was not aware of a consensus that > thought this was true. I thought the objective of this proposed change > was to solve the Internet's routing and addressing problems. > > Well, for one thing it was part of the results of Group 2 at the first > IAB architecture retreat, recorded in RFC-1287 and reported to the > Atlanta IETF meeting. I don't recall your objecting before. And is it > a surprising objective? It seems like Motherhood/Apple Pie (in the sky, > it would appear from this week's events!). Do you really take exception > to it?? No, but we need to be sure of the cost of achieving the goal. > Other work which will have to be done is to define current mappings for > running CLNP over all of the current types of networks, that we > currently have for IP. This is a significant project and will open up > old issues about how best to do it over each type of network. > > As has been agreed for several years, it is the objective of the > IAB/IETF to build a multiprotocol-suite Internet, so the IAB assumed > that we are on the road to solving these issues anyway. I am not saying that it is impossible, but it does need to be done and it will take real time to complete. My concern is that given the total magnitude all of small changes required to implement the CLNP proposal, the internet will break long before it can be completed. > On the other hand if we proceed this way, we are likely to start a war. > There is no consensus on this approach. I think it would be much > preferable to take some time to work out the many issues stated in this > document regarding the conversion to CLNP and to examine other > approaches. There will be much less fighting if the community feels > that there has been a fair hearing of the issues and approaches. > > Well, it does seem you were right about starting a war. The degree of > irrationality that is floating around is quite disconcerting. I have > recently seen some personal attacks on the integrity of IAB members > that make me quite angry. I regret most that my attempt to explain > our ideas was apparently inadequate, because people keep bringing up > the same misconceptions. Some of it may be irrational, but I think a lot of it is based on very real concerns about the impact of the CLNP proposal. I agree with you that all personal attacks are unwarranted. We are all trying to do what is right. Bob From owner-Big-Internet@munnari.oz.au Thu Jul 9 15:17:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23466; Thu, 9 Jul 1992 15:17:37 +1000 (from owner-Big-Internet) Return-Path: Received: from ray.lloyd.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23448; Thu, 9 Jul 1992 15:17:22 +1000 (from brian@lloyd.com) Received: by ray.lloyd.com (4.1/SMI-4.1/Brent-911016) id AA07137; Wed, 8 Jul 92 22:17:10 PDT Date: Wed, 8 Jul 92 22:17:10 PDT From: brian@lloyd.com (Brian Lloyd) Message-Id: <9207090517.AA07137@ray.lloyd.com> To: big-internet@munnari.oz.au Subject: future of IP Reply-To: brian@lloyd.com No Chicken Little, the sky is not falling. There seems to be an undercurrent of panic. No, we are not facing the imminent exhaustion of IP addresses, only the imminent exhaustion of class-B network numbers and a painful expansion of the routing tables. CIDR deals with these immediate problems so let's try to keep all this in perspective. So let's implement CIDR and take a deep breath. Then we can decide what is really needed to replace IP and try to get it right. Remember, we do not need to adopt the first solution presented. Brian Lloyd, WB6RQN Lloyd & Associates Principal and Network Architect 3420 Sudbury Road brian@lloyd.com Cameron Park, CA 95682 voice (916) 676-1147 -or- (415) 725-1392 From owner-Big-Internet@munnari.oz.au Thu Jul 9 22:05:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04988; Thu, 9 Jul 1992 22:06:12 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207091206.4988@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04967; Thu, 9 Jul 1992 22:05:31 +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, 9 Jul 1992 13:03:55 +0100 To: big-internet@munnari.oz.au Subject: Re: IAB proposal for CIDR and IPv7 - NSAP Allocation Date: Thu, 09 Jul 92 13:03:49 +0100 From: Jon Crowcroft this wont worry many folks in the US, but i just thought: how do you tell the difference between a CONS NSAP and a CLNS NSAP? (at the moment, many systems are parsing PSAPs and pulling out DoD magic, or ISO magic and thence deterimine the protocol domain with which to communciate with peer...this is a bit tricky if the parse is the same...) j. From owner-Big-Internet@munnari.oz.au Fri Jul 10 01:05:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09719; Fri, 10 Jul 1992 01:05:50 +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 AA09709; Fri, 10 Jul 1992 01:05:34 +1000 (from Bob.Hinden@Eng.Sun.COM) Received: from Eng.Sun.COM (zigzag-bb.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1) id AA26844; Thu, 9 Jul 92 08:05:21 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA22500; Thu, 9 Jul 92 08:05:22 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA02953; Thu, 9 Jul 92 08:05:03 PDT Date: Thu, 9 Jul 92 08:05:03 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9207091505.AA02953@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA24562; Thu, 9 Jul 92 08:05:18 PDT To: brian@lloyd.com Cc: big-internet@munnari.oz.au In-Reply-To: <9207090517.AA07137@ray.lloyd.com> Subject: future of IP Brian, I agree with you. The near term problems we are facing are exhaustion of the Class-B addresses and our ability to continue to do dynamic routing. We don't face running out of addresses until the end of the decade. I did a very simple projection assuming that we now have 7,000 networks and that it doubles each year. This is somewhat conservative because I don't think we are doubling each year. Last time I looked it was more like 14-18 months. Year Networks ----- --------- 0 7,000 1 14,000 2 28,000 3 56,000 4 112,000 5 224,000 6 448,000 7 896,000 8 1,792,000 9 3,584,000 10 7,168,000 I think we have about 8 years. If there is a crisis, it is to solve the routing problems. CIDR is the first step. We will need step two shortly there after. Bob From owner-Big-Internet@munnari.oz.au Fri Jul 10 01:13:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10045; Fri, 10 Jul 1992 01:13:30 +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 AA10038; Fri, 10 Jul 1992 01:13:21 +1000 (from jbvb@ftp.com) Received: from jbvb.plug.ftp.com by ftp.com via PCMAIL with DMSP id AA28094; Thu, 9 Jul 92 10:54:13 -0400 Date: Thu, 9 Jul 92 10:54:13 -0400 Message-Id: <9207091454.AA28094@ftp.com> To: ietf@isi.edu Subject: Re: IPv7 (CLNP) a mistake From: jbvb@ftp.com (James B. Van Bokkelen) Reply-To: jbvb@ftp.com Cc: big-internet@munnari.oz.au, iab@ISI.EDU, iesg@nri.reston.va.us, road@lanl.gov Sender: jbvb@ftp.com Repository: babyoil.ftp.com Originating-Client: plug.ftp.com A vendor's perspective: We at FTP have always taken the point of view that if we implement for the Internet, that will also satisfy our non-connected customer base, since the Internet is where they're likely to be in a few years. If we're to continue to do this, and if the protocol suite we've invested in is to continue to compete well against the proprietary stacks, the Internet must remain viable. I see the following problems affecting the Internet's viability: 1. Security of networked hosts. 2. Installation, configuration and maintenance of networked hosts. 3. Routing table size issues. 4. Address space exhaustion. The IAB proposal to adopt CLNP is aimed at the latter two. On the face of it, the 20-byte NSAP solves 4, and the extra room lets us use space inefficiently doing route aggregation, which solves 3 as well. Why CLNP, and not something else? CLNP appears to have three things going for it: First, it is standardized and implemented in both hosts and routers, which is a positive compared to other proposals. Second, a fairly large fraction of the existing Internet router base either already can carry CLNP traffic, or can easily be upgraded to do so. Third, CLNP is viewed as a "step towards ISO" by a number of large organizations which have major political commitments towards it. CLNP also has a number of technical and organizational negatives, but they've been discussed by others. The first two major positives for CLNP are eliminated if we don't use it out of the box, as it is specified in current ISO documents (I expect that the third would still get a lot of PR play). Many of CLNP's negatives can be dealt with by a CLNP+. But specifying and implementing a CLNP+ will be an effort of the same scale as doing IPv7 by doubling the size of RFC 791's Src, Dst and Hlen fields. A rose by any other name... Also, some thoughts about the practical issues relating to an IPv7 as they affect the existing code base. Internetwork layer: If the Internet isn't to be fragmented, during the transition all hosts have to remain able to interconnect. In practical terms, this means they would have to implement either IPv4 or both IPv4 and IPv7. I don't think transition by network or region with translating gateways will fly, simply because of the number of people who're bound to what's available commercially, off the shelf. Experience with the HRRFCs suggests that it will take three or four years before all the vendors respond, and no region will be able to convert prior to that unless their equipment is homogeneous, current production, and supported by a forward-looking vendor. Having two IP stacks will complicate configuration, and increase the memory required by the stack (I'd guess that at least 30% of the hosts in the Internet are DOS PCs, and this will cost in that environment). Transport layer: Initially, TCP and UDP continue to work, but they depend on a "magic glue layer" which figures out whether the IP address they're dealing with is real, to be handled by the IPv4 side, or only a local token which needs to be mapped to an NSAP for IPv7. Later, TCP and IP become NSAP-aware. For most stacks, the work here will be new upper and lower APIs which allow opaque addresses of arbitrary size. Maybe we don't care about the TCP "pseudo-header" anymore, and the IP address and ports can become constants. It's only saved my bacon a couple of times, when deep in the internals of our TCP, and it does make things much harder in a multi-homed host. Applications: Initially, we should be able to hide the transition from IPv4 to IPv7 beneath the transport layer API. The name-resolver determines which to use, and supplies the "local token" if necessary. This gets you going in situations where the name resolver isn't actually linked into the application, but some PC stacks which chose to do otherwise will make their 3rd parties suffer. The downside is that anything that prints an IP address (and most supportable Internet applications do somewhere in their debugging code) is devalued. Eventually, all applications have to be re-compiled (and maybe re-coded if the new API doesn't just change the size of struct sockaddr or whatever). This process won't be finished before the turn of the century. My conclusions: First, we need to stop arguing and start work on solving the routing table size and address space problems now, since it will take years to propagate into the installed base. From what I've seen so far, I'd prefer IP-inside-IP, since it greatly reduces the number of places where things get complicated (I router vendors, J routers and K regional network NOCs instead of 1000 times as many application vendors, hosts and LAN administrators, respectively). However, if this can't be done for reasons I'm unaware of, FTP is going to have to do the coding and suffer the support/upgrade pain whether IPv7 is CLNP or 2x(RFC 791), and we'll live with it. Second, departure from "by the book" CLNP might be worthwhile, but we shouldn't try to hang onto the name if we chose to do so. Even something that looks as simple as re-doing the NSAP format and address assignment is likely to require code changes in both the packet forwarding and routing protocol sections of most CLNP-capable routers. James B. VanBokkelen, Exec. V.P. 26 Princess St., Wakefield, MA 01880 FTP Software Inc. voice: (617) 246-0900 From owner-big-internet@munnari.oz.au Fri Jul 10 03:04:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14106; Fri, 10 Jul 1992 03:04: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 AA10309; Fri, 10 Jul 1992 01:17:44 +1000 (from kasten@ftp.com) Received: by ftp.com id AA28262; Thu, 9 Jul 92 10:58:20 -0400 Date: Thu, 9 Jul 92 10:58:20 -0400 Message-Id: <9207091458.AA28262@ftp.com> To: big-internets@munnari.oz.au.mrose@dbc.mtview.ca.us Subject: Re: IAB proposal for CIDR and IPv7 From: kasten@ftp.com (Frank Kastenholz) Cc: lyman@bbn.com, big-internet@munnari.oz.au, iab@venera.isi.edu, iesg@nri.reston.va.us, ietf@isi.edu, road@lanl.gov i second the motion -- furthermore, a few days ago someone suggested that we emulate the bostonians of 200+ years ago and, substituing the iab members for tea, we hold another boston tea party... and with the tall ships being in town, we can dump the "tea" off of real sailing ships > So, my second solution is this: we wait until the Boston meeting of the > IETF. If the IAB retracts, we start working like demons using the IESG > recommendations as a roadmap. If not, I suggest we start a grass roots > effort to devise a small, stream-lined "Internet Technology Board" (pick > your own name), which would maintain a document series of "good" > technology, and be responsible to "the consent of the governed". It > seems to me that we would could collapse the two-tier IAB/IESG structure > into the ITB. Of course, fundamental to such a revolution would be the > notion that we start paying more attention to "product". (At present, > the IESG appears to care far more about "process" rather than > "product"--we need to reverse that trend.) > -- Frank Kastenholz From owner-Big-Internet@munnari.oz.au Fri Jul 10 04:21:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16119; Fri, 10 Jul 1992 04:21:44 +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 AA16116; Fri, 10 Jul 1992 04:21:24 +1000 (from braden@ISI.EDU) Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Thu, 9 Jul 1992 11:22:33 -0700 Date: Thu, 9 Jul 1992 11:20:27 -0700 From: braden@ISI.EDU Posted-Date: Thu, 9 Jul 1992 11:20:27 -0700 Message-Id: <199207091820.AA06497@braden.isi.edu> Received: by braden.isi.edu (5.65c/4.0.3-4) id ; Thu, 9 Jul 1992 11:20:27 -0700 To: kasten@ftp.com Subject: Re: Comments on IPv7 Document Cc: Bob.Hinden@eng.sun.com, big-internet@munnari.oz.au From kasten@ftp.com Thu Jul 9 11:15:00 1992 Date: Thu, 9 Jul 92 14:14:26 -0400 To: braden@ISI.EDU Subject: Re: Comments on IPv7 Document From: kasten@ftp.com (Frank Kastenholz) Cc: Bob.Hinden@eng.sun.com, big-internet@munnari.oz.au > A new version of IP is one approach, but I don't > see why it is required. IPAE and similar approaches present clear > alternatives to deploying a new version of IP with much less impact on > the existing operational system. Further, no solution to the routing > table explosion problem is presented here at all as far as I can tell. > > In our discussion, we clearly identified IPAE as a technically credible > approach, and we recognized its low operational impact. However, as I > noted above, we felt that continuing homogeneity of forwarding was a > principle we did not want to give up. I suggest that there are lots of > hidden costs implicit in introducing the new level of structure > implied by Commonwealths. Commonwealths just represent one way of doing routing hierarchies and, therefore, route aggregation. Bill, I believe the issue is forwarding (as I noted in my earlier comment), not routing. Bob Braden From owner-Big-Internet@munnari.oz.au Fri Jul 10 04:27:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16249; Fri, 10 Jul 1992 04:27:13 +1000 (from owner-Big-Internet) Return-Path: Received: from babyoil.ftp.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16241; Fri, 10 Jul 1992 04:27:00 +1000 (from kasten@ftp.com) Received: by ftp.com id AA05124; Thu, 9 Jul 92 14:14:26 -0400 Date: Thu, 9 Jul 92 14:14:26 -0400 Message-Id: <9207091814.AA05124@ftp.com> To: braden@ISI.EDU Subject: Re: Comments on IPv7 Document From: kasten@ftp.com (Frank Kastenholz) Cc: Bob.Hinden@eng.sun.com, big-internet@munnari.oz.au > A new version of IP is one approach, but I don't > see why it is required. IPAE and similar approaches present clear > alternatives to deploying a new version of IP with much less impact on > the existing operational system. Further, no solution to the routing > table explosion problem is presented here at all as far as I can tell. > > In our discussion, we clearly identified IPAE as a technically credible > approach, and we recognized its low operational impact. However, as I > noted above, we felt that continuing homogeneity of forwarding was a > principle we did not want to give up. I suggest that there are lots of > hidden costs implicit in introducing the new level of structure > implied by Commonwealths. Commonwealths just represent one way of doing routing hierarchies and, therefore, route aggregation. Encoding routing hunks/domains/ areas/... in the 20 bytes of NSAP is another way of doing route aggregation. This all adds more structure to routing. Furthermore, we already, with IPv4, have routing levels and structures that the end nodes have to deal with ("Is the destination on my net/subnet or not? If it isn't, which router do I send the packet to?"). In other words, we do not today have a "homogeneity of forwarding." I do not see how IPv7/CLNP's form of structure (buried in various parts of the NSAP/ Address) is inherently better/worse than any of the other schemes for doing structure. There might be transition issues, but there will be transition issues with anything we do and I imagine, that once we start fielding the new protocol, we will find that the actual problems with transition will have little, if anything, to do with what we now think the issues will be. -------------------------------------------------------------------------- > >> We furthermore argue in favor of a variable-length address format, > >> with a known upper bound. This upper bound will need to be large, > >> potentially increasing the IP header size significantly. However, > >> with a reasonable address assignment scheme, most networks numbers > >> will be much smaller. Indeed, it might be desirable to use the > >> existing 4-byte IP addresses for many hosts during a transition. > Another point that needs to be addressed is the amount of storeage NSAP > addresses will take in routers. Ignoring the issue of performance > inefficiencies in processing variable length addresses, I fail to > understand how routers in this architecture will be able to store large > quantities of 20-byte addresses when today they have problems with fewer > 4-byte addresses. Memory is certainly getting cheaper, but not by a > factor this large. We need larger addresses for sure, but 5 time bigger? > > We urged variable-length addresses. Variable length things are a bad idea. Period. Things like addresses are referenced and diddled with so often. To make them variable length means that you have to do a lot of decoding and parsing of the header and this kills your performance. One of the best things about IPv4 is that the address is 32 bits and that fits real nicely into CPU registers, etc. Unfortunately I still have to deal with address classes, and that slows things down. As to router storage, I imagine that only the "important" part of the address would be kept in storage -- i.e. the part of the address that the router actually uses for routing. ----------------------------------------------------------------------- > >> 2.7. Extensibility > >> > >> Evolution from IPv4 to IPv7 will be occurring at the same time that > >> research work is on the verge of requiring architectural extensions > >> in other areas. Two important examples are supporting real time > >> applications (e.g., packet voice and video) [Realtime], and > >> providing better security services. IPv7 should provide easy > >> extensibility in order to support such new areas. > >> > >> In particular, it is vital to escape the 60 byte limit on the IPv4 > >> header, in order to have more space available for options. > > Why is it "vital" to escape the 60-byte limit on IP options? There is > a significant body of experience that says the options are a bad idea > in the first place. This is the first time I have seen this argument > that we should have room for more options. > > "Bad idea" seems a bit strong. They are an architectural technique for > relatively painless extensions; I am not aware of an alternative, but this > may just be my ignorance (I would be happy to be wrong here, and if there > *is* an alternative, it could certainly affect my own conclusions). Options: A) Imply variable lengths. Which, in turn, slows down processing of the header. It slows down routing. It makes the code more complex. B) Imply optionality. If they are optional then they are not really needed to move traffic through the net and that is what this protocol is supposed to do. I contend that, if it is needed to move traffic through the net, put it in the "non-optional" part of the protocol. If it is not needed either toss it or make it part of a separate protocol. Furthermore, you run into real problems when I implement options 1, 3, and 5 and you implement options 2, 4, and 6. Because of it, we may not be able to communicate. Also, the fact that I implement option 3 does not imply that everyone implements it so, since I can not be sure that all of the other nodes that I wish to communicate with implement option 3, I probably will not make much use of it. There would then be an added complexity with very little gain. ------------------------------------------------------------------------ > >> In addition, CLNP has awkward boundary alignments for RISC- > >> architecture machines. We do not regard any of these as show- > >> stoppers. > > The RISC performance issue is not a showstopper, but is an important > performance concern. I can't see any way around this except for a very > major change to CLNP. > > I don't disagree. And these change changes will result in a large rearrangement of the header, in effect creating an entirely different protocol. If the ISO do not adopt these changes then there will be no interoperability. --------------------------------------------------------------------------- > Another concern I have with CLNP is the checksum algorithm used. It is > much more expensive to compute in software than the IP checksum. I > have even heard that some comments that it is harder to do in hardware. > Specifically, I site the decision by Protocol Engines to not include > the CLNP checksum in the network chip they have built. Greg Chessins > should be able to provide more information. > > The checksum has been extensively discussed in the last few days. I see > no problem in changing it if we need to; the incremental update problem > in a router does seem like a potential show-stopper to me. Again, by doing this to the protocol, it will change dramatically. It will not be interoperable with the "real" (i.e. ISO approved/sanctioned/blessed) protocol (modulo the ISO changing their version of the spec). > Agreed, a possible solution. The IAB did not want to make engineering > judgments, except to try to detect show-stoppers before the show started. I've tried to keep this note technically oriented, as the big-internet list's discussion should be but this is too weird. Saying "use CLNP" IS an engineering judgement. -- Frank Kastenholz FTP Software From owner-Big-Internet@munnari.oz.au Fri Jul 10 08:28:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22156; Fri, 10 Jul 1992 08:28: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 AA22151; Fri, 10 Jul 1992 08:28:29 +1000 (from bill@wizard.gsfc.nasa.gov) Received: by wizard.gsfc.nasa.gov (5.65/1.35) id AA04385; Thu, 9 Jul 92 18:28:30 -0400 From: bill@wizard.gsfc.nasa.gov (Bill Fink) Message-Id: <9207092228.AA04385@wizard.gsfc.nasa.gov> Subject: Re: Comments on IPv7 Document To: big-internet@munnari.oz.au Date: Thu, 9 Jul 92 18:28:29 EDT X-Mailer: ELM [version 2.3 PL11] I think the IAB recommendation to base IPv7 on CLNP is misguided because, from my perspective, it's main goal seems to be optimizing the wrong things. In particular, much more weight seems to be given interoperability with the relatively small OSI internet rather than with the extensive, day-to-day operational, real Internet. Given the tremendous base of current IP systems and the fact of a very protracted transition period, the continued interoperability of both "old" and "new" hosts must be a paramount consideration. Having survived the very painful transition from NCP to TCP, when the fledgling Internet was several orders of magnitude smaller than it is today, IMHO it would be completely disastrous to change to an incompatible addressing and routing structure. If we are going to go through that level of pain, then it should not only be done to support a bigger Internet but a much better Internet, with support for new functionality such as real-time voice and video. This will require a major research effort and therefore will almost certainly not be based around ANY current internetwork packet format, including IP and CLNP, but should most certainly be based upon all the lessons learned from the design, development, and deployment of both those protocols. Also, a key argument for the CLNP approach to IPv7 is that it is perceived to be the solution with the least change to the Internet architecture, the claim being made that we're just swapping one packet format for another. First, although minimizing changes to the Internet architecture should definitely be a consideration in the design choices made, it should not unduly interfere with other more significant goals. One of the most important of these goals should be to minimize the changes required to the hundreds of thousands of hosts in the Internet, provided by hundreds of vendors, and supported by thousands of campus and regional network support organizations, together with the massive accumulated knowledge and experience of all these groups, the Internet Mind if you will. The optimal solution would require changes only to the Internet routers, which are much fewer in number than hosts and generally managed by more experienced network personnel than end users. Even better would be if any major changes were restricted only to a select set of border routers, which would be managed extremely carefully during the transition period. But even the perceived advantage of the CLNP approach doing the least harm to the Internet architecture is IMHO only a mirage. It sure sounds simple to say we're only changing one packet format for another but what does it really entail. The analogy I would like to present is that swapping out IP for CLNP is like trying to live in a house while someone is ripping out the foundation and replacing it with a new one while somehow continuing to keep the electricity, plumbing, heating and air conditioning, phones, and other services working. Maybe it could be done without destroying the house, but I certainly wouldn't want to be the one living there while this was happening. Maybe if there were no better alternatives, we'd just have to live with the pain. But there are much better alternatives. I happen to favor the IPAE approach because of its minimal disruption to the existing Internet infrastructure. And contrary to the claims in the IAB recommendation, I think it doesn't significantly alter the Internet architecture, but simply adds a useful extension. In my house analogy, it would be akin to adding an extension to the house. Although there would be some disruption to activities, the house would remain livable during the building period. To conclude, I would recommend using CIDR as the short term solution, IPAE as the medium term solution, and research leading to a son of IP and CLNP as the long term solution. It's what the Internet requires to continue to grow and prosper. -Bill From owner-Big-Internet@munnari.oz.au Fri Jul 10 15:05:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04060; Fri, 10 Jul 1992 15:05:45 +1000 (from owner-Big-Internet) Return-Path: Received: from ppp.dbc.mtview.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04050; Fri, 10 Jul 1992 15:05:19 +1000 (from mrose@dbc.mtview.ca.us) Received: from localhost (localhost.ARPA) by dbc.mtview.ca.us (4.1/3.1.090690) id AA07159; Thu, 9 Jul 92 22:04:37 PDT To: big-internet@munnari.oz.au Subject: oops, a bad address... Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Date: Thu, 09 Jul 1992 22:04:36 -0700 Message-Id: <7158.710744676@dbc.mtview.ca.us> From: Marshall Rose ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" sorry for the inconvenience... ------- =_aaaaaaaaaa0 Content-Type: multipart/digest; boundary="----- =_aaaaaaaaaa1" (RFC 934 compatible encapsulation) ------- =_aaaaaaaaaa1 Replied: Thu, 09 Jul 1992 21:58:06 -0700 Replied: dave@sabre.bellcore.com Replied: big-internets@munnari.oz.au Replied: ietf@isi.edu Path: dbc!sabre.bellcore.com!dave >From: dave@sabre.bellcore.com Newsgroups: internet.ietf Subject: Re: IAB proposal for CIDR and IPv7 Message-ID: <9207081538.AA09421@sword.bellcore.com> Date: Wed, 8 Jul 1992 11:39:28 -0500 Sender: daemon@dbc.UUCP Lines: 59 Return-Path: To: big-internets@munnari.oz.au Cc: ietf@ISI.EDU >IPv7 "decision" and associated Internet-draft do not contain such an >analysis. Instead, they say something which could be paraphrased as: > > "we *will* do IPv7, we will ignore any other proposal, and all we > need to do now is to figure out a way to make IPv7 work" > >The most polite term I can use for this behavior is irresponsible. Please tell me from what part of the text you draw this conclusion: I've already posted 2 examples of what I perceive as text of a substantially more moderate tone: Abstract: "IAB's current *preference*..." Section 1.3: "Section 5 summarizes *proposed* directions..." "we *believe*..." Section 2.3: "we *argue* in favor of..." Section 5: "we therefore *recommend*" Section 5 "the IAB *favors*..." Hey, I'm tired of playing defense attorney; and before you all dismiss these as rantings of yet another ISORmite, please read my comments on IPAE, offered in the spirit of finding a good solution to the problem. If I can ever pry myself away from mail, I'll get to PIP and EIP as well...oh, and those SMP thingies...(and you grump about the IESG wasting cycles...:-( >IPv7 is either an ISO-standard protocol, or it's not an ISO-standard >protocol. The argument about "being able to have our cake and eat it >too" is specious. If you run CLNP, then you have bought into the ISO >process. If not, then it isn't CLNP any more. How long before we >overhear a conversation like this: > > "What do you mean your CLNP router/host doesn't do that version of > CLNP? What do you mean there are two versions of CLNP and I just > bought a router/host that does the wrong one?" > >Talk about skewering the users! I continue to have substantially more faith in the people who try to work within the system than you do. I'm willing to sweat the blood to try to change CLNP for the better, whether it is to align with IPv7 or not; I wrote CLNP for OSI, and whether it is only for OSI or for OSI and TCP, I'd like to see it be the best it can be. >Now the rather obvious hidden-agenda of the IAB ... The balance of this message is so far removed from my perception of the process I can't imagine how to respond... --------- David M. Piscitello Bellcore NVC 1C322 331 Newman Springs Road Red Bank, NJ 07701 (908)-758-2286 (908)-785-4177 (Fax) ------- =_aaaaaaaaaa1 Resent: Thu, 09 Jul 1992 22:02:13 -0700 Resent: big-internet@munnari.oz.au To: dave@sabre.bellcore.com cc: big-internets@munnari.oz.au, ietf@isi.edu reply-to: big-internets@munnari.oz.au Subject: Re: IAB proposal for CIDR and IPv7 In-reply-to: Your message of "Wed, 08 Jul 1992 11:39:28 CDT." <9207081538.AA09421@sword.bellcore.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Jul 1992 21:58:02 -0700 Message-ID: <7055.710744282@dbc.mtview.ca.us> >From: Marshall Rose In response to the three issues you raise: Issue 1: Your claim that IPv7 is not an IAB "decision" > Please tell me from what part of the text you draw this > conclusion: I've already posted 2 examples of what I > perceive as text of a substantially more moderate tone: > > ... > > Hey, I'm tired of playing defense attorney; My guess is that you can take any number of random phrases from the IAB's Internet-draft and make it sound "moderate". However, if you take it as a whole, I will observe that: 1. They dismiss the other proposals. 2. They do not provide an analysis of the benefits and cost-distribution of each of the proposals. Now, we all know that each of the 4+ proposals have benefits and costs. What is lacking from the IAB's position is a comparitive analysis. Without such an analysis, their decision is not based on having the facts and is therefore unreasonable from a technical perspective. Issue 2: Your response to the political fallout of the IPv7 approach >> IPv7 is either an ISO-standard protocol, or it's not an ISO-standard >> protocol. The argument about "being able to have our cake and eat it >> too" is specious. If you run CLNP, then you have bought into the ISO >> process. If not, then it isn't CLNP any more. How long before we >> overhear a conversation like this: >> >> "What do you mean your CLNP router/host doesn't do that version of >> CLNP? What do you mean there are two versions of CLNP and I just >> bought a router/host that does the wrong one?" >> >> Talk about skewering the users! > I continue to have substantially more faith in the people who > try to work within the system than you do. I'm willing to > sweat the blood to try to change CLNP for the better, whether > it is to align with IPv7 or not; I wrote CLNP for OSI, and > whether it is only for OSI or for OSI and TCP, I'd like to > see it be the best it can be. What does this have to do with anything? Faith will not prevent the "two versions of CLNP" problem. Faith will not prevent the marketing slime trying to take advantage of this decision. (I notice you didn't even try to defend against that prediction.) Issue 3: Your response to the question of a hidden agenda > The balance of this message is so far removed from my > perception of the process I can't imagine how to respond... My only suggestion is that you open your eyes and figure out what's going on. As individuals, the IAB members may be good people. That is not the issue. The issue is that as a group, they have, to my mind, demonstrated themselves to be "a clear and present danger" to the Internet community. Me thinks it is time for a system which incorporates the notion of accountability -- something that the present system, which you have so much faith in, is sorely lacking. If this is the best defense you can mount for the IAB's apparent malfeasance, then they had better get another attorney. [Karl - you wanna take the case? (-: (-: ... (-: ] /mtr ------- =_aaaaaaaaaa1-- ------- =_aaaaaaaaaa0-- From owner-big-internet@munnari.oz.au Fri Jul 10 16:02:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05877; Fri, 10 Jul 1992 16:02:43 +1000 (from owner-big-internet) Return-Path: Received: from ppp.dbc.mtview.ca.us by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03980; Fri, 10 Jul 1992 15:02:52 +1000 (from mrose@dbc.mtview.ca.us) Received: from localhost (localhost.ARPA) by dbc.mtview.ca.us (4.1/3.1.090690) id AA07147; Thu, 9 Jul 92 22:02:12 PDT To: dave@sabre.bellcore.com Cc: big-internets@munnari.oz.au, ietf@isi.edu Reply-To: big-internets@munnari.oz.au Subject: Re: IAB proposal for CIDR and IPv7 In-Reply-To: Your message of "Wed, 08 Jul 1992 11:39:28 CDT." <9207081538.AA09421@sword.bellcore.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 09 Jul 1992 21:58:02 -0700 Message-Id: <7055.710744282@dbc.mtview.ca.us> From: Marshall Rose Resent-To: big-internet@munnari.oz.au Resent-Date: Thu, 09 Jul 1992 22:02:11 -0700 Resent-Message-Id: <7146.710744531@dbc.mtview.ca.us> Resent-From: Marshall Rose In response to the three issues you raise: Issue 1: Your claim that IPv7 is not an IAB "decision" > Please tell me from what part of the text you draw this > conclusion: I've already posted 2 examples of what I > perceive as text of a substantially more moderate tone: > > ... > > Hey, I'm tired of playing defense attorney; My guess is that you can take any number of random phrases from the IAB's Internet-draft and make it sound "moderate". However, if you take it as a whole, I will observe that: 1. They dismiss the other proposals. 2. They do not provide an analysis of the benefits and cost-distribution of each of the proposals. Now, we all know that each of the 4+ proposals have benefits and costs. What is lacking from the IAB's position is a comparitive analysis. Without such an analysis, their decision is not based on having the facts and is therefore unreasonable from a technical perspective. Issue 2: Your response to the political fallout of the IPv7 approach >> IPv7 is either an ISO-standard protocol, or it's not an ISO-standard >> protocol. The argument about "being able to have our cake and eat it >> too" is specious. If you run CLNP, then you have bought into the ISO >> process. If not, then it isn't CLNP any more. How long before we >> overhear a conversation like this: >> >> "What do you mean your CLNP router/host doesn't do that version of >> CLNP? What do you mean there are two versions of CLNP and I just >> bought a router/host that does the wrong one?" >> >> Talk about skewering the users! > I continue to have substantially more faith in the people who > try to work within the system than you do. I'm willing to > sweat the blood to try to change CLNP for the better, whether > it is to align with IPv7 or not; I wrote CLNP for OSI, and > whether it is only for OSI or for OSI and TCP, I'd like to > see it be the best it can be. What does this have to do with anything? Faith will not prevent the "two versions of CLNP" problem. Faith will not prevent the marketing slime trying to take advantage of this decision. (I notice you didn't even try to defend against that prediction.) Issue 3: Your response to the question of a hidden agenda > The balance of this message is so far removed from my > perception of the process I can't imagine how to respond... My only suggestion is that you open your eyes and figure out what's going on. As individuals, the IAB members may be good people. That is not the issue. The issue is that as a group, they have, to my mind, demonstrated themselves to be "a clear and present danger" to the Internet community. Me thinks it is time for a system which incorporates the notion of accountability -- something that the present system, which you have so much faith in, is sorely lacking. If this is the best defense you can mount for the IAB's apparent malfeasance, then they had better get another attorney. [Karl - you wanna take the case? (-: (-: ... (-: ] /mtr From owner-big-internet@munnari.oz.au Fri Jul 10 18:29:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10144; Fri, 10 Jul 1992 18:29: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 AA08587; Fri, 10 Jul 1992 17:34:12 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09848; Fri, 10 Jul 92 03:32:44 -0400 Date: Fri, 10 Jul 92 03:32:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207100732.AA09848@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, braden@isi.edu Subject: Re: FYI Cc: jnc@ginger.lcs.mit.edu we felt that continuing homogeneity of forwarding was a principle we did not want to give up I absolutely, utterly, completely agree. (In fact, I take a more radical view here, as you will see.) I think allowing/keeping internal routers tied to some crummy ancient routing architecture will be a giant millstone around our necks as we try to struggle through to a new R&A system. I think it is simply not worth the (alleged) reduction in cost. Most routers are maintained by support organizations (i.e. not by some professor who throws the new software releases for his workstation in a drawer), are from vendors with good new release support, etc. They can be changed at a far lower cost in pain than hosts, and I think it is reasonable to do so to get a unified routing system. If we kept unmodified internal routers working on a different addessing model, the resulting system will be more complex, confusing, difficult and error-prone, and I'm willing to bet the extra costs of doing that will very, very, very quickly outweigh the savings in internal router updating and reconfiguration. Parenthetically, I'll state my opinion that all we will be doing is replaying in a order of magnitude more obvious and complex way what I consider the current folly of separating inter and intra-domain routing. I know not everyone agree that this is a Bad Idea, but think; that separation just provides a firewall, and new routing technologies provide far more subtle and sophisticated firewalls. At the San Diego Architecture retreat, Sue Hares had a lot of problems she wanted to get some insight on, and they all turned out to be caused by the EGP/IGP split. It's an essentially identical situation to the old days when the fact that ARPANet topology was not visible to the IP routers didn't allow us optimal use of the ARPANet; e.g. a hop across the ARPANet to a WBNet router, up and down, then another hop to the destination. Arguments that you want the routing to have different characteristics on a local and global scale (e.g. update frequency, etc) cut zero ice with me. Add a knob. Have a program frob the knob, if you don't want to let people play with it. It's not clean, but it's much cleaner than two whole protocols. Split routing architectures are always bad news. Grand Unification! Dave Clark has suggested .... application-layer gateways architected in. The IAB is not willing to buy into that... we want to maintain the concept of a fully-connected and uniform internet-level transport mechanism I'm not thrilled with this idea either, and completely agree with the IAB here too. I understand the motivating factors; the Swiss cheese we call Internet security is a powerful motivator. My single biggest argument against it is that a really nice feature of the IP architecture is that you can deploy new applications really easily, with no cenralized planning or support from the 'DP department' who run the routers *whatsover*. Two hosts install the code, and presto... With application gateways, you either gotta put gateway code to handle a new application in all intervening gateways, or run it on top of an existing gatewayed protocol, thereby recreating the whole system again in miniature (the 49 layer model, I think this I've seen this called :-). Let's not forget, all the internal stuff we love is just sausage guts to the people who made the system this big, and *applications*, new ones, better ones, more powerful ones, are what they want. Anything that gets in the way of deploying these is going a long way to vitiate the whole point of the network. [Options] are an architectural technique for relatively painless extensions... Again, I concur with the IAB. As I pointed out before, options are the only way we have of extending the semantics of the packet layer without a global change of header format, and we better have some flexibility here, or we are sunk. Efficiency we can fix piecemeal in the routers, but if you can't say something you gotta say, you're #$%'d. I think the introduction of a new layer of encapsulation and a new level of entity having different access rules is a significant complication of the architecture. I agree that in the long term these points are important. I generally pass on anything with encapsulation in it; I've been burned too many times. For this and other reason (e.g. routing split), I just don't think IPAE is a clean system in the long run. I still stick to a technique where I understand clearly the ultimate goal, and that goal is the best system I can devise, and then pick a path which minimizes the costs of getting to that goal. I'm dubious that IPAE is either the endpoint (for numerous reasons, some of which we have touched on), or on that path. One way to look at this is 'what are you trying to optimize in the transition'. Minimizing the number of times we change the hosts is a really big factor. If you buy Van's argument that a change to the packet format (and the hosts) now is to be avoided, then IPAE is not on the most efficient path. I've yet to hear a debate as to why Van is wrong on this. Sure, we'll need to change the hosts as some point (unless we do NAT, ugh), but why quickly? Remember, to get out of your commonwealth, you have to change your host (or use an application gateway, ugh). I'll bet a lot of people don't want to be stuck inside their commonwealth, so we'll have a lot of hosts to convert fairly quickly after deployment starts. Also, in analyzing the costs of the transition path, I see things that don't make sense to me. Keeping internal routers unchanged is not high on my list of priorities. The degree of irrationality that is floating around is quite disconcerting. People are involved. People are, at base, emotional and irrational, more so in times of stress. Years of professional work and ego, and lots of business, money and responsibility to provide services are at stake. I'm only surprised it wasn't *worse*. I have recently seen some personal attacks on the integrity of IAB members that make me quite angry. I agree this sort of thing is unhelpful. Let's stop speculating about motives; nobody has a telescope that shows a person's soul. People are complex, and do things for subtle mixes of reasons. Some debate on how the organization works at a non-personal level is acceptable, but let's remember the organization is here as a means, not an end. That end is good design. Let's concentrate on the technical issues of what is and is not good design, and keep to that. We can't go wrong if we all stick to that guiding light. Noel From owner-Big-Internet@munnari.oz.au Fri Jul 10 18:44:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10459; Fri, 10 Jul 1992 18:44: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 AA10452; Fri, 10 Jul 1992 18:44:28 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10390; Fri, 10 Jul 92 04:44:08 -0400 Date: Fri, 10 Jul 92 04:44:08 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207100844.AA10390@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Nimrod BoF Agenda question Cc: jnc@ginger.lcs.mit.edu One of the things I want to do at the Nimrod BoF is bounce around some interesting points, of which a number came up on the mailing list that I'm still thinking about. (There are a small sea of open points in the document; I'll list the major ones, but doubt there will be time to tackle them, unless we hold other meetings after the BoF.) I've got a partial list of the mailing list ones, and I'm looking for ones I forgot. Can people who remember (or think up) others send them to me? (Reply to me only, please, I will summarize to the list.) Noel --------- From Big-I: - Do we keep ARP (i.e. does some part of address binding happen locally) - What do endpoint identifiers look like (i.e. fixed/variable length, how are the assigned, etc) - Address size and basing (i.e. do addresses grow up, down or both) - Multiple addresses (i.e. what uses do people see for these) - Mobile hosts (i.e. do we map addresses to addresses, or what, and how far back toward the source do we go with the news that the address has changed) - New packet format (i.e. do people believe Van and think we should put this off as long as possible, and if not, why not) Local: - Deployment plan (i.e. what holes do people see in this that I have missed) Document: - Area representation issues (i.e. is an area a node or a simpler piece of topology, and are area nodes s always separated by routers) - 5.1 - Strict reduction (i.e. can level K area only contain K-1 objects, or K-2 .... 0 objects as well) - 5.1 - Default abstraction algorithm (model an area as a pseudo node with individual links to border routers, or N^2 border router direct interconnections) - 5.4 - Do we wrap packets (how do we add addresses to packets which need them, and are packets in flows modified or wrapped) - 5.7 - Entry point optimization (i.e. of the three suggested methods for handling people with multiple service providers, which looks most promising) - 6.3 From owner-Big-Internet@munnari.oz.au Fri Jul 10 23:14:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16518; Fri, 10 Jul 1992 23:15:07 +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 AA16512; Fri, 10 Jul 1992 23:14:55 +1000 (from ljm@ftp.com) Received: from ljm.leather-lace.ftp.com by ftp.com via PCMAIL with DMSP id AA08149; Fri, 10 Jul 92 09:14:27 -0400 Date: Fri, 10 Jul 92 09:14:27 -0400 Message-Id: <9207101314.AA08149@ftp.com> To: big-internet@munnari.oz.au Subject: Re: IPv7 == CLNP or CLNP+ ? From: ljm@ftp.com (leo j mclaughlin iii) Reply-To: ljm@ftp.com Sender: ljm@ftp.com Repository: babyoil.ftp.com Originating-Client: leather-lace.ftp.com >> Given this deployed base, won't that make it that much harder to get >> non-interoperable modifications to the basic CLNP through the ISO? Is the ISO >> really going to be willing to obsolete the substantial investment made by all >> the vendors and users who have taken the path the ISO laid out? > > It sure will be. Just look at '88 X.400 vs. '84 X.400. > I have. However, I find it rather extraordinary that the '84 to '88 X.400 'transition' be held up as an example of successful protocol development or deployment. enjoy, leo j mclaughlin iii ljm@ftp.com From owner-Big-Internet@munnari.oz.au Sat Jul 11 04:56:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29374; Sat, 11 Jul 1992 04:56:23 +1000 (from owner-Big-Internet) Return-Path: Received: from upeksa.sdsc.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29370; Sat, 11 Jul 1992 04:56:17 +1000 (from hwb@upeksa.sdsc.edu) Received: Fri, 10 Jul 1992 11:56:08 -0700 by upeksa.sdsc.edu (AIX/1.6) From: Hans-Werner Braun Message-Id: <9207101856.AA16832@upeksa.sdsc.edu> Subject: Digital Equipment Position on TUBA (fwd) To: big-internet@munnari.oz.au Date: Fri, 10 Jul 92 11:56:08 PDT (Forwarded with permission from the author) Forwarded message: >From root Fri Jul 10 10:29:34 1992 >Subject: Digital Equipment Position on TUBA >To: iab@ISI.EDU >X-Mailer: Poste 2.0B3 >From: lauck@tl.lkg.dec.com (Tony Lauck) >Date: Fri, 10 Jul 92 13:27:16 -0400 >Message-Id: <920710132716.7400@tl.lkg.dec.com> > >Ross Callon and Dave Oran have been participating in the ROAD >committee at the request of the IAB and Peter Ford, the ROAD group >chair. I asked them to participate on behalf of Digital Equipment >Corporation because I believed, and continue to believe, that a >solution to the routing and addressing problems associated with the >continued growth of the Internet is very important for the future of >computer networking. > >If requested by the Internet community, Digital Equipment Corporation >will continue to particpate in the refinement of the TUBA architectural >proposal and will participate in a prototyping effort of this proposal, >should such an effort commence under IETF auspices and should such an >effort include the development and interoperation of at least two >separate TUBA prototype implementations. We believe that this effort >should be targetted to a short term (4 to 6 month) demonstration. We >are prepared to develop one prototype implementation and to work with >other groups in the specification, implementation, and testing of >multiple interoperabile TUBA implementations. > >By participating in such a prototyping effort, Digital Equipment >Corporation does not indicate any interest or commitment to products >based on TUBA. Our product strategy regarding extenstions to IP >will be driven by the market demand for products and by which proposal, >or proposals, ultimately become Internet Standards. In this context, we >consider TUBA to be one contender among several. > > >Tony Lauck >Manager, Network Architecture >Digital Equipment Corporation >Littleton, Massachusetts From owner-Big-Internet@munnari.oz.au Sat Jul 11 06:34:44 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01886; Sat, 11 Jul 1992 06:35:18 +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 AA01875; Sat, 11 Jul 1992 06:34:44 +1000 (from craig@aland.bbn.com) Received: from port12.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA23100; Fri, 10 Jul 92 16:34:22 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA07144; Fri, 10 Jul 92 13:33:09 PDT Message-Id: <9207102033.AA07144@aland.bbn.com> To: big-internet@munnari.oz.au Subject: a chat with Vint Reply-To: Craig Partridge From: Craig Partridge Date: Fri, 10 Jul 92 13:33:09 -0700 Sender: craig@aland.bbn.com [hi folks -- a copy of this note is also going to IETF] Hi folks: I had a brief chat with Vint Cerf this morning and since Vint's on travel and finding it hard to get to a terminal, he suggested I send this note. What I'm trying to do here is summarize what I understood Vint to say his views were on the IPv7/CLNP issue. I take full responsibility for any errors in trying to represent Vint's views. What Vint understood himself to be approving at the IAB meeting in Kobe was a statement that the Internet community should consider whether there was merit in using CLNP as IPv7, *not* a statement that CLNP was the way to go. Vint's primary concern is ensuring the continued stable operation of the Internet and the networking protocols and services that use it. He believes we must move swiftly to confront the approaching technical problems of routing explosion and address depletion, and that we also need to start narrowing the set of approaches we pursue so that a solution will be in place when we need it. So insofar as CLNP might have proved a helpful starting point in encouraging us to start making hard choices about which approaches to pursue, it seemed like a reasonable thing to suggest. Finally, Vint noted that clearly the Kobe announcement had completely failed to convey these ideas. This conversation certainly gave me a more cheerful perspective on next week's IETF meeting. I hope you all find it equally cheering. Craig E-mail: craig@aland.bbn.com or craig@bbn.com From owner-Big-Internet@munnari.oz.au Sat Jul 11 07:13:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02939; Sat, 11 Jul 1992 07:13:27 +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 AA02930; Sat, 11 Jul 1992 07:13:15 +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 AA11179; Fri, 10 Jul 92 17:12:42 EDT Message-Id: <9207102112.AA11179@mitchell.cit.cornell.edu> To: Craig Partridge Cc: big-internet@munnari.oz.au Reply-To: swb@nr-tech.cit.cornell.edu Subject: Re: a chat with Vint In-Reply-To: Craig Partridge's message of Fri, 10 Jul 92 13:33:09 -0800. <9207102033.AA07144@aland.bbn.com> Date: Fri, 10 Jul 92 17:12:33 -0400 From: Scott Brim Astounding, considering that the IESG was already doing just that. From owner-Big-Internet@munnari.oz.au Sat Jul 11 10:18:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07117; Sat, 11 Jul 1992 10:18:56 +1000 (from owner-Big-Internet) Return-Path: Received: from crl.dec.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07110; Sat, 11 Jul 1992 10:18:32 +1000 (from callon@bigfut.enet.dec.com) Received: by crl.dec.com; id AA12291; Fri, 10 Jul 92 20:17:42 -0400 Received: by easynet.crl.dec.com; id AA15359; Fri, 10 Jul 92 17:02:01 -0400 Message-Id: <9207102102.AA15359@easynet.crl.dec.com> Received: from bigfut.enet; by crl.enet; Fri, 10 Jul 92 17:02:07 EDT Date: Fri, 10 Jul 92 17:02:07 EDT From: Ross Callon To: big-internet@munnari.oz.au, craig@aland.bbn.com Cc: callon@bigfut.enet.dec.com Apparently-To: big-internet@munnari.oz.au, craig@aland.bbn.com Subject: re: a chat with Vint Over the years I have attended 22 of the 23 IETF meetings, as well as 4 OSI meetings (and some number of ANSI meetings). It appears to me that there are a lot of similarities between both processes, and that in both forums the majority of folks participating have not had time to read the associated technical material (causing political decision making to be very dangerous). However the IETF process has one **enormous** advantage -- decisions are based on what has been implemented and shown to work. It has been my assumption all along that any "final decision" on what will be deployed would be based on real working systems and testing in the operational Internet. Thus, my reading of the IAB statement (to the extent that I have had time to read it, since I just returned today from a two week vacation) is: (i) They have looked hard at the problem (I already knew that several of the IAB folks have put a lot of time and effort into understanding the various technical proposals); (ii) They consider the problem to be very important (which again I already knew); and (iii) They feel that CIDR and TUBA and other proposals should be looked at seriously (without naming the other proposals). Thus I don't see what the big deal is: We are going to pursue multiple options; Which options are finally adopted will be based on what is shown to work. For a variety of reasons I personally feel that the TUBA proposal (combined with other orthogonal but compatible proposals, such as CIDR) is the most practical solution. However, I think that we need to spend our time demonstrating this, not arguing about whether or not it is true (although I am interested in reading the criticisms of TUBA in order to make sure that there are no hidden "gotcha's"). I take this as being compatible with Craig's recent discussion with Vint. Ross From owner-Big-Internet@munnari.oz.au Sat Jul 11 20:27:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17871; Sat, 11 Jul 1992 20:27:37 +1000 (from owner-Big-Internet) Return-Path: Received: from muri.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17867; Sat, 11 Jul 1992 20:27:34 +1000 (from kre) To: Big-Internet@munnari.OZ.AU From: Big-Internet-Request@munnari.OZ.AU Reply-To: Big-Internet-Request@munnari.OZ.AU Subject: You are a recipient of Big-Internet messages Date: Sat, 11 Jul 92 20:27:31 +1000 Message-Id: <2228.710850451@munnari.oz.au> Sender: kre@munnari.oz.au This is just to confirm (to everyone on the list) that you're listed as a recipient of Big-Internet list messages. If somehow some of you missed getting the "Welcome to the list" message, you can fetch a copy of it, if you want it, from the big-internet directory on munnari.OZ.AU [128.250.1.21]. Its in the file "Welcome". It contains details on how to fetch the list archives, etc. Should you want to be deleted from the list, or change your address, send a message to Big-Internet-Request@munnari.OZ.AU. Please check to make sure you aren't accidentally sending a copy of your message to Big-Internet@munnari.OZ.AU, which would result in its being broadcast to the list as a whole. If you don't recall asking to get this information, you may have been added to a local redistribution list at your site. If you have any queries about messages from the list, it would help if you could send the headers of a message you have received from it, that can help me track problems a lot sooner. Thanks, kre Big-Internet-Request@munnari.OZ.AU From owner-Big-Internet@munnari.oz.au Tue Jul 14 07:36:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11599; Tue, 14 Jul 1992 07:36: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 AA11587; Tue, 14 Jul 1992 07:36:02 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA00985; Mon, 13 Jul 92 17:35:46 -0400 Message-Id: <9207132135.AA00985@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Route fragments, a routing proposal From: David Clark Date: Mon, 13 Jul 92 17:35:46 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp Folks, Discussion at the IETF with Noel and others has prompted me to write down a proposal for how to do routing, and to send it out for comment. This idea came out of one of the routing architecture discussions, and it may have been discussed on this list already. If so, I apologize. (I dropped out of the addressing business for a while, and have not read the backlog...) Lots of people, including Chiappa's NIMROD proposal, have concluded that we need two sorts of names associated with end-point computing elements (in other words, "hosts" or some generalization). One name should be a UID, and the other should provide input to generating the route to the end-point. These latter names are often called addresses, since they suggest how a route can be derived but are not the route themselves. In this note I suggest a way of constructing these names that lead to routes. Instead of addresses, I call these names "route fragments", which suggests how they may be used. Some context: routes are either generated hop-by-hop, or all at once, which is sometimes called source routing. I too will say source routing, while noting that the generation does not have to happen at the literal source. Source routing has the advantage that it does not require routing consistency, which is key in a very large net. On the other hand, source routing requires that one place know all the necessary information, which does not scale if the routes are expressed at the detailed level. So most proposals for large scale routing provide for source routing at some abstract level, where it is still possible for the propagation of global information to succeed, and then make the route concrete (reduce the abstract decision to specific sequences of routers) on a hop-by-hop basis. Now here is the assumption that is the basis of my proposal. I know a lot about the networks near me, and you know a lot about the networks near you. Think about an analogy of routing in the streets and highways from my house to yours. I know how to get from my house to the freeway. You know how to get from the freeway to your house. So I provide the first part of the route, you provide the last part, I put them together to get the complete route I follow. Very specifically, let us imagine that in the DNS, we store the UID for a end-point, and additionally a number of "route suffixes". A route suffix is simply the tail of a route that terminates on the identified end-node. When I look up a host name in the DNS, I get back the UID as well at the route suffixes. To make a route, I look at these, as well as the knowledge local to me. These "route prefixes" are obviously just the reverse of the suffixes that I advertise in the DNS for me. To over-simplify, I find a prefix and suffix that "meet in the middle" (that is, which share a common name between them) and which meet the policy requirements. I put them together, and at relatively low computational cost, I get a complete route. (Yes, that was oversimplified, but please give me a paragraph or two.) At what level of abstraction should these route fragments be expressed? One view is that the level of abstraction should be variable, since flexibility here is key (I think this is Noel's view). I find that a concrete proposal is easier to understand, so I would propose that route fragments be sequences of AD names. By AD I mean a separately administered collection of networks, for example a campus like MIT, a regional like NEARnet, or a long-lines provider like NSF. I leave to each AD as a private matter the generation of the physical route from entry to exit, and control by source routing the choice of ADs. So: an example using MIT as a end-point: Host: ginger.lcs.mit.edu Route fragments: NSF>NEARnet>MIT ATT>NYNEX>MIT MCI>NYNEX>MIT ESnet>MIT and so on. So if I am at Stanford, and I have a fragment for me that reads: NSF>BARnet>Stanford, then by finding that MIT has a fragment that has NSF in it, I get the complete route of: MIT>NEARnet>NSF>BARnet>Stanford. Comment 1: In finding a route it is not necessary to look only at the "end" of the fragment. If I am trying to get to MIT, and I see NSF>NEARnet>MIT, and I know directly how to route to NEARnet, then I can make a route directly to that AD. Comment 2: These fragments can be qualified with policy requirements such as appropriate use. This will allow the composition of routes that meet particular needs. Now to the major over-simplification that I ignored above. What happens if my fragments and your fragments do not reach far enough into the Internet to "meet" each other? If I am trying to reach the other side to the globe, this is very likely. What then? The answer is "route middles", which go with prefixes and suffixes. Route middles are provided by long-lines carriers, and represent their agreements to provide service. So if NSF is the academic carrier for the U.S., and EURO (I made something up) is the academic carrier for Europe, and they directly provide interconnect, then they would advertise a "route middle" of: >NSF>EURO>. Now to make a route I need three pieces of information: I need local information I provide myself. I need the remote version of that information that I get from the DNS, and I need the route middles I get from the "transit network route service". Transit services do not come and go second-by-second, so this data can be retrieved and cached (sure, there are details here.) What is the practical optimization here? What is the presumed simplification? Construction of a global mesh of abstract links, even at the AD level, may not scale well enough for the global Internet. What we need is to use local knowledge to prune the search options. Transit network know that they are transit nets, end points know they are end points, and so on. The structure proposed here allows this knowledge to be provided in a way that is easy to manipulate. At the same time, this scheme allows us to avoid any assumption in the addresses that there is a single addressing hierarchy, as NIMROD proposes in its basic scheme. This idea admits that ADs do not exist in a hierarchy, but in a full mesh. Effective routing depends on using this full mesh. This proposal allows a full mesh, but structures it in a way to control the complexity of finding routes. Final comment: To make this sort of scheme work, we presume that routers know how to deal with source routes. This is a matter that I would leave to another note, or to some other proposal such as NIMROD. But I want to recognize that the proposal depends on this idea. Dave Clark From owner-Big-Internet@munnari.oz.au Tue Jul 14 13:13:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21982; Tue, 14 Jul 1992 13:13:14 +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 AA21973; Tue, 14 Jul 1992 13:13:04 +1000 (from estrin%caldera.usc.edu@usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA05652; Mon, 13 Jul 92 20:12:59 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA26200; Mon, 13 Jul 92 20:12:57 PDT Date: Mon, 13 Jul 92 20:12:57 PDT Message-Id: <9207140312.AA26200@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin%caldera.usc.edu@usc.edu To: big-internet@munnari.oz.au Subject: Clark's route fragments Reply-To: estrin@usc.edu I fully agree that your concept of route fragments should be used to facillitate route computation as part of any inter-domain source-route mechanism (be it IDPR, Nimrod, or SDRP component of Unified) To extend the route fragment concept even further, we can treat IDRP/BGP computed AD paths as route fragments also. And at the same time, one gets the efficiency of efficiently-computed generic routes; i.e., our old argument for "Unified", instead of source specific routes as the only mechanism, goes here... One question of clarification, How does this version of route fragment mechanism differ from that which I remember from a couple years ago? Are you suggesting that now transits may advertise fragments in addition to simply the direct AD neighbor informatoin that is distributed in the usual link-state/IDPR approach? (I could not tell from your BB-Euro example because the BB could be just advertising its direct neighbor AD link. ) These route middles could also be taken from the BB's IDRP/BGP routing information. In Unified we want to develop the idea of collecting this information on demand and avoid global distribution; is that also what you had in mind? you said this explicitly re. you route prefix/suffix (you get it on demand when you contact the DNS), but did not say re. the route middles... D. From owner-big-internet@munnari.oz.au Tue Jul 14 13:25:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22414; Tue, 14 Jul 1992 13:25:25 +1000 (from owner-big-internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20428; Tue, 14 Jul 1992 12:19:37 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Mon, 13 Jul 92 22:19:23 EDT Received: by chiya.bellcore.com (4.1/4.7) id for ddc@lcs.mit.edu; Mon, 13 Jul 92 22:19:21 EDT Date: Mon, 13 Jul 92 22:19:21 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207140219.AA07765@chiya.bellcore.com> To: big-internet@munnari.oz.au, ddc@lcs.mit.edu Subject: Re: Route fragments, a routing proposal Dave, Good to have you back on the net. Seems it's been a while since I've seen "ddc" (but, I guess you have been on the net, just not on the lists I've been reading). A few comments..... 1. Your proposal works just fine with Pip, and in fact your glued together route fragments look exactly like some of my routing directive examples (MIT>NEARnet>NSF>BARnet>Stanford....start at "bottom" going up, then go down again). Perhaps a difference is that in my examples, the number that represents say MIT is significant only in the context of NEARnet's number. That is, it really is hierarchical in the sense of number assignment. Pip will also work just fine if the numbers are all globally unique, you just end up with a larger (perhaps substantially so) header. (Of course, you also end up with fewer number assignment headaches). 2. I think that there is room for hop-by-hop routing in the context of route fragments. In general, you only have to put in a source route when 1) hop-by-hop routing is not sufficient to get you there (ie, NSFnet does not know how to route to MongoliaNet), or 2) there are multiple choices hop-by-hop could make and you want to force one of them. I believe that hop-by-hop routing has certain advantages, such as freeing up the source from making a decision (if the source doesn't care or doesn't have a choice), and allowing the middle to make local decisions that optimize things for it. In short, hop-by-hop routing can save thr source from having to worry about the middle part of the route in those cases where the source doesn't care or has no choice. 3. I also want to comment (I know this is nothing more than a bald-faced plug for myself, but I can't help it) that having multiple route-fragments has certain similarities to the multiple hierarchical addresses thing I wrote for Zurich sigcomm. The main difference is that in that work, I tried to stay completely in the context of existing header and address structures, whereas you (and Pip) are being completely general about it (which is a great improvement). Anyway, I think the key is having multiple of these things (route fragments or addresses). 4. Finally, I hope people start thinking a bit about destination-based policies (a real-life example of which is 800 numbers). When a destination advertizes its route fragments, it might want to also provide an indication of what its policies are with respect to those fragments (or just not mention those it doesn't want used in a particular case). It might also want to advertise what QOS is available with various route fragments. PT From owner-Big-Internet@munnari.oz.au Tue Jul 14 15:46:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27642; Tue, 14 Jul 1992 15:46:23 +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 AA27633; Tue, 14 Jul 1992 15:46:12 +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 2224; Tue, 14 Jul 92 01:44:52 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 2250; Tue, 14 Jul 92 01:44:51 EDT Date: Tue, 14 Jul 92 01:40:05 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Route fragments, a routing proposal To: David Clark , big-internet@munnari.oz.au In-Reply-To: <9207132135.AA00985@ginger.lcs.mit.edu> Message-Id: <920714.014005.EDT.VALDIS@vtvm1.cc.vt.edu> On Mon, 13 Jul 92 17:35:46 -0400 you said: >Host: ginger.lcs.mit.edu > >Route fragments: > >NSF>NEARnet>MIT >... > >and so on. So if I am at Stanford, and I have a fragment for me that >reads: > >NSF>BARnet>Stanford, then by finding that MIT has a fragment that has >NSF in it, I get the complete route of: > >MIT>NEARnet>NSF>BARnet>Stanford. Yow. bang-paths live again. ;) Who's gonna port Pathalias to a cisco router? Only half a smiley here - the final routing architecture could end up looking a LOT like pathalias. I think Pathalias already has policy routing? ;) Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Tue Jul 14 20:30:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05347; Tue, 14 Jul 1992 20:31:31 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207141031.5347@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05314; Tue, 14 Jul 1992 20:30:27 +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 ; Tue, 14 Jul 1992 11:29:27 +0100 To: David Clark Cc: big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal In-Reply-To: Your message of "Mon, 13 Jul 92 17:35:46 EDT." <9207132135.AA00985@ginger.lcs.mit.edu> Date: Tue, 14 Jul 92 11:29:21 +0100 From: Zheng Wang Route fragments routing seems to be similar to the hierarchical routing used in Pip etc. You actually need the concept of hierarchy so that you know where to stop when you specify the addresses. In fact, if you take subnet as a further hierarchy, the current IP uses the same hierarchical routing (with two-level hierarchy). Source IP address = subnet1>net1>internet destination IP address = subnet2>net2>internet Note that the ">internet" above is not necessary as both net1 and net2 are part of the internet (the top hierarchy). What we need is more levels of hierarchy in the "internet" part so that further abstraction can be achieved. >I get the complete route of: > >MIT>NEARnet>NSF>BARnet>Stanford. If NSF is the only top hierarchy, "NSF" in the above route may not be necessary. Hierarchical routing is, in some sense, a type of source routing. But it is different from the definition of source routing in IP (ie. loose source routing and strict source routing). (Some people were confused when Paul Tsychiya called his route directive source routing at a talk here. They thought that the route is simply a list of all routerIDs from source to destination.) We have to distinguish two types of source routing: 1) "concrete source routing" - that specifies the nodes that must be visited. 2) "abstract source routing" - that specifies the nets that must be visited. Hierarchical routing is a type of abstract source routing in which the networks are arranged in hierarchy. Cheers Zheng From owner-Big-Internet@munnari.oz.au Tue Jul 14 23:28:12 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08817; Tue, 14 Jul 1992 23:29:32 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08728; Tue, 14 Jul 1992 23:28:12 +1000 (from dave@japan.bellcore.com) Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA06559; Tue, 14 Jul 92 09:30:38 EDT Return-Path: Received: by japan (4.1/4.7) id AA07882; Tue, 14 Jul 92 09:14:49 EDT Date: Tue, 14 Jul 92 09:14:49 EDT From: dave@sabre.bellcore.com (Dave Piscitello) X-Station-Sent-From: japan.bellcore.com Message-Id: <9207141314.AA07882@japan> To: big-internet@munnari.oz.au Subject: Re: IAB proposal for CIDR and IPv7 >My guess is that you can take any number of random phrases from the IAB's >Internet-draft and make it sound "moderate". However, if you take it as >a whole, I will observe that: > >1. They dismiss the other proposals. > >2. They do not provide an analysis of the benefits and cost-distribution > of each of the proposals. My "moderate" interpretation is that they encouraged the IETF to pursue one; if you choose to say "dismiss", do so. I will and have agreed that (2) and the absence of comparative analysis was unfortunate and seriously undermined their efforts; *if* I had been involved, I might have suggested a more complete proposal and a different timing (are you surprised to find I was not part of a secret cabal? sorry, I'm not good at that sort of thing) >... Faith will not prevent the "two >versions of CLNP" problem. Faith will not prevent the marketing slime >trying to take advantage of this decision. (I notice you didn't even >try to defend against that prediction.) Hard work and cooperation will prevent the first; absolutely nothing you or I do will ever prevent the latter. I didn't defend against your "prediction" because I doubt whether the slime will have any long lasting effect, it hasn't since the early 1980s. >My only suggestion is that you open your eyes and figure out what's >going on. As individuals, the IAB members may be good people. That is >not the issue. The issue is that as a group, they have, to my mind, >demonstrated themselves to be "a clear and present danger" to the >Internet community. Me thinks it is time for a system which >incorporates the notion of accountability -- something that the present >system, which you have so much faith in, is sorely lacking. I'm a poor defense attorney; I'm probably worse as judge and jury; you can take this responsibility, I don't want it. >If this is the best defense you can mount for the IAB's apparent malfeasance, >then they had better get another attorney. I began an unsolicited defense of the IAB because I think we can cooperatively come to a better understanding if no one feels the presence of a knife to his/her throat. Between this and the natural "guilt by association", I suppose I should have looked first to the knife at my throat. I remain unconvinced that malfeasance exists, and hope for kinder jurors than you. From owner-Big-Internet@munnari.oz.au Wed Jul 15 01:17:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12215; Wed, 15 Jul 1992 01:18:19 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12191; Wed, 15 Jul 1992 01:17:13 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04330; Tue, 14 Jul 92 11:16:42 -0400 Message-Id: <9207141516.AA04330@ginger.lcs.mit.edu> To: estrin@usc.edu Cc: big-internet@munnari.oz.au Subject: Re: Clark's route fragments In-Reply-To: Your message of Mon, 13 Jul 92 20:12:57 -0700. <9207140312.AA26200@caldera.usc.edu> From: David Clark Date: Tue, 14 Jul 92 11:16:41 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp Deborah, Yes, my example was a little simple. I was proposing that route middles could be long fragments, not just next-neighbor fragments. And I agree totally that a route computation like IDRP/BGP could be the source of route middles. They could be computed in advance and provided on demand. Paul T. also observed that my note was not clear on generic routes. I agree that for default routes you want a very efficient method for route instantiation. I tend towards the idea (which I think you share) that these routes would be hop-by-hop, reserving source routes for special problems. But in the long run, I think that routes to distant and unknown parts of the network may be simple forms of source routes, since this will prune what the routers have to store in their active routing tables "just in case". My thinking about this stuff has not changed much in two years. Its just that I had another talk with Noel about Nimrod. He still believes that the fundamental structure of Nimrod is that end-points have one "address" (the thing that is input to the route generation process). This leads to his hierarchy of regions, which I have never liked. So I was motivated to write this down. Dave From owner-Big-Internet@munnari.oz.au Wed Jul 15 03:36:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17640; Wed, 15 Jul 1992 03:37: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 AA17632; Wed, 15 Jul 1992 03:36:56 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06427; Tue, 14 Jul 92 13:36:48 -0400 Message-Id: <9207141736.AA06427@ginger.lcs.mit.edu> To: Paul Tsuchiya Cc: big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal In-Reply-To: Your message of Mon, 13 Jul 92 22:19:21 -0400. <9207140219.AA07765@chiya.bellcore.com> From: David Clark Date: Tue, 14 Jul 92 13:36:47 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp Paul, I think that several of these ideas do look a lot alike, And perhaps the problem has to do with the word "hierarchy". So let me try this carefully. Hierarchy is a kind of structuring. I think that we all agree that we need structure. But is hierarchy the right structure? The problem is that hierarchy is so obvious a structure that we tend to fall back on its terminology when it is not exactly what we mean. So: in a proper hierarchy there is one root. Hierarchy properly describes the management structure of the church, and there is one pope. Things with more than one root are not hierarchies. The early church very carefully killed anyone who thought that. I am not trying to commit a heresy, or get killed. But I am proposing a structure for which I have neither a name or a formal definition. So let me offer a name. "Polyarchy". (I think that is properly compounded from the Greek; my wife is not home to ask.) What is a polyarchy? It is like matrix management. Or the phone system after divestiture. There are things at the top of the structure (or, in network terms, the center), but there are multiple of them. Think: ATT, MCI, Sprint... But there is still a strong idea of structure. It is not a simple fully connected graph. It has explicit structure, such as: things at the bottom, or edge, do not perfmorm transit routing. And it has exceptions to the structure. As does the phone system of today. Think: bypass, private networks, etc. So what we have to do in our routing is to find some way to express and reason about (compute routes in) a polyarchy. My route fragments do that. Essentially, each route middle represents a potential "top of the polyarchy" to which an AD can connect. And each route suffix represents a decision by an end AD to join the polyarchy in a particular way. Each such route represents a different decision; there can be many. When Noel says hierarchy, he does not mean polyarchy. I remember discussing this with you at Zurich, and I was unsure where you stood. It is quite possible that we are in agreement. But note: -- I think that the AD number (e.g. the number for MIT) must be global exactly because in a polyarchy, since there are multiple "up links", you cannot presume to use a single uplink to find a context to disambiguate the name. All of the nodes "above" you in the polyarchy must be able to resolve your name. BTW: I think that things like 800 services are an excellent example of how we can do "value aded" routing once we have a basic structure in place that permits "specialty routing" such as source routing. The way 800 routing would work is that when the user contacts the DNS to reach some service, a record comes back with route fragments plus an additional note that the recipient will pay the network charges if he is allowed to compute the route. Either the network company or a third party will offer the service of buillding the route to the needs of the service being called, and it all fits in. The key is not to think that we must architect the "one way" that things like 800 will be done. The key is to see the next generation of packet forwarder as a mechanism into which routes can be injected by a number of means. If the interface is open, then the means can be invented as needed. Dave From owner-Big-Internet@munnari.oz.au Wed Jul 15 03:48:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18715; Wed, 15 Jul 1992 03:48: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 AA18703; Wed, 15 Jul 1992 03:48:50 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06526; Tue, 14 Jul 92 13:48:46 -0400 Message-Id: <9207141748.AA06526@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Building routers for the routing of tomorrow In-Reply-To: Your message of Tue, 14 Jul 92 11:29:21 +0100. <9207140629.aa16363@mintaka.lcs.mit.edu> From: David Clark Date: Tue, 14 Jul 92 13:48:45 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp From owner-Big-Internet@munnari.oz.au Wed Jul 15 05:05:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24680; Wed, 15 Jul 1992 05:05: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 AA24677; Wed, 15 Jul 1992 05:05:15 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA06992; Tue, 14 Jul 92 15:05:10 -0400 Message-Id: <9207141905.AA06992@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Building routers for the routing of tomorrow -- 2nd try From: David Clark Date: Tue, 14 Jul 92 15:05:09 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp Oh drat... The body was missing on the first sending. Sorry. Folks, Here is a suggestion for a change we should make in the next generation IP header. It has the goal of speeding up the forwarding code in the routers, dealing with new routing objectives such as source routing, and new TOS such as application-level resource setup. Today, the forwarding code takes the destination address (the 32 bit thing) out of the header, and uses this to find the next hop address. This lookup can involve a "routing table" or, more commonly, a cache of recently used destination addresses. Perhaps the destination is hashed to find some index which is then used to enter the table. In the future, this is going to get more complex for several reasons. First, addresses are going to get longer, if not variable length. Second, not all packets to the same destination will use the same next hop, and third, different packets to the same destination will require different TOS queueing. To provide this sort of "fine-grained" routing, the router must look at more than the destination. One approach, which has been used in experimental routers today, is to provide the router with a series of packet mask/value pairs: the mask is used to select the needed fields in the packet, which are then compared to the value. This is used on source/destination host address pairs to support access control, and (peaking up to the TCP port numbers) to provide TOS distinctions for classes of traffic such as Telnet, or specific application flows such as real-time audio or video streams. This works, but requires "layer peaking" and is potentially an efficiency concern. So this problem should be considered in a future IP header. One solution, is to go to a full-fledged connection model. (Sigh) Then the actual packets of the connection just carry the connection ID, and the router just looks that up. This might make sense for the restricted case of application-specific resource allocation, but does not relate well to our connectionless cultural history. Is there a half-way point? The half way point is to have the source put a "connection index" or CI in the packet without actually doing any connection setup. (Since we do no connection setup, the name "connection index" is wrong; we need some other name like "connectionless index", or CI.) What is this CI, and how does it help? The rule for the source is that the source is to assign a distinct CI for each sequence of packets that can be usefully discriminated inside the network in any way. So each TCP connection would have a distinct CI, as well as any flow of UDP packets on behalf of a application. Packets in one TCP stream with different TOS would use a distinct CI, and so on. The rule for the source is use the CI in as fine-grained manner as reasonable. Now what does the router do? It presumes that the CI values are uniformly distributed from the range of values; when it gets the packet, it uses the CI as a hash index into a table. [In detail, one implementation would be to mask off some number of CI bits, use this as an index, and then look at the full CI and source address to see if it found the correct entry.] If it finds an entry, that entry contains the next hop and TOS queueing information. If it finds no entry, it makes one, using whatever management and header information it has. (In other words, what it would have done if we did not have the CI concept.) One way to think about this is to observe that most routers compute a hash function of some packet fields to forward the packet. Since every router does this, why not have the source pre-compute this function and put it in the packet? But of course, in this case the value need not be a literal hash of the packet fields so long as it is randomly distributed across its value range and so long as the source has not used the same CI for packets that require different treatment. So the source puts this "pseudo-hash" in the header, and then each router does what it wants with it, including ignore it. In this context, how does source routing or resource reservation work. If those services are required, then the source (or its agent) sends out a suitable message (TBD) that provides the proper information and the CI. The router caches this, creates the proper control information, and waits for the packets to come. Should we admit that this is really a connection setup? Well, there are two ways to think about it. One is to observe that the CI allows a range of behavior, from fully connection to fully connectionless, using the same packet forwarding code. But I would prefer the view that even this model of source routing is not a real connection. Instead of asking the router to maintain hard state (state that survives a crash) to reflect these reservations, what is needed is a simple flag in the header (it could be one value of the TOS field) which means: "the router should already have a control block for this value of the CI". If the router does not, then instead of setting one up, it should send an ICMP "recreate the CI state" message back to the source. This deals with route changes, router crashes, and so on. This mechanism is very simple. It permits a wide variety of routing schemes to be put in on "top of" this simple packet header. Schemes can co-exist that derive the route from the header, that get it from a route server, and that get it from a management interface. For any sequence of packets, it provides a uniform forwarding cost for all but the first packet or the setup packet. And finally, it can be deployed before we know exactly how we will do source routing, or real-time, or whatever. It allows us to change the IP header now, and then fill in new function later using header options to carry the setup info, or a new kind of packet (e.g. ICMP resource request), or SNMP. To make this efficient, the following details help. The CI is disambiguated using the source address. It would help if the source had some fixed length UID that it put in the packet, to make the comparison efficient. The CI must be big enough to separate all the simultaneous flows from a source. 16 bits seems a minimum size. The values that the source selects for the CIs must be uniform across the range of 2**16 or whatever. Small integers would be easier for the source to assign but would mess up the hashing efficiency. It is interesting to compare this CI scheme to connection schemes such as B-ISDN. B-ISDN uses a 24 bit VCI that is smaller than our 32 bit IP address. Since this is too small for global uniqueness, they require a full connection setup so that the VCI can be made unique for each link. It is claimed that this is more efficient, since the field is smaller and the lookup is more efficient. I claim that my scheme is very close in efficiency, and much more general. They have the option of a direct lookup, since the standard says to use the VCIs "compactly". But one may easily find that a level of indirection is needed. In my scheme, the CI is masked to a suitable size (this is a router-specific decision as to the proper "compactness" of the table), then we require one level of indirection to reach the hash bucket, and then a comparison with the full CI and the source address is needed. This is a few memory operations and comparisons. From this cost I get semantics that supports connectionless service (plain old datagram service, or PODS), source directed routing, and resource reservation which almost feels like a full connection. Thoughts? Dave Clark From owner-Big-Internet@munnari.oz.au Wed Jul 15 05:07:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24898; Wed, 15 Jul 1992 05:07:48 +1000 (from owner-Big-Internet) Return-Path: Received: from EMU.NCSL.NIST.GOV by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24880; Wed, 15 Jul 1992 05:07:38 +1000 (from colella@emu.ncsl.nist.gov) Received: by emu.ncsl.nist.gov (4.1/NIST(rbj/dougm)) id AA09837; Tue, 14 Jul 92 15:08:55 EDT Date: Tue, 14 Jul 92 15:08:55 EDT From: Richard Colella Organization: National Institute of Standards and Technology (NIST) Sub-Organization: Computer Systems Laboratory (CSL) Message-Id: <9207141908.AA09837@emu.ncsl.nist.gov> To: ddc@lcs.mit.edu Subject: Re: Route fragments, a routing proposal Cc: big-internet@munnari.oz.au Dave, > > offer a name. "Polyarchy". (I think that is properly compounded from the > Greek; my wife is not home to ask.) What is a polyarchy? It is like matrix > management. Or the phone system after divestiture. There are things at the > top of the structure (or, in network terms, the center), but there are > multiple of them. Think: ATT, MCI, Sprint... But there is still a strong > idea of structure. It is not a simple fully connected graph. It has explicit > structure, such as: things at the bottom, or edge, do not perfmorm transit > routing. And it has exceptions to the structure. As does the phone system > of today. Think: bypass, private networks, etc. > Sounds something like a partial order with cross-connects. --Richard From owner-Big-Internet@munnari.oz.au Wed Jul 15 06:59:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01574; Wed, 15 Jul 1992 06:59:35 +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 AA01568; Wed, 15 Jul 1992 06:59:29 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07828; Tue, 14 Jul 92 16:59:25 -0400 Date: Tue, 14 Jul 92 16:59:25 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207142059.AA07828@ginger.lcs.mit.edu> To: ddc@lcs.mit.edu, tsuchiya@thumper.bellcore.com Subject: Re: Route fragments, a routing proposal Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Noel is not positive he doesn't mean polyarchy. I talked at some length about partial addresses not having meaning except in the local context in which they are unique; this in some sense is just a different way to describe polyarchy. It might be that a polyarchy is a better way to represent the kind of complex interactions we wil get in the networking world; I will think about this. Noel PS: Polyarchies remind me in a way of Tassos' up-down stuff; is there a connection here? From owner-Big-Internet@munnari.oz.au Wed Jul 15 06:56:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01461; Wed, 15 Jul 1992 06:56:30 +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 AA01457; Wed, 15 Jul 1992 06:56:20 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07791; Tue, 14 Jul 92 16:56:15 -0400 Date: Tue, 14 Jul 92 16:56:15 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207142056.AA07791@ginger.lcs.mit.edu> To: ddc@lcs.mit.edu, estrin@usc.edu Subject: Re: Clark's route fragments Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu He still believes that the fundamental structure of Nimrod is that end-points have one "address" No, no, NO! Let's get our terminology straight, or we won't know when we agree and when we don't. 'Endpoints' are end-end/fate-sharing locales; think of an endpoint as one end of a TCP connection. Endpoints names are 'identifiers', which tells you nothing about where it is in the network, etc, etc; it's simply a globally unique binary string (probably shortish fixed length). Each endpoint has one identifier (probably, no good reason to do otherwise?). Network interfaces are another fundamental object class. They have names, called 'addresses' (only for lack of a better term :-) which are structured, and the structure is related to the network topology. Endpoints do not have addresses, the only kind of names they have are identifiers. The mapping from the obkjects of this class of object (and their names, identifiers) to the interface class of object (and their names, i.e. 'addresses'), is very flexible. One endpoint can have mutiple interfaces (thus multiple addresses), e.g. multi-homed host, or several endpoints can be at a single interface (thus a single address), e.g. a MIMD multi-processor. Now, separately from all this, and what I think you really meant, but is now out of date, is that an interface can have several addresses. I feel that the use to which these multiple addresses can be put should bea limited. I do not want to use them for doing policy. I will use them for allowing easy reassignment of addresses as topology changes. One thing I am not yet sure about is allowing users to make more interlligent choices about how to get the address; i.e. the case you always cite with MIT and regionals. In the '91 Nimrod spec, multiple addresses is explicitly listed as a possible way to do this optimization, although it is sort of deprecated, see section 6.3. In conversation in the Nimrod BoF second session today, I came up with a clearer argument as to why this may not be a good idea, and I'll type it in when I get to a better keyboard. In the meantime, if I misunderstood what you were trying to say, please redo it with the terminology above (unless you think I've made bad choices for the object classes to name and the form of their names, in which case we can argue about that :-)! Noel From owner-Big-Internet@munnari.oz.au Wed Jul 15 07:04:45 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01764; Wed, 15 Jul 1992 07:04: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 AA01759; Wed, 15 Jul 1992 07:04:45 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07937; Tue, 14 Jul 92 17:04:41 -0400 Date: Tue, 14 Jul 92 17:04:41 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207142104.AA07937@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, ddc@lcs.mit.edu Subject: Re: Building routers for the routing of tomorrow -- 2nd try Cc: jnc@ginger.lcs.mit.edu I was assuming that flows in Nimrod would look a lot like this in many ways; the only minor twinge I could add would be that the flow would in fact be globally uniquely identified by the concatenation of the source endpoint id and a locally (i.e. within the endpoint) unique flow id. Since the source ep-id would be a shortish binary string (probably fixed length), this would make a very convenient cache tag. Noel From owner-Big-Internet@munnari.oz.au Wed Jul 15 12:36:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12808; Wed, 15 Jul 1992 12:36:40 +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 AA12803; Wed, 15 Jul 1992 12:36:34 +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 AA01023; Tue, 14 Jul 1992 22:36:21 -0400 Received: by walrus (5.4.1/140.2) id AA09894; Tue, 14 Jul 1992 22:33:46 -0400 Date: Tue, 14 Jul 1992 22:33:46 -0400 From: throop@dg-rtp.dg.com (Dean D. Throop) Message-Id: <9207150233.AA09894@walrus> To: big-internet@munnari.oz.au Subject: Re: Clark's route fragments > From: jnc@ginger.lcs.mit.edu (Noel Chiappa) > Message-Id: <9207142056.AA07791@ginger.lcs.mit.edu> > Subject: Re: Clark's route fragments > ... > > 'Endpoints' are end-end/fate-sharing locales; think of an endpoint as > one end of a TCP connection. Endpoints names are 'identifiers', which tells > you nothing about where it is in the network, etc, etc; it's simply a globally > unique binary string (probably shortish fixed length). Each endpoint has one ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ They can't be too short because the number space will have to be divided to allow distributed assignment of identifiers. > identifier (probably, no good reason to do otherwise?). Network interfaces are > another fundamental object class. They have names, called 'addresses' (only > for lack of a better term :-) which are structured, and the structure is > related to the network topology. ... Dean Throop throop@dg-rtp.dg.com From owner-Big-Internet@munnari.oz.au Wed Jul 15 13:49:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15506; Wed, 15 Jul 1992 13:49: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 AA15500; Wed, 15 Jul 1992 13:49:15 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA14444 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 15 Jul 1992 13:49:32 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA04385; Wed, 15 Jul 92 13:49:12 EST Message-Id: <9207150349.AA04385@wanda.mel.dit.CSIRO.AU> To: David Clark Cc: big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal In-Reply-To: Your message of "Tue, 14 Jul 92 13:36:47 -0400." <9207141736.AA06427@ginger.lcs.mit.edu> Date: Wed, 15 Jul 92 13:49:11 +1000 From: Bob Smart >Paul, > I think that several of these ideas do look a lot alike You're darn tootin! There are 3 threads in this debate: CLNP; hack into IP4 to extend the address space; ID+address. The ID+address people agree on much more than they seem to think they do: 1. We need what Zheng calls "abstract source routing" at times. In some scenarios this is only for flow setup, though in mine it is the normal mode of address specification. 2. Hop-by-hop is still important within routing domains, and between them at the top level. Well you can regard the latter as a special case of the former by saying there is a top level routing domain. 3. Flows with possibly attached resources is going to be an important mode in the future. To look at some differences Dave Clark has highlighted: a. Hierarchy or all routing domains at the top level? Even Dave would like to preserve the net/subnet distinction. The question is do we need more levels? To me the answer is obviously yes. There is no need for MIT to have a globally unique number: the problem of it having different numbers under different higher levels is handled easily in the DNS - I have a simple proposal. MIT is obviously big enough that a top level number is not silly, but what about XYZ Boot Repairs with one PC? The fact that there are different levels in the address space in PIP doesn't impose any restrictions on how things are connected or packets are routed, though it does define a default routing. b. PIP currently has a flow mode where flow identifiers are small but are changed at each router. This is similar to the way ATM works. Dave has proposed a globally unique flow identifier consisting of the host identifier + host-unique number. To put this in Pip just requires allowing tables with large indices which are accessed by a hash table [currently I think it is envisaged that all tables are accessed by indexing]. This is not a big change to Pip. One of the paradoxes of the debate is that the ID+address plans can use the IP4 address as an ID. This has the potential to allow hosts running old IP4-only software to hang around the edge of the new network WITH FULL CONNECTIVITY for as long as 32 bit IDs survive. Yes folks, ID+address is the true "backward compatible" solution. Figuring out the packet format and the forwarding engine is not the hardest part of the job. I reckon if we locked Dave and Noel and Paul in a room in the morning we'd see a puff of white smoke before lunch. PIP has been designed to handle the 3 modes listed above. It has been designed to be a minimal design that does all of them. If people think it can be done more simply they owe us more than hand-waving arguments. Dave Clark is one of the most respected figures in Internet engineering and his appearance on the side of ID+address is most welcome. In my capacity as a random list member on the other side of the planet I'd like to nominate him as the leader of the ID+address proposal. If we don't get some unity into the ID+address side of the argument soon the chances of overturning the IAB's semi-decision for CLNP are low. Bob Smart P.S. A new protocol separating ID and address need not estrange us from the OSI community. I believe they would follow with a similar protocol very soon. If we could take some of their concerns into account we might be able to devise a protocol they would accept as-is. From owner-Big-Internet@munnari.oz.au Wed Jul 15 15:04:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18447; Wed, 15 Jul 1992 15:04:46 +1000 (from owner-Big-Internet) Return-Path: Received: from dscs.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18444; Wed, 15 Jul 1992 15:04:40 +1000 (from medin@nsipo.nasa.gov) Received: Tue, 14 Jul 92 22:03:30 PDT from localhost.arc.nasa.gov by dscs.arc.nasa.gov (4.1/1.5T) Message-Id: <9207150503.AA06478@dscs.arc.nasa.gov> To: Bob Smart Cc: David Clark , big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal In-Reply-To: Your message of "Wed, 15 Jul 92 13:49:11 +1000." <9207150349.AA04385@wanda.mel.dit.CSIRO.AU> Date: Tue, 14 Jul 92 22:03:30 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Bob, I guess you didn't hear this, but Vint Cerf Monday morning basically retracted the IAB position. They are now supporting the IESG position, and he said that the IAB has learned not to try and enforce stuff from above. The messages I got about his speech had the subject line of "IAB shows the White Flag..." Vint said that the object of the I-D was not to set policy but simply have a document about the CLNP approach which could be compared against documents of other proposals. I wasn't there, but my boss in NASA was asked to delay his speech at the IETF plenary so that Vint could give his speech. Perhaps somone on the IAB could fill us on all the details of the retraction. Or someone who was there Monday morning to hear it. Apparently Vint did a strip tease until he took off his shirt to reveal an "IP over everything" T-shirt underneath. I also heard Marshall Rose has T-shirts of his own there, something about ISO (Silent C) + IAB = IPv7, and "Toasting politically correct internetworking", - Inet 92, Kobe... Sounds like a lot of fun. Tune in to the IETF audio multicast Thursday night. Should be - er... - fun. Thanks, Milo PS Anyone in Boston care to correct or add to this note? From owner-Big-Internet@munnari.oz.au Wed Jul 15 15:28:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19316; Wed, 15 Jul 1992 15:29:12 +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 AA19304; Wed, 15 Jul 1992 15:28:50 +1000 (from estrin%caldera.usc.edu@usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA06149; Tue, 14 Jul 92 22:28:41 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA04500; Tue, 14 Jul 92 22:28:41 PDT Date: Tue, 14 Jul 92 22:28:41 PDT Message-Id: <9207150528.AA04500@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin%caldera.usc.edu@usc.edu To: big-internet@munnari.oz.au Subject: small question/clarification re. ddc idea and state Reply-To: estrin@usc.edu Simple destination based forwarding aggregates state info in the router by definition; no matter where you come from kthe router just bothers with the destination. Dave, I assume that the way you avoid proliferation of state requirements (O(N^2) in routers is by treating CI entry like a cache and if you toss an entry out, that is ok because you can route the next packet anyway? Or does this small amount of state per active src-dst pair not bother you to begin with? also... just an aside... but speaking of B-ISDN they are having problems because of the small VCI space and the absence of source ID when it comes to multicast so that argues for the src+id approach; on the other hand it is not really a fair comparison since comparing IP and B-ISDN is a bit apples and oranges...or maybe oranges and orange-sections... From owner-Big-Internet@munnari.oz.au Wed Jul 15 17:53:55 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23645; Wed, 15 Jul 1992 17:54:14 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207150754.23645@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA23635; Wed, 15 Jul 1992 17:53:55 +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, 15 Jul 1992 08:53:23 +0100 To: David Clark Cc: big-internet@munnari.oz.au Subject: Re: Building routers for the routing of tomorrow -- 2nd try In-Reply-To: Your message of "Tue, 14 Jul 92 15:05:09 EDT." <9207141905.AA06992@ginger.lcs.mit.edu> Date: Wed, 15 Jul 92 08:53:22 +0100 From: Jon Crowcroft >This works, but requires "layer peaking" and is potentially an >efficiency concern. So this problem should be considered in a future >IP header. >One solution, is to go to a full-fledged connection model. (Sigh) Then during the IETF multicast, we have been thinking about multicast in the net and in the transport, and would like to introduce closed loop congestion ctl a la TCP - (in the absence of admission control and qos on setup, and in the presence of such varying link bandwidths, and traffic variation, this is needed - by observation!) unfortunately this means getting acks, which with over 70 sites participating is very bad news - solution we suggest is hop by hop (even more sacriligous than suggesting connections!) and have the multicast routers do layer peaking, look at returning acks, and do ack accumulation! i.e. when everything is ok, the sender gets 1 or so acks per packet! (although for n receiverts, there are n acks, but at each level of the multicast distribution n-ary tree, they get squashed by n). yo might find the state needed in the net unnacceptable - however, currently reverse path truncated broadcast (and multicast) routing has source address info in the routing tables anyhow! and for many multicast applications, for a given multicast group there may be only a small number of sources at any one time... anyhow, just something more to toss into the IPv7 melting pot! cheers j. [most the AVT group seem to be discussing things in the context of an imaginary net with class based queuing everywhere, and authenticated, mechanisms for defining or setting up flows, as if that is all a solved problem - although a lot of bits are in place, we want some soln that will admit of using bits of the current internet for a while!). From owner-Big-Internet@munnari.oz.au Thu Jul 16 00:04:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02905; Thu, 16 Jul 1992 00:04: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 AA02871; Thu, 16 Jul 1992 00:04:06 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11277; Wed, 15 Jul 92 10:03:32 -0400 Date: Wed, 15 Jul 92 10:03:32 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207151403.AA11277@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, throop@dg-rtp.dg.com Subject: Re: Clark's route fragments Cc: jnc@ginger.lcs.mit.edu You have to understand what I mean by 'shortish'; to me it means 64 bits or so! I'm merely saying shortish as compared to DNS names or NSAP's. I didn't say 'short' since that means 16 bits or so.... Noel From owner-Big-Internet@munnari.oz.au Thu Jul 16 00:36:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04679; Thu, 16 Jul 1992 00:37: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 AA04667; Thu, 16 Jul 1992 00:36:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11425; Wed, 15 Jul 92 10:36:51 -0400 Date: Wed, 15 Jul 92 10:36:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207151436.AA11425@ginger.lcs.mit.edu> To: ddc@lcs.mit.edu, smart@mel.dit.csiro.au Subject: Re: Route fragments, a routing proposal Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu The ID+address people agree on much more than they seem to think they do Well, I'm not sure I think this is a fair characterization. I do understand that more and more people see the utility of an endpoint identifier, etc. However, there are still some fairly important differences, though. Partially these are in areas that have been little explored on this list (e.g. abstraction), and how these influence things like what addresses should look like. MIT is obviously big enough that a top level number is not silly I'm not sure this is true. How many organization are there world-wide which are the size of MIT? If the answer is more than about 10K, and I suspect it is, then it's porbably not reasonable for MIT to have a top-level. Routing costs *at any level* are always polynomial, or something close to that, and numbers like 10K are about the effective limit for reasonable routing. (The baling wire on the NSF backbone is excluded as a counterexample....) Yes folks, ID+address is the true "backward compatible" solutio.n Absolutely. Nimrod was just the first scheme to take advantage of this, but I can imagine lots of non-Nimrod routing architectures (e.g. IDRP) which use the same technique. I am *convinced* this is how we will deploy a new R+A architecture. Figuring out the packet format and the forwarding engine is not the hardest part of the job. I reckon if we locked Dave and Noel and Paul in a room in the morning we'd see a puff of white smoke before lunch. Don't be too sure about this. (You might have to call in the police!) The problem is that there are substantial differences at some of the higher conceptual levels, and these effect what you want to see in an address. They only *look* similar since they are all heirarchical, etc... If people think it can be done more simply they owe us more than hand-waving arguments. I am simply not impressed by any scheme which does not *start* with a routing architecture, for reasons I have tried to explain for a long time. Addresses are just the data that routing carries around; if you don't know how the routing will work, and what are all the tasks which you want addresses to help perform, how can you know if you've got them right? I mean, in Nimrod, addresses do no less than *SIX* separate things (see 3.3.2 for details): - uniquely identify a network attachment point - show topologically related groups of NAP's - allows the point on the map named by the address to be found easily - provides a representation for the topology exchange - provides a framework for the abstraction process - controls where the simplest routes will go Addresses are *extremely* overloaded mechanisms (exactly what they do differs from routing architecture to architecture in detail), and very subtle differences, which seem unimportant when you consider them without the routing architecture, can make performing all of those many goals equally well much harder. Slightly different schemes only look similar if you have not thought in detail about how they will interact with all these tasks. For a thing which has *so many* uses, you have to get it *just right*, and you *cannot* do that without knowing *exactly* how they will be used. If you still consider this hand-waving I'm afraid there isn't much more I can add. If we don't get some unity into the ID+address side of the argument soon the chances of overturning the IAB's semi-decision for CLNP are low. The IAB's decision is basically DOA at this point. Forcing premature closure of a healthy debate, in the name of 'getting things done', is *exactly* the mistake the IAB made. I personally think implementing 2 or 3 different schemes and trying them is a good thing; I don't think intellectual desk argument will ever tell you as much as real world experience... Noel From owner-Big-Internet@munnari.oz.au Thu Jul 16 01:04:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05389; Thu, 16 Jul 1992 01:04: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 AA05386; Thu, 16 Jul 1992 01:04:39 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11554; Wed, 15 Jul 92 11:04:30 -0400 Date: Wed, 15 Jul 92 11:04:30 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207151504.AA11554@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, estrin@usc.edu Subject: Re: small question/clarification re. ddc idea and state Cc: jnc@ginger.lcs.mit.edu avoid proliferation of state requirements (O(N^2) in routers Every time I hear this steam comes out of my ears. Why do people assume that router state will scale as N^2, where N is the size of the network? Presumably the *upper limit* of state growth is *bandwidth growth* into and out of the routers. Even if *every* packet is to a diffferent destination, state can only grow as fast as the bandwidth into the router, right? I assume that it will grow slower, since many packets will be part of flows. True, recently router bandwidth has been growing faster than the network size, but still! Don't get me wrong, I am *very* worried about state growth in the routers, but I don't think it is quite as bad as everyone seems to think. Noel From owner-Big-Internet@munnari.oz.au Thu Jul 16 01:47:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06635; Thu, 16 Jul 1992 01:47:50 +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 AA06588; Thu, 16 Jul 1992 01:47:21 +1000 (from estrin%caldera.usc.edu@usc.edu) Received: from caldera.usc.edu by usc.edu (5.64+/SMI-3.0DEV3) id AA27557; Wed, 15 Jul 92 08:47:05 PDT Received: by caldera.usc.edu (4.1/SMI-3.0DEV3) id AA05666; Wed, 15 Jul 92 08:47:04 PDT Date: Wed, 15 Jul 92 08:47:04 PDT Message-Id: <9207151547.AA05666@caldera.usc.edu> From: estrin@usc.edu (Deborah Estrin) Sender: estrin%caldera.usc.edu@usc.edu To: jnc@ginger.lcs.mit.edu Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In-Reply-To: Noel Chiappa's message of Wed, 15 Jul 92 11:04:30 -0400 <9207151504.AA11554@ginger.lcs.mit.edu> Subject: Re: small question/clarification re. ddc idea and state Reply-To: estrin@usc.edu quench the steam noel. Not all associations consume the same bw. you might have a few big flows consuming some and a "bigish" :} number of very low bw flows consuming the rest. If you are keeping state in between these individual packets with larger inter-packet arrival times then it could be alot of state. So i was just clarifying that dave's state was truely soft for the non-reserv traffic and you can route the packet without the state. Anyway the point is that we do care about state but that src+CI schemes do NOT preclude doing efficient things. I sort of meant my message to preempt such concerns by others... From owner-big-internet@munnari.oz.au Thu Jul 16 02:57:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10219; Thu, 16 Jul 1992 02:57: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 AA08560; Thu, 16 Jul 1992 02:34:25 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16598; Wed, 15 Jul 92 12:33:38 -0400 Message-Id: <9207151633.AA16598@ginger.lcs.mit.edu> To: "Milo S. Medin" (NASA ARC NSI Office) Cc: Bob Smart , David Clark , big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal In-Reply-To: Your message of Tue, 14 Jul 92 22:03:30 -0700. <9207150503.AA06478@dscs.arc.nasa.gov> From: David Clark Date: Wed, 15 Jul 92 12:33:37 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp I think that what you said is basically correct. Vint said some very constructive words, and took his clothes off in public as you said. He also did a belly dance while someone stuffed a dollar into his clothing.... It remains to be seen how the political ramifications will play out. There is lots of muttering in the halls. But technically, no one should think that any decision has been made that precludes options. But I would like to offer this comment in the context of the IAB ID. What I do not see here is any process for converging. The idea of locking folks in a room and waiting for white smoke was supposed to be the ROAD agenda. There was lots of talk, but no obvious path to a long-term convergence. I do not know that different people would have helped. Having spend days in rooms with some of the folks in question, I have my doubts. No one in this community has the POWER to decide. People now seem to doubt the JUDGEMENT of the IAB to decide. I have not seen the IESG moving towards a process to decide. So the community has a basic problem, which is how to make hard long-term decisions. (For other examples of how long-term policy decisions do not work, regard the U.S. federal govt...) So our problem is not unique, just painful. Dave From owner-Big-Internet@munnari.oz.au Thu Jul 16 04:12:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16107; Thu, 16 Jul 1992 04:12: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 AA16095; Thu, 16 Jul 1992 04:12:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17364; Wed, 15 Jul 92 14:11:59 -0400 Date: Wed, 15 Jul 92 14:11:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207151811.AA17364@ginger.lcs.mit.edu> To: hwb@upeksa.sdsc.edu, jnc@ginger.lcs.mit.edu Subject: Re: Route fragments, a routing proposal Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I've just realized that I was a little loose in my language in a previous message, for which I apologize. Here's what I said: Forcing premature closure of a healthy debate, in the name of 'getting things done', is *exactly* the mistake the IAB made. What I was meaning to say was: Forcing premature closure of a healthy debate, in the name of 'getting things done', is *exactly* what in the perception of many people was happening in the recent message from Lyman and the associated IAB proposal (even though that many not have been what the IAB as a whole in fact intended), and many (including me) feel that trying to close down debate in the name of efficieny is a mistake. Noel From owner-big-internet@munnari.oz.au Thu Jul 16 05:00:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19969; Thu, 16 Jul 1992 05:00: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 AA11083; Thu, 16 Jul 1992 03:10:47 +1000 (from ddc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA16966; Wed, 15 Jul 92 13:10:38 -0400 Message-Id: <9207151710.AA16966@ginger.lcs.mit.edu> To: estrin@usc.edu Cc: big-internet@munnari.oz.au Subject: Re: small question/clarification re. ddc idea and state In-Reply-To: Your message of Tue, 14 Jul 92 22:28:41 -0700. <9207150528.AA04500@caldera.usc.edu> From: David Clark Date: Wed, 15 Jul 92 13:10:37 -0400 Sender: ddc@ginger.lcs.mit.edu X-Mts: smtp Deborah, I have several answers to your question. I must admit that most of them are statistical guesses, nothing better. First, I am not too scared by a large number of cache entries. They are like the route entries in the Unix router today. They are not too big, and mostly contain pointers to other larger structures with more information. This use of pointers allows lots of CI entries to share a common action in the router. Second, they are just cache entries, and if one gets tossed, you can still forward the packet. (The ones where the state did not come from the packet should be more stickey.) Third, I suspect that the explosion in the number of entries would actually be small. Lets look at what it would mean if we used my scheme to replicate exactly what we do today: simple destination routing. Whereas now there is one entry per destination, in my scheme there would be some number per source-destination pair. How bad would that be? For a router deep inside some net, I suspect that the number of active connections to one destination is small. In that case case, the increase is minor. But what if there are many connections to one destination? There is actually a nice bound here as well. Here is the key. Consider the connections going in both directions. In one direction, converging on the destination, there will be one entry. In the "other" direction (packets going to the sources from this destination), there will be N entries, one for each source. In my scheme (assuming for a moment one connection between each pair) there would be 2*N entries, N in each direction. So in this case, which would match a router in a client-server context, the table size increase is 2 (or some small multiple of this depending on how many active connections there are between each address pair.) The worst case is where the topology is a richly active peer context. Lots of machines on the left talking to lots of machines on the right, and all going at once. In this case the increase in the table size might get closer to N*N than 2*N. But I suspect (and in any case hope) that this situation is uncommon. When it is not, I fall back on points one and two. Dave From owner-big-internet@munnari.oz.au Thu Jul 16 05:26:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21742; Thu, 16 Jul 1992 05:26: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 AA15318; Thu, 16 Jul 1992 04:03:12 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA17305; Wed, 15 Jul 92 14:03:07 -0400 Date: Wed, 15 Jul 92 14:03:07 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207151803.AA17305@ginger.lcs.mit.edu> To: ddc@lcs.mit.edu, medin@nsipo.nasa.gov Subject: Re: Route fragments, a routing proposal Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I have not seen the IESG moving towards a process to decide. Dave, did you see the draft IESG recommendation which was circulated to Big-I a while back? It contained a recommendation on a process (with realtime dates on various stages of the process) to decide on the long-term solution. The IESG has not released a new version to avoid further muddying the waters WRT the IAB. No one in this community has the POWER to decide. .... So the community has a basic problem, which is how to make hard long-term decisions. This is getting toward the root of the whole blow-up, which is how does the community makes decsisions and what is the best way to make decisions. Some feel (for good reason) that this long, costly, agonizing process the IETF goes through to make the hard decisions is wasteful of energy and time. Others feel (for equally good reasons) that in fact the competition is healthy and good. However, I don't think we can solve this here, and in any case this isn't *really* the right forum.... wonder what is? The IETF meeting itself, probably; the IETF mailing list probably couldn't keep up. Noel From owner-Big-Internet@munnari.oz.au Thu Jul 16 05:40:46 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22715; Thu, 16 Jul 1992 05:41:04 +1000 (from owner-Big-Internet) Return-Path: Received: from cincsac.arc.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22705; Thu, 16 Jul 1992 05:40:46 +1000 (from medin@nsipo.nasa.gov) Received: Wed, 15 Jul 92 12:38:34 PDT from localhost.arc.nasa.gov by cincsac.arc.nasa.gov (4.1/1.5T) Message-Id: <9207151938.AA04321@cincsac.arc.nasa.gov> To: David Clark Cc: Bob Smart , big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal In-Reply-To: Your message of "Wed, 15 Jul 92 12:33:37 EDT." <9207151633.AA16598@ginger.lcs.mit.edu> Date: Wed, 15 Jul 92 12:38:34 -0700 From: "Milo S. Medin" (NASA ARC NSI Office) Dave, I very much agree with you. There are pluses and minuses to the distributed control of the Internet. Being able to change things in a reasonable way is one of the hard problems that people face. One thing I think is essential to being able to make progress here is in the area of incentives. That is, an organization that will have to expend resources (dollars, people, etc...) in order to support a new IP will have to have some form of local incentive to justify expending those resources. Being able to expand the global system is not something that any one site cares about very much, especially if that site is already connected and can already communicate effectively to most of their peers. This is one reason why I hope that the successor we choose to pursue provides new functionality, such as better resource control, security, etc... That will provide an incentive for people to deploy it, instead of trying to use coercion. If you expect any changes to the hosts, that change MUST buy the host's owners something new or it just won't happen. Why is it that OSI has "failed to achieve orbit" (in NASA lingo)? Because noone percieves OSI as effectively providing any new functionality over their IP or proprietary implementations. In the real world, people will do a cost benefit analysis before expending resources on conversion. If you are trying to get them to do something, it's important that calculation comes out the right way. No one is going to spend dollars on the global good, except maybe for the Government (maybe). There are user groups in NASA who can't justify to their management upgrading from XNS to IP because they can't justify the cost for the benefit in functionality. And if you want people to switch from IPv4 to IPv7, it had better be cheap, and do a lot of things you couldn't do before. If there is no new functionality, then you will have to live a design that only changes routers, and not the hosts. Even in the network providers case, few networks carry the full routing table. So for the big backbones, they've got a problem, but the mid-levels and others that feed into them typically use default, so they don't see a problem. So what incentive is there for the mid levels to expend resources to make the problem of the backbones easier to solve? A few months ago, one mid-level dumped in 300+ networks from a company called NCR. That included something like 256 Class C's. All from one organization. I complained because my routers at the FIXes have to carry all that nonsense, and the mid-level in question could have used a single class B instead of 255 Class C's. And now that mid-level has a class A, so they could just give all those sites Class A subnets. But NCR didn't want to bind their host addresses to the mid-level, or even making a decision that all their sites will be connected via any one provider. So they got 255 class C's and a pile of Class B's added. They did that because they had no incentive to make life easier on the top level backbones. The mid-level also didn't have any such incentive. Thus I and NSF and DOE and others have to carry all that extra nonsense. We should learn something from this experience about incentives the various network organizations have to cooperate. It does no good to expend a lot of time and money on an approach that will never get deployed because it fails to recognize the lack of incentives provided to the organizations that are needed to make it work. Also, what was even worse, is that after sending my complaint out to the nsr list, I got back about a dozen replies from people in the network organzations on that list saying how glad they were that I raised the issue, because they couldn't do it themselves for political reasons! Folks, we have a long hard path in front of us. Don't expect the IAB and other such groups to be of much help. Thanks, Milo Thanks, Milo From owner-Big-Internet@munnari.oz.au Thu Jul 16 07:07:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27810; Thu, 16 Jul 1992 07:07:53 +1000 (from owner-Big-Internet) Return-Path: Received: from wilbur.nas.nasa.gov by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27786; Thu, 16 Jul 1992 07:07:35 +1000 (from lekash@nas.nasa.gov) Received: by wilbur.nas.nasa.gov (5.61.a/1.34) id AA13282; Wed, 15 Jul 92 14:06:54 -0700 Date: Wed, 15 Jul 92 14:06:54 -0700 From: lekash@nas.nasa.gov (John Lekashman) Message-Id: <9207152106.AA13282@wilbur.nas.nasa.gov> To: ddc@lcs.mit.edu Cc: medin@nsipo.nasa.gov, smart@mel.dit.csiro.au, big-internet@munnari.oz.au In-Reply-To: David Clark's message of Wed, 15 Jul 92 12:33:37 -0400 <9207151633.AA16598@ginger.lcs.mit.edu> Subject: Route fragments, a routing proposal But I would like to offer this comment in the context of the IAB ID. What I do not see here is any process for converging. The idea of locking folks in a room and waiting for white smoke was supposed to be the ROAD agenda. There was lots of talk, but no obvious path to a long-term convergence. Since you asked. The path to long term convergence: 1. Fund several different groups to go build whatever they feel is the best solution, and try some out. Whether the Government or private companies do it, doesn't especially matter, although many of the private companies seem to want a standard before they'll build anything. Let market forces go to work. ROAD suffered/suffers? from the basic problem of trying to legislate decision. The winner will be that solution (or solutions) which people want to do, not that they are told to do. 2. Recognize you won't really get it, for quite a while. (Decades?) There are many incremental technology advances due to occur for the forseeable future, so there will be many people in varying stages of transition, for some time to come. Change management is the key to success. john From owner-Big-Internet@munnari.oz.au Thu Jul 16 12:25:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10245; Thu, 16 Jul 1992 12:25:46 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA10240; Thu, 16 Jul 1992 12:25:41 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from Mordor.Stanford.EDU by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA25568; Wed, 15 Jul 92 22:18:23 -0400 Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA10407; Wed, 15 Jul 92 19:18:21 PDT Message-Id: <9207160218.AA10407@Mordor.Stanford.EDU> To: big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Wed, 15 Jul 92 12:33:37 -0400. <9207151633.AA16598@ginger.lcs.mit.edu> Date: Wed, 15 Jul 92 19:18:20 -0700 From: Dave Crocker Date: Wed, 15 Jul 92 12:33:37 EDT To: "Milo S. Medin" (NASA ARC NSI Office) From: David Clark Subject: Re: Route fragments, a routing proposal ... I have not seen the IESG moving towards a process to decide. Dave, Let me pursue Noel's response to you in a bit more detail: The IESG's assessment was that it was not possible to make a recommendation at this time because no existing proposal provided enough detail, e.g., specification of a transition plan. What we therefore did was to suggest the beginnings of a criteria set for evaluating the alternatives. (We've gotten some useful suggestions for enhancing this list, but not as much detailed response as I personally would like to see.) By November-time, we intend to apply those criteria to evaluate the alternatives. A number of outcomes are possible, but our intent is to develop an IESG recommendation. My own expectation is that this will mean that we suggest one option over any of the others. There is, of course, no force of law in such a recommendation. If we are lucky, the recommendation will be acceptable to the bulk of the Internet community. If not, things will again get interesting. Ideally, the community, itself, will have developed a dominant preference for one of the options, so that the IESG's job really will be to "report" that concensus. I do not see an alternate scenario that is viable in this community. Do you? Dave From owner-Big-Internet@munnari.oz.au Thu Jul 16 13:02:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA11549; Thu, 16 Jul 1992 13:02:22 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11545; Thu, 16 Jul 1992 13:02:14 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA01139 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 16 Jul 1992 13:02:27 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA08222; Thu, 16 Jul 92 13:02:09 EST Message-Id: <9207160302.AA08222@wanda.mel.dit.CSIRO.AU> To: David Clark Cc: big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal In-Reply-To: Your message of "Wed, 15 Jul 92 12:33:37 -0400." <9207151633.AA16598@ginger.lcs.mit.edu> Date: Thu, 16 Jul 92 13:02:08 +1000 From: Bob Smart >So the community has a basic problem, which is how to make hard >long-term decisions. (For other examples of how long-term policy decisions >do not work, regard the U.S. federal govt...) So our problem is not unique, >just painful. If the American political process is a hard slog it is because the founding fathers wanted it that way. With 200 years of democracy and freedom they haven't been proved wrong yet. Let's think about some things we can do to move the political wheels along. 1. If you pick one solution people rebel. If you pick 2 or 3 and then have a testing period then people will line up behind the one they dislike least and fall in love with it (political honeymoon period). If then one of the other solutions wins in what looks like a fair fight they'll accept that. Since we have concensus not majority voting we hope one solution will win by a long way, but that is likely: the reason it doesn't happen in the politics is that both sides stay close to the centre and technical differences are often low. 2. The backbone carriers are the ones that provide our universal connectivity. Once it comes to the crunch and they are in trouble they have levers they can pull. They can insist that people with only one provider take their address from that provider; non-connected addresses can be reused. We can survive quite a long time on those measures. The next step is to charge per year for accessable network numbers. I like Paul Tsuchiya's suggestion of the money going to ISOC: I wouldn't like to see network numbers as a real commodity. If you have a new protocol which lets you use the number space very densely, i.e. an ID-Address based protocol, then there will be economic pressure for people to move to that. 3. To build concensus we look for areas of agreement initially. The ROAD group lacked any common ground to start with. Its hard to see from this distance why the people who want ID+address+flows don't have a good starting point to work from. Anyway lets suppose that there is an IAF group. If it is going to win it has to do 2 things. It has to resolve its internal differences by debate. It has to simultaneously put on as good a show of unity as it can muster while trying to attract in more people to the cause. A fact that has to be accepted is that people can't look at every idea that anyone has. So a strategy that most of us follow is that we look at ideas that have support from someone we know and respect from other previous matters. [That's why it is great to have Dave Clark on the team!]. So you need to try to get endorsements from well known people. They don't have to be experts in the field. If Johnny Carson said that ID+address was the way to go people would say "what would he know" but they'd also be much more inclined to spend some of their (valuable) time trying to understand it. 4. Don't make more enemies than you have to. That's why I suggested some contact with ISO. If we could bring ID+address in with some reasonable hope of it becoming an ISO standard we'd do a lot to defuse the CLNP argument. Many would say that this was a good thing to do even if it was done with the most cynical of motives. 5. Look for leadership. Actually the MIME working group was interesting. There was a very good chair (Greg Vaudreuil - pardon spelling) who was not the author of the RFC. The chair and the authors provided different sorts of leadership that worked well together. But you can't guarantee what political structures will work: it depends so much on the individuals. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - So there it is: politics, compromise, struggle, technical problems to solve, personality clashes to overcome, no guarantee that we'll get the best result, no guarantee that we'll get any result. The worst decision making system in the world except for all the others. The other price of liberty. Bob Smart From owner-Big-Internet@munnari.oz.au Thu Jul 16 13:25:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12086; Thu, 16 Jul 1992 13:25:56 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA12079; Thu, 16 Jul 1992 13:25:47 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA01437 (5.65c/IDA-1.4.4/DIT-1.3 for ); Thu, 16 Jul 1992 13:25:58 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA08326; Thu, 16 Jul 92 13:25:38 EST Message-Id: <9207160325.AA08326@wanda.mel.dit.CSIRO.AU> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal In-Reply-To: Your message of "Wed, 15 Jul 92 10:36:51 -0400." <9207151436.AA11425@ginger.lcs.mit.edu> Date: Thu, 16 Jul 92 13:25:37 +1000 From: Bob Smart Noel, When I hear someone mention the OSI 7-layer model my mind goes "Bullshit alert... batten down the hatches". Your messages are starting to have the same effect. Now I know that's unfair: your stuff has a lot of good ideas and I've incorporated everything I can understand but this stuff about address design is something I can't possibly understand without some more concrete idea of what you think an address _might_ be like. Something on the level of the PIP overview would be good. The level of detail in Dave Clark's messages is quite ok. But this endless sequence of English sentences couched in general terms is not getting through to me. > Addresses are just the data that routing carries around; if you >don't know how the routing will work, and what are all the tasks >which you want addresses to help perform, how can you know if you've >got them right? I mean, in Nimrod, addresses do no less than *SIX* >separate things (see 3.3.2 for details): > >- uniquely identify a network attachment point >- show topologically related groups of NAP's >- allows the point on the map named by the address to be found easily >- provides a representation for the topology exchange >- provides a framework for the abstraction process >- controls where the simplest routes will go I don't know what "providing a framework" means, but it sounds like too much work for a simple thing like an address. Apart from that all these things are trivially provided by PIP. What the hell are you talking about? Bob Smart From owner-Big-Internet@munnari.oz.au Fri Jul 17 03:32:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03380; Fri, 17 Jul 1992 03:34:20 +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 AA03308; Fri, 17 Jul 1992 03:32:01 +1000 (from craig@aland.bbn.com) Received: from port12.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA14487; Thu, 16 Jul 92 13:31:27 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA07830; Thu, 16 Jul 92 10:29:51 PDT Message-Id: <9207161729.AA07830@aland.bbn.com> To: big-internet@munnari.oz.au Subject: note on implementing IPAE Reply-To: Craig Partridge From: Craig Partridge Date: Thu, 16 Jul 92 10:29:51 -0700 Sender: craig@aland.bbn.com [this was handed out at the IPAE bof this morning at IETF] As an experiment to try to figure out how hard IPAE is to implement, I spent some time last week putting the appropriate changes into the BSD Networking Release 2 distribution. (Please note that I have no plans to support this code). I've finished putting in the changes, and the changes lint. I expect to spend an afternoon abusing some BSD kernels with Eric Brunner (thanks Eric!) late this week to see if there's anything ghastly I've missed. This note describes what the changes are like and how hard the process has been to date. NEW CODE SIZE The revised code has just a bit over 400 new lines of new code (code written from scratch to support IPAE) and a little over 100 diffs to existing code. That's far less work than it sounds -- most of the diffs are purely mechanical and the IPAE code was almost entirely straightforward code that stuffs the right values in the right fields, looks up a route, does a checksum, and checks for odd situations (mostly of the form of address clashes). WHAT I DID Essentially, I did three things. First, I changed the (struct in_addr) structure to contain a larger IP address, while revising the protocol header definitions to keep a 4-byte address. This meant that everywhere in the BSD code that assumed that a (struct in_addr) was 4 bytes (i.e. the same size as the addresses that go in the IP protocol header) had to be changed. That change process was a nuisance, but almost all the BSD utility routines in the kernel are address size independent (they do bcmp() on addresses structures) so by changing (struct in_addr) I got to use a majority of the existing BSD code without modification. Second, I wrote the code to support IPAE as a layer above IP, and changed UDP, and TCP to call the IPAE output routine rather than IP output. (On the inbound side, ipintr() sees the IP datagram is an IPAE datagram and just calls ipae_input()). I also wrote ipae_forward() so the BSD code can act as an IPAE router. If IPAE is not used, the BSD system acts like a normal IP host/router. Third, I added a few lines of code to support IPAE addresses in the routing code and to expand the number of significant bits in the IP routing table to 96 bits from 32. If IPAE is not used, the upper 64-bits are always 0. The 96-bit size is a strawman size. A larger address size can be used just as well (modulo some portability concerns with older BSDs noted below). Another way to think of these changes is that almost the entire netinet/ directory of the kernel sources has been retrained to think in terms of 96-bit addresses instead of 32-bit addresses. However, the 32-bit address fields in IP and the TCP and UDP pseudo-headers are unchanged. ISSUES This section briefly discusses some issues encountered in the code. Can one just slip IPAE over IP? It turns out not to be quite that simple. At first, I thought I could just write a few IPAE routines to send and receive IPAE datagrams and touch up the routing code and be done. The idea was that I'd make the code think it was IP except when it had to do a little bit of IPAE. That turns out to be a bad idea, primarily because of multihoming. Consider the following multihomed host, with IP address 1.2.3.4 in commonwealth A and IP address 1.2.3.4 in commonwealth B, and suppose there are two TCP connections, one from to and the other from to . Since both connections are inside a commonwealth, they run over IP (no IPAE). But the multihomed host is now getting datagrams for a TCP connection between 1.2.3.4 and 2.3.4.5 on both interfaces (for confusion's sake, assume the port numbers are identical too). As a result, it is possible that segments from different connections may get mixed. To avoid this problem it is necessary for the interfaces to stamp their commonwealths on inbound IP datagram. So when an IP datagram from 2.3.4.5 arrives on the interface to commonwealth B, the interface layer needs to tell IP, so that IP will understand that this datagram is from 2.3.4.5 in commonwealth B. (Much as interfaces now tell IP that this datagram had a link level broadcast destination address). Now IP can distinguish between datagrams from 2.3.4.5 in commonwealth A and datagrams from 2.3.4.5 in commonwealth B. But it does mean the IP code must think in terms of IPAE addresses internally. For similar reasons, when IP routes a datagram, it must route not on the destination's IP address, but the destination's IPAE address. Otherwise IP might send a datagram for 2.3.4.5 in commonwealth B to 2.3.4.5 in commonwealth A by mistake. (An alternative is to keep a separate routing table for each locally attached commonwealth -- but the BSD code doesn't make that easy). Some folks had expressed concern that it would easy for an IP packet to magically slip from one IPAE commonwealth to another. The only way I could see this happening is if a BSD system was acting as an IP router at an IPAE boundary. So the code simply refuses to be an IP router if it is also an IPAE router. Another concern is ICMP redirects. Consider our poor multihomed host again. If it gets an ICMP redirect saying route to 2.3.4.5 via 5.4.3.2, it cannot do anything because it doesn't know which 5.4.3.2 (in commonwealth A or B?) to use. Tagging ICMPs with the interface's commonwealth apparently solves this problem, for ICMP within a commonwealth, but I haven't solved the problem where 2.3.4.5 in commonwealth A is also 5.4.3.2 in commonwealth B, and it wants 1.2.3.4 in commonwealth A (which it knows is multihomed) to send datagrams to via because the route through commonwealth B has fewer hops. (Note that if one tried to implement this routing with an IP source route, the same problem would appear - which 5.4.3.2 to route to? My view, however, is that an IP source route is implicitly making a host into an IP router for the source-routed datagram, and IP routers can't cross IPAE domains). PERFORMANCE The goal in this implementation was to make the code reasonably straightforward to understand, both to reduce debugging time and to help other folks think about what changes had to be made. So far, I haven't seen any showstoppers for performance. Right now the worse problem seems to be that IPAE will run somewhat slower than IP because the code does two routing look ups. One lookup to convert an IPAE commonwealth to the IP address of the router for that commonwealth, and then a lookup on the IP address to get the local next hop address (i.e. the next hop on the connected subnet). But these routing lookups could be consolidated by redesigning the routing table to return two addresses (gateway and local next hop) for an IPAE address, much as some folks have revised their IP routing table to return both local next hop and MAC address to avoid having to do an IP routing lookup followed by an ARP cache lookup. Computing the extra checksum is about 20 instructions (but now only done at the hosts, not in routers). I had thought putting the IPAE header after the IP options was going to kill performance, but because IP options must end at an even byte boundary, and the IP header length tells me the offset to the IPAE header, there's usually only one or two instruction penalty to compute the offset. (There's a bigger penalty if by some mischance the IPAE header is not fully in the same mbuf as the IP header, but one could have the same problems putting the extra addresses into options in the IP header). POTENTIAL GOTCHAS Right now the code assumes 96-bit addresses are what IPAE uses. In general the number of bits could be made arbitrarily large. However at more than 96-bits, older BSD implementations that assume a sockaddr cannot be larger than 16 bytes will require a revision of their socket layer code. (Note that they would need this change to support CLNP too). OVERALL COMMENTS In general, the changes were pretty easy. I just wrote a little IPAE code, and changed (struct in_addr) and then let lint find me all the places where things went wrong (like addresses sizes which were no longer the expected ones). From owner-big-internet@munnari.oz.au Fri Jul 17 08:53:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10210; Fri, 17 Jul 1992 08:56:46 +1000 (from owner-big-internet) Return-Path: Message-Id: <9207162256.10210@munnari.oz.au> Received: from CLynn.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA01645; Fri, 17 Jul 1992 02:10:25 +1000 (from clynn@BBN.COM) Date: Thu, 16 Jul 92 12:06:03 EDT From: Charles Lynn To: big-internet@munnari.oz.au Cc: CLynn@BBN.COM Subject: Another Proposal Moving Toward a Solution to the Internet Growth Problem Using IPv4 CLynn@BBN.Com July 16, 1992 Summary This message outlines a way to both alleviate the IP Address Space and Routing Table Explosion Problems which has less risk and expense than other proposals being discussed. It generalizes, reinterprets, and reuses familiar concepts and reuses the bulk of the current infrastructure, including physical systems and trained personnel. Most of the extra development will be needed for any of the proposed solutions and pieces of the required code can be "borrowed" from other places. The basic idea is to use IP Source Routing to extend the address space hierarchically to more than 32 bits. This will permit each leaf-like or organization's network to be of "Class A" size. It also reduces the number of routes required by the backbone or regional networks through use of topology based routing, and can simultaneously solve the "mobile-network"/"change of providers" problem. Since the proposal is based on IPv4 it can be introduced and tested incrementally in the current, live internet without causing any disruptions. In fact, the proposal is a simple generalization of work I did almost a decade ago to allow TCP connections to survive the failure of one of a multi-homed TOPS-20's interfaces or attached networks. This technique is being proposed because it will give us enough time to do the research, implementation, and evaluation of policy based routing, security, and guaranteed services needed for the next generation internet protocol without requiring that a significant amount of resources be diverted from those efforts. Hopefully, the community can reach consensus on the next generation IP quickly enough that this proposal will not be needed. Thus it should be viewed as a fallback plan. Problems Alleviated or Solved This proposal addresses the following problems: o Exhaustion of 32-bit IP Address Space o Growth of backbone routing tables o Limitations on an organization's address space o Routing aggregation o Running out of Class B addresses o Support for changing providers and mobile networks Constraints There are several constraints that this proposal meets: o Does not require any changes to backbone or regional routers o Does not require any changes to packet formats o Does not require changes to hosts before 32-bit IP Addresses are no longer unique, and may not even be required at that time o Does not require changes to routing protocols o Does not require much retraining of personnel o Interoperability with most deployed systems o Limit resources expended on elements that will not be part of a longer term solution Proposed Solutions Many other proposals with varying degrees of similarity to pieces of this proposal have been made by members of the community. There are so many similarities between the techniques used in this message and other proposals before the community that if this proposal "won't work" then the other proposals will need reevaluation or redesign. Common Problems and Solutions The various proposals for solving the problems identified above have several common areas. The basic technique for extending the address space is to move to larger addresses, possibly of variable length. This in turn will require changes to the mechanisms used to translate Domain Names into system addresses, e.g., the DNS or other directory services. Note, however, that the mechanisms (protocol and code) for storing and returning variable length DNS information already exist and can be reused. In addition, the mechanisms required to return "additional information" with DNS queries already exists and can be augmented to return the new longer address records (NAP-records) whenever standard 32-bit IP Address records (A-records) are being returned. The basic technique for reducing the routing tables is to move toward topology-based address assignment so that more routes can be aggregated. Thus all of the proposals require work to figure out what the routing hierarchy should look like and for assigning addresses consistent with that hierarchy. An IPv4 Solution At the most basic level, this proposal is to change the interpretation of what the NIC allocates from blocks of end-system addresses to blocks of Network Attachment Points (NAPs). See the figure below. Within the INTERNET, e.g., the collection of world-wide backbone and regional networks, the only "addresses" used for routing are the NAPs. Of course, during the transition, other addresses, e.g., of endpoints, will be present. Providers obtain the NAPs and assign one (or more) to each customer's network attachment point, e.g., the interconnecting router interface on the provider side. A customer is free to obtain internet connection from multiple providers and would consequently have one or more NAPs from each, e.g., NET X has NAP-1 and NAP-2. Each organization /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\ could assign \ \ addresses within / INTERNET / its network (NET \ \ in the figure) as \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ it chooses. During \ / | the transition, it NAP-1 NAP-2 NAP-3 would be wise to \ / | maintain globally ^v^v^v^ ^v^v^v^ unique addresses < > < > over all NETs to > NET < > NET < delay any host < X > < Y > software changes. v^v^v^v v^v^v^v / \ / \ One can think of the +----+ +----+ +----+ NAP-4 concatenation of the |HOST| |HOST| |HOST| \ 32-bit NAP and the | A | | B | | C | ^v^v^v^ 32-bit HOST Address +----+ +----+ +----+ < > as a 64-bit IP Address. > NET < From the perspective of the INTERNET, the 32-bit < Z > addresses of the HOSTs can be viewed as a flat Host v^v^v^v Identifier and the 32-bit NAP is the Host's Address. / | IP Version 4 has the mechanisms required to handle +----+ +----+ these 64-bit addresses using the Loose Source Route |HOST| |HOST| option. The use of the option only increase the | E | | F | size of the IP header by 12 bytes. +----+ +----+ One could interpret the levels of hierarchy in a 64-bit addresses as Internet, Regional, and Network in the most significant 32-bits and the usual Network, Subnetwork, and Host in the least significant. The routers connecting the NETs to the INTERNET are modified to insert an IP Loose Source Route consisting of the NAPs into all packets that it passes into the INTERNET. The router already knows its own NAP (IP Address of the interface). The routers obtain the remote NAP from the DNS, either by direct query, or indirectly by watching DNS requests passing through and caching the IP Address to NAP mapping. Note that a caching DNS resolver could be placed in a NET to simplify or make more robust the interaction between the router and the DNS. If the router and caching resolver are collocated, then the interactions can be quite reliable. The most basic algorithm is to always insert the source route option. Several optimizations are possible but will not be enumerated here. For example, if HOST A wants to send a packet to HOST C, it would place A in the IP Source Address field, C in the Destination Address field, i.e., "A -> C", and send it through NET X to an exit gateway, e.g., at NAP-1. The router there would lookup C in the DNS and get back NAP-3. The router would then insert a source route option to get "A, NAP-1 -> NAP-3, C" and send it into the INTERNET. The INTERNET routes the packet to NAP-3. At the NAP-3 router, nothing beyond the normal source route processing has to be done to packets being passed into a NET, e.g.., the packet would contain "A, NAP-1, NAP-3 -> C" in NET Y. This differs from the encapsulation schemes which require the encapsulation to be removed before being passed to the destination hosts. Additional route aggregation can be achieved if the objects labeled NET in the figure above are in fact Administrative Domains containing multiple networks. In that case, a single NAP would represent all of the networks in the domain. One could interpret this hierarchy as Internet, Regional, and Administrative Domain in the most significant 32-bits and the usual Network, Subnetwork, and Host in the least significant. The NAPs can be the current provider side address the the gateway connecting the NET to the INTERNET. If a provider wanted to achieve higher levels of route aggregation, it could choose to renumber the NAPs. Such a change could be accomplished ether by actual renumbering or by assigning a logical NAP address to the gateway and inserting the logical address into the routing updates sent into the INTERNET, e.g., using a static route. Note that if we cannot live with 64-bit addresses until the next version of IP is ready, additional levels could be added through inclusion of additional 32-bit address chunks (NAPs). E.g., NET Z is accessed through two levels of NAPs, NAP-3 and NAP-4. Hosts on NET Z can be thought of as having 96-bit addresses. When B sends to E, the DNS would return the NAP-record as additional information in response to a query for E's address. The packet sent into the INTERNET at NAP-1 would contain "B, NAP-1 -> NAP-3, NAP-4, E". Growth could happen from either above or below so there is no fixed top or bottom. Note that this proposal permits different length addresses (A's is 64 bits, E is 96 bits) while some other proposals restrict all addresses to be of identical length. Obviously, the DNS can return multiple NAP-records in a query for an IP Address to allow the source to choose what it considers to be the best path. This allows operation with no "top level". The proposal also covers the case of interconnects between NETs or Administrative Domains as is alluded to by the connection between NET-Y and NET-Z. The interconnecting router(s) simply have a NAP assigned to each interface or use their current interface addresses as NAPs. For connection oriented protocols such as TCP, the destinations hosts, e.g., C, do the standard thing -- invert the source route for the reply, as specified in RFC 1122. If this is done, no processing or cache/DNS lookup would be required for packets sent back to its peer, e.g., A. Subsequent packets from A to C would also have the source route option in place, e.g., at NAP-1. Thus the DNS lookup and insertion of the source route only happens for the first packet sent. For connectionless protocols, such as UDP, it may well be the case that the applications do not properly invert source routes that are received. This does not cause a new problem, but means that the source route option will have to be inserted into each datagram by the routers at the NAPs. Note that the mapping works until the 32-bit IP address space is exhausted and the addresses are no longer unique. If the next generation IP is still not in place by that time, it is likely that the hosts would need to be modified to insert the source route option. Advantages No address reassignment is required. No changes to the IP header. No changes to hosts. No changes to subnets. No changes to network management. No changes to tools. No changes to routing protocols such as EGP, IGP, etc. except to do route aggregation, if it proves to be necessary. No throw-away changes to DNS. Since the systems in the NET do not know the NAP(s) changing providers (or even redoing the routing hierarchy!) is straight-forward and a local matter between an organization and its DNS servers. Mobile networks or hosts are just special cases of "changing a provider". The only components that are not standard off the shelf (RFC 1122 compliant ;-) boxes are the routers connecting the NETs to the INTERNET and the additional DNS record type. Since source routing is part of the IP Architecture, any upper-layer problems should be minimal. E.g., no changes to the TCP and UDP checksum computation is required. Since only standard IPv4 functions are used, NETs which have transitioned to use of NAPs should interoperate with those that have not. In cases where an old net wants to communicate with a NET that has transitioned, the old IP still works as long as the INTERNET has not run out of routing table space and 32-bit host identifiers are no longer unique. There is no impact on communication within a NET. The routing hierarchy may grow either up or down, if necessary by addition of more 32-bit addresses entries in the source route. This proposal allows us to get some current operational experience with creating, administering, and using hierarchal routing. This experience can be fed back into the development of the next version of IP. The regional and backbone providers can take responsibility for the deployment and operation of the modified routers, thus greatly simplifying the logistics since the individual organizations would not be involved. Each NET potentially gets a class A address (e.g., 127.0.0.0 ;-) to allocate as it wants -- but interoperation with older systems would argue against it. Issues There are several details to be worked out and tradeoffs and tunings that can be made. Some claim that options reduce performance, others claim that variable length addresses slow things down, some claim shorter addresses speed things up. However, these issues do not affect functionality thus I do not consider it to be a significant issue. There are lots of ways to tune an implementation if that is where folks want to spend their resources. It may be the case that there is already a source route option present in a packet received from a NET by a router. The ability to determine whether the source route needs to be modified and if so how it should be edited will be needed. This does not appear to be a significant problem; ST-II is already addressing the problem. However, it will require a few cpu cycles. Insertion of a header option may lead to fragmentation problems if the addition causes a link's MTU to be exceeded. Since no insertion happens on the INTERNET -> HOST direction, it is not a problem there. In the HOST -> INTERNET direction, the insertion happens at the the exit points from a NET. At that point, one could configure an artificially lower MTU to get around the problem, if necessary. Insertion of options requires copying. In a reasonable implementation the copying is limited to the 20-byte standard IP header. This does not seem to be significant. The fact that memory cache lines are getting bigger and that processor speed is getting faster also reduce the significance of inserting or processing options. The issue of not having to remove source routes at entry into the destination net has been discussed above. The issue of hosts not properly implementing the IP Source Route option, and of applications not inverting one, have been covered above. Implementation bugs in the processing of IP Source Route options may be discovered in deployed routers (I have not heard of or encountered any). Most vendors seem to be responsive to problem reports. The cooperation of the vendors will be required to make any transition to a new IP successful. The FTP port problem isn't a problem until 32-bit IP Addresses are no longer unique. In any case, the port command looks like it ought to be changed to something like . Given that things which parse FQDNs should accept Dotted 4, such a change can be made to be backwards compatible. The problem with routing table size is beginning to ring warning bells. During any transition to longer addresses, it appears that the routing tables are going to get even bigger before they get smaller. [I would be willing to bet by an order of magnitude in number of bytes.] This raises the issue of whether the engineering decisions we made many years ago are still the right ones for the future. If one steps back and looks at this proposal, one sees that a different routing system architecture is being used. Routing in the INTERNET no longer knows about the addresses in the NETs or how to route to them. Routers in the NETs do not know addresses in the INTERNET or how to route to them. The DNS is being used to distribute routing information, e.g., source route fragments. [Another old idea from the packet radio work in the 80's that is resurfacing.] The advantage of this scheme over the current one of computing more or less global forwarding information in each forwarding box based on routing updates is that routing information is only distributed where it is needed instead of where it might be needed (but probably will never be used). We might benefit by considering the separation of routing topology updates from routing connectivity updates. Remove route computation form the forwarding boxes. Load the routes from some server with the routes they need, or let them query for the information on an as needed basis. Let them keep track of "how to get to X" and "how to get to X if the primary path has failed" with the latter being something that is determined "locally". One can envision a big machine computing a "global" or "neighborhood" routing topology and making it available (for sale?) to the forwarding boxes. The space saved by removal of the routing protocol code and "full" routing tables can be used to process source route options and make bigger caches. One implication of using DNS for routing is that we need robust bullet-proof directory services. We need that in any case. Any comments? Charlie From owner-Big-Internet@munnari.oz.au Fri Jul 17 23:06:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00683; Fri, 17 Jul 1992 23:06:57 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207171306.683@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00680; Fri, 17 Jul 1992 23:06:49 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Fri, 17 Jul 1992 14:06:08 +0100 To: Craig Partridge Cc: big-internet@munnari.oz.au Subject: Re: note on implementing IPAE In-Reply-To: Your message of "Thu, 16 Jul 92 10:29:51 PDT." <9207161729.AA07830@aland.bbn.com> Date: Fri, 17 Jul 92 14:06:04 +0100 From: Zheng Wang Criag, I found your note is very interesting. I think the modifications to ICMP will actually be much more complicated than IP itself becuase ICMP includes parts of the original IP as its data, then encapsulates the ICMP data in the IP. Any encapsulation schemes will have problems here. If we just want to extend the space and allow routing aggregation, we can actually do it with EIP (ie. put an AD/CommonW/Area code into the Extension field). The modifications are much smaller! The only change to IP code is to add an extension field after the minial IP header. No modifications to ICMP at all! But the question is whether we should take this opportunity to make some more radical changes to routing. If maintain backward compatibilty is important, it is possible to make radical changes to routing yet maintain some backward compatibility. Note that most of the fields in current IP will be still needed in any newIP. We can arrange the newIP header format in a way similar to the IP header and put the new stuff in the extension field. EIP provides such a mechanism. For example, you can put Pip's routing directive etc into the extension field, you can achieve radical changes to routing but backward compatibility to IP. Note that the problem we have with current IP is in addressing/routing. Much of the modifications should be in routers/routing algorithms. Cheer Zheng From owner-Big-Internet@munnari.oz.au Sat Jul 18 00:52:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03922; Sat, 18 Jul 1992 00:53:07 +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 AA03913; Sat, 18 Jul 1992 00:52:49 +1000 (from craig@aland.bbn.com) Received: from port12.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA03659; Fri, 17 Jul 92 10:52:20 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA10431; Fri, 17 Jul 92 07:50:57 PDT Message-Id: <9207171450.AA10431@aland.bbn.com> To: Zheng Wang Cc: big-internet@munnari.oz.au Subject: Re: note on implementing IPAE Reply-To: Craig Partridge From: Craig Partridge Date: Fri, 17 Jul 92 07:50:57 -0700 Sender: craig@aland.bbn.com > I think the modifications to ICMP will actually be much more complicated > than IP itself becuase ICMP includes parts of the original > IP as its data, then encapsulates the ICMP data in the IP. > Any encapsulation schemes will have problems here. You're right there are some ICMP issues, though I wouldn't state them as strongly as you do. The general problem is 64 bits of the original data isn't enough to include the full IPAE header, much less the transport protocol header. So one needs to send back more than 64-bits. If you make that change, everything flies wonderfully. Note that it would be nice, though probably not essential, if all IP systems used more than 64 bits. (The problem I see is the following -- an IPAE host sends, for some reason, to an IP only host. The IP only host sends an ICMP message back to the last hop gateway. The ICMP message contains enough info to indicate that it is in response to IPAE, since part of the IPAE header is included. But not enough of the IPAE header is included to figure out the source IPAE address to which the ICMP message should be forwarded....) Craig From owner-Big-Internet@munnari.oz.au Sat Jul 18 12:01:41 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18789; Sat, 18 Jul 1992 12:01:51 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18786; Sat, 18 Jul 1992 12:01:41 +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, 17 Jul 92 22:01:27 EDT Received: by chiya.bellcore.com (4.1/4.7) id for tsuchiya@thumper.bellcore.com; Fri, 17 Jul 92 22:01:27 EDT Date: Fri, 17 Jul 92 22:01:27 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207180201.AA09360@chiya.bellcore.com> To: ddc@lcs.mit.edu, tsuchiya@thumper.bellcore.com Subject: Re: Route fragments, a routing proposal Cc: big-internet@munnari.oz.au > > So what we have to do in our routing is to find some way to express and > reason about (compute routes in) a polyarchy. My route fragments do that. > Essentially, each route middle represents a potential "top of the polyarchy" > to which an AD can connect. And each route suffix represents a decision by > an end AD to join the polyarchy in a particular way. Each such route > represents a different decision; there can be many. > > When Noel says hierarchy, he does not mean polyarchy. I remember discussing > this with you at Zurich, and I was unsure where you stood. It is quite > possible that we are in agreement. But note: I still think that this is essentially the same as the "multiple hierarchical addresses" thing I did for sigcomm. There also you can (indeed are encouraged, for policy routing) to have multiple roots. > > -- I think that the AD number (e.g. the number for MIT) must be global > exactly because in a polyarchy, since there are multiple "up links", you > cannot presume to use a single uplink to find a context to disambiguate the > name. All of the nodes "above" you in the polyarchy must be able to resolve > your name. > Perhaps so. I have always tended to think in terms of traditional addresses (albiet multiple of them), just because it didn't occur to me not to. If you do do traditional hierarchical addresses, the things above you in the polyarchy can still resolve to your name (because you are unambiguous with respect to to other things "under" that root, but with the global numbers you have far fewer address assignment headaches, which may be a big plus. There are disadvantages as well (longer packets, more complicated "address" lookup), but I can't get too hot and bothered about the disadvantages. PT From owner-Big-Internet@munnari.oz.au Sat Jul 18 13:59:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21522; Sat, 18 Jul 1992 13:59:47 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21519; Sat, 18 Jul 1992 13:59:37 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 17 Jul 92 23:59:26 EDT Received: by chiya.bellcore.com (4.1/4.7) id for estrin@usc.edu; Fri, 17 Jul 92 23:59:25 EDT Date: Fri, 17 Jul 92 23:59:25 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207180359.AA09576@chiya.bellcore.com> To: ddc@lcs.mit.edu, estrin@usc.edu Subject: Re: small question/clarification re. ddc idea and state Cc: big-internet@munnari.oz.au > > Second, they are just cache entries, and if one gets tossed, you can still > forward the packet. (The ones where the state did not come from the packet > should be more stickey.) But much more slowly, since the point behind the CI is faster forwarding not VCI per se. Seems to defeat the purpose of the CI in those cases where the cache is too small. > > Third, I suspect that the explosion in the number of entries would actually > be small. Lets look at what it would mean if we used my scheme to replicate > exactly what we do today: simple destination routing. Whereas now there is > one entry per destination, in my scheme there would be some number per > source-destination pair. How bad would that be? But, today the destinations are one per network, and in the near future may be one per backbone (since per/network isn't scaling nicely). But, with CI, it is one per source-dest HOST pair. So, scaling is much worse. Unless perhaps you mean by this that all routers hash and cache the results of IP address lookups on a per dest host basis. But, my understanding is that NSFnet routers do not cache, precisely because the number of individual host flows is too large. Can somebody confirm this? PT From owner-Big-Internet@munnari.oz.au Sun Jul 19 01:37:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA04179; Sun, 19 Jul 1992 01:38:13 +1000 (from owner-Big-Internet) Return-Path: Received: from TIGERMOTH.CIT.CORNELL.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA04172; Sun, 19 Jul 1992 01:37:38 +1000 (from swb@tigermoth.cit.cornell.edu) Received: from localhost.ARPA by tigermoth.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA00271; Fri, 17 Jul 92 22:55:58 EDT Message-Id: <9207180255.AA00271@tigermoth.cit.cornell.edu> To: ddc@lcs.mit.edu, big-internet@munnari.oz.au Reply-To: swb@nr-tech.cit.cornell.edu Subject: Re: Route fragments, a routing proposal In-Reply-To: Your message of "Wed, 15 Jul 92 14:06:54 PDT." <9207152106.AA13282@wilbur.nas.nasa.gov> Date: Fri, 17 Jul 92 22:55:57 -0400 From: Scott Brim > What I do not see here is any process for converging. The idea of > locking folks in a room and waiting for white smoke was supposed to be > the ROAD agenda. There was lots of talk, but no obvious path to a > long-term convergence. True. I would say we (the ROAD group) all had hopes of converging as we examined the technical issues, and that we definitely had common goals. There was a lot of agreement when we could nail down facts, but at the end it was impossible to make a single recommendation because dealing with the issues we *could* handle just wasn't enough. On the other hand, we had no way of knowing that would be the case without trying. So, in ROAD there *was* a path which we hoped would lead to long-term convergence, but in the end only gave us a lot of technical analysis of some of the options. Scott From owner-big-internet@munnari.oz.au Mon Jul 20 13:54:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15367; Mon, 20 Jul 1992 13:54:56 +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 AA14220; Mon, 20 Jul 1992 13:19:08 +1000 (from pgross@ans.net) Received: by interlock.ans.net id AA28587 (InterLock SMTP Gateway 1.1 for big-internet@munnari.oz.au); Sun, 19 Jul 1992 23:18:45 -0400 Received: by interlock.ans.net (Internal Mail Agent-1); Sun, 19 Jul 1992 23:18:45 -0400 Message-Id: <199207200318.AA17510@home.ans.net> To: David Clark Cc: big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal In-Reply-To: (Your message of Wed, 15 Jul 92 12:33:37 D.) <9207151633.AA16598@ginger.lcs.mit.edu> Date: Sun, 19 Jul 92 23:18:27 -0500 From: Phill Gross > : I think that what you said is basically correct. Vint said some very constructive words, and took his clothes off in public as you said. He also did a belly dance while someone stuffed a dollar into his clothing.... I am astonished by your implication that Vint Cerf, godfather of the Internet and former IAB chair, would do a "belly dance" for a dollar. Let the record show it was $5.00! ... I have not seen the IESG moving towards a process to decide. ... Hey, now I'm really astonished! :-) The IESG recommendation, sent to the IAB and Big-Internet list a few weeks ago, outlined a proposed timeline and process for making a decision. In a nutshell, the IESG developed some preliminary "decision criteria", and set up a timetable for proposals to be judged based on the "criteria". To quote from the text: "4.6 Milestones And Timetable For Making a Recommendation for Bigger Internet Addresses The IESG recommends that a call for proposals be made, with initial activities to begin at the July IETF and with a very strict timetable for reaching a recommendation coming out of the November IETF meeting. A working group will be formed for each proposed approach. The charter of each WG will be to explore the criteria described in section 4.3 and develop a detailed plan for IESG consideration. The WGs will have their first meeting at the July 1992 IETF meeting in Boston. The WGs will be asked to submit an Internet-Draft prior to the November IETF, and to make presentations at the November IETF. The IESG and the IETF will review all submitted proposals and then the IESG will make a recommendation to the IAB immediately following the November 1992 IETF meeting. Therefore, the firm milestones and timetable for the IESG to reach a recommendation on bigger Internet addresses are: June 1992 -- Issue a call for proposals to form working groups to explore separate approaches for bigger Internet addresses. Distribute the selection criteria for public review. July 1992 -- Convene proposed WGs at the Boston IETF meeting. The selection criteria will be discussed publicly, and modified as appropriate. July-November 1992 -- WGs continue deliberations by email and/or face-face meetings. October 1992 -- Each WG will be required to submit a written description of the approach and how the criteria are satisfied. These documents must be distributed as Internet-Drafts for public review 30 days prior to the November IETF meeting to be considered. November 1992 -- Each WG will be given an opportunity to present its findings in detail at the November 1992 IETF meeting. Based on the written documents, the presentations, and public discussions (by email and at the IETF), the IESG will forward a recommendation to the IAB. " We will be sending an (updated, post-IETF) second draft of the IESG recommendations as an I-D this week. The dates may be a bit agressive, but I think its a good goal. I believe an open discussion of the "selection criteria" will also be a very important exercise in the coming months leading up to the November IETF. I expect that the Big-Internet list will play an important role in finetuning these criteria. Phill From owner-Big-Internet@munnari.oz.au Mon Jul 20 17:26:16 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20942; Mon, 20 Jul 1992 17:26:21 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207200726.20942@munnari.oz.au> Received: from rschp1.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA20939; Mon, 20 Jul 1992 17:26:16 +1000 (from hugh@rschp1.anu.edu.au) Received: by rschp1.anu.edu.au (16.8/16.2) id AA10167; Mon, 20 Jul 92 17:24:56 +1000 From: Hugh Fisher Subject: Why not 64 bit IP? To: Big-Internet@munnari.oz.au Date: Mon, 20 Jul 92 17:24:56 EST Mailer: Elm [revision: 70.30] I'm an Internet end user, syadmin for a couple of systems attached to the Internet, and wannabe network application programmer. All this makes me woefully unqualified to comment on routing issues, but new addressing schemes would have an effect on me so I feel compelled to throw in my $0.02 (Australian). This may be regarded as a dumb question in networking circles, but I haven't seen any general references so I'll ask it anyway: why not a 64 bit IP? Upwardly compatible (from my end user perspective), and enough address space for every man, woman, child, and toaster on the planet. In all seriousness, why not do what the CPU hardware people are doing: define the new 64 bit address packet now, with the high 32 bits and some extra fields clearly marked "reserved for future use". Run the old software and addresses in the new packets until you figure out what to do with the extra bits. If this has been discussed, can someone please point me in the right direction? I hunted through the archive for this mailing list and couldn't find anything. Hugh Fisher From owner-Big-Internet@munnari.oz.au Mon Jul 20 20:41:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25592; Mon, 20 Jul 1992 20:41:16 +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 AA25586; Mon, 20 Jul 1992 20:41:05 +1000 (from huitema@mitsou.inria.fr) Received: from localhost.inria.fr by mitsou.inria.fr with SMTP (5.65c/IDA-1.2.8) id AA13840; Mon, 20 Jul 1992 12:40:59 +0200 Message-Id: <199207201040.AA13840@mitsou.inria.fr> To: David Clark Cc: big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal In-Reply-To: Your message of "Mon, 13 Jul 92 17:35:46 EDT." <9207132135.AA00985@ginger.lcs.mit.edu> Date: Mon, 20 Jul 92 12:40:59 -0400 From: Christian Huitema X-Mts: smtp Dave, A couple of comments on your initial "route fragments" proposal. 1) Since the basis of your demonstration is "I know a lot about the networks near me" why cant you assume that "the nearby routers know a lot about the networks around them"? If that is the case, you dont have any need to prepend your source route fragment into "MIT>NEARnet>NSF>BARnet>Stanford". The routers at MIT would probably no how to reach NSF, and a loose source route of the form "NSF>BARnet>Stanford" would probably be enough in the general case where you dont have to select on a policy basis between several routes to NSF.. 2) Isn't polyarchy a big name for a partially ordered address space? 3) Are we really absolutely sure that we need to manage two different name spaces, one for "network end point identifiers" and one for "route identifiers"? After all, the only thing that would be needed to implement your proposal in today's IP address space would be to have a "virtual address" reserved for objects like "NSFnet as a whole" -- something that would have the same leading bits as a regular IP number of an NSFnet host, but a reserved host number, and would in fact mean "any host within this network", i.e. the dual of a broadcast address. Packets would be routed towards NSFnet naturally, and the first NSFnet host would recognize that he needs to start working on the next item in the source route. 4) Isn't the problem becoming sort of much more complex (NP complete?) the moment you start introducing your "middle route" segment? Could we not keep the simplicity (for the user) of current routing by assuming a level of hierarchy above "NSF", that would say something like "world wide academics", "world wide public PTT", etc. A loose route like "world wide academics" would indeed have to be matched by any host in the "level under" -- or at least some of these hosts. 5) Elephants apart, aren't MX records a (limited) implementation of your scheme at the mail level? Christian Huitema From owner-Big-Internet@munnari.oz.au Tue Jul 21 02:11:04 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03613; Tue, 21 Jul 1992 02:11: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 AA03610; Tue, 21 Jul 1992 02:11:04 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA18496; Mon, 20 Jul 92 12:10:49 -0400 Date: Mon, 20 Jul 92 12:10:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207201610.AA18496@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au, Hugh.Fisher@anu.edu.au Subject: Re: Why not 64 bit IP? Cc: jnc@ginger.lcs.mit.edu The probem is that we not only need the extra bits 'right now', we also need what you can *do* with the extra bits "right now"! Also, 64 bits is probably not enough to provide "addresses" (in the JNC sense) large enough (i.e. enough levels, and space in each level) given the non-optimal use of space in addresses. I'll send you some references. Noel From owner-Big-Internet@munnari.oz.au Tue Jul 21 04:20:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06731; Tue, 21 Jul 1992 04:20:26 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06728; Tue, 21 Jul 1992 04:20:19 +1000 (from dave@japan.bellcore.com) Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA11224; Mon, 20 Jul 92 14:23:00 EDT Return-Path: Received: by japan (4.1/4.7) id AA03344; Mon, 20 Jul 92 09:43:02 EDT Date: Mon, 20 Jul 92 09:43:02 EDT From: dave@sabre.bellcore.com (Dave Piscitello) X-Station-Sent-From: japan.bellcore.com Message-Id: <9207201343.AA03344@japan> To: big-internet@munnari.oz.au, estrin@usc.edu Subject: Re: small question/clarification re. ddc idea and state also... just an aside... but speaking of B-ISDN they are having problems because of the small VCI space and the absence of source ID when it let's be careful with VCI's; like DLCI's in frame relay, they are not useful as globally unique addresses. The E.164 addresses (sigh...) serve this purpose. In fact, lots of folks make serious errors trying to turn VCI's into more than they are intended. From owner-Big-Internet@munnari.oz.au Tue Jul 21 04:38:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07297; Tue, 21 Jul 1992 04:39:00 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07294; Tue, 21 Jul 1992 04:38:51 +1000 (from dave@japan.bellcore.com) Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA10964; Mon, 20 Jul 92 13:31:33 EDT Return-Path: Received: by japan (4.1/4.7) id AA03344; Mon, 20 Jul 92 09:43:02 EDT Date: Mon, 20 Jul 92 09:43:02 EDT From: dave@sabre.bellcore.com (Dave Piscitello) X-Station-Sent-From: japan.bellcore.com Message-Id: <9207201343.AA03344@japan> To: big-internet@munnari.oz.au, estrin@usc.edu Subject: Re: small question/clarification re. ddc idea and state also... just an aside... but speaking of B-ISDN they are having problems because of the small VCI space and the absence of source ID when it let's be careful with VCI's; like DLCI's in frame relay, they are not useful as globally unique addresses. The E.164 addresses (sigh...) serve this purpose. In fact, lots of folks make serious errors trying to turn VCI's into more than they are intended. From owner-Big-Internet@munnari.oz.au Tue Jul 21 04:54:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07681; Tue, 21 Jul 1992 04:54:18 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07675; Tue, 21 Jul 1992 04:54:10 +1000 (from dave@japan.bellcore.com) Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA10056; Mon, 20 Jul 92 11:18:37 EDT Return-Path: Received: by japan (4.1/4.7) id AA03344; Mon, 20 Jul 92 09:43:02 EDT Date: Mon, 20 Jul 92 09:43:02 EDT From: dave@sabre.bellcore.com (Dave Piscitello) X-Station-Sent-From: japan.bellcore.com Message-Id: <9207201343.AA03344@japan> To: big-internet@munnari.oz.au, estrin@usc.edu Subject: Re: small question/clarification re. ddc idea and state also... just an aside... but speaking of B-ISDN they are having problems because of the small VCI space and the absence of source ID when it let's be careful with VCI's; like DLCI's in frame relay, they are not useful as globally unique addresses. The E.164 addresses (sigh...) serve this purpose. In fact, lots of folks make serious errors trying to turn VCI's into more than they are intended. From owner-Big-Internet@munnari.oz.au Tue Jul 21 04:54:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07689; Tue, 21 Jul 1992 04:54:39 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07685; Tue, 21 Jul 1992 04:54:26 +1000 (from dave@japan.bellcore.com) Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA09390; Mon, 20 Jul 92 09:59:40 EDT Return-Path: Received: by japan (4.1/4.7) id AA03344; Mon, 20 Jul 92 09:43:02 EDT Date: Mon, 20 Jul 92 09:43:02 EDT From: dave@sabre.bellcore.com (Dave Piscitello) X-Station-Sent-From: japan.bellcore.com Message-Id: <9207201343.AA03344@japan> To: big-internet@munnari.oz.au, estrin@usc.edu Subject: Re: small question/clarification re. ddc idea and state also... just an aside... but speaking of B-ISDN they are having problems because of the small VCI space and the absence of source ID when it let's be careful with VCI's; like DLCI's in frame relay, they are not useful as globally unique addresses. The E.164 addresses (sigh...) serve this purpose. In fact, lots of folks make serious errors trying to turn VCI's into more than they are intended. From owner-Big-Internet@munnari.oz.au Tue Jul 21 04:55:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07718; Tue, 21 Jul 1992 04:55:38 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07712; Tue, 21 Jul 1992 04:55:30 +1000 (from dave@japan.bellcore.com) Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA09518; Mon, 20 Jul 92 10:18:36 EDT Return-Path: Received: by japan (4.1/4.7) id AA03344; Mon, 20 Jul 92 09:43:02 EDT Date: Mon, 20 Jul 92 09:43:02 EDT From: dave@sabre.bellcore.com (Dave Piscitello) X-Station-Sent-From: japan.bellcore.com Message-Id: <9207201343.AA03344@japan> To: big-internet@munnari.oz.au, estrin@usc.edu Subject: Re: small question/clarification re. ddc idea and state also... just an aside... but speaking of B-ISDN they are having problems because of the small VCI space and the absence of source ID when it let's be careful with VCI's; like DLCI's in frame relay, they are not useful as globally unique addresses. The E.164 addresses (sigh...) serve this purpose. In fact, lots of folks make serious errors trying to turn VCI's into more than they are intended. From owner-Big-Internet@munnari.oz.au Tue Jul 21 06:27:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09552; Tue, 21 Jul 1992 06:27: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 AA09545; Tue, 21 Jul 1992 06:27:09 +1000 (from kre) To: Big-Internet@munnari.OZ.AU From: Big-Internet-Request@munnari.OZ.AU Subject: Repeated message from Dave Piscitello Date: Tue, 21 Jul 92 06:26:55 +1000 Message-Id: <24580.711664015@munnari.oz.au> Sender: kre@munnari.oz.au Before anyone else notices and sends me mail about it, yes, there were 5 copies of Dave Piscitello's message "Subject: Re: small question/clarification re. ddc idea and state" It appears that the problem is between japan.bellcore.com and sabre.bellcore.com where the message appears to have been repeated. If it keeps happening I will shut the list off for a while to give the bellcore people a chance to find & remove any remaining copies. This isn't any kind of mailing list loop however - the list is just delivering what its sent, nothing is coming back to haunt it - this time at least. kre From owner-Big-Internet@munnari.oz.au Tue Jul 21 06:57:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10423; Tue, 21 Jul 1992 06:57:33 +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 AA10418; Tue, 21 Jul 1992 06:57:24 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA08083; Mon, 20 Jul 92 13:57:05 -0700 Date: Mon, 20 Jul 92 16:24:37 EDT From: "William Allen Simpson" Message-Id: <562.bsimpson@angband.stanford.edu> To: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: Route fragments, a routing proposal It seems to me that any numbering of ADs actually *is* heirarchical, in that they must be globally unique, and therefore serve as the "layer" under an effective root node. > At the same time, this scheme allows us to avoid any assumption in the > addresses that there is a single addressing hierarchy, as NIMROD > proposes in its basic scheme. This idea admits that ADs do not exist > in a hierarchy, but in a full mesh. Effective routing depends on using > this full mesh. This proposal allows a full mesh, but structures it in > a way to control the complexity of finding routes. > A Nimrod scheme could use this as the uppermost layer. In PIPE, I suggested that the current AS number be reused, and that it be administratively allocated topologically in two octets. This number is already maintained in every border router. Splitting it into octets would deliberately limit the size of areas within layers and allow very small forwarding tables. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Tue Jul 21 07:11:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10634; Tue, 21 Jul 1992 07:12:00 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA10631; Tue, 21 Jul 1992 07:11:53 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA00421; Mon, 20 Jul 92 14:11:40 PDT Message-Id: <9207202111.AA00421@Mordor.Stanford.EDU> To: Hugh Fisher Cc: Big-Internet@munnari.oz.au Subject: Re: Why not 64 bit IP? Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Mon, 20 Jul 92 17:24:56 -0500. <9207200726.20942@munnari.oz.au> Date: Mon, 20 Jul 92 14:11:39 -0700 From: Dave Crocker Hugh, You ask a perfectly reasonable question. Here's my attempt at some of the answers: 1. Most discussions seem to feel that 96 bits is likely to be the smallest size that will be adequate for "long term" growth. The key, here, is that designing the usage of the bits to permit acceptable administration means using the bits somewhat inefficiently. 2. Simply changing IP's header format is likely to have a _very_ large impact on the installed base, unless there is a transition plan to support the extended period of time in which different nodes on the Internet support either the old format or the new. For example, if my end system and yours wish to use the new format, note that _all_ of the intermediate systems in the sequence need also to support the new format. Dave From owner-Big-Internet@munnari.oz.au Tue Jul 21 13:53:29 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22004; Tue, 21 Jul 1992 13:53:45 +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 AA21996; Tue, 21 Jul 1992 13:53:29 +1000 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA04736); Mon, 20 Jul 92 22:53:19 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9207210353.AA04736@is.rice.edu> Subject: ISO SC6 meeting tidbits (fwd) To: big-internet@munnari.oz.au Date: Mon, 20 Jul 92 22:53:19 CDT X-Mailer: ELM [version 2.3 PL11] A peek at how things are progressing in other camps... :-) Thanks to Dave Katz for the review... and sorry if you have already seen this. > To: noop@merit.edu > Subject: ISO SC6 meeting tidbits > > A PDAM to the addressing standard for multicast addressing will be > issued after this meeting. The goals of multicast addressing are to > make multicast addresses syntactically distinct from unicast addresses, > to not change unicast addressing at all, and to not add any new address > administration. This was done by conceptually creating a multicast AFI > for every existing unicast AFI, providing every existing addressing > authority with an equal-sized block of multicast addresses (note that > there is not necessarily any relationship between a particular unicast > address and its corresponding multicast address). Technically, a multicast > address has an AFI with binary abstract syntax, with multicast AFI x'A0' > corresponding to unicast AFI 10, up through x'F9' and 99. The check for > a multicast address then becomes a simple check for AFI >= A0. Note that > this addressing structure provides the ability to assign hierarchical > multicast addresses, which may have interesting applications for scope > control (this does not mandate that addresses be interpreted hierarchically, > of course). > > The address administration amendment (like reverse ARP) to ES-IS > passed its PDAM ballot, and should be published for DAM ballot > out of this meeting. Basically, an ES multicasts (to all ISs) a > request for an address, and one or more ISs can offer it an NSAP > "template" (basically an NSAP address with an NSEL of 00) from which > it may derive individual NSAP addresses. The fact that an NSAP is assigned > by an IS does not necessarily mean that the ES will use the address; > the ES will report the actual address chosen with an ESH. > > DIS 10733, network layer management, closed for DIS ballot on May 28. > The NO votes were accommodated, so the full IS should be published > out of this meeting. This document is the network layer MIB. > > CD 11577, the network layer security protocol, failed the CD ballot and > will need to go out for a second CD ballot. > > CD 10747, IDRP, has advanced to a DIS. The DIS text will include a > number of significant changes over the CD text, including the multiprotocol > extensions necessary for running IDRP for IP. The encoding of the > protocol ID field is such that it should support virtually any protocol > (it essentially grandfathers in NLPIDs, Ethertypes, and LSAPs). The > editor estimates that the DIS text should go out for six month ballot > by September, thus closing by March of next year. The DIS text should > be available in the next month or two. > > An initial contribution on the interaction between IDRP and IS-IS was > introduced. The general technical approach was accepted, and the > editors of IDRP and IS-IS will produce formal amendments for future > ballot. > > As discussed above, multicast addressing will be published for PDAM > ballot. Other standards potentially needing amendments to support > simple connectionless multicast transport include the connectionless > network and transport service definitions, CLNP, ES-IS, IS-IS, IDRP, > and the connectionless transport protocol. New work items will be > ballotted for the network service definition, CLNP, and ES-IS. New > work items for IS-IS and IDRP will not be issued until some base text > is available. Initial IS-IS text is likely to look a lot like the > multicast extensions to OSPF, unsurprisingly. > > Many fine lunches and dinners were enjoyed by the delegates, at least one > of whom was wearing jeans and a t-shirt. > -- 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 Jul 21 14:58:01 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23890; Tue, 21 Jul 1992 14:58: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 AA22198; Tue, 21 Jul 1992 13:57:07 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22392; Mon, 20 Jul 92 23:56:54 -0400 Date: Mon, 20 Jul 92 23:56:54 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207210356.AA22392@ginger.lcs.mit.edu> To: Hugh.Fisher@anu.edu.au, dcrocker@mordor.stanford.edu Subject: Re: Why not 64 bit IP? Cc: Big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu 96 bits is probably not enough for an 'address' (JNC definition) with topological significance, unless you divide it in fixed ways, and that is likely to bite you. E.g. which is better; 12 layers of one byte each, or 6 layers of two bytes each? The former will make any given layer run out too soon, the latter probably gives you not enough layers. Some layers with one, some with the other? How do you know which ones? Use masks? Management of that on that scale can get very tricky very quickly; ask the people who are starting to use variable width subnet masks. I really think a variable length parseable string of a variable number of variable length entries (no, not ASN.1 :-) is the way to go. Remember, I *DO NOT* expect these will be in every packet, any more than the DNS name is in every packet, and thus we won't be parsing them or needing the space for them very often. On the other hand, it's pretty long for a unique identifier. Just to amuse myself, I sat down with a calculator. Assuming the age of the universe is 15x10^9 years (and that my math is right :-), if we allocate one identifier per second out of a 2^96 space, you can allocate away for 10^11 universe ages! I.e., if you allocate one million a second, you *only* get 10^5 universe ages out of this space! 2^96 is a ***BIG*** number! 2^64 is smaller by a factor of 4x10^9, and so is on the hairy edge of being long enough. Dunno what to do exactly.... Noel From owner-Big-Internet@munnari.oz.au Tue Jul 21 15:31:13 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24649; Tue, 21 Jul 1992 15:31:24 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24641; Tue, 21 Jul 1992 15:31:13 +1000 (from dkatz@cisco.com) Received: by cider.cisco.com; Mon, 20 Jul 92 22:30:41 -0700 Date: Mon, 20 Jul 92 22:30:41 -0700 From: Dave Katz Message-Id: <9207210530.AA14630@cider.cisco.com> To: bmanning@is.rice.edu Cc: big-internet@munnari.oz.au In-Reply-To: William Manning's message of Mon, 20 Jul 92 22:53:19 CDT <9207210353.AA04736@is.rice.edu> Subject: ISO SC6 meeting tidbits (fwd) I think the disclaimer was edited out, namely that the SC6 meeting is still going on, and none of this is official until after the closing plenary at the end of the week. I also note a 3am error in the text on multicast addressing--it should say that every addressing authority would automatically end up with a block of multicast addresses equal in size to its block of unicast addresses. For the uninitiated, CDs and PDAMs are like proposed internet standards, and DISs and DAMs are like draft internet standards. The progression mechanism is by formal letter ballot; any NO vote must be accompanied by comments explaining the technical reasoning behind the vote, and such votes are often reversed by having the editor take the comments into account. From owner-Big-Internet@munnari.oz.au Tue Jul 21 22:31:37 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05704; Tue, 21 Jul 1992 22:31:49 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207211231.5704@munnari.oz.au> Received: from datanet.tele.fi by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA05700; Tue, 21 Jul 1992 22:31:37 +1000 (from Juha.Heinanen@datanet.tele.fi) Received: from datanet.tele.fi by datanet.tele.fi id <24906-0@datanet.tele.fi>; Tue, 21 Jul 1992 13:26:47 +0300 To: dkatz@cisco.com Cc: bmanning@is.rice.edu, big-internet@munnari.oz.au In-Reply-To: <9207210530.AA14630@cider.cisco.com> "dkatz@cisco.com" Subject: ISO SC6 meeting tidbits (fwd) Date: Tue, 21 Jul 1992 13:26:47 +0300 From: Juha Heinanen Sender: Juha.Heinanen@datanet.tele.fi dave, what is the current status of the IP AFI? i think it would be useful for many purposes in addition to TUBA if there were an ISO way to write an IP address. of course one could get a DCC for ISOC, but i would prefer an AFI. -- juha From owner-Big-Internet@munnari.oz.au Tue Jul 21 23:06:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06585; Tue, 21 Jul 1992 23:06:37 +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 AA06574; Tue, 21 Jul 1992 23:06:15 +1000 (from bmanning@is.rice.edu) Received: by is.rice.edu (AA09570); Tue, 21 Jul 92 08:05:37 CDT From: bmanning@is.rice.edu (William Manning) Message-Id: <9207211305.AA09570@is.rice.edu> Subject: Re: ISO SC6 meeting tidbits (fwd) To: Juha.Heinanen@datanet.tele.fi (Juha Heinanen) Date: Tue, 21 Jul 92 8:05:37 CDT Cc: big-internet@munnari.oz.au In-Reply-To: <9207211231.AA09372@is.rice.edu>; from "Juha Heinanen" at Jul 21, 92 1:26 pm X-Mailer: ELM [version 2.3 PL11] Juha Heinanen > > dave, > > what is the current status of the IP AFI? > > -- juha > Apparently the IETF (or some WG) was asked some time back if it wanted an AFI and they (we) declined. I asked Lyman if he would re-open this request, since there now seems to be more interest in this sort of thing. I understand that he will pursue the request. -- 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 Wed Jul 22 03:09:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14281; Wed, 22 Jul 1992 03:10:09 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14270; Wed, 22 Jul 1992 03:09:54 +1000 (from dkatz@cisco.com) Received: by cider.cisco.com; Tue, 21 Jul 92 10:09:39 -0700 Date: Tue, 21 Jul 92 10:09:39 -0700 From: Dave Katz Message-Id: <9207211709.AA25120@cider.cisco.com> To: Juha.Heinanen@datanet.tele.fi Cc: bmanning@is.rice.edu, big-internet@munnari.oz.au In-Reply-To: Juha Heinanen's message of Tue, 21 Jul 1992 13:26:47 +0300 <9207211231.5704@munnari.oz.au> Subject: ISO SC6 meeting tidbits (fwd) The IP AFI was killed by general agreement. It had a fundamental technical flaw, namely that the IDI is a decimal field, into which it is difficult to put a binary IP address. I think that an ICD for ISOC is probably the only way to do it, given the, um, interesting OSI addressing scheme. For what it's worth, there was concern among the ISO delegates that this move would be viewed as a snub against the internet community, so a liason letter will be sent stressing SC6's desire to work in concert with the internet communitiy. Note that this AFI is not needed when routing native IP with OSI routing protocols; both IS-IS and IDRP carry IP addresses in native IP format. From owner-Big-Internet@munnari.oz.au Wed Jul 22 06:35:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19098; Wed, 22 Jul 1992 06:35:12 +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 AA19095; Wed, 22 Jul 1992 06:35:06 +1000 (from bac@SDSC.EDU) Received: from sluggo.sdsc.edu by shark.mel.dit.csiro.au with SMTP id AA07488 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 22 Jul 1992 06:35:17 +1000 Received: from serendip.sdsc.edu by sluggo.sdsc.edu (4.1/4.7) id AA04226; Tue, 21 Jul 92 13:26:11 PDT From: Bilal Chinoy Message-Id: <9207212026.AA04226@sluggo.sdsc.edu> Subject: Re: small question/clarification re. ddc idea and state To: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Date: Tue, 21 Jul 92 13:30:50 PDT Cc: ddc@lcs.mit.edu, estrin@usc.edu, big-internet@munnari.oz.au In-Reply-To: <9207180359.AA09576@chiya.bellcore.com>; from "Paul Tsuchiya" at Jul 17, 92 11:59 pm The NSFnet routers *did* play with source-destination based caches. I seem to remember war stories of the type "I can get from A to B, but not from C to B", where A and C are machines on the same subnet, and some transit NSFnet router choked on the C to B flow. I looked into precisely the problem of maintaining source-destination based state in the routes and the size of the information base. If I remember correctly, I was seeing on the order of 18,000 to 20,000 active host flows per 3 minute intervals, during peak times. TCP conversations lasted on the order of a few minutes on the average, and the (hypothetical) cache hit rates used to be decent. Flows were concentrated and a few hosts in a few nets exchanged a bulk of the total traffic carried. This was when the net had about 4000 networks in it's database, and who knows how many hosts were in the universe. The point being .. If you take advantage of source-destination locality and traffic patterns, then the cache refresh rate and sheer size may not be a burden. And, as Dave points out, it is a cache. The penalty you pay (installation of an entry, or sending of an ICMP message or whatever contol mechanism) and the potential slower lookup maybe offset by the gain in flow semantics. Cheers, -- Bilal ps. I seem to remember the "congram" approach espoused by Guru Parulkar and others embodied some of the semantics we are discussing here. > > > > > Second, they are just cache entries, and if one gets tossed, you can still > > forward the packet. (The ones where the state did not come from the packet > > should be more stickey.) > > But much more slowly, since the point behind the CI is faster > forwarding not VCI per se. Seems to defeat the purpose of the > CI in those cases where the cache is too small. > > > > > Third, I suspect that the explosion in the number of entries would actually > > be small. Lets look at what it would mean if we used my scheme to replicate > > exactly what we do today: simple destination routing. Whereas now there is > > one entry per destination, in my scheme there would be some number per > > source-destination pair. How bad would that be? > > But, today the destinations are one per network, and in the near future > may be one per backbone (since per/network isn't scaling nicely). But, > with CI, it is one per source-dest HOST pair. So, scaling is much worse. > > Unless perhaps you mean by this that all routers hash and cache the > results of IP address lookups on a per dest host basis. But, my > understanding is that NSFnet routers do not cache, precisely because > the number of individual host flows is too large. > > Can somebody confirm this? > > PT > From owner-Big-Internet@munnari.oz.au Wed Jul 22 06:45:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19455; Wed, 22 Jul 1992 06:46:00 +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 AA19452; Wed, 22 Jul 1992 06:45:50 +1000 (from bsimpson@angband.stanford.edu) Received: from via.ws04.merit.edu by Angband.Stanford.EDU (5.65/inc-1.0) id AA08931; Tue, 21 Jul 92 13:45:20 -0700 Date: Tue, 21 Jul 92 12:42:55 EDT From: "William Allen Simpson" Message-Id: <566.bsimpson@angband.stanford.edu> To: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Cc: big-internet@munnari.oz.au Reply-To: bsimpson@angband.stanford.edu Subject: Re: Route fragments, a routing proposal > I disagree that any AS numbering scheme is hierarchical. Even ISO NSAPs > are not hierarchical within the Government AFI and IFI. More to the point > the commercialmodel of the world is likely to be pairs of binary administ- > rative relationships between AS's. (Because more complicated businessrelation > ships increase the # of lawyerspast the threshold for progress). These > pairs may be weakly coupled to topology or maybe not. > I think you are confusing the terms heirarchical and topological. The AS number is heirarchical in nature *because* it is unique at a point in a heirarchy; in this case, the "root", even if no physical root exists. All other addresses are found below this layer. The AS numbers are not currently topologically assigned. Indeed, one might be entirely behind another, as seen from any particular backbone. I'm suggesting loose topological assignment, geographically based. The administrative relationships might not be any better than the current organization. But if there *is* topological assignment, at least there is a *chance* that inter-AS route folding may occur. At the very least, intercontinental route folding. And if we keep the layer numbers small enough (octet size), it won't matter if the numbers are imperfectly distributed. A table search of 256 is a lot faster than a table search of 65000, and hash lookups might be avoided altogether. Furthermore, if the AS numbers are also assigned based on AUP attributes within the topological/geographic areas, the administrative pairing becomes much easier. I don't want to create a scheme which encourages formulation of extremely complicated policy. Bill_Simpson@um.cc.umich.edu bsimpson@ray.lloyd.com From owner-Big-Internet@munnari.oz.au Thu Jul 23 07:20:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28695; Thu, 23 Jul 1992 07:21:11 +1000 (from owner-Big-Internet) Return-Path: Received: from animal.clearpoint.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28683; Thu, 23 Jul 1992 07:20:59 +1000 (from solensky@animal.clearpoint.com) Received: by animal.clearpoint.com (4.1/1.34) id AA14270; Wed, 22 Jul 92 17:16:20 EDT Date: Wed, 22 Jul 92 17:16:20 EDT From: solensky@animal.clearpoint.com (Frank T. Solensky) Message-Id: <9207222116.AA14270@animal.clearpoint.com> To: clynn@bbn.com Subject: Re: Another Proposal In-Reply-To: Mail from 'Charles Lynn ' dated: Thu, 16 Jul 92 12:06:03 EDT Cc: big-internet@munnari.oz.au > Moving Toward a Solution to the Internet Growth Problem > Using IPv4 >... >There are so many similarities between the techniques used in this message and >other proposals before the community that if this proposal "won't >work" then the other proposals will need reevaluation or redesign. > Anyone else remember a National Lampoon cover from a few years back: "Buy this magazine or we shoot the dog"? Seriously, though: while the proposal has some merit, it doesn't give the scaling into 64-bit addressibility that it initially appears to. As I understand it, you're using a 32-bit IP address of a router as the top of the address and the real IP destination as the bottom 32 bits. This is a path rather than a true heirarchy; thus, you'd only actually generate 32-bits worth of IP address space. Let me clarify by your illustration: the only 64-bit address that would end with the address of 'Host C' would be the one that starts with 'NAP-3'. Adding a Source Route option to a packet halfway to its destination seems like a dangerous proposition since you can't differentiate between the one that may have been supplied by the originating system and the one that was inserted along the way. Further, if there are already some options in the packet, you may not have enough space left in the header to insert the one you want to add. Does this cause some sites to become reachable only when the length of the options is less than some amount and fail with longer headers? PS: I've looked through the ST-II spec for an indication that this is already being done there and couldn't find it. Could you elaborate? >We might benefit by considering the separation of >routing topology updates from routing connectivity updates. Remove >route computation form the forwarding boxes. Load the routes from >some server with the routes they need, or let them query for the >information on an as needed basis. Let them keep track of "how to get >to X" and "how to get to X if the primary path has failed" with the >latter being something that is determined "locally". One can envision >a big machine computing a "global" or "neighborhood" routing topology >and making it available (for sale?) to the forwarding boxes. The >space saved by removal of the routing protocol code and "full" routing >tables can be used to process source route options and make bigger >caches. Maybe I'm misunderstanding, but it seems like what you're suggesting here is static routes. I'd think that you'd still want to have some routing protocols running so that you don't wind up forwarding packets into links that may be down or missing ones that have been created since the last (purchased?) update. The idea of selling the updates doesn't seem feasible, either: the topology may then be a function of who's got current information and who doesn't. -- Frank From owner-Big-Internet@munnari.oz.au Thu Jul 23 09:41:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03435; Thu, 23 Jul 1992 10:03:32 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207230003.3435@munnari.oz.au> Received: from syacus.acus.oz (via basser) by munnari.oz.au with SunIII (5.83--+1.3.1+0.50) id AA03428; Thu, 23 Jul 1992 10:03:24 +1000 (from andrewf@syacus.acus.oz.au) From: andrewf@syacus.acus.oz.au Subject: NSAP AFI for IP (was: ISO SC6 meeting tidbits) To: dkatz@cisco.com@munnari.OZ.AU Date: Thu, 23 Jul 92 9:41:04 EST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9207211709.AA25120@cider.cisco.com>; from "Dave Katz" at Jul 21, 92 10:09 am Dave, > > The IP AFI was killed by general agreement. It had a fundamental technical > flaw, namely that the IDI is a decimal field, into which it is difficult > to put a binary IP address. I think that an ICD for ISOC is probably the > only way to do it, given the, um, interesting OSI addressing scheme. > >... Hmm. I would say a minor blemish. There's nothing to stop you having a single decimal fixed IDI (Initial Domain Identifier) and representing the IP address in the DSP (Domain Specific Part) except the OSI "right way". The field could even be put to good use, using decimal values to indicate the style of IP address contained within e.g. old (current) style, new style topology independant, new style with country routing hint, new style with country and regional network routing hint. The new style IP addresses are just products of my imagination. I seem to remember that an IDI is not required, AFI=49 consists of only a DSP, does it not? Alternatively, one could use the wierd (clever?) OSI scheme for representing binary addresses in decimal. And gee whiz, they could always change the rules (again). Sure, AFI=47 is the "right" way to do it, but if the CCITT can have AFIs for their networking technologies, why can't we? (How does the size of the Internet and other private and semi-private networks, compare with the size of say the CCITT X.25 network?) BTW, I hope that any allocations of a future IP NSAP, would require that the NSAP actually be reachable from the Internet if it is reachable at all, unlike the existing NSAP types which encapsulate sub-network addresses. Regards, Andrew -- | Tel: +61 2 390 1338 | Internet: andrewf@syacus.acus.oz.au Andrew Friedman | Fax: +61 2 390 1391 | ACSnet: andrewf@syacus.acus.oz From owner-Big-Internet@munnari.oz.au Thu Jul 23 12:10:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07424; Thu, 23 Jul 1992 12:10:39 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207230210.7424@munnari.oz.au> Received: from BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07421; Thu, 23 Jul 1992 12:10:32 +1000 (from lyman@BBN.COM) From: "Lyman Chapin" Subject: Re: ISO SC6 meeting tidbits (fwd) To: bmanning@is.rice.edu Cc: big-internet@munnari.oz.au, Juha.Heinanen@datanet.tele.fi In-Reply-To: <9207211305.AA09570@is.rice.edu> Date: Wed, 22 Jul 92 17:28:02 EDT Mail-System-Version: >From: bmanning@is.rice.edu (William Manning) >Subject: Re: ISO SC6 meeting tidbits (fwd) >To: Juha.Heinanen@datanet.tele.fi (Juha Heinanen) >Date: Tue, 21 Jul 92 8:05:37 CDT >Cc: big-internet@munnari.oz.au > >Juha Heinanen >> >> dave, >> >> what is the current status of the IP AFI? >> >> -- juha >> > >Apparently the IETF (or some WG) was asked some time back if it wanted >an AFI and they (we) declined. I asked Lyman if he would re-open this >request, since there now seems to be more interest in this sort of thing. >I understand that he will pursue the request. > >-- >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 did, but having just gone through a cycle in which an "IP" AFI was proposed, then abandoned because the IP address doesn't fit neatly into the decimal-encoded IDI field, the ISO folks decided to put this on hold until they understand better exactly what the IETF wants the resulting NSAP address to look like. If we figure this out, I have no doubt that the ISO WG will be glad to oblige. - Lyman From owner-Big-Internet@munnari.oz.au Thu Jul 23 16:51:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16100; Thu, 23 Jul 1992 16:51:15 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207230651.16100@munnari.oz.au> Received: from rschp1.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA16097; Thu, 23 Jul 1992 16:51:11 +1000 (from hugh@rschp1.anu.edu.au) Received: by rschp1.anu.edu.au (16.8/16.2) id AA17545; Thu, 23 Jul 92 16:49:52 +1000 From: Hugh Fisher Subject: Pip looks like 64 bit IP To: big-internet@munnari.oz.au Date: Thu, 23 Jul 92 16:49:52 EST Mailer: Elm [revision: 70.30] Thank you to everyone who replied to my posting about 64 bit IP. The references have been very educational. As an app programmer, the Chiappa draft and Pip proposal look just like an upwardly compatible IP scheme. Both would separate the network address from a globally unique 64 bit node/end system identifier. Since I regard the current IP addresses as just such "magic cookies" to pass around, I wouldn't notice any difference when the system changed. (Assuming the old IP addresses were still valid as part of the new node/end system identifier space.) Both these documents say it would be possible to plug in mobile PCs anywhere in the Net without changing their identifier...great! On the other hand the EIP proposal says that old IP host identifiers will cease to be globally unique after a while, and the messages about CLNP seem to assume that the network address is the same as the host. Not so good. OK, that's one(1) application programmer vote for Pip/Nimrod. Hugh Fisher From owner-big-internet@munnari.oz.au Thu Jul 23 16:55:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA16245; Thu, 23 Jul 1992 16:55:46 +1000 (from owner-big-internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14787; Thu, 23 Jul 1992 16:11:22 +1000 (from dkatz@cisco.com) Received: by cider.cisco.com; Wed, 22 Jul 92 23:11:00 -0700 Date: Wed, 22 Jul 92 23:11:00 -0700 From: Dave Katz Message-Id: <9207230611.AA17284@cider.cisco.com> To: andrewf@syacus.acus.oz.au Cc: big-internet@munnari.OZ.AU In-Reply-To: andrewf@syacus.acus.oz.au's message of Thu, 23 Jul 92 9:41:04 EST <9207230003.3412@munnari.oz.au> Subject: NSAP AFI for IP (was: ISO SC6 meeting tidbits) Hmm. I would say a minor blemish. There's nothing to stop you having a single decimal fixed IDI (Initial Domain Identifier) and representing the IP address in the DSP (Domain Specific Part) except the OSI "right way". The field could even be put to good use, using decimal values to indicate the style of IP address contained within e.g. old (current) style, new style topology independant, new style with country routing hint, new style with country and regional network routing hint. The new style IP addresses are just products of my imagination. I seem to remember that an IDI is not required, AFI=49 consists of only a DSP, does it not? Alternatively, one could use the wierd (clever?) OSI scheme for representing binary addresses in decimal. And gee whiz, they could always change the rules (again). Sure, AFI=47 is the "right" way to do it, but if the CCITT can have AFIs for their networking technologies, why can't we? (How does the size of the Internet and other private and semi-private networks, compare with the size of say the CCITT X.25 network?) The OSI addressing structure provides for distributed allocation authorities. AFI 49 is special, because ISO/CCITT explicitly says "nobody controls this space" and so there is no explicit delegation of addressing authority. The semantics of an IP address in the IDI would be that the owner of a particular IP address would be able to assign DSP values (similar to the X.121, E.164, etc., formats)--authority would be delegated to the owners of IP addresses (and explicitly *not* the authority responsible for IP address allocation, BTW). In order for ISOC (for example) to be given a piece of the addressing tree, there needs to be a code point that has the semantics of "ISOC owns this." Right now, all AFIs are owned by ISO and/or CCITT. If ISO were to give ISOC an AFI, it would require an amendment to the addressing standard (8348 Ad. 2) granting that ownership. Note that this is semantically a bit different from the original IP AFI, in which ISO maintained ownership of the AFI (thus being able to define its IDI as being an IP address). It would be possible, although unprecedented, for ISO to assign an AFI value to ISOC; I don't pretend to understand the political implications of this. One possibility is that ISO would require ISOC to become a bona fide standards organization before this could take place. It's a *much* simpler thing for ISOC to get something a bit lower on the addressing hierarchy; an ICD value is the obvious and appropriate choice-- ISOC would seem to satisfy the requirements for an ICD value, and this is a simple code point assignment (drawn from 10,000 possible values rather than 90). Yes, it costs two octets, but that doesn't seem to me to be a big deal--this is CLNP, after all. :-) [You could imagine assigning the fourth octet to be a version number a la GOSIP, and then you'd even have longword alignable addresses...] BTW, I hope that any allocations of a future IP NSAP, would require that the NSAP actually be reachable from the Internet if it is reachable at all, unlike the existing NSAP types which encapsulate sub-network addresses. If the IP-within-IDI scheme had gone forward, the addressing standard would, as you point out, say that there is no implication that the NSAP be reachable at that IP address; however, this does not constrain service providers from making this assumption and, for instance, using IP routing tables. I would be free to assign an NSAP to my CLNS toaster based on the address of my IP workstation; however, my CLNS network provider might not care to route to my toaster (or charge me up the wazoo for carrying around the exception information to the general routing rules). Explicitly tying the two addresses together does not belong in the ISO addressing document; it can be enforced by other means. From owner-Big-Internet@munnari.oz.au Thu Jul 23 23:05:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08921; Thu, 23 Jul 1992 23:05: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 AA08917; Thu, 23 Jul 1992 23:05:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA19779; Thu, 23 Jul 92 09:05:02 -0400 Date: Thu, 23 Jul 92 09:05:02 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207231305.AA19779@ginger.lcs.mit.edu> To: Hugh.Fisher@anu.edu.au, big-internet@munnari.oz.au Subject: Re: Pip looks like 64 bit IP Cc: jnc@ginger.lcs.mit.edu On the other hand the EIP proposal says that old IP host identifiers will cease to be globally unique after a while, Well, there's really no way around this in the long run in any scheme. Sooner or later there will be more than 2^32 hosts, right? and the messages about CLNP seem to assume that the network address is the same as the host. Not so good. Well, the TUBA scheme seems to say (TUBAites please correct my probable misapprehensions :-) that the NSAP field of the CLNP header will always have a 48 bit host- as part of it, and the TCP/UDP checksums in TUBA would include that field, and no other. It's not clear exactly how far this would go towards having real host-identifiers; e.g. would packets from two different NSAP's with the same 48-bit field go to the same TCP connection? Noel From owner-Big-Internet@munnari.oz.au Thu Jul 23 23:47:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA10262; Thu, 23 Jul 1992 23:47:55 +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 AA10259; Thu, 23 Jul 1992 23:47:47 +1000 (from swb@nr-tech.cit.cornell.edu) Received: from MITCHELL.CIT.CORNELL.EDU by mitchell.cit.cornell.edu (4.1/1.34/Honig-1.3) id AA12233; Thu, 23 Jul 92 09:47:18 EDT Message-Id: <9207231347.AA12233@mitchell.cit.cornell.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Hugh.Fisher@anu.edu.au, big-internet@munnari.oz.au Reply-To: swb@nr-tech.cit.cornell.edu Subject: Re: Pip looks like 64 bit IP In-Reply-To: Noel Chiappa's message of Thu, 23 Jul 92 09:05:02 -0500. <9207231305.AA19779@ginger.lcs.mit.edu> Date: Thu, 23 Jul 92 09:47:16 -0400 From: Scott Brim Noel, I'll dare to answer for Ross, and he can correct me later. >Well, the TUBA scheme seems to say (TUBAites please correct my probable >misapprehensions :-) that the NSAP field of the CLNP header will always have >a 48 bit host- as part of it, and the TCP/UDP checksums in TUBA >would include that field, and no other. It's not clear exactly how far >this would go towards having real host-identifiers; e.g. would packets from >two different NSAP's with the same 48-bit field go to the same TCP connection? Yes, sort of. Since the id field is unique (and he really does want this), then you would only send packets to that id to an address you knew would work, and you would only send to two different addresses if the destination host were roaming. At any particular time you would only send to one address, the one which you were most recently told was most efficient. Scenario: you send a packet to the host's "base" address, and either you do some setup with that address (or that host's agent in its base domain, or something) or immediately go to the next step, in which you receive a packet from the roaming host specifying a source address which reflects where it really is at that time. You don't recognize this address, so you scan your recently active address list (tree ...) for something with the same ID, and for a while after that (set a timer, do an LRU, ...) you use the new roaming address as a preferred substitute for the home address. This is also a way for a multihomed receiving host to tell the sending host which of its entry points it wants to receive traffic on for that particular interaction. Scott From owner-Big-Internet@munnari.oz.au Fri Jul 24 07:15:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21819; Fri, 24 Jul 1992 07:15:18 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207232115.21819@munnari.oz.au> Received: from CLynn.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21798; Fri, 24 Jul 1992 07:15:06 +1000 (from clynn@BBN.COM) Date: Thu, 23 Jul 92 17:11:31 EDT From: Charles Lynn To: "Frank T. Solensky" Cc: clynn@BBN.COM, big-internet@munnari.oz.au Subject: Re: Another Proposal Frank, > Seriously, though: while the proposal has some merit, it doesn't > give the scaling into 64-bit addressibility that it initially appears to. > As I understand it, you're using a 32-bit IP address of a router > as the top of the address and the real IP destination as the bottom 32 bits. > This is a path rather than a true hierarchy; thus, you'd only actually > generate 32-bits worth of IP address space. > Let me clarify by your illustration: the only 64-bit address that > would end with the address of 'Host C' would be the one that starts with > 'NAP-3'. In the end, no. HOST A (on NET X) and HOST E (on NET Z) could have the same 32-bit identifier as HOST C (on NET Y). If A wants to communicate with C, A would look up in the DNS its ID, A-record = "HOST C", and Address, NAP-records = "NAP-1", "NAP-2", as well as that of C, A-record = "HOST C" and NAP-record = "NAP-3". It builds an IP packet with Src = "HOST C", Dst = "NAP-2", LSR = ptr-> "NAP-3", "HOST C" and sends it off. (I'm ignoring here how A makes a selection between NAP-1 and NAP-2 as the decision is orthogonal to your question.) It gets routed via NAP-2 and NAP-3 to C, which would receive an IP packet with Src = "HOST C", Dst = "HOST C", LSR = "NAP-2", ptr->". Replies to A would be received at A as Src = "HOST C", Dst = "HOST C", LSR = "NAP-3", ptr->". However we are not at the "end", and will have to go through a transition phase to get there. My personal opinion is that I never want to get to the "end" with this proposal -- I want a real successor to IPv4 that has security, policy, guaranteed services (=> accounting), nice routing, addressing, identification, etc. Remember, this proposal is hopefully minimal cost to keep us going if the community cannot bring things together in time. During the transition we would like to not require that all hosts wishing to communicate be modified (as seems to be the case with IPv7, NIMROD, PIP and TUBA++ proposals). The agent to be modified in this proposal, as well as EIP and IP Encapsulation, is a "border router". One difference between the latter appears to be that only the source route choice does not require a peer to undo the mapping, e.g., remove the encapsulation or understand the new extended address option. The issue here is whether we can incrementally deploy our solution -- do we have to change all the "border routers" attached to the NSFNet backbone, or a regional, "at the same time"? Can we do it? Scaling is an issue -- can we do adequate testing before throwing the switch? Can we back out? To work, the "border router" must be able to use the IP Dst to map to the NAPs. To work correctly ALL the time, this requires that the 32-bit ID be unique. I believe it would be a poor engineering choice to deliberately duplicate the low 32 bits, or have overlap between the high 32-bits and the lower, before we have to; in that sense, yes, we are still using a 32-bit address space. One can make arguments about how things could be made to work MOST of the time if that is an interesting topic. What is an acceptable level of "wrong numbers"? The successor to IPv4 better have authentication. > Adding a Source Route option to a packet halfway to its destination > seems like a dangerous proposition since you can't differentiate between > the one that may have been supplied by the originating system and the one > that was inserted along the way. Well, if the originating system is supplying source routes, then we have evidence that the functionality is implemented & works. ;-) Why do you feel that we need to be able to differentiate how the routing was derived? If this is really an issue here, it might also be one for schemes to provide support for policy. > Further, if there are already some options in the packet, you may not > have enough space left in the header to insert the one you want to add. This may be an issue. Is anyone in a position, and willing, to monitor packets, e.g., entering the NSFNet backbone, or a regional, to record the IP Header Length bits so we can get some hard data? The next version of IP ought to have more room for options. In the current Internet, we do not even have enough space for an end-to-end Record Route option. > Does this cause some sites to become reachable only when the length of > the options is less than some amount and fail with longer headers? We might want to add an ICMP message for this, or use Parameter Problem. If the cause of the failure is clearly reported how much of a problem is it? Is it worth spending much of our resources to "solve" before IP++ arrives? > PS: I've looked through the ST-II spec for an indication that this > is already being done there and couldn't find it. Could you elaborate? RFC 1190 specifies the format of data to be interchanged and how that data might be used. It tries to only specify things needed for interoperability and to leave everything else as areas of possible research. The source routing parameters -- strict and loose for both ST and IP Encapsulated ST (pg 95) -- may appear multiple times in the specification for a target (pg 97). This source-supplied routing information may be combined with source routes from the routing table. The code to do the merge is in the BBN ST-II implementation, but has not been tested since the BSD "routing" table only provides next-hop forwarding information. The source routing has been used in DARTNet to connect sites whose network is not being advertised globally. Does this answer your question or are you asking for an algorithm? > >We might benefit by considering the separation of > >routing topology updates from routing connectivity updates. Remove > >route computation form the forwarding boxes. Load the routes from > >some server with the routes they need, or let them query for the > >information on an as needed basis. Let them keep track of "how to get > >to X" and "how to get to X if the primary path has failed" with the > >latter being something that is determined "locally". One can envision > >a big machine computing a "global" or "neighborhood" routing topology > >and making it available (for sale?) to the forwarding boxes. The > >space saved by removal of the routing protocol code and "full" routing > >tables can be used to process source route options and make bigger > >caches. > > Maybe I'm misunderstanding, but it seems like what you're suggesting here > is static routes. I'd think that you'd still want to have some routing > protocols running so that you don't wind up forwarding packets into links > that may be down or missing ones that have been created since the last > (purchased?) update. From what I've read on this list, the "routing table explosion" / "route aggregation" and the "lack of Class B addresses" problems are more sever that running out of IP addresses. CIDR should take care of the Class B problem. Something seems very wrong about the "routing table explosion" problem. What do we have today 6-7,000 networks? If it doubles every year for 3 years we get 56,000 nets. A brute force table of tuples is less than half a MByte. Put a cache in front of it for speed. This still seems like a drop in the bucket, especially if one is a major backbone or regional provider. This leads me to speculate that the real problem is something else. Is it the way that the tables are maintained? The way updates are distributed? What is the real problem we are trying to solve? How robust must the system be to meet our specified level of service; do we even have such a requirement? How many routers have to fail before we say, ok, the connect cannot be completed now so I'll try later? Maybe topology updates on the order of a week (or however long it takes to get a network number assigned) with failure detection and quick (pre computed) backup route selection is sufficient. If so, what do we need in the next IP to make it work? > The idea of selling the updates doesn't seem feasible, either: the topology > may then be a function of who's got current information and who doesn't. I think you mean "routing" instead of "topology". Information has value. If one can pay a route server for a route that can reduce the cost of an instance of communication by more than the cost of the information and meet your policy requirements, etc., would systems use it? My crystal ball is a little cloudy. Charlie From owner-Big-Internet@munnari.oz.au Fri Jul 24 08:42:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA24075; Fri, 24 Jul 1992 08:42:25 +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 AA24065; Fri, 24 Jul 1992 08:42:09 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA26680; Thu, 23 Jul 92 15:41:58 -0700 Received: by us1rmc.bb.dec.com; id AA17533; Thu, 23 Jul 92 18:40:17 -0400 Message-Id: <9207232240.AA17533@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Thu, 23 Jul 92 18:40:18 EDT Date: Thu, 23 Jul 92 18:40:18 EDT From: Ross Callon To: swb@nr-tech.cit.cornell.edu, big-internet@munnari.oz.au Cc: callon@bigfut.enet.dec.com Apparently-To: swb@nr-tech.cit.cornell.edu, big-internet@munnari.oz.au Subject: re: 48-bit IDs and TUBA (was: Pip looks like 64 bit IP) > > ...Noel, I'll dare to answer for Ross, and he can correct me later. > My pleasure. > >Well, the TUBA scheme seems to say (TUBAites please correct my probable > >misapprehensions :-) that the NSAP field of the CLNP header will always have > >a 48 bit host- as part of it, and the TCP/UDP checksums in TUBA > >would include that field, and no other. It's not clear exactly how far > >this would go towards having real host-identifiers; e.g. would packets from > >two different NSAP's with the same 48-bit field go to the same TCP connection? > > Yes, sort of. Since the id field is unique (and he really does want > this), then you would only send packets to that id to an address you > knew would work, and you would only send to two different addresses if > the destination host were roaming. At any particular time you would > only send to one address, the one which you were most recently told was > most efficient. > Well, for discussion purposes we might separate what is a necessary part of the TUBA scheme, and what I would personally recommend. TUBA is really just a way to transition to some datagram IP with bigger addresses than the current IP. I would personally recommend that we transition to CLNP, and that we separate the CLNP (NSAP) addresses into a "globally unique ID" and a "location". > > Scenario: you send a packet to the host's "base" address, and either you > do some setup with that address (or that host's agent in its base > domain, or something) or immediately go to the next step, in which you > receive a packet from the roaming host specifying a source address which > reflects where it really is at that time. You don't recognize this > address, so you scan your recently active address list (tree ...) for > something with the same ID, and for a while after that (set a timer, do > an LRU, ...) you use the new roaming address as a preferred substitute > for the home address. > I see separation of the host identifier from the host location as useful for several different purposes (all of which would be possible without this separation, they are just made easier if we make the separation). The things that this makes easier include: - Automatic configuration of the host address (including automatic re-configuration of the address when it changes). The notion here is that the host somehow already knows its globally unique ID, and the ID stays the same even if the address otherwise changes. The location part of the address is auto-configured. - Mobile hosts: Specifically, this works *almost* the same as the existing IP mobile host scheme, but eliminates the need for encapsulation (or source routing, if comparing with Yakov's proposal). Also, this can eliminate the need for some sort of redirect message to allow a host to automatically find out when the host that it is talking to has moved (and a new address should be used, eg for packets relating to an existing connection). - What I have been calling 'Mobile routing domains': Basically, if there are too many routing domains worldwide to maintain a route to all of them, then you likely will use some sort of hierarchical addressing scheme which maintains a single route entry for multiple domains (for example, the IP addressing BOF at the IETF last week talked about assigning future IP network numbers based on the public network provider which a routing domain is attached to, allowing one route entry for multiple routing domains attached to the same provider). However, if you do this, then when a routing domain changes which provider it is attached to, then its address either will need to change, or will be "wrong" in some sense. Thus you will want to have a way that systems which are still using the "wrong" address can have their packets delivered correctly, and quickly find out how to send future packets quickly to the correct location. This can be accomplished by having a "changing address server" intercept the packet sent to the old address, and insert the correct "location" part of the address instead of the older incorrect location. In a sense, a "mobile host" is a host who's address changes. We think of this as having the address change because the host moves physically. However, if instead the address changes due to a change in the network hierarchy, then very similar mechanisms can be used to allow graceful continued operation. > > This is also a way for a multihomed receiving host to tell the sending > host which of its entry points it wants to receive traffic on for that > particular interaction. > Gee, I hadn't thought of this use. I would not be surprised if there are other uses as well. I think that Noel made the point well. Addresses are used for a bunch of different things. Sometimes when you have one function trying to do two things it makes more sense to have two functions do two things independently, just in case you want to change one without changing the other. To go back to Noel's point: > > ...that the NSAP field of the CLNP header will always have > >a 48 bit host- as part of it, and the TCP/UDP checksums in TUBA > >would include that field, and no other. My suggestion is that the NSAP address used in the CLNP header will always have a 48 bit globally unique host identifier in it. There are a couple of places that you might get the host identifier. As was discussed in a previous flurry of messages, it is probably BAD BAD BAD to assume that the ID is more than just a unique identifier (for example, if you take the ID from the 48-bit IEEE space, then you might by coincidence have a system which uses the same 48 bit value for both its unique host ID, and as its Ethernet address, but you can't require or count on this happy coincidence). Whether the TCP/UDP checksums only include the ID, or the ID plus the location, is a detail which a working group should determine. If the TCP/UDP checksum were to include the location as well, then this would require that "mobile host servers" or "address change servers", when they change the location part of the address (since the host has moved or changed addresses), would need to correct the TCP/UDP checksum. Given that the address is (of course) part of the network header, the network (CLNP) checksum would also need to be corrected (fortunately both the TCP and CLNP checksums can be incrementally updated). > >It's not clear exactly how far > >this would go towards having real host-identifiers; e.g. would packets from > >two different NSAP's with the same 48-bit field go to the same TCP connection? My intention is that this would really be a unique and globally meaningful ID. Thus, two different incoming TCP packets with the same IDs (for both source and destination) would indeed go to the same TCP connection. Ross From owner-Big-Internet@munnari.oz.au Fri Jul 24 10:51:00 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28134; Fri, 24 Jul 1992 10:51:09 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA28129; Fri, 24 Jul 1992 10:51:00 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28486; Thu, 23 Jul 92 20:50:52 -0400 Date: Thu, 23 Jul 92 20:50:52 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207240050.AA28486@ginger.lcs.mit.edu> To: clynn@bbn.com, solensky@animal.clearpoint.com Subject: Re: Another Proposal Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I don't have time to reply in detail to this, but a few points: HOST A (on NET X) and HOST E (on NET Z) could have the same 32-bit identifier as HOST C (on NET Y). I must confess I didn't have time (what with other things going on offstage) to parse the original proposal. I'm not sure I'm catching this, then, but is it in fact true that there are no globally unique identifiers? During the transition we would like to not require that all hosts wishing to communicate be modified (as seems to be the case with .. NIMROD ... proposals). This is news to me. Nimrod only *requires* hosts to be changed if they wish to communicate with endpoints which cannot be expressed in 32 bits, and even this only happens in the 32->64 bit identifier upgrade stage (see section 7.3 of the Nimrod doc), which would be part of a way-off upgrade to a new IP with resource allocation, security and auto-configuration architecture, etc. There is no way that I know of to have more than 2^32 hosts in the system network-wide without requiring some changes to hosts at some point unless you have a NAT type solution, which patches into the DNS and has locally significant only 32 bit thingys in IP packets. Since hosts are currently generating packets with only 32-bit quantities, and expecting that to completely specify the destination, there's *no* way to get around that 2^32 limit without either a) changing the hosts, or b) making the 32-bit quantities locally significant only, and using magic outside the hosts to get the extra significance, which almost certainly means tying into the DNS. Noel From owner-big-internet@munnari.oz.au Fri Jul 24 11:28:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29304; Fri, 24 Jul 1992 11:28:14 +1000 (from owner-big-internet) Return-Path: Received: from spock.retix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27924; Fri, 24 Jul 1992 10:43:16 +1000 (from des@spock.retix.com) Received: by spock.retix.com id AA15238; Thu, 23 Jul 1992 17:42:34 -0700 Date: Thu, 23 Jul 1992 17:42:34 -0700 From: des@spock.retix.com (Mondo) Message-Id: <199207240042.AA15238@spock.retix.com> To: big-internet@munnari.oz.au Could you please add me to the mailing list. --------------------------------------------------------------------- Desmond Borresen. RETIX : The open newtorking company. email: des@retix.retix.com phone: (310) 828-3400 snail-mail: c/o Retix, 2401 Colorado Ave., Santa Monica, CA 90404. --------------------------------------------------------------------- From owner-Big-Internet@munnari.oz.au Fri Jul 24 15:28:42 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06844; Fri, 24 Jul 1992 15:28:54 +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 AA06839; Fri, 24 Jul 1992 15:28: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 7434; Fri, 24 Jul 92 01:27:04 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 7359; Fri, 24 Jul 92 01:27:04 EDT Date: Fri, 24 Jul 92 01:00:20 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: Another Proposal To: Charles Lynn Cc: big-internet@munnari.oz.au In-Reply-To: <9207232115.21819@munnari.oz.au> Message-Id: <920724.010020.EDT.VALDIS@vtvm1.cc.vt.edu> On Thu, 23 Jul 92 17:11:31 EDT Charles Lynn said: >From what I've read on this list, the "routing table explosion" / >"route aggregation" and the "lack of Class B addresses" problems are >more sever that running out of IP addresses. CIDR should take care of >the Class B problem. Something seems very wrong about the "routing >table explosion" problem. What do we have today 6-7,000 networks? If >it doubles every year for 3 years we get 56,000 nets. A brute force >table of tuples is less than half a MByte. Put a >cache in front of it for speed. This still seems like a drop in the >bucket, especially if one is a major backbone or regional provider. >This leads me to speculate that the real problem is something else. >Is it the way that the tables are maintained? The way updates are >distributed? What is the real problem we are trying to solve? Charles: Currently we have 3 main links from our Class B to the world - one router that has a T-1 to the ENSS at Greensboro and a T1 to the UMD NSS, and another router that connects to Vernet via a 56KB link. It is *already* amazing what happens when the one router blows chow and starts barfing 4,000 routing updates saying "try the 56KB link on the other router". I hate to think what will happen when we have 70,000 networks - everything will come to a screeching halt while the routers recalculate their opinions of reality. Now, it's tough to get a routing table update to be much faster than O(n), and I suspect O(n log n) is more likely - when 'n' is pushing 100K it gets painful. (All you routing experts - does there exist an O(c) algorithm that runs in constant time? Static routes aren't the answer either. The two big reasons for adopting dynamic routing algorithms are that you can't tolerate a wait till Monday for somebody to fix the routing table, and that with 100K nets, you can't trust people to get it right by hand. Look at /etc/hosts versus DNS - that was done because 5,000 hosts was unmanageable. And I'm sure that there's well over 20,000 links to worry about in the net by now, and growing fast. Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Sat Jul 25 01:23:07 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21652; Sat, 25 Jul 1992 01:23:14 +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 AA21649; Sat, 25 Jul 1992 01:23:07 +1000 (from kasten@ftp.com) Received: by ftp.com id AA10605; Fri, 24 Jul 92 11:22:54 -0400 Date: Fri, 24 Jul 92 11:22:54 -0400 Message-Id: <9207241522.AA10605@ftp.com> To: big-internet@munnari.oz.au Subject: some thoughts From: kasten@ftp.com (Frank Kastenholz) hi after contemplating the various activities of last week i think that i can coherently say this..... one of the main points of last week's discussion in the smp bof is that a single big change is infinitely preferred to many many small changes. we discussed the merits of a slow/creeping evolution (add this feature this year, the next feature next year) vs. a single, more revolutionary change. the impression that i got was that the single change is the preferred method by far. i seem to recall some folks expressing the opinion that if the only option was slow evolution then they would prefer not to have any change at all. even worse, of course, would be a series of large changes. i think that this can be directly applied to the ipv7 efforts as follows. we will get one and only one chance to change ip for the next 10-15 years. whatever we change it to now is what we will be stuck with for quite some time. the term "change" covers everything that a host has to deal with -- thus, the elementary change to a host's ip that ipae engenders is just as much of a change as is going to tuba/clnp or pip or... all of the proposals that we are considering for ipv7 are that one change. so, we need to be sure that the proposed ipv7 can address all of the things that we have identified today as critical and that ipv4 lacks, and all of the things that we are pretty sure will happen over the next 5-7 years. we will not be able to have our cake and eat it to by inventing new options to do the things we want. options do not seem to be widely and consistantly implemented. thus, you will have an option, i will not, and as a result, we may not be able to communicate. some of the discussions that i had with the various ipv7 people last week seemed to indicate that their proposal was oriented towards solving the more immediate problems (addressing space and routing) and we could evolve their proposal over time to solve other problems as we see fit. i think that this will not work. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Sat Jul 25 01:29:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21858; Sat, 25 Jul 1992 01:30:02 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21850; Sat, 25 Jul 1992 01:29:49 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA01580; Fri, 24 Jul 92 11:29:23 -0400 Date: Fri, 24 Jul 92 11:29:23 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207241529.AA01580@ginger.lcs.mit.edu> To: VALDIS@vtvm1.cc.vt.edu, clynn@bbn.com Subject: Re: Another Proposal Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu I hate to think what will happen when we have 70,000 networks - everything will come to a screeching halt while the routers recalculate their opinions of reality. This is what you get for having routing tables. In a world where you have topology maps and route caches, things are less drastic. In a routing table world (particularly a DV world), a single link going up/down can cause all the entries in the routing table to need to be updated. In a LS world, you get one minigram saying 'this link went up/down', and then you recalculate routes as needed. does there exist an O(c) algorithm that runs in constant time I don't know of any algorithm which recalculates all routes in anything like this. Use of heirarchy can reduce the number of destinations you have to track, but the cost to calcuate routes to the destinations you do track is still the same. I don't know the math so I forget the exact current minimum cost. Noel From owner-Big-Internet@munnari.oz.au Sat Jul 25 02:14:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22832; Sat, 25 Jul 1992 02:14:48 +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 AB22826; Sat, 25 Jul 1992 02:14:34 +1000 (from craig@aland.bbn.com) Received: from port6.sf.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA04210; Fri, 24 Jul 92 12:14:06 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA15664; Fri, 24 Jul 92 09:11:52 PDT Message-Id: <9207241611.AA15664@aland.bbn.com> To: Frank Kastenholz Cc: big-internet@munnari.oz.au Subject: re: some thoughts Reply-To: Craig Partridge From: Craig Partridge Date: Fri, 24 Jul 92 09:11:52 -0700 Sender: craig@aland.bbn.com Frank: I don't think anyone disagrees that we'd like to make just one change in the next ten years. However, I think we're caught in a nasty fight with the calendar. I can think of at least three technical problems that we need to solve in IP in the next ten years: (1) The routing and addressing explosion we've been debating vigorously over the past week; (2) Ubiquitous computing/mobile systems; (3) Support for multimedia (such as the IETF multicast last week); Of these items (1) clearly requires changes to the IP header; (2) may require changes, though the hope is that we know enough know to know what holes to leave in our addressing plan to to cope with mobility; but for (3) we're still struggling for answers -- the hope was to see tentative architectures by late this year, which probably means we don't seem firm answers for another year or so Now there seems to be a majority of folks who believe we don't have a year to wait to figure out how the IP header gets redone (or we'll be swamped by various routing/addressing calamities...). That implies we'll change IP soon for routing/addressing and then have to change it again for multimedia. My hope is that multimedia support will prove a sufficiently enticing improvement to drive folks to support IPv8 (the successor to IPv7), but that's just a hope. The other option is for the folks doing multimedia work to push very hard and hope that they can make coherent suggestions in November. That's certainly what I'm trying to do myself (I've been working on flow set up issues for gigabit networks and the same ideas ought to work for IP). But that does raise the serious chance that people working on their various proposals and implementations will find themselves suddenly confronted with a bunch of multimedia requirements in, say, late October, just as they're nailing down details for the November IETF. That's not conducive to a well-reasoned consideration of how to fit multimedia into the various proposals. Craig From owner-Big-Internet@munnari.oz.au Sat Jul 25 03:32:38 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27608; Sat, 25 Jul 1992 03:32:49 +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 AA27603; Sat, 25 Jul 1992 03:32:38 +1000 (from kasten@ftp.com) Received: by ftp.com id AA13994; Fri, 24 Jul 92 13:32:09 -0400 Date: Fri, 24 Jul 92 13:32:09 -0400 Message-Id: <9207241732.AA13994@ftp.com> To: Craig Partridge Subject: re: some thoughts From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au craig, > I don't think anyone disagrees that we'd like to make just one change > in the next ten years. However, I think we're caught in a nasty fight > with the calendar. i think that you missed my point. i think that we can make only one change, not that we would like to make only one. > Now there seems to be a majority of folks who believe we don't have > a year to wait to figure out how the IP header gets redone (or we'll be > swamped by various routing/addressing calamities...). That implies > we'll change IP soon for routing/addressing and then have to change it > again for multimedia. My hope is that multimedia support will prove > a sufficiently enticing improvement to drive folks to support IPv8 > (the successor to IPv7), but that's just a hope. i think that this is not going to happen. the vendor community, for one, would be most unhappy. as it stands now, vendors will have to support ipv4 for many many years and they will have to start supporting ipv7. if, in (eg) three or four years, ipv8 for multi-media comes out, vendors will have to support 3 network layer protocols. this is disgusting. remember, one of the more popular taunts that we throw at iso is "you guys need 2 network layers? ha ha ha!" at the smp meeting many people took the position to defer introducing snmp security and wait for smp which addresses more of their problems. the sentiment was "if we have to make a change (for snmp security) let's make it a really worthwhile change and wait for smp which has security and additional function". it is very likely that the same sentiment would be felt towards ipv7/ipv8. ipv7 is for The Internet and only for The Internet. there are a gizilion ip hosts that are not on The Internet and are not likely to be for the forseeable future. they do not need ipv7 if it only addresses addressing and routing. why change to it? now, this posited ipv8 holds the promise of something that is of interest to all hosts, not just those with Internet connectivity. i.e. proper support for multi-media applications. from a commercial point of view it may make a great amount of sense to ignore ipv7 and wait for ipv8. i realize that the multi-media effort is really in its infancy. i do not think that a full solution is required from the multi-media folks. now, i really do not understand what multi-media needs, but perhaps it would be possible to get some rough hints and feed that into the ipv7 effort. we may not be able to have a finely polished solution this november, but perhaps we could get the right hooks in place. even hints like "mm could need a lot of info in the network header" would be useful -- because this could lead the ipv7 people to allocate 2 bytes for a header length field. even things like " is bad in ipv4". while i am on this particular rant, i know that you've been doing work in very high speed networks. do you have any insights to add to the general ipv7 discussions with respect to network layers and giganets? again, it might be broad hints. -- frank kastenholz From owner-Big-Internet@munnari.oz.au Sat Jul 25 04:31:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29005; Sat, 25 Jul 1992 04:31:18 +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 AA28997; Sat, 25 Jul 1992 04:31:02 +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 AA18924; Fri, 24 Jul 92 11:28:53 PDT Received: from b5mail.Eng.Sun.COM (b5mail-ebb) by Eng.Sun.COM (4.1/SMI-4.1) id AA19806; Fri, 24 Jul 92 11:28:29 PDT Received: from bigriver.Eng.Sun.COM by b5mail.Eng.Sun.COM (4.1/SMI-4.1) id AA11276; Fri, 24 Jul 92 11:28:30 PDT Date: Fri, 24 Jul 92 11:28:30 PDT From: Bob.Hinden@Eng.Sun.COM (Bob Hinden) Message-Id: <9207241828.AA11276@b5mail.Eng.Sun.COM> Received: by bigriver.Eng.Sun.COM (4.1/SMI-4.1) id AA22544; Fri, 24 Jul 92 11:28:13 PDT To: kasten@ftp.com (Frank Kastenholz) Cc: Craig Partridge , big-internet@munnari.oz.au In-Reply-To: <9207241732.AA13994@ftp.com> Subject: re: some thoughts Frank, One small point. I think there is a significant difference between the changes to support larger addresses/routing and changes required for new functionality (for multi-media, real-time, etc.). The former changes need to get made everywhere or the internet will break. If we don't do this, we will not have a global internet. The changes to add new functionality to IP can be phased in gradually by users and organizations that want these new features. Not all users may want them for a very long time. It would be nice if we could do both at the same time, but we may not have the time. Bob From owner-Big-Internet@munnari.oz.au Sat Jul 25 04:50:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29530; Sat, 25 Jul 1992 04:51:17 +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 AA29526; Sat, 25 Jul 1992 04:50:56 +1000 (from craig@aland.bbn.com) Received: from port5.la.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA15776; Fri, 24 Jul 92 14:50:39 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA16366; Fri, 24 Jul 92 11:47:46 PDT Message-Id: <9207241847.AA16366@aland.bbn.com> To: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au Subject: re: some thoughts Reply-To: Craig Partridge From: Craig Partridge Date: Fri, 24 Jul 92 11:47:46 -0700 Sender: craig@aland.bbn.com Frank: Yes, I partially missed your point. You were saying "we can only make one change," and I was saying "well, we've been told we must start the change in November, so we're stuck with two." I think your point that November may not prove a deadline is an interesting one. Moving on to the questions of multimedia and gigabits. I still largely hold to the views of the report I gave to the IETF at Stanford saying that there's no big problem to IP forwarding at gigabit speeds -- at the time we need to do it, the appropriate platforms will be available. Multimedia, well, this is a bit of a stretch, but here's a rough sketch. The only way I've seen to do multimedia across internetworks is to implement some sort of multiple queuing scheme (hierarchical queues, fair-queuing, etc.). So there will need to be something in each IP datagram that identifies the flow it is associated with, and allows the gateway to figure out which queue to put the datagram in. If we're lucky, we'll compress that flow id into some sort of simple number that identifies a priority but I doubt we'll succeed. In any case, there will be some value in *every* IP header that you'll have to examine to figure out how to forward the datagram. My guess is that the value will be small (say 16-bits), and will be unique only in the context of the source and destination addresses (just as TCP connections are uniquely identified by tuples). For LANs that provide some sort of reserved bandwidth, one will also use the flow ID to figure out what portion of that reserved bandwidth to stick this IP datagram into. The other bit of fun is once a flow ID has been established along a path (which I assume will *not* be done with IP), we'll need to do something to make sure that the IP datagrams for that flow actually take that path. So there are routing issues here. One suggestion has been to do some form of source routing (either strict or loose could conceivably work). If we go down the source route path a fair hunk of the IP datagrams a router sees will have a source route in them, and the source route may be long (e.g. all 32 hops specified..) Now yes, some of these ideas look ghastly (32 source routes * 96-bit address is 384 bytes added to your IP header). And yes there's hope that we won't have to suffer some of them. I put them up because if you said I had to decide, this instant, what functionality is required, I'd say well I need good source routes and space for a flow ID, even though I'd hope to never use them. I hope that helps! Craig E-mail: craig@aland.bbn.com or craig@bbn.com From owner-Big-Internet@munnari.oz.au Sat Jul 25 05:08:18 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29864; Sat, 25 Jul 1992 05:08:29 +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 AA29861; Sat, 25 Jul 1992 05:08:18 +1000 (from kasten@ftp.com) Received: by ftp.com id AA17261; Fri, 24 Jul 92 15:04:21 -0400 Date: Fri, 24 Jul 92 15:04:21 -0400 Message-Id: <9207241904.AA17261@ftp.com> To: Bob.Hinden@Eng.Sun.COM Subject: re: some thoughts From: kasten@ftp.com (Frank Kastenholz) Cc: craig@aland.bbn.com, big-internet@munnari.oz.au > One small point. I think there is a significant difference between the > changes to support larger addresses/routing and changes required for new > functionality (for multi-media, real-time, etc.). one is strictly for the Internet. the other is of more general interest. remember, we have to be concerned both with the Internet AND with all of those ip hosts that are not on the net. vendors are concerned with money which translates into where the hosts are. > The former changes need to get made everywhere or the internet will > break. If we don't do this, we will not have a global internet. true > The changes to add new functionality to IP can be phased in gradually by > users and organizations that want these new features. Not all users may > want them for a very long time. you can get away with this sort of feeping creaturism if and only if each new creature is a) compatible with all previous creatures and b) none of the creatures are needed for "basic" communiciations -- i.e. on the order of what we have today. if ipv8 and ipv7 are not interoperable then you have problems. suppose sun and ftp. being progressive, bleeding-edge types of companies, upgrade their systems to ipv8 and the trailing-edge technology, inc., does not. then you and i can communicate, but trailing-edge can't. furthermore, you would have to convinve vendors to support a lot more stuff than they do today (q.v. the note i sent today which discusses vendors supporting several network layer protocols). > It would be nice if we could do both at the same time, but we may not > have the time. > > Bob given that the time-pressure is ONLY with respect to the Internet, the better solution might be to do whatever hacks are necessary to the Internet's infrastructure to keep it creaking along with the hosts completely unchanged until we have the "complete solution". -- just a random thought early on a friday afternoon as my brain is really contemplating a restful weekend... -- frank kastenholz From owner-Big-Internet@munnari.oz.au Sat Jul 25 06:33:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02021; Sat, 25 Jul 1992 06:33: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 AA02018; Sat, 25 Jul 1992 06:33:03 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA04829; Fri, 24 Jul 92 16:32:59 -0400 Date: Fri, 24 Jul 92 16:32:59 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207242032.AA04829@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, kasten@ftp.com Subject: Re: some thoughts Cc: jnc@ginger.lcs.mit.edu Hmmm. Not sure I agree with totally with this; I do agree that we should shoot for a single packet format change, but I think it can be delayed quite a bit. This is the stuff I keep going on about Van saying we should keep the existing packet format as long as we can, and I think we can push it a bit yet. Here's my thinking again: 1) We can introduce a new routing and addressing architecture, one suitable for N years to come, *without* *immediately* having *any* change to packet formats. We do this by changing the definition of the 32-bit 'address' fields in the existing packet format to be 'identifier', so we don't have to go around and change all the hosts (and there are a *lot* of them, both implementations and sheer numbers). The new routing and addressing system would primarily be visible only in the routers, although I can think of some (truly) small changes to hosts which would *optimize* the performance of the new system, but even these would not change the basic packet format. 2) At some point in the moderate future, i.e. about 3-5 years before we have 2^32 hosts, which will be a while yet, we design a new packet format which has a bunch of new features, and also 64 bit identifiers. We transition to that as laid out in Nimrod section 7.3. During this time, we keep the existing 'new' routing and addressing architecture, which is the same before and after the change; i.e. addresses would be the same before and after, and so would all the routing protocols, etc. The new R&A architecture provides a 'fixed point' in common between the new and old packet layers. 3) The new packet format would have whatever fields, semantics, etc we need to do resource allocation and congestion avoidance/control, a real thoroughgoing security architecture, autoconfiguration, etc, etc, etc. With more leisure (i.e. not haste, I am not saying we should lie back and listen to tunes :-) to design it, we can complete research in these vital areas before proceeding. I raised this issue on the Big-I list just before the big Brou-ha-ha broke out, and the only counterargument that I got to putting off the adoption of a new packet format came from Bob Smart (sorry I haven't relied yet, Bob, still planning to :-). For more info, look back at the archives. Noel From owner-Big-Internet@munnari.oz.au Sat Jul 25 06:39:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02132; Sat, 25 Jul 1992 06:39:22 +1000 (from owner-Big-Internet) Return-Path: Received: from Mordor.Stanford.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA02129; Sat, 25 Jul 1992 06:39:10 +1000 (from dcrocker@Mordor.Stanford.EDU) Received: from LOCALHOST by Mordor.Stanford.EDU (5.59/inc-1.0) id AA07704; Fri, 24 Jul 92 13:38:51 PDT Message-Id: <9207242038.AA07704@Mordor.Stanford.EDU> To: kasten@ftp.com (Frank Kastenholz) Cc: Craig Partridge , big-internet@munnari.oz.au Subject: Re: some thoughts Org: The Branch Office Phone: +1 408 246 8253; fax: +1 408 249 6205 In-Reply-To: Your message of Fri, 24 Jul 92 13:32:09 -0400. <9207241732.AA13994@ftp.com> Date: Fri, 24 Jul 92 13:38:50 -0700 From: Dave Crocker Frank, The idea of "adding some basic fields for later definition" and equivalent attempts to anticipate future needs and usage is very appealing. It seems to have very limited benefit, however. SNMP put in a security field "for later definition." As nearly as I can tell, it proved useless. IP options certainly get used, but not in the main stream of the service. My guess is that planning for future use only works if you have a very, very good idea of what that use will look like, rather than a "rough guess". And it does not appear that we have that very good idea for policy routing, multimedia, etc. Sigh. Dave From owner-Big-Internet@munnari.oz.au Sat Jul 25 06:43:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02234; Sat, 25 Jul 1992 06:43:25 +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 AA02230; Sat, 25 Jul 1992 06:43:14 +1000 (from kasten@ftp.com) Received: by ftp.com id AA20467; Fri, 24 Jul 92 16:42:59 -0400 Date: Fri, 24 Jul 92 16:42:59 -0400 Message-Id: <9207242042.AA20467@ftp.com> To: jnc@ginger.lcs.mit.edu Subject: Re: some thoughts From: kasten@ftp.com (Frank Kastenholz) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu noel, i think we are pretty much in agreement as to the meta principles, with one exception. to me, anything that changes the code in the hosts is a change. it need not change the packet formats. for example, subnets were a change. i'll re-read nimrod this weekend and see exactly what you are proposing > more leisure (i.e. not haste, I am not saying we should lie back and listen > to tunes :-) to design it, we can complete research in these vital areas can we listen to tunes and do the new ip at the same time? -- frank kastenholz From owner-Big-Internet@munnari.oz.au Sat Jul 25 07:36:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03321; Sat, 25 Jul 1992 07:37:10 +1000 (from owner-Big-Internet) Return-Path: Received: from optics.wc.novell.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03316; Sat, 25 Jul 1992 07:36:53 +1000 (from minshall@wc.novell.com) Received: from localhost.wc.novell.com by wc.novell.com (4.1/smi4.1.1.v91190) id AA03677; Fri, 24 Jul 92 14:36:54 PDT Message-Id: <9207242136.AA03677@wc.novell.com> To: big-internet@munnari.oz.au Subject: The importance of the three-piece suit... Date: Fri, 24 Jul 92 14:36:53 -0700 From: minshall@wc.novell.com As some of you know, i've spent the past 4-1/2 years working in and around AppleTalk. I understand there has been a fair bit of AppleTalk bashing on this list, and i'm a happy basher. However... For a number of years i have felt that what makes AppleTalk easier to configure than IP is the fact the AppleTalk hosts (ES's) dynamically acquired their addresses at startup. The host-part of the address they "bid" for on the local wire, and the network-part of the address they got by "asking" a router on the network (i.e., by looking in a RIP broadcast). Finally (and later than most people, i suspect), after sitting in on some conversations with Noel Chiappa and with Radia Perlman last week, i realized that i was fundamentally mistaken about why AppleTalk is so much easier to configure than IP. **** AppleTalk is easier to configure than IP because in assigning AppleTalk network numbers you pay absolutely no attention to any routing issues. **** I imagined moving our installed (AppleTalk) base over to IP. I imagined that, miracle of miracles, dynamic host configuration converged and allowed for easy assignment of IP addresses to end systems. And, i was happy. For a bit. Then, i thought about AppleTalk customers trying to configure their routers with IP addresses. AppleTalk customers are used to picking an AppleTalk network number using the following scheme: find a number that isn't in use in the network and use that. Trying to teach these people to worry about subnet numbers, possible variable length subnets, etc., is a *hard* problem. I submit: building an AppleTalk network of medium size is, in practice, easier than building an IP network of medium size. There's a gotcha, though: AppleTalk networks don't scale like IP networks do. But, AppleTalk networks of medium size work fine (and, would probably work better if we weren't using RIP as a routing protocol, but that is neither here nor there). But, i think to myself, why not "layer" ("concatenate"?) IP scalability on top of AppleTalk ease-of-configuration? ******** So, here's the point: One wants *3* (THREE) components to an address. 1. Host identifier. 32-bit IP address - fine. 48-bit IEEE address - maybe better. 2. Small to medium scale routing part. Numbers picked out of a barrel. Probably should handle 3k to 10k subnets today. 10 years from now the technology (CPU speeds, etc.) might support an order of magnitude or so more. 3. Large scale routing part. This is the piece that allows for scalability. This is where "network engineers" earn their keep. ******** From a configuration point of view, hosts should learn the routing portions of their address from routers. Item 2 routers should learn their item 3 portions of their address from other routers. Item 3 routers need to have very sophisticated configuration. In some version of the future, item 3 routers might only live inside of service providers. Customers can then just deal with item 2 configuration which is, though much simpler, complex enough. Greg Minshall Novell, Inc. minshall@wc.novell.com 1-510-975-4507 From owner-Big-Internet@munnari.oz.au Sat Jul 25 08:04:20 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03934; Sat, 25 Jul 1992 08:04:43 +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 AA03931; Sat, 25 Jul 1992 08:04:20 +1000 (from kre) To: minshall@wc.novell.com Cc: big-internet@munnari.oz.au Subject: Re: The importance of the three-piece suit... In-Reply-To: Your message of Fri, 24 Jul 92 14:36:53 -0700. <9207242136.AA03677@wc.novell.com> Date: Sat, 25 Jul 92 08:04:00 +1000 Message-Id: <26271.712015440@munnari.oz.au> From: Robert Elz Date: Fri, 24 Jul 92 14:36:53 -0700 From: minshall@wc.novell.com Message-ID: <9207242136.AA03677@wc.novell.com> I submit: building an AppleTalk network of medium size is, in practice, easier than building an IP network of medium size. I disagree with this - it may seem easier, but long term the difference probably goes the other way. We run a "medium scale" Appletalk net here, and if we allowed the local net owners to simply pick an unused net number as you suggest we'd just have chaos. Certainly its fractionally easier for the net manager to simply pick a number that has no semantics attatched, and assign that, but the difference between picking an IP subnet number and an appletalk net number (even with variable length subnet masks, that we do use to some extent) is not really that great. On the other hand, those seduced by the apparent simplicity of appletalk assignments are likely to be in for a rude shock sometime in the future. This is all somewhat analagous to those vendors who ship systems with all security, etc, disabled, on the theory that its easier for the customers that way - things just work the way they "expect" without any hassles. In just the same way the sites that know what they're doing simply turn it all on, or as much as they want, as each system is installed, which is about the same amount of work as turning security off if it was shipped all turned on - but those who don't know what they're doing do nothing, take the easy way out, and again are in for a very rude shock somewhere down the line. The difficulty of patching things up later in either of these situations is much greater than the sum of the incremental small amounts of work needed to get things right in the first place. Vendors who like to be "popular" by making things easy for the incompetant will be found out in the long term, and are likely to suffer because of it. kre ps: which isn't to say that we shouldn't aim for dynamic configuration, just make sure that its done properly, not just the "pick a number and hope" philosophy. And again - please lets not turn this list into a "bash appletalk" list - contrary to what Greg said, there hasn't been much of that, fortunately, and it doesn't belong here. From owner-Big-Internet@munnari.oz.au Sat Jul 25 09:43:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06289; Sat, 25 Jul 1992 09:43:43 +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 AA06271; Sat, 25 Jul 1992 09:43:31 +1000 (from peter@goshawk.lanl.gov) Received: from goshawk.lanl.gov by p.lanl.gov (5.65/1.14) id AA01928; Fri, 24 Jul 92 17:42:08 -0600 Received: by goshawk.lanl.gov (4.1/5.17) id AA06807; Fri, 24 Jul 92 17:42:07 MDT Date: Fri, 24 Jul 92 17:42:07 MDT From: peter@goshawk.LANL.GOV (Peter S. Ford) Message-Id: <9207242342.AA06807@goshawk.lanl.gov> To: big-internet@munnari.oz.au, ietf@nri.reston.va.us, noop@merit.edu Subject: TUBA mailing list announcement. The TUBA/TUCAN mailing list has been established. The purpose of this mailing list is to discuss transitioning the Internet to using addresses longer than 32 bits. The nature of the proposed transition is that hosts will be dual-network stacked. CLNP (ISO-IP) is the candidate network layer protocol at this time. It is envisioned that the "regular" suite of Internet protocols and tools would run on top of TUBA systems including SMTP, Telnet, FTP, various and sundry RPCs, etc. The mailing list is: tuba@lanl.gov and the mailing list maintenance address is: tuba-request@lanl.gov *** PLEASE SEND ALL REQUESTS TO BE ADDED TO THIS LIST *** TO THE tuba-request@lanl.gov address A starting point for discussion is RFC 1347 by Ross Callon titled: ``TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing.'' This can be retrieved from nic.ddn.mil using anonymous ftp. Current Agenda for discussion on mailing list (which is open to agenda bashing): Establish overall vision of what TUBA is. What is an "internet address". id- entity identifier loc-where the entity is in the routing topology What is a Tuba Address, what can be done in the context of CLNP. How to route the Internet. what is the hierarchy what are the protocols: now and in the future ES-IS, IS-IS, IDRP (?RIP,OSPF, IGRP?) Impact on infrastructure: DNS, SNMP/SMP, Routers, Operations, Management Impact on Internet Protocol Suite: IP, UDP, TCP, Telnet, FTP, etc. Impact on Host Software: OS interfaces system libraries (socket, gethostby .., etc.) toolkits (Novell, Apple comm toolkit, etc.) What about OSI stack (TP-4 getting graveful close?) Encapsulation on "everything". Nature of Internet connectivity over time. Prospects for Network address translation (nat). Establish work plan to include: trial implementations on a variety of platforms routing and addressing plan proposal for AFI==ISOC Establish Working Group charter and submit to IESG. I would like to especially encourage people who work on OS systems, libraries, and toolkits to join this list since a major point of the current TUBA RFC is that hosts will need to be dual network layer stacked. If you are interested in developing a trial implementation of TUBA systems on *any* platform, please let me know. Please feel free to add, delete and comment on anything in the agenda listed above. cheers, peter Peter Ford peter@lanl.gov Los Alamos National Laboratory From owner-Big-Internet@munnari.oz.au Sat Jul 25 10:17:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07057; Sat, 25 Jul 1992 10:17: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 AA07054; Sat, 25 Jul 1992 10:17:34 +1000 (from smart@mel.dit.csiro.au) Received: from manta.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA29887 (5.65c/IDA-1.4.4/DIT-1.3 for ); Sat, 25 Jul 1992 10:17:49 +1000 Received: by manta.mel.dit.CSIRO.AU (4.1/SMI-4.0.1) id AA15472; Sat, 25 Jul 92 10:17:31 EST Message-Id: <9207250017.AA15472@manta.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: some thoughts In-Reply-To: Your message of "Fri, 24 Jul 92 16:32:59 -0400." <9207242032.AA04829@ginger.lcs.mit.edu> Date: Sat, 25 Jul 92 10:17:29 +1000 From: Bob Smart > I raised this issue on the Big-I list just before the big Brou-ha-ha >broke out, and the only counterargument that I got to putting off the adoption >of a new packet format came from Bob Smart (sorry I haven't relied yet, Bob, >still planning to :-). For more info, look back at the archives. I basically agree with Noel's prescription for preserving backward compatibility by moving to 32 bit ID and separate address. Reading Ross Callon's recent posting on TUBA I think the CLNP proposal is heading in the same direction [they just need to have one option of their 48bit ID be "the rest is a 32 bit IP4-compatible ID" -- might I suggest the 16 bit value D0D0 to introduce that meaning]. So I think this aspect of "how to keep the old machines running" will end up in various proposals. The area of disagreement is how the packet crosses the network of routers. Noel would like to come up with a scheme where the packet remains in its current format and has no internal addressing information. I believe this is impossible [1. flow recovery very hard ; 2. router memory usage too great]. So I think the IP4 packet has to be converted or encapsulated at the first router. I think that the correct solution is conversion to PIP: 1. Conversion is no harder than encapsulation. We are not talking about adjusting TCP checksums or anything internal to packets: just bung on a different header. 2. If we convert then we can also have PIP hosts and PIP hosts can talk directly to IP4 hosts. The more PIP hosts the less conversion in routers. Really we want to get routers out of the business of finding addresses for IDs as soon as possible. 3. PIP seems to meet some envisaged needs already: can be routed very fast [looks likely]; has a mode for following a flow that has been setup. It would be nice if Craig Partridge would comment on how close PIP is to fulfilling the requirements he sees for multi-media. By the way the IDs will still have to be allocated through some fan-out mechanism and so we won't get to 2^32 hosts -- 2^31 is a chance. Bob Smart From owner-big-internet@munnari.oz.au Sat Jul 25 11:27:49 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08325; Sat, 25 Jul 1992 11:27:58 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07757; Sat, 25 Jul 1992 10:59:19 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA09519; Fri, 24 Jul 92 20:59:09 -0400 Date: Fri, 24 Jul 92 20:59:09 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207250059.AA09519@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: some thoughts Cc: jnc@ginger.lcs.mit.edu The area of disagreement is how the packet crosses the network of routers. Noel would like to come up with a scheme where the packet remains in its current format and has no internal addressing information. I believe this is impossible Actually, I'm going to (perhaps) surprise you slightly, and say you might well be right, particularly for packets which are single-shot. (I think packets which are part of long flows from unmodified hosts would only need at most a flow-number IP option added to the header, not very expensive.) We might want some kind of wrapper, etc, especially if IP headers prove to short to contain, e.g. a complete source route. During the Nimrod engineering phase, when these detailed engineering questions (remember, the Nimrod doc always said it was not an engineering document, just a basic architecture :-), it might turn out that this is the way to go. Even if it does, however, I'd still think we want to discourage a new *host-visible* packet format, for the reasons I mentioned. The efficiency arguments you mention would be less important for packets which are part of flows, since I think we can handle these efficiently without a whole new header. Really we want to get routers out of the business of finding addresses for IDs as soon as possible. As I indicated, a very small change to the hosts (change one module - i.e. get_host_by_name, and relink the applications) will optimize this away. A *lot* less work than a new packet format. By the way the IDs will still have to be allocated through some fan-out mechanism and so we won't get to 2^32 hosts -- 2^31 is a chance. Yah, you're right, we don't get all 2^32. However, a well designed fan-out should get us to about 75% or more. It's the same analysis as disk wastage; the bigger the blocks, the higher the % of waste as a total of the whole. Noel From owner-Big-Internet@munnari.oz.au Sat Jul 25 21:52:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18480; Sat, 25 Jul 1992 21:52:32 +1000 (from owner-Big-Internet) Return-Path: Received: from ds1.scri.fsu.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18475; Sat, 25 Jul 1992 21:52:23 +1000 (from westmark@ds1.scri.fsu.edu) Received: by ds1.scri.fsu.edu (5.61/Ultrix2.4-C) id AA15682; Sat, 25 Jul 92 06:51:40 -0500 Date: Sat, 25 Jul 92 06:51:40 -0500 From: westmark@ds1.scri.fsu.edu (Jay Westmark) Message-Id: <9207251151.AA15682@ds1.scri.fsu.edu> To: kre@munnari.oz.au, minshall@wc.novell.com Subject: Re: The importance of the three-piece suit... Cc: big-internet@munnari.oz.au I submit: building an AppleTalk network of medium size is, in practice, easier than building an IP network of medium size. I disagree with this - it may seem easier, but long term the difference probably goes the other way. We run a "medium scale" Appletalk net here, and if we allowed the local net owners to simply pick an unused net number as you suggest we'd just have chaos. You are over exaggerating the example. I believe that greg was using the allocation of host and network numbers as an example of how the LAN network operating system venders manage addressing (apple, Banyan, Novel, Microsoft, etc). In most LAN NOSs the end node addresses are dynamically allocated thereby relieving the administrator of the responsibility of keeping up with who's on first. I don't think that greg was implying that end-users should just grab a net number and assign it to their system. Certainly its fractionally easier for the net manager to simply pick a number that has no semantics attatched, and assign that, but the difference between picking an IP subnet number and an appletalk net number (even with variable length subnet masks, that we do use to some extent) is not really that great. On the other hand, those seduced by the apparent simplicity of appletalk assignments are likely to be in for a rude shock sometime in the future. I'm not very familiar with appletalk, would explain what you mean? This is all somewhat analagous to those vendors who ship systems with all security, etc, disabled, on the theory that its easier for the customers that way - things just work the way they "expect" without any hassles. In just the same way the sites that know what they're doing simply turn it all on, or as much as they want, as each system is installed, which is about the same amount of work as turning security off if it was shipped all turned on - but those who don't know what they're doing do nothing, take the easy way out, and again are in for a very rude shock somewhere down the line. two points, 1) most LAN NOS vendors do ship with all security options off, but who cares? You have to configure the things anyway... this give the end-users the flexibility of turning on just what is required for their purposes. 2) what type of rude shock? The difficulty of patching things up later in either of these situations is much greater than the sum of the incremental small amounts of work needed to get things right in the first place. It sounds like you are arguing for eliminating any solution that does not require a technical genius to understand or administer. Vendors who like to be "popular" by making things easy for the incompetant will be found out in the long term, and are likely to suffer because of it. yea, microsoft, novel, apple, and banyan are really suffering!! -jay Jehu F. Westmark Centel Corporation (904) 599-1843 From owner-Big-Internet@munnari.oz.au Sat Jul 25 23:14:05 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19658; Sat, 25 Jul 1992 23:14:11 +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 AA19653; Sat, 25 Jul 1992 23:14:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11838; Sat, 25 Jul 92 09:13:57 -0400 Date: Sat, 25 Jul 92 09:13:57 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207251313.AA11838@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au, craig@aland.bbn.com Subject: re: some thoughts Cc: jnc@ginger.lcs.mit.edu I don't think anyone disagrees that we'd like to make just one change in the next ten years. Absolutely, if you will insert the phrase "to the hosts", after "one change". I really do think it is reasonable engineering to make more changes to the routers; there are fewer of them, there are fewer vendors, more of them tend to be maintained by real support organizations (as opposed to being on some professor's desk with new software release tapes in a drawer, unopened), etc. However, I think we're caught in a nasty fight with the calendar. Not necessarily. I really think we can put off changing the packet format as seen by the hosts for a while yet, as I have previously explained. (1) The routing and addressing explosion we've been debating vigorously over the past week; (2) Ubiquitous computing/mobile systems; We can kill both these birds with a new routing and addressing system which is deployed as an adjunct to the current packet layer, primarily/principally in the routers; this system would be the first "part" of the new packet layer. (1) clearly requires changes to the IP header Everyone keeps repeating this mantra. I don't believe it (and thus, in the usual JNC manner, it is starting to make steam come out my ears :-)! Sure, in the long run (5-8 years), but not right away. Maybe the routers need something special too. However, I think you can deploy a new R&A architecture with the existing headers as far as the hosts are concerned. What am I missing? (3) we're still struggling for answers Exactly. Which is why I want to put off designing a new packet format as long as possible. ("Early binding is the root of all evil" - CS dictum.) There's also security, auto-configuration, etc, etc. That implies we'll change IP soon for routing/addressing and then have to change it again for multimedia. Nope. One of your premises I don't agree with. Yes, we need a routing fix; no, it doesn't mandate a new packet format visible to the hosts. The other option is for the folks doing multimedia work to push very hard and hope that they can make coherent suggestions in November. Take your time, do it right. Also, when you say "multimedia", I assume you're really just using this as a shorthand for "resource allocation and other low level mechanisms which multimedia among other applications might need"? We need to think more broadly that just some applications in designing a new packet layer. Noel From owner-Big-Internet@munnari.oz.au Sat Jul 25 23:45:22 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20173; Sat, 25 Jul 1992 23: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 AA20170; Sat, 25 Jul 1992 23:45:22 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11960; Sat, 25 Jul 92 09:45:18 -0400 Date: Sat, 25 Jul 92 09:45:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207251345.AA11960@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au, craig@aland.bbn.com Subject: re: some thoughts Cc: jnc@ginger.lcs.mit.edu there's no big problem to IP forwarding at gigabit speeds -- at the time we need to do it, the appropriate platforms will be available. I concur. I know of at least one way to do it, but the lawyers say it's best if I don't tell anyone how just yet (i.e. patents, etc....). Sorreee... So there will need to be something in each IP datagram that identifies the flow it is associated with, and allows the gateway to figure out which queue to put the datagram in. Gee, sounds a lot like some of the ideas some people are proposing on how to handle routing and addressing; gee, wonder if they were thinking of this sort of thing when they went down that path? :-) Yes, ever since Dave Clark came up with the idea of flows in the early 80's (Dave: is there a reference to this that we can include in papers, etc?) it has been clear that this was the way to go. If you sit down and analyze the pros and cons of 'traditional' datagram and virtual circuit networks, it's clear they each have some advantages. It seemed clear then (and does so still) that a hybrid approach which kept a little more state in the network, but not *critical* state (i.e. nothing you can't afford to blow away and have the endpoints fairly easily recover from) could have the advantages of both, and the disadvantages of neither. Hence, flows. My guess is that the value will be small (say 16-bits), and will be unique only in the context of the source and destination addresses Yes, but why in the context of the *pair*? If the source identifier ('address' is a bad word to me! :-) is unique throughout the network, and the value (yes, 16 bits is probably enough, but...) is unique within that source, these two together provide a network wide unique flow identifier. The other bit of fun is once a flow ID has been established along a path (which I assume will *not* be done with IP), we'll need to do something to make sure that the IP datagrams for that flow actually take that path. Again, this sounds very familiar. Wonder why! :-) If we go down the source route path a fair hunk of the IP datagrams a router sees will have a source route in them, and the source route may be long... Now yes, some of these ideas look ghastly (32 source routes * 96-bit address is 384 bytes added to your IP header) Right, flow setup for routing (as opposed to source routing) is purely an engineering efficiency move. In the early days of thinking about the ideas that became IDPR and Nimrod, it was clear that source selected routing was the way to go. Source routes in packets, and flow setup, are just two different mechanisms to do this. Flow setup was picked since it was felt it was more efficient for longer trains of packets (you just use the id/flow pair as a tag to a cache entry, rather than parsing the source route and looking up the next hop), and the headers are shorted (i.e. less overhead), and it tied in well with likely future resource alllocation directions. None of this means that we won't need mechanisms to optimize handling of one-shot traffic, as Deborah pointed out. I promptly 'stole' this good idea (as I like to with all good ideas :-), and as a result I have suggested a number of these optimizations in Nimrod (section 6.1). Noel From owner-Big-Internet@munnari.oz.au Sat Jul 25 23:50:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20205; Sat, 25 Jul 1992 23:50: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 AA20202; Sat, 25 Jul 1992 23:50:23 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA12024; Sat, 25 Jul 92 09:50:18 -0400 Date: Sat, 25 Jul 92 09:50:18 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207251350.AA12024@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au Subject: Re: some thoughts anything that changes the code in the hosts is a change True, but Nimrod does not, as far as I know, *require* *any* changes to the host. For optimizations, it does seem to me to make some difference as to whether they are small or far-reaching; the easier ones will propogate faster. i'll re-read nimrod this weekend and see exactly what you are proposing I apologise in advance for the density and poor organization of the document. Sections 2* can be skipped to minimize the stuff you have to wade through. There's a lot of stuff there, and it's all abstract, sorry! Should have had some pictures... can we listen to tunes and do the new ip at the same time? Hey, that's not optional, that's mandatory! Without listening to The Master (aka JSB, DBQ, etc :-), how can we see Perfection? Noel From owner-Big-Internet@munnari.oz.au Mon Jul 27 09:59:34 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01957; Mon, 27 Jul 1992 13:41:36 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207270341.1957@munnari.oz.au> Received: from syacus.acus.oz (via metro) by munnari.oz.au with SunIII (5.83--+1.3.1+0.50) id AA01954; Mon, 27 Jul 1992 13:41:34 +1000 (from andrewf@syacus.acus.oz.au) From: andrewf@syacus.acus.oz.au Subject: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) To: dkatz@cisco.com@munnari.OZ.AU Date: Mon, 27 Jul 92 9:59:34 EST Cc: big-internet@munnari.OZ.AU In-Reply-To: <9207230611.AA17284@cider.cisco.com>; from "Dave Katz" at Jul 22, 92 11:11 pm Dave, Thank you for your description of the OSI "right way". My argument was that except for this there was no real problem, routers and hosts are largely unaware of the address registration hierarchy. There might be the odd system out there that verifies that the NSAP has been formed according to the rules of ISO8348/Ad.2, but I assume not enough to bother about. I suppose it's wishful thinking on my part to think ISO would change one of their standards just for the Internet community. Anyway, I didn't want to bore the rest of the list just to say that, I'd like to query you about something you said, which I think is of more general interest. > > BTW, I hope that any allocations of a future IP NSAP, would require that > the NSAP actually be reachable from the Internet if it is reachable at > all, unlike the existing NSAP types which encapsulate sub-network > addresses. > > If the IP-within-IDI scheme had gone forward, the addressing standard > would, as you point out, say that there is no implication that the NSAP be > reachable at that IP address; however, this does not constrain service > providers from making this assumption and, for instance, using IP routing > tables. I would be free to assign an NSAP to my CLNS toaster based on the > address of my IP workstation; however, my CLNS network provider might not > care to route to my toaster (or charge me up the wazoo for carrying around > the exception information to the general routing rules). Explicitly tying > the two addresses together does not belong in the ISO addressing document; > it can be enforced by other means. > If allowing the network provider the right to prefer some forms of network addressing over others represents ISO thinking, are there are any mechanisms planned to allow network subscribers to easily change their addresses, when they change network providers? (or, is it a conspiracy with the CCITT to maximise use of PTTs :-), through use of non-optimal routing.) I disagree that tying sub-network addresses together with NSAPs does not belong in the ISO addressing document. You suggest that a network provider may charge customers to advertise exceptional routes, there may also be a charge to customers to obtain routes, either directly or indirectly (perhaps due to the bandwidth consumed). If you know a-priori that a certain class of NSAPs encapsulates a usable sub-network address than you would be spared from any cost of obtaining routing info for those NSAPs. I consider that highly desirable, especially while we have waited and are waiting for a CONS routing solution to become widely deployed. BTW, even if those NSAPs were guaranteed to contain routable SNPAs, there would still be a problem: with the X.121 AFI, for example, one cannot determine where the IDI finishes and the DSP starts, without knowledge of how the nominated PDN assigns X.121 addresses (X.121 addresses are not fixed length.) Cheers, Andrew -- | Tel: +61 2 390 1338 | Internet: andrewf@syacus.acus.oz.au Andrew Friedman | Fax: +61 2 390 1391 | ACSnet: andrewf@syacus.acus.oz From owner-Big-Internet@munnari.oz.au Mon Jul 27 17:14:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07448; Mon, 27 Jul 1992 17:14:54 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07445; Mon, 27 Jul 1992 17:14:48 +1000 (from dkatz@cisco.com) Received: by cider.cisco.com; Mon, 27 Jul 92 00:14:26 -0700 Date: Mon, 27 Jul 92 00:14:26 -0700 From: Dave Katz Message-Id: <9207270714.AA26935@cider.cisco.com> To: andrewf@syacus.acus.oz.au Cc: big-internet@munnari.OZ.AU In-Reply-To: andrewf@syacus.acus.oz.au's message of Mon, 27 Jul 92 9:59:34 EST <9207270341.1950@munnari.oz.au> Subject: NSAP AFI for IP (was: ISO SC6 meeting tidbits) From: andrewf@syacus.acus.oz.au Date: Mon, 27 Jul 92 9:59:34 EST Dave, Thank you for your description of the OSI "right way". My argument was that except for this there was no real problem, routers and hosts are largely unaware of the address registration hierarchy. There might be the odd system out there that verifies that the NSAP has been formed according to the rules of ISO8348/Ad.2, but I assume not enough to bother about. I suppose it's wishful thinking on my part to think ISO would change one of their standards just for the Internet community. My point was that the whole issue of changing standards could be completely sidestepped using existing procedures at a negligible cost. The issue of "the CCITT gets AFIs so why can't we" is silly. My suspicion is that, indeed, the internet could probably get an AFI, but why go through the trouble (and the wait)? If allowing the network provider the right to prefer some forms of network addressing over others represents ISO thinking, are there are any mechanisms planned to allow network subscribers to easily change their addresses, when they change network providers? (or, is it a conspiracy with the CCITT to maximise use of PTTs :-), through use of non-optimal routing.) This doesn't represent ISO thinking, just mine. FYI, IDRP, IS-IS, and the ES-IS address assignment addendum provide mechanisms that make the changing of addresses possible. I disagree that tying sub-network addresses together with NSAPs does not belong in the ISO addressing document. You suggest that a network provider may charge customers to advertise exceptional routes, there may also be a charge to customers to obtain routes, either directly or indirectly (perhaps due to the bandwidth consumed). If you know a-priori that a certain class of NSAPs encapsulates a usable sub-network address than you would be spared from any cost of obtaining routing info for those NSAPs. I consider that highly desirable, especially while we have waited and are waiting for a CONS routing solution to become widely deployed. I don't disagree with the technical point of embedding subnetwork addresses, just the formalism in which it is defined. 8348 is too high-level a document in which to do this. If it is desired to make an embedded SNPA mandatory, it should be done by the addressing authority owning the space (who would most likely want to put at least one octet before the SNPA so as to not lock the entire address space into this approach). The primary intent of the X.121, etc., addressing formats, from what I've been able to tell (it's before my time), was to bootstrap the NSAP allocation process by providing a mechanism with which people could assign themselves NSAP addresses that would be guaranteed to be globally unambiguous. The length of time it took to establish the national addressing authorities bore out the wisdom of the intent, if not necessarily the approach. Of course, if you really wanted to embed an X.121 address and mandate its validity as a subnetwork address, an address authority could define a DSP format as such. BTW, even if those NSAPs were guaranteed to contain routable SNPAs, there would still be a problem: with the X.121 AFI, for example, one cannot determine where the IDI finishes and the DSP starts, without knowledge of how the nominated PDN assigns X.121 addresses (X.121 addresses are not fixed length.) Not true, 8348 mandates padding IDIs with variable-length abstract syntax to their full length when encoding. Cheers, Andrew -- | Tel: +61 2 390 1338 | Internet: andrewf@syacus.acus.oz.au Andrew Friedman | Fax: +61 2 390 1391 | ACSnet: andrewf@syacus.acus.oz From owner-Big-Internet@munnari.oz.au Mon Jul 27 22:40:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14732; Mon, 27 Jul 1992 22:40:20 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207271240.14732@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA14716; Mon, 27 Jul 1992 22:40:09 +1000 (from jcurran@nic.near.net) To: big-internet@munnari.oz.au Subject: Separation of routing and system identification in TUBA - thoughts Date: Mon, 27 Jul 92 08:40:03 -0400 From: John Curran I posted this to the TUBA specific mailing list, but alas, it did not appear out the other side. Hence, this copy to big-internet. Here's a skeleton outline for how the Internet network layer could look over the long-term, and a some brief of notes describing how TUBA can get us there. Enjoy, /John --- Alternate Internet Network Services Architecture using TUBA - Hosts are identified via globally unique identifiers, which may or may not have been allocated via an administrative hierarchy, but in any case do not encode topological or routing information within. Multiple allocation schemes may be in use as long as uniqueness is assured. - Applications running on systems perform communications with other systems using only the system identifier information. Library interfaces are not required to provide the ability to specify routing information during typical application communications. - Network layer datagrams have headers which include fully-qualified addresses including both routing and system identification fields. Additional fields are present to provide handling information (TTL, etc.) and transport protocol selection. - Datagram forwarding occurs on a hop-by-hop basis based on longest-match routing in each router. Routing protocols are utilized to acquire and propagate this information between routers. - Support in the network layer for multicasting, security, and system mobility be incorporated where possible and considered mandatory in the long term. That's it. The major change from our current architecture is the acceptance that system identification does not contain routing information (assisting host mobility and dynamic reconfiguration) and establishing the acquisition of such routing information as a function of the network layer (as opposed to the application layer). Several of the big-internet proposals advocate a directory-based approach for obtaining routing information, wherein an application would receive such information during their normal resolution process, and would provide it to the network layer for generation of outgoing datagrams. Such approaches demonstrate architectural simplicity, but may not be viable given our current situation. There are thousands of applications which use a current well-defined set of library interfaces to communicate via TCP/UDP/IP, and any change to these library interfaces will place in a major hurdle in path of migration. Not only will every application be changed, but organizations will have to insure that they have the "updated" versions of every application before converting a given system. It is reasonable to expect these library interfaces to change as the network evolves, but such changes should be performed with backward compatibility if they are to succeed. Given that we treat the existing 4-octet IP addresses as system identifiers, it must be possible for the network layer to obtain the associated routing information for inclusion in an outgoing datagram. This lookup is non-trivial, since our assumptions allow for non-hierarchical assignment of system id's; additionally, it has significant implications for security and host mobility. At this point, it is necessary to leave the clean model behind, and weigh priorities to achieve a working result (i.e. "engineering). Here is one possibility using TUBA and the current IP address allocation schemes: 1) Profile an CLNP address format for IPv7. Recognize the value of the existing GOSIPv2 infrastructure (both operational and for allocation purposes) and use that. 2) Determine a default mapping of an IP address into the system-id field. Interact with IEEE as necessary. Document it clearly. 3) Since hosts map to IP address, and IP addresses are valid identifiers under this scheme, no new DNS records are needed for long addresses. Likewise for inverse-lookup (IN-ADDR). 4) [TANSTAAFL] However, the network layer needs to get the remainder of the CLNP address from somewhere, and DNS is all we have that works in a distributed manner, so... Attack DNS and insert a new record type which is unorganized just as the current PTR IN-ADDR records are only these new records (RTR?) return the remainder of the routing info: Ex.: 4.71.52.192 IN RTR 47.0005.80.FFEE00.0000.0000.1100 Also return the record as a hint along with any "A" record lookup. 5) Write the IPV7 compatibility routines which look like normal socket interfaces but performs the above gyrations as necessary. Include wonderful switches for: act-as-ipv4, dual-stack-prefer-ipv4, dual-stack-prefer-ipv7, ipv7. Allow for autoconfiguration of current routing domain and area. 6) Forget about address depletion problems, since "ip addresses" are now just unique identifiers. If you run out of space in your class C, just ask your neighbor for a free address, and use it on your network. It'll work, as long as he remembers to put the RTR record in for you. We gain maximum address utilization with 2**32 possible systems. 7) Think about mobility; adopt a route-redirect which updates the necessary cache so that outgoing datagrams go straight to the current location. Either provide for dynamic update of the DNS info, or accept the existence of a "mobility server" and a fixed starting point for all communications. 7) Prepare for the CIDR/DNS crisis, in which it is possible to allocate an organization the "piece" of the IP address space needed for short term Internet usage, but not possible to allocate the matching IN-ADDR slice so that IPv7 records can be maintained. This means that those folks chopping up their previously-large address classes had best be prepared to provide DNS support for some time to come. 9) Plan for the coming of X.500 and consider permanently delegating DNS to the role of providing routing information. Squeeze it into layer 3 as the network level "ARP" function, and eliminate any initial condition dependencies (RTR records for root servers, etc..). 10) Consider redefining the system-id in the interfaces to allow 6 octet identifiers which will be needed someday. Make sure that existing calling sequence still works for 4-octet folks. Ponder who runs the IN-ADDR zones for all those IEEE identifiers, and how they get their initial information (email routing registration? security? yurg...) From owner-Big-Internet@munnari.oz.au Mon Jul 27 23:23:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA15676; Mon, 27 Jul 1992 23:23:22 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15671; Mon, 27 Jul 1992 23:23:09 +1000 (from dave@japan.bellcore.com) Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA15957; Mon, 27 Jul 92 09:26:08 EDT Return-Path: Received: by japan (4.1/4.7) id AA00528; Mon, 27 Jul 92 09:08:37 EDT Date: Mon, 27 Jul 92 09:08:37 EDT From: dave@sabre.bellcore.com (Dave Piscitello) X-Station-Sent-From: japan.bellcore.com Message-Id: <9207271308.AA00528@japan> To: andrewf@syacus.acus.oz.au, dkatz@cisco.com@munnari.oz.au Subject: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) Cc: big-internet@munnari.oz.au Hmm. I would say a minor blemish. There's nothing to stop you having a single decimal fixed IDI (Initial Domain Identifier) and representing nothing to stop you but "hesitation" ISO standards do change... I seem to remember that an IDI is not required, AFI=49 consists of only IDI is whatever "AFI" sez it is... Sure, AFI=47 is the "right" way to do it, but if the CCITT can have AFIs for their networking technologies, why can't we? why is AFI=47 more right than any other way to do it? and yes, ISOC/IETF can and should have an AFI; I'm not sure ISO would have a credible argument against providing one to us. (How does the size of the Internet and other private and semi-private networks, compare with the size of say the CCITT X.25 network?) wild speculation on my part, but I don't know of any X.25 net in the U.S. that comes close to the subscriber base of some of the mid-levels, much less the Internet as a whole (hey, if I'm wrong, at least I'll goad one of the X.25 folks into setting the record straight:-) From owner-Big-Internet@munnari.oz.au Tue Jul 28 01:53:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20130; Tue, 28 Jul 1992 01:54:00 +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 AA20127; Tue, 28 Jul 1992 01:53:48 +1000 (from craig@aland.bbn.com) Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA04800; Mon, 27 Jul 92 11:52:45 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA04022; Mon, 27 Jul 92 08:51:06 PDT Message-Id: <9207271551.AA04022@aland.bbn.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Big-Internet@munnari.oz.au, craig@aland.bbn.com Subject: how much time do we have? Reply-To: Craig Partridge From: Craig Partridge Date: Mon, 27 Jul 92 08:51:06 -0700 Sender: craig@aland.bbn.com > (1) clearly requires changes to the IP header > > Everyone keeps repeating this mantra. I don't believe it (and thus, in the > usual JNC manner, it is starting to make steam come out my ears :-)! Hi Noel: I had no intention of making your ears warm... Later in your note you agree that changes to the IP header are needed -- the question is how soon? I'd love to hear that we've got a couple of years. Most folks seem to have decided that we're ostriches if we don't tackle the header problem ASAP. So, have we reached a rough consensus (perhaps minus JNC) that we bite off the header problem *now*, or is this still open for debate? If it is open for debate we need to decide briskly so we can decide if the IESG program for a decision in November is premature. Someone got the current project curves and a statement of how much CIDR will buy (with some error bars, so we have a sense of how close catastrophy could be in the worst case)? Craig From owner-Big-Internet@munnari.oz.au Tue Jul 28 01:58:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA20283; Tue, 28 Jul 1992 01:58:41 +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 AA20280; Tue, 28 Jul 1992 01:58:30 +1000 (from craig@aland.bbn.com) Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA05206; Mon, 27 Jul 92 11:57:59 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA04040; Mon, 27 Jul 92 08:56:05 PDT Message-Id: <9207271556.AA04040@aland.bbn.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: Big-Internet@munnari.oz.au Subject: re: some thoughts Reply-To: Craig Partridge From: Craig Partridge Date: Mon, 27 Jul 92 08:56:05 -0700 Sender: craig@aland.bbn.com Noel: Not surprised this sounds familiar to you. As you say, some ideas come from conversations with Dave Clark. > My guess is that the value will be small (say 16-bits), and will be > unique only in the context of the source and destination addresses > > Yes, but why in the context of the *pair*? If the source identifier ('address' > is a bad word to me! :-) is unique throughout the network, and the value (yes, > 16 bits is probably enough, but...) is unique within that source, these two > together provide a network wide unique flow identifier. Tired thinking on my part. It should be unique when combined with src identifier. There's some funniness about how we tag multicast flows (which may have multiple senders and receivers) but I assume we'll puzzle this out. Craig From owner-Big-Internet@munnari.oz.au Tue Jul 28 04:19:21 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA23201; Tue, 28 Jul 1992 04:19:31 +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 AA23197; Tue, 28 Jul 1992 04:19:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA22966; Mon, 27 Jul 92 14:19:11 -0400 Date: Mon, 27 Jul 92 14:19:11 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207271819.AA22966@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au, craig@aland.bbn.com Subject: Re: how much time do we have? Cc: jnc@ginger.lcs.mit.edu Craig: I had no intention of making your ears warm... It's not so much my ears, which are the conduit, but the rapdily-dessicating brain matter.. :-) Later in your note you agree that changes to the IP header are needed -- the question is how soon? I'd love to hear that we've got a couple of years. First, recall that in that statement I was referring to changes in the *host-visible* header format. As I indicated in my message to Bob Smart, Nimrod (or any solution) might well decide that we change the *router-visible* header format, but not the one the host sees. Second,, I admit I don't have every last bit in Nimrod nailed down, so I don't have a 100% certain answer. However, if you accept that: i) we need to add endpoints to the architecture ii) the existing source and destination 'address' fields in the IP packet can be 're-semanticed' to do this iii) a new routing and addressing architecture can be deployed (primarily or entirely in the routers) as an adjunct to the existing packet layer if we do i) and ii) then we only need a new packet format for one of two reasons: i) other fields that we need in packets to make a new R&A architecture work won't fit in the existing host-visible header, and we want to put them in that header, or ii) we run out of 32 bit identifiers Clearly, the second is going to happen, but not in a year or two. We need a new host-visible header before that happens. However, I'm not at all sure about i). A number of people (including yourself, as I recall :-) have expressed nervousness about a change to the header now being premature. We might end up having to make a similar change *again* at a later date. My thinking is, if this has a chance of being true, and there is *not* a *large* benefit that we *cannot* get without a change to the header now, why take a chance? If we can deploy something in the scaling problem in R&A which in fact does not require a new host-visible packet format, why risk such a cost? What are we gaining? Most folks seem to have decided that we're ostriches if we don't tackle the header problem ASAP. It's true that as time goes on there are more and more hosts to change. This worries me greatly! The sooner we make the change, the argument goes, the better, and it's a good point. On the other hand, if we *do* make a change, and it's *still* not right, then the energies expended in that change are not maximally well spent. What I am hearing from lots of people is that we just don't know enough yet in lots of important areas (resource allocation, congestion avoidance, security architecture, auto-configuration) to do it right. If this is so, waiting may not be bad. Yes, I know about 'the best being the enemy of the good'. I don't see that here. The question is "Can we get the existing format to do 98% of what a new format would do, albeit at some cost (e.g. using options)?" If so, you have to balance two costs; one is the cost of making a change to a new format, the other is what it will cost to kludge keeping going with the existing one. If it is open for debate we need to decide briskly so we can decide if the IESG program for a decision in November is premature. Again, I'm not sure I see that this follows. I still think you can make a decision on a new R&A architecture without necessaily chosing a new packet format. (Also, November might be a little aggressive, but better to post and aggressive target and slip it a bit; this at least encourages maximum effort, with no dawdling! :-) Someone got the current project curves and a statement of how much CIDR will buy (with some error bars The range is pretty wide, depending on whether people ever want to renumber, and things like that. If people want to be able to change where they are in the topology, but keep their existing 'IP address', it is going to cost to allow that. One or two doing it you can manage trivially; if everyone does it, the system will simply be unable to handle it. Think of the US Mail analogy; it's as if you wanted to keep the first US Postal address you ever had, no matter where you move. If everyone tried to do this the system would croak. Noel From owner-Big-Internet@munnari.oz.au Tue Jul 28 06:34:25 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26415; Tue, 28 Jul 1992 06:34:40 +1000 (from owner-Big-Internet) Return-Path: Received: from harvard.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA26408; Tue, 28 Jul 1992 06:34:25 +1000 (from gmalkin@Xylogics.COM) Received: by harvard.harvard.edu (5.54/a0.25) (for big-internet@munnari.oz.au) id AA24891; Mon, 27 Jul 92 16:34:20 EDT Received: by Xylogics.COM (4.12/4.7_jlv1/7/90) id AA09049; Mon, 27 Jul 92 16:36:03 edt Date: Mon, 27 Jul 92 16:36:03 edt From: Gary Scott Malkin Message-Id: <9207272036.AA09049@Xylogics.COM> To: big-internet@munnari.oz.au Subject: iv7 congestion control Allow me to start a new thread. I was just discussing, with a co-worker, how best to handle congestion caused by link-speed mismatch. It occurred to me that a lot of congestion is caused by TCP retransmissions of packets which are added to the end of a queue which still contains the original packet. It further occurred to me that if one were to save the TCP checksum of a packet in the buffer descriptor (whatever that may be for a given implementation), then, when a link's output queue starts to grow beyond some high water mark, new packets could be checked to see if they were retransmissions (since their checksums would be identical). Now I know that there a 1 in 64K chance that this will result in an incorrect drop, but if the link is becomming congested, you'd be doing a random drop anyway. I also realize that this is a layering violation, but it's in a good cause :-} Now, the reason I bring this up here, is that we might want to think about incorporating some form of congestion control into ip7. Remember, TCP windows provide end-to-end flow control which does not guarantee that an intermediate system won't die under the weight of dozens of flow controlled connections. And there is no flow control for UDP. My thinking is that transport protocols might provide some form of ID which the network layer could carry, then use for congestion control. This would eliminate the chance of an improper discard and remove the layering violation. Comments? ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Tue Jul 28 07:05:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26950; Tue, 28 Jul 1992 07:05:28 +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 AB26928; Tue, 28 Jul 1992 07:05:03 +1000 (from craig@aland.bbn.com) Received: from port10.mv.pub-ip.psi.net by uu2.psi.com (5.65b/4.0.071791-PSI/PSINet) id AA28564; Mon, 27 Jul 92 17:04:37 -0400 Received: by aland.bbn.com (4.1/3.1.090690-BBN) id AA06765; Mon, 27 Jul 92 14:03:10 PDT Message-Id: <9207272103.AA06765@aland.bbn.com> To: Gary Scott Malkin Cc: big-internet@munnari.oz.au Subject: re: iv7 congestion control From: Craig Partridge Date: Mon, 27 Jul 92 14:03:10 -0700 Sender: craig@aland.bbn.com > It further occurred to me that if one were to save the TCP > checksum of a packet in the buffer descriptor (whatever that may be for > a given implementation), then, when a link's output queue starts to grow > beyond some high water mark, new packets could be checked to see if they > were retransmissions (since their checksums would be identical). Gary: This assumes that the retransmitted TCP packet is identical to the original. That's only true for transfers using MTU-sized segments. Telnet retransmission, for example, tend to include all the chars previously transmitted. You can avoid the layering violation by reusing the IP ID for MTU-sized segments which are being retransmitted, which has the added with of perhaps helping to complete a fragmented IP datagram at the receiver which is missing one fragment. As for the ID idea -- that's precisely the idea of a flow id -- something that maps to a set of rules about how your datagrams are to be handled (including congestion issues). Now there's a question of whether to distinguish datagrams within a flow (i.e. some are more readily loosable than others). There are so-called coloring schemes for this purpose. Craig From owner-Big-Internet@munnari.oz.au Tue Jul 28 07:08:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA26987; Tue, 28 Jul 1992 07:08:59 +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 AA26984; Tue, 28 Jul 1992 07:08:35 +1000 (from kre) To: Gary Scott Malkin Cc: big-internet@munnari.oz.au Subject: Re: iv7 congestion control In-Reply-To: Your message of Mon, 27 Jul 92 16:36:03 -0400. <9207272036.AA09049@Xylogics.COM> Date: Tue, 28 Jul 92 07:08:19 +1000 Message-Id: <27085.712271299@munnari.oz.au> From: Robert Elz But aren't TCP implementations these days supposed to measure the RTT, and not re-transmit within the measured RTT. Given that the chances of a re-transmitted packet arriving at the same gateway as its predecessor seems pretty slim, and should diminish over time, so designing in something to cope with this particular problem doesn't really seem worth the effort. Also given that a retransmitted TCP segment doesn't need to be identical to the original (may have updated ACK number, and window, and may even have additional data) attempting to implement the short term checksum test doesn't look particularly useful either. kre From owner-Big-Internet@munnari.oz.au Tue Jul 28 07:51:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27983; Tue, 28 Jul 1992 07:52: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 AA27980; Tue, 28 Jul 1992 07:51:53 +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 1790; Mon, 27 Jul 92 17:51:24 EDT Received: from vtvm1.cc.vt.edu (VALDIS) by vtvm1.cc.vt.edu (Mailer R2.08 R208002) with BSMTP id 9829; Mon, 27 Jul 92 17:51:23 EDT Date: Mon, 27 Jul 92 17:43:42 EDT From: Valdis Kletnieks Organization: Virginia Polytechnic Institute Subject: Re: iv7 congestion control To: Gary Scott Malkin , big-internet@munnari.oz.au In-Reply-To: <9207272036.AA09049@Xylogics.COM> Message-Id: <920727.174342.EDT.VALDIS@vtvm1.cc.vt.edu> On Mon, 27 Jul 92 16:36:03 edt you said: >Allow me to start a new thread. I was just discussing, with a co-worker, >how best to handle congestion caused by link-speed mismatch. It occurred >to me that a lot of congestion is caused by TCP retransmissions of packets >which are added to the end of a queue which still contains the original >packet. It further occurred to me that if one were to save the TCP A few questions: A) Does Jacobsen's "Slow Start" stuff address this problem already? I could have *sworn* that the whole key to that stuff was Van's observation that 98% (do I mis-remember?) of all lost packets in the Internet core were dropped on the floor when routers were overloaded and queues filled, so the case of a lost ACK was treated as an implicit ICMP source quench. B) Do there really exist routers that fall so far behind that they are *still* sitting on packets that have had the retransmit timer pop on them? C) Does anybody have any hard numbers on how acute a problem this *really* is? Valdis Kletnieks Computer Systems Engineer Virginia Polytechnic Institute From owner-Big-Internet@munnari.oz.au Tue Jul 28 09:38:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00826; Tue, 28 Jul 1992 09:39:01 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207272339.826@munnari.oz.au> Received: from rschp1.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA00820; Tue, 28 Jul 1992 09:38:56 +1000 (from hugh@rschp1.anu.edu.au) Received: by rschp1.anu.edu.au (16.8/16.2) id AA25947; Tue, 28 Jul 92 09:37:35 +1000 From: Hugh Fisher Subject: Whose GOSIP? (Was separation in TUBA) To: big-internet@munnari.oz.au Date: Tue, 28 Jul 92 9:37:34 EST Mailer: Elm [revision: 70.30] This was triggered by John Currans posting "Separation of routing and system identification in TUBA - thoughts" in which he wrote: ... > 1) Profile an CLNP address format for IPv7. Recognize the value of > the existing GOSIPv2 infrastructure (both operational and for > allocation purposes) and use that. ... Now, my knowledge of CLNP/OSI is pretty minimal but I do know that the Australian and UK governments, at least, have their own GOSIPs, and somehow I doubt that these are what the CLNP advocates (not just John Curran) plan to be compatible with. Can you say "Cultural Imperialism"? :-) From owner-Big-Internet@munnari.oz.au Tue Jul 28 11:22:56 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03962; Tue, 28 Jul 1992 11:23:00 +1000 (from owner-Big-Internet) Received: from mundamutti.cs.mu.OZ.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA03959; Tue, 28 Jul 1992 11:22:56 +1000 (from kre) Received: from spock.retix.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29879; Tue, 28 Jul 1992 09:04:37 +1000 (from des@spock.retix.com) Return-Path: Received: by spock.retix.com id AA25558; Mon, 27 Jul 1992 16:03:53 -0700 Date: Mon, 27 Jul 1992 16:03:53 -0700 From: des@spock.retix.com (Mondo) Message-Id: <199207272303.AA25558@spock.retix.com> To: kre@munnari.oz.au Subject: Re: iv7 congestion control Resent-To: Big-Internet@munnari.OZ.AU Resent-Date: Tue, 28 Jul 92 11:22:46 +1000 Resent-Message-Id: <27245.712286566@munnari.oz.au> Resent-From: Robert Elz The prospect of IP dropping TCP retransmissions is certainly unpleasant from the layering point of view. A better approach would be to allow TCP to take advantage of the improved congestion avoidance provided within CLNP, this way TCP can do its own congestion avoidance. Any thoughts on other existing aplications making use of this aspect of CLNP. The congestion avoidance information should be available to higher level protocols running over CLNP in the big internet. dpb From owner-Big-Internet@munnari.oz.au Tue Jul 28 12:03:15 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05447; Tue, 28 Jul 1992 12:03:23 +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 AA05436; Tue, 28 Jul 1992 12:03:15 +1000 (from dennis@MrBill.CAnet.CA) Received: from MrBill.CAnet.CA by shark.mel.dit.csiro.au with SMTP id AA29890 (5.65c/IDA-1.4.4/DIT-1.3 for ); Tue, 28 Jul 1992 11:33:06 +1000 Received: by MrBill.CAnet.CA id <105517>; Mon, 27 Jul 1992 21:29:58 +0100 From: Dennis Ferguson To: jcurran@nic.near.net Subject: Re: Separation of routing and system identification in TUBA - thoughts Cc: big-internet@munnari.oz.au Message-Id: <92Jul27.212958bst.105517@MrBill.CAnet.CA> Date: Mon, 27 Jul 1992 21:29:44 +0100 > That's it. The major change from our current architecture is the acceptance >that system identification does not contain routing information (assisting >host mobility and dynamic reconfiguration) and establishing the acquisition >of such routing information as a function of the network layer (as opposed >to the application layer). Note that we have no less than three (count 'em) network layer proposals on the table which advocate the use of a globally unique host ID which carries no routing information, but which can be used as a key for a database lookup to find out information about the host it identifies. This is a sure sign that this is an idea whose time has come, independent of which network layer we all end up using. Given this, I think it is probably worth while to see if there is consensus as to what this host ID should be, what properties it should have and how it gets assigned, so that we end up with host ID's which are useful for any and all of these network layer proposals. This maximizes the probability that we'll end up with a one-host-ID-works-for-everything scheme for host ID assignment that makes everyone happy, and will provide people who are thinking of proposing Yet Another New Network Layer with information about what they should be trying to work with as well. Also, given that modifications to TCP to use any of these network layers are going to be mostly dependent on properties of the host ID, in particular its length and how it gets included in the checksum, nailing down what the host ID looks like early on may help get TCPs which are less attached to the IPv4 header and addresses implemented sooner. This would be universally useful. Dennis Ferguson From owner-Big-Internet@munnari.oz.au Tue Jul 28 14:06:30 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09138; Tue, 28 Jul 1992 14:07:51 +1000 (from owner-Big-Internet) Return-Path: Received: from SPECTRUM.CMC.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09105; Tue, 28 Jul 1992 14:06:30 +1000 (from lars@CMC.COM) Received: by Spectrum.CMC.COM (4.1/SMI-4.1(Spectrum)) id AA02196; Mon, 27 Jul 92 21:05:27 PDT Newsgroups: ietf.big-internet Path: lars From: lars@spectrum.CMC.COM (Lars Poulsen) Subject: Re: iv7 congestion control Message-Id: <1992Jul28.040517.2156@spectrum.CMC.COM> Organization: CMC Network Systems (Rockwell DCD), Santa Barbara, CA, USA References: <920727.174342.EDT.VALDIS@vtvm1.cc.vt.edu> Date: Tue, 28 Jul 92 04:05:17 GMT Apparently-To: Big-Internet@munnari.OZ.AU In article <920727.174342.EDT.VALDIS@vtvm1.cc.vt.edu> VALDIS@VTVM1.CC.VT.EDU (Valdis Kletnieks) writes: >B) Do there really exist routers that fall so far behind that they are >*still* sitting on packets that have had the retransmit timer pop on >them? Wherever you transition from a (fast) LAN to a (slow) wide-area link, there will be occasional deep pileups. In the past, we saw this at the campus-to-ARPA border routers. In the next two years we will see it at dialup-links in the same speed class (9600 to 64,000 bps). If you don't suffer from this problem, then your network is not serving a large class of users yet. :-) :-) -- / Lars Poulsen, SMTS Software Engineer Internet E-mail: lars@CMC.COM CMC (Rockwell Digital Systems) Telephone: +1-805-968-4262 Santa Barbara, CA 93117-5503 TeleFAX: +1-805-968-8256 From owner-big-internet@munnari.oz.au Tue Jul 28 21:19:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19833; Tue, 28 Jul 1992 21:22:09 +1000 (from owner-big-internet) Return-Path: Message-Id: <9207281122.19833@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA15578; Tue, 28 Jul 1992 18:00:16 +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, 28 Jul 1992 08:47:37 +0100 To: des@spock.retix.com (Mondo) Cc: kre@munnari.oz.au, Big-Internet@munnari.OZ.AU Subject: Re: iv7 congestion control In-Reply-To: Your message of "Mon, 27 Jul 92 16:03:53 PDT." <199207272303.AA25558@spock.retix.com> Date: Tue, 28 Jul 92 08:47:34 +0100 From: Jon Crowcroft >The prospect of IP dropping TCP retransmissions is >certainly unpleasant from the layering point of view. pretty horrible since it is completelt disfunctional! how does a gateway figure out which retransmission is guilty rather than real beacuase _other_ flows may be congesting the net...? >A better approach would be to allow TCP to take advantage of >the improved congestion avoidance provided within CLNP, this >way TCP can do its own congestion avoidance. Any thoughts on >other existing aplications making use of this aspect of CLNP. not really - all you get is a DEC bit which means that the receiver of a packet may get an early warning that the sender is using a path that is overused - you then need to either not ack (same as lost packet anyhow) or set the bit in the CLNP packet returning down the path carrying the ack... howerver, you could just run X.25:-) >The congestion avoidance information should be available to higher >level protocols running over CLNP in the big internet. sure....there is a very large literature on congestion avoidance and control - a few intro docs attached... however, a lot of thje work has been done based on either dec bit or lost ack - what you do when the net level does flow specs as well as a TCP doing stuff maybe does need a bit of thought...it can only get better though jon %A Z Wang %A J Crowcroft %T "A New Approach to Congestion Control in Datagram Networks" %D Jan 91 %J Computer Communications Review %P ACM %X 3 %A Z Wang %A J Crowcroft %T "A New Approach to Congestion Control in Datagram Networks" %D June 1991 %J ACM Performance Evaluation Revue/ACM SIGMETRICS. %P ACM %X 3 %A DW Davies %T The Control of Congestion in Packet Switched Computer Networks %J IEEE Trans on Comms, pp. 546-550 %D June 1972 %A IEEE %T Special Issue on Congestion Control in Computer Networks %J IEEE Trans on Comms, Vol. COM-29, No. 4 %D April 1981 %A RK Jain %T CUTE: A Timeout Based Congestion Control Scheme for Digital Network Architecture %J Digital Equipment Corporation, DEC-TR-353 %D March 1985 %A R Magoon %A D Twyver %T Flow and Congestion Control in SL-10 Networks %J Proc. Int. Symp. on Flow Control in Computer Networks, North-Holland, pp. 45-61, Versailles %D February 1979 %A J Nagle %T Congestion Control in IP/TCP Internetworks %J Computer Communication Review, Vol. 14, No. 4, pp. 11-17 %D October 1984 %A KK Ramakrishnan %T Analysis of the Dynamic Window Congestion Control Protocol in Heterogeneous Environments Including Satellite Links %J Digital Equipment Corporation, DEC-TR-284 %D August 1984 %A H Amano %T RSM (Receiver Selectable Multicast): a communication mechanism for multiprocessors %J INSPEC Conference Paper %P 149-56 %I IEEE Comput. Soc. Press %C Washington %D 23-27 June 1987 %X RSM is a special multiport memory that allows multiple processors to read data simultaneously. Providing only copies of necessary data. RSM maintains a high performance with relatively small memory requirements. Using a CMOS gate array and RAM, RSM is economically implemented in a parallel machine named (SM)/sup 2/-11 (Sparse Matrix Solving Machine version II). Applications programs on the mchine using RSM are introduced, andthe congestion on RSM is analyzed both empirally and theoretically. The analysis indicated that RSM provides maximum performanace in the noninterleaved shared memory system. Effective methods for using RSM are also indicated. %A Van Jacobson %T TCP Timers and Congestion Control %J Proceedings ACM SIGCOMM Symposium %D August 1988 %A RK Jain %T CUTE: A Timeout Based Congestion Control Scheme for Digital Network Architecture %J Digital Equipment Corporation, DEC-TR-353 %D March 1985 %A Jain, R %T Myths about Congestion Management in High Speed Networks %J DEC TR %V 726 %D Oct 1990 %A David Clark %A Lixia Zhang %A Scott Schenker %T Observations on the Dynamics of a Congestion Control Algorithm: The Effects of Two Way Traffic %J ACM Computer Communications Review %V ??? %P ??? %I ACM %D ??? 1991 %K Congestion Control, Two Way Traffic, Slow Start %X Examines the dynamics of congestion control, with two way traffic, exhibiting ack compression, and out of phase window synchronisation. %A Wilder %A Ramakrishan %A Mankin %T Dynamics of Congestion Control and Avoidance of Two-Way Traffic in an OSI Tes tbed %J DRAFT %I MITRE %D March 1991 %K Congestion Control, Dynamics, %X Experiments on two way dynamics of TP4 with Cute in the gateways on a real testbed. %A Wang %A Crowcroft %T A New Congestion Control Scheme: Slow Start and Search (Tri-S) %J Computer Communications Review %V 21 %P 32-43 %I ACM %D January 1991 %K Congestion Control TCP Transport Protocol %X Enhancement to Slow Start to remember where the point of optimality is and togo and search for it %A Amarnath Mukherjee %A John C. Strikwerda %T Analysis of Dynamic Congestion Control Protocols - A Fokker Planck Approximat ion %J ACM Computer Communications Review %P 159-169 %I ACM %C Zurich %D September 1991 %K Queuing analysis diffusion %A Raj Jain %T A Delay-Based Approach for Congestion Avoidance in Interconnected Heterogenous Computer Networks %J ACM Computer Communications Review %V 19-5 %P 56-71 %I ACM %D October 1989 %K delay control From owner-Big-Internet@munnari.oz.au Tue Jul 28 23:16:28 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22169; Tue, 28 Jul 1992 23:17:40 +1000 (from owner-Big-Internet) Received: from sabre.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA22150; Tue, 28 Jul 1992 23:16:28 +1000 (from dave@japan.bellcore.com) Received: by sabre.bellcore.com (5.57/Ultrix2.4-C) id AA23811; Tue, 28 Jul 92 09:19:01 EDT Return-Path: Received: by japan (4.1/4.7) id AA06661; Tue, 28 Jul 92 09:01:22 EDT Date: Tue, 28 Jul 92 09:01:22 EDT From: dave@sabre.bellcore.com (Dave Piscitello) X-Station-Sent-From: japan.bellcore.com Message-Id: <9207281301.AA06661@japan> To: dcrocker@mordor.stanford.edu, kasten@ftp.com Subject: Re: some thoughts Cc: big-internet@munnari.oz.au, craig@aland.bbn.com The idea of "adding some basic fields for later definition" (Groan...)--CLNP really got stuffed on this one, too. There are security options--3 of them--well, actually, there are place-holders for (of course) variable length security options, but no one has ever bothered to think about what they should be. (For TUBA, I suppose we could associate the existing IP option with one of the variants of the CLNP security option, not sure this is best way to do this, but doable nonethelesss) My guess is that planning for future use only works if you have Dave, you have the right words in the sentence, but mis-ordered; "planning for future use is my guess" From owner-Big-Internet@munnari.oz.au Tue Jul 28 23:08:26 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21975; Tue, 28 Jul 1992 23:09:32 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207281309.21975@munnari.oz.au> Received: from Relay.Prime.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21950; Tue, 28 Jul 1992 23:08:26 +1000 (from @Relay.Prime.COM:AL@TURBO.Kean.EDU) Received: from TURBO.Kean.EDU by Relay.Prime.COM; 28 Jul 92 09:12:27 EST Received: (from user AL) by TURBO.Kean.EDU; 28 Jul 92 09:08:32 EDT To: big-internet@munnari.oz.au From: Al Costanzo Organization: Kean College of New Jersey Security: -- none -- Comment: Sender Phone# (908) 527-2061 Comment: Sender Fax# (908) 527-2243 Subject: complexity of changes Date: 28 Jul 92 09:08:32 EDT What every proposal is moved forward, it should have enough complex changes and be mind boggling enough to keep all of us network people with jobs till at least the end of the recession [sic] I vote for a 64 bit van. IP with no toppings. Regards, !AKC5 From owner-Big-Internet@munnari.oz.au Wed Jul 29 01:04:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25829; Wed, 29 Jul 1992 01:06:01 +1000 (from owner-Big-Internet) Return-Path: Received: from hobbit.gandalf.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA25805; Wed, 29 Jul 1992 01:04:40 +1000 (from chris@cannibal.gandalf.ca) Received: from cannibal.gandalf.ca by hobbit.gandalf.ca (4.1/SMI-4.1) id AA01065; Tue, 28 Jul 92 11:04:11 EDT Received: by cannibal.gandalf.ca (4.1/SMI-4.1) id AA06985; Tue, 28 Jul 92 11:04:08 EDT Date: Tue, 28 Jul 92 11:04:08 EDT From: chris@gandalf.ca (Chris Sullivan) Message-Id: <9207281504.AA06985@cannibal.gandalf.ca> To: jcurran@nic.near.net, dennis@MrBill.CAnet.CA Subject: Re: Separation of routing and system identification in TUBA - thoughts Cc: big-internet@munnari.oz.au > Given this, I think it is probably worth while to see if there is > consensus as to what this host ID should be, what properties it > should have and how it gets assigned, so that we end up with host ID's > which are useful for any and all of these network layer proposals. This > maximizes the probability that we'll end up with a > one-host-ID-works-for-everything scheme for host ID assignment that makes > everyone happy, and will provide people who are thinking of proposing Yet > Another New Network Layer with information about what they should be trying > to work with as well. I agree, however I think as Noel pointed out it is extremely important not to overload this ID with addressing semantics. The address IS where something is in the topology, and is inextricable from the kind of topology used (i.e., if 3d geoposition is used, the address is a triple, dynamically allocated or learned, universally unique). "You can't take it with you". On the other hand an ID is permanently associated with the that-which-is- identified, and its uses are more likely to have to do with accounting, resource management, security, etc. "Don't leave home without it". -Chris Sullivan From owner-big-internet@munnari.oz.au Wed Jul 29 02:56:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA28473; Wed, 29 Jul 1992 02:59:03 +1000 (from owner-big-internet) Return-Path: Message-Id: <9207281659.28473@munnari.oz.au> Received: from nic.near.net by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA24421; Wed, 29 Jul 1992 00:06:46 +1000 (from jcurran@nic.near.net) To: Hugh Fisher Cc: big-internet@munnari.oz.au Subject: Re: Whose GOSIP? (Was separation in TUBA) In-Reply-To: Your message of Tue, 28 Jul 92 09:37:34 -0500. <9207272339.826@munnari.oz.au> Date: Tue, 28 Jul 92 10:06:08 -0400 From: John Curran -------- From: Hugh Fisher Subject: Whose GOSIP? (Was separation in TUBA) Date: Tue, 28 Jul 92 9:37:34 EST This was triggered by John Currans posting "Separation of routing and system identification in TUBA - thoughts" in which he wrote: ... > 1) Profile an CLNP address format for IPv7. Recognize the value of > the existing GOSIPv2 infrastructure (both operational and for > allocation purposes) and use that. ... Now, my knowledge of CLNP/OSI is pretty minimal but I do know that the Australian and UK governments, at least, have their own GOSIPs, and somehow I doubt that these are what the CLNP advocates (not just John Curran) plan to be compatible with. Can you say "Cultural Imperialism"? :-) In a message to this same list on June 12, Jon Crowcroft reposted a message from Pault Bryant which listed over a dozen different NSAP formats. I'm quite aware of the diversity out there... My suggestion for GOSIPv7 was just that: a suggestion. Is there a format from amongst the others that you prefer? /John From owner-Big-Internet@munnari.oz.au Wed Jul 29 03:23:48 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29030; Wed, 29 Jul 1992 03:24:52 +1000 (from owner-Big-Internet) Return-Path: Received: from harvard.harvard.edu by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29016; Wed, 29 Jul 1992 03:23:48 +1000 (from gmalkin@Xylogics.COM) Received: by harvard.harvard.edu (5.54/a0.25) (for big-internet@munnari.oz.au) id AA13371; Tue, 28 Jul 92 13:23:19 EDT Received: by Xylogics.COM (4.12/4.7_jlv1/7/90) id AA28541; Tue, 28 Jul 92 13:25:07 edt Date: Tue, 28 Jul 92 13:25:07 edt From: Gary Scott Malkin Message-Id: <9207281725.AA28541@Xylogics.COM> To: craig@aland.bbn.com Cc: big-internet@munnari.oz.au In-Reply-To: Craig Partridge's message of Mon, 27 Jul 92 14:03:10 -0700 <9207272103.AA06765@aland.bbn.com> Subject: iv7 congestion control > This assumes that the retransmitted TCP packet is identical to the > original. That's only true for transfers using MTU-sized segments. > Telnet retransmission, for example, tend to include all the chars > previously transmitted. If the retransmitted packet isn't truely identical, then you probably don't want to chuck it anyway. Besides, I wasn't suggesting that this would be a great way to do congestion control (because it ain't :-) I just wanted to be sure that the issue was considered when creating ip7. ---------------------------------------------------------------------- Gary Malkin Humankind asks: "Why are we here?" (617) 272-8140 Earth responds: "PLASTIC, morons." From owner-Big-Internet@munnari.oz.au Wed Jul 29 04:18:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA29957; Wed, 29 Jul 1992 04:19:55 +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 AA29936; Wed, 29 Jul 1992 04:18:47 +1000 (from hitchcoc@oerv01.er.doe.gov) Received: by er.doe.gov (5.57/OER-V1.0) id AA00415; Tue, 28 Jul 92 14:15:49 -0400 Date: Tue, 28 Jul 92 14:15:49 -0400 From: hitchcoc@oerv01.er.doe.gov (Dan Hitchcock) Message-Id: <9207281815.AA00415@er.doe.gov> To: big-internet@munnari.oz.au Subject: transitions and uncertainty To summarize thestate of the current discussions: the consensus is that separating ID from routing seems to be a good idea. Also, more than one change is likely in next 5 years... isochronous services, accounting, resource reservation,... Do not have time to wait and "settle" all of these and still manage joint routing/addressing problems of current net. Also multiple changes, especially to host software, is a bad or at least unpopular thing. We have learned, with 20-20 hindsight the features in our implementations which prevent graceful introduction of new features, addressing schemes,.... Some other random observations: Users hate to see the things that are visible to them about their environment (which in IP includes their address) change. Some route aggregation will be needed whether it is hierarchical or some complex other topology. Backward compatbility is very important. Need to convince host manufacturers at least to invest in installing upgrade in their boxes. Any scheme for global coordination of ID's and routing info will have significant bureaucratic hassles (On hopes the current ISO structure is maximal in this but that is not proven). Conclusions: 1) As part of this grps discussion we need to understand what changes will be needed in host software so that future changes can be implemented incrementally and in cases where we cannot do this we need to try to ensure that the choices we make will last 5-10 years. 2) We need to explore transition strategies especially things which impact users. Hiding addresses/ID's and routing specifics would improve things here. Impact on DNS/X.500 services needs to be evaluated. 3) It is very important to involve end system vendors so that the one majo r change in host software buys us flexibility in the future so that at least new services incoming are ignored and outgoing are set to reasonable standard defaults. 4) New routing architectures must interoperate with one another at borders and must be able to support accounting, policy,... extensions. Dan Hitchcock From owner-Big-Internet@munnari.oz.au Wed Jul 29 05:12:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01059; Wed, 29 Jul 1992 05:14:00 +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 AA01034; Wed, 29 Jul 1992 05:12:53 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA17411; Tue, 28 Jul 92 12:12:10 -0700 Received: by sneezy (5.57/ULTRIX-4.2-3)id AA09915; Tue, 28 Jul 92 15:12:04 -0400 To: VALDIS@vtvm1.cc.vt.edu, clynn@bbn.com Subject: Re: Another Proposal In-Reply-To: <9207241529.AA01580@ginger.lcs.mit.edu> References: <9207241529.AA01580@ginger.lcs.mit.edu> Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu X-Mailer: Poste 2.0B3 From: Dave Oran Date: Tue, 28 Jul 92 15:11:43 -0400 Message-Id: <920728151143.2364@sneezy.lkg.dec.com> Encoding: 31 TEXT, 6 TEXT SIGNATURE > > does there exist an O(c) algorithm that runs in constant time > If there is you should steal it and make $$$$$. If there isn't and you invent one you can make $$$$$$$$$. "Standard" SPF executes in O(ElogN) time, where E is the number of links and N is the number of nodes. OSPF works like this. ISO ISIS reduces this to O(E) by restricting the dynamic range of the link metric thus permitting the paths to be binned by distance and avoiding the sort operation which accounts for the logN in the total complexity. Most distance vector algorithms are worse - RIP-like protocols are O(N^3) and I've heard arguments that under certain topology and worst-case timing assumptions they behave exponentially. In the example you give of 70K networks, if 90% of these are stubs, this is still not a big problem, since "smart" SPF implementers keep track of leaves of the SPF tree separately and do graft operations rather than complete recalculation when their shortest path changes. All of the above notwithstanding, you want hierarchy and summarizations anyway, for a number of important reasons: 1. To control the amount of memory needed in routers so that the world doesn't blow up if all of a sudden a new region hooks up 2. To control the amount of bandwidth eaten up sending around updates 3. To control the information overload on network managers (now where was that misbehaving net...let me just scroll through these 70,000 entries on my screen) etc., etc. -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@sneezy.lkg.dec.com 550 King Street Littleton, MA 01460 From owner-big-internet@munnari.oz.au Wed Jul 29 06:07:19 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02150; Wed, 29 Jul 1992 06:09: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 AA24989; Wed, 29 Jul 1992 00:30:05 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA28669; Tue, 28 Jul 92 10:29:51 -0400 Date: Tue, 28 Jul 92 10:29:51 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207281429.AA28669@ginger.lcs.mit.edu> To: dennis@mrbill.canet.ca, jcurran@nic.near.net Subject: Re: Separation of routing and system identification in TUBA - thoughts Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Given this, I think it is probably worth while to see if there is consensus as to what this host ID should be, what properties it should have and how it gets assigned, so that we end up with host ID's which are useful for any and all of these network layer proposals. Hmm, could be true. I've always imagined these ID's as relatively short (i.e. 64 to 96 bits), fixed length, effectively random (as far as the network is concerned, but like 48 bit IEEE numbers, they would have an *allocation* hierarchy) binary strings. I know not everyone agress with all parts of this; Bob Smart has had ideas on variable length identifiers, for instance. Maybe we should tackle this first; fixed or variable length? Also, given that modifications to TCP to use any of these network layers are going to be mostly dependent on properties of the host ID, in particular its length and how it gets included in the checksum Listen, everyone, deploying an entire new routing and addressing architecture is going to be a big enough pain in our lives. I am utterly dumbfounded that people are seriously talking about doing a new host-visible packet format at the same time. Just the first is going to be a big enough thing to chew off; are we all mad, to consider the second as well? I have yet to hear what I consider a solid argument that this is *necessary*, let alone a *good idea*. (I except one message from Bob S I haven't had time to parse yet. :-) a globally unique host ID which carries no routing information, but which can be used as a key for a database lookup to find out information about the host it identifies. Two minor but important nits: First, I claim that the ID (in whichever scheme we use) should name not a host, but what I call an 'endpoint', which is more or less one end of a TCP connection. See the Big-I archive for more details; an endpoint is actually an end-end or fate-sharing region. I was convinced at the San Diego meeting by some people - Tony Li? - outside the meeting hall that this was the right thing, and not a host. Second, the database lookup thing is only a temporary hack to allow existing, unmodified hosts to work. I imagine that in the future, a DNS lookup will return both a new style address *and* the identifier; you normally wouldn't try and do anything with the identifier except use it as a unique name. This is a sure sign that this is an idea whose time has come, independent of which network layer we all end up using. Yes, I'm pleased to see more and more schemes are using this. I'm convinced we need an extra layer of naming, but won't rehash all that! I've been pushing this for 10 years, and have to pinch myself! Also, a plug for Jerry Saltzer, who figured this out in 1982 and has been waiting 10 years for the rest of us to catch on! Noel From owner-Big-Internet@munnari.oz.au Wed Jul 29 06:17:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02373; Wed, 29 Jul 1992 06:18: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 AA02357; Wed, 29 Jul 1992 06:17:09 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA03930; Tue, 28 Jul 92 16:16:53 -0400 Date: Tue, 28 Jul 92 16:16:53 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207282016.AA03930@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, des@spock.retix.com Subject: Re: iv7 congestion control Cc: Big-Internet@munnari.oz.au, jnc@ginger.lcs.mit.edu pretty horrible since it is completelt disfunctional! how does a gateway figure out which retransmission is guilty rather than real beacuase _other_ flows may be congesting the net...? Jon, I don't think people are trying to discard packets (duplicate or not) from flows which are causing congestion as a means of 'punishing' congesters. I think what people are saying is simply that if a router has two duplicate packets in its queues, it can safely discard one, with consequently less wastage of resources, without making the situation any worse. Presumably you would discard the newer of the two, i.e. the one furthest away from being sent back out. Noel From owner-big-internet@munnari.oz.au Wed Jul 29 06:37:23 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02728; Wed, 29 Jul 1992 06:40:02 +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 AA26195; Wed, 29 Jul 1992 01:18:41 +1000 (from kasten@ftp.com) Received: by ftp.com id AA09890; Tue, 28 Jul 92 11:16:01 -0400 Date: Tue, 28 Jul 92 11:16:01 -0400 Message-Id: <9207281516.AA09890@ftp.com> To: Craig Partridge Subject: Re: how much time do we have? From: kasten@ftp.com (Frank Kastenholz) Cc: jnc@ginger.lcs.mit.edu, Big-Internet@munnari.oz.au > So, have we reached a rough consensus (perhaps minus JNC) that we > bite off the header problem *now*, or is this still open for debate? If > it is open for debate we need to decide briskly so we can decide if the > IESG program for a decision in November is premature. no we have not (at least i have not :-). there seems to be some adequate proposals for solving the more immediate problems without having to change the end hosts. since there are a couple of things coming up that probably would require header changes, i propose that we put off making header changes until we absolutely have to. remember, like i said a few days ago, we get one header change every ten years or so. we can make such a change now, but do we want to live with it until 2002? if we can hold off changing the header until, say, 12 or 18 months from now, we may have a better handle on what things like multi-media, resource allocation, security, etc, want in the ip header. if so, we can roll this stuff into the ipv7 header then and do it "properly". otherwise, we run the risk of doing ipv8 in 1994/5 or hacking the additional functions into the header or just plain not doing the new things because the header changes are too expensive. what is really needed is not ipv7 research. we pretty much understand how to build a network layer protocol. what is needed is concentrated research, engineering, and prototyping on the "new" stuff so that we can design a full function header in the summer of 1993. -- frank kastenholz d configuration. The piece that's missing from the existing protocols is a way that the "item 2" routers can learn their global address. Paul Tsuchiya proposed a way to do this using ISIS but so far there has been insufficient interest to resurrect this. If TUBA becomes a real possibility for widespread deployment, I suggest we resurrect this and get it added to ISIS. It isn't hard, and would be even easier with IDRP in place to anchor the whole addressing hierarchy with RDIs. > In some version of the future, item 3 routers might only live inside of > service providers. Customers can then just deal with item 2 > configuration which is, though much simpler, complex enough. > For most organizations, this may be viable. For many large organizations, they will have multiple routing domains inside themselves and need control over the deployment of level 3 routers. Cheers, -+-+-+-+-+-+-+ David R. Oran Phone: + 1 508 486-7377 Digital Equipment Corporation Fax: + 1 508 486-5279 LKG 1-2/A19 Email: oran@sneezy.lkg.dec.com 550 King Street Littleton, MA 01460 From owner-Big-Internet@munnari.oz.au Wed Jul 29 09:42:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07631; Wed, 29 Jul 1992 09:43:03 +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 AA07624; Wed, 29 Jul 1992 09:42:52 +1000 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.57/Ultrix3.0-C) id AA02190; Tue, 28 Jul 92 19:42:32 -0400 Message-Id: <9207282342.AA02190@boa.gsfc.nasa.gov> Subject: Host Identifier and Location To: big-internet@munnari.oz.au Date: Tue, 28 Jul 92 19:42:31 EDT From: Dick desJardins Cc: dkatz@cisco.com, colella@osi.ncsl.nist.gov, medin@nsipo.nasa.gov, desjardi@boa.gsfc.nasa.gov (Dick desJardins) X-Mailer: ELM [version 2.3 PL11] I like the idea of a single worldwide hierarchical internet routing and addressing scheme based on ease of administration and efficient routing, plus a globally unique host identifier. This should be designed so as to support all (or nearly all) the big internet proposals. Here are some thoughts in a little paper, with rough edges and all still intact. (I see a shape there; maybe somebody can express it better or point out the flaws.) Dick dJ -------- HOST IDENTIFIER and LOCATION, with POLITICS by Dick desJardins There does seem to be a growing opinion that Host Identifier should be globally unique and separate from Host Location which should be used for routing. Can the Internet community come up with a scheme for both of these in the near term that would be compatible with any medium or long term solution to the Big Internet problem? That would benefit everybody. Here are my (not necessarily naive) ideas in three areas: Host Identifier, Host Location, and Politics. HOST IDENTIFIER: Two, four, six or eight bytes? Support them all! Here's how: o Two bytes (or better: variable within some range, as in CIDR) for local IDs assigned by an administrator within an area or autonomous system. o Four bytes for existing Internet addresses used as globally unique host identifiers. o Six bytes for the existing IEEE Ethernet address assignment scheme. o Eight bytes reserved as a potential target for use with future versions of network protocols. (Some people think that we run out of six-byte addresses as soon as all the toasters et al in the world are addressable. This assumes that we will some day feed all the people in the world, which is another *Good Idea*.) o An appropriate coding scheme to tell these address formats apart within each larger structure. --> Suggestion: Somebody with knowledge of the existing schemes could come up with a reasonable analysis of the difficulties and approaches. HOST LOCATION: This should focus on ease of hierarchical administration and routing, not on squeezing out every last address and bit. As a starting point, what do you lose with fixed length assignments and a three-level administrative hierarchy? From the bottom up: two bytes for area (i.e., local administrators), two bytes for routing domain (i.e., organization administrators) -- this much is just the existing CLNP GOSIP scheme -- and two (or more?) bytes for a new worldwide commonwealth backbone of internet service providers. Such a three-level scheme would work like this: o The existing Internet commonwealth would use the four-byte Internet address of the Host Identifier for routing as well as for identification, as it does now. o All other (new) commonwealths, as well as the existing internet service providers, would be required to be part of a (new) worldwide backbone scheme, and would be allocated identifiers in the highest order two (or more?) bytes of address. Commonwealth identifier allocation would be handled by a body chartered under ISOC/IAB/IETF: See POLITICS at the end of the paper. o Each commonwealth (i.e., internet provider) would be responsible for allocating its own two-byte routing domain identifiers (allowing up to 64K routing domains per commonwealth identifier leaf, with the size of each commonwealth subtree decided by the allocation body). This would allow internet providers to support a large number of routing domains (i.e., independent organizations with large networks or provider internal networks), and to organize their own hierarchical routing schemes. Each routing domain could have multiple interfaces to one or more providers, thus allowing for multihoming at any level of the hierarchy: an interesting routing situation to work out, but not really an addressing problem since there are plenty of addresses to go around. Essentially, the 64K routing domains per provider leaf become the Class B networks of the future. There is plenty of room within this scheme for providers to obtain as large a subtree as needed, for organizations to operate multiple routing domains as needed, and for providers to operate routing domains in support of small organizations. IDRP-BGP would be used between commonwealths and between routing domains. (And for you folks who think that working with CCITT and ISO is so tough, talk to Dave Katz (dkatz@cisco.com) about how easy it was to get IDRP through ISO.) o Each routing domain (large organization or provider internal network) would be responsible for allocating its own two-byte area identifiers (up to 64K areas per routing domain), which it would do with an eye toward its own hierarchical routing and administration situation. The routers in the routing domain would use the IS-IS protocol to learn how to get to all the areas in the routing domain. o With this scheme, all routing to area leaf is by longest prefix, which we know how to do. Routing within an area will work for both IP and CLNP style routing protocols. o Although this three-level routing and addressing scheme would be designed to support IP extensions as well as CLNP, here's a commercial for how CLNP/ES-IS/IS-IS would handle the areas: Within each area, the Host Identifiers are required to be unique (locally unique within the area, but of course, mostly they would be globally unique worldwide). Each host within the area knows its own Host Identifier, and uses ES-IS to broadcast its Host Identifier to the routers on its LAN. The hosts also use ES- IS to listen to their router(s) and find out their entire Host Location prefix and preferred first hops. All the routers in the area share their reachable ES Host Identifiers with the other routers in the area using the IS-IS protocol. So all the routers in the area dynamically know how to get to all the hosts in their area. This almost instantly solves the mobile host problem (within an area). I really don't understand the hostility to the ES- IS and IS-IS protocols: They separate Host Identifier from Host Location, the routers automatically find all their Host Identifiers, the hosts automatically find their Host Location, all without any host-level configuration except power on and maybe some performance management remote tuning. It seems wonderful, it's off-the-shelf, all the system and router manufacturers support it. Why doesn't everyone want to do it? That brings us to: POLITICS: Here's the political situation in my view: o ISOC/IETF should approach CCITT and ISO and simply claim the authority to set up the worldwide Internet commonwealth/provider backbone addressing scheme. Remember, ISOC has just claimed its right to issue international standards for the Internet and to be recognized as a peer of CCITT. Setting up the worldwide backbone scheme would be right in line with that claim, and would be an extension of how the Internet currently works anyway. o I'm sure that GOSIP will eventually go along with any reasonable addressing scheme which Internet comes up with that is compatible with CLNP. What else could GOSIP do but eventually accept it? In fact, the existing GOSIP Version 2 NSAP scheme could support the above proposal: Get two low order bytes of the Administrative Authority Identifier delegated to Internet for its use in creating the worldwide commonwealth providers backbone, leaving two reserved bytes strategically located for future growth. But if ISOC wants to get its own Authority and Format Identifier (AFI), I'm sure it can, and then ISOC can formulate its own NSAP address scheme as long as it's compatible with the existing ISO addressing framework standards (and there's no reason why it shouldn't be). Talk to Rich Colella (colella@osi.ncsl.nist.gov), manager of network protocols at NIST, about all this. o I talked with Milo Medin (medin@nsipo.nasa.gov) about the commonwealth/provider addressing scheme. He agrees (speak for yourself, Milo) that we should indeed be able to come up with some intelligent commonwealth/provider-oriented scheme for the worldwide backbone that would support all proposals for evolution of Big Internet. Now Milo is surely one of the more fervent IPers in the rambunctious Federal network family, so if he and I can agree on this, I hope that lots of other people will consider it carefully. o UK and Australia GOSIPs are formulated around connection- oriented subnetworks, i.e., X.25. The US GOSIP is formulated around connectionless Internet. Which one do you think is going to win? This is *not* "Cultural Imperialism", it's simple technology-driven market force. Let it happen: "If you build it, they will come." Already, the European Procurement Handbook for Open Systems (EPHOS), which is the European Community's procurement profile in this area, recognizes the US GOSIP profile as optional (meaning they'll buy it). If the Big Internet solution is compatible in some upward evolutionary way with off- the-shelf CLNP/ES-IS/IS-IS, there will be no limitation on internet market growth caused by confusion and uncertainty. From owner-Big-Internet@munnari.oz.au Wed Jul 29 10:27:59 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA08965; Wed, 29 Jul 1992 10:28:18 +1000 (from owner-Big-Internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA08950; Wed, 29 Jul 1992 10:27:59 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07225; Tue, 28 Jul 92 20:27:49 -0400 Date: Tue, 28 Jul 92 20:27:49 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207290027.AA07225@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov Subject: Re: transitions and uncertainty Cc: jnc@ginger.lcs.mit.edu Do not have time to wait and "settle" all of these and still manage joint routing/addressing problems of current net. No, NO, ***NO***! I see *no* reason why we cannot deploy a new routing and addressing system as an adjunct to the current host-visible packet layer, if we go the ID route (it was one of the reasons I picked the ID route as the deployment path for Nimrod). Please explain why I am wrong. Noel From owner-Big-Internet@munnari.oz.au Wed Jul 29 10:42:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09527; Wed, 29 Jul 1992 10:42: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 AA09524; Wed, 29 Jul 1992 10:42:53 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07284; Tue, 28 Jul 92 20:42:44 -0400 Date: Tue, 28 Jul 92 20:42:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207290042.AA07284@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, hitchcoc@oerv01.er.doe.gov Subject: Re: transitions and uncertainty Cc: jnc@ginger.lcs.mit.edu multiple changes, especially to host software, is a bad or at least unpopular thing. Absolutely, and since we can't design a system with good and tested resource allocation yet, we can't step straight to something that won't need to change again shortly. If anyone thinks putting in some blank fields and hoping will do, ask yourself "how well did the TOS hooks that were put into IP4 work to do *real* QOS"? I remember (perhaps the only active participant on this list other than Dave Clark to do so :-) the arguments over what to put in this field when IP4 was being done. Turns out we were wasting our time; we could have flipped a coin, since it was all 92% broken anyway. Users hate to see the things that are visible to them about their environment (which in IP includes their address) change. True, but they will probably like having the network stop working even less. Of course, if we make the current 'address' field an ID, we probably can avoid changing the contents of this field for most people. (CIDR may be a bit more problematic, but I'm more thinking about the long range.) Some route aggregation will be needed whether it is hierarchical or some complex other topology. You're saying something I agree with, but in a very Destination-Vector view of the world way. Modern routing technology (i.e. Link State) does not exchange routing tables (although it may calculate them internally for certain limited kinds of efficiency). A better way to put this is that calculating the optimal route, which requires complete information, is too expensive (the bulk of information is too expensive to ship around), and we will have to use abstracted routing information (which is less expensive to ship around, but creates non-optimal routes) to create routes. Backward compatbility is very important. Absolutely. Any scheme which is not deployable in an interoperable way is simply a non-starter. Any scheme for global coordination of ID's and routing info will have significant bureaucratic hassles Not necessarily. IEEE 48 bit ID's are handed out with a great deal of fuss, for example. From owner-big-internet@munnari.oz.au Wed Jul 29 12:09:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12045; Wed, 29 Jul 1992 12:10:00 +1000 (from owner-big-internet) Return-Path: Received: from gateway.bnr.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07765; Wed, 29 Jul 1992 09:47:55 +1000 (from FORTINP@BNR.CA) Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA11169; Tue, 28 Jul 92 19:47:42 -0400 Message-Id: <9207282347.AA11169@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 4615; Tue, 28 Jul 92 19:45:50 EDT Date: 28 Jul 92 19:48:00 EDT To: From: Pierre (P.) Fortin Subject: Re: iv7 congestion control - tradeoff point? Sender: Pierre (P.) Fortin > I think what people are saying is simply that if a router has two > duplicate packets in its queues, it can safely discard one, with consequently > less wastage of resources, without making the situation any worse. Presumably > you would discard the newer of the two, i.e. the one furthest away from being > sent back out. > > Noel > This would be most welcome (operationally vs architecturally) even as a way of overcoming the current NFS over WAN problems we constantly experience: fixed timers vs dynamic traffic loading on WAN. _Other_ flows congesting the net which causes more NFS traffic which becomes _other_ to the _other_ flows... Hundreds of NFS mounts across DS-3/FDDI are no less immune than one over a slow link; this should be scalable (that word again :^) and worth doing... Does anyone have any idea where the tradeoff between implementing/ignoring this would be in existing routers (and at which bandwidths & queue sizes)? In the case of large-buffer multi-packet services like NFS, isn't it likely many originals/duplicates will be dropped by a full queue anyway during congestion periods resulting in more retransmissions which add to the problem, but with no dups in the queues to be detected/discarded? Besides, there are usually so many other flows that relative to the queue sizes, the chances of finding duplicates start approaching that of lotteries. And if the traffic is light (little or no congestion), why bother? Can you say "network avalanche"...? :^) Pierre From owner-Big-Internet@munnari.oz.au Wed Jul 29 12:56:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA13266; Wed, 29 Jul 1992 12:56:43 +1000 (from owner-Big-Internet) Return-Path: Received: from shark.mel.dit.CSIRO.AU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA13263; Wed, 29 Jul 1992 12:56:36 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA02885 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 29 Jul 1992 12:56:51 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA00751; Wed, 29 Jul 92 12:56:33 EST Message-Id: <9207290256.AA00751@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: Separation of routing and system identification in TUBA - thoughts In-Reply-To: Your message of "Tue, 28 Jul 92 10:29:51 -0400." <9207281429.AA28669@ginger.lcs.mit.edu> Date: Wed, 29 Jul 92 12:56:33 +1000 From: Bob Smart > I know not everyone agress with all parts of this; Bob Smart has >had ideas on variable length identifiers, for instance. Maybe we should >tackle this first; fixed or variable length? I've been convinced that it should be fixed length 64 bits. That's an extra 32 bits for fanout. We'd have to squander it very stupidly for it to be insufficient. As Noel said an ID fanout should waste less than 50%, so 64 bits is plenty. We don't have to decide anything about the fanout yet: just reserve the top 32 bits == 0 for use with the initial IP4 compatible scheme. > Listen, everyone, deploying an entire new routing and addressing >architecture is going to be a big enough pain in our lives. I am utterly >dumbfounded that people are seriously talking about doing a new host-visible >packet format at the same time. Just the first is going to be a big enough >thing to chew off; are we all mad, to consider the second as well? > I have yet to hear what I consider a solid argument that this is >*necessary*, let alone a *good idea*. (I except one message from Bob S I >haven't had time to parse yet. :-) Come on, my stuff isn't that hard to parse. Actually my parser is having trouble with "that this is *necessary*, let alone a *good idea*". What we are proposing in allowing hosts to use the existing packet format with a new meaning for some fields, and without changing the host software, is a backward compatibility hack. It should work a lot better than earlier schemes for address translation, but it is still not a clean engineering solution. As a practical point it will impose an unknown extra amount of load on some routers. I think we can restrict that to the local router. Even so the IETF should not even consider this as _the_ solution unless they've seen it running and got reasonable estimates of the performance impact. It is an engineering fact of life that sometimes it costs less to build a new bridge than to prop up the old one, _even_ when you know you can't afford the bridge you'll need in 6 years time. I have high hopes that we can find an ID+address solution that will avoid any need to split Internet host connectivity. However it is for us to prove we can do it, not challenge others to prove we can't. Certainly Noel's suggestion that some hosts can be modified to tell their local router about ID->address translations as they come in from the DNS should take load off the local routers. Noel also suggested lightly that routers could tap the wire for DNS packets, but that is rather horrible, and might add more load than it saves. Suppose the backbone format is PIP. I certainly don't think the argument that it was designed in the wrong order proves anything about its suitability. If it isn't suitable we need an alternative proposal with clear practical advantages. To me it is obvious that PIP will do the job. Suppose we have a transition plan for PIP that handles IP4 hosts in the proposed way. What Noel is saying is that it isn't necessary to do the whole transition and get to the stage where PIP is actually running in hosts. Actually we don't have to decide in November how much of the transition plan we'll do. We can leave the question of PIP's suitability for end systems to be "For Further Study". Let's not decide more than we have to. However I have an argument that convinces me that we won't need an IPv8 beyond PIP. One unavoidable requirement of a packet format is that it should be used by routers to determine a simple question: "what output queue should I put it in?". You can spread the information around in the packet as with IP4 and let the router analyse it OR you can get the source to analyse that information and collect it in a simple place so that the router can handle it in a very dumb fashion. Clearly the latter is right if it is at all possible. To me PIP is an existance proof that it is possible. What more can you do? Having a simple forwarding scheme is all you can do for performance. Allowing flows is all you can do for attaching resources to connections. We can do some things about security, but does it belong at this level? Surely accounting information should be done in options (and is very closely bound up with resource allocation). At the moment no-one has any substantive thing they want to do that PIP doesn't cover, there is just a vague feeling that we don't understand things well enough to decide. That is an argument for never doing anything. Let's stay in bed and not get up today. At the very least if there is a PIP backbone we can have some experimental PIP hosts and use them to experiment with flows and source routed policy based routing and other new ideas. We will then be in better shape to know if we need a different host visible packet format. So any proposal for a backbone format that was not suitable for end systems would need to have significant other advantages. I can't even imagine such an alternative, and time is running out for such a proposal to even enter the race. Bob Smart From owner-big-internet@munnari.oz.au Wed Jul 29 13:42:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14428; Wed, 29 Jul 1992 13:42: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 AA10869; Wed, 29 Jul 1992 11:29:43 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA07549; Tue, 28 Jul 92 21:29:38 -0400 Date: Tue, 28 Jul 92 21:29:38 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207290129.AA07549@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, desjardi@boa.gsfc.nasa.gov Subject: Re: Host Identifier and Location Cc: colella@osi.ncsl.nist.gov, dkatz@cisco.com, jnc@ginger.lcs.mit.edu, medin@nsipo.nasa.gov Dick: Your section on identifiers is pretty good, although, as I have pointed out innumerable times in mail to this list, and which I will spare you all so doing again, hosts are not the things we should name with them. For the four separate lengths (and I don't know whether the longest should be 64, 96, or something else) bits, I would suggest that you embed them all in the large space, with the requisite amount of leading 0's in each case. (I hope this doesn't cause any conflicts!) I.e. (assuming 64 bit id's), 32 bits of zero, an 32 bit IP 'address' could be embedded with 32 leading 0 bits. IEEE numbers would have 16; were IEEE addresses with the first 16 bits 0 ever assigned (they would conflict with this suggestion for IP 'addreses')? The 'host location' section has more problems, to my eye. As a starting point, what do you lose with fixed length assignments and a three-level administrative hierarchy? Lots. Sooner or later you will hit a stone wall and wish you never did this; the resulting pain would be substantial. Imagine street addresses could only have a maximum of 4 digits; El Camino Real numbers wouldn't fit. Image mail addresses could only have 3 items below country (state, city/county, and street address); how would you handle apartments? Truly flexible addresses, variable numbers of variable length levels, will likely last you much longer, and cause less pain in so doing. They are more work to parse, so just arrange to parse them less often, and add hints to make parsing them faster when you do have to. an interesting routing situation to work out, but not really an addressing problem since there are plenty of addresses to go around. Here we go again, designing the addresses, and leaving the routing to be solved later. I will again omit the diatribe. (Which reminds me, that's another message I owe Bob S a reply on...) IDRP-BGP would be used between commonwealths and between routing domains. I assume from this that you don't intend to try do do any congestion avoidance/resource allocation tie-in in your routing at this level? mostly they would be globally unique worldwide Either they are or they aren't. If they aren't, they are only about 15% as useful as if they are. Each host within the area knows its own Host Identifier, and uses ES-IS to broadcast its Host Identifier to the routers on its LAN. Why put all this extra load on the routing for the minimal benefit of allowing hosts to be mobile within their area? I understand why DECNet IV had this capability, but multi-drop LAN's and WAN's are the rule these days, right? He agrees (speak for yourself, Milo) that we should indeed be able to come up with some intelligent commonwealth/provider-oriented scheme for the worldwide backbone that would support all proposals for evolution of Big Internet. Milo should know better. While we need abstraction to make routing work on a world-wide scale, it seems to me unlikely that the "routing table" model of routing which this proposal seems to be oriented towards (I know, I know, IS-IS is LS, but it effectively uses DV for going outside the routing domain) is not the way to handle diverse policy needs in very large networks. When you get into your car to drive cross-country, what do you look at; a map of the interstate system, or a big table which lists which turns to take for large numbers of destinations? Noel From owner-Big-Internet@munnari.oz.au Wed Jul 29 14:55:36 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17154; Wed, 29 Jul 1992 14:55: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 AA17151; Wed, 29 Jul 1992 14:55:36 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08263; Wed, 29 Jul 92 00:55:27 -0400 Date: Wed, 29 Jul 92 00:55:27 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207290455.AA08263@ginger.lcs.mit.edu> To: big-internet@munnari.oz.au, smart@mel.dit.csiro.au Subject: Re: Separation of routing and system identification in TUBA - thoughts Cc: jnc@ginger.lcs.mit.edu I've been convinced that it should be fixed length 64 bits. You had some interesting arguments about making it easy to allocate new ones, but I really think the ease of dealing with a fixed length thing (which I imagine you will look at all the time) is very substantial. I mean, even in hardware, fixed length things are good; that's why RISC machines all have fixed length instructions. I admit I haven't done the calculations to be sure, but my guess is 64 is enough. If we do pick 64, I think we ought to consider if it is possible to design packet formats, etc, to make it easy to go up to 96 (i.e. leave 32 bit MBZ fields in the right places, etc). Come on, my stuff isn't that hard to parse. It's not that it's hard to understand what you are saying, it's that I have to *think* hard to craft the reply! Actually my parser is having trouble with "that this is *necessary*, let alone a *good idea*". What I was trying to say is that you might switch to a new format either because you simply had no choice, or because you saw some advantage to be gained in so doing. The former is probably more powerful that the latter; sort of like someone trying to convince you by threatening you with a gun versus offering you a bunch of money. You might turn down the latter, but probably not the former! What we are proposing in allowing hosts to use the existing packet format with a new meaning for some fields, and without changing the host software, is a backward compatibility hack. ... it is still not a clean engineering solution. Oh, absolutely. I only liked it because of the interoperability issues, and because in doing so it allows the cleanest sheet of paper for the *new* system to be built on. The bit about allowing putting off a new packet format was only added recently, after I talked to Van; it wasn't in Nimrod originally. Even so the IETF should not even consider this as _the_ solution unless they've seen it running and got reasonable estimates of the performance impact. Again, no argument here. My only comment would be that you need to balance the cost (i.e. the performance impact for unmodified hosts, and how easy it is to modify hosts to greater efficiency) against the benefit (the ability to delay going to a new host-visible packet format, quality of the newly designed part of the system, etc). Also, I don't know but that a demonstration isn't already on hand. IDPR routes on AS number, which is looked up in the DNS along with the 32-bit IP thing in a way very similar to what is proposed for new addresses in Nimrod. I thought they had a mode to work with unmodified hosts (i.e. have the router look up an AS number, given a 32-bit thing), but am not sure about this. I don't know enough about the IDPR field trials to know whether they have got to a stage where they could measure this. Any IDPR'ers on this list? However it is for us to prove we can do it, not challenge others to prove we can't. True, a demonstration is necessary (that's the IETF way :-) but is there some equivalent test for those who want a new packet format? How can you prove you need a new format? Can you only prove you don't? Can you prove a new format, designed today, will have everything we need in 10 years? some hosts can be modified to tell their local router about ID->address translations as they come in from the DNS should take load off the local routers Yes, and what's nice about this optimization is that it can be restricted to a single module (get_host_by_name I think it's called), and in the applications to boot. There may be some cases that this misses, but I expect you can live with the cost of the router doing the lookup in a few cases.. routers could tap the wire for DNS packets, but that is rather horrible, and might add more load than it saves Oh, I agree, it's horrible. I only suggested it as an additional possible optimization, one that doesn't require changes to the hosts. I'd much prefer not to have to do it! I certainly don't think the argument that it was designed in the wrong order proves anything about its suitability. I hope to provide an answer to this tonight, in answer to your previous message during IETF week. However I have an argument that convinces me that we won't need an IPv8 beyond PIP. One unavoidable requirement of a packet format is that it should be used by routers to determine a simple question: "what output queue should I put it in?". I think the reasons we may need a format beyond PIP are that a) the IP layer is used by more than the routers; some information in it is used at the ends, and b) routers in the future may have to do more with packets than forward them to their next hop. In both of these areas, we may need to have the packet layer do things which we don't fully understand yet. It's hard to see that we can design a packet format which will do everything we need the packet layer to do when we don't yet know for sure what it is we need to do! That is an argument for never doing anything. Let's stay in bed and not get up today. I understand that this is a danger. Believe me, I am a big believer in bold strokes which are technically extremely radical (e.g. Nimrod itself :-), so it's not that I am scared of changing the IP format, or anything. It's just that I am really convinced that the benefits (i.e. new capabilities) we can get with a new packet format *at this point* are not worth the cost in upheaval on the hosts. This is clearly a value judgement, and thus harder to analyze rationally, although we could probably be more rigorous about it than we have been so far. Anyone want to take a crack at listing exactly what capabilities (including more option space, and longer ID's) we'd get from a new packet format? (It needs to list things you'd get *only* from a new packet format, or a mandatory option, which is effectively the same thing.) Noel From owner-Big-Internet@munnari.oz.au Wed Jul 29 15:13:08 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17597; Wed, 29 Jul 1992 15:13:17 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207290513.17597@munnari.oz.au> Received: from rschp1.anu.edu.au by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA17586; Wed, 29 Jul 1992 15:13:08 +1000 (from hugh@rschp1.anu.edu.au) Received: by rschp1.anu.edu.au (16.8/16.2) id AA29845; Wed, 29 Jul 92 15:11:49 +1000 From: Hugh Fisher Subject: Re: Host identifiers To: big-internet@munnari.oz.au Date: Wed, 29 Jul 92 15:11:49 EST Mailer: Elm [revision: 70.30] Speaking as an application programmer, make host/endpoint identifiers a fixed 64 bits, and they have to be globally unique, not just within a region. Fixed 64 bits because variable length things are a hassle to deal with: I don't WANT to know about the structure. It is quicker and easier on all the machines I work with to copy eight bytes from place to place than to extract some count, then copy that many bytes (assuming we are talking up to 16 bytes at most.) Make it 64 bits rather than 48 because it aligns nicely in memory, and is big enough to enclose other schemes. Make it globally unique because I can imagine groups of cooperative applications passing identifiers around, especially broker/resource manager type apps "Hey, let this other process know when you've finished, OK?" As for structure and assignment, the Ethernet people already have worked this out so set up a similar scheme? Maybe reserve the 64 bit space with the top 32 zero for the current IP addresses? From owner-Big-Internet@munnari.oz.au Wed Jul 29 15:41:50 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18396; Wed, 29 Jul 1992 15:42:58 +1000 (from owner-Big-Internet) Return-Path: Received: from optics.wc.novell.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18370; Wed, 29 Jul 1992 15:41:50 +1000 (from minshall@wc.novell.com) Received: from localhost.wc.novell.com by wc.novell.com (4.1/smi4.1.1.v91190) id AA14722; Tue, 28 Jul 92 22:41:19 PDT Message-Id: <9207290541.AA14722@wc.novell.com> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: some nits In-Reply-To: Your message of "Tue, 28 Jul 92 21:29:38 EDT." <9207290129.AA07549@ginger.lcs.mit.edu> Date: Tue, 28 Jul 92 22:41:19 -0700 From: minshall@wc.novell.com There are some little nits in current host IP implementations which make it slightly difficult to remove all topological information from IP addresses (ID's): 1. Many hosts don't react well if they are told that the local router is on a different subnet (addr&mask == addr&mask) from the host's address on a given interface. [Well, you could say the subnet mask is zero, but ...] 2. If two hosts are on the same physical subnet but NOT on the same logical subnet (addr&mask == again...), they are going to want to talk to each other through a router. If we had ES-IS, then IF there were a router, the router could redirect them. [Well, you could say the subnet mask is zero, but ...] 3. If two hosts are on different physical subnets but on the same logical subnet, they are going to ARP for each other (i don't need to go on, do i?)... [Well, you could say the subnet mask is all ones, but ...] Again, nits. But, sometimes nits, nails, horseshoes, ... Greg Minshall From owner-Big-Internet@munnari.oz.au Wed Jul 29 16:30:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA19365; Wed, 29 Jul 1992 16:31: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 AA19337; Wed, 29 Jul 1992 16:30:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA08607; Wed, 29 Jul 92 02:29:44 -0400 Date: Wed, 29 Jul 92 02:29:44 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207290629.AA08607@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, smart@mel.dit.csiro.au Subject: Re: Route fragments, a routing proposal Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu This is in reply to a message you sent (on July 16) when we were going down the thread of my claim that it's wrong to design the address before you have done the routing architecture. [Technical content starts at the '***', for those who wish to skip to it.] I sent a message where I indicated that I was unable to give more clear logic than I did in that message why I felt this was so. (I was, in truth, frustrated at my inability to communicate what I understood.) You replied, with understandable frustration, that you didn't understand what the hell I was talking about. I attempted to formulate a reply (at 4AM in the morning in the middle of the IETF :-), spent an hour at it, discovered there was more to your question than I first thought, and that I needed to do a lot more thinking, and put my draft reply away. I'm not sure this reply will be satisfactory either, but if you will put up with my difficulty in expressing things in English that I seem to understand in some bizarre non-verbal way, I will keep trying. This is actually very useful (if painful to us both :-), since it is helping me to refine the exposition. I've finally found the time (after the brou-ha-ha, digging my life out, etc) to write my thoughts down, so, on to the reply. When I hear someone mention the OSI 7-layer model my mind goes "Bullshit alert... batten down the hatches". Your messages are starting to have the same effect. I hope that Dave P and Ross C got as good a chuckle out of this as I did! Must say, never thought I'd be classed in with the OSI 7-layer model! But this endless sequence of English sentences couched in general terms is not getting through to me. I concede that I tend to talk in abstractions about this. I also note that it took me years of drawing the generic little stupid JNC dots and arcs maps (which Dave Clark and Deborah Estrin will undoubtly remember so well :-) until I could think about routing at a pure abstraction level, as opposed to in terms of examples. I do think about routing now at an abstract level, as opposed to drawing mental pictures of what I very dimly glimpse. I prefer the precision and conciseness of this, but admit I may not be great at communicating this stuff to everyone. Perhaps I should be drawing more pictures for people, but realize that I now see things at an abstract level and translate that directly into pseudo-formal statements which I admit can sound handwavy (particularly without formal notations and proofs). Also, I have this tendency to give great weight to computer science principles (e.g. 'early binding is the root of all evil'), and I concede I sometimes consider a debate settled by mentioning one, whereas the other party, not having the same attitude, may consider it an inappropraite platitude. Something on the level of the PIP overview would be good. Frankly, I mostly skip the examples in routing papers now, because I don't have whatever it takes to work through them; usually lots of numbers, letters, dots and lines I don't have the patience to plow through. This does occasionally bite me, when an example shows something which isn't pointed out in the text. *** >- provides a framework for the abstraction process I don't know what "providing a framework" means, but it sounds like too much work for a simple thing like an address. If you have drawn nested loops on your network map which represent the boundaries of the parts of the network which you will name as higher level 'areas', the names of which are generally the components of the various levels of the hierarchical address, generally these areas are the things which you will be advertising in the routing when you want to abstract (or 'aggregate', if you like) routing data. In that way, the things which serves as components of the address are also the higher level things which are the routing advertises when it aggregates routing data. I.e. you are somewhat limited in terms of what you can name as aggregated objects in the routing to the things which are used in naming addresses. Clear as mud, right? Well, imagine a system in which the names of aggregated objects (for use in routing) were different from the names used to address interfaces. Put another way, imagine two different sets of nested circles drawn on the topology map; one set is used for distributing (and aggregating) routing data, and a different set is used for creating heirarchical addresses. You'd clearly have to have some way of getting from one to the other, etc. However, in this system, addresses *would not* be providing the aggregation framework for routing. Does this help? Apart from that all these things are trivially provided by PIP. A part of the problem is that none of the three distinct components of the PIP header is just an 'address', as in my meaning of a structured name for a network attachment point. The RD may contain an address, but has the semantics of (and in most cases is) a source route. The HD is clearly not an address, and neither is the ESI. About only 'address' I could find in the PIP overview document are in the examples! PIP *mostly* consists of a header format which in some ways provides enormous flexibility to do various thing, and in other ways takes certain views about how packet forwarding ought to happen (e.g. provides facilities for having a routing step intermingled with the forwarding; i.e. hop-by-hop routing). All very interesting and useful, but it some sense outside the scope of Nimrod! The latter concerns itself mostly with the distribution of routing information, and what that information should look like, not how it is used to forward packets. However, this is begging the real issue, which is why I think PIP (and other) addresses are not specified enough to be useful; showing this, I think, is another way of saying why you have to do the routing arhitecture first. (I hope this is more useful than the previous attempt!) A PIP address seems to consist of a ordered set of identifiers, which individually identify nested topological aggregations; the address as a whole names a network attachment point. The problem is that this is a pretty generic description of *any* heirarchical address. Sure, the *syntax* is pretty much the same in all of these, but the *semantics* may differ considerably. We learn a little of the semantics of PIP addresses, but not a lot. The bottom one seems to identify an interface. Each (as far as I can tell from the examples; I don't see it talked about in the text) is assumed to be unique only in the immediately higher topological aggregation. My list of 6 things in the message you replied to was, I see now, a list of the *different* tasks (as the example above with 'abstraction framework' showed) which addresses must perform in the course of being the key data which the routing system deals in. My plaint was that without knowing more about how the routing works (which influences what these tasks are like in detail), it's hard to really specify the semantics of the address. I don't consider an addressing scheme fully specified until the semantics of addresses are done, and we can, for example, say which kinds of addresses are legal, and which are not. Syntax alone does not make it for me! Also, slight differences of how various tasks are performed in various routing architectures may mean that a syntax which is appropriate for one particular routing design (and its specific versions of the set of tasks) is not appropriate for another design. Here is some examples of some of these. Can a K level object (i.e. area) contain anything other than K-1 level objects? If so (using the notation [Name0.Level0, ... NameN.LevelN]), you can get addresses of the form [A.5, X.1], as well as [A.5, B.4, C.3, D.2, E.1]. If not, then the former example is illegal. Here's another one; can an address for an interface not be fully specified? E.g., if we kept an ARP like thing, it might be possible to utilize the address/id tuple { [A.5, B.4, C.3, D.2], ID=Q } to name a interface just as clearly as the [A.5 .. E.1] example. You get to physical network D.2 and then find the interface behind which ID Q is resident. There are other (more complex) examples having to do with aggregation and flexible no-brainer routing; some ways of doing this optimization mean that two K level objects both contain the same piece of the physical topology. (I.e., the circles overlap on the map). Again, hard to say what should be allowed, until you have worked out how you are going to perform this optimization. Sure, you can say, we'll define the syntax of addresses, and let the hosts parse that, but leave the semantics till later, and let the routers deal with that. I just don't think that's very useful; for all the good it does the hosts, they might just as well be byte strings. About the only useful thing you can do with things where you understand the syntax, but not the semantics, is read and print them in convenient forms. You can't really use them fully, since you don't know what they *mean*, really. Well, I'm not sure this is much more help than the previous attempt, but I think it's a little better. My brain is now fried totally, so I'll fire this off. Mull this over and ask away! Noel From owner-Big-Internet@munnari.oz.au Wed Jul 29 17:42:03 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21071; Wed, 29 Jul 1992 17:43:05 +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 AA21039; Wed, 29 Jul 1992 17:42:03 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA06855 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 29 Jul 1992 17:42:04 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA01595; Wed, 29 Jul 92 17:41:45 EST Message-Id: <9207290741.AA01595@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal In-Reply-To: Your message of "Wed, 29 Jul 92 02:29:44 -0400." <9207290629.AA08607@ginger.lcs.mit.edu> Date: Wed, 29 Jul 92 17:41:43 +1000 From: Bob Smart >I hope that Dave P and Ross C got as good a chuckle out of this as I did! >Must say, never thought I'd be classed in with the OSI 7-layer model! In the early days of OSI when there were no products or even real protocols, sales type people kept putting up pictures of 7-layer towers with 3-layer tram stops in between. Companies took out big ads saying how XYZ Network Architecuture complies (!?) with the OSI 7 layer model. That is the thing I was remembering. I wasn't commenting on actual OSI protocols, which is what the IETF is interested in, and certainly CLNP and associated protocols are quite sensible (though it would be nice to come up with something more functional for IPv7). > All very interesting and useful, but it some sense outside the scope >of Nimrod! The latter concerns itself mostly with the distribution of routing >information, and what that information should look like, not how it is used to >forward packets. Well exactly. The point of PIP is that whatever the routing architecture and however the addresses are conceived, the source converts this into a packet format which is oriented to packet forwarding in the router. I've just thought of a good analogy: the router tables which PIP uses along the way are like a memo capability in a Functional Programming Language. The function that they memo for can be as general as you like. Bob Smart From owner-Big-Internet@munnari.oz.au Wed Jul 29 18:10:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA21706; Wed, 29 Jul 1992 18:11:43 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207290811.21706@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA21670; Wed, 29 Jul 1992 18:10:32 +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, 29 Jul 1992 09:05:45 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: des@spock.retix.com, Big-Internet@munnari.oz.au, end2end-interest@ISI.EDU Subject: Re: iv7 congestion control In-Reply-To: Your message of "Tue, 28 Jul 92 16:16:53 EDT." <9207282016.AA03930@ginger.lcs.mit.edu> Date: Wed, 29 Jul 92 09:05:34 +0100 From: Jon Crowcroft > Jon, I don't think people are trying to discard packets (duplicate or >not) from flows which are causing congestion as a means of 'punishing' >congesters. > I think what people are saying is simply that if a router has two >duplicate packets in its queues, it can safely discard one, with consequently i think you are making BIG assumptions about TCPv7 here i mean if we get to put a) craig's flow spec in IPv7/PIP b) congestion experienced bits c) flow id's then TCPv7 can have some serious e2e congestion smarts plus we can tidy up 1323 extensions & roll them into a nicer header and remove ports (and push bit) and maybe put in application frame markers instead... and unify the audi/video transport at the same time... jon From owner-Big-Internet@munnari.oz.au Wed Jul 29 18:55:09 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA22587; Wed, 29 Jul 1992 18:56:12 +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 AA22542; Wed, 29 Jul 1992 18:55:09 +1000 (from Z.Wang@cs.ucl.ac.uk) Received: from bells.cs.ucl.ac.uk by shark.mel.dit.csiro.au with SMTP id AA07911 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 29 Jul 1992 18:51:55 +1000 Message-Id: <199207290851.AA07911@shark.mel.dit.csiro.au> Received: from sol.cs.ucl.ac.uk by bells.cs.ucl.ac.uk with local SMTP id ; Wed, 29 Jul 1992 09:48:45 +0100 To: Dick desJardins Cc: big-internet@munnari.oz.au Subject: Re: Host Identifier and Location In-Reply-To: Your message of "Tue, 28 Jul 92 19:42:31 EDT." <9207282342.AA02190@boa.gsfc.nasa.gov> Date: Wed, 29 Jul 92 09:48:42 +0100 From: Zheng Wang >HOST IDENTIFIER and LOCATION, with POLITICS >by Dick desJardins > >There does seem to be a growing opinion that Host Identifier >should be globally unique and separate from Host Location which >should be used for routing. Can the Internet community come up >with a scheme for both of these in the near term that would be >compatible with any medium or long term solution to the Big >Internet problem? That would benefit everybody. Here are my >(not necessarily naive) ideas in three areas: Host Identifier, Host >Location, and Politics. The question we face is not whether we should have host IDs separate from host locations or not. Most people will agree that we need host IDs and Locations. In current Internet, we have domain names (sort of host IDs) and addresses (host locations). The issue is wether we should use host IDs in the communication subnet or not. For example, in Pip, the host ID is translated to the address at the source host (ie. outside the communication subnet) and the address is carried in packets for routing. In Nirmod, the host ID is translated by routers during setup (ie. inside the communication subnet) and the host ID is carried in packets for routing. Zheng From owner-Big-Internet@munnari.oz.au Wed Jul 29 21:59:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA25554; Wed, 29 Jul 1992 22:01: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 AA25540; Wed, 29 Jul 1992 21:59:53 +1000 (from smart@mel.dit.csiro.au) Received: from wanda.mel.dit.CSIRO.AU by shark.mel.dit.csiro.au with SMTP id AA09139 (5.65c/IDA-1.4.4/DIT-1.3 for ); Wed, 29 Jul 1992 21:59:58 +1000 Received: by wanda.mel.dit.CSIRO.AU (4.1/SMI-4.0) id AA02221; Wed, 29 Jul 92 21:59:40 EST Message-Id: <9207291159.AA02221@wanda.mel.dit.CSIRO.AU> To: big-internet@munnari.oz.au Subject: Re: some nits In-Reply-To: Your message of "Tue, 28 Jul 92 22:41:19 MST." <9207290541.AA14722@wc.novell.com> Date: Wed, 29 Jul 92 21:59:39 +1000 From: Bob Smart >1. Many hosts don't react well if they are told that the local >router is on a different subnet (addr&mask == addr&mask) from the host's >address on a given interface. [Well, you could say the subnet mask is >zero, but ...] As you say we can set the subnet mask to 0. However I think we should try to make it work without changing hosts at all. To handle this I suggest we reserve IDs with low order byte of 1 for routers. Then if a subnet has a host with ID 4.5.6.7 then the primary router will respond to 4.5.6.1 as one of the numbers for itself. If there is more than one router on the wire then we come down to point (2) in your list and the primary router for that wire might have to forward the packet. There are some issues, like broadcast address which are still difficult unless you set the subnet mask to 0. However these problems are not too bad since people run multiple subnets on one wire today. >2. If two hosts are on the same physical subnet but NOT on the same >logical subnet (addr&mask == again...), they are going to want to talk >to each other through a router. If we had ES-IS, then IF there were a >router, the router could redirect them. [Well, you could say the subnet >mask is zero, but ...] The worst that happens is that if you can't set mask to 0 then packets go through a router, as happens today where some people have multiple subnets on one wire. However apart from mobility the need to have hosts with very different IDs on one wire is not great. It is more the other way around: we want to use all of a range of IDs so we want to have 9 hosts on one subnet and 130 on another, etc, all using the same top 24 bits. >3. If two hosts are on different physical subnets but on the same >logical subnet, they are going to ARP for each other (i don't need to go >on, do i?)... [Well, you could say the subnet mask is all ones, but ...] The router responds on behalf of the destination (proxy arp). In fact ciscos do this today: I noticed that many of our hosts have subnet mask set to 255.255.0.0 instead of 255.255.255.0, but the cisco makes it all work. Bob Smart From owner-big-internet@munnari.oz.au Thu Jul 30 02:45:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01689; Thu, 30 Jul 1992 02:47:52 +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 AA23577; Wed, 29 Jul 1992 19:56:00 +1000 (from avalon@coombs.anu.edu.au) Received: by coombs.anu.edu.au (5.61/1.0) id AA16200; Wed, 29 Jul 92 19:54:38 +1000 From: avalon@coombs.anu.edu.au (Darren Reed) Message-Id: <9207290954.AA16200@coombs.anu.edu.au> Subject: Re: Host Identifier and Location To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Date: Wed, 29 Jul 92 19:54:37 EST Cc: big-internet@munnari.oz.au In-Reply-To: <9207290129.AA07549@ginger.lcs.mit.edu>; from "Noel Chiappa" at Jul 28, 92 9:29 pm Reply-To: avalon@coombs.anu.edu.au X-Mailer: ELM [version 2.3 PL11] In some email I received from Noel Chiappa, they wrote: [...] > As a starting point, what do you lose with fixed > length assignments and a three-level administrative hierarchy? > > Lots. Sooner or later you will hit a stone wall and wish you never did > this; the resulting pain would be substantial. > Imagine street addresses could only have a maximum of 4 digits; El > Camino Real numbers wouldn't fit. Image mail addresses could only have 3 items > below country (state, city/county, and street address); how would you handle > apartments? > Truly flexible addresses, variable numbers of variable length levels, > will likely last you much longer, and cause less pain in so doing. They are > more work to parse, so just arrange to parse them less often, and add hints to > make parsing them faster when you do have to. Is there any chance that variable length addresses could be a win for SLIP or PPP too ? For two hosts on a slow line, they only need 1 byte of addressing to satisfy that local 'network'. I'm not sure if there are any real savings here, but 1 byte compared to 8 (for 64bit address) might make a few people with slow links happy. Darren. From owner-Big-Internet@munnari.oz.au Thu Jul 30 04:49:58 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03851; Thu, 30 Jul 1992 04:51:10 +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 AA03835; Thu, 30 Jul 1992 04:49:58 +1000 (from oran@sneezy.lkg.dec.com) Received: by mts-gw.pa.dec.com; id AA03280; Wed, 29 Jul 92 11:48:37 -0700 Received: by sneezy (5.57/ULTRIX-4.2-3)id AA11153; Wed, 29 Jul 92 14:48:33 -0400 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, desjardi@boa.gsfc.nasa.gov, colella@osi.ncsl.nist.gov, dkatz@cisco.com, medin@nsipo.nasa.gov Subject: Re: Host Identifier and Location In-Reply-To: <9207290129.AA07549@ginger.lcs.mit.edu> References: <9207290129.AA07549@ginger.lcs.mit.edu> X-Mailer: Poste 2.0B3 From: Dave Oran Date: Wed, 29 Jul 92 14:48:32 -0400 Message-Id: <920729144832.10820@sneezy.lkg.dec.com> > Milo should know better. While we need abstraction to make routing > work on a world-wide scale, it seems to me unlikely that the "routing table" > model of routing which this proposal seems to be oriented towards (I know, I > know, IS-IS is LS, but it effectively uses DV for going outside the routing > domain) is not the way to handle diverse policy needs in very large networks. > When you get into your car to drive cross-country, what do you look > at; a map of the interstate system, or a big table which lists which turns > to take for large numbers of destinations? > > > Noel Good analogy Noel. At the risk of getting us farther afield, let me take it a bit farther. Many maps have big black spots on them. Maps published in the US had big black spots where the Soviet Union is (was) during the 1930s. The reason is that not just the internal topology, but the policies for traversing that region of the map, may be private to the supplier. If you buy this argument, then link state can't be used for interdomain routing, since the raw (even aggregated versions of the raw) information can't be globally distributed. This is the one persuasive argument I've heard for IDRP/BGP-like protocols for policy-sensitive routing. I'm not sure I buy the requirement as important, but the logical consequences seem inescapable. Dave. From owner-big-internet@munnari.oz.au Thu Jul 30 06:32:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05800; Thu, 30 Jul 1992 06:42:47 +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 AA26362; Wed, 29 Jul 1992 22:50:24 +1000 (from Garrett.Wollman@UVM.EDU) Received: by sadye.emba.uvm.edu id AA03817 (5.65/1.23); Wed, 29 Jul 92 08:49:00 -0400 Date: Wed, 29 Jul 92 08:49:00 -0400 From: Garrett.Wollman@UVM.EDU Message-Id: <9207291249.AA03817@sadye.emba.uvm.edu> To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu, smart@mel.dit.csiro.au Subject: Re: Route fragments, a routing proposal In-Reply-To: <9207290629.AA08607@ginger.lcs.mit.edu> References: <9207290629.AA08607@ginger.lcs.mit.edu> On Wed, 29 Jul 92 02:29:44 -0400, jnc@ginger.lcs.mit.edu (Noel Chiappa) said: > [Regarding what hosts can do with PIP-style addresses...] > About the only useful thing you can do with things where you > understand the syntax, but not the semantics, is read and print them in > convenient forms. You can't really use them fully, since you don't know what > they *mean*, really. It seems to me that part of the whole point of PIP was that PIP RD's (when used in the mode of JNC `addresses') don't *have* to `mean' anything at all to the hosts, at least in the simplest mode of operation. The host has to know what its address is(*), and it has to know the PIP and link-layer addresses of a nearby router for every interface it wants to send PIP-grams on, but other than that, it can get by without knowing anything else about the `meaning' of an RD. After all, it is a `routing directive', intended for routers. This is not to say that the address *cannot* have host-visible semantics; only that it doesn't have to. Indeed, ``dumb'' and ``smart'' hosts can converse (provided that connectivity is reflexive when using address selected by the ``smart'' host) with the ``dumb'' host being none the wiser. This seems to me to be the whole point of PIP: changes in routing and addressing outside of the local interfaces are invisible to hosts which interpret the RD minimally. Such hosts might not take advantage of useful features of a new network architecture, but they won't break because of them either. Now, if you want to define ``address'' in the PIP world as being the pair < RD, EPID >, then you have created a definition where there already are semantics defined for the address, since by definition the EPID is a globally unique identifier. -GAWollman -- Garrett A. Wollman = wollman@emba.uvm.edu = UVM is welcome to my opinions = uvm-gen!wollman = That's what being alive is all about. No deity, no higher goal exists, than to bring joy to another person. - Elf Sternberg From owner-big-internet@munnari.oz.au Thu Jul 30 07:40:35 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA06879; Thu, 30 Jul 1992 07:51:11 +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 AA29175; Thu, 30 Jul 1992 00:26:23 +1000 (from kasten@ftp.com) Received: by ftp.com id AA07415; Wed, 29 Jul 92 10:25:54 -0400 Date: Wed, 29 Jul 92 10:25:54 -0400 Message-Id: <9207291425.AA07415@ftp.com> To: Big-Internet@munnari.oz.au Subject: Re: iv7 congestion control From: kasten@ftp.com (Frank Kastenholz) Cc: end2end-interest@ISI.EDU hi i really think that having the network protocol make assumptions as to the behavior and desires of the transport protocol is a bad thing. if the wrong assumption is made then things _might_ be made catastrophically worse. the transport has a means of telling the network what it wants -- the type of service (in the generic sense, not necessarily IPv4's TOS and Precedence fields). while we do not completely understand tos, what it means, how to route it, etc, this is the hint that the user of the network (e.g. the transport protocol) gives to the network as to how the net should treat that user's packets. -- frank kastenholz From owner-big-internet@munnari.oz.au Fri Jul 31 05:59:47 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA00268; Fri, 31 Jul 1992 06:00:15 +1000 (from owner-big-internet) Return-Path: Received: from due.unit.no by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27364; Wed, 29 Jul 1992 23:47:54 +1000 (from arnej@due.unit.no) Received: by due.unit.no id AA11383 (5.65b/IDA-1.4.3.1 for Big-Internet@munnari.oz.au); Wed, 29 Jul 92 15:47:22 +0200 Date: Wed, 29 Jul 92 15:47:22 +0200 From: Arne Henrik Juul Message-Id: <9207291347.AA11383@due.unit.no> To: Big-Internet@munnari.oz.au Subject: Re: some nits > From: minshall@wc.novell.com > > There are some little nits in current host IP implementations which make > it slightly difficult to remove all topological information from IP > addresses (ID's): > > 1. Many hosts don't react well if they are told that the local > router is on a different subnet (addr&mask == addr&mask) from the host's > address on a given interface. [Well, you could say the subnet mask is > zero, but ...] But what? This should be doable. Admittedly, some hosts have really bad IP implementations, that either disallows subnet masks at all or don't understand them properly. Many hosts also allows you to tell them "don't try to find a router, just ARP it out on the ethernet" with some suitable route add default `hostname` 0 (sun) or route add default interface `hostname` (386bsd). This is what we currently do for a lot of the subnets at the University, as we have a big broadband/bridged network with many subnets (~30 earlier, somewhat reduced now by router purchasing) on the same physical cable. > 2. If two hosts are on the same physical subnet but NOT on the same > logical subnet (addr&mask == again...), they are going to want to talk > to each other through a router. If we had ES-IS, then IF there were a > router, the router could redirect them. [Well, you could say the subnet > mask is zero, but ...] Again 'but what?' > 3. If two hosts are on different physical subnets but on the same > logical subnet, they are going to ARP for each other (i don't need to go > on, do i?)... [Well, you could say the subnet mask is all ones, but ...] Yes: this is the reason for 'proxy arp': The router between the two subnets needs to understand where to route the packets anyway, all we need is to answer the ARP request with a 'send it to the router' answer. Most modern routers have this function, but you can also have this functionality in some other box in the network. (Like our Sparcstation answering ARP requests for other nets: when A arps for B's ethernet address, the machine answers with an arp package saying "I have B's IP adress and C's ethernet adress" neither of which are true.) This IS a big violation and probably a bit messy in practice, so we'll probably try to avoid it if we can, but any backwards-compatible solution will probably introduce some mess. > Again, nits. But, sometimes nits, nails, horseshoes, ... > > Greg Minshall I hope I have reduced the horseshoe to a nail at least :-) (Lurker going into hiding again), Arne H. Juul (arnej@lise.unit.no) From owner-big-internet@munnari.oz.au Fri Jul 31 06:20:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01196; Fri, 31 Jul 1992 06:20:58 +1000 (from owner-big-internet) Return-Path: Received: from GINGER.LCS.MIT.EDU by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29473; Thu, 30 Jul 1992 00:44:02 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10435; Wed, 29 Jul 92 10:43:48 -0400 Date: Wed, 29 Jul 92 10:43:48 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207291443.AA10435@ginger.lcs.mit.edu> To: J.Crowcroft@cs.ucl.ac.uk, jnc@ginger.lcs.mit.edu Subject: Re: iv7 congestion control Cc: Big-Internet@munnari.oz.au, des@spock.retix.com, end2end-interest@isi.edu, jnc@ginger.lcs.mit.edu i think you are making BIG assumptions about TCPv7 here Huh? I'm not talking about TCPv7 (I know Gary was). I'm talking about what we can do already in IP4 and TCP4. Noel From owner-big-internet@munnari.oz.au Fri Jul 31 06:35:53 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA01734; Fri, 31 Jul 1992 06:36:01 +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 AA29741; Thu, 30 Jul 1992 01:03:21 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11885; Wed, 29 Jul 92 11:03:03 -0400 Date: Wed, 29 Jul 92 11:03:03 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207291503.AA11885@ginger.lcs.mit.edu> To: Big-Internet@munnari.oz.au, Garrett.Wollman@uvm.edu Subject: Re: Route fragments, a routing proposal Cc: jnc@ginger.lcs.mit.edu The host has to know what its address is(*), and it has to know the PIP and link-layer addresses of a nearby router for every interface it wants to send PIP-grams on, but other than that, it can get by without knowing anything else about the `meaning' of an RD. This can be true of almost any address design you care to name; the host can treat them all as byte strings. Now, if you want to define ``address'' in the PIP world as being the pair < RD, EPID >, then you have created a definition where there already are semantics defined for the address, since by definition the EPID is a globally unique identifier. Again, true, but so what? The point of my message was that I think you have to design the routing first because i) you need to optimize the semantics of addresses to help the routing (which has some difficult things to do, and needs all the help it can get from the semantics of its principal data object), and ii) you can't finalize the complete semantics until the routing is done anyway. Noel From owner-big-internet@munnari.oz.au Fri Jul 31 06:48:24 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA02341; Fri, 31 Jul 1992 06:48:30 +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 AA29687; Thu, 30 Jul 1992 00:57:47 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA11793; Wed, 29 Jul 92 10:57:20 -0400 Date: Wed, 29 Jul 92 10:57:20 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207291457.AA11793@ginger.lcs.mit.edu> To: Z.Wang@cs.ucl.ac.uk, desjardi@boa.gsfc.nasa.gov Subject: Re: Host Identifier and Location Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu In current Internet, we have domain names (sort of host IDs) True, in some sense, but remember that the form of the name for an object is as important as what it names, and the form of DNS names is one that is useful for administration, lookup, and humans. None of these attributes is what is needed in the form of the names for identifiers we have been discussing, which are shortish (8 character; short compared to DNS names), fixed length, binary (needed to get enough combos out of 8 bytes), etc. For example, in Pip, the host ID is translated to the address at the source host (ie. outside the communication subnet) and the address is carried in packets for routing. According to a recent conversation with Paul (at the IETF), he has now concluded that basically all PIP packets will now carry the identifier; it's not optional any more, as I understand it. In Ni[mr]od, the host ID is translated by routers during setup No, NO, ***NO***! (To use a phrase I'm beoming fond of! :-) It does do this, but only as a TEMPORARY, digusting, kludgy, nasty, painful, ugly, HACK to allow interoperability for old hosts which have not been updated. This is a deployment WART, nothing more. Once things are deployed and working, the host will look up the identifier *and* the new type address in the same DNS query, and (unspecified magic) it gets to the router from the host. the host ID is carried in packets for routing. The identifier may be used as a cache tag for *forwarding*; there is nothing you can do with the identifier *directly* to do *routing*; that's the whole point of an identifier! Noel From owner-big-internet@munnari.oz.au Fri Jul 31 06:59:40 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AB02942; Fri, 31 Jul 1992 06:59: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 AA29395; Thu, 30 Jul 1992 00:40:58 +1000 (from jnc@ginger.lcs.mit.edu) Received: by ginger.lcs.mit.edu id AA10403; Wed, 29 Jul 92 10:40:34 -0400 Date: Wed, 29 Jul 92 10:40:34 -0400 From: jnc@ginger.lcs.mit.edu (Noel Chiappa) Message-Id: <9207291440.AA10403@ginger.lcs.mit.edu> To: jnc@ginger.lcs.mit.edu, minshall@wc.novell.com Subject: Re: some nits Cc: big-internet@munnari.oz.au, jnc@ginger.lcs.mit.edu Ah, believe, me, I've sweated blood over these. I didn't think up a really good solution at the time I wrote the Nimrod document; there is some handwaving in section 7.2, but it's not real good. You missed the worst case, which is when you are on a network which doesn't use ARP, and in which the network hardware address is embedded directly in the IP address; you *have* to allocate 32-bit thingys in blocks here. Bob Smart has since contributed a very useful idea, which should really help. His idea is to use ARP, on networks which use ARP, to make this work. (I know, I know, another disgusting ARP kludge, just the kind of thing I hate. Sigh, interoperability means doing the nasty things...) This should really help, since when subnets were introduced, we went through a phase where hosts didn't have the mask code in them, and ARP-subnet-routing kept the system running while we got that out. The idea is that we make the hosts on nets with ARP treat the world like one giant subnet (i.e. mask 0). Every router looks like it's local, and all hosts are ARP'ed for directly; local hosts respond directly. Whenever a host tries to get to a host on another wire, the appropriate router responds with the ARP reply. It is kludgy, slow, nasty, and expensive, but it will work. In the longer run, there are a number of good reasons (i.e. not just identifier type interoperability schemes like Nimrod) to get rid of the match and mask code in the hosts, and rely entirely on the routers to know what's where. One is the 'shortcut routing' stuff coming through in IPLPDN, to handle giant WAN networks, such as SMDS etc. They don't want to make the entire WAN packet network one IP network (don't ask), but they want hosts in different IP logical networks on 'the' WAN network to talk directly, not through a router, since the extra hop(s) through the router(s) will cost money. This currently breaks the IP model, since hosts assume that to get off their IP network, they have to go to a router. Even if the router sends them an ICMP Redirect to the destination host, they will toss it, since it looks like they are being redirected to a first hop which is not on the local IP network. When you think about it for a while, there are a number of places where it seems like the current model of having the hosts assume they know something (albeit a lot less than when we started on IP in the late 70's :-) about where destination is is not working well either, and we ought to put the entire decision in the routers, thereby getting *all* routing decisions out of the hosts, letting us do whatever we like to routing. The algorithms becomes i) all hosts have one or more routers, ii) all packets for destinations not in the cache are sent to a (random?) router, iii) if the router is not the right first hop router, or the host can get to the destination directly, the host gets an ICMP Redirect. I just handwaved past how you prevent bogus ICMP Redirects (filter incoming ICMP's out in the border routers, or use authentication if you are really paranoid), what to do on networks with no routers (try sending all packets directly to the destination - has to work :-), etc. This is a pretty easy fix; you just have to remove code. Since a number of different things all seem to want the same mechanism, that says to me that there's a good chance it's the Right Thing. Noel From owner-big-internet@munnari.oz.au Fri Jul 31 07:02:32 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03076; Fri, 31 Jul 1992 07:02:40 +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 AA00102; Thu, 30 Jul 1992 01:26:28 +1000 (from desjardi@boa.gsfc.nasa.gov) Received: by boa.gsfc.nasa.gov (5.57/Ultrix3.0-C) id AA04922; Wed, 29 Jul 92 11:26:02 -0400 Message-Id: <9207291526.AA04922@boa.gsfc.nasa.gov> Subject: Host identifier length To: jnc@ginger.lcs.mit.edu Date: Wed, 29 Jul 92 11:26:02 EDT From: Dick desJardins Cc: big-internet@munnari.oz.au X-Mailer: ELM [version 2.3 PL11] Noel, The proposal for a fixed-length 8-byte Host Identifier is a *Good Idea* if we embed the shorter identifiers (e.g., IEEE Ethernet address, existing IP address) in it. This allows them to be used in six-byte or four-byte format situations (CLNP, IP) until the high order two bytes becomes significant later. We can design a new NSAP format using an Internet AFI that provides eight bytes for System ID. That would allow things to keep working in the mid-term, while putting a stake in the ground for the long-term designers. I'll have to take a while to respond to your comments on the Host Location part of my suggestions. As a quick response, they're more long-term solution oriented. That's good: we have to get that right. But we also have to operate in the mid-term. So the evaluation criterion is does it allow us to keep operating and at the same time evolve to the long term desirable state (which may be fuzzy but some of the principles may be clear). Dick dJ From owner-big-internet@munnari.oz.au Fri Jul 31 07:09:02 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03331; Fri, 31 Jul 1992 07:09:14 +1000 (from owner-big-internet) Return-Path: Message-Id: <9207302109.3331@munnari.oz.au> Received: from bells.cs.ucl.ac.uk by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA29917; Thu, 30 Jul 1992 01:18:24 +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 ; Wed, 29 Jul 1992 16:17:50 +0100 To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: big-internet@munnari.oz.au Subject: Re: Host Identifier and Location In-Reply-To: Your message of "Wed, 29 Jul 92 10:57:20 EDT." <9207291457.AA11793@ginger.lcs.mit.edu> Date: Wed, 29 Jul 92 16:17:48 +0100 From: Zheng Wang > In current Internet, we have domain names (sort of host IDs) > >True, in some sense, but remember that the form of the name for an object >is as important as what it names, and the form of DNS names is one that is >useful for administration, lookup, and humans. None of these attributes >is what is needed in the form of the names for identifiers we have been >discussing, which are shortish (8 character; short compared to DNS names), >fixed length, binary (needed to get enough combos out of 8 bytes), etc. The current Internet does not provide a binary equivalent of domain name simply because it is not carried by the packets. >According to a recent conversation with Paul (at the IETF), he has now >concluded that basically all PIP packets will now carry the identifier; >it's not optional any more, as I understand it. Pip includes Host IDs from the very first version. But the point is that the Host IDs are not used for forwarding. > In Ni[mr]od, the host ID is translated by routers during setup > > No, NO, ***NO***! (To use a phrase I'm beoming fond of! :-) It does >do this, but only as a TEMPORARY, digusting, kludgy, nasty, painful, ugly, >HACK to allow interoperability for old hosts which have not been updated. >This is a deployment WART, nothing more. > Once things are deployed and working, the host will look up the >identifier *and* the new type address in the same DNS query, and >(unspecified magic) it gets to the router from the host. Does the packet contains both Host IDs and the new type of address??? > the host ID is carried in packets for routing. > >The identifier may be used as a cache tag for *forwarding*; there is nothing >you can do with the identifier *directly* to do *routing*; that's the whole >point of an identifier! Okay, I should have used forwarding instead of routing. Cheers Zheng From owner-big-internet@munnari.oz.au Fri Jul 31 07:12:27 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03476; Fri, 31 Jul 1992 07:12:36 +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 AA01387; Thu, 30 Jul 1992 02:30:09 +1000 (from braden@ISI.EDU) Received: from braden.isi.edu by venera.isi.edu (5.65c/5.65+local-6) id ; Wed, 29 Jul 1992 09:31:51 -0700 Date: Wed, 29 Jul 1992 09:29:33 -0700 From: braden@ISI.EDU Posted-Date: Wed, 29 Jul 1992 09:29:33 -0700 Message-Id: <199207291629.AA04650@braden.isi.edu> Received: by braden.isi.edu (5.65c/4.0.3-4) id ; Wed, 29 Jul 1992 09:29:33 -0700 To: Big-Internet@munnari.oz.au, FORTINP@BNR.CA Subject: Re: iv7 congestion control - tradeoff point? This would be most welcome (operationally vs architecturally) even as a way of overcoming the current NFS over WAN problems we constantly experience: fixed timers vs dynamic traffic loading on WAN. _Other_ flows congesting the net which causes more NFS traffic which becomes _other_ to the _other_ flows... Hundreds of NFS mounts across DS-3/FDDI are no less immune than one over a slow link; this should be scalable (that word again :^) and worth doing... Does anyone have any idea where the tradeoff between implementing/ignoring this would be in existing routers (and at which bandwidths & queue sizes)? In the case of large-buffer multi-packet services like NFS, isn't it likely many originals/duplicates will be dropped by a full queue anyway during congestion periods resulting in more retransmissions which add to the problem, but with no dups in the queues to be detected/discarded? Besides, there are usually so many other flows that relative to the queue sizes, the chances of finding duplicates start approaching that of lotteries. And if the traffic is light (little or no congestion), why bother? Can you say "network avalanche"...? :^) Pierre This topic is certainly misplaced on this list... end2end-interest would be much more appropriate. But since you have started the music, I can't help singing. What we are missing is a transaction transport protocol. Each UDP-based application like NFS implicitly builds a transport protocol at the application layer. A transport protocol is a non-trivial beast, and needs to be done every bit as carefully as TCP, including adequate congestion control machinery -- RTT estimation, exponential backoff, slow start, etc, etc. If you don't, you get all the congestion collapse effects we discovered with TCP, and Van fixed. Or, we could do all this work once in the kernel, in a proper transaction transport protocol. See RFC-955. Now I suggest again that transport protocol and congestion issues don't belong on this list. Solving the big Internet problem seems like enough of a challenge... Bob Braden From owner-big-internet@munnari.oz.au Fri Jul 31 07:24:39 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA03920; Fri, 31 Jul 1992 07:24:47 +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 AA00983; Thu, 30 Jul 1992 02:10:23 +1000 (from callon@bigfut.enet.dec.com) Received: by inet-gw-2.pa.dec.com; id AA14744; Wed, 29 Jul 92 09:10:00 -0700 Received: by us1rmc.bb.dec.com; id AA03825; Wed, 29 Jul 92 12:07:12 -0400 Message-Id: <9207291607.AA03825@us1rmc.bb.dec.com> Received: from bigfut.enet; by us1rmc.enet; Wed, 29 Jul 92 12:07:13 EDT Date: Wed, 29 Jul 92 12:07:13 EDT From: Ross Callon To: big-internet@munnari.oz.au Cc: callon@bigfut.enet.dec.com Apparently-To: big-internet@munnari.oz.au Subject: re: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) I think that NSAPs are subject to a fair amount of mis-understanding. I have not been involved in ISO meetings for several years, but was involved in off-line discussions about the AFI for IP. My understanding is that there were two reasons why one wasn't assigned up to now: - Some minor concerns about the decimal IDI: In the past, IDIs were assigned in decimal (represented in BCD when carried in binary fields). The old proposal was to represent a binary IP address in the IDI as binary. However, this problem shouldn't matter now for two reasons: First of all, it would not be necessary to carry the IP address in the IDI. An AFI for IP (or for the ISOC) could have a null IDI, and then a binary DSP assigned however we want it (for the unitiated unfamiliar with OSI terminology, this means that the first byte would be a value assigned by ISO, which if represented in hex would just happen to be using the digits 0 through 9 but not the digits A through F, and the rest could be a binary field assigned however we felt like). Also, the most recent re-write of the Network service definition (including the Network address specification) have removed the coupling between binary and decimal address encodings, which means that now an address can be purely binary and does not have to be capable of being represented in decimal. - Some significant concerns about what we wanted to do with the AFI: Over the last year, there have been all sorts of different proposals regarding what we generally had in mind for an IP AFI. There was one proposal that this be used to carry IP address information in NSAP address fields in IDPR, to be used for routing IP traffic (this proposal was overtaken by the preferred method of admitting that an IP address is a different thing than an NSAP address, and allowing IP addresses to have their own field). There was another proposal to carry IP addresses as the low order part of a longer NSAP address (somewhat similar to the current IPAE proposal of having the IP address be the low order part of a longer global IPAE address). My recollection was that there were also other very different uses proposed, although I don't recall all of the details. My second-hand recollection is that the main reason that an AFI was not already assigned to IP or to the ISOC is that we hadn't the foggiest notion of what in general we were planning to use it for. The resolution that I remember was basically "we would be very happy to assign an AFI for IP or the ISOC, but come back when you have figured out whether you need one". There is one other issue here: We have to decide whether we actually need our own address space. My *very* rough back-of-the-envelope calculation suggests that the format already used by US GOSIP / ANSI / OSINET / european CLNP pilot will be able to scale to several orders of magnitude larger than anyone is projecting the Internet could possible scale to (I even allowed for a possible Chinese PTT delivering CLNP service to a LAN in every home in China). Naturally, it is very hard to figure out how to make such projections, and any projections are likely to be controversial and full of contigency plans, given that we really don't know how an infrastructure for 10^9 administrative domains will be put together (eg, will there be more than 10,000 public providers worldwide? If so, then will they be structured in some way to facilitate routing between them). We might however want to have our own AFI so that we can have greater control over the manner in which addresses are assigned in the Internet. Ross From owner-big-internet@munnari.oz.au Fri Jul 31 08:07:54 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA05285; Fri, 31 Jul 1992 08:08:00 +1000 (from owner-big-internet) Return-Path: Received: from [129.213.128.4] by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA11516; Thu, 30 Jul 1992 11:13:28 +1000 (from cmj@bridge2.NSD.3Com.COM) Received: from jaspar.NSD.3Com.COM by bridge2.NSD.3Com.COM with SMTP id AA07745 (5.65c/IDA-1.4.4nsd for ); Wed, 29 Jul 1992 18:08:41 -0700 Received: by jaspar.NSD.3Com.COM id AA12212 (5.65c/IDA-1.4.4-910730); Wed, 29 Jul 1992 18:08:39 -0700 Date: Wed, 29 Jul 1992 18:08:39 -0700 From: "Cyndi M. Jung" Message-Id: <199207300108.AA12212@jaspar.NSD.3Com.COM> To: dave@sabre.bellcore.com Subject: Re: some thoughts Cc: big-internet@munnari.oz.au (Groan...)--CLNP really got stuffed on this one, too. There are security options--3 of them--well, actually, there are place-holders for (of course) variable length security options, but no one has ever bothered to think about what they should be. GOSIP II defines security options for CLNP which are fully aligned (identical) to the IP security option defined in RFC1108, except, of course, how they are identified in the context of a CLNP PDU. From owner-Big-Internet@munnari.oz.au Fri Jul 31 09:17:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA07618; Fri, 31 Jul 1992 09:17:38 +1000 (from owner-Big-Internet) Return-Path: Received: from gateway.bnr.ca by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA07609; Fri, 31 Jul 1992 09:17:31 +1000 (from FORTINP@BNR.CA) Received: from BNRECADA.BNR.CA by gateway.bnr.ca (5.61/1.34) id AA19150; Thu, 30 Jul 92 19:17:08 -0400 Message-Id: <9207302317.AA19150@gateway.bnr.ca> Received: from BNRECADA.BNR.CA by BNRECADA.BNR.CA (IBM VM SMTP R1.2.1) with BSMTP id 5703; Thu, 30 Jul 92 19:15:16 EDT Date: 30 Jul 92 19:18:00 EDT To: braden@ISI.EDU, From: Pierre (P.) Fortin Subject: Re: iv7 congestion control - tradeoff point? Sender: Pierre (P.) Fortin Bob, Thanks for the info [deleted]. > This topic is certainly misplaced on this list... end2end-interest > would be much more appropriate. But since you have started the music, > I can't help singing. Totally agree. I suppose I might have started the music, but only in response to a request... :^) I suppose I was too subtle... ...but precisely why I added the last paragraph which ended with: > sizes, the chances of finding duplicates start approaching that of lotteries. > And if the traffic is light (little or no congestion), why bother? or: a) Chances are slim, and b) not too likely, so.............^^^^^^^^^^^ Cheers, Pierre - 30 - From owner-Big-Internet@munnari.oz.au Fri Jul 31 10:43:17 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09690; Fri, 31 Jul 1992 10:43:25 +1000 (from owner-Big-Internet) Return-Path: Received: from thumper.bellcore.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA09685; Fri, 31 Jul 1992 10:43:17 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Thu, 30 Jul 92 20:35:23 EDT Received: by chiya.bellcore.com (4.1/4.7) id for pip@thumper.bellcore.com; Thu, 30 Jul 92 20:35:22 EDT Date: Thu, 30 Jul 92 20:35:22 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207310035.AA03175@chiya.bellcore.com> To: big-internet@munnari.oz.au, pip@thumper.bellcore.com Subject: Re: Host Identifier and Location > > For example, in Pip, the host ID is translated to the address > at the source host (ie. outside the communication subnet) and > the address is carried in packets for routing. > > According to a recent conversation with Paul (at the IETF), he has now > concluded that basically all PIP packets will now carry the identifier; > it's not optional any more, as I understand it. > My latest thinking is that the ID should be with all packets, and before the routing info (which is variable length). Therefore, the "fixed" part of the Pip header will have the IDs. Many routers will not need to look at this info, but I guess that many will, for instance for filtering purposes, billing, or perhaps even flow identification (although this can be done using the RD as well). But, this and many other aspects of Pip are open to debate. I think I have provided an interesting and strong starting point, but could use lots of other opinions on Pip. PT From owner-Big-Internet@munnari.oz.au Fri Jul 31 10:53:31 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA09861; Fri, 31 Jul 1992 10:53: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 AA09857; Fri, 31 Jul 1992 10:53:31 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Thu, 30 Jul 92 20:53:27 EDT Received: by chiya.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Thu, 30 Jul 92 20:53:25 EDT Date: Thu, 30 Jul 92 20:53:25 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207310053.AA03217@chiya.bellcore.com> To: Big-Internet@munnari.oz.au Subject: Question on Clark's route fragments I have a question about Dave Clark's route fragments, in particular about the fact that all domains get their own number out of a flat number space, rather than assigning hierarchical numbers (where domains with different parent's can have the same number). In the examples Dave gave, the route fragments were specified only down to the stub domain. But of course the route fragment (or some other routing information) must specify down to the host, so an "area" (subnet) and "host" must be appended to the route fragment: NSFNet-JVNCnet-Bellcore-AreaX-HostY. If the numbers used to identify each thing in the fragment all come from the same flat space, then the space must be quite large--large enough to accomodate all hosts. So, probably each identifier must be 8 bytes long (this is the length that people have been talking about for the host ID part of various new internet protocols). This makes the above route fragment 40 bytes long, same as two NSAP addresses. But, there will be a source route fragment and optionally a middle part. So, the header could get really huge. Do people see this as a problem (I know that there are some "slow link" people that see even CLNP header as too large, but what about "fast link" people)? If we assume one identifier per domain instead of one per host, then perhaps we can get away with 4 bytes per identifier, and so the length of a route-fragment header approaches that of CLNP (but still longer). But this complicates the lookup process, because now routers have to know the context within which they are routing (is this a domain or an area or a host?). I wonder that if you are going to have this kind of lookup anyway, perhaps it is best just to have nested hierarchical numbers everywhere. Just a thought, PT From owner-big-internet@munnari.oz.au Fri Jul 31 13:02:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA12559; Fri, 31 Jul 1992 13:03:00 +1000 (from owner-big-internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA06443; Fri, 31 Jul 1992 08:49:27 +1000 (from dkatz@cisco.com) Received: by cider.cisco.com; Thu, 30 Jul 92 15:21:32 -0700 Date: Thu, 30 Jul 92 15:21:32 -0700 From: Dave Katz Message-Id: <9207302221.AA14244@cider.cisco.com> To: callon@bigfut.enet.dec.com Cc: big-internet@munnari.oz.au, callon@bigfut.enet.dec.com In-Reply-To: Ross Callon's message of Wed, 29 Jul 92 12:07:13 EDT <9207291607.AA03825@us1rmc.bb.dec.com> Subject: Re: NSAP AFI for IP (was: ISO SC6 meeting tidbits) First of all, it would not be necessary to carry the IP address in the IDI. An AFI for IP (or for the ISOC) could have a null IDI, and then a binary DSP assigned however we want it I think this is true only if ISO actually assigns the AFI to ISOC; otherwise, the trail of adminstrative authority is lost. One of the functions of the NSAP structure is to show a clear hierarchy of administrative authority. The only reason that the "local AFIs" (48/49) can be owned by ISO and have no IDI is because there is *no* administrative authority defined for such addresses. Think about it--what would 8348 say about this AFI w/o IDI? Also, the most recent re-write of the Network service definition (including the Network address specification) have removed the coupling between binary and decimal address encodings, which means that now an address can be purely binary and does not have to be capable of being represented in decimal. This does syntactically make binary IDIs possible; however, unless there has been a change to the appropriate parts of 8348, it still says that the IDI has decimal abstract syntax (meaning that only decimal numbers are valid, which are then encoded as BCD). This would have the side effect of making the abstract syntax of the IDI dependent on the AFI (the existing IDIs must continue to be decimal), which is not currently true (not that it's a huge problem). address fields in IDPR, to be used for routing IP traffic Careful, you mean IDRP! There is one other issue here: We have to decide whether we actually need our own address space. My *very* rough back-of-the-envelope calculation suggests that the format already used by US GOSIP / ANSI / OSINET / european CLNP pilot will be able to scale to several orders of magnitude larger than anyone is projecting the Internet could possible scale to (I even allowed for a possible Chinese PTT delivering CLNP service to a LAN in every home in China). Naturally, it is very hard to figure out how to make such projections, and any projections are likely to be controversial and full of contigency plans, given that we really don't know how an infrastructure for 10^9 administrative domains will be put together (eg, will there be more than 10,000 public providers worldwide? If so, then will they be structured in some way to facilitate routing between them). The assignment of an ICD value to ISOC would add three octets to the space already available, even if a version number octet were included *and* assuming that the GOSIP/ANSI "reserved" field was used in the current addressing structure. An AFI would add two more. We might however want to have our own AFI so that we can have greater control over the manner in which addresses are assigned in the Internet. I think this is a red herring; ISOC has complete control over the chunk of address space assigned to it, regardless of where the ISOC address space branches off of the tree (AFI, ICD, GOSIP AAI). From owner-Big-Internet@munnari.oz.au Fri Jul 31 14:22:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14674; Fri, 31 Jul 1992 14:22:57 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA14667; Fri, 31 Jul 1992 14:22:43 +1000 (from vaf@Valinor.Stanford.EDU) Received: from Valinor.Stanford.EDU by relay2.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA08245; Thu, 30 Jul 92 21:33:18 -0400 Received: by Valinor.Stanford.EDU (5.65/inc-1.0) id AA00394; Thu, 30 Jul 92 18:33:03 -0700 Date: Thu, 30 Jul 92 18:33:02 PDT From: Vince Fuller To: jnc@ginger.lcs.mit.edu (Noel Chiappa) Cc: minshall@wc.novell.com, big-internet@munnari.oz.au Office: Spruce Hall F15, (415) 723-6860 Usmail: Pine Hall 115, Stanford, CA, 94305-4122 Subject: Re: some nits In-Reply-To: Your message of Wed, 29 Jul 92 10:40:34 -0400 Message-Id: iii) if the router is not the right first hop router, or the host can get to the destination directly, the host gets an ICMP Redirect. I just handwaved past how you prevent bogus ICMP Redirects (filter incoming ICMP's out in the border routers, or use authentication if you are really paranoid), what to do on networks with no routers (try sending all packets directly to the destination - has to work :-), etc. This is a pretty easy fix; you just have to remove code. Since a number of different things all seem to want the same mechanism, that says to me that there's a good chance it's the Right Thing. One reason why some of us don't like to depend on redirects is that on a subnet with multiple exit points (routers) there is no way to reroute if the router to which one is redirected dies. This needs to be fixed. Unfortunately, the router discovery people punted on this the first time out. This is one reason why RIP is still commonly used as an router discovery protocol (and RIP-II will do this job even *better* 1/2 :-) --Vince From owner-Big-Internet@munnari.oz.au Fri Jul 31 14:27:51 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14859; Fri, 31 Jul 1992 14:28:00 +1000 (from owner-Big-Internet) Return-Path: Received: from uunet by munnari.oz.au with UUCP (5.83--+1.3.1+0.50) id AA14853; Fri, 31 Jul 1992 14:27:51 +1000 (from atkinson@itd.nrl.navy.mil) Received: from itd.nrl.navy.mil by relay1.UU.NET with SMTP (5.61/UUNET-internet-primary) id AA24383; Thu, 30 Jul 92 21:39:03 -0400 Received: by itd.nrl.navy.mil (4.1/SMI-4.1) id AA03279; Thu, 30 Jul 92 21:35:06 EDT Date: Thu, 30 Jul 92 21:35:06 EDT From: atkinson@itd.nrl.navy.mil (Randall Atkinson) Message-Id: <9207310135.AA03279@itd.nrl.navy.mil> To: Big-Internet@munnari.oz.au Subject: CLNP & IPSO A small aside: The "IP Security Option" should have been named the "IP Sensitivity label Option" because it really doesn't provide ANY security properties whatsoever. Both current IP and CLNP lack much in the way of real security properties. Some few of us think this is a problem. Most folks don't. I don't think this is really relevant to Big-Internet and so would like to try to direct followups to some other more appropriate place like: USENET's comp.security.misc or maybe the SAAG list... Ran atkinson@itd.nrl.navy.mil From owner-big-internet@munnari.oz.au Fri Jul 31 14:23:43 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA14722; Fri, 31 Jul 1992 14:23:54 +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 AA14064; Fri, 31 Jul 1992 13:59:57 +1000 (from kre@cs.mu.oz.au) Received: from mulga.cs.mu.OZ.AU by shark.mel.dit.csiro.au with SMTP id AA16609 (5.65c/IDA-1.4.4/DIT-1.3 for ); Fri, 31 Jul 1992 13:42:59 +1000 Received: from mundamutti.cs.mu.OZ.AU by mulga.cs.mu.OZ.AU with SMTP (5.64+1.3.1+0.50); id AA12347 Fri, 31 Jul 1992 13:40:08 +1000 (from kre) To: Big-Internet@munnari.OZ.AU Subject: Some comments/queries on PIP Date: Fri, 31 Jul 92 13:38:40 +1000 Message-Id: <28447.712553920@munnari.oz.au> From: Robert Elz Some of this has been going round in my mind for a while, I know I should read all the docs again, and that might answer some of these questions, but in any event it may be an idea to make a fool of myself in public, just in case someone else is wondering about any of the same issues. Before the more substantive issues, I want to set down my position on a couple of minor issues that have been mentioned in the past - this stuff doesn't demand or expect a reply or comment from anyone, it's just for the record. I fully support carrying src & dst ID's in every packet - if Noel's recent message is correct (and I've just seen Paul's confirmation), this is no longer an issue. I believe all packets need a pkt-id field - for lots of reasons, not the least of which is to make monitoring of what's happening on the wire a bit easier (possible to associate what's seen at the monitoring station with what was sent from the host easily) - also so returned packets can be associated with their senders, without presuming anything about the nature of the upper level protocols. I strongly believe that fragmentation is necessary - that its not (often) needed for TCP is no answer, things like UDP, and even ICMP, occasionally need to send > MTU sized packets, making each of them invent a mechanism to support fragmentation is not the right way to go - strictly, fragmentation would be a link level function, as its a link level "feature" that has to be overcome (the limitation on packet sizes), but given that most common link layers provide no reasonable support for frag/reassembly, and also that it can be useful to route frags over different paths, putting it at the net level is reasonable. Higher up is not. So much for just stating my opinions. I am a little unsure that simply undefining away the meaning of the handling directive fields is a sane thing to do. I know that it seems to add flexibility, but I suspect "seems" is as far as it goes. These fields are meaningless unless the router implements some support for them - to do that, it must know what the things might mean - that is, it must understand the semantics of the bits, and except possibly in some rare cases I can't think of right now, those semantics are going to need to be known in the code, or the hardware, not purely in forwarding tables of some kind. To "router" here add "host" for the analagous parts of the packet that might be there to apply to the end host, if there are any. For the semantics to be understood, there's going to need to be agreements reached amongst the implementors of the routers (ie: RFC's written by the IETF) so everyone understands the same meaning for some particular action - that is, its not much good simply defining something to mean "low cost" if in one area, or implementation, that means "forward on links that cost < $0.01 per Mb only", and on another it means "pick the cheapest link that will result in reasonably speedy delivery". Those two things are just different. If the semantics need to be known and agreed in advance, I don't see that it can hurt at all to define the syntax as well at the same time - in this case, that means defining what handling directive bits have this particular defined semantic meaning. I also don't see the use of these directives having possible local meaning only - ie: if I'm a router, and you tell me by whatever means its proposed to be done to "frob my glortznik" in a packet you send me, just what am I supposed to do with that? Just ignore it? Not good if the intended meaning was "do not forward out of the local administrative domain under any circumstances". Or drop packets that contain an unknown hint? If that's it, then hints that aren't "well known" will never be used in practice, or they may result in packets being discarded all over the place. At the very least, if this syntax & semantics undefined field is to be left there, there needs to be some way to distinguish between the cases "ignore this if you don't understand it" and "drop/return this packet if you don't understand this", and that needs to be well defined, and probably settable for each individual hint that's there - which means both that hints can't be single bits, and that the general syntax of the field (two bits/hint, 8 bits/hint, ...) needs to be defined. Next - I'm a little counfsed about how the source address is actually formed - I hnow that as the RHF Offset moves, the part to the left of it (before it) is the "source address" (recversed) - but when the packet arrives at the destination the Offset will be at the rightmost RHF. That means that if the address is reversed (in a fairly dumb fashion) and used as the destination address for a return packet, then its not symmetric with the examples of sending an original packet, where the Offset is originally started beyond the local part of the address. This also raises the question of just how a receiving host makes use of this field - its been assumed in some quarters at least that this can be an opaque bit string - if so, how does the host manage to reverse it in order to form the destination address for a return packet? Actually, I don't think either of these is relevant, as I don't believe that the (receiving) host should use this field for anything at all - I think it should use the sending host ID, and make a directory enquiry based on that as the key to find the destination address to use to return packets. I'd only use the 'reverse the RD' technique in routers that want to send back ICMP type messages. Next to almost make nonsense of (at least) the terminology I've just been using ... As Noel pointed out in a recent message, the "routing directive" is really a source route, its not an address - this raises two points. First, taking an analogy to IPv4 is this source route intended to be a "loose" source route, or a "strict" one? From the examples I've seen, I assume the answer here is "loose". That is, the entry here will point me towards another router, but we may pass through several routers without the RHF Offset being altered at all - all interpreting the same field, and doing some kind of hop by hop forwarding to get the packet to the next RHF, where the Offset will be incremented and the whole thing repeated. That's fine - but might not there be some demand for "strict" source routing as well? That would be interpreted something like "if you don't increment the RHF Offset bounce the packet". What's more, since all this is new, we could get to fix the abberation in IPv4 that doesn't allow LSRR and SSRR to be mixed in one packet - or more correctly, simply doesn't say what the hell that would mean if you did it. Its entirely reasonable for a host to want to get a packet to some point (through some intermediate hops) without being too concerned about exactly where the packets go, but then in one particular region specify a very detailed path for some policy reasons, and then revert to more general control - and perhaps repeat that over and over. To use one of Noel's motoring examples (with apologies to people who don't know California roads at all - I pick this as its the only US example I know well enough ...) you might decide to take 101 north from LA, to San Jose (passing through various places), then 880 to Oakland (again passing through several cities), then specify in detail exactly how you want to exit to Martin Luther King Jr Way, and take that north to Shattuck (sp?) in Ashby, then turn left down University in Berkeley, then onto 80 north, and continue (through various places) to Sacremento. (No, I'm not recommending this as a route from LA to Sacremento). If the RHF is purely an index into a table, and the RHFR is simply "up/down/none" then something else should be added to indicate "strict/loose". Also, also noting that the Routing Hints are really a source route, I wonder a little at exactly how the hosts works out what to put there? Most discussion so far seems to have assumed that some directory server somewhere simply provides this thing as a sequence of bits that the host doesn't interpret. OK - but from where does this directory server get the information - its important to note here that this thing is a route, not an address, which, or course, means that its not a constant per destination, it varies by source/dest pairs. So, the RH's in PIP look like they'd be a good candidate for Dave Clark's route fragments - which may be related to Paul's recent message on that topic. Whether the route fragments are constructed out of host-id's in some form, or table offsets, I don't see is important to the idea. Assuming that, or something like it, then either the sending host, or the directory server it talks to, needs to make routing decisions, and construct the RH from this information. If its the host, then the "opaque bit string" model certainly won't work. If its a directory server, then this is going to need to be an entirely different kind of beast than the DNS or X.500. Finally - and this again goes back to something Noel keeps saying, and that I agree with - I'm not yet convinced that its possible to actually distribute the information that PIP needs to build the RH from the fragments .. that is, I'd like to see an explanation of exactly how those RHF numbers are distributed around the world, and how they actually work as things come and go. Since these are intended to be indices into tables in the router (which very much constrains the implementation of the router incidentally, something I'm not sure I like in a protocol specification), and also as its assumed everywhere that these are all small numbers (not too many bits need to be allocated), then I conclude that these tables are intended to be kept in a fairly compact form. That means that as things go away the table is rearranged - either by re-using old slots for new things that appear (perhaps not so bad), or by simply compacting the table and renumbering everything. Just how this is all done, and how the information is dstributed to everyone else who needs to know it I think needs to be set out more explicitly - at least one example of how it could be done needs to be given. I can't do that, as at the minute I'm not convinced that it can be. By this I think I'm asking for much the same as Noel when he asks for the routing architectire to be specified before anything else - and I think that's probably right, until we do that who knows what else we may decide we should be doing. kre From owner-big-internet@munnari.oz.au Fri Jul 31 15:24:11 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA17177; Fri, 31 Jul 1992 15:24:16 +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 AA09374; Fri, 31 Jul 1992 10:32:57 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Thu, 30 Jul 92 20:31:18 EDT Received: by chiya.bellcore.com (4.1/4.7) id for Big-Internet@munnari.oz.au; Thu, 30 Jul 92 20:31:16 EDT Date: Thu, 30 Jul 92 20:31:16 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207310031.AA03171@chiya.bellcore.com> To: Big-Internet@munnari.oz.au Subject: Re: Route fragments, a routing proposal > > Again, true, but so what? The point of my message was that I think you > have to design the routing first because i) you need to optimize the semantics > of addresses to help the routing (which has some difficult things to do, and > needs all the help it can get from the semantics of its principal data > object), and ii) you can't finalize the complete semantics until the routing > is done anyway. > > Noel > This has all been hashed out before, but so as not to let Noel have the last word, I still maintain that if the "routing" info in the header is general enough (as I believe Pip is), then you can change the semantics of the routing info as the routing algorithm evolves. I believe that Noel and I have agreed to disagree on this, but I would like to hear other opinions about it. PT From owner-Big-Internet@munnari.oz.au Fri Jul 31 16:08:06 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA18530; Fri, 31 Jul 1992 16:08:16 +1000 (from owner-Big-Internet) Return-Path: Received: from cider.cisco.com by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA18520; Fri, 31 Jul 1992 16:08:06 +1000 (from tli@cisco.com) Received: by cider.cisco.com; Thu, 30 Jul 92 23:07:56 -0700 Date: Thu, 30 Jul 92 23:07:56 -0700 From: Tony Li Message-Id: <9207310607.AA28516@cider.cisco.com> To: tsuchiya@thumper.bellcore.com Cc: Big-Internet@munnari.oz.au In-Reply-To: Paul Tsuchiya's message of Thu, 30 Jul 92 20:31:16 EDT <9207310031.AA03171@chiya.bellcore.com> Subject: Route fragments, a routing proposal From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) I believe that Noel and I have agreed to disagree on this, but I would like to hear other opinions about it. Well, ok. You asked for it. I believe that we _cannot_ get routing info in the header to be sufficiently general. This is not intended to be a slight to Pip or Nimrod. It is a simple recognition of the fact that our crystal ball is flawed and that we cannot possibly predict the future applications that we will need to support within the lifetime of this protocol. So given that we cannot possibly do it _right_ today, what do we do? We have to provide the services that we have available now, and we have to leave in the hooks so that we can extend and adapt the protocol to new and interesting environments. So to be concrete, I would advocate a) designing an optimized header for maximal performance in the simplest cases, b) leaving in enough hooks so that we can change the routing algorithm later, and c) insuring that the extension/adaptation mechanism is very efficient, so that there is not a big penalty for processing extensions. Lest anyone accuse me of being creative, please note that this is just a transliteration of Unix design philosophy: Small and extensible is beautiful. I hope that this appeals to at least the gentleman from Bellcore... ;-) Tony From owner-Big-Internet@munnari.oz.au Fri Jul 31 23:14:14 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27282; Fri, 31 Jul 1992 23:14:18 +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 AA27279; Fri, 31 Jul 1992 23:14:14 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 31 Jul 92 09:14:06 EDT Received: by chiya.bellcore.com (4.1/4.7) id for jnc@ginger.lcs.mit.edu; Fri, 31 Jul 92 09:14:05 EDT Date: Fri, 31 Jul 92 09:14:05 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207311314.AA03500@chiya.bellcore.com> To: avalon@coombs.anu.edu.au, jnc@ginger.lcs.mit.edu Subject: Re: Host Identifier and Location Cc: big-internet@munnari.oz.au > > Is there any chance that variable length addresses could be a win for SLIP > or PPP too ? For two hosts on a slow line, they only need 1 byte of > addressing to satisfy that local 'network'. I'm not sure if there are any > real savings here, but 1 byte compared to 8 (for 64bit address) might make a > few people with slow links happy. > > Darren. > This is exactly how Pip works. You only put in as much of the address as you need. So, if the destination is nearby, you get away with quite a small header (although encoding schemes like IPAE tend to wipe out some of the savings by keeping old header stuff for backwards compatibility reasons). But, even over slip, if the destination is "far away" (in a topological sense), then you still need full addressing information (in the absense of header compression). PT From owner-Big-Internet@munnari.oz.au Fri Jul 31 23:33:52 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27536; Fri, 31 Jul 1992 23:33:56 +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 AA27533; Fri, 31 Jul 1992 23:33:52 +1000 (from tsuchiya@thumper.bellcore.com) Received: from chiya.bellcore.com by thumper.bellcore.com (4.1/4.7) id for big-internet@munnari.oz.au; Fri, 31 Jul 92 09:33:40 EDT Received: by chiya.bellcore.com (4.1/4.7) id for smart@mel.dit.csiro.au; Fri, 31 Jul 92 09:33:38 EDT Date: Fri, 31 Jul 92 09:33:38 EDT From: tsuchiya@thumper.bellcore.com (Paul Tsuchiya) Message-Id: <9207311333.AA03533@chiya.bellcore.com> To: Garrett.Wollman@UVM.EDU, jnc@ginger.lcs.mit.edu Subject: Re: Route fragments, a routing proposal Cc: big-internet@munnari.oz.au, smart@mel.dit.csiro.au > > It seems to me that part of the whole point of PIP was that PIP > RD's (when used in the mode of JNC `addresses') don't *have* to `mean' > anything at all to the hosts, at least in the simplest mode of > operation. The host has to know what its address is(*), and it has to > know the PIP and link-layer addresses of a nearby router for every > interface it wants to send PIP-grams on, but other than that, it can > get by without knowing anything else about the `meaning' of an RD. > After all, it is a `routing directive', intended for routers. Yes. Pip should be seen as the "progressable" internet protocol, in the sense that you should be able to progress to knew routing styles while changing the fewest number of systems. So, if hosts are able to operate in dumb mode, then they can be spoon fed the appropriate RD for the given situation (although this obviously requires a smart box somewhere, but it doesn't have to be the host). Even Pip "icmp" messages are (will be?) designed to allow hosts to be very dumb. That is, a router can say to a host "use this RD instead of that RD in these situations", and the host will dumbly accept it. > > Now, if you want to define ``address'' in the PIP world as being the > pair < RD, EPID >, then you have created a definition where there > already are semantics defined for the address, since by definition the > EPID is a globally unique identifier. Did I miss a previous message that set up the context for this? Because, I don't see the point of discussing whether an "address" is RD,EPID pair, or just RD, or just part of the RD, or whatever. An RD is and RD and an EPID is an EPID. PT From owner-Big-Internet@munnari.oz.au Fri Jul 31 23:37:10 1992 Received: by munnari.oz.au (5.83--+1.3.1+0.50) id AA27597; Fri, 31 Jul 1992 23:37:13 +1000 (from owner-Big-Internet) Return-Path: Message-Id: <9207311337.27597@munnari.oz.au> Received: from CLynn.BBN.COM by munnari.oz.au with SMTP (5.83--+1.3.1+0.50) id AA27594; Fri, 31 Jul 1992 23:37:10 +1000 (from clynn@BBN.COM) Date: Fri, 31 Jul 92 8:59:40 EDT From: Charles Lynn To: Paul Tsuchiya Cc: big-internet@munnari.oz.au, pip@thumper.bellcore.com Subject: Re: Host Identifier and Location Folks, Have we agreed to accept the "CI" field for flow identification? If so, it sounds like it ought to be positioned next to the source host ID as that combination uniquely identifies the flow. Charlie